lkml.org 
[lkml]   [2008]   [Jul]   [2]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
FromDenys Vlasenko <>
SubjectRe: [PATCH 1/23] make section names compatible with -ffunction-sections -fdata-sections
DateWed, 2 Jul 2008 09:09:40 +0200
On Wednesday 02 July 2008 06:30, Andrew Morton wrote:
> On Wed, 2 Jul 2008 02:33:48 +0200 Denys Vlasenko <vda.linux@googlemail.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


\
 
 \ /
  Last update: 2008-07-02 09:13    [from the cache]
©2003-2008