[llvm-dev] AllocateTarget for ELF objects on Darwin

Stefan Gränitz via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 4 07:38:31 PST 2018


Hello everyone

I am linking the Clang libs into my executable for JIT compilation. In
order to enable debugging the jited code on OSX via the GDB JIT
Interface, I switched the format of the in-memory object files to ELF. I
thought this target triple should do:

  Triple TT;
  TT.setTriple(sys::getProcessTriple());
  TT.setObjectFormat(llvm::Triple::ELF);

But Clang exits with an error:

  backend data layout 'e-m:e-i64:64-f80:128-n8:16:32:64-S128'
  does not match expectedtarget description
  'e-m:o-i64:64-f80:128-n8:16:32:64-S128'
  1 error generated.

The target selection is a little tricky here and I wonder if it's on
purpose or not. One solution is to add another line:

  TT.setOS(llvm::Triple::UnknownOS);

This line removes the OS info from my triple, so that the
AllocateTarget() function no longer returns a DarwinX86_64TargetInfo
from here:
https://github.com/llvm-mirror/clang/blob/71928e1dab585f336f6d0fb337969eda00ccd19c/lib/Basic/Targets.cpp#L491

The problem with DarwinX86_64TargetInfo is, that it's hard-coded for
Mach-O. It always sets the same data-layout string in the target
description:
https://github.com/llvm-mirror/clang/blob/master/lib/Basic/Targets/X86.h#L757

*** This causes the above error. Can anyone explain this behavior? Is
there anyone possibly relying on it? ***

My impression is that one of these points should be changed. Either the
branch to DarwinX86_64TargetInfo
from: Triple.isOSDarwin() || Triple.isOSBinFormatMachO()
to:   Triple.isOSDarwin() && Triple.isOSBinFormatMachO()

Or DarwinX86_64TargetInfo itself should respect the object format:

if (T.isOSBinFormatMachO())
  resetDataLayout("e-m:o-i64:64-f80:128-n8:16:32:64-S128");
else
  resetDataLayout("e-m:e-i64:64-f80:128-n8:16:32:64-S128");

My workaround to set OS to Unknown will cause the AllocateTarget()
function to fall back to the generic X86_64TargetInfo, which also sets
the correct data-layout and avoids the above error.

Best
Stefan

-- 
https://weliveindetail.github.io/blog/
https://cryptup.org/pub/stefan.graenitz@gmail.com




More information about the llvm-dev mailing list