[LLVMdev] [RFC PATCH] X32 ABI support for Clang/compiler-rt
225 views
Skip to first unread message
Steven Newbury
Aug 22, 2013, 2:04:55 AM8/22/13
to llv...@cs.uiuc.edu
Hi,
I'm working on bringing up complete coverage for a Gentoo x32 "desktop"
system. I've been cooking up quite a few patches for various packages
to push upstream, but right now, the biggest blocker is the lack of
support for building with/codegen targeting x32 in llvm/clang. Since
the x32 patches were sent last year, I see support code has landed in
LLVM, and basic handling of 32-bit pointers in Clang, but no
elf32_x86_64 codegen or support for the -mx32 switch. I've been trying
to get x32 ABI support working in Clang and compiler-rt, I based off the
previous clang patch, bringing it up to date with the changes in trunk,
and hacked together handling of x32 "ARCH" support for compiler-rt.
(there must be a better way??)
Unfortunately, although the build succeeds as far as beginning to build
compiler-rt the resulting clang doesn't seem to respect the fact that
the target is x86_64-pc-linux-gnux32, nor that the "-mx32" opt has been
supplied. Something is clearly missing.
Can somebody please take a look at the patches, and look to see what I'm
missing/where I've gone wrong, or otherwise point me to a working
patchset/repo if I'm duplicating effort.
Patches to follow...
_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
I'm working on bringing up complete coverage for a Gentoo x32 "desktop"
system. I've been cooking up quite a few patches for various packages
to push upstream, but right now, the biggest blocker is the lack of
support for building with/codegen targeting x32 in llvm/clang. Since
the x32 patches were sent last year, I see support code has landed in
LLVM, and basic handling of 32-bit pointers in Clang, but no
elf32_x86_64 codegen or support for the -mx32 switch. I've been trying
to get x32 ABI support working in Clang and compiler-rt, I based off the
previous clang patch, bringing it up to date with the changes in trunk,
and hacked together handling of x32 "ARCH" support for compiler-rt.
(there must be a better way??)
Unfortunately, although the build succeeds as far as beginning to build
compiler-rt the resulting clang doesn't seem to respect the fact that
the target is x86_64-pc-linux-gnux32, nor that the "-mx32" opt has been
supplied. Something is clearly missing.
Can somebody please take a look at the patches, and look to see what I'm
missing/where I've gone wrong, or otherwise point me to a working
patchset/repo if I'm duplicating effort.
Patches to follow...
_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Steven Newbury
Aug 22, 2013, 2:07:38 AM8/22/13
to llv...@cs.uiuc.edu
Clang patch for X32 support. Applies against current trunk.
--- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16
21:51:51.286129820 +0000
+++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16
21:53:24.875004239 +0000
@@ -841,6 +841,7 @@
HelpText<"Enable hexagon-qdsp6 backward compatibility">;
def m3dnowa : Flag<["-"], "m3dnowa">, Group<m_x86_Features_Group>;
def m3dnow : Flag<["-"], "m3dnow">, Group<m_x86_Features_Group>;
+def mx32 : Flag<["-"], "mx32">, Group<m_Group>, Flags<[DriverOption]>;
def m64 : Flag<["-"], "m64">, Group<m_Group>, Flags<[DriverOption]>;
def mabi_EQ : Joined<["-"], "mabi=">, Group<m_Group>;
def march_EQ : Joined<["-"], "march=">, Group<m_Group>;
--- ./tools/clang/lib/Driver/Driver.cpp.orig
+++ ./tools/clang/lib/Driver/Driver.cpp
@@ -1700,6 +1700,9 @@ static llvm::Triple computeTargetTriple(StringRef
DefaultTargetTriple,
if (Target.getArch() == llvm::Triple::ppc)
Target.setArch(llvm::Triple::ppc64);
}
+ } else if (Args.getLastArg(options::OPT_mx32)) {
+ if (Target.getArch() == llvm::Triple::x86_64)
+ Target.setEnvironment(llvm::Triple::GNUX32);
}
return Target;
--- ./tools/clang/lib/Basic/Targets.cpp.orig 2013-08-18
12:00:04.501402572 +0000
+++ ./tools/clang/lib/Basic/Targets.cpp 2013-08-18 12:08:11.086175660
+0000
@@ -2384,6 +2384,14 @@
Builder.defineMacro("__amd64");
Builder.defineMacro("__x86_64");
Builder.defineMacro("__x86_64__");
+ if (PointerWidth == 64 && getLongWidth() == 64) {
+ Builder.defineMacro("_LP64");
+ Builder.defineMacro("__LP64__");
+ } else if (PointerWidth == 32 && getLongWidth() == 32 &&
+ getIntWidth() == 32) {
+ Builder.defineMacro("_ILP32");
+ Builder.defineMacro("__ILP32__");
+ }
} else {
DefineStd(Builder, "i386", Opts);
}
@@ -3013,20 +3021,31 @@
class X86_64TargetInfo : public X86TargetInfo {
public:
X86_64TargetInfo(const llvm::Triple &Triple) : X86TargetInfo(Triple)
{
- LongWidth = LongAlign = PointerWidth = PointerAlign = 64;
+ const bool IsX32 = (getTriple().getEnvironment() ==
llvm::Triple::GNUX32);
+ LongWidth = LongAlign = PointerWidth = PointerAlign = IsX32 ? 32 :
64;
LongDoubleWidth = 128;
LongDoubleAlign = 128;
LargeArrayMinWidth = 128;
LargeArrayAlign = 128;
SuitableAlign = 128;
- IntMaxType = SignedLong;
- UIntMaxType = UnsignedLong;
- Int64Type = SignedLong;
+ if (IsX32) {
+ SizeType = UnsignedInt;
+ PtrDiffType = SignedInt;
+ IntPtrType = SignedInt;
+ } else {
+ IntMaxType = SignedLong;
+ UIntMaxType = UnsignedLong;
+ Int64Type = SignedLong;
+ }
RegParmMax = 6;
- DescriptionString =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-"
-
"i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-"
-
"a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128";
+ DescriptionString = IsX32 ?
+ "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-"
+ "i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-"
+ "a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" :
+ "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-"
+ "i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-"
+ "a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128";
// Use fpret only for long double.
RealTypeUsesObjCFPRet = (1 << TargetInfo::LongDouble);
--- ./tools/clang/lib/Driver/ToolChains.h.orig 2013-08-18
13:38:36.158022094 +0000
+++ ./tools/clang/lib/Driver/ToolChains.h 2013-08-18 13:39:12.822210498
+0000
@@ -121,7 +121,7 @@
SmallVectorImpl<StringRef> &BiarchLibDirs,
SmallVectorImpl<StringRef>
&BiarchTripleAliases);
- void ScanLibDirForGCCTriple(llvm::Triple::ArchType TargetArch,
+ void ScanLibDirForGCCTriple(llvm::Triple TargetTriple,
const llvm::opt::ArgList &Args,
const std::string &LibDir,
StringRef CandidateTriple,
--- ./tools/clang/lib/Driver/Tools.cpp.orig 2013-08-18
13:35:35.783789840 +0000
+++ ./tools/clang/lib/Driver/Tools.cpp 2013-08-18 13:42:18.806549941
+0000
@@ -6045,6 +6045,8 @@
ToolChain.getArch() == llvm::Triple::ppc64le ||
ToolChain.getArch() == llvm::Triple::systemz)
return "/lib64/ld64.so.1";
+ else if (ToolChain.getTriple().getEnvironment() ==
llvm::Triple::GNUX32)
+ return "/libx32/ld-linux-x32.so.2";
else
return "/lib64/ld-linux-x86-64.so.2";
}
@@ -6125,8 +6127,12 @@
}
else if (ToolChain.getArch() == llvm::Triple::systemz)
CmdArgs.push_back("elf64_s390");
- else
- CmdArgs.push_back("elf_x86_64");
+ else if (ToolChain.getArch() == llvm::Triple::x86_64)
+ CmdArgs.push_back(ToolChain.getTriple().getEnvironment() ==
+ llvm::Triple::GNUX32
+ ? "elf32_x86_64" : "elf_x86_64");
+ else
+ llvm_unreachable("unknown arch");
if (Args.hasArg(options::OPT_static)) {
if (ToolChain.getArch() == llvm::Triple::arm
--- ./tools/clang/lib/Driver/ToolChains.cpp.orig 2013-08-18
14:18:42.527568969 +0000
+++ ./tools/clang/lib/Driver/ToolChains.cpp 2013-08-18
14:20:41.647025183 +0000
@@ -998,7 +998,6 @@
llvm::Triple BiarchVariantTriple =
TargetTriple.isArch32Bit() ? TargetTriple.get64BitArchVariant()
: TargetTriple.get32BitArchVariant();
- llvm::Triple::ArchType TargetArch = TargetTriple.getArch();
// The library directories which may contain GCC installations.
SmallVector<StringRef, 4> CandidateLibDirs, CandidateBiarchLibDirs;
// The compatible GCC triples for this particular architecture.
@@ -1035,7 +1034,7 @@
if (!llvm::sys::fs::exists(LibDir))
continue;
for (unsigned k = 0, ke = CandidateTripleAliases.size(); k < ke;
++k)
- ScanLibDirForGCCTriple(TargetArch, Args, LibDir,
+ ScanLibDirForGCCTriple(TargetTriple, Args, LibDir,
CandidateTripleAliases[k]);
}
for (unsigned j = 0, je = CandidateBiarchLibDirs.size(); j < je;
++j) {
@@ -1044,7 +1043,7 @@
continue;
for (unsigned k = 0, ke = CandidateBiarchTripleAliases.size(); k
< ke;
++k)
- ScanLibDirForGCCTriple(TargetArch, Args, LibDir,
+ ScanLibDirForGCCTriple(TargetTriple, Args, LibDir,
CandidateBiarchTripleAliases[k],
/*NeedsBiarchSuffix=*/ true);
}
@@ -1321,6 +1351,7 @@
}
static bool findTargetBiarchSuffix(std::string &Suffix, StringRef Path,
+ llvm::Triple TargetTriple,
llvm::Triple::ArchType TargetArch,
const ArgList &Args) {
// FIXME: This routine was only intended to model bi-arch toolchains
which
@@ -1351,6 +1382,8 @@
TargetArch == llvm::Triple::ppc64 ||
TargetArch == llvm::Triple::systemz)
Suffix = "/64";
+ else if (TargetTriple.getEnvironment() == llvm::Triple::GNUX32)
+ Suffix = "/x32";
else
Suffix = "/32";
@@ -1358,9 +1391,10 @@
}
void Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple(
- llvm::Triple::ArchType TargetArch, const ArgList &Args,
+ llvm::Triple TargetTriple, const ArgList &Args,
const std::string &LibDir, StringRef CandidateTriple,
bool NeedsBiarchSuffix) {
+ llvm::Triple::ArchType TargetArch = TargetTriple.getArch();
// There are various different suffixes involving the triple we
// check for. We also record what is necessary to walk from each back
// up to the lib directory.
@@ -1413,7 +1447,7 @@
// crtbegin.o without the subdirectory.
std::string BiarchSuffix;
- if (findTargetBiarchSuffix(BiarchSuffix, LI->path(), TargetArch,
Args)) {
+ if (findTargetBiarchSuffix(BiarchSuffix, LI->path(),
TargetTriple, TargetArch, Args)) {
GCCBiarchSuffix = BiarchSuffix;
} else {
if (NeedsBiarchSuffix ||
@@ -2186,8 +2220,9 @@
static StringRef getMultilibDir(const llvm::Triple &Triple,
const ArgList &Args) {
+ const bool IsX32 = Triple.getEnvironment() == llvm::Triple::GNUX32;
if (!isMipsArch(Triple.getArch()))
- return Triple.isArch32Bit() ? "lib32" : "lib64";
+ return Triple.isArch32Bit() ? "lib32" : IsX32 ? "libx32" : "lib64";
// lib32 directory has a special meaning on MIPS targets.
// It contains N32 ABI binaries. Use this folder if produce
--- ./lib/Target/X86/X86JITInfo.cpp.orig 2013-08-19 11:38:44.998820677
+0000
+++ ./lib/Target/X86/X86JITInfo.cpp 2013-08-19 11:39:14.769549714 +0000
@@ -396,6 +396,7 @@
// PC-relative branch instead of loading the actual address. (This
is
// considerably shorter than the 64-bit immediate load already
there.)
// We assume here intptr_t is 64 bits.
+#if defined (__LP64__)
intptr_t diff = NewVal-RetAddr+7;
if (diff >= -2147483648LL && diff <= 2147483647LL) {
*(unsigned char*)(RetAddr-0xc) = 0xE9;
@@ -405,6 +406,11 @@
((unsigned char*)RetAddr)[0] = (2 | (4 << 3) | (3 << 6));
}
sys::ValgrindDiscardTranslations((void*)(RetAddr-0xc), 0xd);
+#else // If intptr_t is only 32 bits, always use a PC-relative branch.
+ *(unsigned char*)(RetAddr-0xc) = 0xE9;
+ *(intptr_t *)(RetAddr-0xb) = NewVal-RetAddr+7;
+ sys::ValgrindDiscardTranslations((void*)(RetAddr-0xc), 0xd);
+#endif
#else
((unsigned char*)RetAddr)[-1] = 0xE9;
sys::ValgrindDiscardTranslations((void*)(RetAddr-1), 5);
@@ -442,7 +448,7 @@
void *X86JITInfo::emitGlobalValueIndirectSym(const GlobalValue* GV,
void *ptr,
JITCodeEmitter &JCE) {
-#if defined (X86_64_JIT)
+#if defined (X86_64_JIT) && defined (__LP64__)
const unsigned Alignment = 8;
uint8_t Buffer[8];
uint8_t *Cur = Buffer;
@@ -481,7 +487,7 @@
JCE.emitAlignment(4);
void *Result = (void*)JCE.getCurrentPCValue();
if (NotCC) {
-#if defined (X86_64_JIT)
+#if defined (X86_64_JIT) && defined (__LP64__)
JCE.emitByte(0x49); // REX prefix
JCE.emitByte(0xB8+2); // movabsq r10
JCE.emitWordLE((unsigned)(intptr_t)Target);
@@ -496,7 +502,7 @@
return Result;
}
-#if defined (X86_64_JIT)
+#if defined (X86_64_JIT) && defined (__LP64__)
JCE.emitByte(0x49); // REX prefix
JCE.emitByte(0xB8+2); // movabsq r10
JCE.emitWordLE((unsigned)(intptr_t)Target);
--- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16
21:51:51.286129820 +0000
+++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16
21:53:24.875004239 +0000
@@ -841,6 +841,7 @@
HelpText<"Enable hexagon-qdsp6 backward compatibility">;
def m3dnowa : Flag<["-"], "m3dnowa">, Group<m_x86_Features_Group>;
def m3dnow : Flag<["-"], "m3dnow">, Group<m_x86_Features_Group>;
+def mx32 : Flag<["-"], "mx32">, Group<m_Group>, Flags<[DriverOption]>;
def m64 : Flag<["-"], "m64">, Group<m_Group>, Flags<[DriverOption]>;
def mabi_EQ : Joined<["-"], "mabi=">, Group<m_Group>;
def march_EQ : Joined<["-"], "march=">, Group<m_Group>;
--- ./tools/clang/lib/Driver/Driver.cpp.orig
+++ ./tools/clang/lib/Driver/Driver.cpp
@@ -1700,6 +1700,9 @@ static llvm::Triple computeTargetTriple(StringRef
DefaultTargetTriple,
if (Target.getArch() == llvm::Triple::ppc)
Target.setArch(llvm::Triple::ppc64);
}
+ } else if (Args.getLastArg(options::OPT_mx32)) {
+ if (Target.getArch() == llvm::Triple::x86_64)
+ Target.setEnvironment(llvm::Triple::GNUX32);
}
return Target;
--- ./tools/clang/lib/Basic/Targets.cpp.orig 2013-08-18
12:00:04.501402572 +0000
+++ ./tools/clang/lib/Basic/Targets.cpp 2013-08-18 12:08:11.086175660
+0000
@@ -2384,6 +2384,14 @@
Builder.defineMacro("__amd64");
Builder.defineMacro("__x86_64");
Builder.defineMacro("__x86_64__");
+ if (PointerWidth == 64 && getLongWidth() == 64) {
+ Builder.defineMacro("_LP64");
+ Builder.defineMacro("__LP64__");
+ } else if (PointerWidth == 32 && getLongWidth() == 32 &&
+ getIntWidth() == 32) {
+ Builder.defineMacro("_ILP32");
+ Builder.defineMacro("__ILP32__");
+ }
} else {
DefineStd(Builder, "i386", Opts);
}
@@ -3013,20 +3021,31 @@
class X86_64TargetInfo : public X86TargetInfo {
public:
X86_64TargetInfo(const llvm::Triple &Triple) : X86TargetInfo(Triple)
{
- LongWidth = LongAlign = PointerWidth = PointerAlign = 64;
+ const bool IsX32 = (getTriple().getEnvironment() ==
llvm::Triple::GNUX32);
+ LongWidth = LongAlign = PointerWidth = PointerAlign = IsX32 ? 32 :
64;
LongDoubleWidth = 128;
LongDoubleAlign = 128;
LargeArrayMinWidth = 128;
LargeArrayAlign = 128;
SuitableAlign = 128;
- IntMaxType = SignedLong;
- UIntMaxType = UnsignedLong;
- Int64Type = SignedLong;
+ if (IsX32) {
+ SizeType = UnsignedInt;
+ PtrDiffType = SignedInt;
+ IntPtrType = SignedInt;
+ } else {
+ IntMaxType = SignedLong;
+ UIntMaxType = UnsignedLong;
+ Int64Type = SignedLong;
+ }
RegParmMax = 6;
- DescriptionString =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-"
-
"i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-"
-
"a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128";
+ DescriptionString = IsX32 ?
+ "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-"
+ "i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-"
+ "a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" :
+ "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-"
+ "i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-"
+ "a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128";
// Use fpret only for long double.
RealTypeUsesObjCFPRet = (1 << TargetInfo::LongDouble);
--- ./tools/clang/lib/Driver/ToolChains.h.orig 2013-08-18
13:38:36.158022094 +0000
+++ ./tools/clang/lib/Driver/ToolChains.h 2013-08-18 13:39:12.822210498
+0000
@@ -121,7 +121,7 @@
SmallVectorImpl<StringRef> &BiarchLibDirs,
SmallVectorImpl<StringRef>
&BiarchTripleAliases);
- void ScanLibDirForGCCTriple(llvm::Triple::ArchType TargetArch,
+ void ScanLibDirForGCCTriple(llvm::Triple TargetTriple,
const llvm::opt::ArgList &Args,
const std::string &LibDir,
StringRef CandidateTriple,
--- ./tools/clang/lib/Driver/Tools.cpp.orig 2013-08-18
13:35:35.783789840 +0000
+++ ./tools/clang/lib/Driver/Tools.cpp 2013-08-18 13:42:18.806549941
+0000
@@ -6045,6 +6045,8 @@
ToolChain.getArch() == llvm::Triple::ppc64le ||
ToolChain.getArch() == llvm::Triple::systemz)
return "/lib64/ld64.so.1";
+ else if (ToolChain.getTriple().getEnvironment() ==
llvm::Triple::GNUX32)
+ return "/libx32/ld-linux-x32.so.2";
else
return "/lib64/ld-linux-x86-64.so.2";
}
@@ -6125,8 +6127,12 @@
}
else if (ToolChain.getArch() == llvm::Triple::systemz)
CmdArgs.push_back("elf64_s390");
- else
- CmdArgs.push_back("elf_x86_64");
+ else if (ToolChain.getArch() == llvm::Triple::x86_64)
+ CmdArgs.push_back(ToolChain.getTriple().getEnvironment() ==
+ llvm::Triple::GNUX32
+ ? "elf32_x86_64" : "elf_x86_64");
+ else
+ llvm_unreachable("unknown arch");
if (Args.hasArg(options::OPT_static)) {
if (ToolChain.getArch() == llvm::Triple::arm
--- ./tools/clang/lib/Driver/ToolChains.cpp.orig 2013-08-18
14:18:42.527568969 +0000
+++ ./tools/clang/lib/Driver/ToolChains.cpp 2013-08-18
14:20:41.647025183 +0000
@@ -998,7 +998,6 @@
llvm::Triple BiarchVariantTriple =
TargetTriple.isArch32Bit() ? TargetTriple.get64BitArchVariant()
: TargetTriple.get32BitArchVariant();
- llvm::Triple::ArchType TargetArch = TargetTriple.getArch();
// The library directories which may contain GCC installations.
SmallVector<StringRef, 4> CandidateLibDirs, CandidateBiarchLibDirs;
// The compatible GCC triples for this particular architecture.
@@ -1035,7 +1034,7 @@
if (!llvm::sys::fs::exists(LibDir))
continue;
for (unsigned k = 0, ke = CandidateTripleAliases.size(); k < ke;
++k)
- ScanLibDirForGCCTriple(TargetArch, Args, LibDir,
+ ScanLibDirForGCCTriple(TargetTriple, Args, LibDir,
CandidateTripleAliases[k]);
}
for (unsigned j = 0, je = CandidateBiarchLibDirs.size(); j < je;
++j) {
@@ -1044,7 +1043,7 @@
continue;
for (unsigned k = 0, ke = CandidateBiarchTripleAliases.size(); k
< ke;
++k)
- ScanLibDirForGCCTriple(TargetArch, Args, LibDir,
+ ScanLibDirForGCCTriple(TargetTriple, Args, LibDir,
CandidateBiarchTripleAliases[k],
/*NeedsBiarchSuffix=*/ true);
}
@@ -1321,6 +1351,7 @@
}
static bool findTargetBiarchSuffix(std::string &Suffix, StringRef Path,
+ llvm::Triple TargetTriple,
llvm::Triple::ArchType TargetArch,
const ArgList &Args) {
// FIXME: This routine was only intended to model bi-arch toolchains
which
@@ -1351,6 +1382,8 @@
TargetArch == llvm::Triple::ppc64 ||
TargetArch == llvm::Triple::systemz)
Suffix = "/64";
+ else if (TargetTriple.getEnvironment() == llvm::Triple::GNUX32)
+ Suffix = "/x32";
else
Suffix = "/32";
@@ -1358,9 +1391,10 @@
}
void Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple(
- llvm::Triple::ArchType TargetArch, const ArgList &Args,
+ llvm::Triple TargetTriple, const ArgList &Args,
const std::string &LibDir, StringRef CandidateTriple,
bool NeedsBiarchSuffix) {
+ llvm::Triple::ArchType TargetArch = TargetTriple.getArch();
// There are various different suffixes involving the triple we
// check for. We also record what is necessary to walk from each back
// up to the lib directory.
@@ -1413,7 +1447,7 @@
// crtbegin.o without the subdirectory.
std::string BiarchSuffix;
- if (findTargetBiarchSuffix(BiarchSuffix, LI->path(), TargetArch,
Args)) {
+ if (findTargetBiarchSuffix(BiarchSuffix, LI->path(),
TargetTriple, TargetArch, Args)) {
GCCBiarchSuffix = BiarchSuffix;
} else {
if (NeedsBiarchSuffix ||
@@ -2186,8 +2220,9 @@
static StringRef getMultilibDir(const llvm::Triple &Triple,
const ArgList &Args) {
+ const bool IsX32 = Triple.getEnvironment() == llvm::Triple::GNUX32;
if (!isMipsArch(Triple.getArch()))
- return Triple.isArch32Bit() ? "lib32" : "lib64";
+ return Triple.isArch32Bit() ? "lib32" : IsX32 ? "libx32" : "lib64";
// lib32 directory has a special meaning on MIPS targets.
// It contains N32 ABI binaries. Use this folder if produce
--- ./lib/Target/X86/X86JITInfo.cpp.orig 2013-08-19 11:38:44.998820677
+0000
+++ ./lib/Target/X86/X86JITInfo.cpp 2013-08-19 11:39:14.769549714 +0000
@@ -396,6 +396,7 @@
// PC-relative branch instead of loading the actual address. (This
is
// considerably shorter than the 64-bit immediate load already
there.)
// We assume here intptr_t is 64 bits.
+#if defined (__LP64__)
intptr_t diff = NewVal-RetAddr+7;
if (diff >= -2147483648LL && diff <= 2147483647LL) {
*(unsigned char*)(RetAddr-0xc) = 0xE9;
@@ -405,6 +406,11 @@
((unsigned char*)RetAddr)[0] = (2 | (4 << 3) | (3 << 6));
}
sys::ValgrindDiscardTranslations((void*)(RetAddr-0xc), 0xd);
+#else // If intptr_t is only 32 bits, always use a PC-relative branch.
+ *(unsigned char*)(RetAddr-0xc) = 0xE9;
+ *(intptr_t *)(RetAddr-0xb) = NewVal-RetAddr+7;
+ sys::ValgrindDiscardTranslations((void*)(RetAddr-0xc), 0xd);
+#endif
#else
((unsigned char*)RetAddr)[-1] = 0xE9;
sys::ValgrindDiscardTranslations((void*)(RetAddr-1), 5);
@@ -442,7 +448,7 @@
void *X86JITInfo::emitGlobalValueIndirectSym(const GlobalValue* GV,
void *ptr,
JITCodeEmitter &JCE) {
-#if defined (X86_64_JIT)
+#if defined (X86_64_JIT) && defined (__LP64__)
const unsigned Alignment = 8;
uint8_t Buffer[8];
uint8_t *Cur = Buffer;
@@ -481,7 +487,7 @@
JCE.emitAlignment(4);
void *Result = (void*)JCE.getCurrentPCValue();
if (NotCC) {
-#if defined (X86_64_JIT)
+#if defined (X86_64_JIT) && defined (__LP64__)
JCE.emitByte(0x49); // REX prefix
JCE.emitByte(0xB8+2); // movabsq r10
JCE.emitWordLE((unsigned)(intptr_t)Target);
@@ -496,7 +502,7 @@
return Result;
}
-#if defined (X86_64_JIT)
+#if defined (X86_64_JIT) && defined (__LP64__)
JCE.emitByte(0x49); // REX prefix
JCE.emitByte(0xB8+2); // movabsq r10
JCE.emitWordLE((unsigned)(intptr_t)Target);
Steven Newbury
Aug 22, 2013, 2:09:30 AM8/22/13
to llv...@cs.uiuc.edu
X32 support patch for compiler-rt. Applies against current trunk.
--- projects/compiler-rt/make/platform/clang_linux.mk~ 2013-08-21
06:27:38.000000000 +0000
+++ projects/compiler-rt/make/platform/clang_linux.mk 2013-08-21
11:16:55.891621025 +0000
@@ -41,7 +41,18 @@
SupportedArches += x86_64
endif
else
- SupportedArches := x86_64
+ # x86-64 arch has two ABIs 64 bit x86-64 and 32 bit x32
+ ifeq ($(lastword $(subst -gnu, ,$(CompilerTargetTriple))),x32)
+ SupportedArches := x32
+ ifeq ($(call TryCompile,$(CC),$(test_source),-m64),0)
+ SupportedArches += x86_64
+ endif
+ else
+ SupportedArches := x86_64
+ ifeq ($(call TryCompile,$(CC),$(test_source),-mx32),0)
+ SupportedArches += x32
+ endif
+ endif
ifeq ($(call TryCompile,$(CC),$(test_source),-m32),0)
SupportedArches += i386
endif
@@ -74,6 +85,22 @@
Arch.lsan-x86_64 := x86_64
endif
+# Build runtime libraries for x32.
+ifeq ($(call contains,$(SupportedArches),x32),true)
+Configs += full-x32 profile-x32 san-x32 asan-x32 tsan-x32 \
+ msan-x32 ubsan-x32 ubsan_cxx-x32 dfsan-x32 lsan-x32
+Arch.full-x32 := x32
+Arch.profile-x32 := x32
+Arch.san-x32 := x32
+Arch.asan-x32 := x32
+Arch.tsan-x32 := x32
+Arch.msan-x32 := x32
+Arch.ubsan-x32 := x32
+Arch.ubsan_cxx-x32 := x32
+Arch.dfsan-x32 := x32
+Arch.lsan-x32 := x32
+endif
+
ifneq ($(LLVM_ANDROID_TOOLCHAIN_DIR),)
Configs += asan-arm-android
Arch.asan-arm-android := arm-android
@@ -89,22 +116,33 @@
CFLAGS.full-i386 := $(CFLAGS) -m32
CFLAGS.full-x86_64 := $(CFLAGS) -m64
+CFLAGS.full-x32 := $(CFLAGS) -mx32
CFLAGS.profile-i386 := $(CFLAGS) -m32
CFLAGS.profile-x86_64 := $(CFLAGS) -m64
+CFLAGS.profile-x32 := $(CFLAGS) -mx32
CFLAGS.san-i386 := $(CFLAGS) -m32 $(SANITIZER_CFLAGS) -fno-rtti
CFLAGS.san-x86_64 := $(CFLAGS) -m64 $(SANITIZER_CFLAGS) -fno-rtti
+CFLAGS.san-x32 := $(CFLAGS) -mx32 $(SANITIZER_CFLAGS) -fno-rtti
CFLAGS.asan-i386 := $(CFLAGS) -m32 $(SANITIZER_CFLAGS) -fno-rtti \
-DASAN_FLEXIBLE_MAPPING_AND_OFFSET=1
CFLAGS.asan-x86_64 := $(CFLAGS) -m64 $(SANITIZER_CFLAGS) -fno-rtti \
-DASAN_FLEXIBLE_MAPPING_AND_OFFSET=1
+CFLAGS.asan-x32 := $(CFLAGS) -mx32 $(SANITIZER_CFLAGS) -fno-rtti \
+ -DASAN_FLEXIBLE_MAPPING_AND_OFFSET=1
CFLAGS.tsan-x86_64 := $(CFLAGS) -m64 $(SANITIZER_CFLAGS) -fno-rtti
+CFLAGS.tsan-x32 := $(CFLAGS) -mx32 $(SANITIZER_CFLAGS) -fno-rtti
CFLAGS.msan-x86_64 := $(CFLAGS) -m64 $(SANITIZER_CFLAGS) -fno-rtti
+CFLAGS.msan-x32 := $(CFLAGS) -mx32 $(SANITIZER_CFLAGS) -fno-rtti
CFLAGS.ubsan-i386 := $(CFLAGS) -m32 $(SANITIZER_CFLAGS) -fno-rtti
CFLAGS.ubsan-x86_64 := $(CFLAGS) -m64 $(SANITIZER_CFLAGS) -fno-rtti
+CFLAGS.ubsan-x32 := $(CFLAGS) -mx32 $(SANITIZER_CFLAGS) -fno-rtti
CFLAGS.ubsan_cxx-i386 := $(CFLAGS) -m32 $(SANITIZER_CFLAGS)
CFLAGS.ubsan_cxx-x86_64 := $(CFLAGS) -m64 $(SANITIZER_CFLAGS)
+CFLAGS.ubsan_cxx-x32 := $(CFLAGS) -mx32 $(SANITIZER_CFLAGS)
CFLAGS.dfsan-x86_64 := $(CFLAGS) -m64 $(SANITIZER_CFLAGS)
+CFLAGS.dfsan-x32 := $(CFLAGS) -mx32 $(SANITIZER_CFLAGS)
CFLAGS.lsan-x86_64 := $(CFLAGS) -m64 $(SANITIZER_CFLAGS)
+CFLAGS.lsan-x32 := $(CFLAGS) -mx32 $(SANITIZER_CFLAGS)
SHARED_LIBRARY.asan-arm-android := 1
ANDROID_COMMON_FLAGS := -target arm-linux-androideabi \
@@ -120,30 +158,45 @@
# enough support to build the sanitizers or profile runtimes.
CFLAGS.full-i386 += --sysroot=$(ProjSrcRoot)/SDKs/linux
CFLAGS.full-x86_64 += --sysroot=$(ProjSrcRoot)/SDKs/linux
+CFLAGS.full-x32 += --sysroot=$(ProjSrcRoot)/SDKs/linux
FUNCTIONS.full-i386 := $(CommonFunctions) $(ArchFunctions.i386)
FUNCTIONS.full-x86_64 := $(CommonFunctions) $(ArchFunctions.x86_64)
+FUNCTIONS.full-x32 := $(CommonFunctions) $(ArchFunctions.x32)
FUNCTIONS.profile-i386 := GCDAProfiling
FUNCTIONS.profile-x86_64 := GCDAProfiling
+FUNCTIONS.profile-x32 := GCDAProfiling
FUNCTIONS.san-i386 := $(SanitizerCommonFunctions)
FUNCTIONS.san-x86_64 := $(SanitizerCommonFunctions)
+FUNCTIONS.san-x32 := $(SanitizerCommonFunctions)
FUNCTIONS.asan-i386 := $(AsanFunctions) $(InterceptionFunctions) \
$(SanitizerCommonFunctions)
FUNCTIONS.asan-x86_64 := $(AsanFunctions) $(InterceptionFunctions) \
$(SanitizerCommonFunctions)
$(LsanCommonFunctions)
+FUNCTIONS.asan-x32 := $(AsanFunctions) $(InterceptionFunctions) \
+ $(SanitizerCommonFunctions)
$(LsanCommonFunctions)
FUNCTIONS.asan-arm-android := $(AsanFunctions) $(InterceptionFunctions)
\
$(SanitizerCommonFunctions)
FUNCTIONS.tsan-x86_64 := $(TsanFunctions) $(InterceptionFunctions) \
$(SanitizerCommonFunctions)
+FUNCTIONS.tsan-x32 := $(TsanFunctions) $(InterceptionFunctions) \
+ $(SanitizerCommonFunctions)
FUNCTIONS.msan-x86_64 := $(MsanFunctions) $(InterceptionFunctions) \
$(SanitizerCommonFunctions)
+FUNCTIONS.msan-x32 := $(MsanFunctions) $(InterceptionFunctions) \
+ $(SanitizerCommonFunctions)
FUNCTIONS.ubsan-i386 := $(UbsanFunctions)
FUNCTIONS.ubsan-x86_64 := $(UbsanFunctions)
+FUNCTIONS.ubsan-x32 := $(UbsanFunctions)
FUNCTIONS.ubsan_cxx-i386 := $(UbsanCXXFunctions)
FUNCTIONS.ubsan_cxx-x86_64 := $(UbsanCXXFunctions)
+FUNCTIONS.ubsan_cxx-x32 := $(UbsanCXXFunctions)
FUNCTIONS.dfsan-x86_64 := $(DfsanFunctions) $(SanitizerCommonFunctions)
+FUNCTIONS.dfsan-x32 := $(DfsanFunctions) $(SanitizerCommonFunctions)
FUNCTIONS.lsan-x86_64 := $(LsanFunctions) $(InterceptionFunctions) \
$(SanitizerCommonFunctions)
+FUNCTIONS.lsan-x32 := $(LsanFunctions) $(InterceptionFunctions) \
+ $(SanitizerCommonFunctions)
# Always use optimized variants.
OPTIMIZED := 1
--- tools/clang/runtime/compiler-rt/Makefile.orig 2013-08-21
16:20:43.915932247 +0000
+++ tools/clang/runtime/compiler-rt/Makefile 2013-08-21
17:03:15.856154519 +0000
@@ -96,29 +96,66 @@
$(1) $$cflags $(2) -o /dev/null > /dev/null 2> /dev/null ; \
echo $$?)
-# We try to build 32-bit runtimes both on 32-bit hosts and 64-bit
hosts.
-Runtime32BitConfigs = \
+# We try to build x86 runtimes both on x86 hosts and 64-bit hosts.
+Runtimex86Configs = \
full-i386.a profile-i386.a san-i386.a asan-i386.a ubsan-i386.a \
ubsan_cxx-i386.a
+Runtime64BitConfigs = \
+ full-x86_64.a profile-x86_64.a san-x86_64.a asan-x86_64.a \
+ tsan-x86_64.a msan-x86_64.a ubsan-x86_64.a ubsan_cxx-x86_64.a \
+ dfsan-x86_64.a lsan-x86_64.a
+
+Runtimex32Configs += \
+ full-x32.a profile-x32.a san-x32.a asan-x32.a \
+ tsan-x32.a msan-x32.a ubsan-x32.a ubsan_cxx-x32.a \
+ dfsan-x32.a lsan-x32.a
+
+
# We currently only try to generate runtime libraries on x86.
ifeq ($(ARCH),x86)
-RuntimeLibrary.linux.Configs += $(Runtime32BitConfigs)
+RuntimeLibrary.linux.Configs += $(Runtimex86Configs)
+
+ifneq ($(LLVM_ANDROID_TOOLCHAIN_DIR),)
+RuntimeLibrary.linux.Configs += asan-arm-android.so
+endif
endif
ifeq ($(ARCH),x86_64)
-RuntimeLibrary.linux.Configs += \
- full-x86_64.a profile-x86_64.a san-x86_64.a asan-x86_64.a \
- tsan-x86_64.a msan-x86_64.a ubsan-x86_64.a ubsan_cxx-x86_64.a \
- dfsan-x86_64.a lsan-x86_64.a
-# We need to build 32-bit ASan/UBsan libraries on 64-bit platform, and
add them
+CompilerTargetTriple := $(shell \
+ $(CC) -v 2>&1 | grep 'Target:' | cut -d' ' -f2)
+ifeq ($(CompilerTargetTriple),)
+$(error "unable to infer compiler target triple for $(CC)")
+endif
+ifeq ($(lastword $(subst -gnu, ,$(CompilerTargetTriple))),x32)
+ARCH=x32
+RuntimeLibrary.linux.Configs += $(Runtimex32Configs)
+# We need to build x86 ASan/UBsan libraries on x32 platform, and add
them
# to the list of runtime libraries to make
-# "clang -fsanitize=(address|undefined) -m32" work.
-# We check that Clang can produce working 32-bit binaries by compiling
a simple
+# "clang -fsanitize=(address|undefined) -m32/-m64" work.
+# We check that Clang can produce working 32/64-bit binaries by
compiling a simple
# executable.
test_source =
$(LLVM_SRC_ROOT)/tools/clang/runtime/compiler-rt/clang_linux_test_input.c
+ifeq ($(call TryCompile,$(ToolDir)/clang,$(test_source),-m64),0)
+RuntimeLibrary.linux.Configs += $(Runtime64BitConfigs)
+endif
ifeq ($(call TryCompile,$(ToolDir)/clang,$(test_source),-m32),0)
-RuntimeLibrary.linux.Configs += $(Runtime32BitConfigs)
+RuntimeLibrary.linux.Configs += $(Runtimex86Configs)
+endif
+else
+RuntimeLibrary.linux.Configs += $(Runtime64BitConfigs)
+# We need to build x86/x32 ASan/UBsan libraries on 64-bit platform, and
add them
+# to the list of runtime libraries to make
+# "clang -fsanitize=(address|undefined) -m32/-mx32" work.
+# We check that Clang can produce working x86 binaries by compiling a
simple
+# executable.
+test_source =
$(LLVM_SRC_ROOT)/tools/clang/runtime/compiler-rt/clang_linux_test_input.c
+ifeq ($(call TryCompile,$(ToolDir)/clang,$(test_source),-m32),0)
+RuntimeLibrary.linux.Configs += $(Runtimex86Configs)
+endif
+ifeq ($(call TryCompile,$(ToolDir)/clang,$(test_source),-mx32),0)
+RuntimeLibrary.linux.Configs += $(Runtimex32Configs)
+endif
endif
ifneq ($(LLVM_ANDROID_TOOLCHAIN_DIR),)
RuntimeLibrary.linux.Configs += asan-arm-android.so
--- projects/compiler-rt/make/platform/clang_linux.mk~ 2013-08-21
06:27:38.000000000 +0000
+++ projects/compiler-rt/make/platform/clang_linux.mk 2013-08-21
11:16:55.891621025 +0000
@@ -41,7 +41,18 @@
SupportedArches += x86_64
endif
else
- SupportedArches := x86_64
+ # x86-64 arch has two ABIs 64 bit x86-64 and 32 bit x32
+ ifeq ($(lastword $(subst -gnu, ,$(CompilerTargetTriple))),x32)
+ SupportedArches := x32
+ ifeq ($(call TryCompile,$(CC),$(test_source),-m64),0)
+ SupportedArches += x86_64
+ endif
+ else
+ SupportedArches := x86_64
+ ifeq ($(call TryCompile,$(CC),$(test_source),-mx32),0)
+ SupportedArches += x32
+ endif
+ endif
ifeq ($(call TryCompile,$(CC),$(test_source),-m32),0)
SupportedArches += i386
endif
@@ -74,6 +85,22 @@
Arch.lsan-x86_64 := x86_64
endif
+# Build runtime libraries for x32.
+ifeq ($(call contains,$(SupportedArches),x32),true)
+Configs += full-x32 profile-x32 san-x32 asan-x32 tsan-x32 \
+ msan-x32 ubsan-x32 ubsan_cxx-x32 dfsan-x32 lsan-x32
+Arch.full-x32 := x32
+Arch.profile-x32 := x32
+Arch.san-x32 := x32
+Arch.asan-x32 := x32
+Arch.tsan-x32 := x32
+Arch.msan-x32 := x32
+Arch.ubsan-x32 := x32
+Arch.ubsan_cxx-x32 := x32
+Arch.dfsan-x32 := x32
+Arch.lsan-x32 := x32
+endif
+
ifneq ($(LLVM_ANDROID_TOOLCHAIN_DIR),)
Configs += asan-arm-android
Arch.asan-arm-android := arm-android
@@ -89,22 +116,33 @@
CFLAGS.full-i386 := $(CFLAGS) -m32
CFLAGS.full-x86_64 := $(CFLAGS) -m64
+CFLAGS.full-x32 := $(CFLAGS) -mx32
CFLAGS.profile-i386 := $(CFLAGS) -m32
CFLAGS.profile-x86_64 := $(CFLAGS) -m64
+CFLAGS.profile-x32 := $(CFLAGS) -mx32
CFLAGS.san-i386 := $(CFLAGS) -m32 $(SANITIZER_CFLAGS) -fno-rtti
CFLAGS.san-x86_64 := $(CFLAGS) -m64 $(SANITIZER_CFLAGS) -fno-rtti
+CFLAGS.san-x32 := $(CFLAGS) -mx32 $(SANITIZER_CFLAGS) -fno-rtti
CFLAGS.asan-i386 := $(CFLAGS) -m32 $(SANITIZER_CFLAGS) -fno-rtti \
-DASAN_FLEXIBLE_MAPPING_AND_OFFSET=1
CFLAGS.asan-x86_64 := $(CFLAGS) -m64 $(SANITIZER_CFLAGS) -fno-rtti \
-DASAN_FLEXIBLE_MAPPING_AND_OFFSET=1
+CFLAGS.asan-x32 := $(CFLAGS) -mx32 $(SANITIZER_CFLAGS) -fno-rtti \
+ -DASAN_FLEXIBLE_MAPPING_AND_OFFSET=1
CFLAGS.tsan-x86_64 := $(CFLAGS) -m64 $(SANITIZER_CFLAGS) -fno-rtti
+CFLAGS.tsan-x32 := $(CFLAGS) -mx32 $(SANITIZER_CFLAGS) -fno-rtti
CFLAGS.msan-x86_64 := $(CFLAGS) -m64 $(SANITIZER_CFLAGS) -fno-rtti
+CFLAGS.msan-x32 := $(CFLAGS) -mx32 $(SANITIZER_CFLAGS) -fno-rtti
CFLAGS.ubsan-i386 := $(CFLAGS) -m32 $(SANITIZER_CFLAGS) -fno-rtti
CFLAGS.ubsan-x86_64 := $(CFLAGS) -m64 $(SANITIZER_CFLAGS) -fno-rtti
+CFLAGS.ubsan-x32 := $(CFLAGS) -mx32 $(SANITIZER_CFLAGS) -fno-rtti
CFLAGS.ubsan_cxx-i386 := $(CFLAGS) -m32 $(SANITIZER_CFLAGS)
CFLAGS.ubsan_cxx-x86_64 := $(CFLAGS) -m64 $(SANITIZER_CFLAGS)
+CFLAGS.ubsan_cxx-x32 := $(CFLAGS) -mx32 $(SANITIZER_CFLAGS)
CFLAGS.dfsan-x86_64 := $(CFLAGS) -m64 $(SANITIZER_CFLAGS)
+CFLAGS.dfsan-x32 := $(CFLAGS) -mx32 $(SANITIZER_CFLAGS)
CFLAGS.lsan-x86_64 := $(CFLAGS) -m64 $(SANITIZER_CFLAGS)
+CFLAGS.lsan-x32 := $(CFLAGS) -mx32 $(SANITIZER_CFLAGS)
SHARED_LIBRARY.asan-arm-android := 1
ANDROID_COMMON_FLAGS := -target arm-linux-androideabi \
@@ -120,30 +158,45 @@
# enough support to build the sanitizers or profile runtimes.
CFLAGS.full-i386 += --sysroot=$(ProjSrcRoot)/SDKs/linux
CFLAGS.full-x86_64 += --sysroot=$(ProjSrcRoot)/SDKs/linux
+CFLAGS.full-x32 += --sysroot=$(ProjSrcRoot)/SDKs/linux
FUNCTIONS.full-i386 := $(CommonFunctions) $(ArchFunctions.i386)
FUNCTIONS.full-x86_64 := $(CommonFunctions) $(ArchFunctions.x86_64)
+FUNCTIONS.full-x32 := $(CommonFunctions) $(ArchFunctions.x32)
FUNCTIONS.profile-i386 := GCDAProfiling
FUNCTIONS.profile-x86_64 := GCDAProfiling
+FUNCTIONS.profile-x32 := GCDAProfiling
FUNCTIONS.san-i386 := $(SanitizerCommonFunctions)
FUNCTIONS.san-x86_64 := $(SanitizerCommonFunctions)
+FUNCTIONS.san-x32 := $(SanitizerCommonFunctions)
FUNCTIONS.asan-i386 := $(AsanFunctions) $(InterceptionFunctions) \
$(SanitizerCommonFunctions)
FUNCTIONS.asan-x86_64 := $(AsanFunctions) $(InterceptionFunctions) \
$(SanitizerCommonFunctions)
$(LsanCommonFunctions)
+FUNCTIONS.asan-x32 := $(AsanFunctions) $(InterceptionFunctions) \
+ $(SanitizerCommonFunctions)
$(LsanCommonFunctions)
FUNCTIONS.asan-arm-android := $(AsanFunctions) $(InterceptionFunctions)
\
$(SanitizerCommonFunctions)
FUNCTIONS.tsan-x86_64 := $(TsanFunctions) $(InterceptionFunctions) \
$(SanitizerCommonFunctions)
+FUNCTIONS.tsan-x32 := $(TsanFunctions) $(InterceptionFunctions) \
+ $(SanitizerCommonFunctions)
FUNCTIONS.msan-x86_64 := $(MsanFunctions) $(InterceptionFunctions) \
$(SanitizerCommonFunctions)
+FUNCTIONS.msan-x32 := $(MsanFunctions) $(InterceptionFunctions) \
+ $(SanitizerCommonFunctions)
FUNCTIONS.ubsan-i386 := $(UbsanFunctions)
FUNCTIONS.ubsan-x86_64 := $(UbsanFunctions)
+FUNCTIONS.ubsan-x32 := $(UbsanFunctions)
FUNCTIONS.ubsan_cxx-i386 := $(UbsanCXXFunctions)
FUNCTIONS.ubsan_cxx-x86_64 := $(UbsanCXXFunctions)
+FUNCTIONS.ubsan_cxx-x32 := $(UbsanCXXFunctions)
FUNCTIONS.dfsan-x86_64 := $(DfsanFunctions) $(SanitizerCommonFunctions)
+FUNCTIONS.dfsan-x32 := $(DfsanFunctions) $(SanitizerCommonFunctions)
FUNCTIONS.lsan-x86_64 := $(LsanFunctions) $(InterceptionFunctions) \
$(SanitizerCommonFunctions)
+FUNCTIONS.lsan-x32 := $(LsanFunctions) $(InterceptionFunctions) \
+ $(SanitizerCommonFunctions)
# Always use optimized variants.
OPTIMIZED := 1
--- tools/clang/runtime/compiler-rt/Makefile.orig 2013-08-21
16:20:43.915932247 +0000
+++ tools/clang/runtime/compiler-rt/Makefile 2013-08-21
17:03:15.856154519 +0000
@@ -96,29 +96,66 @@
$(1) $$cflags $(2) -o /dev/null > /dev/null 2> /dev/null ; \
echo $$?)
-# We try to build 32-bit runtimes both on 32-bit hosts and 64-bit
hosts.
-Runtime32BitConfigs = \
+# We try to build x86 runtimes both on x86 hosts and 64-bit hosts.
+Runtimex86Configs = \
full-i386.a profile-i386.a san-i386.a asan-i386.a ubsan-i386.a \
ubsan_cxx-i386.a
+Runtime64BitConfigs = \
+ full-x86_64.a profile-x86_64.a san-x86_64.a asan-x86_64.a \
+ tsan-x86_64.a msan-x86_64.a ubsan-x86_64.a ubsan_cxx-x86_64.a \
+ dfsan-x86_64.a lsan-x86_64.a
+
+Runtimex32Configs += \
+ full-x32.a profile-x32.a san-x32.a asan-x32.a \
+ tsan-x32.a msan-x32.a ubsan-x32.a ubsan_cxx-x32.a \
+ dfsan-x32.a lsan-x32.a
+
+
# We currently only try to generate runtime libraries on x86.
ifeq ($(ARCH),x86)
-RuntimeLibrary.linux.Configs += $(Runtime32BitConfigs)
+RuntimeLibrary.linux.Configs += $(Runtimex86Configs)
+
+ifneq ($(LLVM_ANDROID_TOOLCHAIN_DIR),)
+RuntimeLibrary.linux.Configs += asan-arm-android.so
+endif
endif
ifeq ($(ARCH),x86_64)
-RuntimeLibrary.linux.Configs += \
- full-x86_64.a profile-x86_64.a san-x86_64.a asan-x86_64.a \
- tsan-x86_64.a msan-x86_64.a ubsan-x86_64.a ubsan_cxx-x86_64.a \
- dfsan-x86_64.a lsan-x86_64.a
-# We need to build 32-bit ASan/UBsan libraries on 64-bit platform, and
add them
+CompilerTargetTriple := $(shell \
+ $(CC) -v 2>&1 | grep 'Target:' | cut -d' ' -f2)
+ifeq ($(CompilerTargetTriple),)
+$(error "unable to infer compiler target triple for $(CC)")
+endif
+ifeq ($(lastword $(subst -gnu, ,$(CompilerTargetTriple))),x32)
+ARCH=x32
+RuntimeLibrary.linux.Configs += $(Runtimex32Configs)
+# We need to build x86 ASan/UBsan libraries on x32 platform, and add
them
# to the list of runtime libraries to make
-# "clang -fsanitize=(address|undefined) -m32" work.
-# We check that Clang can produce working 32-bit binaries by compiling
a simple
+# "clang -fsanitize=(address|undefined) -m32/-m64" work.
+# We check that Clang can produce working 32/64-bit binaries by
compiling a simple
# executable.
test_source =
$(LLVM_SRC_ROOT)/tools/clang/runtime/compiler-rt/clang_linux_test_input.c
+ifeq ($(call TryCompile,$(ToolDir)/clang,$(test_source),-m64),0)
+RuntimeLibrary.linux.Configs += $(Runtime64BitConfigs)
+endif
ifeq ($(call TryCompile,$(ToolDir)/clang,$(test_source),-m32),0)
-RuntimeLibrary.linux.Configs += $(Runtime32BitConfigs)
+RuntimeLibrary.linux.Configs += $(Runtimex86Configs)
+endif
+else
+RuntimeLibrary.linux.Configs += $(Runtime64BitConfigs)
+# We need to build x86/x32 ASan/UBsan libraries on 64-bit platform, and
add them
+# to the list of runtime libraries to make
+# "clang -fsanitize=(address|undefined) -m32/-mx32" work.
+# We check that Clang can produce working x86 binaries by compiling a
simple
+# executable.
+test_source =
$(LLVM_SRC_ROOT)/tools/clang/runtime/compiler-rt/clang_linux_test_input.c
+ifeq ($(call TryCompile,$(ToolDir)/clang,$(test_source),-m32),0)
+RuntimeLibrary.linux.Configs += $(Runtimex86Configs)
+endif
+ifeq ($(call TryCompile,$(ToolDir)/clang,$(test_source),-mx32),0)
+RuntimeLibrary.linux.Configs += $(Runtimex32Configs)
+endif
endif
ifneq ($(LLVM_ANDROID_TOOLCHAIN_DIR),)
RuntimeLibrary.linux.Configs += asan-arm-android.so
Dmitri Gribenko
Aug 22, 2013, 2:54:52 AM8/22/13
to Steven Newbury, llv...@cs.uiuc.edu
On Wed, Aug 21, 2013 at 11:07 PM, Steven Newbury <st...@snewbury.org.uk> wrote:
> Clang patch for X32 support. Applies against current trunk.
Not a real review, but it seems like this change needs tests -- at
> Clang patch for X32 support. Applies against current trunk.
least driver tests, and tests for predefined macros.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <grib...@gmail.com>*/
Dmitri Gribenko
Aug 22, 2013, 2:59:14 AM8/22/13
to Steven Newbury, Clang Developers, llv...@cs.uiuc.edu
On Wed, Aug 21, 2013 at 11:04 PM, Steven Newbury <st...@snewbury.org.uk> wrote:
> I've been trying
> to get x32 ABI support working in Clang and compiler-rt, I based off the
> previous clang patch, bringing it up to date with the changes in trunk,
> and hacked together handling of x32 "ARCH" support for compiler-rt.
> (there must be a better way??)
If you are just trying to get basic things working, you don't need to
> I've been trying
> to get x32 ABI support working in Clang and compiler-rt, I based off the
> previous clang patch, bringing it up to date with the changes in trunk,
> and hacked together handling of x32 "ARCH" support for compiler-rt.
> (there must be a better way??)
port compiler-rt immediately. It is still pretty important (for
example, to support features like Address Sanitizer), but not critical
-- you will still get a useable Clang without building compiler-rt.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <grib...@gmail.com>*/
Steven Newbury
Aug 22, 2013, 3:23:07 AM8/22/13
to Dmitri Gribenko, Clang Developers, llv...@cs.uiuc.edu
On Wed, 2013-08-21 at 23:59 -0700, Dmitri Gribenko wrote:
> On Wed, Aug 21, 2013 at 11:04 PM, Steven Newbury <st...@snewbury.org.uk> wrote:
> > I've been trying
> > to get x32 ABI support working in Clang and compiler-rt, I based off the
> > previous clang patch, bringing it up to date with the changes in trunk,
> > and hacked together handling of x32 "ARCH" support for compiler-rt.
> > (there must be a better way??)
>
> If you are just trying to get basic things working, you don't need to
> port compiler-rt immediately. It is still pretty important (for
> example, to support features like Address Sanitizer), but not critical
> -- you will still get a useable Clang without building compiler-rt.
>
> Dmitri
>
Having Clang working would of course be my primary goal, that said,
> On Wed, Aug 21, 2013 at 11:04 PM, Steven Newbury <st...@snewbury.org.uk> wrote:
> > I've been trying
> > to get x32 ABI support working in Clang and compiler-rt, I based off the
> > previous clang patch, bringing it up to date with the changes in trunk,
> > and hacked together handling of x32 "ARCH" support for compiler-rt.
> > (there must be a better way??)
>
> If you are just trying to get basic things working, you don't need to
> port compiler-rt immediately. It is still pretty important (for
> example, to support features like Address Sanitizer), but not critical
> -- you will still get a useable Clang without building compiler-rt.
>
> Dmitri
>
being able to compile compiler-rt is a pretty good test all is working
as it should be! :) It's also built/installed as part of the Gentoo
llvm ebuild when the clang useflag is enabled, so from that point of
view, I need to get it working.
Alexey Samsonov
Aug 22, 2013, 3:27:17 AM8/22/13
to Steven Newbury, LLVM Developers Mailing List
Hi Steven,
This looks interesting and raises a number of questions :)
1) Does applying this patch actually bring working sanitizers to x32 platform?
That is, after you build the clang, does "clang -fsanitize=whatever foo.c" compile/link/run with expected results?
I doubt that, as there is some platform-specific code in all the sanitizers, and many of them heavily depend
on the address space layout. Porting TSan and MSan to 32-bit address space is especially hard, and we don't plan
to do this anytime soon. I think it makes sense to build only the libraries that are expected to work on a given arch.
2) If we're stepping on the path of porting some sanitizers to x32, it would be great to
setup a buildbot, make our tests pass cleanly, and make this bot public to catch regressions.
Do you have plans for that? Running sanitizer test suites also leads us to...
3) Do you plan to add support for building sanitizers on x32 to CMake build system? It would
make sense (and, in fact, I would start from there), as our testsuite can be run only in CMake builds.
--
Alexey Samsonov, MSK
Alexey Samsonov
Aug 22, 2013, 3:29:37 AM8/22/13
to Dmitri Gribenko, llv...@cs.uiuc.edu, Clang Developers
Ah, I've replied in a different thread already. What Dmitri says - If you're interesting in only building the Clang on x32 host, you may avoid checking out compiler-rt repo for now.
On Thu, Aug 22, 2013 at 10:59 AM, Dmitri Gribenko <grib...@gmail.com> wrote:
On Wed, Aug 21, 2013 at 11:04 PM, Steven Newbury <st...@snewbury.org.uk> wrote:If you are just trying to get basic things working, you don't need to
> I've been trying
> to get x32 ABI support working in Clang and compiler-rt, I based off the
> previous clang patch, bringing it up to date with the changes in trunk,
> and hacked together handling of x32 "ARCH" support for compiler-rt.
> (there must be a better way??)
port compiler-rt immediately. It is still pretty important (for
example, to support features like Address Sanitizer), but not critical
-- you will still get a useable Clang without building compiler-rt.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <grib...@gmail.com>*/
_______________________________________________
cfe-dev mailing list
cfe...@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Alexey Samsonov, MSK
Alexey Samsonov
Aug 22, 2013, 3:31:26 AM8/22/13
to Steven Newbury, Clang Developers, llv...@cs.uiuc.edu
On Thu, Aug 22, 2013 at 11:23 AM, Steven Newbury <st...@snewbury.org.uk> wrote:
On Wed, 2013-08-21 at 23:59 -0700, Dmitri Gribenko wrote:Having Clang working would of course be my primary goal, that said,
> On Wed, Aug 21, 2013 at 11:04 PM, Steven Newbury <st...@snewbury.org.uk> wrote:
> > I've been trying
> > to get x32 ABI support working in Clang and compiler-rt, I based off the
> > previous clang patch, bringing it up to date with the changes in trunk,
> > and hacked together handling of x32 "ARCH" support for compiler-rt.
> > (there must be a better way??)
>
> If you are just trying to get basic things working, you don't need to
> port compiler-rt immediately. It is still pretty important (for
> example, to support features like Address Sanitizer), but not critical
> -- you will still get a useable Clang without building compiler-rt.
>
> Dmitri
>
being able to compile compiler-rt is a pretty good test all is working
as it should be! :) It's also built/installed as part of the Gentoo
llvm ebuild when the clang useflag is enabled, so from that point of
view, I need to get it working.
I see, but it's not really good to build the libraries that are not expected to work...I think you
should instead detect x32 host in the makefiles and avoid buidling compiler-rt libraries in that case.
_______________________________________________
LLVM Developers mailing list
LLV...@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Alexey Samsonov, MSK
Dmitri Gribenko
Aug 22, 2013, 3:34:46 AM8/22/13
to Steven Newbury, Clang Developers, llv...@cs.uiuc.edu
On Thu, Aug 22, 2013 at 12:23 AM, Steven Newbury <st...@snewbury.org.uk> wrote:
> Having Clang working would of course be my primary goal, that said,
> being able to compile compiler-rt is a pretty good test all is working
> as it should be! :) It's also built/installed as part of the Gentoo
> llvm ebuild when the clang useflag is enabled, so from that point of
> view, I need to get it working.
Note that compiler-rt contains arch/type-size dependent code, so it
> Having Clang working would of course be my primary goal, that said,
> being able to compile compiler-rt is a pretty good test all is working
> as it should be! :) It's also built/installed as part of the Gentoo
> llvm ebuild when the clang useflag is enabled, so from that point of
> view, I need to get it working.
might need porting in addition to build system changes.
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <grib...@gmail.com>*/
Steven Newbury
Aug 22, 2013, 3:39:31 AM8/22/13
to Alexey Samsonov, LLVM Developers Mailing List
On Thu, 2013-08-22 at 11:27 +0400, Alexey Samsonov wrote:
> Hi Steven,
>
> This looks interesting and raises a number of questions :)
>
> 1) Does applying this patch actually bring working sanitizers to x32
> platform?
> That is, after you build the clang, does "clang -fsanitize=whatever foo.c"
> compile/link/run with expected results?
> I doubt that, as there is some platform-specific code in all the
> sanitizers, and many of them heavily depend
> on the address space layout. Porting TSan and MSan to 32-bit address space
> is especially hard, and we don't plan
> to do this anytime soon. I think it makes sense to build only the libraries
> that are expected to work on a given arch.
>
I should have made clear this is very much a WIP. I expect to have make
> Hi Steven,
>
> This looks interesting and raises a number of questions :)
>
> 1) Does applying this patch actually bring working sanitizers to x32
> platform?
> That is, after you build the clang, does "clang -fsanitize=whatever foo.c"
> compile/link/run with expected results?
> I doubt that, as there is some platform-specific code in all the
> sanitizers, and many of them heavily depend
> on the address space layout. Porting TSan and MSan to 32-bit address space
> is especially hard, and we don't plan
> to do this anytime soon. I think it makes sense to build only the libraries
> that are expected to work on a given arch.
>
an effort to port compiler-rt, but first I need to be able to generate
elf32_x86_64 objects with Clang. I confess, my method of porting code
to x32 so far has consisted of trying to build existing code and
modifying what breaks, or disabling features where inapplicable. I
haven't studied the code well enough to understand and predict where I'm
going to have make modification in advance. It's worked so far with
most things I've attempted but LLVM/Clang/compiler-rt is an order of
magnitude more complex than anything else I've poked at. The biggest
success I've had so far with this method is porting of Mozilla
Spidermonkey/js17.
> 2) If we're stepping on the path of porting some sanitizers to x32, it
> would be great to
> setup a buildbot, make our tests pass cleanly, and make this bot public to
> catch regressions.
> Do you have plans for that? Running sanitizer test suites also leads us
> to...
>
> 3) Do you plan to add support for building sanitizers on x32 to CMake build
> system? It would
> make sense (and, in fact, I would start from there), as our testsuite can
> be run only in CMake builds.
>
cmake so I should be able to figure it out. From my distro point of
view, the plan on Gentoo is to switch to CMake for the LLVM/Clang
ebuild, but it hasn't happened yet. Perhaps this could be expedited, I
can contact the package maintainer.
Steven Newbury
Aug 22, 2013, 3:44:56 AM8/22/13
to Dmitri Gribenko, Clang Developers, llv...@cs.uiuc.edu
On Thu, 2013-08-22 at 00:34 -0700, Dmitri Gribenko wrote:
> On Thu, Aug 22, 2013 at 12:23 AM, Steven Newbury <st...@snewbury.org.uk> wrote:
> > Having Clang working would of course be my primary goal, that said,
> > being able to compile compiler-rt is a pretty good test all is working
> > as it should be! :) It's also built/installed as part of the Gentoo
> > llvm ebuild when the clang useflag is enabled, so from that point of
> > view, I need to get it working.
>
> Note that compiler-rt contains arch/type-size dependent code, so it
> might need porting in addition to build system changes.
>
I figured this would be the case, but decided to post my build system
> On Thu, Aug 22, 2013 at 12:23 AM, Steven Newbury <st...@snewbury.org.uk> wrote:
> > Having Clang working would of course be my primary goal, that said,
> > being able to compile compiler-rt is a pretty good test all is working
> > as it should be! :) It's also built/installed as part of the Gentoo
> > llvm ebuild when the clang useflag is enabled, so from that point of
> > view, I need to get it working.
>
> Note that compiler-rt contains arch/type-size dependent code, so it
> might need porting in addition to build system changes.
>
changes as is. My plan was/is to look into making the compiler-rt code
work after failing to build it! :-) Generally type-size errors get
detected with at least a warning, although that's admittedly pretty lazy
porting on my part, there was just no way I could read through that much
code in the last few days without trying to get something working
first! ;-)
Alexey Samsonov
Aug 22, 2013, 3:50:26 AM8/22/13
to Steven Newbury, LLVM Developers Mailing List
So, IIUC, if you're working on making LLVM/Clang/compiler-rt source tree
build on x32 host, I suggest your first step should be: disable building compiler-rt
on x32 host :) One of the reasons: in makefile-based build compiler-rt sources
are compiled with just-built Clang (I honestly don't know if Clang can target x32
at the moment). Another reason: compiler-rt code is really arch-specific, and even
if it compiles, it wouldn't work.
I'm new to llvm/clang, I'm going to have to take guidance from others.
> 2) If we're stepping on the path of porting some sanitizers to x32, it
> would be great to
> setup a buildbot, make our tests pass cleanly, and make this bot public to
> catch regressions.
> Do you have plans for that? Running sanitizer test suites also leads us
> to...
>
I can do so, (locally switch to cmake) I have a little experience with
> 3) Do you plan to add support for building sanitizers on x32 to CMake build
> system? It would
> make sense (and, in fact, I would start from there), as our testsuite can
> be run only in CMake builds.
>
cmake so I should be able to figure it out. From my distro point of
view, the plan on Gentoo is to switch to CMake for the LLVM/Clang
ebuild, but it hasn't happened yet. Perhaps this could be expedited, I
can contact the package maintainer.
FTR, CMake would probably see that we our host is neither x86_64 nor i386,
and won't build anything in compiler-rt. If it wouldn't, we should go and fix this.
--
Alexey Samsonov, MSK
Steven Newbury
Aug 22, 2013, 3:48:48 AM8/22/13
to Alexey Samsonov, Clang Developers, llv...@cs.uiuc.edu
libraries are beyond my current ability to port, it might well be worth
making available what does work. But right now this is only building on
my local chroot, with the intention of then pushing it to my
experimental x32 portage overlay once I have something worth testing.
Steven Newbury
Aug 22, 2013, 3:56:31 AM8/22/13
to Alexey Samsonov, LLVM Developers Mailing List
to target x32, I'm also suspicious that x32 built clang isn't correctly
working to produce 64-bit code, but that's a somewhat different bug that
I haven't yet attempted to address. Without modifying Clang to target
x32, the x32 *built* Clang fails to compile compiler-rt with -m64, I
need help decoding the crash backtrace to figure out where that bug
lies, but it's not related to (or helped by) my patch.
>
> >
> > > 2) If we're stepping on the path of porting some sanitizers to x32, it
> > > would be great to
> > > setup a buildbot, make our tests pass cleanly, and make this bot public
> > to
> > > catch regressions.
> > > Do you have plans for that? Running sanitizer test suites also leads us
> > > to...
> > >
> > I'm new to llvm/clang, I'm going to have to take guidance from others.
> >
> > > 3) Do you plan to add support for building sanitizers on x32 to CMake
> > build
> > > system? It would
> > > make sense (and, in fact, I would start from there), as our testsuite can
> > > be run only in CMake builds.
> > >
> > I can do so, (locally switch to cmake) I have a little experience with
> > cmake so I should be able to figure it out. From my distro point of
> > view, the plan on Gentoo is to switch to CMake for the LLVM/Clang
> > ebuild, but it hasn't happened yet. Perhaps this could be expedited, I
> > can contact the package maintainer.
>
>
> FTR, CMake would probably see that we our host is neither x86_64 nor i386,
> and won't build anything in compiler-rt. If it wouldn't, we should go and
> fix this.
>
Maybe. Although, technically it *is* x86_64, but with a different ABI.
> >
> > > 2) If we're stepping on the path of porting some sanitizers to x32, it
> > > would be great to
> > > setup a buildbot, make our tests pass cleanly, and make this bot public
> > to
> > > catch regressions.
> > > Do you have plans for that? Running sanitizer test suites also leads us
> > > to...
> > >
> > I'm new to llvm/clang, I'm going to have to take guidance from others.
> >
> > > 3) Do you plan to add support for building sanitizers on x32 to CMake
> > build
> > > system? It would
> > > make sense (and, in fact, I would start from there), as our testsuite can
> > > be run only in CMake builds.
> > >
> > I can do so, (locally switch to cmake) I have a little experience with
> > cmake so I should be able to figure it out. From my distro point of
> > view, the plan on Gentoo is to switch to CMake for the LLVM/Clang
> > ebuild, but it hasn't happened yet. Perhaps this could be expedited, I
> > can contact the package maintainer.
>
>
> FTR, CMake would probably see that we our host is neither x86_64 nor i386,
> and won't build anything in compiler-rt. If it wouldn't, we should go and
> fix this.
>
I don't know how that's handled, although it works for ARM/MIPS, right??
Steven Newbury
Aug 22, 2013, 4:02:19 AM8/22/13
to Alexey Samsonov, Clang Developers, llv...@cs.uiuc.edu
On Thu, 2013-08-22 at 11:29 +0400, Alexey Samsonov wrote:
> Ah, I've replied in a different thread already. What Dmitri says - If
> you're interesting in only building the Clang on x32 host, you may avoid
> checking out compiler-rt repo for now.
>
>
compiler-rt does make a convenient compiler test though.. :)
> Ah, I've replied in a different thread already. What Dmitri says - If
> you're interesting in only building the Clang on x32 host, you may avoid
> checking out compiler-rt repo for now.
>
>
fatal error: error in backend: Cannot select: 0x30ccf38: ch = brind
0x30cccf8:1, 0x30cc368 [ORD=109] [ID=11]
0x30cc368: i32 = add 0x30cccf8, 0x30cc518 [ORD=109] [ID=10]
0x30cccf8: i32,ch = load 0x30cc2d8:1, 0x30ccfc8,
0x30cc6c8<LD4[JumpTable]> [ORD=109] [ID=9]
0x30ccfc8: i32 = add 0x30cc5a8, 0x30cc518 [ORD=109] [ID=8]
0x30cc5a8: i32 = shl 0x30cc2d8, 0x30ccc68 [ORD=109] [ID=7]
0x30cc2d8: i32,ch = CopyFromReg 0x30a6168, 0x30cc908 [ORD=109]
[ID=5]
0x30cc908: i32 = Register %vreg29 [ID=1]
0x30ccc68: i8 = Constant<2> [ID=4]
0x30cc518: i32 = X86ISD::WrapperRIP 0x30ccab8 [ID=6]
0x30ccab8: i32 = TargetJumpTable<0> [ID=3]
0x30cc6c8: i32 = undef [ID=2]
0x30cc518: i32 = X86ISD::WrapperRIP 0x30ccab8 [ID=6]
0x30ccab8: i32 = TargetJumpTable<0> [ID=3]
In function: __atomic_compare_exchange
clang: error: clang frontend command failed with exit code 70 (use -v to
see invocation)
clang version 3.4 (trunk)
Target: x86_64-pc-linux-gnux32
Thread model: posix
This is what happens when compiling compiler-rt with -m64 or -mx32,
exact same error without my patches (where -mx32 is supported).
However, I know -mx32 isn't working since the objects always end up
elf_x86_64, which is why I known this is a somewhat unrelated bug.
Steven Newbury
Aug 22, 2013, 4:12:30 AM8/22/13
to Alexey Samsonov, Clang Developers, llv...@cs.uiuc.edu
Alexey Samsonov
Aug 22, 2013, 4:29:05 AM8/22/13
to Steven Newbury, LLVM Developers Mailing List
So, it looks like Clang built on x32 host:
(a) doesn't work with -m64 (can't target x86_64)
(b) can target x32 with your patch.
If that's the case, (a) should be investigated (maybe, you can open a bug for this
as a start), while you should try to get your patch for (b) submitted. Let's move the
discussion to that thread, most likely you'll have to add tests and find a
reviewer for that patch.
>Maybe. Although, technically it *is* x86_64, but with a different ABI.
> >
> > > 2) If we're stepping on the path of porting some sanitizers to x32, it
> > > would be great to
> > > setup a buildbot, make our tests pass cleanly, and make this bot public
> > to
> > > catch regressions.
> > > Do you have plans for that? Running sanitizer test suites also leads us
> > > to...
> > >
> > I'm new to llvm/clang, I'm going to have to take guidance from others.
> >
> > > 3) Do you plan to add support for building sanitizers on x32 to CMake
> > build
> > > system? It would
> > > make sense (and, in fact, I would start from there), as our testsuite can
> > > be run only in CMake builds.
> > >
> > I can do so, (locally switch to cmake) I have a little experience with
> > cmake so I should be able to figure it out. From my distro point of
> > view, the plan on Gentoo is to switch to CMake for the LLVM/Clang
> > ebuild, but it hasn't happened yet. Perhaps this could be expedited, I
> > can contact the package maintainer.
>
>
> FTR, CMake would probably see that we our host is neither x86_64 nor i386,
> and won't build anything in compiler-rt. If it wouldn't, we should go and
> fix this.
>
I don't know how that's handled, although it works for ARM/MIPS, right??
Yes, we're able to target ARM on x86_64 host if that's what you're asking about.
Alexey Samsonov, MSK
Steven Newbury
Aug 22, 2013, 4:31:48 AM8/22/13
to Alexey Samsonov, LLVM Developers Mailing List
ARCH. (o32, n32, n64 for MIPS, and EABI EABIHF etc for ARM) I need to
study the build system code a little more to figure out what it does,
unless someone can clarify..?
Steven Newbury
Aug 22, 2013, 10:00:29 AM8/22/13
to Alexey Samsonov, Clang Developers, LLVM Developers Mailing List
Environment part of the Triple is always GNUX32, I've now changed it so
that it gets properly set to GNU. This *fixes* the -m64 case, since
otherwise it *always* tries to compile to ILP32 except for some reason
the object ends up as elf_x86_64, not sure why yet... (can anybody help
here?) The -m32 case worked because then the Arch component was set to
i386 which is !=x86_64 as protects all the GNUX32 tests for throughout
the patch.
The upshot of this is the x86_64 target is now working on x32 hosts for
the first time! :-)
Unfortunately, it does reveal a problem with X32; or possibly it's just
that atomic.c from compiler-rt won't work as is with X32 target, but it
shouldn't be triggering a crash...
Will send new patch shortly.
Steven Newbury
Aug 22, 2013, 10:14:08 AM8/22/13
to Alexey Samsonov, Clang Developers, LLVM Developers Mailing List
probably not surprising that it's crashing. The question is what did I
miss?
This chunk (largely unchanged from the original patch sent to llvm-dev
last year) should be doing the trick, so why doesn't it?
> @@ -6125,8 +6127,12 @@
> }
> else if (ToolChain.getArch() == llvm::Triple::systemz)
> CmdArgs.push_back("elf64_s390");
> - else
> - CmdArgs.push_back("elf_x86_64");
> + else if (ToolChain.getArch() == llvm::Triple::x86_64)
> + CmdArgs.push_back(ToolChain.getTriple().getEnvironment() ==
> + llvm::Triple::GNUX32
> + ? "elf32_x86_64" : "elf_x86_64");
> + else
> + llvm_unreachable("unknown arch");
>
Steven Newbury
Aug 22, 2013, 10:22:54 AM8/22/13
to llv...@cs.uiuc.edu
This patch is still not creating elf32_x86_64 objects. No idea
why. :( It does however, fix elf_x86_64 (-m64) code generation on x32
hosts which is nice. :)
--- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16
21:51:51.286129820 +0000
+++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16
21:53:24.875004239 +0000
@@ -841,6 +841,7 @@
HelpText<"Enable hexagon-qdsp6 backward compatibility">;
def m3dnowa : Flag<["-"], "m3dnowa">, Group<m_x86_Features_Group>;
def m3dnow : Flag<["-"], "m3dnow">, Group<m_x86_Features_Group>;
+def mx32 : Flag<["-"], "mx32">, Group<m_Group>, Flags<[DriverOption]>;
def m64 : Flag<["-"], "m64">, Group<m_Group>, Flags<[DriverOption]>;
def mabi_EQ : Joined<["-"], "mabi=">, Group<m_Group>;
def march_EQ : Joined<["-"], "march=">, Group<m_Group>;
--- tools/clang/lib/Driver/Driver.cpp.orig 2013-08-22 14:07:13.397091755
+0000
+++ tools/clang/lib/Driver/Driver.cpp 2013-08-22 14:05:55.275249307
+0000
@@ -1897,6 +1897,8 @@
// Handle pseudo-target flags '-m32' and '-m64'.
// FIXME: Should this information be in llvm::Triple?
if (Arg *A = Args.getLastArg(options::OPT_m32, options::OPT_m64)) {
+ if (Target.getEnvironment() == llvm::Triple::GNUX32)
+ Target.setEnvironment(llvm::Triple::GNU);
if (A->getOption().matches(options::OPT_m32)) {
@@ -1908,6 +1910,9 @@
why. :( It does however, fix elf_x86_64 (-m64) code generation on x32
hosts which is nice. :)
--- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16
21:51:51.286129820 +0000
+++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16
21:53:24.875004239 +0000
@@ -841,6 +841,7 @@
HelpText<"Enable hexagon-qdsp6 backward compatibility">;
def m3dnowa : Flag<["-"], "m3dnowa">, Group<m_x86_Features_Group>;
def m3dnow : Flag<["-"], "m3dnow">, Group<m_x86_Features_Group>;
+def mx32 : Flag<["-"], "mx32">, Group<m_Group>, Flags<[DriverOption]>;
def m64 : Flag<["-"], "m64">, Group<m_Group>, Flags<[DriverOption]>;
def mabi_EQ : Joined<["-"], "mabi=">, Group<m_Group>;
def march_EQ : Joined<["-"], "march=">, Group<m_Group>;
+0000
+++ tools/clang/lib/Driver/Driver.cpp 2013-08-22 14:05:55.275249307
+0000
@@ -1897,6 +1897,8 @@
// Handle pseudo-target flags '-m32' and '-m64'.
// FIXME: Should this information be in llvm::Triple?
if (Arg *A = Args.getLastArg(options::OPT_m32, options::OPT_m64)) {
+ if (Target.getEnvironment() == llvm::Triple::GNUX32)
+ Target.setEnvironment(llvm::Triple::GNU);
if (A->getOption().matches(options::OPT_m32)) {
if (Target.getArch() == llvm::Triple::x86_64)
Target.setArch(llvm::Triple::x86);
@@ -1908,6 +1910,9 @@
if (Target.getArch() == llvm::Triple::ppc)
Target.setArch(llvm::Triple::ppc64);
}
+ } else if (Args.getLastArg(options::OPT_mx32)) {
+ if (Target.getArch() == llvm::Triple::x86_64)
+ Target.setEnvironment(llvm::Triple::GNUX32);
}
return Target;
Target.setArch(llvm::Triple::ppc64);
}
+ } else if (Args.getLastArg(options::OPT_mx32)) {
+ if (Target.getArch() == llvm::Triple::x86_64)
+ Target.setEnvironment(llvm::Triple::GNUX32);
}
return Target;
Steven Newbury
Aug 22, 2013, 10:56:15 AM8/22/13
to llv...@cs.uiuc.edu, Clang Developers
On Thu, 2013-08-22 at 15:22 +0100, Steven Newbury wrote:
> This patch is still not creating elf32_x86_64 objects. No idea
> why. :( It does however, fix elf_x86_64 (-m64) code generation on x32
> hosts which is nice. :)
I know why. I had assumed Michael Liao (the original patch author) had
> This patch is still not creating elf32_x86_64 objects. No idea
> why. :( It does however, fix elf_x86_64 (-m64) code generation on x32
> hosts which is nice. :)
submitted all the _LLVM_ x32 support as separate patches, and it was
just the tests/Clang/compiler-rt support that was missing. It seems not
so. Those specific patches he did submit got commited, but many pieces
are missing... I should NEVER make such big assumptions!
Looks like I'm going to have to go through the original patch and create
a new patch series.
If I'm going to submit the Clang patch, how should it be submitted? One
patch with what's required to get x32 host to work, then another
enabling x32 code generation once the required changes to llvm are
merged? Would that be sufficient?
Steven Newbury
Aug 22, 2013, 11:43:01 AM8/22/13
to Dmitri Gribenko, Clang Developers, llv...@cs.uiuc.edu
On Thu, 2013-08-22 at 08:40 -0700, Dmitri Gribenko wrote:
>
Been chatting with jfb on irc. It seems Google NaCl has all the needed
changes to get LLVM to work with x32, in addition to their other
requirements, so I'm going to go through their changes and make relevant
parts conditional on GNUX32. Then when their code lands which they hope
won't be too long x32 will come for free.
> On Thu, Aug 22, 2013 at 7:56 AM, Steven Newbury <st...@snewbury.org.uk> wrote:
> > If I'm going to submit the Clang patch, how should it be submitted? One
> > patch with what's required to get x32 host to work, then another
> > enabling x32 code generation once the required changes to llvm are
> > merged? Would that be sufficient?
>
> Sounds good to me.
> > If I'm going to submit the Clang patch, how should it be submitted? One
> > patch with what's required to get x32 host to work, then another
> > enabling x32 code generation once the required changes to llvm are
> > merged? Would that be sufficient?
>
>
Been chatting with jfb on irc. It seems Google NaCl has all the needed
changes to get LLVM to work with x32, in addition to their other
requirements, so I'm going to go through their changes and make relevant
parts conditional on GNUX32. Then when their code lands which they hope
won't be too long x32 will come for free.
Dmitri Gribenko
Aug 22, 2013, 11:40:11 AM8/22/13
to Steven Newbury, Clang Developers, llv...@cs.uiuc.edu
On Thu, Aug 22, 2013 at 7:56 AM, Steven Newbury <st...@snewbury.org.uk> wrote:
> If I'm going to submit the Clang patch, how should it be submitted? One
> patch with what's required to get x32 host to work, then another
> enabling x32 code generation once the required changes to llvm are
> merged? Would that be sufficient?
Sounds good to me.
> patch with what's required to get x32 host to work, then another
> enabling x32 code generation once the required changes to llvm are
> merged? Would that be sufficient?
Dmitri
--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <grib...@gmail.com>*/
Eli Bendersky
Aug 22, 2013, 12:56:12 PM8/22/13
to Steven Newbury, Clang Developers, LLVM Developers Mailing List
On Thu, Aug 22, 2013 at 7:56 AM, Steven Newbury <st...@snewbury.org.uk> wrote:
On Thu, 2013-08-22 at 15:22 +0100, Steven Newbury wrote:I know why. I had assumed Michael Liao (the original patch author) had
> This patch is still not creating elf32_x86_64 objects. No idea
> why. :( It does however, fix elf_x86_64 (-m64) code generation on x32
> hosts which is nice. :)
submitted all the _LLVM_ x32 support as separate patches, and it was
just the tests/Clang/compiler-rt support that was missing. It seems not
so. Those specific patches he did submit got commited, but many pieces
are missing... I should NEVER make such big assumptions!
Looks like I'm going to have to go through the original patch and create
a new patch series.
If I'm going to submit the Clang patch, how should it be submitted? One
patch with what's required to get x32 host to work, then another
enabling x32 code generation once the required changes to llvm are
merged? Would that be sufficient?
Please note that the bulk of work to make Clang x32-capable is in LLVM. The patches sent by Michael a while back no longer apply because we upstreamed some things since then, but the support is not complete yet (mainly in SelDAG). Please be sure to go over the mailing list archives discussing x32, as well as look at the SVN logs for everything mentioning x32. There's quite a bit of history here and it's important to have a full grasp of things.
Eli
Reply all
Reply to author
Forward
0 new messages