[I assume you meant to send this to the list as well, not just me.] Begin forwarded message: Date: Wed, 3 Nov 2010 14:43:54 +0000 From: Salomon Brys <salomon.brys at gmail.com> To: Török Edwin <edwintorok at gmail.com> Subject: Re: [LLVMdev] Forcing the Interpreter segfaults I have build LLVM in debug mode. Here are the informations of the segfault : memcpy() at 0x7ffff6f6581e LoadIntFromMemory() at ExecutionEngine.cpp:887 0xb3c297 llvm::ExecutionEngine::LoadValueFromMemory() at ExecutionEngine.cpp:915 0xb3c3f9 llvm::Interpreter::visitLoadInst() at Execution.cpp:812 0xa1f855 llvm::InstVisitor<llvm::Interpreter, void>::visitLoad() at 0xa28357 llvm::InstVisitor<llvm::Interpreter, void>::visit() at 0xa26b4e llvm::Interpreter::run() at Execution.cpp:1,328 0xa235ff llvm::Interpreter::runFunction() at Interpreter.cpp:95 0xa166fa .... So the segfaults happens because of the memcpy call in the LoadIntFromMemory function in ExecutionEngine.cpp on line 887... Any clue ? Adding .setOptLevel(llvm::CodeGenOpt::None) to the EngineBuilder creation reduces the time by 25% but that is still not enough :( 2010/11/3 Török Edwin <edwintorok at gmail.com>> On Wed, 3 Nov 2010 11:18:34 +0000 > Salomon Brys <salomon.brys at gmail.com> wrote: > > > Jiting with no optimization does not reduce significantly the > > compilation with very small code... > > I mean the parameter to createJIT, OptLevel. Try setting it to None. > Or if you use EngineBuilder, setOptLevel(CodeGenOpt::None). > > > What is the local register allocator ??? > > -regalloc=fast, or -regalloc=local parameter to llc, or lli. > I think there was a programatic way to choose register allocator, but > I forgot how. > > Best regards, > --Edwin >-- ########################################### # Salomon BRYS # +33 (0) 6 83 54 55 96 #------------------------------------------ # > EPITECH "Koala" : C++ assistant : Sbire du C++ # > Zend Certified Engineer for PHP5 #------------------------------------------ # All data in this e-mail is confidential. # If you are not, or if you don't believe you are, the recipient of this e-mail, please delete it. #------------------------------------------ # GPG : http://gpgkey-salomon.antesocial.fr/ ########################################### -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101103/1e1f80c1/attachment.html>
Cyrille Berger Skott
2010-Nov-03 14:52 UTC
[LLVMdev] Fw: Forcing the Interpreter segfaults
Hi, On Wednesday 03 November 2010, Török Edwin wrote:> So the segfaults happens because of the memcpy call in the > LoadIntFromMemory function in ExecutionEngine.cpp on line 887... Any > clue ?You need libffi to have support for calling functions with the interpreter. -- Cyrille Berger Skott -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101103/ac25f5a7/attachment.html>
Hi,> I have build LLVM in debug mode. Here are the informations of the > segfault : memcpy() at 0x7ffff6f6581e > LoadIntFromMemory() at ExecutionEngine.cpp:887 0xb3c297 > llvm::ExecutionEngine::LoadValueFromMemory() at ExecutionEngine.cpp:915 > 0xb3c3f9 > llvm::Interpreter::visitLoadInst() at Execution.cpp:812 0xa1f855 > llvm::InstVisitor<llvm::Interpreter, void>::visitLoad() at 0xa28357 > llvm::InstVisitor<llvm::Interpreter, void>::visit() at 0xa26b4e > llvm::Interpreter::run() at Execution.cpp:1,328 0xa235ff > llvm::Interpreter::runFunction() at Interpreter.cpp:95 0xa166fa > .... > So the segfaults happens because of the memcpy call in the > LoadIntFromMemory function in ExecutionEngine.cpp on line 887... Any > clue ?usually this kind of thing means that your bitcode is doing something bad, such as writing to random memory locations, and you just happened to get away with it when using the JIT. Try running under valgrind (either the interpreter or, if you can, make a real program out of your bitcode and run that under valgrind). Ciao, Duncan.> > > Adding .setOptLevel(llvm::CodeGenOpt::None) to the EngineBuilder > creation reduces the time by 25% but that is still not enough :( > > > 2010/11/3 Török Edwin<edwintorok at gmail.com> > >> On Wed, 3 Nov 2010 11:18:34 +0000 >> Salomon Brys<salomon.brys at gmail.com> wrote: >> >>> Jiting with no optimization does not reduce significantly the >>> compilation with very small code... >> >> I mean the parameter to createJIT, OptLevel. Try setting it to None. >> Or if you use EngineBuilder, setOptLevel(CodeGenOpt::None). >> >>> What is the local register allocator ??? >> >> -regalloc=fast, or -regalloc=local parameter to llc, or lli. >> I think there was a programatic way to choose register allocator, but >> I forgot how. >> >> Best regards, >> --Edwin >> > > > > > > I have build LLVM in debug mode. Here are the informations of the segfault : > memcpy() at 0x7ffff6f6581e > LoadIntFromMemory() at ExecutionEngine.cpp:887 0xb3c297 > llvm::ExecutionEngine::LoadValueFromMemory() at ExecutionEngine.cpp:915 0xb3c3f9 > llvm::Interpreter::visitLoadInst() at Execution.cpp:812 0xa1f855 > llvm::InstVisitor<llvm::Interpreter, void>::visitLoad() at 0xa28357 > llvm::InstVisitor<llvm::Interpreter, void>::visit() at 0xa26b4e > llvm::Interpreter::run() at Execution.cpp:1,328 0xa235ff > llvm::Interpreter::runFunction() at Interpreter.cpp:95 0xa166fa > .... > So the segfaults happens because of the�memcpy call in the�LoadIntFromMemory > function in�ExecutionEngine.cpp on line 887... Any clue ? > > > Adding .setOptLevel(llvm::CodeGenOpt::None) to the�EngineBuilder creation > reduces the time by 25% but that is still not enough :( > > > 2010/11/3 T�r�k Edwin <edwintorok at gmail.com <mailto:edwintorok at gmail.com>> > > On Wed, 3 Nov 2010 11:18:34 +0000 > Salomon Brys <salomon.brys at gmail.com <mailto:salomon.brys at gmail.com>> wrote: > > > Jiting with no optimization does not reduce significantly the > > compilation with very small code... > > I mean the parameter to createJIT, OptLevel. Try setting it to None. > Or if you use EngineBuilder, setOptLevel(CodeGenOpt::None). > > > What is the local register allocator ??? > > -regalloc=fast, or -regalloc=local parameter to llc, or lli. > I think there was a programatic way to choose register allocator, but I > forgot how. > > Best regards, > --Edwin > > > > > -- > ########################################### > # Salomon BRYS > # +33 (0) 6 83 54 55 96 > #------------------------------------------ > # > EPITECH "Koala" : C++ assistant : Sbire du C++ > # > Zend Certified Engineer for PHP5 > #------------------------------------------ > # All data in this e-mail is confidential. > # If you are not, or if you don't believe you are, the recipient of this e-mail, > please delete it. > #------------------------------------------ > # GPG : http://gpgkey-salomon.antesocial.fr/ > ########################################### > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Hi Salomon, please don't forget to reply to the list too (I've CC'd the list).> I don't think my code is doing anything worng...No, it looks fine to me, and the interpreter certainly supports this. That suggests that the value of %str is not being transmitted to the function right. If it is getting the wrong pointer value, that would explain why it barfs. Ciao, Duncan.> This segfaults : > define i32 @llvmre_1(i8* %str) { > entry: > %char = load i8* %str > %cond = icmp eq i8 %char, 97 > br i1 %cond, label %State1, label %End > > State1: ; preds = %entry > br label %End > > End: ; preds = %State1, %entry > %retPtr.0 = phi i32 [ 1, %State1 ], [ 0, %entry ] > ret i32 %retPtr.0 > } > > It just checks if the first character of the string is an a. > The given parameter is "abc"... > > On Wed, Nov 3, 2010 at 16:10, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.fr>> wrote: > > Hi, > > > I have build LLVM in debug mode. Here are the informations of the > > segfault : memcpy() at 0x7ffff6f6581e > > LoadIntFromMemory() at ExecutionEngine.cpp:887 0xb3c297 > > llvm::ExecutionEngine::LoadValueFromMemory() at ExecutionEngine.cpp:915 > > 0xb3c3f9 > > llvm::Interpreter::visitLoadInst() at Execution.cpp:812 0xa1f855 > > llvm::InstVisitor<llvm::Interpreter, void>::visitLoad() at 0xa28357 > > llvm::InstVisitor<llvm::Interpreter, void>::visit() at 0xa26b4e > > llvm::Interpreter::run() at Execution.cpp:1,328 0xa235ff > > llvm::Interpreter::runFunction() at Interpreter.cpp:95 0xa166fa > > .... > > So the segfaults happens because of the memcpy call in the > > LoadIntFromMemory function in ExecutionEngine.cpp on line 887... Any > > clue ? > > usually this kind of thing means that your bitcode is doing something bad, such > as writing to random memory locations, and you just happened to get away with > it when using the JIT. Try running under valgrind (either the interpreter or, > if you can, make a real program out of your bitcode and run that under > valgrind). > > Ciao, > > Duncan. > > > > > > > Adding .setOptLevel(llvm::CodeGenOpt::None) to the EngineBuilder > > creation reduces the time by 25% but that is still not enough :( > > > > > > 2010/11/3 Török Edwin<edwintorok at gmail.com <mailto:edwintorok at gmail.com>> > > > >> On Wed, 3 Nov 2010 11:18:34 +0000 > >> Salomon Brys<salomon.brys at gmail.com <mailto:salomon.brys at gmail.com>> wrote: > >> > >>> Jiting with no optimization does not reduce significantly the > >>> compilation with very small code... > >> > >> I mean the parameter to createJIT, OptLevel. Try setting it to None. > >> Or if you use EngineBuilder, setOptLevel(CodeGenOpt::None). > >> > >>> What is the local register allocator ??? > >> > >> -regalloc=fast, or -regalloc=local parameter to llc, or lli. > >> I think there was a programatic way to choose register allocator, but > >> I forgot how. > >> > >> Best regards, > >> --Edwin > >> > > > > > > > > > > > > I have build LLVM in debug mode. Here are the informations of the segfault : > > memcpy() at 0x7ffff6f6581e > > LoadIntFromMemory() at ExecutionEngine.cpp:887 0xb3c297 > > llvm::ExecutionEngine::LoadValueFromMemory() at ExecutionEngine.cpp:915 > 0xb3c3f9 > > llvm::Interpreter::visitLoadInst() at Execution.cpp:812 0xa1f855 > > llvm::InstVisitor<llvm::Interpreter, void>::visitLoad() at 0xa28357 > > llvm::InstVisitor<llvm::Interpreter, void>::visit() at 0xa26b4e > > llvm::Interpreter::run() at Execution.cpp:1,328 0xa235ff > > llvm::Interpreter::runFunction() at Interpreter.cpp:95 0xa166fa > > .... > > So the segfaults happens because of the�memcpy call in the�LoadIntFromMemory > > function in�ExecutionEngine.cpp on line 887... Any clue ? > > > > > > Adding .setOptLevel(llvm::CodeGenOpt::None) to the�EngineBuilder creation > > reduces the time by 25% but that is still not enough :( > > > > > > 2010/11/3 T�r�k Edwin <edwintorok at gmail.com <mailto:edwintorok at gmail.com> > <mailto:edwintorok at gmail.com <mailto:edwintorok at gmail.com>>> > > > > On Wed, 3 Nov 2010 11:18:34 +0000 > > Salomon Brys <salomon.brys at gmail.com <mailto:salomon.brys at gmail.com> > <mailto:salomon.brys at gmail.com <mailto:salomon.brys at gmail.com>>> wrote: > > > > > Jiting with no optimization does not reduce significantly the > > > compilation with very small code... > > > > I mean the parameter to createJIT, OptLevel. Try setting it to None. > > Or if you use EngineBuilder, setOptLevel(CodeGenOpt::None). > > > > > What is the local register allocator ??? > > > > -regalloc=fast, or -regalloc=local parameter to llc, or lli. > > I think there was a programatic way to choose register allocator, but I > > forgot how. > > > > Best regards, > > --Edwin > > > > > > > > > > -- > > ########################################### > > # Salomon BRYS > > # +33 (0) 6 83 54 55 96 > > #------------------------------------------ > > # > EPITECH "Koala" : C++ assistant : Sbire du C++ > > # > Zend Certified Engineer for PHP5 > > #------------------------------------------ > > # All data in this e-mail is confidential. > > # If you are not, or if you don't believe you are, the recipient of this > e-mail, > > please delete it. > > #------------------------------------------ > > # GPG : http://gpgkey-salomon.antesocial.fr/ > > ########################################### > > > > > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > -- > ########################################### > # Salomon BRYS > # +33 (0) 6 83 54 55 96 > #------------------------------------------ > # > EPITECH "Koala" : C++ assistant : Sbire du C++ > # > Zend Certified Engineer for PHP5 > #------------------------------------------ > # All data in this e-mail is confidential. > # If you are not, or if you don't believe you are, the recipient of this e-mail, > please delete it. > #------------------------------------------ > # GPG : http://gpgkey-salomon.antesocial.fr/ > ###########################################
Thank you. Anyway, I have written my own interpreter. It took me 20 minutes when I passed all the day searching for making the LLVM interpreter working... On Wed, Nov 3, 2010 at 16:28, Duncan Sands <baldrick at free.fr> wrote:> Hi Salomon, please don't forget to reply to the list too (I've CC'd the > list). > > > I don't think my code is doing anything worng... >> > > No, it looks fine to me, and the interpreter certainly supports this. That > suggests that the value of %str is not being transmitted to the function > right. > If it is getting the wrong pointer value, that would explain why it barfs. > > Ciao, > > Duncan. > > This segfaults : >> define i32 @llvmre_1(i8* %str) { >> entry: >> %char = load i8* %str >> %cond = icmp eq i8 %char, 97 >> br i1 %cond, label %State1, label %End >> >> State1: ; preds = %entry >> br label %End >> >> End: ; preds = %State1, >> %entry >> %retPtr.0 = phi i32 [ 1, %State1 ], [ 0, %entry ] >> ret i32 %retPtr.0 >> } >> >> It just checks if the first character of the string is an a. >> The given parameter is "abc"... >> >> On Wed, Nov 3, 2010 at 16:10, Duncan Sands <baldrick at free.fr >> <mailto:baldrick at free.fr>> wrote: >> >> Hi, >> >> > I have build LLVM in debug mode. Here are the informations of the >> > segfault : memcpy() at 0x7ffff6f6581e >> > LoadIntFromMemory() at ExecutionEngine.cpp:887 0xb3c297 >> > llvm::ExecutionEngine::LoadValueFromMemory() at >> ExecutionEngine.cpp:915 >> > 0xb3c3f9 >> > llvm::Interpreter::visitLoadInst() at Execution.cpp:812 0xa1f855 >> > llvm::InstVisitor<llvm::Interpreter, void>::visitLoad() at 0xa28357 >> > llvm::InstVisitor<llvm::Interpreter, void>::visit() at 0xa26b4e >> > llvm::Interpreter::run() at Execution.cpp:1,328 0xa235ff >> > llvm::Interpreter::runFunction() at Interpreter.cpp:95 0xa166fa >> > .... >> > So the segfaults happens because of the memcpy call in the >> > LoadIntFromMemory function in ExecutionEngine.cpp on line 887... Any >> > clue ? >> >> usually this kind of thing means that your bitcode is doing something >> bad, such >> as writing to random memory locations, and you just happened to get >> away with >> it when using the JIT. Try running under valgrind (either the >> interpreter or, >> if you can, make a real program out of your bitcode and run that under >> valgrind). >> >> Ciao, >> >> Duncan. >> >> > >> > >> > Adding .setOptLevel(llvm::CodeGenOpt::None) to the EngineBuilder >> > creation reduces the time by 25% but that is still not enough :( >> > >> > >> > 2010/11/3 Török Edwin<edwintorok at gmail.com <mailto: >> edwintorok at gmail.com>> >> >> > >> >> On Wed, 3 Nov 2010 11:18:34 +0000 >> >> Salomon Brys<salomon.brys at gmail.com <mailto:salomon.brys at gmail.com>> >> wrote: >> >> >> >>> Jiting with no optimization does not reduce significantly the >> >>> compilation with very small code... >> >> >> >> I mean the parameter to createJIT, OptLevel. Try setting it to >> None. >> >> Or if you use EngineBuilder, setOptLevel(CodeGenOpt::None). >> >> >> >>> What is the local register allocator ??? >> >> >> >> -regalloc=fast, or -regalloc=local parameter to llc, or lli. >> >> I think there was a programatic way to choose register allocator, >> but >> >> I forgot how. >> >> >> >> Best regards, >> >> --Edwin >> >> >> > >> > >> > >> > >> > >> > I have build LLVM in debug mode. Here are the informations of the >> segfault : >> > memcpy() at 0x7ffff6f6581e >> > LoadIntFromMemory() at ExecutionEngine.cpp:887 0xb3c297 >> > llvm::ExecutionEngine::LoadValueFromMemory() at >> ExecutionEngine.cpp:915 >> 0xb3c3f9 >> > llvm::Interpreter::visitLoadInst() at Execution.cpp:812 0xa1f855 >> > llvm::InstVisitor<llvm::Interpreter, void>::visitLoad() at 0xa28357 >> > llvm::InstVisitor<llvm::Interpreter, void>::visit() at 0xa26b4e >> > llvm::Interpreter::run() at Execution.cpp:1,328 0xa235ff >> > llvm::Interpreter::runFunction() at Interpreter.cpp:95 0xa166fa >> > .... >> > So the segfaults happens because of the�memcpy call in >> the�LoadIntFromMemory >> > function in�ExecutionEngine.cpp on line 887... Any clue ? >> > >> > >> > Adding .setOptLevel(llvm::CodeGenOpt::None) to the�EngineBuilder >> creation >> > reduces the time by 25% but that is still not enough :( >> > >> > >> > 2010/11/3 T�r�k Edwin <edwintorok at gmail.com <mailto: >> edwintorok at gmail.com> >> <mailto:edwintorok at gmail.com <mailto:edwintorok at gmail.com>>> >> >> > >> > On Wed, 3 Nov 2010 11:18:34 +0000 >> > Salomon Brys <salomon.brys at gmail.com <mailto: >> salomon.brys at gmail.com> >> <mailto:salomon.brys at gmail.com <mailto:salomon.brys at gmail.com>>> >> wrote: >> > >> > > Jiting with no optimization does not reduce significantly the >> > > compilation with very small code... >> > >> > I mean the parameter to createJIT, OptLevel. Try setting it to >> None. >> > Or if you use EngineBuilder, setOptLevel(CodeGenOpt::None). >> > >> > > What is the local register allocator ??? >> > >> > -regalloc=fast, or -regalloc=local parameter to llc, or lli. >> > I think there was a programatic way to choose register >> allocator, but I >> > forgot how. >> > >> > Best regards, >> > --Edwin >> > >> > >> > >> > >> > -- >> > ########################################### >> > # Salomon BRYS >> > # +33 (0) 6 83 54 55 96 >> > #------------------------------------------ >> > # > EPITECH "Koala" : C++ assistant : Sbire du C++ >> > # > Zend Certified Engineer for PHP5 >> > #------------------------------------------ >> > # All data in this e-mail is confidential. >> > # If you are not, or if you don't believe you are, the recipient of >> this >> e-mail, >> > please delete it. >> > #------------------------------------------ >> > # GPG : http://gpgkey-salomon.antesocial.fr/ >> > ########################################### >> > >> > >> > >> > _______________________________________________ >> > LLVM Developers mailing list >> > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> >> http://llvm.cs.uiuc.edu >> >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> >> http://llvm.cs.uiuc.edu >> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> >> >> -- >> ########################################### >> # Salomon BRYS >> # +33 (0) 6 83 54 55 96 >> #------------------------------------------ >> # > EPITECH "Koala" : C++ assistant : Sbire du C++ >> # > Zend Certified Engineer for PHP5 >> #------------------------------------------ >> # All data in this e-mail is confidential. >> # If you are not, or if you don't believe you are, the recipient of this >> e-mail, >> please delete it. >> #------------------------------------------ >> # GPG : http://gpgkey-salomon.antesocial.fr/ >> ########################################### >> > >-- ########################################### # Salomon BRYS # +33 (0) 6 83 54 55 96 #------------------------------------------ # > EPITECH "Koala" : C++ assistant : Sbire du C++ # > Zend Certified Engineer for PHP5 #------------------------------------------ # All data in this e-mail is confidential. # If you are not, or if you don't believe you are, the recipient of this e-mail, please delete it. #------------------------------------------ # GPG : http://gpgkey-salomon.antesocial.fr/ ########################################### -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101103/d1331a07/attachment.html>