This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports 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: [PATCH 2/2] MIPS16: MIPS16 support proper


On Thu, 24 Jan 2013, Chung-Lin Tang wrote:

> >> > -void
> >> > -__longjmp (env_arg, val_arg)
> >> > +static void __attribute__ ((nomips16))
> >> > +____longjmp (env_arg, val_arg)
> >> >       __jmp_buf env_arg;
> >> >       int val_arg;
> >> >  {
> >> > @@ -86,3 +86,5 @@ __longjmp (env_arg, val_arg)
> >> >    /* Avoid `volatile function does return' warnings.  */
> >> >    for (;;);
> >> >  }
> >> > +
> >> > +strong_alias (____longjmp, __longjmp);
> > Why is the renaming / alias needed?
> > 
> 
> This was because the declaration of __longjmp() in setjmp.h prohibited
> us from tagging it directly with __attribute__ ((nomips16)) locally;
> there will be a declaration inconsistent with header error.

 Indeed, GCC goes through a great pain to enforce consistency between a 
function's prototype and the corresponding definition as far as the mips16 
and nomips16 attributes are concerned.  On the other hand it is possible 
to provide a prototype with neither attribute and freely choose the 
instruction encoding used for the definition with either of the -mips16 
and -mno-mips16 command line options applied when building the relevant 
source file.

 I have no idea where this dichotomy comes from -- Richard, do you happen 
to know?  I'd be happy to get enlightened.

  Maciej


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