public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "H.J. Lu" <hjl.tools@gmail.com>
To: x32-abi@googlegroups.com
Cc: Mike Frysinger <vapier@gentoo.org>,
	autoconf@gnu.org, gcc@gcc.gnu.org, 	config-patches@gnu.org
Subject: Re: new triplet for x32 psABI?
Date: Thu, 13 Oct 2011 00:49:00 -0000	[thread overview]
Message-ID: <CAMe9rOpz5wfJqupEgFAsP1p=pVvh4WG9WeM7QWzWd6vw8cyc5Q@mail.gmail.com> (raw)
In-Reply-To: <CAO-CJbi9ciWRXSGZEfwKZpR1ajmts1SmDqN_hSW=h7Luf=sLaQ@mail.gmail.com>

On Tue, Oct 11, 2011 at 10:03 PM, Michael LIAO <michael.hliao@gmail.com> wrote:
> On Tue, Oct 11, 2011 at 9:21 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> On Tuesday 11 October 2011 22:55:35 Michael LIAO wrote:
>>> On Mon, Oct 3, 2011 at 3:34 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>>> > On Monday, October 03, 2011 18:25:46 Michael LIAO wrote:
>>> >> The current scheme documented on website
>>> >> (https://sites.google.com/site/x32abi/) uses the existing triplet but
>>> >> specify x32 ABI through compiler/linker options. It works for most
>>> >> compilers aware of that, but how other tools not handling
>>> >> compiler/linker options knows the current build is targeted on a
>>> >> different environment?
>>> >
>>> > the mips people have been using a single tuple for multiple abis (n32 and
>>> > n64), and it doesn't appear to have been a blocker for them ...
>>>
>>> That's not true, at least to build glibc, you can use
>>> 'mips64-linux-gnuabi64' to specify a n64 build and
>>> ''mips64-linux-gnuabin32' for a n32 build without specifying compiler
>>> option explicitly. I just figured this out from mips ports of glibc
>>> from
>>> http://repo.or.cz/w/glibc-ports.git/blob/HEAD:/sysdeps/mips/preconfigure,
>>> where both compiler option and triplet are checked and triplet is
>>> preferred if they are not match.
>>
>> while it is true glibc has this code, it doesn't make my statements incorrect:
>> a single tuple works just fine with mips for multiple ABIs.  if you look at
>> other projects like gcc, it doesn't check this field at all.  so you're still
>> right where you started: you still haven't shown any cases which necessitate a
>> dedicated tuple.
>
> That's why the proposed new triplet won't break existing packages as,
> if they are compliant to autoconf, they should check that field with
> 'gnu*' or just ignore it instead of an exact matching.
>
> I am not asking a dedicated triplet for x32 to be used exclusively for
> x32 package build. I am asking additional triplet with enough details
> of execution environment (ABI definitely a necessary detail.) for
> package which relies on triplet to tell that. At least that triplet
> could be canonical and widely accepted for package really caring about
> that instead of forcing all package checking compiler options. If a
> package needs to support similar thing to mutlilib just like glibc,
> that new triplet will simiplifies their decision.
>
> gcc definitely is not that kind of package as it could be built to
> support generate x86-64, x32 and i386 code with the same package and
> need a runtime option to tell that.
>

I see 3 separate issues:

1. The file name of an x32 binary package needs to be marked as x32.
2. Compilers need a switch to generate x32 code.
3. We need to configure a software package for x32.

Which problem are you trying to resolve? Please explain yours
if it isn't covered above.

-- 
H.J.

  parent reply	other threads:[~2011-10-12 16:29 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-03 22:26 Michael LIAO
2011-10-03 22:30 ` Eric Blake
2011-10-03 22:35 ` Mike Frysinger
2011-10-03 22:57   ` Michael LIAO
2011-10-03 23:04     ` Mike Frysinger
2011-10-03 23:48       ` Michael LIAO
2011-10-04  0:47         ` Mike Frysinger
2011-10-04  3:26           ` Michael LIAO
2011-10-04  3:56             ` Mike Frysinger
2011-10-04  0:54         ` H.J. Lu
2011-10-04  3:44           ` Michael LIAO
2011-10-04 19:53             ` H.J. Lu
2011-10-03 23:06     ` H.J. Lu
2011-10-12  4:49   ` Michael LIAO
2011-10-12  7:13     ` Mike Frysinger
2011-10-12  7:27       ` Michael LIAO
2011-10-12 22:14         ` Mike Frysinger
2011-10-13  0:49         ` H.J. Lu [this message]
2011-10-13  7:26           ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMe9rOpz5wfJqupEgFAsP1p=pVvh4WG9WeM7QWzWd6vw8cyc5Q@mail.gmail.com' \
    --to=hjl.tools@gmail.com \
    --cc=autoconf@gnu.org \
    --cc=config-patches@gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=vapier@gentoo.org \
    --cc=x32-abi@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).