Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 11 Feb 2023 17:10:02 +0000
From:      David Chisnall <theraven@FreeBSD.org>
To:        Shawn Webb <shawn.webb@hardenedbsd.org>
Cc:        freebsd-hackers <freebsd-hackers@freebsd.org>
Subject:   Re: CFT: snmalloc as libc malloc
Message-ID:  <193D1E1C-73EB-42BB-8A6A-87B0E4AD9D7C@FreeBSD.org>
In-Reply-To: <20230210162350.gg5g7dihp3zef3ov@mutt-hbsd>
References:  <2f3dcda0-5135-290a-2dff-683b2e9fe271@FreeBSD.org> <20230210162350.gg5g7dihp3zef3ov@mutt-hbsd>

next in thread | previous in thread | raw e-mail | index | archive | help
On 10 Feb 2023, at 16:23, Shawn Webb <shawn.webb@hardenedbsd.org> wrote:
>=20
> So I took a little bit of a different approach, which should provide
> the same end result as your submodule approach. Note that I'm doing
> this in HardenedBSD 14-CURRENT (the hardened/current/master branch).
>=20
> 1. git cherry-pick -xs a5c83c69817d03943b8be982dd815c7e263d1a83
> 2. git rm -f .gitmodules contrib/snmalloc
> 3. git commit
> 4. git subtree add -P contrib/snmalloc \
>   git@github.com:microsoft/snmalloc.git main
>=20
> I believe this should leave me with a tree that populates
> contrib/snmalloc and pulls in your non-contrib/ changes, leading me to
> end up in the same end state as your submodule approach.
>=20
> I am seeing some build errors. I've uploaded a WITHOUT_CLEAN=3Dyes log
> to:
>=20
> https://hardenedbsd.org/~shawn/2023-02-10_snmalloc-01.log.txt
>=20
> Note that this is with llvm 15.0.7 that just landed in FreeBSD main.

The error is a bit confusing, because nullptr_t has been in libc++ since =
C++11.  Does HardenedBSD change anything in include orders?  Can you add =
-v to the end of the compile command:


c++  -target x86_64-unknown-freebsd14.0 =
--sysroot=3D/usr/obj/data/src/hardenedbsd/amd64.amd64/tmp =
-B/usr/obj/data/src/hardenedbsd/amd64.amd64/tmp/usr/bin =
-fomit-frame-pointer -O2 -pipe -fno-common -DHARDENEDBSD -DNO__SCCSID =
-DNO__RCSID -I/data/src/hardenedbsd/lib/libc/include =
-I/data/src/hardenedbsd/include -I/data/src/hardenedbsd/lib/libc/amd64 =
-DNLS -ftls-model=3Dinitial-exec -D__DBINTERFACE_PRIVATE =
-I/data/src/hardenedbsd/contrib/gdtoa =
-I/data/src/hardenedbsd/contrib/libc-vis -DINET6 =
-I/usr/obj/data/src/hardenedbsd/amd64.amd64/lib/libc =
-I/data/src/hardenedbsd/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE =
-I/data/src/hardenedbsd/lib/libmd =
-I/data/src/hardenedbsd/lib/libc/locale -DBROKEN_DES -DPORTMAP =
-DDES_BUILTIN -I/data/src/hardenedbsd/lib/libc/rpc -DWANT_HYPERV -DYP =
-DNS_CACHING -DSYMBOL_VERSIONING -g -gz=3Dzlib -mretpoline -fPIC -flto =
-MD -MF.depend.malloc.o -MTmalloc.o -Wno-format-zero-length =
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k =
-Wno-uninitialized -Wdate-time -Wno-empty-body -Wno-string-plus-int =
-Wno-unused-const-variable -Wno-error=3Dunused-but-set-variable =
-Wno-error=3Darray-parameter -Wno-error=3Ddeprecated-non-prototype =
-Wno-error=3Dunused-but-set-parameter -Wno-tautological-compare =
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function =
-Wno-enum-conversion -Wno-unused-local-typedef =
-Wno-address-of-packed-member -Wno-switch -Wno-switch-enum =
-Wno-knr-promoted-parameter -Qunused-arguments =
-I/data/src/hardenedbsd/lib/libutil =
-I/data/src/hardenedbsd/lib/msun/amd64 =
-I/data/src/hardenedbsd/lib/msun/x86 --include-directory-after =
/data/src/hardenedbsd/lib/msun/src -DHARDENEDBSD  =
-I/data/src/hardenedbsd/contrib/snmalloc/src/snmalloc -std=3Dc++20 =
-mcx16 -fno-exceptions -fno-rtti -DSNMALLOC_USE_THREAD_CLEANUP =
-DSNMALLOC_BOOTSTRAP_ALLOCATOR -DSNMALLOC_JEMALLOC3_EXPERIMENTAL =
-DSNMALLOC_JEMALLOC_NONSTANDARD -DSNMALLOC_PLATFORM_HAS_GETENTROPY =
-DSNMALLOC_STATIC_LIBRARY_PREFIX=3D__ -ftls-model=3Dinitial-exec =
-DSNMALLOC_CHECK_CLIENT -DSNMALLOC_FAIL_FAST=3Dfalse -DNDEBUG -g =
-gz=3Dzlib -mretpoline -flto    -Wno-c++11-extensions   -c =
/data/src/hardenedbsd/lib/libc/stdlib/snmalloc/malloc.cc -o malloc.o



That should dump the include paths.  It=E2=80=99s possible that the =
libc++ headers are being included in the wrong order with respect to the =
C paths?

David=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?193D1E1C-73EB-42BB-8A6A-87B0E4AD9D7C>