On Wednesday 02 July 2008 06:30, Andrew Morton wrote:
> On Wed, 2 Jul 2008 02:33:48 +0200 Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx> 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-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
