28.06.2005 17:21:35, Wolfgang Denk wd@denx.de wrote:
In message 85W32HGVT4WOKE0XT1Y1XVTND0OM74.42c15f80@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