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

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

[Anton Wöllert]

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.

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

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

>  
>  And which exact board are we talking about?
>  
>  > 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?

The above, i couldn't acknowledge, but u-boot definitly hangs _after_ 
relocating to memory. it will dump 'Now running in RAM at .....'. But then it 
hangs. After relocating, it tries to manually relocate the command table. But 
that doesn't work. Don't know why, but with the patch it works.
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. 
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, 
where it points, or maybe objdump show more. Btw. this happens on the tqm8xx 
board. Thanks to Vincent for recovering that, that saved me a lot of time...

kind regards

Anton W?llert

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

[Wolfgang Denk]

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.

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

[Anton Wöllert]

Hello,

i recovered, that there are two sections (like Vincent sad) called .data.rel 
and .data.rel.local. Strange, because they can be easily confused 
with .rel.data etc. but well, i've read something on google, that they are 
new to gcc 3.3* or so. it also seems, that these sections are needed trough 
references, but not covered by the link script and so they are pushed 
somewhere in the output (elf-file). my reason for handling this would be 
inserting an *(.data.*) into the data section from the link script 
u-boot.lds.

if anyone knows, for what these sections are, please mail me

thanks

anton w?llert

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

[Wolfgang Denk]

In message <E1DlOVc-0000JB-IN@mailer.emlix.com> you wrote:
> 
> i recovered, that there are two sections (like Vincent sad) called .data.rel 
> and .data.rel.local. Strange, because they can be easily confused 
> with .rel.data etc. but well, i've read something on google, that they are
> new to gcc 3.3* or so. it also seems, that these sections are needed trough

We're using gcc version 3.3.3, and don;t see such problems.

> references, but not covered by the link script and so they are pushed 
> somewhere in the output (elf-file). my reason for handling this would be 

It would be really helpful if you could just once  actually  read  my
replies  and  answer  my  questions,  like  the  request  to  see the
difference between the linker map files. This is the third time now I
have to repeat this.

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
Death, when unnecessary, is a tragic thing.
	-- Flint, "Requiem for Methuselah", stardate 5843.7

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

[Cedric VINCENT]

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
>

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

[Wolfgang Denk]

Dear Cedric,

in message <c8f10050623114735e08f64@mail.gmail.com> you wrote:
>
> > Can you show  the  difference  between  the  linker  maps  using  the
> > original and the patched versions? What exactly is changing?
...
> > 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.]
...
> 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

Grrrrghhhh...


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

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

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?


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

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


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


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
"To IBM, 'open' means there is a modicum  of  interoperability  among
some of their equipment."                            - Harv Masterson

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

[Cedric VINCENT]

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.

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

[Cedric VINCENT]

> 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

Best regards, Cedric VINCENT.

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

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A metaphor is like a simile.

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

[Cedric VINCENT]

Dear Wolfgang,

> Is this problem still relevant for you?

No, this problem was fixed here :
http://sourceware.org/ml/binutils/2005-08/msg00412.html

Best regards,
Cedric VINCENT.

On 3/12/06, Wolfgang Denk <wd@denx.de> wrote:
> 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
>
> --
> Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> A metaphor is like a simile.
>


--
-------------------------------------------
http://cedric.vincent.perso.free.fr/
-------------------------------------------

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

[David Ho]

Hi Anton,

I can confirm the same behaviour with

gcc-4.0.2 glibc-2.3.3 binutils 2.16
gcc-4.1.0 glibc-2.3.6 binutils 2.16.1

The yosemite config builds correctly however.

But my MPC852T based config builds with the same problem you saw.

u-boot-1.1.4

David


On 6/23/05, Anton W?llert <aw@emlix.com> 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.
>
> >  >
> >  > 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 ?
>
> May I ask you why it should not be used? How to recover bugs, if people just
> use older software?
>
> >
> >  And which exact board are we talking about?
> >
> >  > 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?
>
> The above, i couldn't acknowledge, but u-boot definitly hangs _after_
> relocating to memory. it will dump 'Now running in RAM at .....'. But then it
> hangs. After relocating, it tries to manually relocate the command table. But
> that doesn't work. Don't know why, but with the patch it works.
> 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.
> 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,
> where it points, or maybe objdump show more. Btw. this happens on the tqm8xx
> board. Thanks to Vincent for recovering that, that saved me a lot of time...
>
> kind regards
>
> Anton W?llert
>
>
>
> -------------------------------------------------------
> 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_idt77&alloc_id\x16492&opclick
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>