[RS6000] ABI_V4 ifunc

Given a hidden visibility function declaration, the toolchain can say
that the function is local to the module.  This generally means that a
call to the function can be direct, ie. doesn't need to go via the PLT
even in a shared library.  However, ifunc breaks this promise.  GNU
indirect functions may resolve non-locally, and are implemented by
always using a PLT call.

This causes trouble for targets like ppc32 where the -msecure-plt PIC
PLT call stub needs a valid GOT pointer.  Any call that potentially
might be to an ifunc therefore requires a GOT pointer, and can't be a
sibling call (because the GOT pointer on ppc32 is a caller saved reg).

So unless we require that all ifuncs are declared as ifunc, it seems
that ppc32 can't assume extern or weak functions are local.  This
patch does the latter.  Boostrapped and regression tested
powerpc64-linux biarch.  OK to apply?

Also see https://sourceware.org/bugzilla/show_bug.cgi?id=19784 and
testcase ld/testsuite/ld-ifunc/pr17984*.c.  Note that the problem does
not need -Bsymbolic-functions to exhibit on powerpc.

	* config/rs6000/predicates.md (current_file_function_operand):
	Exclude extern and weak sym_refs for ABI_V4 when PIC and
	secure-plt.
	* config/rs6000/rs6000.c (rs6000_function_ok_for_sibcall): Don't
	allow sibcalls for ABI_V4 secure-plt PIC extern and weak.
	(rs6000_elf_encode_section_info): Remove SYMBOL_FLAG_LOCAL on ifuncs.
	* config/rs6000/rs6000.md (call_nonlocal_sysv<mode>): Split when
	extern or weak.
	(call_value_nonlocal_sysv<mode>): Likewise.
	(call_nonlocal_sysv_secure<mode>): Accept extern and weak.
	(call_value_nonlocal_sysv_secure<mode>): Likewise.

On Wed, Aug 24, 2016 at 10:14:29AM +0930, Alan Modra wrote:
> Given a hidden visibility function declaration, the toolchain can say
> that the function is local to the module.  This generally means that a
> call to the function can be direct, ie. doesn't need to go via the PLT
> even in a shared library.  However, ifunc breaks this promise.  GNU
> indirect functions may resolve non-locally, and are implemented by
> always using a PLT call.
> 
> This causes trouble for targets like ppc32 where the -msecure-plt PIC
> PLT call stub needs a valid GOT pointer.  Any call that potentially
> might be to an ifunc therefore requires a GOT pointer, and can't be a
> sibling call (because the GOT pointer on ppc32 is a caller saved reg).
> 
> So unless we require that all ifuncs are declared as ifunc, it seems
> that ppc32 can't assume extern or weak functions are local.  This
> patch does the latter.  Boostrapped and regression tested
> powerpc64-linux biarch.  OK to apply?

Okay for trunk.  (Unless "boostrapped" means that it failed horribly ;-) )


> diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
> index 58dccdd..07e79ab 100644
> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -10278,8 +10278,10 @@

This doesn't show what pattern this is.  If you make a ".gitattributes"
somewhere in your tree (I have it in the gcc/ subdir), containing

*.md  diff=md

and then in your git config (say, in .git/config in the GCC source tree)
you have

[diff "md"]
        xfuncname = "^\\(define.*$"

then magic happens.

Cheers,


Segher

On Wed, 24 Aug 2016, Alan Modra wrote:
> Given a hidden visibility function declaration, the toolchain can say
> that the function is local to the module.  This generally means that a
> call to the function can be direct, ie. doesn't need to go via the PLT
> even in a shared library.  However, ifunc breaks this promise.  GNU
> indirect functions may resolve non-locally, and are implemented by
> always using a PLT call.
> 
> This causes trouble for targets like ppc32 where the -msecure-plt PIC
> PLT call stub needs a valid GOT pointer.  Any call that potentially
> might be to an ifunc therefore requires a GOT pointer, and can't be a
> sibling call (because the GOT pointer on ppc32 is a caller saved reg).

The same issue exists on 32-bit x86: PLT calls require that %ebx holds the
address of GOT (and the sibcall issue arises as well).  I've just confirmed
using a simple testcase that the scenario you describe leads to a runtime error
on i386, and even LD_BIND_NOW=1 doesn't help, as it doesn't trigger early
resolution of ifuncs.

> So unless we require that all ifuncs are declared as ifunc,

(note, that would be impossible with today's GCC because the ifunc attribute
requires designating the resolver, and the resolver cannot be extern -- so
ultimately you cannot declare an extern-ifunc symbol)

> it seems that ppc32 can't assume extern or weak functions are local.

It doesn't seem nice to penalize all normal calls due to this issue. I think a
solution without this cost is possible: have ld synthesize a forwarder function
when it sees a non-plt call to an ifunc symbol. The forwarder can push the GOT
register, load the GOT address, call the ifunc symbol, pop the GOT register and
return. Does this sound right?

HTH.
Alexander

On 24/08/16 02:55, Segher Boessenkool wrote:

>  If you make a ".gitattributes"
> somewhere in your tree (I have it in the gcc/ subdir), containing
> 
> *.md  diff=md
> 
> and then in your git config (say, in .git/config in the GCC source tree)
> you have
> 
> [diff "md"]
>         xfuncname = "^\\(define.*$"
> 
> then magic happens.

Which sort of begs the question as to why nobody has proposed at least
the top bit for GCC's toplevel .gitattributes file.

R.

On Aug 25, 2016, at 3:14 AM, Richard Earnshaw (lists) <Richard.Earnshaw@arm.com> wrote:
> 
> On 24/08/16 02:55, Segher Boessenkool wrote:
>> If you make a ".gitattributes"
>> somewhere in your tree (I have it in the gcc/ subdir), containing
>> 
>> *.md  diff=md
>> 
>> and then in your git config (say, in .git/config in the GCC source tree)
>> you have
>> 
>> [diff "md"]
>>        xfuncname = "^\\(define.*$"
>> 
>> then magic happens.
> 
> Which sort of begs the question as to why nobody has proposed at least
> the top bit for GCC's toplevel .gitattributes file.

No expert has considered it obvious yet.  We can encourage them.  :-)  For the people that don't know git, it might not be obvious.

On Thu, Aug 25, 2016 at 11:14:49AM +0100, Richard Earnshaw (lists) wrote:
> On 24/08/16 02:55, Segher Boessenkool wrote:
> 
> >  If you make a ".gitattributes"
> > somewhere in your tree (I have it in the gcc/ subdir), containing
> > 
> > *.md  diff=md
> > 
> > and then in your git config (say, in .git/config in the GCC source tree)
> > you have
> > 
> > [diff "md"]
> >         xfuncname = "^\\(define.*$"
> > 
> > then magic happens.
> 
> Which sort of begs the question as to why nobody has proposed at least
> the top bit for GCC's toplevel .gitattributes file.

Because it will do no good without the second part (which is more
complicated, so anyone doing that can easily do the first part), and
only the first part on its own does only hurt, not help.


Segher

On 25/08/16 20:13, Segher Boessenkool wrote:
> On Thu, Aug 25, 2016 at 11:14:49AM +0100, Richard Earnshaw (lists) wrote:
>> On 24/08/16 02:55, Segher Boessenkool wrote:
>>
>>>  If you make a ".gitattributes"
>>> somewhere in your tree (I have it in the gcc/ subdir), containing
>>>
>>> *.md  diff=md
>>>
>>> and then in your git config (say, in .git/config in the GCC source tree)
>>> you have
>>>
>>> [diff "md"]
>>>         xfuncname = "^\\(define.*$"
>>>
>>> then magic happens.
>>
>> Which sort of begs the question as to why nobody has proposed at least
>> the top bit for GCC's toplevel .gitattributes file.
> 
> Because it will do no good without the second part (which is more
> complicated, so anyone doing that can easily do the first part), and
> only the first part on its own does only hurt, not help.
> 
> 
> Segher
> 

I disagree.  The first part has to be in-tree (as I understand it) so
having to keep that bit separate from any patches is a real pain.  Yes
you need both parts to make it work, but if the in-tree part is just
there then it's not that hard to maintain the out-of-tree part yourself.

R.