Re: linker-tables v5 testing

[Luis R. Rodriguez]

On Thu, Dec 1, 2016 at 10:31 PM, Nicholas Piggin
<nicholas.piggin@xxxxxxxxx> wrote:
>
> On 2 Dec 2016 2:35 AM, "Luis R. Rodriguez" <mcgrof@xxxxxxxxxx> wrote:
>>
>> 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.
>
> Oh yes I wasn't talking about the sort itself, but about why you broke up
> the existing input section descriptions.

Ah, but I was also talking about this, the only thing is...

> That was my only concern, e.g.,
> .data and .data.[_0-9a-zA-Z] spoke be in the same description.

I was talking about splitting up .data and both .data.tbl .data.rng --
you were talking specifically only about .data and .data.[_0-9a-zA-Z]
and now I see the concern! Yes, you are -- we can avoid this, its just
your glob would also capture .data.tbl and data.rng and I want to sort
these so I do it first. But as you already deduced, this should still
have no harm as I am just stuffing it in well sorted first and the
later glob just captures that. I could have just used .data..tbl and
data..rng as you noted. Either way is fine by me.

Do you have a preference?

>> > 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.
>
> Yeah it's convention because . can be part of a section name but not a C
> symbol.

Great, makes sense -- do you have references for this practice BTW or
did you just infer this?

 Luis