[libc] i386 support

[nickdesaulniers]

In order to incorporate llvm-libc into Android, we MUST to support 32b x86.

Currently, the most immediate build failure with -m32 is:

In file included from external/llvm-libc/test/UnitTest/LibcTest.cpp:9:
In file included from external/llvm-libc/test/UnitTest/LibcTest.h:28:
In file included from external/llvm-libc/src/__support/CPP/string.h:14:
In file included from external/llvm-libc/src/string/memory_utils/inline_memcpy.h:22:
external/llvm-libc/src/string/memory_utils/x86_64/inline_memcpy.h:195:22: error: no member named 'K_AVX' in namespace '
llvmlibc::x86'
  195 |   if constexpr (x86::K_AVX) {
      |                 ~~~~~^
external/llvm-libc/src/string/memory_utils/x86_64/inline_memcpy.h:214:17: error: no member named 'Memcpy' in namespace 
'llvmlibc::x86'
  214 |     return x86::Memcpy::repmovsb(dst, src, count);
      |            ~~~~~^
external/llvm-libc/src/string/memory_utils/x86_64/inline_memcpy.h:219:19: error: no member named 'Memcpy' in namespace 
'llvmlibc::x86'
  219 |       return x86::Memcpy::repmovsb(dst, src, count);
      |              ~~~~~^

This is because x86::K_AVX is only defined when LIBC_TARGET_ARCH_IS_X86_64 is, which is 64b only. We probably need more preprocessor guards using LIBC_TARGET_ARCH_IS_X86_64 (64b vs 32b).

(There may be more build or runtime failures)

cc @gchatelet @enh-google

It will be less work for us to support 32b x86 then for Android to drop 32b x86 support.

[llvmbot]

@llvm/issue-subscribers-libc

Author: Nick Desaulniers (paternity leave) (nickdesaulniers)

In order to incorporate llvm-libc into Android, we MUST to support 32b x86.

Currently, the most immediate build failure with -m32 is:

In file included from external/llvm-libc/test/UnitTest/LibcTest.cpp:9:
In file included from external/llvm-libc/test/UnitTest/LibcTest.h:28:
In file included from external/llvm-libc/src/__support/CPP/string.h:14:
In file included from external/llvm-libc/src/string/memory_utils/inline_memcpy.h:22:
external/llvm-libc/src/string/memory_utils/x86_64/inline_memcpy.h:195:22: error: no member named 'K_AVX' in namespace '
llvmlibc::x86'
  195 |   if constexpr (x86::K_AVX) {
      |                 ~~~~~^
external/llvm-libc/src/string/memory_utils/x86_64/inline_memcpy.h:214:17: error: no member named 'Memcpy' in namespace 
'llvmlibc::x86'
  214 |     return x86::Memcpy::repmovsb(dst, src, count);
      |            ~~~~~^
external/llvm-libc/src/string/memory_utils/x86_64/inline_memcpy.h:219:19: error: no member named 'Memcpy' in namespace 
'llvmlibc::x86'
  219 |       return x86::Memcpy::repmovsb(dst, src, count);
      |              ~~~~~^

This is because x86::K_AVX is only defined when LIBC_TARGET_ARCH_IS_X86_64 is, which is 64b only. We probably need more preprocessor guards using LIBC_TARGET_ARCH_IS_X86_64 (64b vs 32b).

(There may be more build or runtime failures)

cc @gchatelet @enh-google

It will be less work for us to support 32b x86 then for Android to drop 32b x86 support.

[enh-google]

In order to incorporate llvm-libc into Android, we MUST to support 32b x86.

is that true? the example you show is a test suite dependency, not an actual libc one...

[gchatelet]

In order to incorporate llvm-libc into Android, we MUST to support 32b x86.

is that true? the example you show is a test suite dependency, not an actual libc one...

The example above is LLVM libc failing to build with -m32. It may seem that the error is coming from LibcTest (which is our equivalent of Google Test) but the failure comes from inline_memcpy.h which is used to implement memcpy. So, yes, LLVM libc is currently not building with -m32. As @nickdesaulniers said though, it's just a macro definition away from working (as far as this error is concerned). I'll prepare a fix.

[gchatelet]

Looking at the remaining places where we have reference to LIBC_TARGET_ARCH_IS_X86_64 instead of LIBC_TARGET_ARCH_IS_X86 (not counting legitimate uses, #93791 and #93790)

% git grep -n LIBC_TARGET_ARCH_IS_X86_64
config/linux/app.h:38:#if defined(LIBC_TARGET_ARCH_IS_X86_64) ||                                     \
src/__support/OSUtil/linux/syscall.h:16:#ifdef LIBC_TARGET_ARCH_IS_X86_64
src/__support/threads/linux/thread.cpp:61:#elif defined(LIBC_TARGET_ARCH_IS_X86_64)
src/__support/threads/linux/thread.cpp:159:#ifdef LIBC_TARGET_ARCH_IS_X86_64
src/__support/threads/linux/thread.cpp:298:#if defined(LIBC_TARGET_ARCH_IS_X86_64)
src/__support/threads/thread.h:43:     defined(LIBC_TARGET_ARCH_IS_X86_64) ||                                    \
src/setjmp/x86_64/longjmp.cpp:12:#if !defined(LIBC_TARGET_ARCH_IS_X86_64)
src/setjmp/x86_64/setjmp.cpp:12:#if !defined(LIBC_TARGET_ARCH_IS_X86_64)
src/threads/linux/Futex.h:17:     defined(LIBC_TARGET_ARCH_IS_X86_64))
test/src/sys/utsname/uname_test.cpp:21:#ifdef LIBC_TARGET_ARCH_IS_X86_64

It seems we have additional work to do around syscall, setjmp, threading, TLSImage (config/linux/app.h).

[nickdesaulniers]

It seems we have additional work to do around syscall,

Indeed, with #93790 applied, the next issue that I encounter is:

In file included from external/llvm-libc/test/UnitTest/TestLogger.cpp:4:
In file included from external/llvm-libc/src/__support/OSUtil/io.h:19:
In file included from external/llvm-libc/src/__support/OSUtil/linux/io.h:13:
external/llvm-libc/src/__support/OSUtil/linux/syscall.h:31:37: error: no matching function for call to 'syscall_impl'
   31 |   return cpp::bit_or_static_cast<R>(syscall_impl(__number, (long)ts...));
      |                                     ^~~~~~~~~~~~
external/llvm-libc/src/__support/OSUtil/linux/io.h:20:19: note: in instantiation of function template specialization 'llvmlibc::syscall_impl<long, int, const char *, unsigned int>' requested here                                       
   20 |   LIBC_NAMESPACE::syscall_impl<long>(SYS_write, 2 /* stderr */, msg.data(),
      |                   ^
external/llvm-libc/src/__support/OSUtil/linux/syscall.h:29:15: note: candidate template ignored: couldn't infer template argument 'R'                                                                                                     
   29 | LIBC_INLINE R syscall_impl(long __number, Ts... ts) {
      |               ^

[nickdesaulniers]

blocker: #110894

[nickdesaulniers]

Going through some of the issues now:

• long double (96b) float to string conversion: [llvm-libc] support for 96b long double (i386) #110894
• startup code
• stack alignment
• fenv_t
• syscall
• signal stack sizes
• jmp_buf
• clone result reg/thread start
• hermetic tests not compiling as 32b