Re: [gentoo-musl] [GSoC] musl and x32

[Lei Zhang]

2016-06-02 20:53 GMT+08:00 Anthony G. Basile <blueness@g.o>:
> On 6/2/16 8:48 AM, Lei Zhang wrote:
>> 2016-06-02 13:13 GMT+08:00 Anthony G. Basile <blueness@g.o>:
>>> On 6/1/16 11:35 PM, Lei Zhang wrote:
>>>>
>>>> Currently I'm considering introducing a new ABI type "musl" into clang, so
>>>> we can build a native clang targeting "x86_64-linux-musl". But I notice
>>>> there's also an ABI type specifically for x32, named "gnux32". Then what
>>>> about musl on a x32 platform? Should I name it "muslx32" or something? I
>>>> don't know why x86 and x86_64 can live with the same ABI name, while x32
>>>> can't...
>>>
>>> 1) i tried x32 + musl + gcc and ran into quite a few issues and gave up.
>>> i don't recall what those issues are right now, but they were basically
>>> lost of compile time breakage of packages.  since i'm not a big fan of
>>> x32 i didn't put a lot of effort in and when i saw it was a steep climb,
>>> i had bigger fish to fry.
>>
>> musl's FAQ says the support for x32 is still experimental; so the unstability
>> is kind of expected.
>>
>>>
>>> 2) i don't know what you mean by "should i name it muslx32".  what is
>>> the "it" in your sentence?
>>
>> I mean the ABI part in a toolchain triplet.
>
> there shouldn't be an abi part in the toolchain tuple.  i know some have
> done so, but its wrong for the reasons i said.  a single toolchain is
> able to emit multiple abis.  which one would you like to put there?
>
>>
>>> if its the the toolchain tuple, that should
>>> not contain the abi name in it because a given toolchain is able to emit
>>> different abis.  for example gcc on x86_64 architecture can produce
>>> three abis (if the corresponding libc's are available):  gcc -m32, gcc
>>> -m64, gcc -mx32
>>
>> Taking "x86_64-linux-musl" for example, the "musl" is the ABI name and
>> should be in the triplet, right? Otherwise how do we tell which libc
>> this toolchain
>> is using?
>
> no, musl is the name of the libc.  you are confusing the libc with the
> abi.  you can have multilib systems with /lib /lib64 /libx32 each with
> their own abi version of the libc.

The structure of target triplet is really confusing me... Typically a
triplet has the form:

<arch>-<vendor>-<os>

Then what is "musl" or "gnu"s role in this? A part of the <os> field?

>>
>>   enum EnvironmentType {
>>     UnknownEnvironment,
>>
>>     GNU,
>>     GNUEABI,
>>     GNUEABIHF,
>>     GNUX32,
>>     CODE16,
>>     EABI,
>>     EABIHF,
>>     Android,
>>
>>     MSVC,
>>     Itanium,
>>     Cygnus,
>>     AMDOpenCL,
>>     CoreCLR,
>>     LastEnvironmentType = CoreCLR
>>   };
>>
>> The "Environment" refers to the last part of a triplet.
>
> i'm not a clang fan.  if clang insists that the abi be in the tuple
> name, then its doing it wrong.  bug upstream clang people and ask wtf
> they are up to.

But aren't names like "gnueabi" and "gnueabihf" are also used in the GCC world?
It looks to me clang is just mimicking gcc's behavior. Or perhaps I'm
not getting
your point...


Lei