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.
Attachment:
signature.asc
Description: OpenPGP digital signature