[PATCH][OBVIOUS] Fix ifunc detection.

Jakub Jelinek jakub@redhat.com
Fri Mar 2 20:49:00 GMT 2018


On Fri, Mar 02, 2018 at 09:55:22AM -0700, Jeff Law wrote:
> On 03/02/2018 09:38 AM, Thomas Schwinge wrote:
> > Hi!
> > 
> > On Fri, 26 Jan 2018 16:24:48 +0100, Martin Liška <mliska@suse.cz> wrote:
> >> This fixes detection of ifunc target capability.
> >> I'm going to install the patch.
> > 
> > You could also just have approved the patch I had sent two months before:
> > <http://mid.mail-archive.com/87fu9aiemr.fsf@euler.schwinge.homeip.net>.
> > ;-)
> > 
> > One remark:
> > 
> >> --- a/gcc/testsuite/lib/target-supports.exp
> >> +++ b/gcc/testsuite/lib/target-supports.exp
> >> @@ -449,7 +449,7 @@ proc check_ifunc_available { } {
> >>  	extern "C" {
> >>  	#endif
> >>  	typedef void F (void);
> >> -	F* g (void) {}
> >> +	F* g (void) { return 0; }
> >>  	void f () __attribute__ ((ifunc ("g")));
> >>  	#ifdef __cplusplus
> >>  	}
> > 
> > Is it OK to "return 0" from this ifunc handler, or might some analysis in
> > GCC trip over that (at some later point)?  In my patch, I returned the
> > address of an "extern" function.
> ISTM the question is whether or not ifuncs are ever allowed to return
> NULL.  Maybe ping the glibc folks since that's where the extension started?

Returning NULL means immediate segfault if somebody tries to call that
function.

	Jakub



More information about the Gcc-patches mailing list