[PATCH glibc 5/9] glibc: Perform rseq(2) registration at C startup and thread creation (v17)

[Szabolcs Nagy]

The 04/29/2020 08:57, Mathieu Desnoyers wrote:
> ----- On Apr 29, 2020, at 5:01 AM, Florian Weimer fw@deneb.enyo.de wrote:
> 
> > * Szabolcs Nagy:
> > 
> >> cancel tests work for me on an ubuntu system because
> >> of /etc/ld.so.cache, but that may not be present
> >> or the system may not be glibc based at all.
> > 
> > I see.
> > 
> >> i always do the cp because i build gcc myself (usually
> >> close to current master) and don't install it to the
> >> system path which means at compile time and runtime
> >> different libraries are used if i dont copy
> > 
> > I wonder if we should do this automatically (maybe using a symbolic
> > link), at least of GCC and ld can find these shared objects.  Maybe
> > it's possible to tell ld to provide output that makes it easy to
> > locate the actual objects in the file system?
> > 
> > (Trimmed the Cc: list.)
> 
> For the records, here is the output I get here:
> 
> $ gcc --print-file-name libgcc_s.so.1
> /usr/lib/gcc/x86_64-linux-gnu/7/libgcc_s.so.1
> $ gcc --print-file-name libstdc++.so.6
> /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libstdc++.so.6
> $ gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> OFFLOAD_TARGET_DEFAULT=1
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) 
> 
> Even if this becomes worked-around upstream, I suspect it would be good to mention
> this trick in https://sourceware.org/glibc/wiki/Testing/Builds for those
> working on older glibc versions.
> 
> Considering that I my build directory is in:
> 
> /home/efficios/git/glibc-build
> 
> and I configure my glibc from the build directory with:
> "../glibc/configure --prefix=/home/efficios/glibc-test"
> 
> Where exactly should I copy libgcc_s.so.1 and libstdc++.so.6 ? I tried copying
> them to /home/efficios/git/glibc-build/ but it does not appear to fix the issue.

hm then the issue may be something else.

the build directory should be early in the runtime
library search path so if the right libs are there
then things should work.

> I notice that other .so are pulled into /home/efficios/git/glibc-build/testroot.pristine
> and then /home/efficios/git/glibc-build/testroot.root though. Is it where I should
> copy them, and if so, under which subdirectory are they expected ?

that is used if the test is running in a container
(e.g. resolver tests that use custom /etc/resolv.conf)

i'd try to run

strace -f ./testrun.sh nptl/tst-rseq-nptl --direct 2>strace.log

and grep libgcc_s strace.log