symbol relocation

[Ian Lance Taylor]

   From: Todd_Manchester@nmss.com
   Date: Thu, 8 Jul 1999 16:03:22 -0500

   I then do the following:
	objdump -x test.ro > test_ro.txt
	objdump -d --line-numbers test.ro > test_ro.s

   Looking at the output, I see what appear to be some problems with sybol
   addresses.
   For instance:
   In the original assembly the line is (test.s):
	movel _str,sp@-
   In the disassembled output, the line is (test_ro.s):
	50: 2f39 0000 0094  movel 94 <___do_global_dtors+0x18>,%sp@-

   I believe this to be wrong, because the the value of the symbol _str is not
    0x0000 0094, but is 0x00000110

There is no special reason to assume that the output of ld -r has the
symbol values you expect.  As far as ld is concerned, the only thing
which really matters is whether the final link is correct.

You should try running the linker on your relocatable object file
without -r to see if the result is correct.  If it is, then there is
probably nothing wrong with the ld -r output.

Note that in a.out the .data and .bss sections are not linked at
address zero, and that relocations against those sections include the
section VMA in the addend stored in the instruction.  I don't remember
off hand just what the relocation calculation is, so I don't know if
the data you are seeing is correct or not.

   All the relocation entries point to symbols such as .text, .data, and .bss;
      is there any way to find the
   actual symbol that was being referenced?  (that way I could compute my own
   relocations).

In most cases it is a feature to convert relocations against defined
symbols into relocations against sections, because the linker can look
up the section addresses easily and thus compute the relocations more
efficiently.

You could patch the assembler to avoid doing this conversion.
m68k-aout probably doesn't use BFD_ASSEMBLER, so the place to look is
probably tc_aout_fix_to_chars.

   I think this is causing programs that are loaded by my loader to address
   incorrect locations in memory.
   The loader is using the bfd library to perform final linking at load time
   (to place the code at the correct address).
   The loader sets up appropriate data structures and calls bfd_final_link()
   to perform the final link.
   It then extracts the section contents and loads them into memory.

Using bfd_final_link in a custom loader sounds pretty high overhead to
me.  BFD does a lot of stuff which a loader doesn't need to do, like
generate a new symbol table.  I don't know the details of your
application, so maybe this doesn't matter.

If running ld without the -r option does not produce the same results
as your loader, then I expect that the problem is somewhere in your
loader.  How are you constructing the BFD which you pass to
bfd_final_link?  In particular, how are you setting the section VMAs?

Ian