Re: [Bug ld/5785] New: Spurious "section xxx overlaps section yyy"

[Sergei Organov]

Hi Nick,

Thank you very much for taking care of the issue, and please take easy
what I write below, -- this is a woe of a guy who feels very unlucky as
every upgrade of binutils breaks his linker scripts.

Nick Clifton <address@hidden> writes:
> Hi Sergei,
>
>> LD version 2.18.x produces bogus "section .xxx overlaps section .bss", while 
>> LD
>> version 2.16.1 works just fine.
>
> Well the 2.18 linker is behaving as documented.  Specifically in the
> bit on the "Output Section LMA" in the manual:
>
>   If neither AT nor AT> is specified for an allocatable section,
>   the linker will set the LMA such that the difference between
>   VMA and LMA for the section is the same as the preceding output
>   section in the same region.

Too clever and surprising to my taste. I'd invent new syntax for such a
feature, provided it's indeed that convenient.

[...]

> This is a change in the linker's behaviour that was made for the 2.18
> release.  There is even a mention of it in the NEWS file.

I'm sorry I didn't check the NEWS file before reporting it as a bug, --
it just looked so obviously wrong that I didn't even think it could be a
feature. At the very beginning of the "Output Section LMA" of the old
manual it was written:

"The linker will normally set the LMA equal to the VMA.  You can
 change that by using the `AT' keyword.  The expression LMA that follows
 the `AT' keyword specifies the load address of the section."

So I had the following simple rules in my mind:

1. '>REGION' alone sets LMA=VMA and puts the section into the region.
2. 'AT' keyword is there to set LMA different from VMA, if required.

... and now 2.18 broke both of my precious rules (the second one due to
the fact that I now need to use AT to set VMA=LMA) :(

I think it was wrong idea to break backward compatibility for the sake
of "... a more useful default when using overlays and other cases where
you specify an LMA differing from the VMA for some sections", especially
when those new rules are rather questionable, as now one can't tell from
the definition of section alone if it has VMA=LMA or not.

> It does suggest a workaround for the problem:  Change the "> RAM" in
> the description of the .bss section to "AT> RAM".  ie:
>
>    .bss : {
>      . += 0x120;
>    } AT> RAM

... now relying on the note in the documentation:

  "Note that if the section has not had a VMA assigned to it then the
   linker will use the LMA_REGION as the VMA region as well."

Seems like waiting for another clever trick that will change this one as
well...

So, due to the new rules, I should better change all of my "> R" to
">R AT>R", except where AT(addr) is used, e.g.:

.data: AT(addr) { ... } > RAM
.bss : { ... } > RAM AT> RAM

Seems like I'll need to learn to live with this...

> According to the manual this will set both the LMA and the VMA for the
> section, and you will end up with the same behaviour as the 2.16
> linker. (This change is backwards compatible, i.e. it will work with
> the 2.16 linker as well).  Unfortunately there is a bug in the current
> linker sources such that the "AT> [region-name]" syntax is ignored
> unless there is  also an "> [region-name-2]" specified for the
> section, and the two regions are different.  I can see no good reason
> for this, and the behaviour certainly isn't documented, so I am
> planning to check in the uploaded patch to remove this restriction
> unless my regression testing shows up a problem.

Is this bug there in 2.18, or only on the HEAD?

Anyway, I'm glad my wrong bug report helped to find and fix real bug ;)

-- Sergei.