Date: Sun, 12 Feb 2023 12:01:22 -0800 From: Mark Millard <marklmi@yahoo.com> To: shawn.webb@hardenedbsd.org, FreeBSD Hackers <freebsd-hackers@freebsd.org> Cc: David Chisnall <theraven@FreeBSD.org> Subject: Re: CFT: snmalloc as libc malloc Message-ID: <ED93FF21-07BC-4FC0-A114-27424E60C024@yahoo.com> References: <ED93FF21-07BC-4FC0-A114-27424E60C024.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Shawn Webb <shawn.webb_at_hardenedbsd.org> wrote on Date: Sun, 12 Feb 2023 19:44:24 UTC : > On Sat, Feb 11, 2023 at 05:10:02PM +0000, David Chisnall wrote: > > 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. > >=20 > > 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: > >=20 > >=20 > > 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 > >=20 > >=20 > >=20 > > 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? >=20 > Hey David, >=20 > HardenedBSD doesn't have any changes to userland that would cause > changes in include header paths (and the priorities of them.) >=20 > I made sure to `pkg delete -g gcc\* binutils\*` before running another > buildworld, ending up with the same error. >=20 > I tried running your command above. He asked that you add a -v to it. Implicitly also: capture and report the extra text that the -v causes in the output. That extra text covers what the sequence of include paths searched are in the order searched. It shows even the paths for which nothing is/will-be found for the specific compile: where all did the compiler look? Any unexpected places? Any missing places? Any examples of not being in the required order? > Here's the result: > http://ix.io/4nS9 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? > I think Mark might be on the right track with regards to llvm 15. I'll > try importing the snmalloc patch (via the same subtree method) to a > pre-llvm15 import branch and report back. It might be a few days > before I get you a result. >=20 > BTW, I appreciate the work. One long-term goal I've had for > HardenedBSD is to be able to switch between multiple heap > implementations at buildworld-time. I think it would be nifty for > users to have a choice of jemalloc, snmalloc, and GrapheneOS' > hardened_malloc. =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ED93FF21-07BC-4FC0-A114-27424E60C024>