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

[Mathieu Desnoyers]

----- On Apr 30, 2020, at 6:40 AM, Szabolcs Nagy szabolcs.nagy@arm.com wrote:

> 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

After a few attempts, it appears that the issue was that I had already
run "make check" in my build directory beforehand, so even though I then
copied over the .so files to the build directory top level, it did not
populate them into the testroot.pristine nor testroot.root directories
for the following "make check".

If I delete both testroot.pristine and testroot.root, and make check
after making sure both .so are in the toplevel build directory, then
they are copied over to testroot.pristine, but testroot.root is not
created at all (and the test still fails).

Starting from a brand new empty build directory, and copying the .so
files before the first make check gets the test to run fine! By doing so,
the .so are copied into testroot.pristine and testroot.root.

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com