Good day -
Attempts to build latest GCC gcc-6-branch version from SVN ( Revision
260441 ), with the GCC 6.4.1 from the last time I built it ( git
commit starting '4f2cbe2' ), now fail in 'make check' , on a Linux
x86_64 host (RHEL 7.5, glibc 2.17) :
When 'pr59063-2.c' is built with the '-static-libasan' option and
WITHOUT any '-lasan' option being the first DT_NEEDED shared library,
(ie. being the FIRST -l option)
then the program produced emits the message:
'==$pid==ASan runtime does not come first in initial library list; \
you should either link runtime to your application or manually preload \
it with LD_PRELOAD.
' .
Then all tests that run that program fail.
So, if I modify gcc/testsuite/lib/asan-dg.exp to add '-lasan' as the
first '-l' argument, OR I set libasan to be preloaded, the program loads,
but coredumps, as shown in this gdb session:
Reading symbols from ./pr59063-2.exe...done.
(gdb) b sigaction
Breakpoint 1 at 0x42d800: file
../../.././libsanitizer/asan/asan_interceptors.cc, line 287.
(gdb) b real_sigaction
Breakpoint 2 at 0x4ac710: file
../../.././libsanitizer/asan/asan_interceptors.cc, line 297.
(gdb) c
The program is not being run.
(gdb) run
Starting program: /tmp/pr59063-2.exe
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib64/libthread_db.so.1".
Breakpoint 2, __sanitizer::real_sigaction (signum=11, act=0x7fffffffe230,
oldact=0x0) at ../../.././libsanitizer/asan/asan_interceptors.cc:297
297 (struct sigaction *)oldact);
(gdb) n
Breakpoint 1, __interceptor_sigaction (signum=11, act=0x7fffffffe230,
oldact=0x0) at ../../.././libsanitizer/asan/asan_interceptors.cc:287
287 struct sigaction *oldact) {
(gdb)
288 if (!IsDeadlySignal(signum) ||
common_flags()->allow_user_segv_handler) {
(gdb)
289 return REAL(sigaction)(signum, act, oldact);
(gdb)
292 }
(gdb)
289 return REAL(sigaction)(signum, act, oldact);
(gdb)
292 }
(gdb)
289 return REAL(sigaction)(signum, act, oldact);
(gdb)
0x0000000000000000 in ?? ()
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) where
#0 0x0000000000000000 in ?? ()
#1 0x00000000004d02a2 in __sanitizer::MaybeInstallSigaction (signum=11,
handler=0x4c6880 <__asan::AsanOnDeadlySignal(int, void*, void*)>) at
../../.././libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cc:178
#2 0x00000000004d0603 in __sanitizer::InstallDeadlySignalHandlers
(handler=0x4c6880 <__asan::AsanOnDeadlySignal(int, void*, void*)>) at
../../.././libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cc:187
#3 0x00000000004cd50d in __asan::AsanInitInternal () at
../../.././libsanitizer/asan/asan_rtl.cc:502
#4 0x00007ffff7de8d83 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#5 0x00007ffff7dda0ba in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6 0x0000000000000001 in ?? ()
#7 0x00007fffffffe5ab in ?? ()
#8 0x0000000000000000 in ?? ()
(gdb)
It appears that the '__interception::PTR_TO_REAL' mechanism
REAL(sigaction) is using to resolve address of sigaction is
being foxed by the fact that libasan.a is statically linked,
AND the libasan.so is also linked to, but hardly any
symbols are resolved to it.
When I remove '-static-libasan', and supply only '-lasan',
in the build command line generated by asan-dg.exp,
the test compiles and runs fine .
I am not using libasan for my project, just trying to build
latest GCC 6.4.1 with latest retpoline backports & bugfixes
into a version that passes its test suite, and I noticed this
problem - this is the main 'unexpected failure' source .
I guess I should class this an 'unexpected but don't care' failure ?
I just thought I should let the GCC developers know .
Thanks & Best Regards,
Jason
'
