Re: linker-tables v5 testing

[Luis R. Rodriguez]

On Wed, Nov 30, 2016 at 9:20 PM, Nicholas Piggin <npiggin@xxxxxxxxx> wrote:
> On Thu, 1 Dec 2016 16:04:30 +1100
> Nicholas Piggin <npiggin@xxxxxxxxx> wrote:
>
>> On Wed, 30 Nov 2016 19:15:27 -0800
>> "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx> wrote:
>>
>> > On Wed, Nov 30, 2016 at 6:51 PM, Nicholas Piggin <npiggin@xxxxxxxxx> wrote:
>> > > On Wed, 30 Nov 2016 18:38:16 +0100
>> > > "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx> wrote:
>> > >
>> > >> On Wed, Nov 30, 2016 at 02:09:47PM +1100, Nicholas Piggin wrote:
>>
>> > >> What is wrong with that ? Separating linker table and section ranges is
>> > >
>> > > It's not that you separate those, of course you need that. It's that
>> > > you also separate other sections from the input section descriptions:
>> > >
>> > > -               *(.text.hot .text .text.fixup .text.unlikely)           \
>> > > +               *(.text.hot .text)                                      \
>> > > +               *(SORT(.text.rng.*))                                    \
>> > > +               *(.text.fixup .text.unlikely)                           \
>
> Ahh, you're doing it to avoid clash with compiler generated sections.

Nope, its for two reasons:

1) To be able to construct arrays without modifying the linker script
we had to get crafty, and opted in for the trick of picking two
arbitrary delimiters for use of section start, and section end, namely
the tilde character ("~") and the empty string (""), and then stuffing
anything in between. For this to work properly we must SORT() these
specially crafted sections as well.

2) Because I don't want to regress .text if SORT()'ing it breaks
something. In theory it should not but I rather be careful.

> The usual way to cope with that seems to be to use two dots for your name.
> .text..rng.*

I have been wondering why people started doing that, it was not clear
nor documented anywhere. So no, it was not my original motivation, but
if it helps, it will be good to document this as well.

 Luis