search

clangupc / clang-upc

Clang UPC Front-End
https://clangupc.github.io/
Other
16 stars 5 forks source link

MIPS "n32" ABI support #94

Open PHHargrove opened 8 years ago

PHHargrove commented 8 years ago

I can build clang-upc and clang-upc2c on MIPS with no problem when I target the 64-bit ABI (known as "64" to gcc and as "n64" to llvm/clang). I am currently testing clang-upc/libupc on this target, and will enter issues for any problems I may find.

This issue, however, is related to support for the "n32" ABI, and ultimately for multilib.

There are two 32-bit ABIs for MIPS, known as "o32" and "n32". The "n32" ABI is for ILP32 on 64-bit hardware. It is roughly the same concept as the "x32" ABI for x86-64 CPUs. Like x32, it uses 64-bit registers for the 8-byte integer types. This means that this ABI can (and gcc does) support 8-byte atomic operations:

$ gcc -mabi=n32 -dM -E ~/empty.c | grep SYNC
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1

So, I would expect therefore to be able to build libupc, but cannot. The problem is that it seems I need the be able to do either one of two impossible things:

  1. Build clang to produce n32 output by default
  2. Pass "-mabi=32" to clang when it is building libupc

Regarding option 1 (default clang output): I have found that setting LLVM_DEFAULT_TARGET_TRIPLE=mips64el-linux-gnu or LLVM_DEFAULT_TARGET_TRIPLE=mipsel-linux-gnu lets me get a clang-3.8 that generates either "n64" or "o32" output by default. However, I do not see a way to make clang target the "n32" ABI by default.

Regarding option 2 (pass options to clang when building libupc): This is probably (at least near to) the right approach, but I don't see any setting to pass compiler flags. All I can see is logic for automatically picking "-m64" and "-m32" for multilib cases. It is possible I am missing something, as I seem to see evidence that the "x32" ABI is supported.

nenadv commented 8 years ago

We did add multilib support for libupc last year. See #74. But, in this case, we need to go an extra step and generate additional libraries to separate o32 and n32. And make sure that driver picks up the right libraries.