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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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

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

>   I suspect after that change, the cleanup of deleting .text.* 
> > from the various architecture linker scripts that reference it should be 
> > possible.
> 
> Do these special kernel sections include things like the parisc
> .text.do_softirq, .text.sys_exit, etc? James raised a good objection to
> the parisc patch of this series. I'm guessing most people saw it already
> but I'll paste it here for reference,
> 
> 
>     This would destroy all of the named parisc text ordering we do above the
>     removed line because now you'd have swept up all the function sections
>     before we get to them, won't it?
> 
>     The ordering is an execution speed up on 32 bit systems because our
>     relative jump is so short.
> 
>     James
> 
> Will you changes handle this OK?

As long as we don't do the generic gathering of the rest of the text
sections until after the special ones are handled (and this includes the
specific function sections we name), it doesn't really matter to us how
it's done.

James