[U-Boot-Users] Re: compile u-boot with recent toolchain : symbols problem

[Cedric VINCENT <cedric.vincent@gmail.com>]

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