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

[Anthony G. Basile]

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.

>
> You're right a "x86_64-linux-gnu" toolchain should be able to able to produce
> x86, x86_64 and x32 executables. That's why I'm confused when seeing
> "gnux32" as a separate ABI name. This is a code snippet from clang:

they should not be doing that.  that some people do is because they're
not thinking.  later on, when we have to update gnuconfig upstream, you
hit a problem.  take a look at how if-crazy config.sub and config.guess
are, especially the later.  i don't want to add the the craziness.

>
>   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.

>
>
> Lei
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@g.o
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA