Re: CFT: snmalloc as libc malloc

On Feb 12, 2023, at 14:24, Shawn Webb <shawn.webb@hardenedbsd.org> wrote:

> 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?
> 

Quoting prior content, after showing a find
that indicated no examples in system header
areas, including for llvm15:

QUOTE
So, none for FreeBSD and its llvm15.

This makes sense, https://libcxx.llvm.org/Status/Cxx20.html shows:

P1208R6 LWG Adopt source_location for C++20 Cologne Complete 16.0

So, likely FreeBSD will not have this until it progresses to
LLVM16 . It just changed to LLVM15 in main [so: FreeBSD 14].
END QUOTE


===
Mark Millard
marklmi at yahoo.com