Messages in this thread | | | Date | Fri, 9 Dec 2016 12:11:13 +1000 | From | Nicholas Piggin <> | Subject | Re: 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
| |