* RE: details of address relocation procedure
@ 2006-03-20 9:58 Eric Fisher
0 siblings, 0 replies; 3+ messages in thread
From: Eric Fisher @ 2006-03-20 9:58 UTC (permalink / raw)
To: binutils
>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"?
10: ff 05 00 00 00 00 incl 0x0
"ff 05 00 00 00 00" is the binary code of instruction 'incl 0x0',
which corresponds to
"bar++;"
16: e8 fc ff ff ff call 17 <main+0x17>
1b: e8 fc ff ff ff call 1c <main+0x1c>
These correspond to "foo(); foo2();". The called function
address are of relocation address with the specified relocation type.
You can use 'objdump -r' to
learn this. Because the linker hasn't relocate the correct address to
them, so the
binary code of them are the same for now. BFD tells more about this.
Eric.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: details of address relocation procedure
2006-03-19 5:09 sean yang
@ 2006-03-19 10:48 ` Ravi Ramaseshan
0 siblings, 0 replies; 3+ messages in thread
From: Ravi Ramaseshan @ 2006-03-19 10:48 UTC (permalink / raw)
To: sean yang; +Cc: binutils
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. "
^ permalink raw reply [flat|nested] 3+ messages in thread
* details of address relocation procedure
@ 2006-03-19 5:09 sean yang
2006-03-19 10:48 ` Ravi Ramaseshan
0 siblings, 1 reply; 3+ messages in thread
From: sean yang @ 2006-03-19 5:09 UTC (permalink / raw)
To: binutils
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"?
----------------------------------------
//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,
-----------------------------------------------
//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/
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-03-20 9:14 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-03-20 9:58 details of address relocation procedure Eric Fisher
-- strict thread matches above, loose matches on Subject: below --
2006-03-19 5:09 sean yang
2006-03-19 10:48 ` Ravi Ramaseshan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).