[U-Boot-Users] Does u-boot relocate absolute symbols?

[U-Boot-Users] Does u-boot relocate absolute symbols?

[Andreas Block]

Hi,

I'm not quite sure, if this is a bug or a feature, but I tried to do the following and 
it didn't work:

Here at esd, we've some code common for all our boards (used to program FPGAs or CPLDs 
in u-boot). Up to now, the respective CPLD/FPGA-image was included into u-boot as an 
array, declared as follows in a board-dependent file (e.g. pf5200.c):

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

The common code (located in micro.c or ports.c in esd/common/) accesses the image via 
fpgadata using the following extern-declaration:

extern const unsigned char fpgadata[];

This far everything's fine. With a new hardware, we've the following problem:
The CPLD image is too large to fit within u-boot and I'd like to retrieve the CPLD 
image at runtime via TFTP. And I'd like to do this without the need to change any of 
the common code (like the above mentioned extern-declaration), which of course would 
mean to test all other hardware using the common-code again.

It does not work (because it's simply wrong) to declare fpgadata as follows in pf5200.c 
(although looking good in the first place, if you think about it, the compiler needs to 
handle both declarations differently):

const unsigned char *fpgadata = 0x400000; /* (with 0x400000 being the address to store 
the image with TFTP at) */

So I tried a different approach (since all I need is to get access to the array at a 
certain memory location). I didn't declare fpgadata in pf5200.c at all, but instead 
wrote a small fpgadata.S containing the following:

.globl fpgadata
.data
.set fpgadata, 0x400000

It's supposed to generate the symbol fpgadata.c and locate it at the right absolute 
address in memory. One can try this with some small test-code under Linux and it works 
as it's supposed to. Also the output of nm "fpgadata.o" looks beautiful:

00400000 A fpgadata

But when used in u-boot the address of fpgadata is not 0x400000, but something 
different. I assume this is related to u-boot booting from flash and relocating itself 
into RAM. And this is the point, I'm not sure about. Is this the way one wants it work. 
Does one want u-boot to relocate absolute addresses, or is this behaviour even needed 
for u-boot to work at all? Or is it a bug and u-boot doesn't pay attention to the 
absolute flag as it's supposed to? Wouldn't it be nice in a boot-loader to be able to 
locate something at certain memory locations at link time?

Best regards,
Andreas Block

[U-Boot-Users] Does u-boot relocate absolute symbols?

[Rune Torgersen]

I just have to comment on this.

> It does not work (because it's simply wrong) to declare 
> fpgadata as follows in pf5200.c 
> (although looking good in the first place, if you think about 
> it, the compiler needs to 
> handle both declarations differently):
> 
> const unsigned char *fpgadata = 0x400000; /* (with 0x400000 
> being the address to store 
> the image with TFTP at) */
> 

Have you tried to do this?
Because it should work (even if one is declared char [] and the other
char *)

I use something similar to access a FPGA binary image stored in flash
(after U-Boot relocation) and it works.

[U-Boot-Users] Does u-boot relocate absolute symbols?

[Andreas Block]

29.06.2005 17:46:03, "Rune Torgersen" <runet@innovsys.com> wrote:

>I just have to comment on this.
>
>> It does not work (because it's simply wrong) to declare 
>> fpgadata as follows in pf5200.c 
>> (although looking good in the first place, if you think about 
>> it, the compiler needs to 
>> handle both declarations differently):
>> 
>> const unsigned char *fpgadata = 0x400000; /* (with 0x400000 
>> being the address to store 
>> the image with TFTP at) */
>> 
>
>Have you tried to do this?
>Because it should work (even if one is declared char [] and the other
>char *)

Sure, I've tried this. This is the point, where my problem arose. Attached you find two 
small files, you can easily compile under linux (gcc -o arrtest -I ./ ./common.c 
./array.c). The file "common.c" represents the code I can't (don't want to) touch. 
"array.c" represents my project dependent code. If you run arrtest it will show to you, 
that it is not possible to initialize the array "test" in this manner. After looking at 
the disassembly, it is pretty clear, that the compiler has to generate different code 
for the two notations.

Nevertheless, thanks for your hint,
Andreas Block

-------------- next part --------------
A non-text attachment was scrubbed...
Name: array.c
Type: application/octet-stream
Size: 152 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20050630/a9e4fc89/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: common.c
Type: application/octet-stream
Size: 120 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20050630/a9e4fc89/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: common.h
Type: application/octet-stream
Size: 21 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20050630/a9e4fc89/attachment-0002.obj 

[U-Boot-Users] Does u-boot relocate absolute symbols?

[Wolfgang Denk]

In message <NJF2NIMJ61Z631T0787IG4284GAA7.42c3a2fd@pc-block> you wrote:
> 
> Sure, I've tried this. This is the point, where my problem arose. Attached you find two 
> small files, you can easily compile under linux (gcc -o arrtest -I ./ ./common.c 
> ./array.c). The file "common.c" represents the code I can't (don't want to) touch. 

This example does not demonstrate  anything.  Of  course  a  standard
application  code  example in a Linux environment will not work. Also
you example code seems to show a different situation that you claimed
to have.

> "array.c" represents my project dependent code. If you run arrtest it will show to you, 
> that it is not possible to initialize the array "test" in this manner. After looking at 
> the disassembly, it is pretty clear, that the compiler has to generate different code 
> for the two notations.

Remember that in U-Boot you can:

1) play tricks with the linker script
2) play tricks in your board specific configuration file  which  gets
   included everwhere

For example, you can can re-#define the variables (like  "walter"  in
your example) to use a different name and/or to include some trickery
like  "__attribute__  ((section("???")))"  stuff  to place this array
into a special section which then  gets  treated  specially  in  your
linker script, etc.

This is U-Boot, and you have *full* control over what you are  doing,
which is very unlike compared to a standard Linux application example
-  you  are comparing apples and bananas here (they have one thing in
common, though: I like them both :-).

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It's hard to make a program foolproof because fools are so ingenious.

[U-Boot-Users] Does u-boot relocate absolute symbols?

[Andreas Block]

30.06.2005 12:46:34, Wolfgang Denk <wd@denx.de> wrote:

>In message <NJF2NIMJ61Z631T0787IG4284GAA7.42c3a2fd@pc-block> you wrote:
>> 
>> Sure, I've tried this. This is the point, where my problem arose. Attached you find
>> two small files, you can easily compile under linux (gcc -o arrtest -I ./ ./common.c 
>> ./array.c). The file "common.c" represents the code I can't (don't want to) touch. 
>
>This example does not demonstrate  anything.  Of  course  a  standard
>application  code  example in a Linux environment will not work. Also
>you example code seems to show a different situation that you claimed
>to have.
>

Hmm? This example was sent to Rune Torgersen in order to show him, that "char *bla" 
isn't the same as "char bli[]", so I'm not sure, why it doesn't explain anything.


>> "array.c" represents my project dependent code. If you run arrtest it will show to 
>> you, that it is not possible to initialize the array "test" in this manner. After 
>> looking at the disassembly, it is pretty clear, that the compiler has to generate 
>> different code for the two notations.
>
>Remember that in U-Boot you can:
>
>1) play tricks with the linker script
>2) play tricks in your board specific configuration file  which  gets
>   included everwhere
>
>For example, you can can re-#define the variables (like  "walter"  in
>your example) to use a different name and/or to include some trickery
>like  "__attribute__  ((section("???")))"  stuff  to place this array
>into a special section which then  gets  treated  specially  in  your
>linker script, etc.

Thanks, I'll take a deeper look into this, but actually I thought, I had already 
generated an absolute symbol (with those small assembly lines), which obviously isn't 
treated as an absolute symbol by the linker script (or U-Boot?).


>This is U-Boot, and you have *full* control over what you are  doing,
>which is very unlike compared to a standard Linux application example
>-  you  are comparing apples and bananas here (they have one thing in
>common, though: I like them both :-).

I didn't want to compare U-Boot to Linux, but simply explain a peculiarity of C-
language. This stands inside U-Boot as well as inside Linux as well as nearly anywhere 
else, which is programmable in C.

Now, having read your second reply to this thread (from 13:09), I'm quite sure, that I 
need a lds-guru, to get me any further.
To close this thread, I'd like to ask the questions, which started this thread, again 
and I would like you to answer as short and precise as possible:

1) Is U-Boot supposed to relocate absolute symbols located in any objects, that are 
linked against it?

1a) If not, would you be interested in a patch for U-Boot? (For me, I will be able to 
live with my workaround and putting any effort into it, pays only, if these changes 
make their way into the U-Boot tree.)

2) Is it correct, that the linker script creates relocation tags inside of .text-
segments, only? Which would lead to the observed behaviour, that statically initialized 
pointers, which normnally result in relocation tags in .data segments, aren't 
relocated.

2a) s. 1a)
2b) If 2a) is yes, can you estimate, how many code-pieces needed a rewrite, in case 
this would be fixed (of course all manual relocation points wouldn't be needed 
anymore)? Only estimate, just to get a thought, if it's a hand full, hundreds or 
thousands...

Best regards,
Andreas Block

[U-Boot-Users] Does u-boot relocate absolute symbols?

[Jerry Van Baren]

Andreas Block wrote:
> 29.06.2005 17:46:03, "Rune Torgersen" <runet@innovsys.com> wrote:
> 
> 
>>I just have to comment on this.
>>
>>
>>>It does not work (because it's simply wrong) to declare 
>>>fpgadata as follows in pf5200.c 
>>>(although looking good in the first place, if you think about 
>>>it, the compiler needs to 
>>>handle both declarations differently):
>>>
>>>const unsigned char *fpgadata = 0x400000; /* (with 0x400000 
>>>being the address to store 
>>>the image with TFTP at) */
>>>
>>
>>Have you tried to do this?
>>Because it should work (even if one is declared char [] and the other
>>char *)
> 
> 
> Sure, I've tried this. This is the point, where my problem arose. Attached you find two 
> small files, you can easily compile under linux (gcc -o arrtest -I ./ ./common.c 
> ./array.c). The file "common.c" represents the code I can't (don't want to) touch. 
> "array.c" represents my project dependent code. If you run arrtest it will show to you, 
> that it is not possible to initialize the array "test" in this manner. After looking at 
> the disassembly, it is pretty clear, that the compiler has to generate different code 
> for the two notations.
> 
> Nevertheless, thanks for your hint,
> Andreas Block

I assume this was a typo and not in your actual test program?

--- common.c-original	2005-06-30 08:03:26.286019864 -0400
+++ common.c	2005-06-30 08:03:48.815779191 -0400
@@ -4,7 +4,7 @@

  int showwrong(void)
  {
-	printf("test[]: 0x%08X\n");
+	printf("test[]: 0x%08X\n", (int)test);
  	return 0;
  }

gvb

[U-Boot-Users] Does u-boot relocate absolute symbols?

[Wolfgang Denk]

In message <S6Z4ZJE2ZD9OKTKIA9EBQPNIHC652U.42c3dac1@pc-block> you wrote:
> 
> Hmm? This example was sent to Rune Torgersen in order to show him, that "char *bla" 
> isn't the same as "char bli[]", so I'm not sure, why it doesn't explain anything.

I think most of us are aware of the differences between a pointer and
an array, but this is not your point. Your problem was how you  could
keep  existing  code (which uses an array, as I understand), and both
Rune and me said that the existing difference might be worked  around
one way or another.

> Thanks, I'll take a deeper look into this, but actually I thought, I had already 
> generated an absolute symbol (with those small assembly lines), which obviously isn't 
> treated as an absolute symbol by the linker script (or U-Boot?).

I think that "absolute symbol" does not work as you expect it to work
when it comes to relocation.  I  don't  know  enough  of  the  linker
internals  to  make  a  definitive  statement  if this is an issue of
misunderstanding, or an error in the use of the  linker  (i.  e.  the
linker script), or the linker itself.

> 1) Is U-Boot supposed to relocate absolute symbols located in any objects, that are 
> linked against it?

U-Boot doesn't know anything about any symbols. It just walsk the GOT
and adjusts the addresses it finds there.

> 1a) If not, would you be interested in a patch for U-Boot? (For me, I will be able to 
> live with my workaround and putting any effort into it, pays only, if these changes 
> make their way into the U-Boot tree.)

In my understanding you want to find a way  that  "absolute  symbols"
(and  eventually staticlaly initialized function pointers, too ?) get
relocated correctly. Of course I will accept patches that improve the
current code.

> 2) Is it correct, that the linker script creates relocation tags inside of .text-
> segments, only? Which would lead to the observed behaviour, that statically initialized 
> pointers, which normnally result in relocation tags in .data segments, aren't 
> relocated.

No, this is not correct. You can access variables  in  data  and  bss
segments  after relocation, so it's obvious that these got relocated,
too.

> 2b) If 2a) is yes, can you estimate, how many code-pieces needed a rewrite, in case 
> this would be fixed (of course all manual relocation points wouldn't be needed 
> anymore)? Only estimate, just to get a thought, if it's a hand full, hundreds or 
> thousands...

A handfull. All this is pretty concentrated in one place.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I didn't know it was impossible when I did it."

[U-Boot-Users] Does u-boot relocate absolute symbols?

[Andreas Block]

Yes, thanks. Sorry, It might have been a bit too early in the morning. But even with 
correction the result stays the same.

Regards,
Andreas Block


30.06.2005 14:05:44, Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com> wrote:

>Andreas Block wrote:
>> 29.06.2005 17:46:03, "Rune Torgersen" <runet@innovsys.com> wrote:
>> 
>> 
>>>I just have to comment on this.
>>>
>>>
>>>>It does not work (because it's simply wrong) to declare 
>>>>fpgadata as follows in pf5200.c 
>>>>(although looking good in the first place, if you think about 
>>>>it, the compiler needs to 
>>>>handle both declarations differently):
>>>>
>>>>const unsigned char *fpgadata = 0x400000; /* (with 0x400000 
>>>>being the address to store 
>>>>the image with TFTP at) */
>>>>
>>>
>>>Have you tried to do this?
>>>Because it should work (even if one is declared char [] and the other
>>>char *)
>> 
>> 
>> Sure, I've tried this. This is the point, where my problem arose. Attached you find 
two 
>> small files, you can easily compile under linux (gcc -o arrtest -I ./ ./common.c 
>> ./array.c). The file "common.c" represents the code I can't (don't want to) touch. 
>> "array.c" represents my project dependent code. If you run arrtest it will show to 
you, 
>> that it is not possible to initialize the array "test" in this manner. After looking 
at 
>> the disassembly, it is pretty clear, that the compiler has to generate different 
code 
>> for the two notations.
>> 
>> Nevertheless, thanks for your hint,
>> Andreas Block
>
>I assume this was a typo and not in your actual test program?
>
>--- common.c-original	2005-06-30 08:03:26.286019864 -0400
>+++ common.c	2005-06-30 08:03:48.815779191 -0400
>@@ -4,7 +4,7 @@
>
>  int showwrong(void)
>  {
>-	printf("test[]: 0x%08X\n");
>+	printf("test[]: 0x%08X\n", (int)test);
>  	return 0;
>  }
>
>gvb
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>U-Boot-Users mailing list
>U-Boot-Users at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
>
>

[U-Boot-Users] Does u-boot relocate absolute symbols?

[Andreas Block]

30.06.2005 14:40:10, Wolfgang Denk <wd@denx.de> wrote:

>In message <S6Z4ZJE2ZD9OKTKIA9EBQPNIHC652U.42c3dac1@pc-block> you wrote:
>> 
>> Hmm? This example was sent to Rune Torgersen in order to show him, that "char *bla" 
>> isn't the same as "char bli[]", so I'm not sure, why it doesn't explain anything.
>
>I think most of us are aware of the differences between a pointer and
>an array, but this is not your point. Your problem was how you  could
>keep  existing  code (which uses an array, as I understand), and both
>Rune and me said that the existing difference might be worked  around
>one way or another.

I'd appreciate, if any of you could get any more specific, because I don't get your 
hints about workarounds. And on the other side, neither of you comments my way of 
working around with an attempt to tell me, what I did wrong or overlooked.
I understand, you want to push me into the direction of a workaround, but I've no idea 
what you're thinking of.


>> 1) Is U-Boot supposed to relocate absolute symbols located in any objects, that are 
>> linked against it?
>
>U-Boot doesn't know anything about any symbols. It just walsk the GOT
>and adjusts the addresses it finds there.

Sorry, another imprecision on my side. I meant the linker script.


>> 1a) If not, would you be interested in a patch for U-Boot? (For me, I will be able 
>> to live with my workaround and putting any effort into it, pays only, if these 
>> changes make their way into the U-Boot tree.)
>
>In my understanding you want to find a way  that  "absolute  symbols"
>(and  eventually staticlaly initialized function pointers, too ?) get
>relocated correctly. Of course I will accept patches that improve the
>current code.

See below.


>> 2) Is it correct, that the linker script creates relocation tags inside of .text-
>> segments, only? Which would lead to the observed behaviour, that statically 
>> initialized pointers, which normnally result in relocation tags in .data segments, 
>> aren't relocated.
>
>No, this is not correct. You can access variables  in  data  and  bss
>segments  after relocation, so it's obvious that these got relocated,
>too.

Hm, are you sure? As far as I see it, the only relocation points in .data segment are 
the ones initializating pointers. All other relocation points are lying in .text-
segments, aren't they?

E.g.:

Global variables:
int walter; ==> results in relocation point(s) in .text-segment (every access to this 
variable results in machine code (in _.text_) with the need to be patched, when 
relocated)
These are handled perfectly by linker script.

Statically initialized pointers:
char *walter = "Big brown beaver"; ==> Here are two different relocations needed. For 
pointer "walter" see above "Global variables". Everything's fine. But number two 
concerns the address of the string. This results in a relocation entry in the .data-
segment and these seem not to be handled by the linker script. As far as I know, this 
is the only case leading to relocation points in the .data segment.

It seems to me, as if this should be fixable with a change in the linker script, but at 
the moment I've to admit, that the interior of this script is quite magic to me. 
Anyway, if one could fix it in the linker script, the handful codepieces relocating 
pointers are unnecessary. The icing on this cake would be to keep absolute symbols out 
of the GOT.

Best regards,
Andreas Block

[U-Boot-Users] Does u-boot relocate absolute symbols?

[Rune Torgersen]

Wow.... This surprises me...
I have alwayts thought that *test and test[] would be the same thing.

Only solutionI can see is to change the definition in common.c to be
*test, this will still get the address of test[] defined elsewhere.
(See attached files)

> Sure, I've tried this. This is the point, where my problem 
> arose. Attached you find two 
> small files, you can easily compile under linux (gcc -o 
> arrtest -I ./ ./common.c 
> ./array.c). The file "common.c" represents the code I can't 
> (don't want to) touch. 
> "array.c" represents my project dependent code. If you run 
> arrtest it will show to you, 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: common.h
Type: application/octet-stream
Size: 24 bytes
Desc: common.h
Url : http://lists.denx.de/pipermail/u-boot/attachments/20050630/fe93c658/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: array.c
Type: application/octet-stream
Size: 200 bytes
Desc: array.c
Url : http://lists.denx.de/pipermail/u-boot/attachments/20050630/fe93c658/attachment-0001.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: common.c
Type: application/octet-stream
Size: 137 bytes
Desc: common.c
Url : http://lists.denx.de/pipermail/u-boot/attachments/20050630/fe93c658/attachment-0002.obj 

[U-Boot-Users] Does u-boot relocate absolute symbols?

[Jerry Van Baren]

Rune Torgersen wrote:
> Wow.... This surprises me...
> I have alwayts thought that *test and test[] would be the same thing.
> 
> Only solutionI can see is to change the definition in common.c to be
> *test, this will still get the address of test[] defined elsewhere.
> (See attached files)
> 
> 
>>Sure, I've tried this. This is the point, where my problem 
>>arose. Attached you find two 
>>small files, you can easily compile under linux (gcc -o 
>>arrtest -I ./ ./common.c 
>>./array.c). The file "common.c" represents the code I can't 
>>(don't want to) touch. 
>>"array.c" represents my project dependent code. If you run 
>>arrtest it will show to you, 

With the patch in place (previously sent to the list), it works for linux:

vanbaren at sherwood:~/x> ll
total 32
-rwxr-----  1 vanbaren users  200 Jun 30 13:24 array.c
-rwxr-xr-x  1 vanbaren users 8963 Jun 30 13:26 arrtest
-rwxr-----  1 vanbaren users  132 Jun 30 08:03 common.c
-rwxr-----  1 vanbaren users  121 Jun 30 08:03 common.c-original
-rw-r--r--  1 vanbaren users  237 Jun 30 08:04 common.c.diff
-rwxr-----  1 vanbaren users   24 Jun 30 13:23 common.h
vanbaren at sherwood:~/x> gcc -o arrtest -I ./ ./common.c ./array.c
vanbaren at sherwood:~/x> ./arrtest
*test: 0x08048558
test[]: 0x08048558

gvb

[U-Boot-Users] Does u-boot relocate absolute symbols?

[Andreas Block]

Jerry: I'm sorry for the inconvenience, but sent this mail to you instead  
of the U-Boot mailinglist.

I'm not quite sure, what happened on your side.
Here's the result on my side (together with the source as it ought look):

--- BEGIN OF CONSOLE OUTPUT
andreas at pc-linux-dev:~/arrtest> cat common.h
int showwrong(void);

andreas at pc-linux-dev:~/arrtest> cat common.c
#include <stdio.h>

extern const unsigned char test[];

int showwrong(void)
{
         printf("test[]: 0x%08X\n", (int)test);
         return 0;
}

andreas at pc-linux-dev:~/arrtest> cat array.c
#include "common.h"

const unsigned char *test = (unsigned char*)0x40000;

int main(void)
{
         printf("*test: 0x%08X\n", (int)test);
         showwrong();
         return 0;
}
andreas at pc-linux-dev:~/arrtest> gcc -o arrtest -I ./ ./common.c ./array.c
andreas at pc-linux-dev:~/arrtest> ./arrtest
*test: 0x00040000
test[]: 0x080494E4
--- END OF CONSOLE OUTPUT

What buffles me is, that on your side, the *test-output isn't 0x40000,  
because the
pointer is initialized directly in that object and used as pointer. And on  
the other
hand, the output can't be the same:
extern char test[]; ==> results in a symbol at the start address of the  
array.
char *test; ==> is a pointer containing the start-address of the array.  
This means one
more level of reference.

Could you please show your source files as they were used for your test to  
us. I'm
still sure, both notations are not the same, although they work the same  
in most cases.

Regards,
Andreas


30.06.2005 19:28:32, Jerry Van Baren  
<gerald.vanbaren@smiths-aerospace.com> wrote:

> Rune Torgersen wrote:
>> Wow.... This surprises me...
>> I have alwayts thought that *test and test[] would be the same thing.
>> Only solutionI can see is to change the definition in common.c to be
>> *test, this will still get the address of test[] defined elsewhere.
>> (See attached files)
>>
>>> Sure, I've tried this. This is the point, where my problemarose.  
>>> Attached you find twosmall files, you can easily compile under linux  
>>> (gcc -oarrtest -I ./ ./common.c./array.c). The file "common.c"  
>>> represents the code I can't(don't want to) touch."array.c" represents  
>>> my project dependent code. If you runarrtest it will show to you,
>
> With the patch in place (previously sent to the list), it works for  
> linux:
>
> vanbaren at sherwood:~/x> ll
> total 32
> -rwxr-----  1 vanbaren users  200 Jun 30 13:24 array.c
> -rwxr-xr-x  1 vanbaren users 8963 Jun 30 13:26 arrtest
> -rwxr-----  1 vanbaren users  132 Jun 30 08:03 common.c
> -rwxr-----  1 vanbaren users  121 Jun 30 08:03 common.c-original
> -rw-r--r--  1 vanbaren users  237 Jun 30 08:04 common.c.diff
> -rwxr-----  1 vanbaren users   24 Jun 30 13:23 common.h
> vanbaren at sherwood:~/x> gcc -o arrtest -I ./ ./common.c ./array.c
> vanbaren at sherwood:~/x> ./arrtest
> *test: 0x08048558
> test[]: 0x08048558
>
> gvb
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>
>
>

[U-Boot-Users] Does u-boot relocate absolute symbols?

[Andreas Block]

Rune: I'm sorry for the inconvenience, but I sent this mail to you instead  
of the U-Boot mailinglist.

And WD already slapped me for sending this example...

30.06.2005 18:54:40, "Rune Torgersen" <runet@innovsys.com> wrote:

> Wow.... This surprises me...
> I have alwayts thought that *test and test[] would be the same thing.
>
> Only solutionI can see is to change the definition in common.c to be
> *test, this will still get the address of test[] defined elsewhere.
> (See attached files)

Thanks, for your effort. Actually your suggestion is the way it's  
currently working
here, but as I described in my first post, I'm looking for a way, which  
leaves the
common code untouched. In my first post on 24.06.05 I've another solution,  
which is
working for Linux, but does not in U-Boot.

Regards,
Andreas


>> Sure, I've tried this. This is the point, where my problemarose.  
>> Attached you find twosmall files, you can easily compile under linux  
>> (gcc -oarrtest -I ./ ./common.c./array.c). The file "common.c"  
>> represents the code I can't(don't want to) touch."array.c" represents  
>> my project dependent code. If you runarrtest it will show to you,
>

[U-Boot-Users] Does u-boot relocate absolute symbols?

[Jerry Van Baren]

I ran the code you (Andreas) sent, with the one correction for the 
printf().  The code you sent did not set the test array pointer to 
0x40000.  When I use the code you _ment_ rather than what you _sent_ 
(see below - sorry for top-quoting), I get the same effect you get:

vanbaren at sherwood:~/x> ./arrtest
*test: 0x08048558
test[]: 0x08048558

vanbaren at sherwood:~/x> ./arrtest-ptr
*test: 0x00040000
test[]: 0x08048558

I think I now understand the root of your problem.  You want to place an 
initialized array at a specific location.  C has a way of initializing 
arrays:
   const unsigned char test[] = { value... };
and a way of making a pointer to an array:
   const unsigned char *test = (unsigned char*)0x40000;
but it doesn't have a way to do _both_ at the same time.  You are trying 
to avoid the need for two initializations in one declaration limitation 
by doing it _differently_ in _two_ different places.  This is confusing 
the compiler and/or the linker.

I would guess this is a compiler/linker interaction that could be 
labeled unfortunate lack of communications or a bug, depending on your 
frustration level for the day.

I would contend that the "proper" solution is to declare the array 
consistantly and with data initialization in common.h:
   #ifdef EXTERN
     EXTERN const unsigned char test[];
   #else
     const unsigned char test[] = { 0, 1, 2 };
   #endif
(with EXTERN #defined to be extern in exactly one file, in your example 
it would be #defined in array.c -- see attached) and then use the linker 
control file to place the resulting array in the proper location (you 
may need a new section and place "test" in the new section).

I cannot claim expertise in the area, but it looks to me that the 
problem has nothing to do with u-boot relocation per se.  It is a 
language/compiler/linker issue.

You still may have to resolve relocation issues, depending on where you 
locate the resulting array data and whether it gets copied and whether 
it is available in the ROM location, but that is a red herring at this 
point.

gvb


Andreas Block wrote:
> I'm not quite sure, what happened on your side.
> Here's the result on my side (together with the source as it ought look):
> 
> --- BEGIN OF CONSOLE OUTPUT
> andreas at pc-linux-dev:~/arrtest> cat common.h 
> int showwrong(void);
> 
> andreas at pc-linux-dev:~/arrtest> cat common.c 
> #include <stdio.h>
> 
> extern const unsigned char test[];
> 
> int showwrong(void)
> {
>         printf("test[]: 0x%08X\n", (int)test);
>         return 0;
> }
> 
> andreas at pc-linux-dev:~/arrtest> cat array.c 
> #include "common.h"
> 
> const unsigned char *test = (unsigned char*)0x40000;
> 
> int main(void)
> {
>         printf("*test: 0x%08X\n", (int)test);
>         showwrong();
>         return 0;
> }
> andreas at pc-linux-dev:~/arrtest> gcc -o arrtest -I ./ ./common.c ./array.c
> andreas at pc-linux-dev:~/arrtest> ./arrtest 
> *test: 0x00040000
> test[]: 0x080494E4
> --- END OF CONSOLE OUTPUT
> 
> What buffles me is, that on your side, the *test-output isn't 0x40000, because the 
> pointer is initialized directly in that object and used as pointer. And on the other 
> hand, the output can't be the same:
> extern char test[]; ==> results in a symbol at the start address of the array.
> char *test; ==> is a pointer containing the start-address of the array. This means one 
> more level of reference.
> 
> Could you please show your source files as they were used for your test to us. I'm 
> still sure, both notations are not the same, although they work the same in most cases.
> 
> Regards,
> Andreas
> 
> 
> 30.06.2005 19:28:32, Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com> wrote:
> 
> 
>>Rune Torgersen wrote:
>>
>>>Wow.... This surprises me...
>>>I have alwayts thought that *test and test[] would be the same thing.
>>>
>>>Only solutionI can see is to change the definition in common.c to be
>>>*test, this will still get the address of test[] defined elsewhere.
>>>(See attached files)
>>>
>>>
>>>
>>>>Sure, I've tried this. This is the point, where my problem 
>>>>arose. Attached you find two 
>>>>small files, you can easily compile under linux (gcc -o 
>>>>arrtest -I ./ ./common.c 
>>>>./array.c). The file "common.c" represents the code I can't 
>>>>(don't want to) touch. 
>>>>"array.c" represents my project dependent code. If you run 
>>>>arrtest it will show to you, 
>>
>>With the patch in place (previously sent to the list), it works for linux:
>>
>>vanbaren at sherwood:~/x> ll
>>total 32
>>-rwxr-----  1 vanbaren users  200 Jun 30 13:24 array.c
>>-rwxr-xr-x  1 vanbaren users 8963 Jun 30 13:26 arrtest
>>-rwxr-----  1 vanbaren users  132 Jun 30 08:03 common.c
>>-rwxr-----  1 vanbaren users  121 Jun 30 08:03 common.c-original
>>-rw-r--r--  1 vanbaren users  237 Jun 30 08:04 common.c.diff
>>-rwxr-----  1 vanbaren users   24 Jun 30 13:23 common.h
>>vanbaren at sherwood:~/x> gcc -o arrtest -I ./ ./common.c ./array.c
>>vanbaren at sherwood:~/x> ./arrtest
>>*test: 0x08048558
>>test[]: 0x08048558
>>
>>gvb
>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> 
>>from IBM. Find simple to follow Roadmaps, straightforward articles,
> 
>>informative Webcasts and more! Get everything you need to get up to
>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>_______________________________________________
>>U-Boot-Users mailing list
>>U-Boot-Users at lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/u-boot-users
>>
>>
>>
> 
> 
> 
> 

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: common.h
Url: http://lists.denx.de/pipermail/u-boot/attachments/20050701/819f0a91/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: array.c
Url: http://lists.denx.de/pipermail/u-boot/attachments/20050701/819f0a91/attachment-0001.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: common.c
Url: http://lists.denx.de/pipermail/u-boot/attachments/20050701/819f0a91/attachment-0002.txt 

[U-Boot-Users] Does u-boot relocate absolute symbols?

[Andreas Block]

Hi Jerry,

thanks for your time.

On Fri, 01 Jul 2005 16:35:49 +0200, Jerry Van Baren  
<gerald.vanbaren@smiths-aerospace.com> wrote:

> I ran the code you (Andreas) sent, with the one correction for the
> printf().  The code you sent did not set the test array pointer to
> 0x40000.

I did look at the code, I had sent originally (with the typo you proposed)  
and in line 3 of array.c *test is initialized to 0x40000. I was writing  
big time nonsens that morning, but I wasn't that bad.


>  When I use the code you _ment_ rather than what you _sent_
> (see below - sorry for top-quoting), I get the same effect you get:
>
> vanbaren at sherwood:~/x> ./arrtest
> *test: 0x08048558
> test[]: 0x08048558
>
> vanbaren at sherwood:~/x> ./arrtest-ptr
> *test: 0x00040000
> test[]: 0x08048558
>
> I think I now understand the root of your problem.  You want to place an
> initialized array at a specific location.  C has a way of initializing
> arrays:
>    const unsigned char test[] = { value... };
> and a way of making a pointer to an array:
>    const unsigned char *test = (unsigned char*)0x40000;
> but it doesn't have a way to do _both_ at the same time.  You are trying
> to avoid the need for two initializations in one declaration limitation
> by doing it _differently_ in _two_ different places.  This is confusing
> the compiler and/or the linker.

As I already said, this is no bug in the compiler nor the linker. It is  
C-language and this example isn't supposed to work. It's just to show a  
peculiarity of C-language (or better a peculiarity of how most people  
(incl. me) understand C-language). It took me some time to realize, but I  
realized _before_ posting here. Your suggestion again ends up with changes  
in common.h, which is the only thing I'd like to avoid. Don't get me  
wrong, thanks for the time you've invested in order to help me. But I had  
a workaround (with changes in common code) running, before I posted the  
first time.


> I would guess this is a compiler/linker interaction that could be
> labeled unfortunate lack of communications or a bug, depending on your
> frustration level for the day.
> [...]
> You still may have to resolve relocation issues, depending on where you
> locate the resulting array data and whether it gets copied and whether
> it is available in the ROM location, but that is a red herring at this
> point.

The entire discussion is more about, should/could be something changed in  
U-Boot/linker script in order to make relocation somewhat more  
consistent/generic/orthogonal.

Best regards,
Andreas Block