similar to: [LLVMdev] Printing x86 ASM for Function

Dear Maxime, Nyx wrote: > Hello, > > I would like to know how to go about printing the x86 assembly output for a > compiled function (I'm using the JIT). I saw there is a X86IntelAsmPrinter > on doxygen. However, it takes several arguments I don't know how to fill in. > Is there a helper function to create such a pass? Once I have the pass > created, do I just add it

Hi, Long time ago (llvm-svn june 2008) I asked here about a way to output the assembly code of my JIT generated code to a string, so I could use it to read it on the screen. I came up with this solution: std::string Err; const llvm::TargetMachineRegistry::entry* _arch = llvm::TargetMachineRegistry::getClosestTargetForJIT(Err); std::string FeaturesStr; llvm::TargetMachine*

Well, I've been before hours trying this, but soon after I sent the email I found something. However is quite intriguing. I just changed the order of and the static libraries that I was linking. How can this be possible?? I'm using Cmake for building my llvm projects, so I choose the order and I pick the .a libraries I want to link by hand... Thank you, alvaro 2009/3/8 Álvaro

When you say 'static libraries' do you mean static libraries or shared objects (.so)... Because if you mean shared objects, then it could very well explain you crash. On Mar 9, 12:16 am, Álvaro Castro Castilla <alvaro.castro.casti... at gmail.com> wrote: > Well, I've been before hours trying this, but soon after I sent the > email I found something. However is quite

Hello, I'm trying to catch assembly output and do some formatting for its presentation while being executed. I face a problem, which is clear from the error, although I have no clue on how to do it otherwise. If generating the code for its asm output and then for jit execution I get: ********** static llvm::MachineFunction& llvm::MachineFunction::construct(const llvm::Function*, const

Hi, I'm playing with some experimental register allocators for LLVM. One of them needs to build a so-called register class tree for representing the aliasing information among register classes. This tree is not function or module specific. It is actually target specific, because it depends only on the register classes defined for a machine that is used as a target of the current compilation.

Hi, I'm experimenting with using LLVM to generate dynamic FFI bridges in VisualWorks Smalltalk. LLVM is an amazing thing! I'm going from dynamically generated assembler source to machine code, and I have that all working, copied from the llc tool and the JIT example. I have two questions: 1. What optimization passes, if any, should I run on the module before I pass it to the

Hi folks, just installed the new llvm 1.9 build and noticed that my code no longer worked. It seems something has changed with addPassesToEmitFile(). First, the arguments to that method changed so that it no longer takes a PassManager, but only a FunctionPassManager. Instead there is a addPassesToEmitWholeFile() method, but that is marked as optional, and when I change my code to

Chris, Okay, I have done as you have requested. The only thing I did not like was a clsh between the enum X86 and the new namespace X86, which I had to rename as x86 :( Anyway, I suppose the lower case 'x' in 'x86' fits in with the lowercase 'llvm' namespace. Build tested on MS VC2003 and Linux. Aaron -------------- next part -------------- A non-text attachment was

I am now getting the following link errors on all executables: x86.lib(X86AsmPrinter.obj) : error LNK2001: unresolved external symbol "public: virtual bool __thiscall llvm::x86::X86ATTAsmPrinter::runOnMachineFunction(class llvm::MachineFunction &)" (?runOnMachineFunction at X86ATTAsmPrinter@x86 at llvm@@UAE_NAAVMachineFunction at 3@@Z) x86.lib(X86AsmPrinter.obj) : error LNK2001:

>>> You shouldn't have to add new classes to the .td file, just modify >>> printOp for your asmprinters. >> >> I dont think printOp is virtual and therefore cannot be overriden ? > > Why does it need to be virtual? No 'intel' printers want % signs. The GAS intel code generator generates percents, look at the X86InstrInfo.td file it is full of

Hi again, I have put together a "blank skeleton" for a X86NASMPrinter class, with effectively the same behaviour as the X86IntelAsmPrinter class. I had to do this within the X86AsmPrinter.cpp file rather than as a separate source file as the dependancies were so. Please do not commit this yet, I have included it not for confidence sake :)) I do not know whether it is a good idea to

Hi all, Well, suggestion for workarounds for the namespace problems are welcome... this is a 7 minutes compile files on a pentium 4 3ghz 700Mb ram... The fatal error at the end MAY depend on the previous... or at least, I hope so. cl /nologo /TP /EHsc /GR /Zi /Yd /D__STDC_LIMIT_MACROS /DHAVE__FINITE_IN_FLOAT_H /DHAVE__ISNAN_IN_FLOAT_H /ISTLport-4.6.2\stlport /Illvm\inc lude

A possible minor bug in lib/Target/X86/X86IntelAsmPrinter.cpp X86IntelAsmPrinter::doInitialization is calling AsmPrinter::doInitialization() not X86SharedAsmPrinter::doInitialization() Supprised I did not spot it earlier. Aaron -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Thu, 2013-01-31 at 11:29 -0600, Bill Schmidt wrote: > On Thu, 2013-01-31 at 11:23 -0600, Bill Schmidt wrote: > > On Thu, 2013-01-31 at 10:17 -0600, Bill Schmidt wrote: > > > > > > On Thu, 2013-01-31 at 09:42 -0600, Hal Finkel wrote: > > > > ----- Original Message ----- > > > > > From: "Bill Schmidt" <wschmidt at

On Tue, 12 Jul 2005, Aaron Gray wrote: >>>> You shouldn't have to add new classes to the .td file, just modify >>>> printOp for your asmprinters. >>> I dont think printOp is virtual and therefore cannot be overriden ? >> Why does it need to be virtual? No 'intel' printers want % signs. > > The GAS intel code generator generates percents,

>> The GAS intel code generator generates percents, look at the >> X86InstrInfo.td file it is full of them. > > Ah, I see what you're talking about. Please feel free to remove all of > those from the Intel format. For example, change this: > > def IN8rr : I<0xEC, RawFrm, (ops), > "in{b} {%dx, %al|%AL, %DX}">, Imp<[DX],

I've been working some more on my front-end, incorporating the advice from your previous email. I've had some success, in that I can generate a Module object, populated it with functions and instructions, and print out the resulting LLVM IR. But I'm still a little puzzled on how to connect the front end with LLVM's backend code generator, I can't seem to figure out how to

Hello, Benedict > There is still one problem that I am looking into around changing > alignments within SEGMENTS. The problem is that MASM allows 2,4,16,256 > alignments, default being 16, but LLVM is sometimes generating 32 > alignment, for example, consider the following code: That's correct. MASM is too weak to represent even slightly non-trivial program. In your particular

Debug build on x86_64 with`--with-udis86=<path>' option to 'configure' seems broken. Configure command line: ./configure --disable-optimized --enable-assertions --enable-debug-runtime --enable-debug-symbols --enable-jit --enable-pic --enable-targets=x86_64 --with-udis86=/somepath/udis86/udis86-1.7 At least 2 issues: (1) '-L/somepath/udis86/udis86-1.7' is added to the