Gdb, PIE and scan_dyntag(DT_DEBUG)

Jan Kratochvil
Mon Mar 31 18:47:00 GMT 2014

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 and

$ 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/
0x00007f7ceddf3b10  0x00007f7cede0cc70  Yes         /lib64/

> 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.


More information about the Gdb mailing list