From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-ports-return-3604-listarch-libc-ports=sources.redhat.com@sourceware.org>
Received: (qmail 1021 invoked by alias); 24 Jan 2013 13:13:56 -0000
Received: (qmail 782 invoked by uid 22791); 24 Jan 2013 13:13:54 -0000
X-SWARE-Spam-Status: No, hits=-4.4 required=5.0	tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_GJ
X-Spam-Check-By: sourceware.org
Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Jan 2013 13:13:49 +0000
Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93])	by relay1.mentorg.com with esmtp 	id 1TyMcm-0000AL-Lk from Maciej_Rozycki@mentor.com ; Thu, 24 Jan 2013 05:13:48 -0800
Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675);	 Thu, 24 Jan 2013 05:13:48 -0800
Received: from [172.30.4.21] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Thu, 24 Jan 2013 13:13:45 +0000
Date: Thu, 24 Jan 2013 13:13:00 -0000
From: "Maciej W. Rozycki" <macro@codesourcery.com>
To: Richard Sandiford <rdsandiford@googlemail.com>, Chung-Lin Tang	<cltang@codesourcery.com>
CC: "Joseph S. Myers" <joseph@codesourcery.com>, <libc-ports@sourceware.org>
Subject: Re: [PATCH 2/2] MIPS16: MIPS16 support proper
In-Reply-To: <5101086C.2000107@codesourcery.com>
Message-ID: <alpine.DEB.1.10.1301241253570.4834@tp.orcam.me.uk>
References: <alpine.DEB.1.10.1301230313570.4834@tp.orcam.me.uk> <alpine.DEB.1.10.1301230317220.4834@tp.orcam.me.uk> <Pine.LNX.4.64.1301231706590.7102@digraph.polyomino.org.uk> <5101086C.2000107@codesourcery.com>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-ports.sourceware.org>
List-Subscribe: <mailto:libc-ports-subscribe@sourceware.org>
List-Post: <mailto:libc-ports@sourceware.org>
List-Help: <mailto:libc-ports-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: libc-ports-owner@sourceware.org
X-SW-Source: 2013-01/txt/msg00049.txt.bz2

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