similar to: [LLVMdev] Help needed about code & data mixing when emit object files

On 11/04/2013 11:15 AM, Eric Christopher wrote: > > > > On Mon, Nov 4, 2013 at 11:05 AM, Shankar Easwaran > <shankare at codeaurora.org <mailto:shankare at codeaurora.org>> wrote: > > Hi, > > I was looking at the ARM ABI > docs(http://infocenter.arm.__com/help/topic/com.arm.doc.__ihi0044e/IHI0044E_aaelf.pdf >

Hi, I was looking at the ARM ABI docs(http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf) and they mention. "A binary file may use REL or RELA relocations or a mixture of the two (but multiple relocations for the same address must use only one type)." Does LLVM emit rel/rela relocations with ARM ? Any tests ? Thanks Shankar Easwaran -- Qualcomm

On Mon, Nov 4, 2013 at 11:05 AM, Shankar Easwaran <shankare at codeaurora.org>wrote: > Hi, > > I was looking at the ARM ABI docs(http://infocenter.arm. > com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf) and they mention. > > "A binary file may use REL or RELA relocations or a mixture of the two > (but multiple relocations for the same > address must use

On 11/4/2013 1:40 PM, Jack Carter wrote: > On 11/04/2013 11:15 AM, Eric Christopher wrote: >> >> >> >> On Mon, Nov 4, 2013 at 11:05 AM, Shankar Easwaran >> <shankare at codeaurora.org <mailto:shankare at codeaurora.org>> wrote: >> >> Hi, >> >> I was looking at the ARM ABI >>

On Wed, Aug 26, 2015 at 11:49:46AM -0400, Rafael Espíndola wrote: > This is pr10368. > > Do we really need to support hard coded relocation numbers? Looks like > the examples above have a representation as constant expressions: > > (sub (add (ptrtoint @foo) 0xeafffffe) cur_pos) > > no? I'm not sure if this would be sufficient. The R_ARM_JUMP24 relocation on ARM

On Wed, Aug 26, 2015 at 03:53:33PM -0400, Rafael Espíndola wrote: > > I'm not sure if this would be sufficient. The R_ARM_JUMP24 relocation > > on ARM has specific semantics to implement ARM/Thumb interworking; see > > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf > > Note that R_ARM_CALL has the same operation but different semantics.

Moshe, Nir wrote: [...] > I have a question about the LLVM ARM backend: > > I try to build *.c files for Windows Phone (Windows 8) - so, basically > I need to generate an "arm-pe" file (I *think* it has the same file > structure like x86-pe file, but i am not sure). > unfortunately, LLVM has no support with ARM PE\COFF. We recently ran into this. Unfortunately

On Mar 29, 2011, at 8:44 AM, Renato Golin wrote: > Hi there, > > I've created a bug on llvm: > > http://www.llvm.org/bugs/show_bug.cgi?id=9582 > > Basically, ARM, Thumb and data mapping symbols should have been > exported in the ELF file, so the linker can work correctly. > > I can do the change and create some test cases, but I haven't been > paying

Hi Reed, > I'm wondering if there is already some mechanism where I can assign literals > to the text section and get a label for where it has been stored. I think putting them in the text section is reasonably simple, though doesn't have a generic "pleasePutConstantsAfterFunctions()" call in LLVM. A good place to start would be the reverse of my recent patch to AArch64

Hi guys, I have a question about the LLVM ARM backend: I try to build *.c files for Windows Phone (Windows 8) - so, basically I need to generate an "arm-pe" file (I *think* it has the same file structure like x86-pe file, but i am not sure). unfortunately, LLVM has no support with ARM PE\COFF. Any ideas? How difficult is to add the support in this file format? (LLC can generate ARM

On Fri, Oct 7, 2016 at 12:20 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com > wrote: > I've tried implementing some of the alternatives mentioned in this > thread, and so far I like this syntax the most: > > i32 reloc (29, void ()* @f, 3925868544) > ; 29 = 0x1d = R_ARM_JUMP24 > ; 3925868544 = 0xea000000 > > Note the zeroes in the relocated data instead of

On 8/18/2010 12:39 PM, Dale Johannesen wrote: > I can look at this, but you'll need to send the .bc file. Please open > a PR? I would do it but I am in a bit of a pickle as the .bc is from propriety code and I can not post it. Anyway, I have been trying to re-create the problem in a simpler test case. Since, I do not have access to the source for the .bc I am trying to guess the

Dear all, Here's a new patch with Evan's comments (thx Evan!) and some cleanups. Now the (duplicated) exception handling code is in a new file: lib/ExecutionEngine/JIT/JITDwarfEmitter. This patch should work on linux/x86 and linux/ppc (tested). Nicolas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jit-exceptions.patch URL:

On Fri, Oct 7, 2016 at 1:55 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com> wrote: > On Fri, Oct 7, 2016 at 1:22 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > On Fri, Oct 7, 2016 at 12:20 PM, Evgenii Stepanov > > <eugeni.stepanov at gmail.com> wrote: > >> > >> I've tried implementing some of the alternatives mentioned in

On Aug 18, 2010, at 11:37 AMPDT, Pawel Wodnicki wrote: > On 8/18/2010 12:39 PM, Dale Johannesen wrote: >> I can look at this, but you'll need to send the .bc file. Please >> open a PR? > > I would do it but I am in a bit of a pickle as the .bc is from > propriety code and > I can not post it. Can't help much then. You might look into obfuscating the

Hi everyone, Here's a patch that enables exception handling when jitting. I've copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may need to factorize it, but the functionality is there and I'm very happy with it :) lli should now be able to execute the output from llvm-gcc when using exceptions (the UnwindInst instruction is not involved in this patch). Just add the

Hi everyone, vmkit requires to know the size of a jitted method before emitting the method. This allows to allocate the correct size for the method. The attached patch creates this functionality when the flag SizedMemoryCode is on. In order to implement this functionality, i had to virtualize some MachineCodeEmitter functions. Is it OK to commit the patch? Thanks, Nicolas --------------

Looks sane. Thanks. Evan On Feb 1, 2008, at 1:24 AM, Nicolas Geoffray wrote: > Dear all, > > Here's a new patch with Evan's comments (thx Evan!) and some cleanups. > Now the (duplicated) exception handling code is in a new file: > lib/ExecutionEngine/JIT/JITDwarfEmitter. > > This patch should work on linux/x86 and linux/ppc (tested). > > Nicolas > Index:

On Fri, Oct 7, 2016 at 2:48 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com> wrote: > On Fri, Oct 7, 2016 at 2:28 PM, Peter Collingbourne <peter at pcc.me.uk> > wrote: > > On Fri, Oct 7, 2016 at 1:55 PM, Evgenii Stepanov < > eugeni.stepanov at gmail.com> > > wrote: > >> > >> On Fri, Oct 7, 2016 at 1:22 PM, Peter Collingbourne <peter

Hi All, I started to work on code-size improvements on ARM target by comparing GCC and LLVM generated code. My first candidate was switch-case lowering. I also created a Bugzilla issue for this topic: https://bugs.llvm.org/show_bug.cgi?id=34902 The full example code and the generated assembly for GCC and for LLVM is in the Bugzilla issue. My first idea was to simplify the following