search for: jitdwarfemitter

Hello, I'd like some advice on a crash that we have observed on MacOSX with the 2.8 and 2.9 releases of LLVM, but not on the top of trunk. The crash is a null-deref in llvm::JITDwarfEmitter::EmitDwarfTable : Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x0000000100852203 in llvm::JITDwarfEmitter::EmitDwarfTable () at context.h:491 (gdb) bt #0 0x0000000100852203 in llvm::JITDwarfEmitter::EmitDwarfTable ()...

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 to fix on my side. Christophe On 19 avr. 2011, at 17:...

Dear all, Here's a new patch with Evan's comments (thx Evan!) and some cleanups. Now the (duplicated) exception handling code is in a new file: lib/ExecutionEngine/JIT/JITDwarfEmitter. This patch should work on linux/x86 and linux/ppc (tested). Nicolas -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: jit-exceptions.patch URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080201/38ce7f01/attachment.ksh>

Looks sane. Thanks. Evan On Feb 1, 2008, at 1:24 AM, Nicolas Geoffray wrote: > Dear all, > > Here's a new patch with Evan's comments (thx Evan!) and some cleanups. > Now the (duplicated) exception handling code is in a new file: > lib/ExecutionEngine/JIT/JITDwarfEmitter. > > This patch should work on linux/x86 and linux/ppc (tested). > > Nicolas > Index: include/llvm/ExecutionEngine/ExecutionEngine.h > =================================================================== > --- include/llvm/ExecutionEngine/ExecutionEngine.h (revision 46612) >...

...because the resulting 8 byte alignment resulted in JIT emitted addresses which did not seem match the excepted type info offset. In truth I'm not sure what a type info is anyway, as I know they are not c++ type infos, but the array trick seems to work ... sort of. My question though is: 1) In JITDwarfEmitter.cpp these GlobalVariables are emitted with: JCE->emitInt64((intptr_t)Jit.getOrEmitGlobalVariable(GV)); (in JITDwarfEmitter::EmitExceptionTable) 2) The allocated emitted space is calculated by: JITCodeEmitter::allocateSpace(...) as eventually called by getOrEmitGlobalVariable(...) 3) If the...

Thx again Evan for the review. Here's a new patch for the JIT in itself. The major changes are: 1) A JITMemoryManager now has a flag saying "I require to know the size of what you want to emit" 2) DwarfJITEmitter is augmented with GetSize* functions 3) JITEmitter::startFunction checks if the JITMemoryManager requires to know the size. If so, it computes it and gives it through the

...unctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 62 7 lli 0x0000000000d3f9c6 llvm::JIT::getPointerToFunction(llvm::Function*) + 686 8 lli 0x0000000000d67c86 llvm::ExecutionEngine::getPointerToGlobal(llvm::GlobalValue const*) + 70 9 lli 0x0000000000d62805 llvm::JITDwarfEmitter::EmitCommonEHFrame(llvm::Function const*) const + 613 10 lli 0x0000000000d60ac3 llvm::JITDwarfEmitter::EmitDwarfTable(llvm::MachineFunction&, llvm::JITCodeEmitter&, unsigned char*, unsigned char*, unsigned char*&) + 335 ... Ciao, Duncan.

...llvm::MutexGuard > const&) + 62 > 7 lli 0x0000000000d3f9c6 > llvm::JIT::getPointerToFunction(llvm::Function*) + 686 > 8 lli 0x0000000000d67c86 > llvm::ExecutionEngine::getPointerToGlobal(llvm::GlobalValue const*) + 70 > 9 lli 0x0000000000d62805 > llvm::JITDwarfEmitter::EmitCommonEHFrame(llvm::Function const*) const + 613 > 10 lli 0x0000000000d60ac3 > llvm::JITDwarfEmitter::EmitDwarfTable(llvm::MachineFunction&, > llvm::JITCodeEmitter&, unsigned char*, unsigned char*, unsigned char*&) + > 335 > ... > Thanks for looking at this....

...onst&) + 62 >> 7 lli 0x0000000000d3f9c6 >> llvm::JIT::getPointerToFunction(llvm::Function*) + 686 >> 8 lli 0x0000000000d67c86 >> llvm::ExecutionEngine::getPointerToGlobal(llvm::GlobalValue const*) + 70 >> 9 lli 0x0000000000d62805 >> llvm::JITDwarfEmitter::EmitCommonEHFrame(llvm::Function const*) const + 613 >> 10 lli 0x0000000000d60ac3 >> llvm::JITDwarfEmitter::EmitDwarfTable(llvm::MachineFunction&, >> llvm::JITCodeEmitter&, unsigned char*, unsigned char*, unsigned char*&) + >> 335 >> ... >> &gt...

> You mean by lowering to setjmp/longjmp?  Maybe, I don't know. > It should be easy to find out by trying it. No, with DWARF. There's all this code in the JIT (JITDwarfEmitter.cpp) to register the DWARF with libgcc. Reid

...deEmitter and the (un)hidden JITEmitter. But this lead to more dependancies and they lead on to more. I have now made class header for JITEmitter putting it in the llvm namespace. There were several other header dependancies as a result and lib/ExecutionEngine/JIT/JIT.h and lib/ExecutionEngine/JIT/JITDwarfEmitter.h required moving to the include/llvm/ExecutionEngine/JIT directory as a result to make them visible to JIT.h and dependants. * create JITEmitter.h and made class JITEmitter visible in llvm namespace * moved lib/ExecutionEngine/JIT/JIT.h to include/llvm/ExecutionEngine/JIT * moved lib/...

...ked(llvm::Function*, llvm::MutexGuard const&) + 62 > 7 lli 0x0000000000d3f9c6 llvm::JIT::getPointerToFunction(llvm::Function*) + 686 > 8 lli 0x0000000000d67c86 llvm::ExecutionEngine::getPointerToGlobal(llvm::GlobalValue const*) + 70 > 9 lli 0x0000000000d62805 llvm::JITDwarfEmitter::EmitCommonEHFrame(llvm::Function const*) const + 613 > 10 lli 0x0000000000d60ac3 llvm::JITDwarfEmitter::EmitDwarfTable(llvm::MachineFunction&, llvm::JITCodeEmitter&, unsigned char*, unsigned char*, unsigned char*&) + 335 > ... > Thanks for looking at this. > > Ye...

...er. But this lead to > more dependancies and they lead on to more. > > I have now made class header for JITEmitter putting it in the llvm > namespace. There were several other header dependancies as a result > and lib/ExecutionEngine/JIT/JIT.h and lib/ExecutionEngine/JIT/ > JITDwarfEmitter.h required moving to the include/llvm/ > ExecutionEngine/JIT directory as a result to make them visible to > JIT.h and dependants. > > * create JITEmitter.h and made class JITEmitter visible in llvm > namespace > * moved lib/ExecutionEngine/JIT/JIT.h to include/llvm/...

...ch -r 98459 http://llvm.org/svn/llvm-project/llvm/trunk >> 7) make >> 8) Debug/examples/ExceptionDemo 2 >> 9) example will segv >> >> Sorry I'm late identifying this. I'll keep on trying to isolate it further, though I'm guessing that the sensitivity is in JITDwarfEmitter. >> >> Garrison >> >> PS: Patch ref: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097798.html > -------------- next part -------------- A non-text attachment was scrubbed... Name: NewMCAdds_ProbExceptionHack.patch Type: application/octet-stream...

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

...ample will complete successfully 6) svn switch -r 98459 http://llvm.org/svn/llvm-project/llvm/trunk 7) make 8) Debug/examples/ExceptionDemo 2 9) example will segv Sorry I'm late identifying this. I'll keep on trying to isolate it further, though I'm guessing that the sensitivity is in JITDwarfEmitter. Garrison PS: Patch ref: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097798.html

...=0x17196b0, locked=...) at JIT.cpp:624 #4 0x0000000000d3e6a6 in llvm::JIT::getPointerToFunction (this=0x1781e90, F=0x17196b0) at JIT.cpp:680 #5 0x0000000000d66d32 in llvm::ExecutionEngine::getPointerToGlobal (this=0x1781e90, GV=0x17196b0) at ExecutionEngine.cpp:473 #6 0x0000000000d618b1 in llvm::JITDwarfEmitter::EmitCommonEHFrame (this=0x177a3c0, Personality=0x17196b0) at JITDwarfEmitter.cpp:522 #7 0x0000000000d5fb6f in llvm::JITDwarfEmitter::EmitDwarfTable (this=0x177a3c0, F=..., jce=..., StartFunction=0x7ffff7f4c090 "H\203\354\bH\270 @\376\367\377\177", EndFunction=0x7ffff7f4c0b6 &quo...

...lvm.org/svn/llvm-project/llvm/trunk >>> 7) make >>> 8) Debug/examples/ExceptionDemo 2 >>> 9) example will segv >>> >>> Sorry I'm late identifying this. I'll keep on trying to isolate it further, though I'm guessing that the sensitivity is in JITDwarfEmitter. >>> >>> Garrison >>> >>> PS: Patch ref: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100308/097798.html >> > > <NewMCAdds_ProbExceptionHack.patch>

2010/1/22 Duncan Sands <baldrick at free.fr> > Hi James, > > > Yes - sorry I was unclear. I have pruned everything down to a pretty >> minimal test: >> - LLVM 2.6 compiled from source >> - A slightly modified version of Duncan's example ll assembly posted >> earlier >> - A minimal personality function (just a call to fprintf()) in a separate

...CodeEmitter lib/Target/Alpha/AlphaJITInfo.h lib/Target/Alpha/AlphaJITInfo.cpp * Replaced references to MachineCodeEmitter with JITCodeEmitter. lib/ExecutionEngine/JIT/JIT.h lib/ExecutionEngine/JIT/JIT.cpp lib/ExecutionEngine/JIT/JITEmitter.cpp lib/ExecutionEngine/JIT/JITDwarfEmitter.h lib/ExecutionEngine/JIT/JITDwarfEmitter.cpp * Modified to use JITCodeEmitter instead of MachineCodeEmitter (i) http://wiki.llvm.org/Direct_Object_Code_Emission -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/a...