This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Linker problem...


Hi Nick,

On Tuesday 30 August 2005 18:10, Nick Clifton wrote:
> Hi Gerhard,
> 
> >   _edata  =  .;
> >   PROVIDE (edata = .);
> > 
> >   __u_boot_cmd_start = .;
> >   .u_boot_cmd : { *(.u_boot_cmd) }
> 
> > 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
> > [...]
> > fffe8384 D desc_and_len_tbl
> > fffe83b4 D __u_boot_cmd_autoscr
> 
> > __u_boot_cmd_start is placed wrong here, and the resulting bootloader does not
> > work correctly.
> 
> It looks like you need to fix up the linker script.  From ld.texinfo:
> 
>    dot outside sections
> 
>    Setting symbols to the value of the location counter outside
>    of an output section statement can result in unexpected values
>    if the linker needs to place orphan sections.  For example,
>    given the following:
> 
>    SECTIONS
>    {
>      start_of_text = . ;
>      .text: { *(.text) }
>      end_of_text = . ;
> 
>      start_of_data = . ;
>      .data: { *(.data) }
>      end_of_data = . ;
>    }
> 
>    [...] As well, the linker doesn't associate the above
>    symbol names with their sections.  Instead, it assumes
>    that all assignments or other statements belong to the
>    previous output section, except for the special case of
>    an assignment to .  [...] So you could write:
> 
>    SECTIONS
>    {
>      start_of_text = . ;
>      .text: { *(.text) }
>      end_of_text = . ;
> 
>      . = . ;
>      start_of_data = . ;
>      .data: { *(.data) }
>      end_of_data = . ;
>    }
> 
> Cheers
>    Nick
 
indeed that did the trick and thanks for the explanation. 
One thing that has been mentioned on the u-boot lists while discussing the
"broken linker" issue was to use the following:

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

This one seems to fix the issue also...

Hmmm, I get the impression, that I need to re-read the docs more carefully...
Thanks
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 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]