linux-next: build failure after merge of the final tree

Hi all,

After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:

powerpc64-linux-ld: drivers/built-in.o: In function `.gpiochip_is_requested':
(.text+0x4): sibling call optimization to `_savegpr0_29' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_savegpr0_29' extern

I got more than 60000 of these messages before I killed the link. :-(  I
am not sure what has changed to do this, but it may have been masked for
the past few releases due to other linking problems.

I have left this broken for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

On Thu, Jul 05, 2012 at 06:33:45PM +1000, Stephen Rothwell wrote:

powerpc64-linux-ld: drivers/built-in.o: In function `.gpiochip_is_requested':
(.text+0x4): sibling call optimization to `_savegpr0_29' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_savegpr0_29' extern

I got more than 60000 of these messages before I killed the link. :-(  I
am not sure what has changed to do this, but it may have been masked for
the past few releases due to other linking problems.

Let me guess.  You're using bleeding edge gcc but not binutils.

a) Recent gcc has fixed prologue and epilogue generation which now
   properly makes use of out-of-line register save and restore
   functions when compiling with -Os.
b) Recent ld doesn't emit out-of-line save/restore function for ld -r,
   but yours does.  You need my 2012-06-22 patch.
c) Kernel uses ld -r for packaging.

(b) and (c) together mean you get a definition for _savegpr0_29 munged
together with other functions.  That's bad.  If _savegpr0_29 wasn't
emitted until the final link stage then it would be in a code section
containing just save/restore functions.  ld will analyse that section
and notice the absense of toc relocations; functions therein don't
use the toc and can thus be called from any toc group without needing
a toc adjusting stub.  In your case _savegpr0_29 is in a section that
has toc relocations (from normal compiled code), so ld decides that
any function in that section must have a proper value for the toc
register.  But calls to _savegpr0_29 don't have a following nop to
overwrite with a toc restore insn, hence the ld error.

Score another black mark for ld -r.

-- 
Alan Modra
Australia Development Lab, IBM

Hi Alan,

On Thu, 5 Jul 2012 19:13:48 +0930 Alan Modra [off-list ref] wrote:

On Thu, Jul 05, 2012 at 06:33:45PM +1000, Stephen Rothwell wrote:

quoted

powerpc64-linux-ld: drivers/built-in.o: In function `.gpiochip_is_requested':
(.text+0x4): sibling call optimization to `_savegpr0_29' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_savegpr0_29' extern

I got more than 60000 of these messages before I killed the link. :-(  I
am not sure what has changed to do this, but it may have been masked for
the past few releases due to other linking problems.

Let me guess.  You're using bleeding edge gcc but not binutils.

powerpc-linux-gcc (GCC) 4.6.3
GNU ld (GNU Binutils) 2.22

both built from upstream sources (by Tony).

a) Recent gcc has fixed prologue and epilogue generation which now
   properly makes use of out-of-line register save and restore
   functions when compiling with -Os.
b) Recent ld doesn't emit out-of-line save/restore function for ld -r,
   but yours does.  You need my 2012-06-22 patch.
c) Kernel uses ld -r for packaging.

(b) and (c) together mean you get a definition for _savegpr0_29 munged
together with other functions.  That's bad.  If _savegpr0_29 wasn't
emitted until the final link stage then it would be in a code section
containing just save/restore functions.  ld will analyse that section
and notice the absense of toc relocations; functions therein don't
use the toc and can thus be called from any toc group without needing
a toc adjusting stub.  In your case _savegpr0_29 is in a section that
has toc relocations (from normal compiled code), so ld decides that
any function in that section must have a proper value for the toc
register.  But calls to _savegpr0_29 don't have a following nop to
overwrite with a toc restore insn, hence the ld error.

Score another black mark for ld -r.

OK, the new toolchain may be the problem.  I changed from:

powerpc-linux-gcc (GCC) 4.6.0
GNU ld (GNU Binutils) 2.21

on June 20 and the current errors may have been masked an early bailout
after getting theses errors:

powerpc64-linux-ld: arch/powerpc/net/built-in.o: In function `bpf_slow_path_word':
(.text+0x90): sibling call optimization to `skb_copy_bits' does not allow automatic multiple TOCs; recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `skb_copy_bits' extern

which have now been fixed.  So would a simple patch that puts the
_savegpr etc functions in their own section (defined how?) fix this for
us?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

On Fri, Jul 06, 2012 at 10:21:51AM +1000, Stephen Rothwell wrote:

which have now been fixed.  So would a simple patch that puts the
_savegpr etc functions in their own section (defined how?) fix this for
us?

Ah, the kernel provides its own save/restore functions, and these get
mashed into a .text containing normal functions with toc references by
ld -r.  Well, you could stop using ld -r.  Otherwise, try

 .section ".text.save.restore","ax",@progbits

-- 
Alan Modra
Australia Development Lab, IBM

Hi Alan,

On Fri, 6 Jul 2012 10:27:10 +0930 Alan Modra [off-list ref] wrote:

On Fri, Jul 06, 2012 at 10:21:51AM +1000, Stephen Rothwell wrote:

quoted

which have now been fixed.  So would a simple patch that puts the
_savegpr etc functions in their own section (defined how?) fix this for
us?

Ah, the kernel provides its own save/restore functions, and these get
mashed into a .text containing normal functions with toc references by
ld -r.  Well, you could stop using ld -r.  Otherwise, try

 .section ".text.save.restore","ax",@progbits

OK, so that helped a lot.  Now I get this:

drivers/built-in.o: In function `.idt77252_init_ubr.isra.10':
idt77252.c:(.text+0x1ff801c): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
drivers/built-in.o: In function `.idt77252_init_tx':
idt77252.c:(.text+0x1ff8258): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
drivers/built-in.o: In function `.idt77252_change_qos':
idt77252.c:(.text+0x1ff86a0): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
drivers/built-in.o: In function `.idt77252_open':
idt77252.c:(.text+0x1ff898c): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
idt77252.c:(.text+0x1ff8f4c): relocation truncated to fit: R_PPC64_REL24 against symbol `_restgpr0_22' defined in .text.save.restore section in arch/powerpc/lib/built-in.o
drivers/built-in.o: In function `.next_string':
solos-pci.c:(.text+0x1ff8f54): relocation truncated to fit: R_PPC64_REL24 against symbol `_savegpr0_29' defined in .text.save.restore section in arch/powerpc/lib/built-in.o
solos-pci.c:(.text+0x1ff8f64): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
drivers/built-in.o: In function `.print_buffer':
solos-pci.c:(.text+0x1ff904c): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
drivers/built-in.o: In function `.atm_remove':
solos-pci.c:(.text+0x1ff91d4): relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in arch/powerpc/kernel/entry_64.o
solos-pci.c:(.text+0x1ff923c): relocation truncated to fit: R_PPC64_REL24 against symbol `.sysfs_remove_group' defined in .text section in fs/built-in.o
drivers/built-in.o: In function `.fpga_tx':
solos-pci.c:(.text+0x1ff950c): additional relocation overflows omitted from the output

I assume at this point, we are just too large.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

On Fri, Jul 06, 2012 at 01:01:37PM +1000, Stephen Rothwell wrote:

solos-pci.c:(.text+0x1ff923c): relocation truncated to fit: R_PPC64_REL24

                     ^^^^^^^^^

I assume at this point, we are just too large.

Yeah, but not in total.  I didn't see any of these in the allyes
kernel I built with our proof of concept hack to avoid ld -r.  I think
you'll find that these are all from ld -r output, as I assume no one
in kernel land writes drivers or whatever with 33M of text in a single
file.  Branches in that monstrous section can't even reach the
trampolines that ld inserts to extend branch reach.  Did I mention
that ld -r is a bad idea?

One workaround might be to compile with -ffunction-sections.

-- 
Alan Modra
Australia Development Lab, IBM