[U-Boot-Users] Relocation of symbols?

[U-Boot-Users] Relocation of symbols?

[Andreas Block]

Hi,

I've posted another question regarding this topic on 14th June 2005. Since I haven't 
received any answers, I'm unsure, if I'm in the correct mailinglist or if my problem 
was that trivial. In case of the latter one, please, give me a hint, where to post my 
questions instead.

So here's my new question:

I've declared a global array:
char *walter[] = { "ABC", "DEF" };

The u-boot boots from flash and relocates itself into RAM. After relocation the array 
is relocated into RAM and so is its content (the pointers to strings). But the actual 
strings are still located in flash. "walter" is a global symbol located in ".data" 
section of the compiled object. Is this the behaviour I should expect, or is it a 
problem with u-boots relocation code?

Best regards,
Andreas Block

[U-Boot-Users] Relocation of symbols?

[Wolfgang Denk]

Dear Andreas,

in message <3YJEA6HGSNLF3264765ZTQSQYSRNJI43.42bffa31@pc-block> you wrote:
> 
> I've posted another question regarding this topic on 14th June 2005. Since I haven't 
> received any answers, I'm unsure, if I'm in the correct mailinglist or if my problem 
> was that trivial. In case of the latter one, please, give me a hint, where to post my 
> questions instead.

You are on the right list here.

It's just that not many people really understand all the details  how
the relocation works.

> The u-boot boots from flash and relocates itself into RAM. After relocation the array 
> is relocated into RAM and so is its content (the pointers to strings). But the actual 
> strings are still located in flash. "walter" is a global symbol located in ".data" 
> section of the compiled object. Is this the behaviour I should expect, or is it a 
> problem with u-boots relocation code?

If you look at the code, then you  will  find  that  the  same  thing
happens  to  all  pointers with static initialization. If you think a
bit about it you will probably be not  surprised  -  how  should  the
compiler  know  that  the addresses of your strings might change? and
after the compiler generated code with a  static  initializer  -  who
should  then know that the contents of this variable might need to be
relocated?

See for example how we manually adjust (= relocate) the command table
and other pointer constants in board_init_r().

I guess you can probably tell  GCC  to  add  GOT  entries  for  these
pointers,  but  I have to admit that I don't know off-hand what's the
most efficient way.

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
He had quite a powerful intellect, but it  was  as  powerful  like  a
locomotive,  and  ran on rails and was therefore almost impossible to
steer.                          - Terry Pratchett, _Lords and Ladies_

[U-Boot-Users] Relocation of symbols?

[Grant Likely]

On 6/27/05, Wolfgang Denk <wd@denx.de> wrote:
> Dear Andreas,
> 
> in message <3YJEA6HGSNLF3264765ZTQSQYSRNJI43.42bffa31@pc-block> you wrote:

> 
> It's just that not many people really understand all the details  how
> the relocation works.

<stuff deleted>

> I guess you can probably tell  GCC  to  add  GOT  entries  for  these
> pointers,  but  I have to admit that I don't know off-hand what's the
> most efficient way.
> 
Just to satisfy my curiosity...

What is the design decision behind u-boot building as a single
relocatable binary (with all the complexities associated with
relocation)?  As opposed to a a two stage process with a small chunk
of bootstrap code encapsulating the main u-boot image.  The bootstrap
code being linked seperatly from the main image so each image runs in
the address space it is linked to.  (like a Linux zImage; bootstrap
code only responsible for initializing RAM, copying the main image and
jumping to it).

I can see that a two stage scheme would sidestep the relocation issues
mentioned above and should make probing with a debugger simpler.  What
are the advantages of the single binary approach?  Image size perhaps?

Cheers,
g.

[U-Boot-Users] Relocation of symbols?

[Wolfgang Denk]

In message <528646bc05062709261380120e@mail.gmail.com> you wrote:
> 
> What is the design decision behind u-boot building as a single
> relocatable binary (with all the complexities associated with

Making it as easy to port to new hardware and to debug  as  possible.
Which  includes  for example initializing a serial (or other) console
port as soon as possible in the  initialization  sequence.  Which  in
turn requires access to a lot of functions in the "general" code like
stdio  and  string  functions, access to the environment (to read the
baudrate definition), which in turn may require access to  I2C  (like
to access an EEPROM) etc.

> relocation)?  As opposed to a a two stage process with a small chunk
> of bootstrap code encapsulating the main u-boot image.  The bootstrap

Such a "small chunk" would have to include the most critical hadrware
initialization, especially that of the  SDRAM.  If  you  follow  this
mailing  list  for a while you will know that this alone makes 99% of
all the "help me" postings on this list, even  though  it  is  really
easy  to  debug:  you have printf() and all the like. Now assume this
was in a "small chunk" which has to work without all these features -
and which is failing silently as a black box.

> code being linked seperatly from the main image so each image runs in
> the address space it is linked to.  (like a Linux zImage; bootstrap
> code only responsible for initializing RAM, copying the main image and
> jumping to it).

The "only" in this sentence in inappropriate. This is one of the most
critical areas, and you really want to have all comfort for debugging
that you can get.

Try searching this list  and  count  how  many  people  report  about
problems  where the system hangs or acts weird just after relocation.
Assume this happened in some minimal assember code  without  console,
without printf etc. You really don't want to have that.

> I can see that a two stage scheme would sidestep the relocation issues
> mentioned above and should make probing with a debugger simpler.  What
> are the advantages of the single binary approach?  Image size perhaps?

No, the major concern is to make U-Boot easy to debug  and  to  port.
All the things that happen after relocation are "simple" issues ;-)

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
The human race is faced with a cruel choice: work  or  daytime  tele-
vision.

[U-Boot-Users] Relocation of symbols?

[Grant Likely]

On 6/27/05, Wolfgang Denk <wd@denx.de> wrote:
> In message <528646bc05062709261380120e@mail.gmail.com> you wrote:
> > relocation)?  As opposed to a a two stage process with a small chunk
> > of bootstrap code encapsulating the main u-boot image.  The bootstrap
> 
> Such a "small chunk" would have to include the most critical hadrware
> initialization, especially that of the  SDRAM.  If  you  follow  this
> mailing  list  for a while you will know that this alone makes 99% of
> all the "help me" postings on this list, even  though  it  is  really
> easy  to  debug:  you have printf() and all the like. Now assume this
> was in a "small chunk" which has to work without all these features -
> and which is failing silently as a black box.
I do understand this; I wasn't very clear what I meant, see below.

> 
> > code being linked seperatly from the main image so each image runs in
> > the address space it is linked to.  (like a Linux zImage; bootstrap
> > code only responsible for initializing RAM, copying the main image and
> > jumping to it).
> 
> The "only" in this sentence in inappropriate. This is one of the most
> critical areas, and you really want to have all comfort for debugging
> that you can get.
Let me clarify: I'm using "only" to refer to responsibilities, not to
code size or debug facilities.  I agree that bootstrapping is the most
critical function and debug support is non-negotiable.  I meant that
the bootstrap is responsible to get the board ready for the second
stage; It would not have any exotic functionality for were to get the
second stage or handling boot options.  All that would stay in the
second stage.

> 
> Try searching this list  and  count  how  many  people  report  about
> problems  where the system hangs or acts weird just after relocation.
> Assume this happened in some minimal assember code  without  console,
> without printf etc. You really don't want to have that.
And I do understand this; I was not suggesting an absolute minimalist
environment.  Other than final footprint size (which is not a small
issue either), there is nothing preventing common code from being
linked into both images.  Are there any estimates/measurements on how
much code is executed both before and after relocation?

The problem with relocation is that it adds a layer of complexity to
the debug process after jumping into RAM.  Things such as the
manipulating the command tables so the pointers match up again.  Every
time a new static or global is added, you need to worry about such
things.

For example; when built for flash you cannot load the image into RAM
and run it (i.e. from dBug) to see if the code after relocation is
working correctly.  This makes it more difficult to track down a
relocation problem.  When relocation hangs, it can be difficult to
isolate the problem down to code running before or after relocation. 
However, if it was a two stage image, you could run the RAM stage from
dBug.  If it doesn't work then you know you need to fix the RAM image
problem before fixing the ROM code.  If it does work then you know the
problem is with the ROM portion.  As a bonus, you know that code
running out of RAM is identical regardless of whether you've booted
from FLASH or not.

Ultimatly, I'm asking/debating whether or not a two-image scheme would
make it simpler to debug.  Granted there are other issues, such as
duplicate copies of functions; but that's why I'm asking, to get other
perspectives and become a better designer.  :-)

Comments?

[U-Boot-Users] Relocation of symbols?

[Wolfgang Denk]

In message <528646bc050627152162d1dba@mail.gmail.com> you wrote:
>
> The problem with relocation is that it adds a layer of complexity to
> the debug process after jumping into RAM.  Things such as the

It's nothing compared to what you get with a two stage  process.  You
either  end  up  with  lots  of  code duplication (and duplication of
problems and a huge memory footprint) or with a system that is a PITA
to port to new hardware.

> manipulating the command tables so the pointers match up again.  Every
> time a new static or global is added, you need to worry about such
> things.

Remember that this effects only staticaly intialized pointers. 

The simple thing to do is to avoid these.

There are other restrictions like having no writable data segment nor
zeroed bss space in the starup phase. We  can  live  with  this  just
fine.

> For example; when built for flash you cannot load the image into RAM
> and run it (i.e. from dBug) to see if the code after relocation is
> working correctly.  This makes it more difficult to track down a

Sorry, I don't understand what you mean.

> relocation problem.  When relocation hangs, it can be difficult to
> isolate the problem down to code running before or after relocation. 

No, this is a trivial case. When relocation hangs,  then  your  SDRAM
initialization is broken. Period.

> However, if it was a two stage image, you could run the RAM stage from
> dBug.  If it doesn't work then you know you need to fix the RAM image
> problem before fixing the ROM code.  If it does work then you know the

You don't understand. The problems are NOT int the  "running  in  RAM
part".  This  is  simple  stuff.  It usually just works, once you got
there. We spend 95% of teh porting and debugging time  in  the  other
part.

> Ultimatly, I'm asking/debating whether or not a two-image scheme would
> make it simpler to debug.  Granted there are other issues, such as
> duplicate copies of functions; but that's why I'm asking, to get other
> perspectives and become a better designer.  :-)

Been there before. I know exactly why I don't  want  to  change  this
part  of  the  design. Feel free to try it out on your own. Port your
code to 3 or 4 boards. I'm sure we'll see you back here soon.

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
Man is the best computer we can put aboard a spacecraft ...  and  the
only one that can be mass produced with unskilled labor.
                                                 -- Wernher von Braun

[U-Boot-Users] Relocation of symbols?

[Grant Likely]

On 6/27/05, Wolfgang Denk <wd@denx.de> wrote:
> In message <528646bc050627152162d1dba@mail.gmail.com> you wrote:
> > Ultimatly, I'm asking/debating whether or not a two-image scheme would
> > make it simpler to debug.  Granted there are other issues, such as
> > duplicate copies of functions; but that's why I'm asking, to get other
> > perspectives and become a better designer.  :-)
> 
> Been there before. I know exactly why I don't  want  to  change  this
> part  of  the  design. Feel free to try it out on your own. Port your
> code to 3 or 4 boards. I'm sure we'll see you back here soon.
> 

Thanks for the info; I'd been wondering about the design background
for a while, so it's good to get the perspective.

Cheers,
g.

[U-Boot-Users] Relocation of symbols?

[Andreas Block]

Hello Wolfgang,

thanks for your quick reply.

27.06.2005 15:40:25, Wolfgang Denk <wd@denx.de> wrote:

>Dear Andreas,
> 
> [cut...]
>
>It's just that not many people really understand all the details  how
>the relocation works.
>
>> The u-boot boots from flash and relocates itself into RAM. After relocation the
>> array is relocated into RAM and so is its content (the pointers to strings). But the 
>> actual strings are still located in flash. "walter" is a global symbol located in 
>> ".data" section of the compiled object. Is this the behaviour I should expect, or is
>> it a problem with u-boots relocation code?
>
>If you look at the code, then you  will  find  that  the  same  thing
>happens  to  all  pointers with static initialization. If you think a
>bit about it you will probably be not  surprised  -  how  should  the
>compiler  know  that  the addresses of your strings might change? and
>after the compiler generated code with a  static  initializer  -  who
>should  then know that the contents of this variable might need to be
>relocated?
>
>See for example how we manually adjust (= relocate) the command table
>and other pointer constants in board_init_r().
>
>I guess you can probably tell  GCC  to  add  GOT  entries  for  these
>pointers,  but  I have to admit that I don't know off-hand what's the
>most efficient way.

I'm not quite sure, if I understood you.
Just to summerize:
1. Absolute symbols are always relocated (my mail: "Does u-boot relocate absolute 
symbols?", 14.06.2005).
2. Statically initialized pointers are never relocated.

I do understand the second point (and can live with this behaviour), but I'd like to 
know, where you loose the required information to relocate the pointers as well.
The first point is more important to me. As I understand, absolute symbols shouldn't be 
relocated at all. But I guess, you've a similar reason as for the statically 
initialized pointers. Anyway: Is it possible in any way to locate the array at the 
position I want it to be? Or the other way round: Is it as difficult to prevent 
absolute symbols from being added to the GOT as adding something?

Regards,
Andreas


>
>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
>He had quite a powerful intellect, but it  was  as  powerful  like  a
>locomotive,  and  ran on rails and was therefore almost impossible to
>steer.                          - Terry Pratchett, _Lords and Ladies_
>
>
>

[U-Boot-Users] Relocation of symbols?

[Wolfgang Denk]

In message <CNLTR94IEOA0NLOJC7FCATQTQJGRO.42c14780@pc-block> you wrote:
> 
> Just to summerize:
> 1. Absolute symbols are always relocated (my mail: "Does u-boot relocate absolute 
> symbols?", 14.06.2005).

I don't think so. An absolute symbol is, ummm, absolute.

> 2. Statically initialized pointers are never relocated.

Right.

> I do understand the second point (and can live with this behaviour), but I'd like to 
> know, where you loose the required information to relocate the pointers as well.

We don't lose anything. The compiler /  linker  never  has  any  such
information.

For example, asssume we  have  three  pointers  that  are  statically
initialized.  One  is  initialized  with the physical address of some
peripheral on your board, the  second  one  with  the  address  of  a
function  in  the  U-Boot  code,  and the third one with the constant
0x12345678;

For GCC all three of them are just initialized pointers.  Who  should
decide which of these need relocation, and which not?

> The first point is more important to me. As I understand, absolute symbols shouldn't be 
> relocated at all. But I guess, you've a similar reason as for the statically 

I can't parse this.

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.

> initialized pointers. Anyway: Is it possible in any way to locate the array at the 
> position I want it to be? Or the other way round: Is it as difficult to prevent 
> absolute symbols from being added to the GOT as adding something?

I mentioned the simple solution before: either you  avoid  statically
initialized  function  pointers  (for  examply  by initializing these
dynamically after relocation), of you manually adjust  your  pointers
after  relocation,  like  we  do for example for the command table. I
also mentioned that there may be ways (like putting your stuff  in  a
special segment and taking care to relocate this) to handle this, but
I don't have a solution ready, nor do I see an urgent need for it.

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
Ever try. Ever fail. No matter. Try again. Fail again.  Fail  better.
                                                        -- S. Beckett

[U-Boot-Users] Relocation of symbols?

[Andreas Block]

28.06.2005 16:01:56, Wolfgang Denk <wd@denx.de> wrote:

>In message <CNLTR94IEOA0NLOJC7FCATQTQJGRO.42c14780@pc-block> you wrote:
>> 
>> Just to summerize:
>> 1. Absolute symbols are always relocated (my mail: "Does u-boot relocate absolute 
>> symbols?", 14.06.2005).
>
>I don't think so. An absolute symbol is, ummm, absolute.
>
>> 2. Statically initialized pointers are never relocated.
>
>Right.

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.


> [...]
>
>For GCC all three of them are just initialized pointers.  Who  should
>decide which of these need relocation, and which not?

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";

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 first point is more important to me. As I understand, absolute symbols shouldn't 
>> be relocated at all. But I guess, you've a similar reason as for the statically 
>
>I can't parse this.
>
>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.

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.


>> initialized pointers. Anyway: Is it possible in any way to locate the array at the 
>> position I want it to be? Or the other way round: Is it as difficult to prevent 
>> absolute symbols from being added to the GOT as adding something?
>
>I mentioned the simple solution before: either you  avoid  statically
>initialized  function  pointers  (for  examply  by initializing these
>dynamically after relocation), of you manually adjust  your  pointers
>after  relocation,  like  we  do for example for the command table. I
>also mentioned that there may be ways (like putting your stuff  in  a
>special segment and taking care to relocate this) to handle this, but
>I don't have a solution ready, nor do I see an urgent need for it.

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.

Best regards,
Andreas Block

[U-Boot-Users] Relocation of symbols?

[Wolfgang Denk]

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?

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) ?

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

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

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

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
Making files is easy under  the  UNIX  operating  system.  Therefore,
users  tend  to  create  numerous  files  using large amounts of file
space. It has been said that the only standard thing about  all  UNIX
systems  is  the  message-of-the-day  telling users to clean up their
files.                             - System V.2 administrator's guide

[U-Boot-Users] Relocation of symbols?

[Andreas Block]

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?
>
>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) ?

Well, I did show you the output of the generated object itself (before it got linked 
against U-Boot) and all I did in my test-command in U-Boot was to print the address of 
the symbol. All I can think of is relocation. But I'll think again, do some more tests 
and send you the result tomorrow.


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

Of course it's not the compiler, but the linker. When talking about compiler, I was 
speaking of the entire tool-chain, sorry, for this imprecision. But I can show you, 
that it is indeed two different thinks for the compiler (which reaches some information 
about this difference to the linker). I'll do this tomorrow, too.


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

But the compiler tags relocation marks for the linker, right?


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

Thanks a lot, I got that one.


>> 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 ;-)

If I avoided all things I don't understand, I wouldn't have much to do, would I?


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

I will explain this once more in detail tomorrow. The main problem lies in the fact, 
that I don't want to touch any common code, but want to achive a solution within my 
project's code, only.

Regards,
Andreas Block

[U-Boot-Users] Relocation of symbols?

[Andreas Block]

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


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

[U-Boot-Users] Relocation of symbols?

[Wolfgang Denk]

In message <1ZQN5YCAUQ07JHUTNMTVTZWLHCTQQM.42c27942@pc-block> you wrote:
>
...
> 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.

I still can't understand why you cannot  simply  use  an  unitialized
pointer,  or  even one which has a random init value, and then adjust
it in your board specific code, say in a misc_init_r() or maybe  even
in a board_early_init_r() function?

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
Fascinating, a totally parochial attitude.
	-- Spock, "Metamorphosis", stardate 3219.8

[U-Boot-Users] Relocation of symbols?

[Andreas Block]

29.06.2005 15:32:17, Wolfgang Denk <wd@denx.de> wrote:

>In message <1ZQN5YCAUQ07JHUTNMTVTZWLHCTQQM.42c27942@pc-block> you wrote:
>>
>...
>> 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.
>
>I still can't understand why you cannot  simply  use  an  unitialized
>pointer,  or  even one which has a random init value, and then adjust
>it in your board specific code, say in a misc_init_r() or maybe  even
>in a board_early_init_r() function?

Hmm, I take this as a refusal to help and a refusal to acquire new information. For me 
this is quite a basic problem, perhaps with my understanding, but meanwhile I guess not 
with my understanding, but with U-Boot itself. I'm not really looking for a workaround. 
The workaround for me, would be to change the common code and do another round of 
testing on all affected systems (which by the way is also needed with your suggestion). 
I was looking for information, understanding and a reason, why the way I had chosen 
failed. And once again, your suggestion to initialize a pointer in my project dependent 
code, absolutely ignores the fact, that the array is declared in common code as:

extern const char walter[];

Perhaps you don't see a difference to the following notation, which I had to use in my 
project dependent code:

extern const char *walter;

But there is one, even if you refuse to recognize. Feel free to ask, if you'd like to 
know.

I also wonder, whether the issue with the relocation of statically initialized pointers 
is solved?

Regards,
Andreas

[U-Boot-Users] Relocation of symbols?

[Wolfgang Denk]

In message <8ECMIB8MIIC528283SP05OJFEB784F.42c2ad3d@pc-block> you wrote:
> 
> >I still can't understand why you cannot  simply  use  an  unitialized
> >pointer,  or  even one which has a random init value, and then adjust
> >it in your board specific code, say in a misc_init_r() or maybe  even
> >in a board_early_init_r() function?
> 
> Hmm, I take this as a refusal to help and a refusal to acquire new information. For me 

Bollocks. Why don't you just take it as what it is: a  question,  and
the attempt to understand your situation?

The attitude you display here does not really add to my motivation to
dig into this later tonight as I originally intended.

> this is quite a basic problem, perhaps with my understanding, but meanwhile I guess not 
> with my understanding, but with U-Boot itself. I'm not really looking for a workaround. 

That's a pity, because a workaround is probably easier available.

> The workaround for me, would be to change the common code and do another round of 

I think you could do without such a change. This may require a little
hack, and may even result in a not strictly standard  conforming  im-
plementation, but I think it can be done.

> failed. And once again, your suggestion to initialize a pointer in my project dependent 
> code, absolutely ignores the fact, that the array is declared in common code as:
> 
> extern const char walter[];
> 
> Perhaps you don't see a difference to the following notation, which I had to use in my 
> project dependent code:
> 
> extern const char *walter;
> 
> But there is one, even if you refuse to recognize. Feel free to ask, if you'd like to 
> know.

I have no idea why you think I ignored your arguments. I  never  said
anything  like  this. Of course there is a difference. I am perfectly
aware of this. But does it really prevent you  from  doing  what  you
want  to  do? There is so many things you can do. For a little demon-
stration of what can be done in C have a look at the winning  entries
of the IOCCC at http://www.de.ioccc.org/years.html :-)

> I also wonder, whether the issue with the relocation of statically initialized pointers 
> is solved?

There is no "issue" from my point of view. We know the situation, and
we know how to live with it (by manually relocating the pointers).

When I ran into this situation 5 years ago I  didn't  find  a  better
solution  in  a reasonable time. Feel free to show me that there is a
better approach.

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
At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it  on
the computer.

[U-Boot-Users] Relocation of symbols?

[Andreas Block]

29.06.2005 19:32:46, Wolfgang Denk <wd@denx.de> wrote:

>In message <8ECMIB8MIIC528283SP05OJFEB784F.42c2ad3d@pc-block> you wrote:
>> 
>> >I still can't understand why you cannot  simply  use  an  unitialized
>> >pointer,  or  even one which has a random init value, and then adjust
>> >it in your board specific code, say in a misc_init_r() or maybe  even
>> >in a board_early_init_r() function?
>> 
>> Hmm, I take this as a refusal to help and a refusal to acquire new information.
>> For me 
>
>Bollocks. Why don't you just take it as what it is: a  question,  and
>the attempt to understand your situation?
>
>The attitude you display here does not really add to my motivation to
>dig into this later tonight as I originally intended.

Well, I'm sorry. I didn't want to sound rude. I was a bit dissappointed, because it 
seemed to me like you were ignoring great parts of my last post and sort of retreated 
to safer grounds.

Perhaps you could explain to me, how you think I could initialize the declared array at 
those positions you propose (it's not a problem of finding the referenced functions, 
but of knowing how to do it). I've sent a small example as answer to Rune Torgersen, 
which shows quite well, that one can't initialize/locate an "open" array (like fpgadata
[]) by initializing a pointer of the same name. Seemingly it's me, who's failing to 
see, but I don't get how your hint helps me with this.


>> this is quite a basic problem, perhaps with my understanding, but meanwhile I guess 
>> not with my understanding, but with U-Boot itself. I'm not really looking for 
>> a workaround. 
>
>That's a pity, because a workaround is probably easier available.

Sure. The project is actually working. All I'd like to do is to remove the changes done 
to common code and understand, where my problem with U-Boot stems from. If it's me, 
who's not getting it or if there's perhaps a slightly strange/non-generic behaviour in 
U-Boot. It took me quite a while to find out about my initialization problem and the 
non-relocated array-content (it was actually my debug output, which stayed in flash and 
wasn't of any help, when my PLD programmer killed the PLD and thus the flash access) 
and I would like to avoid such pain in the future.


>> The workaround for me, would be to change the common code and do another round of 
>
>I think you could do without such a change. This may require a little
>hack, and may even result in a not strictly standard  conforming  im-
>plementation, but I think it can be done.
>
>> failed. And once again, your suggestion to initialize a pointer in my project 
>> dependent code, absolutely ignores the fact, that the array is declared in
>> common code as:
>> 
>> extern const char walter[];
>> 
>> Perhaps you don't see a difference to the following notation, which I had to use in 
>> my project dependent code:
>> 
>> extern const char *walter;
>> 
>> But there is one, even if you refuse to recognize. Feel free to ask, if you'd like 
>> to know.
>
>I have no idea why you think I ignored your arguments. I  never  said
>anything  like  this. Of course there is a difference. I am perfectly
>aware of this. But does it really prevent you  from  doing  what  you
>want  to  do? There is so many things you can do. For a little demon-
>stration of what can be done in C have a look at the winning  entries
>of the IOCCC at http://www.de.ioccc.org/years.html :-)

Well, at first, you cut away three quarters of my last post. Second, you told me in one 
of your answers, that the compiler knows no differences between these initializations 
and told me, U-Boot wasn't able to distinguish between them either. And no, it does not 
entirely prevent me from what I want to do, but it keeps me from doing it the smoothest 
way or the way I'd like to do it best.


>> I also wonder, whether the issue with the relocation of statically initialized 
pointers 
>> is solved?
>
>There is no "issue" from my point of view. We know the situation, and
>we know how to live with it (by manually relocating the pointers).
>
>When I ran into this situation 5 years ago I  didn't  find  a  better
>solution  in  a reasonable time. Feel free to show me that there is a
>better approach.

I'm afraid, I currently don't have the knowledge, nor the time (at least not at work) 
to do it in a better way. But I thought, perhaps you would like to at least discuss the 
way it's done now and perhaps, combined with your knowledge of how the things are 
running today, come to see a new/better/more generic way of doing it. But please don't 
get me wrong again, I certainly don't want to sound like I'm requesting a change in U-
Boot or something alike.

Best regards,
Andreas Block

[U-Boot-Users] Relocation of symbols?

[Wolfgang Denk]

In message <SNHBXT98B63SQ98BA765YIC51A95Z52.42c3a90c@pc-block> you wrote:
>
> Well, I'm sorry. I didn't want to sound rude. I was a bit dissappointed, because it 
> seemed to me like you were ignoring great parts of my last post and sort of retreated 
> to safer grounds.

I accept ypour aplogy. I just have a habit of NOT trying  to  address
the  problem  the  same way and following the same thoughs - if I did
this, O probably ended up with the same conclusions like you  and  no
solution  at  all. Instead, I try to remember that There Is More Than
One Way To Do Things.

That's why I ask for information that my seem irrelevant to  you,  or
that I seem to ignore information you provided while I'm trying to go
a different way.

> Perhaps you could explain to me, how you think I could initialize the declared array at 
> those positions you propose (it's not a problem of finding the referenced functions, 
> but of knowing how to do it). I've sent a small example as answer to Rune Torgersen, 
> which shows quite well, that one can't initialize/locate an "open" array (like fpgadata
> []) by initializing a pointer of the same name. Seemingly it's me, who's failing to 
> see, but I don't get how your hint helps me with this.

See my previous posting.

> Well, at first, you cut away three quarters of my last post. Second, you told me in one 
> of your answers, that the compiler knows no differences between these initializations 

Yes, I was wrong there. I stand corrected.

> I'm afraid, I currently don't have the knowledge, nor the time (at least not at work) 
> to do it in a better way. But I thought, perhaps you would like to at least discuss the 
> way it's done now and perhaps, combined with your knowledge of how the things are 
> running today, come to see a new/better/more generic way of doing it. But please don't 
> get me wrong again, I certainly don't want to sound like I'm requesting a change in U-
> Boot or something alike.

I'm not that intimate with the linker or the changes  they  implement
to  it  -  which  seem to break existing and seemingly perfectly good
code that used to work for a long time. I'm afraid  there  is  little
help  available  - if there was a linker expert here on the list with
some clever ideas he would have probably spoken up by now.

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
A modem is a baudy house.

OT: Sam Beckett (Was: Re: [U-Boot-Users] Relocation of symbols?)

[Marius Groeger]

On Tue, 28 Jun 2005, Wolfgang Denk wrote:

> Ever try. Ever fail. No matter. Try again. Fail again.  Fail  better.
>                                                        -- S. Beckett

I think that quote should be:

   "Ever tried. Ever failed. No matter.
    Try again. Fail again. Fail better."

I also found this version, which makes even more sense:

   "Ever tried? Ever failed? No matter.
    Try Again. Fail again. Fail better."

Regards,
Marius

-- 
Marius Groeger <mgroeger@sysgo.com>
SYSGO AG                      Embedded and Real-Time Software
Voice: +49 6136 9948 0                  FAX: +49 6136 9948 10
www.sysgo.com | www.elinos.com | www.osek.de | www.pikeos.com

Meet us:  Embedded Systems Expo & Conference, Tokyo Big Sight
           2005-JUN-29 - 2005-JUL-01    http://www.esec.jp/en/