aboutsummaryrefslogtreecommitdiff
path: root/sysdeps/unix/sysv/linux/powerpc/libc-start.h
diff options
context:
space:
mode:
authorGabriel F. T. Gomes <gabrielftg@linux.ibm.com>2019-12-03 22:40:38 -0300
committerGabriel F. T. Gomes <gabrielftg@linux.ibm.com>2019-12-04 09:17:06 -0300
commitd0bc5b725dac852764b98b9b3e0560c003bd000a (patch)
treeb76ba20acf3698d8a7107aaa4ea8d7dcbb8a0954 /sysdeps/unix/sysv/linux/powerpc/libc-start.h
parent6ef1bab699eb82ad24d52a4a045bceb4f7533a5b (diff)
downloadglibc-d0bc5b725dac852764b98b9b3e0560c003bd000a.tar
glibc-d0bc5b725dac852764b98b9b3e0560c003bd000a.tar.gz
glibc-d0bc5b725dac852764b98b9b3e0560c003bd000a.tar.bz2
glibc-d0bc5b725dac852764b98b9b3e0560c003bd000a.zip
Do not use ld.so to open statically linked programs in debugglibc.sh
Debugging programs that have been dynamically linked against an uninstalled glibc requires unusual steps, such as letting gdb know where the thread db library is located and explicitly calling the loader. However, when the program under test is statically linked, these steps are not required (as a matter of fact, using the dynamic loader to run a statically linked program is wrong and will fail), and gdb should be called the usual way. This patch modifies debugglibc.sh so that it checks if the program under test is statically linked, then runs the debugger appropriately. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
Diffstat (limited to 'sysdeps/unix/sysv/linux/powerpc/libc-start.h')
0 files changed, 0 insertions, 0 deletions