search for: recordrelocation

On Nov 19, 2010, at 2:05 PM, Rafael Espíndola wrote: > The rest is already in Target, so LGTM :-). Move the > MBlazeELFObjectWriter code to ELFObjectWritter.ccp and lets go from > there. Will do. Again, thank for taking a look at this. -- Wesley Peck University of Kansas SLDG Laboratory

...at 2:05 PM, Rafael Espíndola wrote: > >> The rest is already in Target, so LGTM :-). Move the >> MBlazeELFObjectWriter code to ELFObjectWritter.ccp and lets go from >> there. > > Will do. Again, thank for taking a look at this. Heads up: I just lifted some code from X86::RecordRelocation to ELFObjectWriter - More to follow. Thanks, -jason > > -- > Wesley Peck > University of Kansas > SLDG Laboratory > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu >...

> Heads up: I just lifted some code from X86::RecordRelocation to > ELFObjectWriter - > More to follow. Thanks, How far do you want to go? I was playing with the idea of factoring the relocation recording into another class and moving those to lib/Target/*. That way the ELF writer becomes non-virtual again. > Thanks, > -jason Cheers, Rafael

...ries >> 4. clarity - avoid special case switching as much as possible - >> 5. Xfactor - how clean is the overall resulting design? >> >> The possible  ways forward I see are >> >> SMALL: keep the code nearly as is - place a switch inside >> ELFObjectWriter::RecordRelocation and dispatch to >> ELFObjectWriterImpl::RecordRelocation<ARCH> >> 1. +1 no new classes >> 2. +1 tiny patch >> 3. +1 no new classes, just one additional function so far. >> 4. -2 need to have special case switching for every routine that needs >> to be tweak...

..., but the r_info data element is now 5 separate elements. Besides the content aspects, endian byte reordering will be different for the area with each element being endianized separately. In my mind there are 3 ways to approach this: 1. Treat this as target specific : * ELFObjectWriter::RecordRelocation would need to be derived for N64 implementations 2. Treat this as generic and continue to pass r_type as an integer masking and unmasking the byte sized N64 values for N64 mode. I've implemented this and it causes no affect on other current targets. 3. Treat as generic and changing r_type...

...from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for any target-specific fixups in code, for example). Then the object streamer resolves those fixups, directly if it can or via relocations otherwise via the MCObjectWriter::RecordRelocation() hook. For MachO, that's been moved to a target hook, but for ELF that's directly in ELFObjectWriter.cpp still, including all the target specific bits. For your specific problem, I suspect what needs to happen is something like: 1) In MCELFStreamer(), implement EmitGPRel32Value() to add...

...from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for any target-specific fixups in code, for example). Then the object streamer resolves those fixups, directly if it can or via relocations otherwise via the MCObjectWriter::RecordRelocation() hook. For MachO, that's been moved to a target hook, but for ELF that's directly in ELFObjectWriter.cpp still, including all the target specific bits. For your specific problem, I suspect what needs to happen is something like: 1) In MCELFStreamer(), implement EmitGPRel32Value() to add...

> Would you mind start by adding code to the existing file? Once we have > at least two working architectures we should have a better idea on how > to split it. I can do that. As a note, I just sent another email (before I saw this one) showing how much code was needed to add support for the MBlaze backend. Do you want to take a look at that before I merge the MBlaze stuff into

...t sent another email (before I saw this one) showing how much code was needed to add support for the MBlaze backend. Do you want to take a look at that before I merge the MBlaze stuff into ELFObjectWriter.c? Lets see: * Constructor. Sure, this (or a factory function) will have to be per target. * RecordRelocation. I also expect this to be truly target dependent. The rest is already in Target, so LGTM :-). Move the MBlazeELFObjectWriter code to ELFObjectWritter.ccp and lets go from there. > Thanks for reviewing this. > > -- > Wesley Peck > University of Kansas > SLDG Laboratory > >...

Well Jim, that may just be my problem. As background I am working on the outer reaches of llvm for the direct object output for Mips. Part of what I am to do is instruct the folks working closer to the backend what I am getting that is incorrect. My first reaction is to assume that I am being fed things the correct way and that I am not handling it correctly. I feed the compiler a source file

...from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for any target-specific fixups in code, for example). Then the object streamer resolves those fixups, directly if it can or via relocations otherwise via the MCObjectWriter::RecordRelocation() hook. For MachO, that's been moved to a target hook, but for ELF that's directly in ELFObjectWriter.cpp still, including all the target specific bits. > > For your specific problem, I suspect what needs to happen is something like: > > 1) In MCELFStreamer(), implement EmitG...

On Sun, Dec 4, 2011 at 9:18 AM, Kai <kai at redstar.de> wrote: > Hi! > > LLVM currently does not implement the implicit TLS model on Windows. This > model is easy: > > - a thread local variable ends up in the .tls section > - to access a thread local variable, you have to do >  (1) load pointer to thread local storage from TEB >      On x86_64, this is gs:0x58, on

...Fx86_64. I took a look at the link provided earlier and noticed a few things... - LLILC provides a resolver that simply returns UINT64_MAX for any given symbol, which the comment explains indicates means that we want to skip relocation resolution and that the client code will handle it manually. - recordRelocations is supposed to be that “manual handling” This raises the following questions: 1) Forgive the noobishness of this, but what is meant by “external” relocations? Something in a DLL? A static library? Something akin to a function declaration in C++ where the definition is not provided (similar to the...

Hi! LLVM currently does not implement the implicit TLS model on Windows. This model is easy: - a thread local variable ends up in the .tls section - to access a thread local variable, you have to do (1) load pointer to thread local storage from TEB On x86_64, this is gs:0x58, on x86 it is fs:0x2C. (2) load pointer to thread local state. In general, the index is stored in variable

...I how exactly does one set an expression to be PC relative and if the > compiler can resolve it, not produce a relocation? > Fixups are created for all expressions that may need a relocation. The MC layer evaluates them as best it can (MCAssembler::EvaluateFixup()) and calls the target hook RecordRelocation() if it cannot evaluate it directly and needs a relocation in the object file. > In our case, the backend produces an expression for the branch which is > the target label. I make a call from the .td for the branch instruction > which calls a routine in MipsMCCodeEmmitter.cpp. That routi...

...e tweak to move the relocation type out to the top level, there shouldn't need to be any explicit scope resolution. > /// The target specific ELF writer instance. > llvm::OwningPtr<MCELFObjectTargetWriter> TargetObjectWriter; > @@ -786,7 +762,7 @@ void ELFObjectWriter::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->getPa...

Gang, I'm tasked with direct object generation for Mips and am trying to not hack the code. I how exactly does one set an expression to be PC relative and if the compiler can resolve it, not produce a relocation? In our case, the backend produces an expression for the branch which is the target label. I make a call from the .td for the branch instruction which calls a routine in

...the relocation type out to the top level, there shouldn't need to be any explicit scope resolution. > >>      /// The target specific ELF writer instance. >>      llvm::OwningPtr<MCELFObjectTargetWriter> TargetObjectWriter; >> @@ -786,7 +762,7 @@ void ELFObjectWriter::RecordRelocation(const MCAssembler &Asm, >>    else >>      assert(isInt<32>(Addend)); >> >> -  ELFRelocationEntry ERE(RelocOffset, Index, Type, RelocSymbol, Addend); >> +  ELFRelocationEntry ERE(RelocOffset, Index, Type, RelocSymbol, Addend, &Fixup); >>    Relocati...

...pe out to the top level, there shouldn't need to be any explicit scope resolution. >> >>> /// The target specific ELF writer instance. >>> llvm::OwningPtr<MCELFObjectTargetWriter> TargetObjectWriter; >>> @@ -786,7 +762,7 @@ void ELFObjectWriter::RecordRelocation(const MCAssembler &Asm, >>> else >>> assert(isInt<32>(Addend)); >>> >>> - ELFRelocationEntry ERE(RelocOffset, Index, Type, RelocSymbol, Addend); >>> + ELFRelocationEntry ERE(RelocOffset, Index, Type, RelocSymbol, Addend, &Fixup);...

...from the generic streamer stuff (see MCObjectStreamer::EmitValueImpl() for example), or from the target's MCCodeEmitter (for any target-specific fixups in code, for example).  Then the object streamer resolves those fixups, directly if it can or via relocations otherwise via the MCObjectWriter::RecordRelocation() hook.  For MachO, that's been moved to a target hook, but for ELF that's directly in ELFObjectWriter.cpp still, including all the target specific bits. >> >> For your specific problem, I suspect what needs to happen is something like: >> >> 1) In MCELFStreamer(), i...