Re: symbol relocation

[Ian Lance Taylor <ian@zembu.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