Re: [PATCH 1/23] make section names compatible with -ffunction-sections -fdata-sections
- From: Denys Vlasenko <vda.linux@xxxxxxxxxxxxxx>
- 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@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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
- References:
- Prev by Date: Re: [PATCH -mmotm] res_counter: fix building failure
- Next by Date: PROBLEM: Kernel panic
- Previous by thread: Re: [PATCH 1/23] make section names compatible with -ffunction-sections -fdata-sections
- Next by thread: [PATCH 2/23] make section names compatible with -ffunction-sections -fdata-sections: alpha
- Index(es):
Relevant Pages
|
