search for: r_addend

...; > public: > + /// @name Relocation Data > + /// @{ > + > + struct ELFRelocationEntry { > + // Make these big enough for both 32-bit and 64-bit > + uint64_t r_offset; > + int Index; > + unsigned Type; > + const MCSymbol *Symbol; > + uint64_t r_addend; > + const MCFixup *fixup; > + > + ELFRelocationEntry() > + : r_offset(0), Index(0), Type(0), Symbol(0), r_addend(0), fixup(0) {} > + > + ELFRelocationEntry(uint64_t RelocOffset, int Idx, > + unsigned RelType, const MCSymbol *Sym, > +...

...Relocation Data >> +  /// @{ >> + >> +  struct ELFRelocationEntry { >> +    // Make these big enough for both 32-bit and 64-bit >> +    uint64_t r_offset; >> +    int Index; >> +    unsigned Type; >> +    const MCSymbol *Symbol; >> +    uint64_t r_addend; >> +    const MCFixup *fixup; >> + >> +    ELFRelocationEntry() >> +      : r_offset(0), Index(0), Type(0), Symbol(0), r_addend(0), fixup(0) {} >> + >> +    ELFRelocationEntry(uint64_t RelocOffset, int Idx, >> +                       unsigned RelType, cons...

...@{ >>> + >>> + struct ELFRelocationEntry { >>> + // Make these big enough for both 32-bit and 64-bit >>> + uint64_t r_offset; >>> + int Index; >>> + unsigned Type; >>> + const MCSymbol *Symbol; >>> + uint64_t r_addend; >>> + const MCFixup *fixup; >>> + >>> + ELFRelocationEntry() >>> + : r_offset(0), Index(0), Type(0), Symbol(0), r_addend(0), fixup(0) {} >>> + >>> + ELFRelocationEntry(uint64_t RelocOffset, int Idx, >>> +...

...rces. 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 if somebody produce...

.... Most architectures have the following 64 bit relocation record format: typedef struct { Elf64_Addr r_offset; /* Address of reference */ Elf64_Xword r_info; /* Symbol index and type of relocation */ } Elf64_Rel; typedef struct { Elf64_Addr r_offset; Elf64_Xword r_info; Elf64_Sxword r_addend; } Elf64_Rela; Whereas N64 has the following format: typedef struct { Elf64_Addr r_offset; /* Address of reference */ Elf64_Word r_sym; /* Symbol index */ Elf64_Byte r_ssym; /* Special symbol */ Elf64_Byte r_type3; /* Relocation type */ Elf64_Byte r_type2; /* Relocation type */...

Here is the patch. On Thu, Mar 22, 2012 at 11:11 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Hi Jim, > > Yes, the relocation entries have to be reordered so that the > got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation > table. As a result, relocations can appear in a different order than > the instructions that they're for. > > For

...uired to retrieve and insert the memory tag of the symbol into the relocated value. For example, the ABS64 relocation becomes: sym_addr = get_symbol_address() // sym_addr = 0x1008 sym_addr |= get_tag(sym_addr & 0xf) // get_tag(0x1008 & 0xf == 0x1000) *r_offset = sym_addr + r_addend; 2. Introduce a TAGGED_RELATIVE relocation - in order to solve the problem where the tag derivation shouldn't be from the relocation result, e.g. static int array[16] = {}; // array_end must have the same tag as array[]. array_end is out of // bounds w.r.t. array, and may poi...

...r=array; ptr != array_end; ++ptr) > Since it's always != due to the tags. > Do I have that right? Yep - you've got it right, this is why we need TAGGED_RELATIVE. For clarity, here's the memory layout where array_end is relocated using TAGGED_RELATIVE{*r_offset = &array[16], r_addend = &array[0]}: array array_end (padding) Memory Tag 0x1 0x1 0x2 0x2 Value 0 0 0 0 (0x1 << 56) | &array[16] 0 0 So the address tag of `array` and `array_end` are the same (only `&array_end` has an memory/address tag of 0x2), and thus `for (int* ptr=array; ptr != array_end; ++ptr)` w...

...ned long int get_module_load_offset(void) } #endif +#ifdef CONFIG_X86_PIE +static u64 find_got_kernel_entry(Elf64_Sym *sym, const Elf64_Rela *rela) +{ + u64 *pos; + + for (pos = (u64*)__start_got; pos < (u64*)__end_got; pos++) { + if (*pos == sym->st_value) + return (u64)pos + rela->r_addend; + } + + return 0; +} + +static u64 module_emit_got_entry(struct module *mod, void *loc, + const Elf64_Rela *rela, Elf64_Sym *sym) +{ + struct mod_got_sec *gotsec = &mod->arch.core; + u64 *got = (u64*)gotsec->got->sh_addr; + int i = gotsec->got_num_entries; + u64 ret; + + /* Che...

...location on the shared object should be: Relocation section '.rela.dyn' at offset 0x548 contains 10 entries: Offset Info Type Sym. Value Sym. Name + Addend 000000010dc0 000000000403 R_AARCH64_RELATIV 7a8 Where 0x7a8 (dynamic relocation r_addend) points to a function at .text segment (in this case frame_dummy). I am trying to made this on lld, but current step sequence is: - Write::run \_ Write::createSections \_ Write::scanRelocs \_ Write::addReloc // Dynamic Relocation creation \_ Write::writeSections \_ OutputSec...

...;> Since it's always != due to the tags. >>> Do I have that right? >> >> >> Yep - you've got it right, this is why we need TAGGED_RELATIVE. For clarity, here's the memory layout where array_end is relocated using TAGGED_RELATIVE{*r_offset = &array[16], r_addend = &array[0]}: >> arrayarray_end(padding) >> Memory Tag0x10x10x20x2 >> Value0000(0x1 << 56) | &array[16]00 >> >> So the address tag of `array` and `array_end` are the same (only `&array_end` has an memory/address tag of 0x2), and thus `for (int* ptr=ar...

Hi Jim, Yes, the relocation entries have to be reordered so that the got16/lo16 or hi16/lo16 pairs appear consecutively in the relocation table. As a result, relocations can appear in a different order than the instructions that they're for. For example, in this code, the post-RA scheduler inserts an instruction with relocation %got(body_ok) between %got(scope_top) and %lo(scope_top). $ cat

...symbol into > the > > relocated value. For example, the ABS64 relocation becomes: > > sym_addr = get_symbol_address() // sym_addr = 0x1008 > > sym_addr |= get_tag(sym_addr & 0xf) // get_tag(0x1008 & 0xf == > 0x1000) > > *r_offset = sym_addr + r_addend; > > 2. > > > > Introduce a TAGGED_RELATIVE relocation - in order to solve the problem > > where the tag derivation shouldn't be from the relocation result, e.g. > > static int array[16] = {}; > > // array_end must have the same tag as array[]....

You are right. LLD does not have this problem. Initially I bumped into the MIPS specific bug related to GP relative relocations calculation. I tried to make reproduction script as general as possible and mistakenly make it too general. So now with your help I realized that the problem solely affects MIPS. On Tue, Sep 27, 2016 at 8:46 PM, Peter Smith <peter.smith at linaro.org> wrote: >

...void processRelocAux(InputSectionBase &Sec, RelExpr Expr, RelType Type, Sec.Relocations.push_back({Expr, Type, Offset, Addend, &Sym}); return; } + if (Sym.isGnuIFunc() && Config->ZIfuncnoplt) { + InX::RelaDyn->addReloc(Type, &Sec, Offset, &Sym, Addend, R_ADDEND, Type); + return; + } bool CanWrite = (Sec.Flags & SHF_WRITE) || !Config->ZText; if (CanWrite) { // R_GOT refers to a position in the got, even if the symbol is preemptible. @@ -977,7 +985,7 @@ static void scanReloc(InputSectionBase &Sec, OffsetGetter &GetOffset, RelTy...

...evel. > Right, this is of course a problem we already have for aliasees and constant initializers. > Also, separating the addend from the section data allows the backend > to choose between .rel and .rela representations. > Do you have an example of a rela relocation which uses both r_addend and the underlying value in the object file? Peter > On Wed, Aug 26, 2015 at 3:29 PM, Peter Collingbourne via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > On Wed, Aug 26, 2015 at 03:53:33PM -0400, Rafael Espíndola wrote: > >> > I'm not sure if this would b...

...>> >> > >> >> Also, separating the addend from the section data allows the backend > >> >> to choose between .rel and .rela representations. > >> > > >> > > >> > Do you have an example of a rela relocation which uses both r_addend > and > >> > the > >> > underlying value in the object file? > >> > >> The point of .rela is to allow addends that do not fit into the > >> underlying value. Such addends can not be expressed as the third > >> argument of reloc(), eithe...

...> constant > > initializers. > > > >> > >> Also, separating the addend from the section data allows the backend > >> to choose between .rel and .rela representations. > > > > > > Do you have an example of a rela relocation which uses both r_addend and > the > > underlying value in the object file? > > The point of .rela is to allow addends that do not fit into the > underlying value. Such addends can not be expressed as the third > argument of reloc(), either. And IMHO the middleend should not worry > about such detai...

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.

Changes: - patch v2: - Adapt patch to work post KPTI and compiler changes - Redo all performance testing with latest configs and compilers - Simplify mov macro on PIE (MOVABS now) - Reduce GOT footprint - patch v1: - Simplify ftrace implementation. - Use gcc mstack-protector-guard-reg=%gs with PIE when possible. - rfc v3: - Use --emit-relocs instead of -pie to reduce