[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: GNU indirect functions vs. symbol visibility
From:       Alan Modra <amodra () gmail ! com>
Date:       2016-08-25 14:18:30
Message-ID: 20160825140629.GZ3677 () bubble ! grove ! modra ! org
[Download RAW message or body]

On Thu, Aug 25, 2016 at 01:36:53PM +0200, Florian Weimer wrote:
> * Alan Modra:
> 
> > glibc people: As the main user of ifuncs, how do you feel about not
> > declaring functions hidden that are implemented in glibc by ifuncs?
> 
> We have run into this before, I think:
> 
>   <https://sourceware.org/ml/libc-alpha/2016-07/msg00089.html>

Yes, this is exactly the same problem, a hidden visibility prototype
with an ifunc definition.  Don't add the visibility attribute to the
prototype and the problem will no longer occur.

Also note that adding hidden visibility to a prototype that has an
ifunc definition in glibc gives no benefit on targets that can handle
this situation.

The difficulty of course is that where glibc does not provide an ifunc
implementation you *do* want the hidden visibility attribute, and
whether or not ifuncs are used varies from target to target.

> > It's fine to make them hidden via a version script, or even define
> > them as hidden (which requires just the rs6000_elf_encode_section_info
> > part of my gcc patch to make ppc32 behave).
> 
> If it doesn't work, we'd certainly prefer an early diagnostic.

Right.  https://sourceware.org/bugzilla/show_bug.cgi?id=20515 opened.

-- 
Alan Modra
Australia Development Lab, IBM
[prev in list] [next in list] [prev in thread] [next in thread]