All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gabriel Paubert <paubert@iram.es>
To: Michael Ellerman <michael@ellerman.id.au>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-kernel@vger.kernel.org, Alan Modra <amodra@bigpond.net.au>
Subject: Re: linux-next: build failure after merge of the final tree (powerpc related)
Date: Thu, 21 Jun 2012 09:29:28 +0200	[thread overview]
Message-ID: <20120621072928.GA13998@visitor2.iram.es> (raw)
In-Reply-To: <1340256961.1998.11.camel@concordia>

On Thu, Jun 21, 2012 at 03:36:01PM +1000, Michael Ellerman wrote:
> On Wed, 2012-06-20 at 17:50 +1000, Stephen Rothwell wrote:
> > Hi all,
> > 
> > After merging the final tree, today's linux-next build (powerpc
> > allyesconfig) failed like this:
> > 
> > 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
> 
> 
> Those seem to be caused because we don't have a nop after the call,
> meaning we can't patch the TOC pointer on the way back. Adding a nop
> fixes those.
> 
> But, then I get 32,410 variants of this:
> 
> powerpc64-linux-ld: /src/next/net/openvswitch/vport-netdev.c:189:(.text+0x89b990): 
> 	sibling call optimization to `_restgpr0_28' does not allow automatic multiple TOCs;
> 	recompile with -mminimal-toc or -fno-optimize-sibling-calls, or make `_restgpr0_28' extern
> 
> 

These functions should not need a TOC in the first place. There is
code in the linker (for 64 bit only: bfd/elf64-ppc.c) to automatically 
generate them whenever they are needed.

I suspect you compile with -Os. But I don't think you can use
these functions when doing a sibling call since restgpr0_nn
implies a return to the caller. restgpr1_nn would be different...

> And those are generated calls so I don't see how we can fix them.
> 
> > I started building with gcc 4.6.3/binutils 2.22 today.  gcc
> > 4.6.0/binutils 2.21 do not produce this error, it produces this instead
> > (which has been happening for a long time):
> > 
> > powerpc64-linux-ld: TOC section size exceeds 64k
> 
> 
> So presumably there's some new error checking that we're hitting, I
> imagine it was always broken, but now it's being more explicit.

I'm not so sure. I suspect gcc, but upgrading gcc and binutils at the
same time may not be the wisest...

	Gabriel

  parent reply	other threads:[~2012-06-21  8:05 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-20  7:50 linux-next: build failure after merge of the final tree (powerpc related) Stephen Rothwell
2012-06-20  7:50 ` Stephen Rothwell
2012-06-20 10:09 ` Benjamin Herrenschmidt
2012-06-20 10:09   ` Benjamin Herrenschmidt
2012-06-21  5:36 ` Michael Ellerman
2012-06-21  5:36   ` Michael Ellerman
2012-06-21  6:24   ` Benjamin Herrenschmidt
2012-06-21  7:07     ` Michael Ellerman
2012-06-21  7:07       ` Michael Ellerman
2012-06-21  7:07       ` Michael Ellerman
2012-06-21  7:38       ` Michael Ellerman
2012-06-21  7:38         ` Michael Ellerman
2012-06-21  7:38         ` Michael Ellerman
2012-06-21 10:48         ` Alan Modra
2012-06-21 10:48           ` Alan Modra
2012-06-21 11:43           ` Alan Modra
2012-06-21 11:43             ` Alan Modra
2012-06-22  0:39             ` Michael Ellerman
2012-06-22  0:39               ` Michael Ellerman
2012-06-21  7:29   ` Gabriel Paubert [this message]
  -- strict thread matches above, loose matches on Subject: below --
2011-12-28  8:49 Stephen Rothwell
2011-12-28  8:49 ` Stephen Rothwell
2011-12-28  8:49 ` Stephen Rothwell
2011-12-28 10:32 ` Benjamin Herrenschmidt
2011-12-28 10:32   ` Benjamin Herrenschmidt
2012-01-02  8:25   ` Grant Likely
2012-01-02  8:25     ` Grant Likely
2012-01-02  8:39     ` Grant Likely
2012-01-02  8:39       ` Grant Likely
2010-09-03  3:24 Stephen Rothwell
2010-09-03  3:24 ` Stephen Rothwell
2010-09-17  4:27 ` Stephen Rothwell
2010-09-17  4:27   ` Stephen Rothwell
2010-07-16  7:19 Stephen Rothwell
2010-07-16  7:19 ` Stephen Rothwell
2010-07-16  7:19 ` Stephen Rothwell
2010-07-19  0:15 ` Benjamin Herrenschmidt
2010-07-19  0:15   ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120621072928.GA13998@visitor2.iram.es \
    --to=paubert@iram.es \
    --cc=amodra@bigpond.net.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=michael@ellerman.id.au \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.