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