All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cedric VINCENT <cedric.vincent@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] compile u-boot with recent toolchain : symbols problem
Date: Wed, 1 Jun 2005 08:58:22 +0200	[thread overview]
Message-ID: <c8f100505312358391fcd78@mail.gmail.com> (raw)
In-Reply-To: <c8f10050531022046f3d639@mail.gmail.com>

---------- Forwarded message (without attachement) ----------

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

Thanks.

Best regards, Cedric VINCENT.

> >
> > I don't know what these (new) sections are, but the problem can be
> > solved in "u-boot.lds" :
> > -   __u_boot_cmd_start = .;
> >     .u_boot_cmd : { *(.u_boot_cmd) }
> >     __u_boot_cmd_end = .;
> > +  __u_boot_cmd_start = ADDR(.u_boot_cmd);
>
> I would like to understand this problem first before  deciding  about
> any fixes or patches.
>
> Thanks.
>
> 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
> "The computer programmer is a creator of universes for which he alone
> is responsible. Universes of virtually unlimited  complexity  can  be
> created  in  the  form  of  computer  programs." - Joseph Weizenbaum,
> _Computer Power and Human Reason_
>

      parent reply	other threads:[~2005-06-01  6:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-26 13:23 [U-Boot-Users] compile u-boot with recent toolchain : symbols problem Cedric VINCENT
2005-05-30  8:08 ` Wolfgang Denk
     [not found]   ` <c8f10050531022046f3d639@mail.gmail.com>
2005-06-01  6:58     ` Cedric VINCENT [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c8f100505312358391fcd78@mail.gmail.com \
    --to=cedric.vincent@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.