Messages in this thread | | | From | "Luis R. Rodriguez" <> | Date | Fri, 2 Dec 2016 07:49:52 -0800 | Subject | Re: 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
| |