lkml.org 
[lkml]   [2016]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linker-tables v5 testing
On Fri, 2 Dec 2016 07:49:52 -0800
"Luis R. Rodriguez" <mcgrof@kernel.org> wrote:

> 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?

I would say use "..", just so there is less ambiguity and more
flexibility in moving around the input section descriptions if needed.

>
> >> > 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?

I believe I've seen something, perhaps it was in the binutils manuals,
but I tried just now and couldn't find anything.

It is a common practice to use dots in labels to avoid clashes with C
names in general. Specifically for sections we already have some cases
in there which I believe were added for similar reasons.

Thanks,
Nick

\
 
 \ /
  Last update: 2016-12-09 03:11    [W:0.124 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site