This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: new triplet for x32 psABI?
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.