similar to: PIC preferred too strongly, even at CodeModel::Large?

On Thu, Jul 28, 2016 at 6:13 PM, Ramkumar Ramachandra via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > We were just debugging a sporadic crash the other day, when we noticed > that RIP-relative addressing was being used in a JumpTable, even when > code and data were well over 4G apart. This is confusing, because we > picked CodeModel::Large, and expected this to

Eli Friedman wrote: > On Thu, Jul 28, 2016 at 6:13 PM, Ramkumar Ramachandra via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> We were just debugging a sporadic crash the other day, when we noticed >> that RIP-relative addressing was being used in a JumpTable, even when >> code and data were well over 4G apart. This is confusing, because we >> picked

On Fri, Jul 29, 2016 at 9:57 AM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > Eli Friedman wrote: > > On Thu, Jul 28, 2016 at 6:13 PM, Ramkumar Ramachandra via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > >> We were just debugging a sporadic crash the other day, when we noticed > >> that RIP-relative addressing was being used in a

I'm trying to add static code generation capabilities to my MCJIT compiler on LLVM 3.4. To that extent I have: targetMachine = engineBuilder.selectTarget(); // ... targetMachine->addPassesToEmitFile(<...>); At first glance this appears to work, but when linking the object file I get the warning: ld: warning: PIE disabled. Absolute addressing (perhaps

ELF module of type ET_REL (Relocable module), generated by LLVM, always has some R_X86_64_32 in debug information sections. This happens with Reloc models Default,Static,PIC_ and with CodeModel set to Large. What is the way to prevent R_X86_64_32 ELF from ever appearing in ELF? Yuri

Aaron, > Maybe we should collect references and do some LLVM PIC documentation and > put it on LLVM website ? What you mean as "LLVM PIC documentation"? What should be included there? > Okay. We need documentation, what is the difference between DynamicNoPIC and > full PIC ? >From TargetMachine.cpp (actually this is show in llc --help): cl::values(

Has anyone experimented with generating non-PIC for MIPS64 and the n64 ABI? Currently MipsISelLowering.cpp uses conditions like: if ((getTargetMachine().getRelocationModel() == Reloc::PIC_) || IsN64) { } around any PIC code generation. Is generating non-PIC just untested, or is it known not to work? I can't find any discussion of it anywhere. I ran into this when trying to see why

Hello everyone, I have an issue with some code that I jit/load as position independent code. I have a feeling that it is not possible to solve the issue but I wanted to give it a try. #include <stdio.h> int magicValue = 123; int magicValue2 = 321; volatile int *pValue = &magicValue; void printMagicValue() { printf("Planschi...\n"); printf("The magic

Hello, I am currently facing an issue at linking stage when compiling basic C code for an embedded PPC32 platform and linking with LLD. For external symbol linkage LLVM appears to use PLT which results in generating a R_PPC_PLTREL24 relocation, that is not support by LDD. Therefore even such a basic example cannot be built: /* s.c */ int f() { return 0; } /* t.c */ int f(); int _start() {

Actually, GCC will generate non-PIC for n64. Maybe that is a recent addition, but we are using its results. Even if PIC may be faster and smaller code, it seems that non-PIC is still useful for bare-metal. That's the driver of my interest. I guess we can just test what happens when that part of the conditional is removed. As a side note, if it isn't supported then we should probably

llvm-dev, Thanks so much in advance for any help, tips, or advice you may be able to offer me. I'm going to try to avoid the big-picture description of the project I'm working on, and only talk about the parts that I have trouble with / currently need to implement. -- I've been starting by taking the source code from the "llvm-mc" tool, and working that down into a

Hal, I very well understand that LDD may not be in a good state for PPC32, and it would definitely need some improvements sooner or later. In fact I even submitted a patch adding a relocation to ldd just a few hours ago. However, this particular case is not related to LDD, it is a design issue and furthermore a regression in LLVM itself. I checked gcc, and neither does it try to use PLT and

Anton, >> Can I ask what platform ABI's are documented other than Itanium ? > I'd bet all platform ABI are more or less documented. Right. Maybe we should collect references and do some LLVM PIC documentation and put it on LLVM website ? >> I need to get to understand PIC on x86, x86_64 and PowerPC for the COFF >> and MachO backends. > ABI is normally induced

I've also tried the next combination: true, // ForceInterpreter false, // UseMCJIT and ios app just crashed with no output 2014-09-18 0:47 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: > Hey. > > I've checked out LLVM/Clang 3.5 and modified my static libs source code to > use the latest llvm/clang sources. > Also i'm trying triple

Hi: This is my first patch submission. Hopefully, this is the proper the protocol. Attached is a patch for the llc ARM backend: Added mechanism to generate switch table in a data section rather than having it interleaved with the code. This is controlled by command line flags and off by default. Also, tried to document and improve the code where I modified it. Robert -------------- next part

Hi, Lang. Thanks for clarification. I will check out current branch tomorrow and report you back. Most likely i will create bug issue with cleaned sources for static lib and test ios app. Actually i'm not professional c++ dev so my question is - is there any chance to do the next: 1. compile .cpp code to .ll code (seems i already did it) 2. interpret .ll file by any supported at the moment

On Fri, May 22, 2015 at 4:14 PM, Keno Fischer <kfischer at college.harvard.edu> wrote: > This might be related to GOT relocations. I rewrote that part of > RuntimeDyldELFbecause I was seeing this issue. Have you tried trunk? > I didn't notice that you were running 3.5 the first time I read this. Keno's diagnosis is very likely to be correct. You should try trunk if

Both Clang/LLVM 3.4 -> Clang/LLVM 3.5 And i will also try using MCJIT. 2014-09-17 18:56 GMT+06:00 Anton Smirnov <dev at antonsmirnov.name>: > Hi, Tim. > > I've used Clang 3.4 final release and now i'm going to test it with 3.5 > release (since i've read about arm64 improvements). > I will report my results. > > BTW, is it possible to get smth like

So it appears that we get about half the crashes with the large code model. The rest are crashing in the same way. It could either mean that large code model still takes that crashing codepath and that the number of crashes only went down by chance, or that in one place in the flow, large code model is not matched to mean ELF::R_X86_64_PC64. I'm digging into this issue further, but any hints

Hi, We are seeing sporadic crashes since we migrated to MCJIT on Win64. The same tests pass without issues on Mac64 and Linux64. The issue is this assertion failure in RuntimeDyldELF.c: RealOffset <= INT32_MAX && RealOffset >= INT32_MIN I haven't managed to successfully catch the failure in Visual to try and debug it. Any tips on how to make progress? Oh, and we're on