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

[Anthony G. Basile]

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