similar to: [LLVMdev] Debugging of LLVM-IR

Unfortunately, the current gdb support doesn't include line numbers. It'll tell you what function it crashed in and the stack trace though. Line numbers will probably come when the llvm-mc project is merged into the JIT. On Tue, Feb 9, 2010 at 9:37 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Are you running this in a JIT? If so this will help:

I suspected something like that. :( I was hoping i could run the program and step throught IR-Code line by line, maybe even have a look at the variables. Well, what about compiling it into assembler-code. Is there any way to know which IR-line generated which assembler line(s)? (I do not need any optimizations or whatever, if that helps...) Sebastian On Tuesday 09 February 2010 18:45:56 you

Are you running this in a JIT? If so this will help: http://llvm.org/docs/DebuggingJITedCode.html. Garrison On Feb 9, 2010, at 10:33, Sebastian Schlunke wrote: > Hello, > > is there any way to debug a program in LLVM-IR line-by-line (i.e. with gdb)? > > The problem is, i have a program in human-readable-intermediate representation that segfaults, when executed. I want to know,

Sebastian Schlunke <schlunki at cs.tu-berlin.de> writes: > I suspected something like that. :( > > I was hoping i could run the program and step throught IR-Code line by line, maybe even have a look at the variables. > > Well, what about compiling it into assembler-code. Is there any way > to know which IR-line generated which assembler line(s)? (I do not > need any

According to http://llvm.org/docs/DebuggingJITedCode.html only ELF objects are supported for gdb support of JIT generated code. Is this still true, or are Mach-O files now supported in 2.7 trunk? Thanks in advance Garrison

I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed before any unwind happens. -- James 2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > No, there is no magic. :-) > > To me though, the tools are magic, because I have no clue what they are > doing without looking at them and using them. >

On Sun, Jan 10, 2010 at 12:38 PM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Won't passing llvm::Function* around vs strings (function names), also work, at code generation time, > without the need for a module A dec to module B impl. mapping? > > Garrison Nope. You cannot place a call instruction into one module whose callee is a Function from another module. You

On Sat, Jul 23, 2011 at 2:36 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hi Bill, > > Thanks for working on this. > > Is there a reference for the function attribute uwtable, or is it to be defined as > part of this effort? It already exists; there's some limited documentation in the LLVM source, but Rafael apparently forgot to add it to LangRef... -Eli

[sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing] On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com>wrote: > Hi Olivier, > > On Feb 25, 2010, at 14:10, Olivier Meurant wrote: > > Hi Garrison, > > I finally come back from holidays and take

Hey all, Attached you will find an experimental patch which allows me to play with a derived JIT class. With this patch I've alleviated my concerns with forcing cross module behavior for all users of JIT. However this introduces some new semantics, and kind of circumvents the EngineBuilder API. More important though, I have not addressed any concern about using stub functions in eager

I think so. It also fails the same way on LLVM trunk from last week. The full backtrace is below. It appears that frame #3 is a compilation of __l_personality() and frame #14 is a compilation of f(). The compilation of __l_personality appears to have been triggered by the need to output DWARF information for f(). -- James #0 0x00007ffff6ed84b5 in *__GI_raise (sig=<value optimised out>) at

Several people on this list have reported issues with the linker regarding a named StructType instance with the same name in two different modules being resolved into two StructTypes with different names due to StructType:: setName(…) collision behavior. Looking at BitcodeReader::ParseTypeTableBody(…), I don't see use of LLVMContextImpl::NamedStructTypes or of Module::getTypeByName(…). Nor do

Interesting. Was this the reason you were getting the recursive compilation error in JIT::runJITOnFunctionUnlocked(...) (isAlreadyCodeGenerating)? Do you have the time to try your test with 2.7? Garrison On Jan 22, 2010, at 17:37, James Williams wrote: > I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed

Hi James, Just wanted to update you. As you implied the problem here is that the personality function has to be jitted before the code that contains the corresponding llvm.eh.selector intrinsic instruction is jitted. I verified this by creating a generated version of the personality function which unless I jitted first, gave me the same error when running the code. Since you are using tools

2010/1/11 Garrison Venn <gvenn.cfe.dev at gmail.com> > I have not tried this, but a linkage type of PrivateLinkage would not add > to the symbol table according > to the doc. > > LLVMSetLinkage(g, LLVMPrivateLinkage); > Thanks - I hadn't thought of that. > > Garrison > > On Jan 11, 2010, at 14:03, James Williams wrote: > > 2010/1/11 Eli Friedman

No problem I'll drop this from our discussion as it really is only germane to my learning path and imagination. :-) I do at this time still have this concern of allowing a user (developer) the right to turn this "cross module linkage" off, but I'm still in the process of understanding your previous comments on this. Thanks again for the help and time by the way. Garrison PS:

Is it consistent to have a Pass instance's run method's implementation use getAnalysisIfAvailable<AnalysisType>() (vs just using getAnalysis< AnalysisType >) when that same instance's getAnalysisUsage(AnalysisUsage &au) implementation invokes au.addRequired<AnalysisType>()? For example in the implementation of SelectionDAGISel::runOnMachineFunction(...) (called

Hi Jeffrey, On Feb 26, 2010, at 16:02, Jeffrey Yasskin wrote: > [sidenote: Please try to avoid extraneous whitespace and line wrapping changes in your patches. It makes it harder to see what you're actually changing] Sorry just saw some preexisting code was not in 80 columns. > > On Fri, Feb 26, 2010 at 4:57 AM, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: > Hi

2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > Hi James, > > Note that the wiki example is a manual JIT example that works directly with > the C++ APIs. As you know, no LLVM tools are used, > just LLVM libraries. I say this to point out, that in the example, the > exception mechanism is under the complete control of the > developer moded by the LLVM libraries.

I just added an exception example to the wiki intended to be run in a JIT environment. Although this information is heavily date dependent, as the LLVM exception subsystem will be modified as time goes on, I could have used such an example when I was looking into this; hence the submission. Having said this, I'm not an LLVM expert, and even though the code works, I'm sure there are