search for: reloc

...image mapping section .data at 0x459000 off 59000 size 5000 flags c0000040 trace:module:map_image mapping section .idata at 0x460000 off 5e000 size 1000 flags c0000040 trace:module:map_image mapping section .rsrc at 0x461000 off 5f000 size 1000 flags 40000040 trace:module:map_image mapping section .reloc at 0x462000 off 60000 size 3000 flags 42000040 trace:module:load_library loaded ntdll.dll 0x403814cc 40050000 trace:module:GetModuleFileNameA C:\windows\desktop\pro666\Debug\PRO666.exe trace:module:MODULE_GetLoadOrder looking for C:\windows\system\user32.dll trace:module:GetModuleFileNameA C:\windo...

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

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

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

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

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

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

...gt; >> > <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 0xfffffe in the > >> >> original proposal. This is aligned w...

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

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

...t; 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 0xfffffe in the > >> original proposal. This is aligned with the way LLVM emits relocations > >&...

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

- 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 ++++++++++++++ src/gallium/d...

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

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

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