search for: mcsymbol

Right now MC is optimized for emitting assembly, but as Rafael pointed out to me over IRC the optimized path should be emitting object files. This WIP patch moves MCSymbolData into MCSymbol.h and makes it a field inside MCSymbol. This eliminates a pointer from MCSymbolData back to MCSymbol, the DenseMap<const MCSymbol *, MCSymbolData *> in MCAssembler, and converts the iplist in MCAssembler into a std::vector (along with some churn to pass around MCSymbols ins...

...comments: -- > diff --git a/lib/MC/WinCOFFStreamer.cpp b/lib/MC/WinCOFFStreamer.cpp > index 1030cdb..079a813 100644 > --- a/lib/MC/WinCOFFStreamer.cpp > +++ b/lib/MC/WinCOFFStreamer.cpp > @@ -18,24 +18,41 @@ > #include "llvm/MC/MCSection.h" > #include "llvm/MC/MCSymbol.h" > #include "llvm/MC/MCExpr.h" > +#include "llvm/MC/MCValue.h" > +#include "llvm/MC/MCAssembler.h" > +#include "llvm/MC/MCAsmLayout.h" > #include "llvm/MC/MCCodeEmitter.h" > #include "llvm/MC/MCSectionCOFF.h" &g...

On Sun, Jul 11, 2010 at 6:10 PM, Chris Lattner <clattner at apple.com> wrote: > This probably needs to be slightly tweaked to work with mainline.  I don't see anything objectionable, but I think Daniel needs to review this one. Updated patch to work with mainline. http://github.com/Bigcheese/llvm-mirror/commit/d19a4c82c18afc4830c09b70f02d162292231c94 - Michael Spencer

Hi all, When emitting GC information, it can be very useful to emit the debug location of a GC point, represented as a MCSymbol. Infortunately I haven't found any API (JIT and codegen) where I can get from a MCSymbol to a DebugLoc. Does that interface exist? If not, I plan on committing a small change in the GC code where the debug location is passed to the constructor of a GC point. Patch attached. Cheers, Nicolas --...

...er, MCAssembler *Assembler) - : MCObjectStreamer(Context, TAB, OS, Emitter, Assembler) {} + : MCObjectStreamer(Context, TAB, OS, Emitter, Assembler), + IsThumb(false), MappingSymbolCounter(0) {} ~MCELFStreamer() {} @@ -58,6 +60,7 @@ public: virtual void EmitLabel(MCSymbol *Symbol); virtual void EmitAssemblerFlag(MCAssemblerFlag Flag); virtual void EmitThumbFunc(MCSymbol *Func); + virtual void EmitDataRegion(MCDataRegionType Kind); virtual void EmitAssignment(MCSymbol *Symbol, const MCExpr *Value); virtual void EmitWeakReference(MCSymbol *Alias, const MC...

Ok, I've isolated the recent additions that cause the issue and supplied a patch which is NOT meant to be applied, but instead solely exists for identification purposes for those who know what they are doing. :-) The patch is offset from HEAD. The patch is a hack which removes use of the MCSymbol::isDefined(...) method, as its use happens to break in the exception JIT context; both in MachineModuleInfo.:: TidyLandingPads(...) and in JITDwarfException:: EmitFrameMoves(...). In this context these symbols are not defined but rather are temporaries. Beyond this I don't understand what the c...

On Sep 12, 2010, at 9:44 AM, nicolas geoffray wrote: > Hi all, > > When emitting GC information, it can be very useful to emit the debug location of a GC point, represented as a MCSymbol. Infortunately I haven't found any API (JIT and codegen) where I can get from a MCSymbol to a DebugLoc. Does that interface exist? If not, I plan on committing a small change in the GC code where the debug location is passed to the constructor of a GC point. Patch attached. I do not know anyt...

Attached is an example of how to reproduce the issue. It uses a C file that happens to has a bunch of switch statements which are encoded as jump tables, giving us data-in-code. Usage: To build object files with clang via the -integrated-as versus via GCC: $ export NDK_DIR=<my_ndk_dir> $ export LLVM_DIR=<my_llvm_bin_dir> $ make To test that the generated objects contain the same

...solated the recent additions that cause the issue and supplied a patch which is NOT meant > to be applied, but instead solely exists for identification purposes for those who know what they are doing. :-) > The patch is offset from HEAD. > > The patch is a hack which removes use of the MCSymbol::isDefined(...) method, as its use happens to break > in the exception JIT context; both in MachineModuleInfo.:: TidyLandingPads(...) and in JITDwarfException:: > EmitFrameMoves(...). In this context these symbols are not defined but rather are temporaries. Beyond this > I don't unders...

Dear llvm-dev-list, I have created my own custom section to be added at the end into a binary upon compilation which contains address of all basic blocks. As the final address of the basic block is not known until link time, I collect the MCSymbol* Symbol Values per BB in a temp array and at the in the custom section and emit it (emitSymbolValue) into my section within EmitEndOfAsmFile() I have found people looking at slightly different uses of the basic block address but running into the same problem as me when compiling. $clang calc_pi.c...

...new GlobalVariable(*m, tmp->getType(), true, llvm::GlobalValue::ExternalLinkage, tmp, "test_llvm_var"); where tmp is a function. Then I tried to access this global variable in the back end MachineFunctionPass like this: MCContext& MCC = MF.getContext(); MCSymbol* MCS = MCC.lookupSymbol("test_llvm_var"); if (MCS == NULL) { errs() << ">>> MCSymbol is null\n"; } else { MCS->dump(); } (MF is a MachineFunction). However I always get MCS==NULL...

...::ExternalLinkage, tmp, "test_llvm_var"); > > > > where tmp is a function. > > > > Then I tried to access this global variable in the back end > MachineFunctionPass like this: > > > > MCContext& MCC = MF.getContext(); > MCSymbol* MCS = MCC.lookupSymbol("test_llvm_var"); > if (MCS == NULL) { > errs() << ">>> MCSymbol is null\n"; > } > else { > MCS->dump(); > } > > > > (MF is a...

...oblems with symbol location in AsmParser. 1. We need to know where symbol was declared. 2. We need to know where symbol was defined first time. There are two ways: 1. Add helper table to the parser with additional symbol info. But it takes additional memory consumption. 2. Add user tag (void*) for MCSymbol object. As I understood MCSymbol can live without asm sources, so we can't add info field directly. But the user tags is pretty common practice for this cases. So, what are you think about it? Stepan

...MetadataPrinter (just like during an AOT compilation). A GCMetadataprinter is called at the end of the compilation of a module after having assigned the slots to the live roots. I have almost everything except that at this step, a collection point (aka safepoint in the GC world) is describe by: * a MCSymbol, which indicates the location of a safepoint (basically the instruction pointer that follows the safepoint) * a list of live roots, each one is described by an offset relative to the frame pointer. Now, I would like to find the concrete address of the MCSymbol. And I don't know how I could fin...

Hi David, Thanks for your efforts here. I have a few comments on your patch, although I realise it's still a work in progress. +class ConstantPool { + MCSymbol *Label; + typedef std::vector<const MCExpr*> EntryVecTy; Use a SmallVector here? + MCSymbol *getLabel() {return Label;} + size_t getNumEntries() {return Entries.size();} + const MCExpr *getEntry(size_t Num) {return Entries[Num];} These can be const. + int64_t ConstantPoolCounter; This...

Hi all, So, MCJIT is working with vmkit, that's great. However, I need to retrieve the GCModuleInfo and the MachineCodeEmitter used during the compilation process. And I don't know how I should proceed? I'm trying to understand how they are preserved with the old jit, but I have to say that I'm a little bit lost because I haven't a global view of the code... So, any help would

Hi Chris, The MCSymbol r98459 patch of llvm seems to have broken the ExceptionDemo example. As the example is dying in the associated personality's first unwind search phase, which happens to have no language specific context, and is returning a _URC_CONTINUE_UNWIND, I believe the issue is generic and not specific to...

...n fact, developing this as a coff assembler (which can be accessed with 'llvm-mc foo.s -o foo.obj -filetype=obj') is easier in a lot of ways than dealing with the compiler! > > Yes somewhat. Currently, the COFF implementation of the assembler backend should maintain a DenseMap from MCSymbol* to whatever data you need to associate with a symbol. This is equivalent to embedding per-symbol stuff in the MCSymbol itself. MCSection should be subclassed and you should put COFF specific stuff in MCSectionCOFF. > >> > > I think this is an important detail I was missing. I c...

Hi Liad, I'm not an expert in MC, but what you describe doesn't sound any different from how you would handle a branch instruction. Create an MCSymbol that represents the address of the target instruction; use that symbol as an operand in the referencing instruction; emit the symbol as a label just prior to emitting the target instruction. The second and third steps can occur in either order, depending on which instruction is emitted first. I...

Forgot to add platform with issue: OS X 10.6.2. I have not tested elsewhere. Garrison On Mar 18, 2010, at 14:20, Garrison Venn wrote: > Hi Chris, > > The MCSymbol r98459 patch of llvm seems to have broken the ExceptionDemo example. As the example is dying in the > associated personality's first unwind search phase, which happens to have no language specific context, and is returning > a _URC_CONTINUE_UNWIND, I believe the issue is generic and not s...