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

From: Tim Abbott
Date: Mon Jun 14 2010 - 18:02:29 EST

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.

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


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 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 "" approach is a good design and I
am not aware of any problems with it.

Some more detailed explanation is available here:

> > > which should match the sections generated by -ffunction-sections
> > > but not the kernel's special sections which now all have names of the form
> > >
> 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 rename haven't been sent yet,
my mistake. I've primarily been tracking the much larger -> 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.
"". But we discovered that it is problem when writing
assembly files, since if you write:

.section ""

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

.section "", "aw"

while if you write e.g.

.section ".data..page_aligned"

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

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

-Tim Abbott
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at