search for: r_offset

...7,6 +28,33 @@ protected: > uint16_t EMachine_, bool HasRelocationAddend_); > > 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(u...

...                           uint16_t EMachine_,  bool HasRelocationAddend_); >> >>  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) {} >&...

..._t EMachine_, bool HasRelocationAddend_); >>> >>> 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)...

...00000000   .bss // %lo(body_ok) > > > The attached patch makes the following changes to make direct object > emitter write out relocations in the correct order: > > 1. Add a target hook MCELFObjectTargetWriter::ReorderRelocs. The > default behavior sorts the relocations by the r_offset. > 2. Move struct ELFRelocationEntry from ELFObjectWriter to > MCELFObjectTargetWriter and add member fixup to it. The overridden > version of ReorderRelocs (MipsELFObjectWriter::ReorderRelocs) needs > access to ELFRelocationEntry::Type and MCFixup::Value to reorder the > relocations...

...0754 00000406 R_MIPS_LO16 00000000 .bss // %lo(body_ok) The attached patch makes the following changes to make direct object emitter write out relocations in the correct order: 1. Add a target hook MCELFObjectTargetWriter::ReorderRelocs. The default behavior sorts the relocations by the r_offset. 2. Move struct ELFRelocationEntry from ELFObjectWriter to MCELFObjectTargetWriter and add member fixup to it. The overridden version of ReorderRelocs (MipsELFObjectWriter::ReorderRelocs) needs access to ELFRelocationEntry::Type and MCFixup::Value to reorder the relocations. Do you think these cha...

...elative->r_data); > ElfW(Addr) bits = ELFW(R_BITS) (relative->r_data); > offset += jump * sizeof(ElfW(Addr)); > if (jump == 0) > { > ++relative; > offset = relative->r_data; > } > ElfW(Addr) r_offset = offset; > for (; bits != 0; bits >>= 1) > { > if ((bits&1) != 0) > elf_machine_relrz_relative (l_addr, (void *) (l_addr + r_offset)); > r_offset += sizeof(ElfW(Addr)); > } > } > } > #end...

...e treated as target specific? My contention is that it should be treated as an alternative generic format handled recognized and handled in the ELF class objects above the target specific level. 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; /* Addres...

...rev [...] > ELFDefinedAtom<ELFT> *createDefinedAtomAndAssignRelocations( > StringRef symbolName, StringRef sectionName, const Elf_Sym *symbol, > const Elf_Shdr *section, ArrayRef<uint8_t> content) { > @@ -380,6 +534,11 @@ private: > (ri->r_offset < symbol->st_value + content.size())) { > auto *ERef = new (_readerStorage) > ELFReference<ELFT>(ri, ri->r_offset - symbol->st_value, nullptr); > + // Read the addend from the section contents > + // TODO : We should move the...

...- they would be required 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...

...#39;t do: > for (int* ptr=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;...

...= 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]}: >> 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),...

...l.Addend, AddrLoc, *Rel.Sym, Expr), Bits); Looking at your calculation for AddrLoc, it seems like your calculation doesn't match the original as Offset is (in trunk lld, your diff is a against an old version, but I think the line hasn't changed semantically) uint64_t Offset = getOffset(Rel.r_offset); which for a regular InputSection will expand to uint64_t Offset = this->OutSecOff + Rel.r_offset; Original: AddrLoc = getOutputSection()->Addr + this->OutSecOff + Rel.r_offset; Yours: AddrLoc = (getOutputSection()->Addr /* output_section->vma */ + cast<InputSect...

...t = 3 and this is somehow confirmed by the code in MCAsmStreamer::AddEncodingComment. All the relocation bits are correctly identified if I emit the encoding of an instruction. The other use of MCFixup.Offset is in MCELFStreamer::EmitInstToData and it looks like it uses MCFixup.Offset to calculate r_offset (Elf32) which is not what I was expecting because I get a slightly skewed offset (off by MCFixup.Offset). I can obviously create the relocation with MCFixup.Offset to be 0 (which most of the targets do) but the code in MCAsmStreamer::AddEncodingComment will not work as expected (identification of...

+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

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

Hello Leslie, I think we are going to need to know a bit more about the ELF ABI for what looks like the ArcCompact before we can help you. LLD's calculation of P (the place to be relocated) is as it is in the generic ELF specification. The Rel.Offset corresponds to the ELF r_offset field. This is covered by: "For a relocatable file, the value is the byte offset from the beginning of the section to the storage unit affected by the relocation." For LLD we are calculating the virtual address (VA) of P, as I understand it this is equivalent to the vma used in BFD. Assu...

Hello everybody, I would like some insights on the semantics of the X86_64_RELOC_UNSIGNED relocation type. When r_extern=1, the semantics seem pretty clear: Let x be a pointer to r_offset of appropriate size given by r_size, then *x += addr_of_symbol(r_symbolnum) However, when r_extern=0 the correct behavior is not clear. By analogy with the above, I would have expected *x += addr_of_section(r_symbolnum) but what LLVM implements is different. In RTDyld it implements *x = (*x-add...

...ElfW(Addr) jump = ELFW(R_JUMP) (relative->r_data); ElfW(Addr) bits = ELFW(R_BITS) (relative->r_data); offset += jump * sizeof(ElfW(Addr)); if (jump == 0) { ++relative; offset = relative->r_data; } ElfW(Addr) r_offset = offset; for (; bits != 0; bits >>= 1) { if ((bits&1) != 0) elf_machine_relrz_relative (l_addr, (void *) (l_addr + r_offset)); r_offset += sizeof(ElfW(Addr)); } } } #endif Note that the 8-bit 'jump' encode...

...(R_BITS) (relative->r_data); >>> offset += jump * sizeof(ElfW(Addr)); >>> if (jump == 0) >>> { >>> ++relative; >>> offset = relative->r_data; >>> } >>> ElfW(Addr) r_offset = offset; >>> for (; bits != 0; bits >>= 1) >>> { >>> if ((bits&1) != 0) >>> elf_machine_relrz_relative (l_addr, (void *) (l_addr + r_offset)); >>> r_offset += sizeof(ElfW(Addr)); >>...

...for-synopsys-dwc-arc-processors/binutils-gdb/blob/arc-2017.09/bfd/elf32-arc.c#L1156 >>> >>> >>>> LLD's calculation of P (the place to be relocated) is as it is in the >>>> generic ELF specification. The Rel.Offset corresponds to the ELF >>>> r_offset field. This is covered by: "For a relocatable file, the value >>>> is the byte offset from the beginning of the section to the storage >>>> unit affected by the relocation." >>>> >>>> For LLD we are calculating the virtual address (VA) of P,...