search for: relocations

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

...CH64_ABS64 one and thus will need to create a dynamic R_AARCH64_RELATIVE relocation. Also from comments at ELF/Writer.cpp:243 I noted that scanRelocs is done early as a design choice. So I am not sure if it would be best to follow the second idea of the comment (and do the scan later *after* the relocations is computed) or if it would be better to allow the TargetInfo add a scan phase to handle such things (as other linker does). Suggestions, tips, advices?

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

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

...<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 to the "Section" element. So a YAML file will look like below....

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

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

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

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

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

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

...d R_MIPS_HI16 >> >> calculation. >> >> >> >> Method A: >> >> 1. Postpone R_MIPS_HI16 relocation calculation and record its >> >> arguments. >> >> 2. When R_MIPS_LO16 is found, iterate over recorded R_MIPS_HI16 >> >> relocations, calculate combined addend and apply relocations. >> >> 3. At the end check orphaned (without R_MIPS_LO16 pair) R_MIPS_HI16 >> >> relocations, show warnings and apply them with zero addend. >> >> >> >> Method B: >> >> 1. Each time we have...

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

...ObjectWriter::RecordRelocation(const MCAssembler &Asm, > else > assert(isInt<32>(Addend)); > > - ELFRelocationEntry ERE(RelocOffset, Index, Type, RelocSymbol, Addend); > + ELFRelocationEntry ERE(RelocOffset, Index, Type, RelocSymbol, Addend, &Fixup); > Relocations[Fragment->getParent()].push_back(ERE); > } > > @@ -1072,8 +1048,7 @@ void ELFObjectWriter::WriteRelocationsFragment(const MCAssembler &Asm, > MCDataFragment *F, > const MCSection...

...PS_LO16 >> relocation [1]. There are two methods to do matching and R_MIPS_HI16 >> calculation. >> >> Method A: >> 1. Postpone R_MIPS_HI16 relocation calculation and record its arguments. >> 2. When R_MIPS_LO16 is found, iterate over recorded R_MIPS_HI16 >> relocations, calculate combined addend and apply relocations. >> 3. At the end check orphaned (without R_MIPS_LO16 pair) R_MIPS_HI16 >> relocations, show warnings and apply them with zero addend. >> >> Method B: >> 1. Each time we have found R_MIPS_HI16 relocation, iterate remaini...

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 z29.s lw $3, %got(scope_top)($gp) lw $2, %got(body_ok)($gp) l...