search for: reltype

...+783,19 @@ void RuntimeDyldELF::resolveSystemZReloc void RuntimeDyldELF::resolveRelocation(const RelocationEntry &RE, uint64_t Value) { const SectionEntry &Section = Sections[RE.SectionID]; - return resolveRelocation(Section, RE.Offset, Value, RE.RelType, RE.Addend); + return resolveRelocation(Section, RE.Offset, Value, RE.RelType, RE.Addend, + RE.SymOffset); } void RuntimeDyldELF::resolveRelocation(const SectionEntry &Section, uint64_t Offset,...

...nship id, the notes and the relationshiptype, I''ve got something like this (sorry for all the relatee and relation_tos, etc): def allrelations ar1 = self.relation_froms.find(:all, :include => :relator).collect {|c| {"id" =>c.id, "notes" =>c.notes, "reltype" => c.reltype, "person" =>c.relator} } ar2 = self.relation_tos.find(:all, :include => :relatee).collect {|d| {"id" =>d.id, "notes" =>d.notes, "reltype" => c.reltype, "person"" =>d.relatee} } ar=ar1+ar2 end...

...mbol *Symbol; > + uint64_t r_addend; > + const MCFixup *fixup; > + > + ELFRelocationEntry() > + : r_offset(0), Index(0), Type(0), Symbol(0), r_addend(0), fixup(0) {} > + > + ELFRelocationEntry(uint64_t RelocOffset, int Idx, > + unsigned RelType, const MCSymbol *Sym, > + uint64_t Addend, const MCFixup *Fixup) > + : r_offset(RelocOffset), Index(Idx), Type(RelType), > + Symbol(Sym), r_addend(Addend), fixup(Fixup) {} > + > + // Support lexicographic sorting. > + bool operator<(const...

...64_t r_addend; >> +    const MCFixup *fixup; >> + >> +    ELFRelocationEntry() >> +      : r_offset(0), Index(0), Type(0), Symbol(0), r_addend(0), fixup(0) {} >> + >> +    ELFRelocationEntry(uint64_t RelocOffset, int Idx, >> +                       unsigned RelType, const MCSymbol *Sym, >> +                       uint64_t Addend, const MCFixup *Fixup) >> +      : r_offset(RelocOffset), Index(Idx), Type(RelType), >> +        Symbol(Sym), r_addend(Addend), fixup(Fixup) {} >> + >> +    // Support lexicographic sorting. >> +  ...

...+ const MCFixup *fixup; >>> + >>> + ELFRelocationEntry() >>> + : r_offset(0), Index(0), Type(0), Symbol(0), r_addend(0), fixup(0) {} >>> + >>> + ELFRelocationEntry(uint64_t RelocOffset, int Idx, >>> + unsigned RelType, const MCSymbol *Sym, >>> + uint64_t Addend, const MCFixup *Fixup) >>> + : r_offset(RelocOffset), Index(Idx), Type(RelType), >>> + Symbol(Sym), r_addend(Addend), fixup(Fixup) {} >>> + >>> + // Support lexicographic so...

Here is the patch. On Thu, Mar 22, 2012 at 11:11 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > 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

...to 22 bits (depending on how you count) in size. But on ARMv6T2 onwards the J1 and J2 fields of the instruction form part of the immediate. Technically, I think a linker is allowed to do what you've done so it's probably good enough for now as long as we put an assertion into the code that RelType isn't too big. Second, I don't think it handles BLX correctly. When used on a BLX the instruction is assumed to be at "Align(PC, 4)" rather than just "PC". I *think* this means that if the BLX instruction was at an address "== 2 (mod 4)" then your code would s...

Hello, here is a patch to add Thumb call relocation to the dynamic linker. I would be happy if you could commit it to the SVN. Thank you, Jonas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130524/069287d6/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed...

...gs, "keep-text-section-prefix", "nokeep-text-section-prefix", false); diff --git a/ELF/Relocations.cpp b/ELF/Relocations.cpp index 8f60aa3d2..a54d87e43 100644 --- a/ELF/Relocations.cpp +++ b/ELF/Relocations.cpp @@ -361,6 +361,10 @@ static bool isStaticLinkTimeConstant(RelExpr E, RelType Type, const Symbol &Sym, R_TLSLD_HINT>(E)) return true; + // The computation involves output from the ifunc resolver. + if (Sym.isGnuIFunc() && Config->ZIfuncnoplt) + return false; + // These never do, except if the entire file is position dependent or if...

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

...mpl<std::_Callable_obj<unsigned __int64 <lambda>(void),0>,std::allocator<std::_Func_class<unsigned __int64> >,unsigned __int64>::_Do_call() Line 229 C++ std::_Func_class<unsigned __int64>::operator()() Line 316 C++ llvm::orc::JITSymbol::getAddress() Line 62 C++ RelType is 4 (IMAGE_REL_AMD64_REL32). Value is 139830239098107. Addend is 0. The symbol that is currently being resolved is _fperrraise. I did some researching and it appears that this symbol resides in libcmtd.lib (for me the path is C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib\amd64\libcmt...

On 26 July 2018 at 18:05, Ed Maste <emaste at freebsd.org> wrote: > On 26 July 2018 at 11:08, Peter Smith <peter.smith at linaro.org> wrote: >> On 26 July 2018 at 15:52, Ed Maste <emaste at freebsd.org> wrote: >>> On 27 February 2018 at 09:06, Ed Maste <emaste at freebsd.org> wrote: >>>> >>>> A number of companies are shipping

...mbda>(void),0>,std::allocator<std::_Func_class<unsigned __int64> > >,unsigned __int64>::_Do_call() Line 229 C++ > > std::_Func_class<unsigned __int64>::operator()() Line 316 C++ > > llvm::orc::JITSymbol::getAddress() Line 62 C++ > > > > RelType is 4 (IMAGE_REL_AMD64_REL32). > > Value is 139830239098107. > > Addend is 0. > > > > The symbol that is currently being resolved is _fperrraise. I did some > researching and it appears that this symbol resides in libcmtd.lib (for me > the path is C:\Program Files (x86)...