[LLVMdev] X32 ABI support for Clang/compiler-rt (re: clang patch)

[Steven Newbury]

On Thu, 2013-08-22 at 15:00 +0100, Steven Newbury wrote:
> On Thu, 2013-08-22 at 12:29 +0400, Alexey Samsonov wrote:
> > On Thu, Aug 22, 2013 at 11:56 AM, Steven Newbury <steve at snewbury.org.uk>wrote:
> > 
> > > On Thu, 2013-08-22 at 11:50 +0400, Alexey Samsonov wrote:
> > > > On Thu, Aug 22, 2013 at 11:39 AM, Steven Newbury <steve at snewbury.org.uk
> > > >wrote:
> > > >
> > > > > 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
> > > > > 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.
> > > > >
> > > >
> > > > 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.
> > > >
> > > See accompanied Clang patch in other email.  I've attempted to get Clang
> > > 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.
> > >
> > 
> > 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.
> > 
> Actually, I've just fixed a bug where when running on a x32 host the
> 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...
As noted above, since the object file is ending up as elf_x86_64 it's
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");
>