Anton Wöllert :

Thanks to Vincent for recovering that, that saved me a lot of time...

I'm glad to help you :)

Wolfgang Denk :

...

...

And which exact board are we talking about?

I repeat this question.

...

...

Can you please show exactly what happens?

I repeat this question, too.

Can you show the difference between the linker maps using the original and the patched versions? What exactly is changing?

It seems that my mail was lost... Here comes my reply:

On 5/30/05, Wolfgang Denk wd@denx.de wrote:

In message c8f10050526062372e8a833@mail.gmail.com you wrote:

...

I used to compile U-Boot with ELDK, but I currently need to work with newer toolchain :

• binutils-2.16
• gcc-3.4.3

This looks line a binutils problem, then. May I ask why you have to use binutils-2.16 ?

We want to test recent toolchain, to see if we should migrate or not (our policy is to keep tools up-to-date, assuming fixes and new features are more important than new bugs).

And which exact board are we talking about?

We're talking about "ADS Virtex-II Pro Development board", I use ML300 port (and some parts of ML2 and MicroBlaze ports).

...

The "__u_boot_cmd_start" symbol value, generated with this new toolchain, is wrong (U-Boot crashes when relocating the command table).

Can you please provide exact data, like the differences between the System.map and the u-boot.map files when using binutils-2.16 and another, working version of binutils? [Please use the _same_ version of GCC for this comparison.]

The problem doesn't appear using binutils-2.16 with GCC provided by ELDK... So it seems to be a GCC problem.

...

There are two new sections between "__u_boot_cmd_start" and ".u_boot_cmd" address :

• .data.rel.local
• .data.rel

Can you please show exactly what happens?

I attached 3 binaries : - u-boot_ELDK, which is compiled with binutils-2.11.93.0.2 (20020207) and gcc-2.95.4 - u-boot_binutils-2.16, which is compiled with binutils-2.16 and gcc-2.95.4 - u-boot_new_toolchain, which is compiled with binutils-2.16 and gcc-3.4.3

As you can see with this command, "__u_boot_cmd_start" is not at the right place : bash# powerpc-405-linux-gnu-nm u-boot_new_toolchain | sort [...] 0002ab8c A __u_boot_cmd_start 0002ab8c D init_sequence 0002abb8 d failed 0002abbc D op_table 0002ac24 D stdio_names 0002ac30 d av_ 0002b038 D z_errmsg 0002b058 D __u_boot_cmd_autoscr 0002b070 D __u_boot_cmd_bdinfo 0002b088 D __u_boot_cmd_reset 0002b0a0 D __u_boot_cmd_go [...]

Since U-Boot uses the address of "__u_boot_cmd_start" to point to the first entry of the command table, U-Boot crashes when relocating this table. Here, the address of "__u_boot_cmd_start" should be 0x0002b058.

I noticed that symbol "init_sequence" belongs to section ".data.rel" and symbols "failed", "op_table", "stdio_names", "av_" and "z_errmsg" belong to section ".data.rel.local".

As you can see with this command, these new sections are above the ".u_boot_cmd" section : bash# powerpc-405-linux-gnu-readelf -S u-boot_new_toolchain [...] [ 1] .text PROGBITS 00010000 000094 016684 00 AX 0 0 4 [ 2] .resetvec PROGBITS 00026684 016718 000004 00 AX 0 0 1 [ 3] .rodata PROGBITS 00026688 01671c 003500 00 A 0 0 4 [ 4] .reloc PROGBITS 00029c00 019c94 000ab8 00 WA 0 0 1 [ 5] .data PROGBITS 0002a6b8 01a74c 0004d4 00 WA 0 0 4 [ 6] .data.rel PROGBITS 0002ab8c 01ac20 00002c 00 WA 0 0 4 [ 7] .data.rel.local PROGBITS 0002abb8 01ac4c 0004a0 00 WA 0 0 4 [ 8] .u_boot_cmd PROGBITS 0002b058 01b0ec 000348 00 WA 0 0 4 [...]

So "__u_boot_cmd_start" points to the start of the ".data.rel" section instead of the start of ".u_boot_cmd" section.

These new sections are disassembled in attached files "section_.data.rel.local_dump" and "section_.data.rel_dump".

Best regards, Cedric VINCENT.

PS: attachements are here : http://cedric.vincent.perso.free.fr/Stages/SMP-France/

On 6/23/05, Wolfgang Denk wd@denx.de wrote:

In message E1DlMsF-0005rm-RG@mailer.emlix.com you wrote:

...

I've got the same problem with binutils 2.16 and gcc 3.4.4. also binutils 2.16.91.0.1 doesn't work right.

Maybe you should discuss this then on a binutils related list?

...

...

This looks line a binutils problem, then. May I ask why you have to use binutils-2.16 ?

May I ask you why it should not be used? How to recover bugs, if people just use older software?

Bleading edge tools may have bugs, and incompatibilities. Suchthings should be discussed on the respective tools related lists first. I see no obvious bugs in the linker script, and it used to work fine so far. I think it makes sense to check if the behaviour of the new tools is correct before "fixing" the problem on the application side.

...

...

And which exact board are we talking about?

I repeat this question.

...

...

...

The "__u_boot_cmd_start" symbol value, generated with this new toolchain, is wrong (U-Boot crashes when relocating the command table).

Can you please provide exact data, like the differences between the System.map and the u-boot.map files when using binutils-2.16 and another, working version of binutils? [Please use the _same_ version of GCC for this comparison.]

...

There are two new sections between "__u_boot_cmd_start" and ".u_boot_cmd" address :

• .data.rel.local
• .data.rel

Can you please show exactly what happens?

I repeat this question, too.

Can you show the difference between the linker maps using the original and the patched versions? What exactly is changing?

...

Obviously

  __u_boot_cmd_start = .;
  .u_boot_cmd : { *(.u_boot_cmd) }
  __u_boot_cmd_end = .;

and

  __u_boot_cmd_start = ADDR(.u_boot_cmd);
  .u_boot_cmd : { *(.u_boot_cmd) }
  __u_boot_cmd_end = .;

should be the same. However, this should be a binutils bug or the linker script voodoo that is done with the first script above isn't really valid.

I tend to think that it is a linker bug, and ask to take this discussion to the binutils people first.

...

Maybe .u_boot_cmd gets misalligned. Maybe i should try to DEBUG(& __u_boot_cmd_start) in both (the patched and unpatched) versions to see,

A lot of maybes here. I would like to see facts first. FOr example, the diff between the linke r maps and/or the binaries.

Best regards,

Wolfgang Denk

-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Anyone can count the seeds in an apple. No one can count the apples in a seed.

---

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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users

On 6/24/05, Wolfgang Denk wd@denx.de wrote:

Grrrrghhhh...

I really don't understand what's going on. Is my English so poor? Am I completely unable to express myself clearly enough?

I apologize...

This is the third time I repeat the same request, and two different people continue to either misunderstand or ignore me.

Did I ignore you ?! Are you talking about my "lost mail", sent to this mailing list the first of June (take a look at gmane archive) ?

I do not want to see any binary images. I want to compare the System.map and the u-boot.map files between the working and the non working versions.

What is so difficult about that?

I believed system.map and the u-boot.map contain only the symbol table, so I thought binaries contain more helpful data (since the symbol table can be read from these, with readelf or nm).

I will send you these 'map' files next week.

...

A lot of maybes here. I would like to see facts first. FOr example, the diff between the linke r maps and/or the binaries.

Facts are in the provided binairies, so what's the problem ?

And please don't top-post / full-quote.

OK.

I think I give up on this. If you cannot provide the information I need I cannot help you.

My first mail was not a "help request" nor a "bug report" since I don't know where the bug comes from (GCC ?, LD ?, U-Boot ?). I sent this first mail to help U-Boot users who have the same problem, it was the only purpose. So, please, stop to blame me !

I would like to thank you for your awesome work, and I know you are very busy. So you can give up on this (tell me if so, please), there is no problem.

Best regards, Cedric VINCENT.

Dear Cedric,

in message c8f10050701092868743bb3@mail.gmail.com you wrote:

...

I want to compare the System.map and the u-boot.map files between the working and the non working versions.

http://cedric.vincent.perso.free.fr/Stages/SMP-France/u-boot_map.tar.bz2

I'm sorry this took so long, but now I get:

The requested URL /Stages/SMP-France/u-boot_map.tar.bz2 was not found on this server.

Is this problem still relevant for you?

Best regards,

Wolfgang Denk