symbol relocation

symbol relocation

[Todd_Manchester]

I am trying to compile code for m68k, with the output format m68k-aout.
I can compile all the code, and link it to produce a relocatable object
file that is loaded by custom written loader (which utilizes the bfd
library).

However, the object file that is produced has what appear to be incorrect
refences to global variables, that is their location seems to be wrong.

For example, for the following code:
/* test.c */
char *str = "Test string 1";

void strdummy(char* s)
{
    s[0] = 't';
    return;
}

int main ()
{
    char *str2 = "test String 2";
    strdummy(str);
    strdummy(str2);
    str = "test string 3";
    str2 = str;
    return;
}

I compile with:
     gcc -save-temps -Wa,-L -m68000 -g -x c -c -o test.o test.c
     gcc -nostartfiles -Wl,--entry=.main,-r,-Map=test.map -o test.ro test.o
(This is a test case, the two step compilation is to mimic more complex
builds.)

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
This is shown in the line below from the symbol listing produced by objdump
 (test_ro.txt):
     00000110 g       .data 0000 00 07 _str

Why is the value in the code different from the symbol listing value (which
 I believe to be correct)?
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).
Am I not understanding the relocation process correctly?
I have look through the bfd source some; where can I go for more
information?

Some other information:
There is a relocation entry for this address (from test_ro.txt):
     00000052 32                .data+0xfffffef0

I am using the cygwin development environment, cygwin-b20.1
with gcc version egcs-2.91.57 19980901 (egcs-1.1 release), configured with
--target=m68k-aout.

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.

Any suggestions as to what is happening with these symbols or this code
would be appreciated.
Also any hints as to how to proceed or problems with my approach would be
helpful.

I can provide more details if necessary.

-Todd Manchester

Re: 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

Re: symbol relocation

[Ian Lance Taylor]

   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

Re: symbol relocation

[Todd_Manchester]

>   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