tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: aarch64 gcc kernel compilation



On 16.07.2018 11:07, Kamil Rytarowski wrote:
> On 16.07.2018 10:50, Kamil Rytarowski wrote:
>> On 16.07.2018 00:00, Kamil Rytarowski wrote:
>>> On 15.07.2018 20:08, Christos Zoulas wrote:
>>>> Hi,
>>>>
>>>> Gcc is now working on aarch64 but the kernel does not compile because of
>>>> some idiomatic clang code that is not supported by gcc (at least gcc-6)
>>>>
>>>> To define constants, it uses:
>>>>
>>>> static const uintmax_t
>>>> FOO = __BIT(9),
>>>> BAR = FOO;
>>>>
>>>> While this is nice, specially for the debugger, it produces an error
>>>> in gcc. While fixing these is easy, gcc also complains about using the
>>>> constants as switch labels. Thus it is better to just nukem all and
>>>> rewrite them as:
>>>>
>>>> #define FOO __BIT(9)
>>>> #define BAR FOO
>>>>
>>>> Should I go ahead and do it, or there is a smarter solution?
>>>>
>>>> christos
>>>>
>>>
>>> I used to have problems to build rumpkernel aarch64 on Linux with GCC
>>> (some years ago) due to usage __uint128_t in reg.h.
>>>
>>> Can we drop it? The __uint128_t type is not used anywhere else in
>>> aarch64 subdirs.
>>>
>>> It's used in assembly in FPREG_Q0-FPREQ_Q31 in cpuswitch.S. The same
>>> optimization can be done without the usage of __uint128_t, probably just
>>> need for proper alignment of fp_reg (15).
>>
>> 16*
>>
>>>
>>> There is also some mysterious fallout that General Purpose Registers in
>>> core files are shipped with 128bit containers. It's not compatible with
>>> LLDB and requires needless generic work for no purpose.
>>>
>>> I can try to prepare a patch blindly and share with aarch64 owners.
>>>
>>
>> Looking deeper, there are various reports regarding aarch64 128-bit
>> broken support.
>>
>> "Be careful of GCC's __uint128_t. It caused us problems on a number of
>> platforms, like ARM64, ARMEL and S/390. We had to give up using it
>> because it was so buggy. For example, GCC calculated the result of u =
>> 93 - 0 - 0 - 0 (using the 128-bit types) as 18446744073709551615 on ARM64"
>>
>> https://stackoverflow.com/questions/11656241/how-to-print-uint128-t-number-using-gcc
>>
>> There are no utility features for such numbers such as PRIu128, no
>> support in printf(3), snprintf(3) etc.
>>
>> I will prepare a patch for removal of this from public machine headers.
>>
> 
> I was asked to provide some links to gcc bugzilla:
> 
> https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=__int128_t
> https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=__uint128_t
> 
> My reason is unportable construct of reg.h, no utility functions for
> 128bits and alien style core files with 128bit containers for registers.
> 

This has been rejected by Martin.

Attachment: signature.asc
Description: OpenPGP digital signature



Home | Main Index | Thread Index | Old Index