Message-Id: <200807020909.40557.vda.linux@googlemail.com>
Date:	Wed, 2 Jul 2008 09:09:40 +0200
From:	Denys Vlasenko <vda.linux@...glemail.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-arch@...r.kernel.org, Russell King <rmk@....linux.org.uk>,
	David Howells <dhowells@...hat.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Lennert Buytenhek <kernel@...tstofly.org>,
	Josh Boyer <jwboyer@...ux.vnet.ibm.com>,
	Paul Mackerras <paulus@...ba.org>,
	David Woodhouse <dwmw2@...radead.org>,
	Andi Kleen <andi@...stfloor.org>,
	torvalds@...ux-foundation.org,
	Paul Gortmaker <paul.gortmaker@...driver.com>,
	linux-embedded@...r.kernel.org, linux-kernel@...r.kernel.org,
	Tim Bird <tim.bird@...sony.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	Dave Miller <davem@...emloft.net>
Subject: Re: [PATCH 1/23] make section names compatible with -ffunction-sections -fdata-sections

On Wednesday 02 July 2008 06:30, Andrew Morton wrote:
> On Wed, 2 Jul 2008 02:33:48 +0200 Denys Vlasenko <vda.linux@...glemail.com> wrote:
> > I am unsure how to synchronize propagation of these patches
> > across all architectures.
> > 
> > Andrew, how this can be done without causing lots of pain
> > for arch maintainers? Please advise.
> 
> You didn't describe the problem which you're trying to solve, so how
> can I say?

The problem is that with -ffunction-sections -fdata-sections gcc
will create sections like .text.head and .data.nosave
whenever someone will have innocuous code like this:

static void head(...) {...}

or this:

int f(...)
{ 
	static int nosave;
...
}

somewhere in the kernel.

Then kernel linker script will be confused and put these sections
in wrong places.

IOW: names like .text.XXXX and .data.XXX must not be used for "magic"
sections.


> Possibilities are:
> 
> a) the generic bit depends on the arch bits
> 
>    -> No probs.  I can merge the generic bit once all architectures are in.
> 
> b) the arch bits depend on the generic bits
> 
>    -> No probs.  I can merge the generic bit then send all the arch bits.
> 
> c) they each depend on each other
> 
>    -> No probs.  We go round gaththering acks, slam it all into
>       a single patch then in it goes.  2.6.28, presumably.

It's definitely (c). Changes in, say, include/linux/init.h:

-#define __nosavedata __section(.data.nosave)
+#define __nosavedata __section(.nosave.data)

must be syncronized with, say, arch/arm/kernel/vmlinux.lds.S:

                . = ALIGN(4096);
                __nosave_begin = .;
-               *(.data.nosave)
+               *(.nosave.data)

> > The following patches fix section names, one per architecture.
> > 
> > The patch in _this_ mail fixes generic part.
> 
> (tries to work out what it does)
> 
> oh, it does the above section renaming.  So I guess we're looking at
> scenario c), above?
> 
> "otherwise section placement done by kernel's custom linker scripts
> produces broken vmlinux and vdso images" is an inadequate description. 
> Please describe the problem more completely.  This is important,
> because once we actually find out what the patch is fixing, perhaps
> others will be aware of less intrusive ways of fixing the problem, and
> we end up with a better patch.

See above. Is that explanation ok?

> Please be aware that last time someone tried function-sections, maybe
> five years ago, problems were encountered with linker efficiency
> (possible an O(nsections) or worse algorithm in ld).  Link times went
> up a lot.

Last time is was probably me :) about a year ago I think.
Last link stage takes niticeably more time, but
nothing really awful.

> So it would be good to hunt down some old ld versions and run some
> timings.  A mention of the results in the changelog is appropriate.
> 
> Is there actually a patch anywhere which enables function-sections for
> some architectures?  It would be good to see that (and its associated
> size-reduction results) so we can work out whether all these changes
> are worth pursuing.

Yes, I was posting it twice during last year.
(digging up old emails from "sent" folder...) here is some:

On Friday 07 September 2007 19:30, Denys Vlasenko wrote:
> On Friday 07 September 2007 17:31, Daniel Walker wrote:
> > On Thu, 2007-09-06 at 18:07 +0100, Denys Vlasenko wrote:
> > > A bit extended version:
> > > 
> > > In the process in making it work I saw ~10% vmlinux size reductions
> > > (which basically matches what Marcelo says) when I wasn't retaining
> > > sections needed for EXPORT_SYMBOLs, but module loading didn't work.
> > > 
> > > Thus I fixed that by adding KEEP() directives so that EXPORT_SYMBOLs
> > > are never discarded. This was just one of many fixes until kernel
> > > started to actually boot and work.
> > > 
> > > I did that before I posted patches to lkml.
> > > IOW: posted patches are not broken versus module loading.
> > 
> > Ok, this is more like the explanation I was looking for..
> > 
> > During this thread you seemed to indicate the patches you release
> > reduced the kernel ~10% , but now your saying that was pre-release ,
> > right?
> 
> CONFIG_MODULE=n will save ~10%
> CONFIG_MODULE=y - ~1%
> 
> Exact figure depends on .config (whether you happen to include
> especially "fat" code or not).

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