search for: relocate

I have written a directdraw program in dx7 that i can get working under wine. I have now written a simple directx8 3d program that works under windows but i am getting these wierd errors under wine. this is the output from wine -debugmsg +module pro666 I think it is a problem with the two libraries d3d8.lib and d3dx8.lib as I can see errors there. Also I notice that these are the two libraries

...g to made this on lld, but current step sequence is: - Write::run \_ Write::createSections \_ Write::scanRelocs \_ Write::addReloc // Dynamic Relocation creation \_ Write::writeSections \_ OutputSectionBase::writeTo \_ InputSection::writeTo \_ InputSection::relocate \_ TargetInfo::relocateOne The problem is only at TargetInfo::relocate the target (aarch64) will see that the relocation is a R_AARCH64_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 i...

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

...on type * r_type - first relocation type Up to three these relocations applied one by one. The first relocation uses an addendum from the relocation record. Each subsequent relocation takes as its addend the result of the previous operation. Only the final operation actually modifies the location relocated. The first relocation uses as a reference symbol specified by the r_sym field. The third relocation assumes NULL symbol. The most interesting case is the second relocation. It uses the special symbol value given by the r_ssym field. This field can contain four predefined values: * RSS_UNDEF - zer...

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 calculated relocation addend back into the Reference object in the...

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

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

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

...read, 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 > >> >> in the backend, and avoids encoding the addend in a > >> >> relocation-specific way in the IR. > >> > > >> &...

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.

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

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

...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 > >> in the backend, and avoids encoding the addend in a > >> relocation-specific way in the IR. > > > > > > I am confused by this statement. If...

...to three these relocations applied one by one. The first relocation >> uses >> an addendum from the relocation record. Each subsequent relocation takes >> as >> its addend the result of the previous operation. Only the final operation >> actually modifies the location relocated. The first relocation uses as >> a reference symbol specified by the r_sym field. The third relocation >> assumes NULL symbol. >> >> The most interesting case is the second relocation. It uses the special >> symbol value given by the r_ssym field. This field can conta...

On Sat, Nov 21, 2015 at 10:08 AM, Rui Ueyama <ruiu at google.com> wrote: > On Fri, Nov 20, 2015 at 11:02 PM, Simon Atanasyan <simon at atanasyan.com> > wrote: >> >> 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: >>

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

...ping 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 code complexity to >> me when I wanted to set calculated relocation a...

Hi Akira, This is looking good. Some specific comments on the details below. Thanks! Jim > diff --git a/include/llvm/MC/MCELFObjectWriter.h b/include/llvm/MC/MCELFObjectWriter.h > index 6e9f5d8..220ecd0 100644 > --- a/include/llvm/MC/MCELFObjectWriter.h > +++ b/include/llvm/MC/MCELFObjectWriter.h > @@ -13,6 +13,7 @@ > #include "llvm/MC/MCObjectWriter.h" >

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

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