Linker problem...

[Gerhard Jaeger <g dot jaeger at sysgo dot com>]

Hi list,

while creating a recent crosstool chain using binutils-2.16.1, I encountered
the problem, that compiling and linking the u-boot bootloader (for a PPC440 target)
seems to went fine, but the resulting bootloader is crap.

Why? Well the u-boot linker script looks at the problematic part like:

.data    :
  {
    *(.data)
    *(.data1)
    *(.sdata)
    *(.sdata2)
    *(.dynamic)
    CONSTRUCTORS
  }

  _edata  =  .;
  PROVIDE (edata = .);

  __u_boot_cmd_start = .;
  .u_boot_cmd : { *(.u_boot_cmd) }
  __u_boot_cmd_end = .;


and the result in the map file used to look like (in the end that's what we expect):

fffe8644 D env_name_spec
fffe8648 d av_
fffe8a50 D z_errmsg
fffe8a70 d failed
fffe8a74 D weekdays
fffe8a90 D op_table
fffe8af8 D reg_5_desc_tbl
fffe8b88 D reg_4_desc_tbl
fffe8c18 D reg_3_desc_tbl
fffe8c3c D reg_2_desc_tbl
fffe8c48 D reg_1_desc_tbl
fffe8d08 D reg_0_desc_tbl
fffe8d80 D reg_0_5_desc_tbl
fffe8db0 D stdio_names
fffe8dbc D init_sequence
fffe8df0 D desc_and_len_tbl
fffe8e20 A __u_boot_cmd_start
fffe8e20 A _edata
fffe8e20 D __u_boot_cmd_autoscr
fffe8e3c D __u_boot_cmd_bdinfo
fffe8e58 D __u_boot_cmd_reset
 .
 .
 .


You see, __u_boot_cmd_start is located at the same address as the first "real" command
__u_boot_cmd_autoscr and could also be used in code i.e.:

for (cmdtp = &__u_boot_cmd_start; cmdtp != &__u_boot_cmd_end; cmdtp++) {
 .
 .
 .


The binutils-2.16.1 (and also the latests snapshots) create the following map output:

fffe7bd8 D env_name_spec
fffe7bdc A __u_boot_cmd_start
fffe7bdc A _edata
fffe7bdc d av_
fffe7fe4 D z_errmsg
fffe8004 d failed
fffe8008 D weekdays
fffe8024 D op_table
fffe808c D reg_5_desc_tbl
fffe811c D reg_4_desc_tbl
fffe81ac D reg_3_desc_tbl
fffe81d0 D reg_2_desc_tbl
fffe81dc D reg_1_desc_tbl
fffe829c D reg_0_desc_tbl
fffe8314 D reg_0_5_desc_tbl
fffe8344 D stdio_names
fffe8350 D init_sequence
fffe8384 D desc_and_len_tbl
fffe83b4 D __u_boot_cmd_autoscr
fffe83d0 D __u_boot_cmd_bdinfo
fffe83ec D __u_boot_cmd_reset

__u_boot_cmd_start is placed wrong here, and the resulting bootloader does not
work correctly.

I tried to find out, when this "behaviour" has been introduced and tracked it down until
the changes from 2004-10-14 (Alan Modra and H.J. Lu), checking out the version before
(cvs update -D 2004-10-14: ld-2.15.93 20041013) works as expected, and the following one 
(cvs update -D 2004-10-15: ld-2.15.93 20041014) fails...

As the change is quite large and I'm not familiar with the code , I stopped here digging 
deeper and wanted to ask you for help here as IMHO one of these changes breaks the linker. 

TIA
Gerhard


-- 
Gerhard Jaeger <gjaeger@sysgo.com>            
SYSGO AG                      Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.pikeos.com | www.osek.de