search for: relocation

...000 trace:module:map_image mapping section .data1 at 0x5ca000 off 161800 size 5000 flags c0000040 trace:module:map_image mapping section .rsrc at 0x5cf000 off 166800 size 600 flags 40000040 trace:module:map_image mapping section .reloc at 0x5d0000 off 166e00 size ec00 flags 42000040 trace:module:do_relocations 44 relocations for page a000 trace:module:do_relocations 20 relocations for page c000 trace:module:do_relocations 20 relocations for page d000 trace:module:do_relocations 28 relocations for page e000 trace:module:do_relocations 404 relocations for page f000 trace:module:do_relocations 16 relocatio...

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 offset 0xd28 contains 1 entries: Offset Info T...

...#39;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. Assuming that the relocation is relocating a regular InputSection from the basic-arc.o object then the LLD calculation of P = getOutputSection()->Addr + getOffset(Rel.O...

Hi, I need an advice on implementation of a very specific kind of relocations used by MIPS N64 ABI. As usual the main problem is how to pass target specific data over Native/YAML conversion barrier. In this ABI relocation record r_info field in fact consists of five subfields: * r_sym - symbol index * r_ssym - special symbol * r_type3 - third relocation type * r_type2 -...

A bit off topic: ARM Group relocations define a logical set of consequent instructions to be relocated to form one single address. For such relocations a 1 to 1 relation is also met, so no need of special processing in applyRelocation. Concerning native format: it also introduced unneeded code complexity to me when I wanted to set cal...

Hi, On Wed, Apr 2, 2014 at 1:03 AM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Mon, Mar 31, 2014 at 10:54 AM, Simon Atanasyan <simon at atanasyan.com> wrote: >> As far as I understand now it is impossible to generate ELF object >> file with relocation sections using yaml2obj tool. I plan to support >> ELF relocations in the yaml2obj. Does anybody work on it already or >> plan to start this task soon? > > I know of nobody working on this. It would be great to have, thanks! I am going to add "Relocations" optional list...

Hi Lang, Can you please let me know you think it would be right to modify RuntimeDyldImpl::resolveExternalSymbols to allow resolvers to return 0 addresses? Something like this would be ideal for me: void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); StringRef Name = i->first(); if (Name.size() == 0) { // This is an absolute symbol, use an address of zero. DEBUG(dbgs() << "Resolving absolute relocations."...

Hello, I'm working on LLILC (a jit for the CoreCLR built on ORC), in particular, on using LLILC as an ngen jit. I would like to have an ability to be notified of relocations that ObjectLinkingLayer is applying and to be able to tell the linking layer not to resolve certain relocations for external symbols (so that the client can do some custom resolutions later). The only way I found of looking at relocations in the client is via NotifyLoadedFtor notifications but I...

...4) > >> >> ; 29 = 0x1d = R_ARM_JUMP24 > >> >> ; 3925868544 = 0xea000000 > >> >> > >> >> Note the zeroes in the relocated data instead of 0xfffffe in the > >> >> original proposal. This is aligned with the way LLVM emits > relocations > >> >> in the backend, and avoids encoding the addend in a > >> >> relocation-specific way in the IR. > >> > > >> > > >> > I am confused by this statement. If the zeros aren't what appear in > the > >> > object f...

Hi Lang, Yes, I can return a non-zero marker value. Are you ok with this version? void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); StringRef Name = i->first(); if (Name.size() == 0) { // This is an absolute symbol, use an address of zero. DEBUG(dbgs() << "Resolving absolute relocations."...

We can't copy_*_user while holding reservations, that will (soon even for nouveau) lead to deadlocks. And it breaks the cross-driver contract around dma_resv. Fix this by adding a slowpath for when we need relocations, and by pushing the writeback of the new presumed offsets to the very end. Aside from "it compiles" entirely untested unfortunately. Signed-off-by: Daniel Vetter <daniel.vetter at intel.com> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org --- dr...

On Sun, Nov 22, 2015 at 1:28 AM, Rui Ueyama <ruiu at google.com> wrote: > I'm not sure if I understand the semantics of HI16 and LO16 relocations. If > my understanding is correct, a pair of HI16 and LO16 represents an addend > AHL. AHL is computed by (AHI<<16) | (ALO&0xFFFF). Can't we apply HI16 and > LO16 relocations separately and produce the same relocation result? Do we > have to pair them up before applying r...

...gt; >> i32 reloc (29, void ()* @f, 3925868544) > >> ; 29 = 0x1d = R_ARM_JUMP24 > >> ; 3925868544 = 0xea000000 > >> > >> Note the zeroes in the relocated data instead of 0xfffffe in the > >> original proposal. This is aligned with the way LLVM emits relocations > >> in the backend, and avoids encoding the addend in a > >> relocation-specific way in the IR. > > > > > > I am confused by this statement. If the zeros aren't what appear in the > > object file, it seems rather relocation specific to me. > > T...

...come up over and over again, we need something in the Atom model > to store information that is target specific. > > Shankar Easwaran > > > On 2/5/2015 2:22 PM, Simon Atanasyan wrote: > >> Hi, >> >> I need an advice on implementation of a very specific kind of relocations >> used by MIPS N64 ABI. As usual the main problem is how to pass target >> specific >> data over Native/YAML conversion barrier. >> >> In this ABI relocation record r_info field in fact consists of five >> subfields: >> * r_sym - symbol index >> *...

...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 original >> >> R_MIPS_HI16 addend and ALO is addend of the matching R_MIPS_LO16 >> >> relocation [1]. There are two methods to do matching and...

- NV30 and NV40 need testing. - I'll take better naming suggestions for so_get_push_reloc(). --- src/gallium/drivers/nouveau/nouveau_stateobj.h | 49 +++++++++++++++++++----- src/gallium/drivers/nv04/nv04_surface_2d.c | 9 +++- src/gallium/drivers/nv30/nv30_state_emit.c | 26 ++++++++++++ src/gallium/drivers/nv40/nv40_state_emit.c | 30 ++++++++++++++

...und-trip > tests do more than that, right? The tests require more -- dumping linker > internal state to a file and reading it correctly. > > On Mon, Feb 9, 2015 at 4:33 AM, Denis Protivensky < > dprotivensky at accesssoftek.com> wrote: > >> A bit off topic: ARM Group relocations define a logical set of consequent >> instructions to be relocated to form one single address. For such >> relocations a 1 to 1 relation is also met, so no need of special processing >> in applyRelocation. >> >> Concerning native format: it also introduced unneeded co...

...h" > #include "llvm/Support/DataTypes.h" > #include "llvm/Support/ELF.h" > +#include <vector> > > namespace llvm { > class MCELFObjectTargetWriter { > @@ -27,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; > +...

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 original >> R_MIPS_HI16 addend and ALO is addend of the matching R_MIPS_LO16 >> relocation [1]. There are two methods to do matching and R_MIPS_HI16 >> calcul...

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