Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754116AbcLICLd (ORCPT ); Thu, 8 Dec 2016 21:11:33 -0500 Received: from mail-pf0-f196.google.com ([209.85.192.196]:33425 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751674AbcLICLc (ORCPT ); Thu, 8 Dec 2016 21:11:32 -0500 Date: Fri, 9 Dec 2016 12:11:13 +1000 From: Nicholas Piggin To: "Luis R. Rodriguez" Cc: Borislav Petkov , Josh Poimboeuf , Guenter Roeck , Masami Hiramatsu , Namhyung Kim , Michael Matz , Nicholas Piggin , David Ahern , Kees Cook , Wang Nan , Fengguang Wu , Jiri Olsa , Arnd Bergmann , Joerg Roedel , "linux-kernel@vger.kernel.org" , "H. Peter Anvin" , Arnaldo Carvalho de Melo , Adrian Hunter Subject: Re: linker-tables v5 testing Message-ID: <20161209121113.31847049@roar.ozlabs.ibm.com> In-Reply-To: References: <20161130013349.GN1402@wotan.suse.de> <20161130140947.3ea27d9e@roar.ozlabs.ibm.com> <20161130173816.GP1402@wotan.suse.de> <20161201135146.295868f0@roar.ozlabs.ibm.com> <20161201160430.6e95710a@roar.ozlabs.ibm.com> <20161201162039.602da20a@roar.ozlabs.ibm.com> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4026 Lines: 100 On Fri, 2 Dec 2016 07:49:52 -0800 "Luis R. Rodriguez" wrote: > On Thu, Dec 1, 2016 at 10:31 PM, Nicholas Piggin > wrote: > > > > On 2 Dec 2016 2:35 AM, "Luis R. Rodriguez" wrote: > >> > >> On Wed, Nov 30, 2016 at 9:20 PM, Nicholas Piggin > >> wrote: > >> > On Thu, 1 Dec 2016 16:04:30 +1100 > >> > Nicholas Piggin wrote: > >> > > >> >> On Wed, 30 Nov 2016 19:15:27 -0800 > >> >> "Luis R. Rodriguez" wrote: > >> >> > >> >> > On Wed, Nov 30, 2016 at 6:51 PM, Nicholas Piggin > >> >> > wrote: > >> >> > > On Wed, 30 Nov 2016 18:38:16 +0100 > >> >> > > "Luis R. Rodriguez" 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