lkml.org 
[lkml]   [2016]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: linker-tables v5 testing
On Thu, Dec 1, 2016 at 10:31 PM, Nicholas Piggin
<nicholas.piggin@gmail.com> wrote:
>
> On 2 Dec 2016 2:35 AM, "Luis R. Rodriguez" <mcgrof@kernel.org> wrote:
>>
>> On Wed, Nov 30, 2016 at 9:20 PM, Nicholas Piggin <npiggin@gmail.com>
>> wrote:
>> > On Thu, 1 Dec 2016 16:04:30 +1100
>> > Nicholas Piggin <npiggin@gmail.com> wrote:
>> >
>> >> On Wed, 30 Nov 2016 19:15:27 -0800
>> >> "Luis R. Rodriguez" <mcgrof@kernel.org> wrote:
>> >>
>> >> > On Wed, Nov 30, 2016 at 6:51 PM, Nicholas Piggin <npiggin@gmail.com>
>> >> > wrote:
>> >> > > On Wed, 30 Nov 2016 18:38:16 +0100
>> >> > > "Luis R. Rodriguez" <mcgrof@kernel.org> 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

\
 
 \ /
  Last update: 2016-12-02 16:51    [W:0.196 / U:0.596 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site