Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

[Nicholas Piggin]

On Fri, 05 Aug 2016 12:17:27 +0200
Arnd Bergmann <arnd@xxxxxxxx> wrote:

> On Friday, August 5, 2016 6:41:08 PM CEST Nicholas Piggin wrote:
> > On Thu, 4 Aug 2016 12:06:41 -0500
> > Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx> wrote:
> >   
> > > On Thu, Aug 04, 2016 at 06:10:57PM +0200, Arnd Bergmann wrote:  
> > > > On Thursday, August 4, 2016 9:47:13 PM CEST Nicholas Piggin wrote:
> > > >     
> > > > > +	__used							\
> > > > > +	__attribute__((section("___kentry" "+" #sym ",\"a\",@note #"), used)) \    
> > > > 
> > > > 
> > > > I've just started testing this, but the first problem I ran into
> > > > is that @ and # are special characters that have an architecture
> > > > specific meaning to the assembler. On ARM, you need "%note @" instead
> > > > of "@note #".    
> > > 
> > > That comment trick (I still feel guilty about it) causes more problems
> > > than it solves.  Please don't try to use it :-)  
> > 
> > Yeah that's a funny hack. I don't think it's required though, but I'm just
> > running through some more tests.
> > 
> > I think I found an improvement with the thin archives as well -- we were
> > still building symbol table after removing the s option (that only avoids
> > index). "S" is required to not build symbol table.
> > 
> > I'll send out an RFC on a slightly more polished patch series shortly.  
> 
> 
> I could not find Nico's patches, but based on the information in his
> presentation at
> 
> https://www.linuxplumbersconf.org/2015/ocw//system/presentations/3369/original/slides.html#(1)
> 
> I created a patch for ARM that mirrors what you have for powerpc, see
> below.

Great, thanks for jumping in. I posted another set which is a lot improved
you should pick up.


> I have successfully built normal-sized kernels with this (not tried
> running them). Unfortunately, the build time for "allyesconfig"
> kernel explodes, the final link time is now in the hours instead of
> minutes (no exact numbers unfortunately, it takes too long to
> reproduce),

That's becase we need to coalesce the new sections properly into the
output file. binutils does not cope with vast number of sections in
final linked file and spends all its time in hash lookup then explodes
usually.


> and I also get link errors for the .text.fixup section
> for any users of __put_user() in really large kernels:
> net/batman-adv/batman-adv.o:(.text.fixup+0x4): relocation truncated to fit: R_ARM_JUMP24 against `.text.batadv_log_read'

This may be fixed by fixing the linker script to bring in the new
sections properly (see new patchset).

If not, then if you can combine the sections rather than have them
consecutive in the output, e.g.,:

    *(.text .text.fixup)

Rather than

    *(.text)            
    *(.text.fixup)

Then the linker has more freedom to rearrange them. I realize it's
not that simple with ARM's .text.fixup, but maybe that helps you
get it to work.

Thanks,
Nick