search for: addends

Hi Lang, Yeah, I remember this case. Basically what’s happening is that there are relocations for ELF on x86 that use a value that is present in the object image as part of the calculation for the final value that goes in the same location. If you ever find yourself applying relocations for a second time (for instance, because the loaded object location is remapped for out-of-proc execution)

Hi all, I committed a first cut at blockless Givens/Whens/Thens to RSpec''s trunk: cd /path/to/rspec/project svn up cd rspec bin/spec examples/story/calculator.rb Take a look at examples/story/calculator.rb to see what''s going on. Needs docs!!!! Thoughts welcome. I''ve also got a cut at the plain text parser checked in, but it''s not hooked up to anything

...44) > >> > > >> > @dummy = internal alias i32* getelementptr (i32, i32* bitcast ([3 x > >> > i32]* @w > >> > to i32*), i32 1) > >> > > >> > This way, you save yourself from needing to worry about manipulating > >> > addends > >> > in the backend, the linker will take care of it for you. > >> > >> That's no worry at all, AsmPrinter::lowerConstant evaluates both > >> constant expressions to MCExpr: w + 4. > > > > > > But you still need to worry about how &quot...

...FFFF). Can't we apply HI16 and > LO16 relocations separately and produce the same relocation result? Do we > have to pair them up before applying relocations? The correct formula for the combined addend is (AHI << 16) + (short)ALO. So the combined addend depends on both AHI and ALO addends, therefore ALO affects result of R_MIPS_HI16 relocation. Current version of bfd GNU linker looks up R_MIPS_LO16 relocation each time it needs to calculate R_MIPS_HI16 relocation. It uses `mips_elf_add_lo16_rel_addend` function for that (https://goo.gl/P7nb76). -- Simon Atanasyan

Hi, Now in case of relocatable object generation LLD merges and copies REL/RELA sections as is and does not touch any addends. But it is incorrect. If we have a relocation which targets a section, we have to adjust the relocation's addend to take in account that the section might be merged with other ones. Here is the reproduction script: % cat t1.s .data .long 0 .text bar: movl $1, .data % cat t2.s .data...

..., 3925868544), > > i32 reloc (29, i32* @dummy, i32 1), 3925868544) > > > > @dummy = internal alias i32* getelementptr (i32, i32* bitcast ([3 x > i32]* @w > > to i32*), i32 1) > > > > This way, you save yourself from needing to worry about manipulating > addends > > in the backend, the linker will take care of it for you. > > That's no worry at all, AsmPrinter::lowerConstant evaluates both > constant expressions to MCExpr: w + 4. > But you still need to worry about how "w + 4" is represented in the object file. > Do yo...

...:46 PM, Peter Smith <peter.smith at linaro.org> wrote: > Hello Simon, > > Can I just check something with you? When I tried the example the > .data section symbols given in the llvm-readelf -r output are > different, one has an offset of 0 and one has an offset of 4 so the > addends don't need updating. In ld the section symbols both have the > same offset of 0 so the addends need updating. So I think the two > approaches are equivalent. > > Have I misunderstood? > > Peter > > On 27 September 2016 at 08:28, Simon Atanasyan via llvm-dev > <llvm...

Hi, Do you have ideas, how to find all those different combinations of integers (>0) that produce as a sum, a certain integer. i.e.: if that sum is 3, the possibilities are c(1,1,1), c(1,2), c(2,1) 4, the possibilities are c(1,1,1,1),c(1,1,2),c(1,2,1),c(2,1,1),c(2,2),c(1,3),c(3,1) etc. Best regards, Atte Tenkanen

...eloc (29, void ()* @f, 3925868544), i32 reloc (29, [3 x i32]* @w, 3925868544), i32 reloc (29, i32* @dummy, i32 1), 3925868544) @dummy = internal alias i32* getelementptr (i32, i32* bitcast ([3 x i32]* @w to i32*), i32 1) This way, you save yourself from needing to worry about manipulating addends in the backend, the linker will take care of it for you. On the other hand, it is possible for a constant expression in the IR > to be lowered to something that is not a valid relocation target, and > it is hard to detect this problem at the IR level. > Right, this is of course a problem...

Hi, I am working on support R_MIPS_HI16 / R_MIPS_LO16 in the new LLD and have a couple of questions. == Q1 In case of MIPS O32 ABI we have to find a matching R_MIPS_LO16 relocation to calculate R_MIPS_HI16 one because R_MIPS_HI16 uses combined addend (AHI << 16) + (short)ALO where AHI is original R_MIPS_HI16 addend and ALO is addend of the matching R_MIPS_LO16 relocation [1]. There are two

On Sat, Nov 21, 2015 at 10:08 AM, Rui Ueyama <ruiu at google.com> wrote: > On Fri, Nov 20, 2015 at 11:02 PM, Simon Atanasyan <simon at atanasyan.com> > wrote: >> >> On Sat, Nov 21, 2015 at 9:28 AM, Rui Ueyama <ruiu at google.com> wrote: >> > On Fri, Nov 20, 2015 at 10:13 PM, Simon Atanasyan <simon at atanasyan.com> >> > wrote: >>

On Sat, Nov 21, 2015 at 9:28 AM, Rui Ueyama <ruiu at google.com> wrote: > On Fri, Nov 20, 2015 at 10:13 PM, Simon Atanasyan <simon at atanasyan.com> > wrote: >> >> In case of MIPS O32 ABI we have to find a matching R_MIPS_LO16 >> relocation to calculate R_MIPS_HI16 one because R_MIPS_HI16 uses >> combined addend (AHI << 16) + (short)ALO where AHI is

...from different sources. Usually we setup it using constant offset from the .got section. Also it might be defined by a linker script. And in rare but possible case it comes from .reginfo / .MIPS.options sections. Got example, GNU bfd linker has the following code to adjust _gp-relative relocation addends: rel->r_addend += _bfd_get_gp_value (input_bfd); rel->r_addend -= _bfd_get_gp_value (output_bfd); But I think we can escape to implement the same adjustments in LLD if we do not support non-zero gp-value in the .reginfo / .MIPS.options sections in input object files. We can get such files...

Hi all, Working on lld aarch64 support I came across an issue where I am not sure which would be best design approach to solve. The aarch64 R_AARCH64_ABS64 relocation for PIC/PIE build requires a dynamic relocation (R_AARCH64_RELATIVE) with the value set as the addend of the relocation. For instance, when linking the crtbeginS.o which contains: Relocation section '.rela.init_array' at

...gt; > > > local exec TLS relocation types, ...) > >> > > > Ignoring the addend (using -2 everywhere) will break this consistency. > >> > > > > >> > > > The relocated code may do pointer subtraction which would work if > >> > addends > >> > > > were > >> > > > respected, but will break using -2 everywhere. > >> > > > >> > > I suspect David meant "any harm to using -2 in all .debug_* sections?" > >> > > and not literally everywhere. Sony...

Hi, Checking the llvm test-suite SingleSource/Regression/C++/EH/class_hierarchy testcase on aarch64 I noted something strange: Dump of assembler code for function _Z4funcj: 0x0000000000400650 <+0>: stp x22, x21, [sp,#-48]! 0x0000000000400654 <+4>: stp x20, x19, [sp,#16] 0x0000000000400658 <+8>: stp x29, x30, [sp,#32] 0x000000000040065c

...location types, ...) > >> >> > > > Ignoring the addend (using -2 everywhere) will break this consistency. > >> >> > > > > >> >> > > > The relocated code may do pointer subtraction which would work if > >> >> > addends > >> >> > > > were > >> >> > > > respected, but will break using -2 everywhere. > >> >> > > > >> >> > > I suspect David meant "any harm to using -2 in all .debug_* sections?" > >> >> &...

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.

Looks like it is also not working on x86_64, using clang/lld I am seeing a segmentation fault: Dump of assembler code for function _Z4funcj: 0x0000000000400590 <+0>: push %rbp 0x0000000000400591 <+1>: push %rbx 0x0000000000400592 <+2>: push %rax 0x0000000000400593 <+3>: mov %edi,%ebp 0x0000000000400595 <+5>: pop %rdx 0x0000000000400596

Hi Akira, This is looking good. Some specific comments on the details below. Thanks! Jim > diff --git a/include/llvm/MC/MCELFObjectWriter.h b/include/llvm/MC/MCELFObjectWriter.h > index 6e9f5d8..220ecd0 100644 > --- a/include/llvm/MC/MCELFObjectWriter.h > +++ b/include/llvm/MC/MCELFObjectWriter.h > @@ -13,6 +13,7 @@ > #include "llvm/MC/MCObjectWriter.h" >