Date:	Mon, 14 Jun 2010 18:02:17 -0400 (EDT)
From:	Tim Abbott <tabbott@...lice.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
cc:	Matt Fleming <matt@...sole-pimps.org>, linux-arch@...r.kernel.org,
	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
	Sam Ravnborg <sam@...nborg.org>, Michal Marek <mmarek@...e.cz>,
	Denys Vlasenko <vda.linux@...glemail.com>
Subject: Re: [PATCH 1/5] vmlinux.lds.h: Include *(.text.*) in TEXT_TEXT

On Mon, 14 Jun 2010, James Bottomley wrote:

> On Mon, 2010-06-14 at 20:33 +0100, Matt Fleming wrote:
> > On Mon, 14 Jun 2010 10:32:46 -0400 (EDT), Tim Abbott <tabbott@...lice.com> wrote:
> > > 
> > > I was planning to submit in the next couple weeks a change that adds 
> > > support for building the kernel with -ffunction-sections -fdata-sections, 
> > > which would have as a piece of it adding to TEXT_TEXT the following 
> > > expression:
> > > 
> > > 	*(.text.[A-Za-z$_]*)	/* handle -ffunction-sections */\
> 
> Just as a point of technical interest, that won't handle
> -ffunction-sections.  At least on parisc, we get a
> section .text.<function name> for every function.  This means that any
> character legal in a function name can appear there, not just letters
> and underscores (we get millicode ones with dollar signs as well for
> instance).  That's why *(.text.*) is safer

Hi James,

I believe that the pattern [A-Za-z$_] matches all valid characters to 
start a function name (in particular, it includes "$").  If I'm missing 
any valid characters for the start of a function name, please correct me.

To give some background, the strategy here for -ffunction-sections support 
is to have the kernel's "magic" text sections all start with

".text.."

while the sections generated by -ffunction-sections will start with

".text." followed by a character other than "."

These sets are disjoint, and so if we have a complete set of valid next 
characters in the pattern ".text.[A-Za-z$_]*", it will be just as good as 
".text.*" for matching the sections produced by -ffunction-sections.  (As 
a sidenote, I would prefer .text.[^.], but I don't believe that is valid 
linker script syntax).

While one could in principle try to handle things by not renaming the 
.text.foo sections and instead just placing the linker script code for 
them all before a .text.* item in the linker script, that approach is 
really fragile.  I think the "text..foo" approach is a good design and I 
am not aware of any problems with it.

Some more detailed explanation is available here:
<http://lkml.org/lkml/2010/2/19/365>

> > > which should match the .text.foo sections generated by -ffunction-sections 
> > > but not the kernel's special sections which now all have names of the form 
> > > .text..foo.
> 
> They do?  I don't find any symbols like that on parisc.
> 
> Historically, the way we've differentiated is that kernel special
> symbols tend to have the text designator *after* the name, whereas the
> linker puts it before  ... of course that has issues for functions
> called things like text or init ... but we try not to do that ...

It looks like the patches for the .text.foo rename haven't been sent yet, 
my mistake.  I've primarily been tracking the much larger .data.foo -> 
.data..foo transition.  I expect a patch series to rename the remaining 
sections and add -ffunction-sections support will be sent by either Denys 
Vlasenko or myself in the next few weeks.

While the kernel does use section names like ".init.text", there were 
before quite recently a very large number of kernel special sections with 
names like ".data.page_aligned" which would conflict with:

static int page_aligned;

when compiling with -fdata-sections.

In fact, we initially sent patches that changed these all to e.g. 
".page_aligned.data".  But we discovered that it is problem when writing 
assembly files, since if you write:

.section ".page_aligned.data"

it doesn't work  -- you need to specify the load flags like so:

.section ".page_aligned.data", "aw"

while if you write e.g.

.section ".data..page_aligned"

the assembler will automatically set the right load flags for read/write 
data.

Since this is a subtle issue and I'd be surprised if there weren't a lot 
of people who work on assembly code in the kernel who don't know about 
this subtle issue, the ".page_aligned.data" naming scheme is destined to 
result in some frustrating bugs.  So we settled on the more bug-proof 
".data..page_aligned" naming scheme for adding -fdata-sections support.

It would probably be a good cleanup to go through and rename e.g. 
.init.text to .text..init so that we're consistent everywhere, but I'd 
like to get -ffunction-sections working before starting that project 
myself.

	-Tim Abbott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists