Messages in this thread | | | From | Denys Vlasenko <> | Subject | Re: [PATCH 1/23] make section names compatible with -ffunction-sections -fdata-sections | Date | Wed, 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
| |