4

I am trying to understand the internal working behind GDB commands. After initial homework of understanding about elf / shared libraries / address space randomization, I attempted to understand how GDB make sense between the executable and corefile.

solib.c contains the implementation of shared library processing. Esp am interested in the info sharedlibrary command.

The comment on the solib.c goes like this..

 
 /* Relocate the section binding addresses as recorded in the shared
 object's file by the base address to which the object was actually
 mapped.  */

 ops->relocate_section_addresses (so, p);

I could not understand much from this comment. Can somebody explain me in plain english how relocation happens? i.e Every time when an executable loads a shared object, it is going to load at some location say X, and all the symbols inside the shared library will be located at fixed offset, say X+Y with some size Z. My question is, how does gdb does the same range of address relocation, so that it matches with the load segments in the corefile. How it takes that hint from executable.

kspviswa
  • 637
  • 3
  • 13

1 Answers1

4

how does gdb does the same range of address relocation, so that it matches with the load segments in the corefile

In other words, how does GDB find the relocation X?

The answer depends on the operating system.

On Linux, GDB finds _DYNAMIC[] array of struct Elf{32,64}_Dyns in the core file, which contains an element with .d_tag == DT_DEBUG.

The .d_ptr in that element points to struct r_debug (see /usr/include/link.h), which points to a linked list of struct link_maps, which describe all loaded shared libraries and their relocations in l_addr.

The relevant file in GDB is solib-svr4.c.

EDIT:

I see that, there are no .dynamic sections in the corefile.

There shouldn't be. There is a .dynamic section in the executable and a matching LOAD segment in the core (the segment will "cover" the .dynamic section, and have the contents that was there at runtime).

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Thanks for your interest. I still don't get it. From the readelf command, I see that, there are no .dynamic sections in the corefile. I also doublechecked using libbfd. Can you please explain what am I missing here? – kspviswa Feb 17 '14 at 17:30
  • So this .dynamic section of exe file is the bridge for GDB to make sense? If so, how does it selects a particular load segment in core file. All I see from the corefile is, the name of the segment as load and virtual adress / physical address / size / permissions and flags. How does gdb matches the .dynamic section of exe with the core file. Also in the solib-svr4.c, I see that, they are using fixed offsets of 20 bytes in svr4_ilp32_fetch_link_map_offsets(). Can you provide some pointers on this magic number? – kspviswa Feb 18 '14 at 13:14
  • I tried some program using elfutil library to playaround with a core. As per the directions in /usr/include/link.h, I tried to find out the segments with DT_DEBUG dtag. But to my surprise, I found 7 segments having the dtag DT_DEBUG. On type casting the d_ptr to _r_debug, the program crashed. Is there any way I can find the _DYNAMIC[] from a load segment? What is the key match b/w the executable's .dynamic segment and corresponding LOAD segment in the core... – kspviswa Mar 14 '14 at 10:54