[U-Boot-Users] Relocation of symbols?

Wed Jun 29 12:34:42 CEST 2005

28.06.2005 17:21:35, Wolfgang Denk <wd at denx.de> wrote:

>In message <85W32HGVT4WOKE0XT1Y1XVTND0OM74.42c15f80 at pc-block> you wrote:
>> 
>> Well, then I don't get it. Perhaps you could have a look at my mail referenced 
>> above. 
>> There's an example of U-Boot relocating an absolute symbol.
>
>I didn't see it. You claimed that there was an absolute symbol in  an
>object  file, but I have not seen the result of the linker run (i. e.
>the U-Boot ELF file, the System.map file or the u-boot.map file); nor
>do I know what you are doing in your linker script.
>
>Is your symbol "fpgadata" really listed in the GOT?

No, it is not. Do absolute symbols need to be entered into the GOT? It is generated as 
described in the mail from 24.6.05. Attached to this mail, you find two source files. 
reloc_test.c simply adds a new U-Boot command "test", which does nothing else but 
printing the address of the symbol array. This symbol is generated from the array.S 
assembler source. As you will see, array is not located at 0x400000 in U_Boot. At least 
not after relocation.

>You mentioned that it contains a bad value, but did you  verify  that
>this  was indeed casued by relocation (i. e. was the value really off
>by the relocation distance) ?

Attached to this mail, you find two very short source files, which show the problem. 
Compile it once into a u-boot (sorry, the relocation offset is calculated by the offset 
of a dummy function, when running in RAM compared to its address shown by nm in the u-
boot-binary, this needs to be changed to your needs at the beginning of reloc-test.c) 
and you'll not only see, that the address is wrong, but it is exactly off by relocation 
distance. Have a look with nm at the generated array.o to see, that the symbol is 
really absolute. Remove the define of ABTEST_UBOOT at the beginning of reloc_test.c to 
compile the example for linux and see it working as expected.

>> Well, I think there has to be a difference for the compiler in the next two cases:
>> 
>> char *walter = 0x4711;
>> char *herbert = "Thommy, the cat";
>
>No. There may be a difference for you, or for the resultof  the  code
>execution,  but  for  the  compiler  it's all the same. AFAIK the ESP
>module of GCC has not been implemented yet :-)

One can see the difference with objdump. Look at the attached example.c. Examine it's 
object with "objdump --reloc example.o". There you can see, that the compiler generated 
relocation entries for the function pointers m2 and m3 and for the static initializer 
"xxx", but NOT for the other static initializer 0x4712. See objdump output below:

example.o:     file format elf32-i386

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE 
00000016 R_386_32          m2
00000025 R_386_32          m3

RELOCATION RECORDS FOR [.data]:
OFFSET   TYPE              VALUE 
00000000 R_386_32          xxx

>> The first one shouldn't be relocated by the compiler, but the last one has to be 
>> relocated, in order to make the program work. At least as far as I understand it, 
>> please correct me, if I'm wrong.
>
>The _compiler_ does not do any relocation at  all.  He  doesn't  even
>know that such a thing exists. For the _compiler_ a pointer is just a
>pointer, in no way more special than an int.

As shown above, you're wrong at this point, sorry.

>> >I don't think  that  GCC/gas  will  normally  generate  any  absolute
>> >symbols  at all. If you manually define such symbols you are expected
>> >to understand what you are doing.
>      ^^^^^^^^^^
>
>The emphasis is on "understand".
>
>> Again, I'd like to reference my above mentioned first request from 14.06.2005. I 
think, 
>> I know what I'm doing and what I want to do, but the generated absolute symbol is 
>> relocated by U-Boot.
>
>You know what you  did,  but  you  posted  here  because  you  didn't
>understand  the  results,  right?  I don't understand it either, so I
>tend to avoid doing such things ;-)

Thanks for blaming myself of not understanding and suggesting to avoid the work I've to 
do. Believe me, there're only a few things I would like to do even more. But I can't. 
The reason to do it in the way described above is already described in my mail 24.6.05.
Since there's an array declared as

extern const unsigned char array[];

in a common-code section, and I can't include the data directly as an initialization 
inside of my program file, like it's done in other projects:

const unsigned char array[] = {
#include "array_data.c"
};

You might see the problem. I can't initialize the array in my project files, because I 
don't know the content and it's size at build time. And on the other hand I can't 
initialize the symbol as a pointer, because it's simply wrong:

NO GOOD: const unsigned char *array = 0x400000;

And since I don't want to touch code common to several projects, I can't initialize the 
pointer dynamically. So the only way for me seems to be to generate the symbol as shown 
in array.S. But this doesn't work.

>> Thanks for your suggestions, but my main problem is I'm not wanting to change any 
>> common code and want to solve my problem in the problem specific code.
>
>
>I really don't understand why you need to statically  intialize  this
>pointer  at  all,  or why you bother about it being relocated or not.
>You mentioned that this is an address to where the code is downloaded
>by TFTP first. So you will have to set up a  TFTP  transfer  and  all
>these  things  - so the address in RAM should be known. Why don't you
>simply use a plain assignment in your code, then?

See above.

Regards,
Andreas Block

-------------- next part --------------
A non-text attachment was scrubbed...
Name: reloc_test.c
Type: application/octet-stream
Size: 1029 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20050629/751ae1e6/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example.c
Type: application/octet-stream
Size: 209 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20050629/751ae1e6/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: array.S
Type: application/octet-stream
Size: 45 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20050629/751ae1e6/attachment-0002.obj 