On Thu, Feb 22, 2024 at 02:57:13AM +0200, Konstantin Belousov wrote: > 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.
Indeed, on further reflection I agree. Another option occured to me which I intend to persue tomorrow: explicitly link the sanitizer .so files with libsys. At least in the base system that should be straight foward. -- Brooks > > > > > -- 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 > > > > > > >
