Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754516AbcLBPuh (ORCPT ); Fri, 2 Dec 2016 10:50:37 -0500 Received: from mail.kernel.org ([198.145.29.136]:39220 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753052AbcLBPu3 (ORCPT ); Fri, 2 Dec 2016 10:50:29 -0500 MIME-Version: 1.0 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> From: "Luis R. Rodriguez" Date: Fri, 2 Dec 2016 07:49:52 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: linker-tables v5 testing To: Nicholas Piggin 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 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3281 Lines: 85 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? >> > 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