Re: [RFC][PATCH 0/5] kbuild changes, thin archives, --gc-sections

[Nicholas Piggin <npiggin@gmail.com>]

On Sun, 07 Aug 2016 22:23:02 +0200
Arnd Bergmann <arnd@arndb.de> wrote:

> On Friday, August 5, 2016 10:11:58 PM CEST Nicholas Piggin wrote:
> > Hello,
> > 
> > I have 3 different things in this patchset. All arch specific, but all
> > involve kbuild changes, so I'd like to discuss them with kbuild
> > maintainers. The goal has been to improve long standing linking
> > difficulties with the powerpc kernel.
> > 
> > * First, building kernel using thin archives rather than incremental
> >   linking. This seems quite clean and is per-arch, so I hope it should
> >   not be too controversial.
> > 
> > * Second, building kernel using -ffunction-sections -fdata-sections,
> >   --gc-sections. Yes, I'm spinning the wheel again. It was motivated
> >   by tiny codesize regression in the first patch, but the results seem
> >   too good to ignore.
> > 
> > * Third, allowing architecture to run a tool over module after it has
> >   been linked. Powerpc wants to use it in order to relocate "alternate
> >   code" instructions that get don't get linked at their runtime
> >   address. No idea if this is the right approach wrt kbuild, but it
> >   seems to work.
> > 
> > I have included the powerpc code for the first two as a reference. The
> > third is much bigger and mostly uninteresting for this cc list, but it
> > can be found here:
> > 
> >  https://patchwork.ozlabs.org/patch/651006/
> > 
> > Comments appreciated.
> > 
> >   
> 
> I've started tested this a bit on ARM now. The first things I noticed
> are:
> 
> 1. /home/arnd/cross-gcc/bin/arm-linux-gnueabi-ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
> 
> (actually this one has been present since the first version that
> stopped using recursive linking, I did 971a69db7dc0 ("Xen: don't
> warn about 2-byte wchar_t in efi") when I first saw the bug, but
> that fix no longer works and we have to do this differently
> 
> 2. big-endian builds on ARM stopped working, I now get
> 
> 22:53:02   CC      init/do_mounts_md.o
> 22:53:02   LD      init/mounts.o
> /home/arnd/cross-gcc/bin/arm-linux-gnueabi-ld: init/do_mounts.o: compiled for a big endian system and target is little endian
> /home/arnd/cross-gcc/bin/arm-linux-gnueabi-ld: failed to merge target specific data of file init/do_mounts.o
> 
> The problem seems to be that we don't pass the correct linker
> flags any more, it should be using --be8 from
> 
> arch/arm/Makefile:LDFLAGS_vmlinux       += --be8
> arch/arm/Makefile:LDFLAGS_MODULE        += --be8
> 
> but that somehow is lost.

These both seem like linker flags are being lost for some reason, but I
don't really know why. Maybe ARM's Makefile. I don't have an ARM build setup
but I'll try to help track it down when I get some time.


> 3. drivers/firmware/efi/libstub/lib.a: error adding symbols: Archive has no index; run ranlib to add one
> 
> haven't investigated at all, turned off EFI for now.

Okay this looks like a bug in patch 2 (caused by me, not Stephen!)

For thin archives, cmd_link_l_target should be:

cmd_link_l_target = rm -f $@; $(AR) rcT$(KBUILD_ARFLAGS) $@ $(lib-y)

(note no "S" option).

Thanks,
Nick