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

[Lei Zhang]

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?


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