[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