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

[Anthony G. Basile]

On 6/2/16 9:12 PM, Lei Zhang wrote:
> Thanks for the explanation. Things look much clearer to me now :)
>
> BTW, is config.guess able to print "x86_64-pc-linux-musl" on a musl
> based system? If so, then how does it detect the presence of musl?

read the code.  it doesn't detect musl, it parses the tuple.

>
>
> Lei
>
> 2016-06-02 21:28 GMT+08:00 Anthony G. Basile <blueness@g.o>:
>> On 6/2/16 9:17 AM, Lei Zhang wrote:
>>> 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>
>>
>> people have not been consistent, it should be
>>
>> machine-vendor-kernel-os
>>
>> see https://wiki.gentoo.org/wiki/Embedded_Handbook/Tuples
>>
>> so like i've been saying, some people will do muslx32 for the os, like
>> they do uclibceabi, but its misleading and should be avoided.
>>
>> having said that it may be impractical to avoid. to answer that
>> question, see what is int gnuconfig right now.
>>
>>>
>>> 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...
>>
>> i am aware.  this would not be the first time a bad practice got
>> historically entrenched.  that does not make it good.
>>
>> so where does the toolchain tuple make a difference?  when running
>> configure the system will have to make "guesses" about you machine's
>> ISA, the kernel, the libc/os.  configure uses config.guess to make these
>> guesses.  take a look at how that file parses things to see what it
>> would do with -musl and -muslx32.  my guess is that it doesn't make the
>> distinction because i was the guy that wrote the patch to get musl
>> recognition into gnuconfig and i was not worried about x32 at the time.
>> of course others may have contributed too, but if there is not -muslx32
>> in there, then i would say, let's not add it.  i'd eventually like to
>> see a multilib amd64 musl system where we have
>>
>> /lib32 <- for 32-bit abi
>> /lib64 <- for 64-bit abi
>> /libx32 <- for x32 abi
>>
>> and tuple x86_64-gentoo-linux-musl which emits all three, with -m64 as
>> the default and -m32 and -mx32 as options.
>>
>> i hope this helps.
>>
>>>
>>>
>>> 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


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