From mboxrd@z Thu Jan 1 00:00:00 1970 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 Message-ID: <200807020909.40557.vda.linux@googlemail.com> References: <200807020233.48646.vda.linux@googlemail.com> <20080701213006.5502987a.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20080701213006.5502987a.akpm@linux-foundation.org> Content-Disposition: inline Sender: linux-embedded-owner@vger.kernel.org To: Andrew Morton Cc: linux-arch@vger.kernel.org, Russell King , David Howells , Ralf Baechle , Lennert Buytenhek , Josh Boyer , Paul Mackerras , David Woodhouse , Andi Kleen , torvalds@linux-foundation.org, Paul Gortmaker , linux-embedded@vger.kernel.org, linux-kernel@vger.kernel.org, Tim Bird , Martin Schwidefsky , Dave Miller List-Id: linux-arch.vger.kernel.org On Wednesday 02 July 2008 06:30, Andrew Morton wrote: > On Wed, 2 Jul 2008 02:33:48 +0200 Denys Vlasenko 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from qb-out-0506.google.com ([72.14.204.238]:19476 "EHLO qb-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759987AbYGBHJw (ORCPT ); Wed, 2 Jul 2008 03:09:52 -0400 Received: by qb-out-0506.google.com with SMTP id d8so1244819qbc.37 for ; Wed, 02 Jul 2008 00:09:49 -0700 (PDT) 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 References: <200807020233.48646.vda.linux@googlemail.com> <20080701213006.5502987a.akpm@linux-foundation.org> In-Reply-To: <20080701213006.5502987a.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <200807020909.40557.vda.linux@googlemail.com> Sender: linux-arch-owner@vger.kernel.org List-ID: To: Andrew Morton Cc: linux-arch@vger.kernel.org, Russell King , David Howells , Ralf Baechle , Lennert Buytenhek , Josh Boyer , Paul Mackerras , David Woodhouse , Andi Kleen , torvalds@linux-foundation.org, Paul Gortmaker , linux-embedded@vger.kernel.org, linux-kernel@vger.kernel.org, Tim Bird , Martin Schwidefsky , Dave Miller Message-ID: <20080702070940.9o1Vl8lDTAOY9r7kPNFrYrFOBT7MCAx9JkdP66VOmcI@z> On Wednesday 02 July 2008 06:30, Andrew Morton wrote: > On Wed, 2 Jul 2008 02:33:48 +0200 Denys Vlasenko 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