This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Gdb, PIE and scan_dyntag(DT_DEBUG)
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Robert Jarzmik <robert dot jarzmik at free dot fr>
- Cc: gdb at sourceware dot org, robert dot jarzmik at intel dot com
- Date: Mon, 31 Mar 2014 20:47:24 +0200
- Subject: Re: Gdb, PIE and scan_dyntag(DT_DEBUG)
- Authentication-results: sourceware.org; auth=none
- References: <87bnwuuhzp dot fsf at free dot fr>
On Tue, 25 Mar 2014 21:43:22 +0100, Robert Jarzmik wrote:
> I have a problem with gdb not finding the shared library list when analyzing a
> core dump of an ELF-X86-64 binary on Linux.
The problem is it works for me. Tested on Fedora 20 x86_64 although I am not
aware of any distro-specific stuff which could affect this functionality.
It is also relevant to know prelink status but I have tested this
functionality now even with unprelinked ld.so and libc.so:
$ echo 'int main(void) { return *(volatile int *)0=0; }'|gcc -o segv -Wall -g -fPIE -pie -x c -;rm -f core.*;(ulimit -c unlimited;./segv);mv core.* segv.core;.../gdb -batch ./segv{,.core} -ex 'info sharedlibrary'
[...]
>From To Syms Read Shared Object Library
0x00007f7ceda53560 0x00007f7cedb94bb4 Yes /lib64/libc.so.6
0x00007f7ceddf3b10 0x00007f7cede0cc70 Yes /lib64/ld-linux-x86-64.so.2
> The trouble lies in the scan_dyntag(DT_DEBUG) called by elf_locate_base() for me
> :
> - it tries first target_ops=core_ops, and looks at non-displaced address of
> .dynamic => failure => that's great
> - it then tries target_ops=exec_ops, and looks at non-displaced address of
> .dynamic => it succeeds, returning 0 => that's my problem
It returns the proper displacement for me. exec_bfd gets relocated to its
proper address during:
#1 in objfile_relocate1 (objfile=0x602c00003680, new_offsets=0x7fffffffcec0) at objfiles.c:819
#2 in objfile_relocate (objfile=0x602c00003680, new_offsets=0x7fffffffcec0) at objfiles.c:843
#3 in svr4_relocate_main_executable () at solib-svr4.c:2882
#4 in svr4_solib_create_inferior_hook (from_tty=1) at solib-svr4.c:2926
#5 in solib_create_inferior_hook (from_tty=1) at solib.c:1200
#6 in post_create_inferior (target=0x3d9e9a0 <core_ops>, from_tty=1) at infcmd.c:442
#7 in core_open (filename=0x6006000138a0 "/home/jks", from_tty=1) at corelow.c:412
#8 in core_file_command (filename=0x7fffffffdd5d "./segv.core", from_tty=1) at corefile.c:81
You should check why svr4_exec_displacement() does not work in your case.
> As the call succeeded, elf_locate_base() won't call scan_dyntag_auxv()
>
> I manually "forced" elf_locate_base() to call scan_dyntag_aux() and then all my
> shared libraries appear.
Yes but exec_bfd probably remains wrongly (=not) relocated.
> why GDB is looking at the executable file .dynamic section before attempting
> AUXV AT_BASE reading and memory read accordingly ?
I do not know answer to this question now but it should work anyway.
Jan