On Wed, Nov 30, 2016 at 9:20 PM, Nicholas Piggin <npig...@gmail.com> wrote: > On Thu, 1 Dec 2016 16:04:30 +1100 > Nicholas Piggin <npig...@gmail.com> wrote: > >> On Wed, 30 Nov 2016 19:15:27 -0800 >> "Luis R. Rodriguez" <mcg...@kernel.org> wrote: >> >> > On Wed, Nov 30, 2016 at 6:51 PM, Nicholas Piggin <npig...@gmail.com> wrote: >> > > On Wed, 30 Nov 2016 18:38:16 +0100 >> > > "Luis R. Rodriguez" <mcg...@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. > 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. Luis