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


"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> 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.

As it happens, this very topic was raised on the GCC list recently:

http://gcc.gnu.org/ml/gcc/2013-01/msg00133.html
http://gcc.gnu.org/ml/gcc/2013-01/msg00229.html

Richard


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