This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [libobjc] fix to nil_method

> Stan Shebs <> writes:
> > Jan Hubicka wrote:
> >
> >>Hi,
> >>on the libobjc the nil_method is declared as varardic function, however
> >>the calls to it (appears to be autmatically generated by objc) are not.
> >>x86_64 requires all calls to varardic functions to eighter have varardic
> >>prototype or no prototype at all, so objc breaks.  WOuld be the attached patch OK?
> >>
> > nil_method is supposed to be of type IMP, which is variadic, so
> > I'm pretty sure everything is correct as-is.  How exactly is ObjC
> > breaking on x86_64?
> The general problem is code like the following:
> int a (...) {implementation}
> different file:
> extern int a (void);
> b (void)
> { a();}
> We pass in one register the number of variadic arguments - but only if
> the function is variadic.  a is called here as a non-variadic function
> but is implemented as a variadic one.  This will break.
> But at first glance, it appears that libobjc does it right:
> libobjc/objc/objc.h: typedef id (*IMP)(id, SEL, ...);
> Honza, where  is actually the problem?

The testcase I've seen simply calls nil_method with nonvariadic
prototype, I am sure.
I am not quite sure how the nil_method calls are constructed,
so perhaps it is time to reconsider.  The testcase was called mbcopy.m
if I recall directly.
For x86_64 it is OK to call nonvariadic function with variadic
prototype, but not vice versa.  Same holds for PPC, where the reuslt is
not runtime crash, just unnecesary touching of FP registers...

> Andreas
> -- 
>  Andreas Jaeger
>   SuSE Labs
>    private

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]