similar to: [LLVMdev] [RFC PATCH] X32 ABI support for Clang/compiler-rt

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">,

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

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

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

I've tried to build something that wanted ms-extensions on OpenBSD. Long story short, didn't work so well, because all system includes lead to <machine/_types.h> #ifndef __cplusplus typedef int __wchar_t; #endif and since ms-extensions includes __char_t as a built-in, this did fail abysmally. It would be simple to fix in OpenBSD, assuming clang did tell us it

On Fri, May 12, 2017 at 12:01:35PM +0200, Dimitry Andric wrote: > On 11 May 2017, at 20:04, Marc Espie via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > I've tried to build something that wanted ms-extensions on OpenBSD. > > Long story short, didn't work so well, because all system includes > > lead to > > > > <machine/_types.h>

It looks fine to me. Anton, does it look ok to you? Evan On Mar 20, 2009, at 2:33 PM, Corrado Zoccolo wrote: > I've created a patch (attached to the bug): > http://llvm.org/bugs/attachment.cgi?id=2744, that goes in a different > direction, and solves the safety problems. > The patch uses original asm, but removes the call through plt, and > puts the invoked function in an

I'm trying to change the Endian of X86 from little to big in the TargetData. I only care about the way in which this effects the LLVM IR, not the actual backend code. I've changed the "e-" to "E-" in X86TargetMachine.cpp (where it sets the DataLayout) with no luck. Are there any other obvious places that I need to change this? The TargetData docs were somewhat helpful

Hi Evan > It looks fine to me. Anton, does it look ok to you? This looks ok for me modulo win64+vcpp issues, which I mentioned in the PR (external .asm files). The anonymous namespace thing should be guarded by define (either _M_AMD64 or X86_64_JIT && _MSC_VER, I'd prefer the latter). -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint

No luck there with modifying clang/lib/Basic/Targets.cpp unfortunately. I only modified BigEndian to 'true' and Builder.defineMacro to "__BIG_ENDIAN__" On Sat, Jul 7, 2012 at 2:34 AM, Anton Korobeynikov <anton at korobeynikov.info>wrote: > > Oh sorry, clang. > Then you should modify clang, not backends, look into Basic/Targets.cpp > there. > > PS: Note

Hi vedant, The program didn't pass the checking "OF->getArch() != Triple(Arch).getArch()" loadBinaryFormat in CoverageMappingReader.cpp and returned an error. It's because "OF->getArch()" returned null and "Triple(Arch).getArch()" returned XXXX(name of my arch). The returned value of " OF->getArch()" is decided by "

Hi all, I'm trying to support llvm-cov for a new architecture and I have successfully built compiler-rt for my arch. Following steps shown in https://clang.llvm.org/docs/SourceBasedCodeCoverage.html , I encountered an error for the last step(step of llvm-cov show). The command line was (supposed my arch is XXXX) "llvm-cov show -arch=XXXX ./foo -instr-profile=foo.profdata" and the

Hi vedant, 1. The definition is from llvm/Supprot/ELF.h. But this machine information(e_machine) is given to compiler at lib/MC/ELFObjectWriter.cpp. I greped the whole llvm project and found that e_machine was assigned at only two files. One was lib/MC/ELFObjectWriter.cpp(there was an comment said “e_machine=target”) and the other was tools/obj2yaml/elf2yaml.cpp(GDB stopped only at the

Hi vedant, 1. First, I think your theory is right that llvm’s object file reading libraries do not “understand” the architecture I’m working on. Since I’m using binutils as assembler which means llvm can only provide asm and object file is provided by biutils. I think these ELF header information is provided by my binutils now, so maybe I have to modify binutils code to provide ELF header

These two subclasses of X86TargetMachine are basically identical. The *only* thing that's different is the constructor. And that *only* differs in the is64Bit argument that it passes to the X86TargetMachine constructor. Replacing the hard-coded 'true' or 'false' with 'Triple(TT).getArch()==Triple::x86_64' makes them *actually* identical. Can we just ditch the

Interesting. Was this the reason you were getting the recursive compilation error in JIT::runJITOnFunctionUnlocked(...) (isAlreadyCodeGenerating)? Do you have the time to try your test with 2.7? Garrison On Jan 22, 2010, at 17:37, James Williams wrote: > I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed

[+llvmdev, -llvm-dev] (Oopsies, llvmdev doesn't have a hyphen in it like all the others do) On 6/17/14, 10:45 AM, Jonathan Roelofs wrote: > [+llvm-dev, cfe-dev] > > Was "Re: [PATCH] ARM: allow inline atomics on Cortex M" > > On 6/17/14, 10:42 AM, Jonathan Roelofs wrote: >> >> >> On 6/17/14, 9:35 AM, Renato Golin wrote: >>> On 17 June 2014

On OS X (10.6.2) running on an Intel Core 2 duo with LLVM 2.7 pulled about a month ago from CVS and built in debug mode: Using the JIT system with exception handling, I am having issues with type infos. "Finally" code (llvm.eh.selector intrinsic call with 0) works fine (correct landing pads found), as does this call with one type info. My type infos are each 64 bit array GlobalVariables

Eric, Attached are patches for llvm and clang that implement this. I've made 'none' a component that must be added explicitly (i.e. don't turn arm-eabi into arm--none-eabi, but rather turn it into arm--unknown-eabi) to try to reduce surprises. It also keeps the normalization logic a bit simpler than it would otherwise have to be. SPIR triples were one place where I was

> 6. When ExecutionEngine::create was called with parameter > "GVsWithCode" set to its default value of true, I got a segfault when > trying to get a pointer to one of my globals.  JIT::getMemoryForGV was > returning NULL in that case.  Explicitly passing false for > "GVsWithCode" cleared it up. That's no good. Could you send me a stack trace and explain