From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cedric VINCENT Date: Thu, 23 Jun 2005 20:47:11 +0200 Subject: [U-Boot-Users] Re: compile u-boot with recent toolchain : symbols problem In-Reply-To: <20050623093728.BE112C1510@atlas.denx.de> References: <20050623093728.BE112C1510@atlas.denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 wrote: > In message 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 wrote: > In message 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 at 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 at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users >