Re: symbol relocation

[Todd_Manchester@nmss.com]

>   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.
>

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


>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.

Actually, the problem isn't that the relocations are against the sections,
it
is that they are all the same.
for instance, for the .text section of test.o I get: (from objdump)
RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
0000004a 32                .text
00000052 32                .data+0xffffff84
00000064 32                .text
00000068 32                .data+0xffffff84
0000006e 32                .data+0xffffff84
00000044 32                ___main

Note that for each offset (location in the code), the relocation value is
the same.
This appears to be the case for all my output.

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.


>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.

I would do the relocation myself, but I can't because all the relocation
records against a section look the same (except for the different locations
in the code), and I don't have a way to find which symbol it is
referencing.
Thus I have no way to calculate what the relocated value should be.
Just using the values in the relocation entry and section vma doesn't seem
to be enough.

>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

I don't believe the loader is the problem, although it could be.
The problem seems to be in the compiler or linker?  Perhaps the options I
am passing, or the configuration of gcc?

As I mentioned, my loader should only have to do fairly simple relocations,
but I can't figure out how to do them on my own.

Thanks so much for your help.

-Todd