[LLVMdev] opt -verify

Ryan M. Lefever lefever at crhc.uiuc.edu
Thu Feb 22 14:17:23 PST 2007


I also tried iterating through the functions of the module and calling 
verifyFunction(), which also returns false, but does not cause an abort 
or report anything to stderr about what caused the verification to fail. 
  From the doxygen for verifyFunction() and verifyModule(), it seems 
like they both should print information to stderr if the verification 
fails and should abort opt if AbortProcessAction is passed as parameter. 
  Is this a bug?

Ryan M. Lefever wrote:
> I followed what you said and called verifyModule() with the 
> AbortProcessAction option.  verifyModule() returns false, but does not 
> abort and does not print out any information about what caused the 
> verification to fail.
> 
> Chris Lattner wrote:
> 
>>On Wed, 21 Feb 2007, Ryan M. Lefever wrote:
>>
>>>I am writing an interprocedural compiler pass.  Because the passneeds
>>>information from a FunctionPass, e.g., the post-dominance frontier
>>>(PDF), and because a ModulePass is not permitted to require a
>>>FunctionPass, I am forced to make my pass a FunctionPass and do majority
>>>of its work in the doFinalization() method.
>>
>>ok
>>
>>
>>>When I run "opt -mypass -verify -o code2.bc code1.bc" I get no
>>>complaints.  However, if I then try run "opt -simplifycfg -verify -o
>>>code3.bc code2.bc," I get the assertion failure below.  If thought that
>>>the verify option should have made sure that bytecode written to
>>>code2.bc was correct.  Am I incorrect?
>>
>>Yes.  the passmanager runs the passes in roughly this order:
>>
>>1. doinitialization for mypass and verify
>>2. runOnModule for mypass
>>3. verifier::runOnFunction for each function
>>4. dofinalization for mypass
>>5. dofinalization for verify
>>
>>Because you'd doing your xform in #4, but verifier checks the code at #3, 
>>you lose :(
>>
>>However, there is hope!  Just call "llvm/Analysis/Verifier.h" -> 
>>verifyModule or verifyFunction explicitly in your pass.
>>
>>-Chris
>>
>>
>>>opt: Reader.cpp:1978: llvm::Value*
>>>llvm::BytecodeReader::ParseConstantPoolValue(unsigned int): Assertion
>>>`(!isa<Constant>(Result) || !cast<Constant>(Result)->isNullValue()) ||
>>>!hasImplicitNull(TypeID) && "Cannot read null values from bytecode!"'
>>>failed.
>>>opt((anonymous namespace)::PrintStackTrace()+0x1a)[0x8645bae]
>>>opt((anonymous namespace)::SignalHandler(int)+0x112)[0x8645e74]
>>>[0x70f420]
>>>/lib/libc.so.6(abort+0x101)[0x4cab64f1]
>>>/lib/libc.so.6(__assert_fail+0xfd)[0x4caae859]
>>>opt(llvm::BytecodeReader::ParseConstantPoolValue(unsigned
>>>int)+0x1b31)[0x856e825]
>>>opt(llvm::BytecodeReader::ParseConstantPool(std::vector<llvm::BytecodeReader::ValueList*,
>>>std::allocator<llvm::BytecodeReader::ValueList*> >&,
>>>std::vector<llvm::PATypeHolder, std::allocator<llvm::PATypeHolder> >&,
>>>bool)+0x147)[0x856e985]
>>>opt(llvm::BytecodeReader::ParseModule()+0x188)[0x856edfe]
>>>opt(llvm::BytecodeReader::ParseBytecode(unsigned char const*, unsigned
>>>int, std::basic_string<char, std::char_traits<char>,
>>>std::allocator<char> > const&, std::basic_string<char,
>>>std::char_traits<char>, std::allocator<char> >*)+0x539)[0x856f6c1]
>>>opt((anonymous
>>>namespace)::BytecodeFileReader::read(std::basic_string<char,
>>>std::char_traits<char>, std::allocator<char> >*)+0xeb)[0x855b569]
>>>opt(llvm::getBytecodeModuleProvider(std::basic_string<char,
>>>std::char_traits<char>, std::allocator<char> > const&,
>>>std::basic_string<char, std::char_traits<char>, std::allocator<char> >*,
>>>llvm::BytecodeHandler*)+0x93)[0x855b60b]
>>>opt(llvm::ParseBytecodeFile(std::basic_string<char,
>>>std::char_traits<char>, std::allocator<char> > const&,
>>>std::basic_string<char, std::char_traits<char>, std::allocator<char>
>>>
>>>>*)+0x20)[0x855b88e]
>>>
>>>opt(main+0x7e)[0x8378c90]
>>>/lib/libc.so.6(__libc_start_main+0xdc)[0x4caa24e4]
>>>opt(__gxx_personality_v0+0x149)[0x836bac1]
>>>Abort
>>>
>>>Regards,
>>>Ryan
>>>
>>>
>>>
>>
>>-Chris
>>
> 
> 

-- 
Ryan M. Lefever  [http://www.ews.uiuc.edu/~lefever]



More information about the llvm-dev mailing list