Re: details of address relocation procedure

["Ravi Ramaseshan" <ramaseshan dot ravi at gmail dot com>]

Hi,

On 3/18/06, sean yang <seanatpurdue@hotmail.com> wrote:
> I want to know some details about symbol address relocation procedure.
> Thanks for your patience to read.
>
> Here I use a simple example to make the question clear:
> we have two files:
> -----------------------
> //in main.c
> extern int foo();
> extern int foo2();
> extern int bar;
> int main(){
>         bar++;
>         foo();
>         foo2();
> }
>
> --------
> //in foo.c
> int bar =1;
> int foo2(){
>         bar>>2;
> }
> int foo(){
>         bar++;
> }
> ------------------------
>
> after >gcc -o *.c, I think the symbol table in main.o should include "foo"
> and "bar" with type of Undefined, which in turn should be resolved during
> the linking procedure.
> But how can a linker backpatch the resolved address to the instruction "e8
> fc ff ff ff          call   17 <main+0x17>", after it figures out the
> address of foo()? As both call foo and call foo2 are represented by "e8 fc
> ff ff ff ", how can the linker tell them apart and `backpatch' correctly? a
> related question is: does opcode fc ff ff ff (following e8) means "address
> to be solved"? does opcode  00 00 00 00 (following ff 05) means variable
> address to be solved"?

The assembler puts in more information than just opcodes called
relocation entries. To see those use `objdump -r`

>
> ----------------------------------------
> //objdump -D main.o
> Disassembly of section .text:
> 00000000 <main>:
>    0:   55                      push   %ebp
>    1:   89 e5                   mov    %esp,%ebp
>    3:   83 ec 08                sub    $0x8,%esp
>    6:   83 e4 f0                and    $0xfffffff0,%esp
>    9:   b8 00 00 00 00          mov    $0x0,%eax
>    e:   29 c4                   sub    %eax,%esp
>   10:   ff 05 00 00 00 00       incl   0x0
>   16:   e8 fc ff ff ff          call   17 <main+0x17>
>   1b:   e8 fc ff ff ff          call   1c <main+0x1c>
>   20:   c9                      leave
>   21:   c3                      ret
> Disassembly of section .data:
>
> ---------------------------------
> //objdump -d foo.o
> Disassembly of section .text:
> 00000000 <foo2>:
>    0:   55                      push   %ebp
>    1:   89 e5                   mov    %esp,%ebp
>    3:   c9                      leave
>    4:   c3                      ret
> 00000005 <foo>:
>    5:   55                      push   %ebp
>    6:   89 e5                   mov    %esp,%ebp
>    8:   ff 05 00 00 00 00       incl   0x0
>    e:   c9                      leave
>    f:   c3                      ret
> Disassembly of section .data:
> 00000000 <bar>:
>    0:   01 00                   add    %eax,(%eax)
>         ...
> -------------------------------------------------
>
> now, we do >gcc -o a.out main.o foo.o, which drives the ld to do the
> relocation as one of its job.
>
> My final question is about the ld source code: which functions(and .c file)
> in the ./binutils-2.16.1/  are in charge of the relocation procedure? In
> other words, I'd like to know (1) the function that enables ld to find the
> location where an address needs to be resolved (e.g.  16:   e8 fc ff ff ff
>         call   17 <main+0x17> in main.o); (2) the function actually get the
> resolved address and write the address to the corresponding place.
>
> Please give a hint that where I should start to look at. Thanks,

You would want to look at bfd/elf32-xxx.c at functions elf_xxx_relocate_section.

> -----------------------------------------------
> //objdump -d a.out
> ....
> 08048310 <main>:
> 8048310:       55                      push   %ebp
> 8048311:       89 e5                   mov    %esp,%ebp
> 8048313:       83 ec 08                sub    $0x8,%esp
> 8048316:       83 e4 f0                and    $0xfffffff0,%esp
> 8048319:       b8 00 00 00 00          mov    $0x0,%eax
> 804831e:       29 c4                   sub    %eax,%esp
> 8048320:       ff 05 28 94 04 08       incl   0x8049428
> 8048326:       e8 0e 00 00 00          call   8048339 <foo>
> 804832b:       e8 04 00 00 00          call   8048334 <foo2>
> 8048330:       c9                      leave
> 8048331:       c3                      ret
> 8048332:       90                      nop
> 8048333:       90                      nop
>
> 08048334 <foo2>:
> 8048334:       55                      push   %ebp
> 8048335:       89 e5                   mov    %esp,%ebp
> 8048337:       c9                      leave
> 8048338:       c3                      ret
>
> 08048339 <foo>:
> 8048339:       55                      push   %ebp
> 804833a:       89 e5                   mov    %esp,%ebp
> 804833c:       ff 05 28 94 04 08       incl   0x8049428
> 8048342:       c9                      leave
> 8048343:       c3                      ret
> ......
> ====================================
>
> _________________________________________________________________
> Don't just search. Find. Check out the new MSN Search!
> http://search.msn.click-url.com/go/onm00200636ave/direct/01/
>
>

Cheers,
--
Ravi Ramaseshan
http://www.geocities.com/ramaseshan_ravi/

" Reality is only something we believe in strongly. "