On Wed, Feb 21, 2024 at 08:20:25PM +0000, Brooks Davis wrote: > That's probably worth a shot. Static linking will work anyway because > libc.a in effect embeds libsys to retain compatability. Please do not add libsys.so to the ABI. Right now it is an implementation detail of libthr and libc, and it is preferable to not change it, at least not yet, and definitely not to solve some minor internal issues.
> > -- Brooks > > On Wed, Feb 21, 2024 at 09:12:41PM +0100, Dimitry Andric wrote: > > Can't we just add libsys.so to the /usr/lib/libc.so linker script? That > > would work for everything except static linking? > > > > -Dimitry > > > > > On 21 Feb 2024, at 21:00, Brooks Davis <bro...@freebsd.org> wrote: > > > > > > TL;DR: you can work around this by adding -lsys to the link line and I > > > aim to improve the situation soon. > > > > > > The sanitizers reach somewhat questionably into libc internals that are > > > exported to allow rtld to update them. I was unable to find an solution > > > that didn't break this and I felt that fixing things like closefrom() > > > using non-deprecated syscalls was more important than avoiding changes > > > to the sanitizer interface. > > > > > > I'm trying to find a way to better solution to the sanitizer. A few > > > ideas I'm considering: > > > - Teach clang to add -lsys when linking with sanitizers on sufficently > > > new systems (con: doesn't fix gcc). > > > - Make the symbol weak in the sanitizer and complain when it's not > > > found or call back to using environ. The latter migth have > > > limitations around direct exec with rtld. > > > - Relocate __elf_aux_vector to csu so the symbol is always available. > > > - Adding a new interface to access __elf_aux_vector directly. > > > > > > I'll continue to work on this. > > > > > > -- Brooks > > > > > > On Wed, Feb 21, 2024 at 09:52:23AM +0000, hartmut.bra...@dlr.de wrote: > > >> Hi, > > >> > > >> I updated yesterday and now event a minimal program with > > >> > > >> cc -fsanitize=address > > >> > > >> produces > > >> > > >> ld: error: undefined symbol: __elf_aux_vector > > >>>>> referenced by sanitizer_linux_libcdep.cpp:950 > > >>>>> (/usr/src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp:950) > > >>>>> sanitizer_linux_libcdep.o:(__sanitizer::ReExec()) in > > >>>>> archive /usr/lib/clang/17/lib/freebsd/libclang_rt.asan-x86_64.a > > >> cc: error: linker command failed with exit code 1 (use -v to see > > >> invocation) > > >> > > >> I think this is caused by the libsys split. > > >> > > >> Cheers, > > >> Harti > > >> > > >> -----Original Message----- > > >> From: owner-freebsd-curr...@freebsd.org > > >> <owner-freebsd-curr...@freebsd.org> On Behalf Of Brooks Davis > > >> Sent: Friday, February 2, 2024 11:32 PM > > >> To: curr...@freebsd.org > > >> Subject: libc/libsys split coming soon > > >> > > >> TL;DR: The implementation of system calls is moving to a seperate > > >> library (libsys). No changes are required to existing software (except > > >> to ensure that libsys is present when building custom disk images). > > >> > > >> Code: https://github.com/freebsd/freebsd-src/pull/908 > > >> > > >> After nearly a decade of intermittent work, I'm about to land a series > > >> of patches which moves system calls, vdso support, and libc's parsing of > > >> the ELF auxiliary argument vector into a separate library (libsys). I > > >> plan to do this early next week (February 5th). > > >> > > >> This change serves three primary purposes: > > >> 1. It's easier to completely replace system call implementations for > > >> tracing or compartmentalization purposes. > > >> 2. It simplifies the implementation of restrictions on system calls such > > >> as those implemented by OpenBSD's msyscall(2) > > >> (https://man.openbsd.org/msyscall.2). > > >> 3. It allows language runtimes to link with libsys for system call > > >> implementations without requiring libc. > > >> > > >> libsys is an auxiliary filter for libc. This means that for any symbol > > >> defined by both, the libsys version takes precedence at runtime. For > > >> system call implementations, libc contains empty stubs. For others it > > >> contains copies of the functions (this could be further refined at a > > >> later date). The statically linked libc contains the full > > >> implementations so linking libsys is not required. > > >> > > >> Additionally, libthr is now linked with libsys to provide _umtx_op_err(). > > >> > > >> The overall implementation follows https://reviews.freebsd.org/D14609, > > >> but is redone from scratch as multiple commits to facilitate review and > > >> assist git's rename detection. > > >> > > >> Testing: > > >> - Boot testing on amd64, aarch64, and riscv > > >> - make tinderbox (prior version, final run in progress) > > >> - exp-run: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276391 > > >> - Kyua tests in poudriere amd64 jails: same 359 failures as with the > > >> latest freebsdci build > > >> > > >> Thanks to Ali Mashtizadeh and Tal Garfinkel for D14609 and many > > >> apologies for not landing this in a timely manner. Additional thanks to > > >> kib@ for many rounds of review, markj@ and kib@ for debugging rtld > > >> issues exposed by this patch, and antoine@ for exp-runs. > > >> > > >> Future work: > > >> - Purely functional interfaces to system calls (no errorno). > > >> Unfortunately there isn't an obvious way to do this without > > >> significant (possibly generated) assembly code. > > >> - Investigate msyscall(2) and pinsyscalls(2). > > >> - Reduce the size of stubs in libc. I????????ve errored on the > > >> side of not touching the copies that end up in libc to keep diff > > >> size down. We might want to generate empty stubs instead. > > >> > > >> See also: > > >> - Solaris Linker and Libraries Guide: > > >> https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter4-4.html > > >> > > >> -- Brooks > > > >
