This is the mail archive of the
mailing list for the GCC project.
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
- From: "H. Peter Anvin" <hpa at zytor dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: NightStrike <nightstrike at gmail dot com>, Olivier Galibert <galibert at pobox dot com>, Chris Lattner <clattner at apple dot com>, Michael Matz <matz at suse dot de>, Richard Guenther <richard dot guenther at gmail dot com>, Joe Buck <Joe dot Buck at synopsys dot com>, Jan Hubicka <hubicka at ucw dot cz>, Aurelien Jarno <aurelien at aurel32 dot net>, linux-kernel at vger dot kernel dot org, gcc at gcc dot gnu dot org
- Date: Thu, 06 Mar 2008 07:50:12 -0800
- Subject: Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
- References: <Pine.LNX.firstname.lastname@example.org> <47CF11D6.email@example.com> <738B72DB-A1D6-43F8-813A-E49688D05771@apple.com> <Pine.LNX.firstname.lastname@example.org> <2F47E21A-9055-4EC3-99CF-B666BBC045C3@apple.com> <47CF3F09.email@example.com> <578FCA7D-D7A6-44F6-9310-4A97C13CDCBE@apple.com> <47CF44E7.firstname.lastname@example.org> <20080306135139.GA5236@dspnet.fr.eu.org> <email@example.com> <firstname.lastname@example.org>
H.J. Lu wrote:
I agree with it. There is no right or wrong here Let's start from
scratch and figure out
what is the best way to handle this, assuming we are defining a new psABI.
No, I believe the right way to approach this is by applying the good
old-fashioned principle from Ask Mr. Protocol:
Be liberal in what you receive, conservative in what you send
In other words:
a. Fix the kernel. Already in progress.
b. Do *not* make gcc assume DF is clean for now. Adding a
switch would be a useful thing, since if nothing else it
would benefit embedded environments. We might assume
DF is clean on 64 bits, since it appears it is rarely used
anyway, and 64 bits is more important in the long run.
c. Once fixed kernels have been out long enough, we can
flip the default of the switch, one platform at a time if
need be (e.g. there may never be another SCO OpenServer.)