search for: jitemitdebuginfo

I found the problem : my code sets JITEmitDebugInfo after creating the JIT. This causes the JITDwarfEmitter DE to not be constructed in the ctor of JITEmitter (JITEmitter.cpp around line 375). Not sure if it's documented anywhere that JITEmitDebugInfo must be set before constructing the JIT, but looking at the code, it makes sense. Easy enough...

...natives=false, noData=false) at ../tao/xlr/xlr/symbols.cpp:375 [From there on, it's our stuff, snip] I first observed this with the 2.8 release tag, and now again on the 2.9 release tag, but not with any top-of-trunk I tried (currently, r129756). The problem goes away if our code does not set JITEmitDebugInfo to true. If I install the 2.9 release and do not rebuild our code, there is no crash either. This seems to imply that the problem is somewhere in the header files. Did anybody else see something similar? Are we doing something incorrect that the verifier and asserts don't catch?3 To reproduc...

With the same source code, gdb on Linux shows function names and on MacOS it doesn't. Why would MacOS be different in respect of this issue? Yuri

Because OS X is not an ELF target, and support was only implemented in LLVM for making ELFs with debug info. I think the docs I wrote on this may suggest that the FSF gdb 7.0+ will work, but that's not the case. Sent from phne Reid On Jan 4, 2011 10:50 PM, "Yuri" <yuri at rawbw.com> wrote: With the same source code, gdb on Linux shows function names and on MacOS it

...e my object file using TargetMachine::addPassesToEmitFile and then I link my resulting files with: gcc -o prog input.o -fexceptions I'm sure I'm just missing some option to generate the Dwarf tables, but I can't figure out what it is. For the JIT version I set JITExceptionHandling and JITEmitDebugInfo on TargetOptions. -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Sign: Please digitally sign your emails. Encrypt: I'm also happy to receive encrypted mail. -------------- next part -------------- A non-text attachment was scrubbed... Name: signa...

...e::addPassesToEmitFile and > then I link my resulting files with: > > gcc -o prog input.o -fexceptions > > I'm sure I'm just missing some option to generate the Dwarf tables, but > I can't figure out what it is. For the JIT version I set > JITExceptionHandling and JITEmitDebugInfo on TargetOptions. > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > -- edA-qa mort-ora-y -- -- -- -- -- -- -- -- -- -- -...

On 06/21/2010 14:14, Reid Kleckner wrote: > Since FreeBSD is an ELF target, this should work fine. I've also > tested that this works in 32-bit by building gdb and llvm in 32-bit > mode and testing this stuff while running on a 64-bit OS. > > I would try setting a breakpoint in gdb on > 'llvm::JITDebugRegisterer::RegisterFunction' to see that it is being > called,

...he big question is whether the exception table is in input.o already or not. You can disassemble it and take a look. > I'm sure I'm just missing some option to generate the Dwarf tables, but > I can't figure out what it is. For the JIT version I set > JITExceptionHandling and JITEmitDebugInfo on TargetOptions. You don't have to do anything AFAIK: by default the code generators will produce an exception table. Probably you should send in your IR and the .o file. Ciao, Duncan.

This may be bogus, but do you have: llvm::JITExceptionHandling = true; for the code that generates the dynamic code? It has been a while, but I don't recall what will happen when dynamic code, generated with jit exception handling turned off, invokes libraries which in turn try to unwind the stack via the libunwind api. However given that you say the code works with 2.8, my concern

Hello, We have been investigating a crash in our application that may be related to how stack frames are generated by the JIT. We observe it with LLVM 2.9, but not with LLVM 2.8, everything else being the same. The crash occurs when dynamically generated code calls code that tries to unwind the stack. Here is what the stack trace looks like on MacOSX 10.6 : 0 libSystem.B.dylib

...er.setJITMemoryManager(llvm::JITMemoryManager::CreateDefaultMemManager()); builder.setEngineKind(llvm::EngineKind::JIT); //CodeGenOpt::Level OLvl = CodeGenOpt::Default; //builder.setOptLevel(OLvl); llvm::TargetOptions Options; Options.JITExceptionHandling = false; Options.JITEmitDebugInfo = false; Options.JITEmitDebugInfoToDisk = false; builder.setTargetOptions(Options); LLVM_ExecE = builder.create(); if (!LLVM_ExecE) { if (!ErrorMsg.empty()) llvm::errs() << argv[0] << ": error creating ExecE: " << ErrorMsg << &q...

Hi, I am starting to poke at the LLVM JIT, which seems to be in need of some TLC. If you are a "sophisticated" JIT user and are using either internal APIs (either by integrating with LLVM, or by other C++ tricks), or are using obscure or poorly documented public APIs (e.g., why is runJITOnFunction exposed?) please make me aware of it! I reserve the right to break anything which

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

...LessPreciseFPMADOption(false), UnsafeFPMath(false), - NoInfsFPMath(false), NoNaNsFPMath(false), + NoInfsFPMath(false), NoNaNsFPMath(false), HonorFPExceptions(false), HonorSignDependentRoundingFPMathOption(false), UseSoftFloat(false), NoZerosInBSS(false), JITEmitDebugInfo(false), JITEmitDebugInfoToDisk(false), GuaranteedTailCallOpt(false), @@ -117,6 +117,11 @@ namespace llvm { /// assume the FP arithmetic arguments and results are never NaNs. unsigned NoNaNsFPMath : 1; + /// HonorFPExceptions - This flag is enabled when code relies on +...