binutils 2.19 issue with kernel link

binutils 2.19 issue with kernel link

[Kumar Gala]

Alan,

We are seeing an issue w/ld and kernel linking of 32-bit kernels.

The ld from fedora 11 (2.19.51.0.2-17.fc11 20090204) ends not  
providing the proper address for _end.

Building stock v2.6.30 w/the mpc85xx_defconfig we get:

00001000 A _end

Using 2.18.50.20080215 we get:

c0680000 A _end

If we modify the linker script:

       _end2 = .;
       _end3 = ALIGN(4096);
       _end4 = ALIGN(PAGE_SIZE);
       . = ALIGN(PAGE_SIZE);
       _end = . ;
       PROVIDE32 (end = .);

and the result is:

00001000 A _end
c067f678 A _end2
c0680000 A _end3
c0680000 A _end4

I used an old version of linker (2.18.50.20080215) and re-linked:

c067f678 A _end2
c0680000 A _end
c0680000 A _end3
c0680000 A _end4

Any ideas?

- k

Re: binutils 2.19 issue with kernel link

[Alan Modra]

On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
> If we modify the linker script:
>
>       _end2 = .;
>       _end3 = ALIGN(4096);
>       _end4 = ALIGN(PAGE_SIZE);
>       . = ALIGN(PAGE_SIZE);
>       _end = . ;
>       PROVIDE32 (end = .);
>
> and the result is:
>
> 00001000 A _end
> c067f678 A _end2
> c0680000 A _end3
> c0680000 A _end4

Possibly some section with a zero vma is being placed before _end.
Generate a link map to see if this is so.

-- 
Alan Modra
Australia Development Lab, IBM

Re: binutils 2.19 issue with kernel link

[Kumar Gala]

On Jul 8, 2009, at 6:39 PM, Alan Modra wrote:

> On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
>> If we modify the linker script:
>>
>>      _end2 = .;
>>      _end3 = ALIGN(4096);
>>      _end4 = ALIGN(PAGE_SIZE);
>>      . = ALIGN(PAGE_SIZE);
>>      _end = . ;
>>      PROVIDE32 (end = .);
>>
>> and the result is:
>>
>> 00001000 A _end
>> c067f678 A _end2
>> c0680000 A _end3
>> c0680000 A _end4
>
> Possibly some section with a zero vma is being placed before _end.
> Generate a link map to see if this is so.

In the broken (ALIGN) case we have:

  .bss           0x00000000c05d3018        0x0 lib/lib.a(klist.o)
  .bss           0x00000000c05d3018        0x0 lib/lib.a(sha1.o)
  .bss           0x00000000c05d3018        0x0 .tmp_kallsyms3.o
  *(COMMON)
                 0x00000000c05d3018                __bss_stop = .

.PPC.EMB.apuinfo
                 0x0000000000000000       0x24
  .PPC.EMB.apuinfo
                 0x0000000000000000       0x1c arch/powerpc/kernel/ 
head_fsl_booke.o
  .PPC.EMB.apuinfo

In the non-ALIGN case we have:

                 0x00000000c05d3018                _end = .
                 0x00000000c05d3018                PROVIDE (end, .)
LOAD arch/powerpc/kernel/head_fsl_booke.o
LOAD init/built-in.o
START GROUP
LOAD usr/built-in.o
LOAD arch/powerpc/kernel/built-in.o
LOAD arch/powerpc/mm/built-in.o
LOAD arch/powerpc/lib/built-in.o
LOAD arch/powerpc/sysdev/built-in.o
LOAD arch/powerpc/platforms/built-in.o
LOAD arch/powerpc/math-emu/built-in.o
LOAD kernel/built-in.o
LOAD mm/built-in.o
LOAD fs/built-in.o
LOAD ipc/built-in.o
LOAD security/built-in.o
LOAD crypto/built-in.o
LOAD block/built-in.o
LOAD lib/lib.a
LOAD lib/built-in.o
LOAD drivers/built-in.o
LOAD sound/built-in.o
LOAD firmware/built-in.o
LOAD net/built-in.o
END GROUP
LOAD .tmp_kallsyms3.o
OUTPUT(vmlinux elf32-powerpc)

.PPC.EMB.apuinfo
                 0x0000000000000000       0x24
  .PPC.EMB.apuinfo
                 0x0000000000000000       0x1c arch/powerpc/kernel/ 
head_fsl_booke.o

Re: binutils 2.19 issue with kernel link

[Kumar Gala]

On Jul 8, 2009, at 6:39 PM, Alan Modra wrote:

> On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
>> If we modify the linker script:
>>
>>      _end2 = .;
>>      _end3 = ALIGN(4096);
>>      _end4 = ALIGN(PAGE_SIZE);
>>      . = ALIGN(PAGE_SIZE);
>>      _end = . ;
>>      PROVIDE32 (end = .);
>>
>> and the result is:
>>
>> 00001000 A _end
>> c067f678 A _end2
>> c0680000 A _end3
>> c0680000 A _end4
>
> Possibly some section with a zero vma is being placed before _end.
> Generate a link map to see if this is so.

Playing with this further I think its related to the -me500 option we  
pass and thus wondering if its something with the APU section  
handling.  If I hack the kernel up a little and pass -m440 instead  
things seem to be ok.

- k

Re: binutils 2.19 issue with kernel link

[Kumar Gala]

On Jul 8, 2009, at 10:39 PM, Kumar Gala wrote:

>
> On Jul 8, 2009, at 6:39 PM, Alan Modra wrote:
>
>> On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
>>> If we modify the linker script:
>>>
>>>     _end2 = .;
>>>     _end3 = ALIGN(4096);
>>>     _end4 = ALIGN(PAGE_SIZE);
>>>     . = ALIGN(PAGE_SIZE);
>>>     _end = . ;
>>>     PROVIDE32 (end = .);
>>>
>>> and the result is:
>>>
>>> 00001000 A _end
>>> c067f678 A _end2
>>> c0680000 A _end3
>>> c0680000 A _end4
>>
>> Possibly some section with a zero vma is being placed before _end.
>> Generate a link map to see if this is so.
>
> Playing with this further I think its related to the -me500 option  
> we pass and thus wondering if its something with the APU section  
> handling.  If I hack the kernel up a little and pass -m440 instead  
> things seem to be ok.

To further verify this if I switch the -me500 to -mspe and build  
things seem to be ok.  This further points at some APU section related  
bug.

- k

Re: binutils 2.19 issue with kernel link

[Alan Modra]

On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
> To further verify this if I switch the -me500 to -mspe and build things 
> seem to be ok.  This further points at some APU section related bug.

Like omitting .PPC.EMB.apuinfo from your kernel link script?  See the
ld info doc on orphan sections.

-- 
Alan Modra
Australia Development Lab, IBM

Re: binutils 2.19 issue with kernel link

[Kumar Gala]

On Jul 8, 2009, at 11:40 PM, Alan Modra wrote:

> On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
>> To further verify this if I switch the -me500 to -mspe and build  
>> things
>> seem to be ok.  This further points at some APU section related bug.
>
> Like omitting .PPC.EMB.apuinfo from your kernel link script?  See the
> ld info doc on orphan sections.

Ok, not terribly enlightening, but why would .PPC.EMB.apuinfo sections  
be different than something like .debug sections which we also dont  
list in the linker script.

- k

Re: binutils 2.19 issue with kernel link

[Dale Farnsworth]

On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
> We are seeing an issue w/ld and kernel linking of 32-bit kernels.
>
> The ld from fedora 11 (2.19.51.0.2-17.fc11 20090204) ends not providing 
> the proper address for _end.
>
> Building stock v2.6.30 w/the mpc85xx_defconfig we get:
>
> 00001000 A _end
>
> Using 2.18.50.20080215 we get:
>
> c0680000 A _end
>
> If we modify the linker script:
>
>       _end2 = .;
>       _end3 = ALIGN(4096);
>       _end4 = ALIGN(PAGE_SIZE);
>       . = ALIGN(PAGE_SIZE);
>       _end = . ;
>       PROVIDE32 (end = .);
>
> and the result is:
>
> 00001000 A _end
> c067f678 A _end2
> c0680000 A _end3
> c0680000 A _end4
>
> I used an old version of linker (2.18.50.20080215) and re-linked:
>
> c067f678 A _end2
> c0680000 A _end
> c0680000 A _end3
> c0680000 A _end4
>
> Any ideas?

We have found the following workaround to be useful.
Thanks to Andrew Jenner at Code Sourcery.

-Dale

Dale Farnsworth
MontaVista Software

diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index acf237f..34b0181 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -282,4 +282,7 @@ SECTIONS
 	. = ALIGN(PAGE_SIZE);
 	_end = . ;
 	PROVIDE32 (end = .);
+
+#undef PPC
+	.PPC.EMB.apuinfo 0 : { *(.PPC.EMB.apuinfo) }
 }

Re: binutils 2.19 issue with kernel link

[Kumar Gala]

On Jul 9, 2009, at 11:39 AM, Dale Farnsworth wrote:

> On Wed, Jul 08, 2009 at 05:41:39PM -0500, Kumar Gala wrote:
>> We are seeing an issue w/ld and kernel linking of 32-bit kernels.
>>
>> The ld from fedora 11 (2.19.51.0.2-17.fc11 20090204) ends not  
>> providing
>> the proper address for _end.
>>
>> Building stock v2.6.30 w/the mpc85xx_defconfig we get:
>>
>> 00001000 A _end
>>
>> Using 2.18.50.20080215 we get:
>>
>> c0680000 A _end
>>
>> If we modify the linker script:
>>
>>      _end2 = .;
>>      _end3 = ALIGN(4096);
>>      _end4 = ALIGN(PAGE_SIZE);
>>      . = ALIGN(PAGE_SIZE);
>>      _end = . ;
>>      PROVIDE32 (end = .);
>>
>> and the result is:
>>
>> 00001000 A _end
>> c067f678 A _end2
>> c0680000 A _end3
>> c0680000 A _end4
>>
>> I used an old version of linker (2.18.50.20080215) and re-linked:
>>
>> c067f678 A _end2
>> c0680000 A _end
>> c0680000 A _end3
>> c0680000 A _end4
>>
>> Any ideas?
>
> We have found the following workaround to be useful.
> Thanks to Andrew Jenner at Code Sourcery.
>
> -Dale
>
> Dale Farnsworth
> MontaVista Software
>
> diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/ 
> vmlinux.lds.S
> index acf237f..34b0181 100644
> --- a/arch/powerpc/kernel/vmlinux.lds.S
> +++ b/arch/powerpc/kernel/vmlinux.lds.S
> @@ -282,4 +282,7 @@ SECTIONS
> 	. = ALIGN(PAGE_SIZE);
> 	_end = . ;
> 	PROVIDE32 (end = .);
> +
> +#undef PPC
> +	.PPC.EMB.apuinfo 0 : { *(.PPC.EMB.apuinfo) }
> }

Is there any plans to fix binutils or is this viewed as not a binutils  
regression?

- k

Re: binutils 2.19 issue with kernel link

[Dale Farnsworth]

On Thu, Jul 09, 2009 at 01:14:28PM -0500, Kumar Gala wrote:
> On Jul 9, 2009, at 11:39 AM, Dale Farnsworth wrote:
>> We have found the following workaround to be useful.
>> Thanks to Andrew Jenner at Code Sourcery.
>>
>> -Dale
>>
>> Dale Farnsworth
>> MontaVista Software
>>
>> diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/ 
>> vmlinux.lds.S
>> index acf237f..34b0181 100644
>> --- a/arch/powerpc/kernel/vmlinux.lds.S
>> +++ b/arch/powerpc/kernel/vmlinux.lds.S
>> @@ -282,4 +282,7 @@ SECTIONS
>> 	. = ALIGN(PAGE_SIZE);
>> 	_end = . ;
>> 	PROVIDE32 (end = .);
>> +
>> +#undef PPC
>> +	.PPC.EMB.apuinfo 0 : { *(.PPC.EMB.apuinfo) }
>> }
>
> Is there any plans to fix binutils or is this viewed as not a binutils  
> regression?

It sure looks like a regression to me, but I don't have details on
a potential fix.

-Dale

Re: binutils 2.19 issue with kernel link

[Edmar Wienskoski-RA8797]

Kumar Gala wrote:
>
> On Jul 8, 2009, at 11:40 PM, Alan Modra wrote:
>
>> On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
>>> To further verify this if I switch the -me500 to -mspe and build things
>>> seem to be ok.  This further points at some APU section related bug.
>>
>> Like omitting .PPC.EMB.apuinfo from your kernel link script?  See the
>> ld info doc on orphan sections.
>
> Ok, not terribly enlightening, but why would .PPC.EMB.apuinfo sections 
> be different than something like .debug sections which we also dont 
> list in the linker script.
>
> - k
>
Alan,

I understand your arguments, but there is something inconsistent about this.
If I change the script to be:
        _end3 = . ;
        . = _end3;
        . = ALIGN(PAGE_SIZE);
        _end = . ;
        PROVIDE32 (end = .);
}
The result is corrected:
c067f678 A _end3
c0680000 A _end

Why the apuinfo section with zero VMA sometimes interfere with "." and 
sometimes not ?

Edmar

Re: binutils 2.19 issue with kernel link

[Alan Modra]

On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797 wrote:
> Kumar Gala wrote:
>>
>> On Jul 8, 2009, at 11:40 PM, Alan Modra wrote:
>>
>>> On Wed, Jul 08, 2009 at 10:52:59PM -0500, Kumar Gala wrote:
>>>> To further verify this if I switch the -me500 to -mspe and build things
>>>> seem to be ok.  This further points at some APU section related bug.
>>>
>>> Like omitting .PPC.EMB.apuinfo from your kernel link script?  See the
>>> ld info doc on orphan sections.
>>
>> Ok, not terribly enlightening, but why would .PPC.EMB.apuinfo sections  
>> be different than something like .debug sections which we also dont  
>> list in the linker script.

Because .PPC.EMB.apuinfo is a note section rather than a debugging
section.  Orphan non-alloc note sections will be placed before
.comment or debug sections while orphan debug sections go right to the
end.  Now, I'll bet you don't have .comment in your script so it too
is an orphan.

> I understand your arguments, but there is something inconsistent about this.
> If I change the script to be:
>        _end3 = . ;
>        . = _end3;
>        . = ALIGN(PAGE_SIZE);
>        _end = . ;
>        PROVIDE32 (end = .);
> }
> The result is corrected:
> c067f678 A _end3
> c0680000 A _end
>
> Why the apuinfo section with zero VMA sometimes interfere with "." and  
> sometimes not ?

That is weird.  You'll need to run ld under gdb to find out.  I'd
expect the orphan apuinfo section to be placed before the first
assignment to dot in both cases, or at the end of the script in both
cases, with placement depending on whether you hit an orphan .comment
or debug section before the orphan .PPC.EMB.apuinfo.


The underlying reason is that if you provide a link script that
doesn't mention a section, then ld is free to place that section
anywhere.  Quoting from the ld info doc:

"Orphan sections are sections present in the input files which are not
explicitly placed into the output file by the linker script.  The
linker will still copy these sections into the output file, but it has
to guess as to where they should be placed.  The linker uses a simple
heuristic to do this.  It attempts to place orphan sections after
non-orphan sections of the same attribute, such as code vs data,
loadable vs non-loadable, etc.  If there is not enough room to do this
then it places at the end of the file.

For ELF targets, the attribute of the section includes section type as
well as section flag."


That's all as expected, and in your case you don't have a section with
the same attribute as .PPC.EMB.apuinfo so it should go to the end.
However, you have multiple orphan sections being added.  After the
first of these is added, you have sections after your end symbol
assignments, and when there are assignments it gets tricky.  The
relevant part of the ld info doc says:


"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 = . ;
}

If the linker needs to place some input section, e.g. .rodata, not
mentioned in the script, it might choose to place that section between
.text and .data.  You might think the linker should place .rodata on
the blank line in the above script, but blank lines are of no
particular significance to the linker.  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 '.'.  I.e., the linker will place the orphan .rodata section as if
the script was written as follows:

SECTIONS
{
    start_of_text = . ;
    .text: { *(.text) }
    end_of_text = . ;

    start_of_data = . ;
    .rodata: { *(.rodata) }
    .data: { *(.data) }
    end_of_data = . ;
}

This may or may not be the script author's intention for the value of
start_of_data.  One way to influence the orphan section placement is
to assign the location counter to itself, as the linker assumes that
an assignment to '.' is setting the start address of a following
output section and thus should be grouped with that section.  So you
could write:

SECTIONS
{
    start_of_text = . ;
    .text: { *(.text) }
    end_of_text = . ;

    . = . ;
    start_of_data = . ;
    .data: { *(.data) }
    end_of_data = . ;
}

Now, the orphan .rodata section will be placed between end_of_text and
start_of_data."


Putting this all together:
a) ld places .comment or some debug section at end
b) ld places .PPC.EMB.apuinfo before the other orphan section, and
thinks your assignments to dot belong with the other orphan, so 
.PPC.EMB.apuinfo goes before them.

As no doubt you've already found, you can fix your link script by not
using ". = ALIGN(PAGE_SIZE)"; instead use "sym = ALIGN(PAGE_SIZE)".

Hmm, having said all that, the following linker patch seems reasonable
to me and probably won't break anything else (always some risk).
Please test it for me.

Index: ld/ldlang.c
===================================================================
RCS file: /cvs/src/src/ld/ldlang.c,v
retrieving revision 1.311
diff -u -p -r1.311 ldlang.c
--- ld/ldlang.c	25 Jun 2009 13:18:46 -0000	1.311
+++ ld/ldlang.c	10 Jul 2009 04:04:57 -0000
@@ -1615,10 +1615,12 @@ output_prev_sec_find (lang_output_sectio
    idea is to skip over anything that might be inside a SECTIONS {}
    statement in a script, before we find another output section
    statement.  Assignments to "dot" before an output section statement
-   are assumed to belong to it.  An exception to this rule is made for
-   the first assignment to dot, otherwise we might put an orphan
-   before . = . + SIZEOF_HEADERS or similar assignments that set the
-   initial address.  */
+   are assumed to belong to it, except in two cases;  The first
+   assignment to dot, and assignments before non-alloc sections.
+   Otherwise we might put an orphan before . = . + SIZEOF_HEADERS or
+   similar assignments that set the initial address, or we might
+   insert non-alloc note sections among assignments setting end of
+   image symbols.  */
 
 static lang_statement_union_type **
 insert_os_after (lang_output_section_statement_type *after)
@@ -1662,7 +1664,12 @@ insert_os_after (lang_output_section_sta
 	  continue;
 	case lang_output_section_statement_enum:
 	  if (assign != NULL)
-	    where = assign;
+	    {
+	      asection *s = (*where)->output_section_statement.bfd_section;
+
+	      if (s == NULL || (s->flags & SEC_ALLOC) != 0)
+		where = assign;
+	    }
 	  break;
 	case lang_input_statement_enum:
 	case lang_address_statement_enum:

-- 
Alan Modra
Australia Development Lab, IBM

Re: binutils 2.19 issue with kernel link

[Alan Modra]

On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797 wrote:
> I understand your arguments, but there is something inconsistent about this.
> If I change the script to be:
>        _end3 = . ;
>        . = _end3;
>        . = ALIGN(PAGE_SIZE);
>        _end = . ;
>        PROVIDE32 (end = .);
> }
> The result is corrected:
> c067f678 A _end3
> c0680000 A _end
>
> Why the apuinfo section with zero VMA sometimes interfere with "." and  
> sometimes not ?

I said it was weird in my last email.  Not so.  The orphan gets placed
between

       _end3 = . ;
       . = _end3;

So dot is restored after the orphan section sets it.

-- 
Alan Modra
Australia Development Lab, IBM

Re: binutils 2.19 issue with kernel link

[Kumar Gala]

On Jul 9, 2009, at 11:15 PM, Alan Modra wrote:

> On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797  
> wrote:
>> I understand your arguments, but there is something inconsistent  
>> about this.
>> If I change the script to be:
>>       _end3 = . ;
>>       . = _end3;
>>       . = ALIGN(PAGE_SIZE);
>>       _end = . ;
>>       PROVIDE32 (end = .);
>> }
>> The result is corrected:
>> c067f678 A _end3
>> c0680000 A _end
>>
>> Why the apuinfo section with zero VMA sometimes interfere with "."  
>> and
>> sometimes not ?
>
> I said it was weird in my last email.  Not so.  The orphan gets placed
> between
>
>       _end3 = . ;
>       . = _end3;
>
> So dot is restored after the orphan section sets it.

This seems to be a bit of a chick and egg scenario.  Older kernel  
linker scripts aren't going to cover all sections and thus may have  
orphan sections.  How do we ensure _end can be set properly under such  
conditions?

- k

Re: binutils 2.19 issue with kernel link

[Kumar Gala]

On Jul 10, 2009, at 9:37 AM, Kumar Gala wrote:

>
> On Jul 9, 2009, at 11:15 PM, Alan Modra wrote:
>
>> On Thu, Jul 09, 2009 at 02:31:53PM -0500, Edmar Wienskoski-RA8797  
>> wrote:
>>> I understand your arguments, but there is something inconsistent  
>>> about this.
>>> If I change the script to be:
>>>      _end3 = . ;
>>>      . = _end3;
>>>      . = ALIGN(PAGE_SIZE);
>>>      _end = . ;
>>>      PROVIDE32 (end = .);
>>> }
>>> The result is corrected:
>>> c067f678 A _end3
>>> c0680000 A _end
>>>
>>> Why the apuinfo section with zero VMA sometimes interfere with "."  
>>> and
>>> sometimes not ?
>>
>> I said it was weird in my last email.  Not so.  The orphan gets  
>> placed
>> between
>>
>>      _end3 = . ;
>>      . = _end3;
>>
>> So dot is restored after the orphan section sets it.
>
> This seems to be a bit of a chick and egg scenario.  Older kernel  
> linker scripts aren't going to cover all sections and thus may have  
> orphan sections.  How do we ensure _end can be set properly under  
> such conditions?

Not sure if this helps, but I've isolated down the version of binutils  
that changes to:

binutils-2.19		_end is what we expect
binutils-2.19.1		_end is what we expect
binutils-2.19.50.0.1	_end is what we expect
binutils-2.19.51.0.1	_end is 00001000

 From the release notes:

binutils-2.19.50.0.1 is based on CVS binutils 2008 1007
binutils-2.19.51.0.1 is based on CVS binutils 2009 0106

- k

Re: binutils 2.19 issue with kernel link

[Kumar Gala]

On Jul 9, 2009, at 11:11 PM, Alan Modra wrote:

> Hmm, having said all that, the following linker patch seems reasonable
> to me and probably won't break anything else (always some risk).
> Please test it for me.
>
> Index: ld/ldlang.c
> ===================================================================
> RCS file: /cvs/src/src/ld/ldlang.c,v
> retrieving revision 1.311
> diff -u -p -r1.311 ldlang.c
> --- ld/ldlang.c	25 Jun 2009 13:18:46 -0000	1.311
> +++ ld/ldlang.c	10 Jul 2009 04:04:57 -0000
> @@ -1615,10 +1615,12 @@ output_prev_sec_find (lang_output_sectio
>    idea is to skip over anything that might be inside a SECTIONS {}
>    statement in a script, before we find another output section
>    statement.  Assignments to "dot" before an output section statement
> -   are assumed to belong to it.  An exception to this rule is made  
> for
> -   the first assignment to dot, otherwise we might put an orphan
> -   before . = . + SIZEOF_HEADERS or similar assignments that set the
> -   initial address.  */
> +   are assumed to belong to it, except in two cases;  The first
> +   assignment to dot, and assignments before non-alloc sections.
> +   Otherwise we might put an orphan before . = . + SIZEOF_HEADERS or
> +   similar assignments that set the initial address, or we might
> +   insert non-alloc note sections among assignments setting end of
> +   image symbols.  */
>
> static lang_statement_union_type **
> insert_os_after (lang_output_section_statement_type *after)
> @@ -1662,7 +1664,12 @@ insert_os_after (lang_output_section_sta
> 	  continue;
> 	case lang_output_section_statement_enum:
> 	  if (assign != NULL)
> -	    where = assign;
> +	    {
> +	      asection *s = (*where)->output_section_statement.bfd_section;
> +
> +	      if (s == NULL || (s->flags & SEC_ALLOC) != 0)
> +		where = assign;
> +	    }
> 	  break;
> 	case lang_input_statement_enum:
> 	case lang_address_statement_enum:
>
> -- 

This patch seems to "fix" things.

- k

Re: binutils 2.19 issue with kernel link

[Alan Modra]

On Fri, Jul 10, 2009 at 10:27:26AM -0500, Kumar Gala wrote:
> binutils-2.19		_end is what we expect
> binutils-2.19.1		_end is what we expect
> binutils-2.19.50.0.1	_end is what we expect
> binutils-2.19.51.0.1	_end is 00001000
>
> From the release notes:
>
> binutils-2.19.50.0.1 is based on CVS binutils 2008 1007
> binutils-2.19.51.0.1 is based on CVS binutils 2009 0106

Yes, I already have good reason to suspect this patch

2008-10-22  Alan Modra  <amodra@bigpond.net.au>

	* ldlang.c (lang_output_section_find_by_flags): Handle non-alloc
	sections.
	* emultempl/elf32.em (enum orphan_save_index): Add orphan_nonalloc.
	(hold): Likewise.
	(gld${EMULATION_NAME}_place_orphan): Handle non-alloc orphans.

causes the change in linker behaviour.  Did you try the patch I posted?

-- 
Alan Modra
Australia Development Lab, IBM

Re: binutils 2.19 issue with kernel link

[Alan Modra]

On Sat, Jul 11, 2009 at 09:35:03AM +0930, Alan Modra wrote:
> Did you try the patch I posted?

/me reads other email.  I see you did.  Applying.

-- 
Alan Modra
Australia Development Lab, IBM