similar to: [LLVMdev] [ARM] Mixing rel/rela relocations

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 >

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

Hi Shankar, > Does LLVM emit rel/rela relocations with ARM ? I believe we emit .rel for (32-bit) ARM. Hard-coded in ARMELFObjectWriter.cpp (“HasRelocationAddend”). It seems to be what most toolchains have settled on. AArch64 is .rela always in LLVM, in case it matters. > Any tests ? Well there are tests of what we do, but obviously not of the full scope of functionality permitted by the

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.

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

Hi, I'm building a new backend which can only load very limited range of imm. So I decided to use constant pool, and place constant pool entries close enough to instructions use the entries (we have very limited range PC-relative memory load). However, lld & llc output the object files that gather all constant pool entries into one section. How can I make them mix these entries into code

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

Hi, Now lld writes relocations to the ".rela" sections only. Mips requires to use the "rel" format. So we need to be able to select format and names of relocation section, names of symbols like __rela_iplt_* / __rel_iplt_*, dynamic table tag DT_RELA / DT_REL. My current idea: - Add two virtual functions DefaultLayout::createDynamicRelocationTable() and

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 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 have reached the relocation phase of my backend implementation and I'm having some trouble. The LLVM code I'm trying to compile is this: %struct.Date = type { i32, i32, i32 } @date = global %struct.Date { i32 2012, i32 10, i32 120000 }, align 4 ; Function Attrs: nounwind define i32 @foo() #0 { %1 = load i32, i32* getelementptr inbounds (%struct.Date, %struct.Date* @date, i32

I think the linking context should decide whether to use rel (or) rela. This is also needed if --emit-relocations option is chosen (or) -r option is used. Thoughts ? Sent from my iPhone > On Jan 19, 2014, at 15:01, Simon Atanasyan <simon at atanasyan.com> wrote: > > Hi, > > Now lld writes relocations to the ".rela" sections only. Mips requires > to use the

On 3 May 2017 at 08:01, Rafael Avila de Espindola via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Can you provide a .s file that shows the difference? I managed to reproduce it by compiling 'char *var = "whatever";' in debug mode (so clang -target arm-none-eabi tmp.c -g"). Direct compile leaves no assembler-local strings, but for some reason going via -S does.

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

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

Hi, We are trying to use LLVM API to programmatically obtain a list of relocations in an ELF file. The way we are doing this is exactly as llvm-objdump does it: we are iterating through sections and in each section we are iterating over relocations (see PrintRelocations() function at https://llvm.org/svn/llvm-project/llvm/trunk/tools/llvm-objdump/llvm-objdump.cpp). However, it does not give us

* Rahul Chaudhry via gnu-gabi: > The encoding used is a simple combination of delta-encoding and a > bitmap of offsets. The section consists of 64-bit entries: higher > 8-bits contain delta since last offset, and lower 56-bits contain a > bitmap for which words to apply the relocation to. This is best > described by showing the code for decoding the section: > > typedef

A simple combination of delta-encoding and run_length-encoding is one of the first schemes we experimented with (32-bit entries with 24-bit 'delta' and an 8-bit 'count'). This gave really good results, but as Sri mentions, we observed several cases where the relative relocations were not on consecutive offsets. There were common cases where the relocations applied to alternate

+llvm-dev Discussion here: https://sourceware.org/ml/gnu-gabi/2017-q2/msg00000.html On Tue, May 2, 2017 at 10:17 AM, Suprateeka R Hegde <hegdesmailbox at gmail.com> wrote: > On 02-May-2017 12:05 AM, Florian Weimer wrote: >> On 05/01/2017 08:28 PM, Suprateeka R Hegde wrote: >>> So the ratio shows ~96% is RELATIVE reloc. And only ~4% others. This is >>> not the