Re: [PATCH 1/5] vmlinux.lds.h: Include *(.text.*) in TEXT_TEXT

[James Bottomley]

On Mon, 2010-06-14 at 18:02 -0400, Tim Abbott wrote:
> 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@xxxxxxxxxxx> 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.

Well, our linker seems to generate annoying symbols with carets in
them ...

> 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.

OK, but how about some actual explanation?  You've just characterised
the current -ffunction-sections scheme that parisc has used for decades
as "fragile"

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

That's still a bit short on explanations.

But if I infer from the rest, someone, somewhere broke the convention
that all our special linux sections be called .XX.data and .XX.text to
distinguish them from the .text.FF and .data.YY the compiler will
generate with the relevant sectional directives? because it's been
working OK for us for a while.

To fix the breakage, the proposal now is to name all linux special
sections as .text..XX and .data..XX?  I can see that's more standard
looking that XX.text and XX.data, but not necessarily that it's better.

This then introduces a problem of matching because .text.X and .text..X
are hard to distinguish using the linker matching scripts.

So even if I buy the rename of the linux symbols, what about using a
linker defined symbol that's illegal as a function as the initial
separator instead of .?  So hyphen looks the obvious one ... you can
have all the linux special sections being .text- and .data- then we can
easily distinguish.

James

> > > > 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.



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