Subject: Re: kern/21844: netwinder kernal cannot be linked because link_set_* sections overlap with .data
To: Ian Lance Taylor <ian@airs.com>
From: Valeriy E. Ushakov <uwe@ptc.spbu.ru>
List: tech-toolchain
Date: 06/12/2003 15:08:36
On Wed, Jun 11, 2003 at 21:23:33 -0700, Ian Lance Taylor wrote:

> > > > The problem is that the kernel ld script for netwinder does not list 
> > > > link_set_* sections, so they are transfered to the ld output as-is 
> > > > after the .text section, however the kernel ld script explicitely 
> > > > places .data section after the .text section with:
> > > 
> > > The linker should actually be sorting
> > > the link_set_ sections along with the .rodata section.
> > 
> > Should it?  My readind of ld(1) docs is that the "orphaned" sections
> > are transferred from input to output as-is.
> 
> I don't know what ``as-is'' would mean in this case.  Anyhow, if the
> GNU linker docs imply that, they are wrong.  The GNU linker for ELF
> sorts orphaned sections by guessing where it thinks they should go
> based on their characteristics.

The paragraph I've been referring to is from the Node: SECTIONS

|    If you do not use a `SECTIONS' command in your linker script, the
| linker will place each input section into an identically named output
| section in the order that the sections are first encountered in the
| input files.  If all input sections are present in the first file, for
| example, the order of sections in the output file will match the order
| in the first input file.  The first section will be at address zero.


Well, that text above provides a less generic statement (no SECTIONS
command) compared to the following xref to it in the Node: MEMORY

| As described in *Note SECTIONS::, if you do not specify an output
| section for some input section, the linker will create an output
| section with the same name as the input section.


I loosely used "as-is" to mean "with the same name, in the same
order", i.e. after .text, but before .data, which is what's relevant
in this case.


PS: I'm Cc'ing to tech-toolchain@ because it's not the first time I
have issues that orphaned link_set_* sections expose in careless
kernel ld scripts, so we'd better have a paper trail that can be used
for reference later on.

SY, Uwe
-- 
uwe@ptc.spbu.ru                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen