Re: [PATCH][OBVIOUS] Fix ifunc detection.

[Jeff Law <law at redhat dot com>]

On 03/02/2018 10:00 AM, Jakub Jelinek wrote:
> 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.
I understand that.  I'm referring to the semantic definition of an
ifunc.  It's an extension and we ought to have a crisp definition of
whether or not it can return NULL.

THe fact that returning NULL will cause the vast majority of systems to
segfault isn't the issue.  The issue is how have we defined the extension.

jeff