This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: symbol relocation
- To: Todd_Manchester@nmss.com
- Subject: Re: symbol relocation
- From: Ian Lance Taylor <ian@zembu.com>
- Date: 9 Jul 1999 22:02:23 -0400
- CC: binutils@sourceware.cygnus.com
- References: <852567A9.00747BC0.00@notes4.nmss.com>
From: Todd_Manchester@nmss.com
Date: Fri, 9 Jul 1999 16:11:27 -0500
I tried a non-relocatable link:
gcc -save-temps -Wa,-L -m68000 -g -x c -c -o test.o test.c
gcc -nostartfiles -Wl,--entry=_main,-Map=test_a.map -o test.ao test.o
objdump -x test.ao > test_ao.txt
objdump -d --line-numbers test.ao > test_ao.s
This gave me to following for the same line as above:
20a0: 2079 0001 ff70 moveal 1ff70 <__etext+0x1de40>,%a0
^^^^ ^^^^
Both the objdump output and map file show that the address should be
0x00020000
(objdump -x test.ao)
00020000 g .data 0000 00 07 _str
(map file: test_a.map)
.data 0x00020000 0x4 test.o
0x00020000 str
Well, that looks like a bug. Could you please send me a test case
which does not involve gcc? Just send the .s file(s) and the as and
ld commands that you are using. Thanks.
Actually, the problem isn't that the relocations are against the sections,
it
is that they are all the same.
This is normal for the m68k a.out format. The addend is actually
stored in the object file itself. The relocation entry only stores
the relocation address, the relocation type, and the symbol index (in
this case a section index).
It appears that when bfd_final_link() does the relocation, it adds
relocation = section->output_section->vma + section->output_offset -
section->vma
+ whatever value is already in that location
(such as 0x00000094 in my original post)
This value it reads from the section contents is often not the symbol
value.
I wouldn't expect it to be the symbol value itself. I would expect it
to be the offset by the section address. In any case, if there is a
bug, this is where it would probably manifest itself.
Ian