[PATCH] D88389: [M68K] (Patch 3/8) Basic infrastructures and changes on object file encoding

Tue Sep 29 19:11:31 PDT 2020

jrtc27 added a comment.

Why M680x0? Everyone knows it as m68k or 68k and that's what's in the triple, so surely M68K would be the logical target choice?

================
Comment at: llvm/cmake/modules/HandleLLVMOptions.cmake:326-330
+# GCC m68k on Linux by default aligns on 16bit, we want 32
+if(LLVM_INFERRED_HOST_TRIPLE STREQUAL "m68k-unknown-linux-gnu")
+    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -malign-int")
+    set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -malign-int")
+endif()
----------------
This is a non-standard ABI and thus is incompatible with system libraries, so IMO is a blocker to merging a native m68k LLVM build. You can still merge cross-compilation support without this though.

================
Comment at: llvm/include/llvm/Object/ELFObjectFile.h:1094
+    case ELF::EM_68K:
+      return "ELF32-M680x0";
     case ELF::EM_386:
----------------
This gets reported in the `file format` line of llvm-objdump so should match what binutils has, which is `elf32-m68k`, though even if that weren't the case it should at least be in keeping with the style of all the others here.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88389/new/

https://reviews.llvm.org/D88389