[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.11.1503311429240.25806@knanqh.ubzr>
Date: Tue, 31 Mar 2015 14:42:24 -0400 (EDT)
From: Nicolas Pitre <nicolas.pitre@...aro.org>
To: Dave Martin <Dave.Martin@....com>
cc: Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Michal Marek <mmarek@...e.cz>,
Russell King - ARM Linux <linux@....linux.org.uk>,
Arnd Bergmann <arnd@...db.de>, linux-kbuild@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH 2/2] Kbuild: avoid partial linking of
drivers/built-in.o
On Tue, 31 Mar 2015, Dave Martin wrote:
> On Tue, Mar 31, 2015 at 11:22:29AM -0400, Nicolas Pitre wrote:
> > On Mon, 30 Mar 2015, Ard Biesheuvel wrote:
> >
> > > On 30 March 2015 at 16:13, Michal Marek <mmarek@...e.cz> wrote:
>
> [...]
>
> > > > What you could do is to add a Kconfig option to arch/arm/Kconfig adding
> > > > -ffunction-sections to the compiler flags. Then allyesconfig would
> > > > select it and work around the problem in a somewhat elegant way.
> > > >
> > >
> > > Excellent idea! Arnd hasn't chimed in yet, but he is the one doing
> > > lots and lots of randconfig builds and other test builds, so I will
> > > wait for him to confirm that this is a useful thing to have.
> >
> > I'm using -ffunction-sections as well for the kernel size reduction work
> > I'm currently doing. The linker script has to be adapted so .text.* is
> > specified along .text otherwise those functions end up appended at the
> > end of the binary.
>
> Interesting ... do you also mean using --gc-sections at link time?
Yes.
> We'd need to avoid pruning needed code that has no explicit caller,
> and functions that are part of the kernel/module ABI but not used
> within vmlinux.
Those are usually located in special sections, like the initcall table,
the CPU entry table, etc. The linker allows for those sections to be
marked with KEEP() not to prune them.
> The GCC docs suggest that -ffunction-sections may impact performance
> and/or increase code size, but I don't know by how much. Maybe it
> interferes with inling.
It doesn't interfere with inlining. However it impose a section
alignment on every function. That still can be overriden though. Also, I
suppose that gcc may not assume that calls to a global function that
happens to be located in the same C file will be close by anymore,
however I don't see this having any impact on ARM code generation.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists