That's probably worth a shot.  Static linking will work anyway because
libc.a in effect embeds libsys to retain compatability.

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

Reply via email to