Re: CFT: snmalloc as libc malloc
- Reply: Mark Millard : "Re: CFT: snmalloc as libc malloc"
- In reply to: Mark Millard : "Re: CFT: snmalloc as libc malloc"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 12 Feb 2023 22:24:56 UTC
On Sun, Feb 12, 2023 at 01:48:59PM -0800, Mark Millard wrote: > On Feb 12, 2023, at 13:09, Shawn Webb <shawn.webb@hardenedbsd.org> wrote: > > > . . . > > That does not include the extra text that would be generated > > by having added the -v requested to that shown command line. > > That tet would likely have been before the text that you did > > include. > > > > Did you add the -v option? Was there extra text? > > Good catch. I missed reading that. Here's the new output: > http://ix.io/4nSy > > Hmm. Scanning that list . . . > > #include "..." search starts here: > #include <...> search starts here: > /data/src/hardenedbsd/lib/libc/include > /data/src/hardenedbsd/include > > The above likely includes a non-C++: stddef.h > That likely overrides any: . . ./include/c++/v1/stddef.h > that is required for things to work for the > nullptr_t issue. (See prior E-mail from when > I noticed that I'd missed the include/c++/v1/stddef.h > involved.) > > /data/src/hardenedbsd/lib/libc/amd64 > /data/src/hardenedbsd/contrib/gdtoa > /data/src/hardenedbsd/contrib/libc-vis > /usr/obj/data/src/hardenedbsd/amd64.amd64/lib/libc > /data/src/hardenedbsd/lib/libc/resolv > /data/src/hardenedbsd/lib/libmd > /data/src/hardenedbsd/lib/libc/locale > /data/src/hardenedbsd/lib/libc/rpc > /data/src/hardenedbsd/lib/libutil > /data/src/hardenedbsd/lib/msun/amd64 > /data/src/hardenedbsd/lib/msun/x86 > /data/src/hardenedbsd/contrib/snmalloc/src/snmalloc > /usr/obj/data/src/hardenedbsd/amd64.amd64/tmp/usr/include/c++/v1 > > The above looks to be the first/only chance to pick > up a C++ based file header (that may in turn look > for a C based one as well). > > /usr/lib/clang/15.0.7/include > /usr/obj/data/src/hardenedbsd/amd64.amd64/tmp/usr/include > /data/src/hardenedbsd/lib/msun/src > End of search list. > > The ordering does not look anything like correct > to me relative to C++ headers, some of which in > turn may include the C variants from the environment. > > It is not so clear to me what the relationship is > to the source_location file issue. Also: find /data/src/hardenedbsd -iname '*source_location*' ^ that returns zero results. Are we ("we" being both FreeBSD and HardenedBSD) completely missing a header file somewhere? Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc