[LLVMdev] opt -verify

Reid Spencer rspencer at reidspencer.com
Thu Feb 22 14:48:27 PST 2007


Ryan,


On Thu, 22 Feb 2007 16:26:24 -0600
  "Ryan M. Lefever" <lefever at crhc.uiuc.edu> wrote:
> I think I misread the doxygen.  verifyFunction & 
>verifyModule return 
> false if no errors are detected.  However, my question 
>now becomes why 
> does the code produced by my transform pass 
>verification, but it causes 
> an assertion failure in the byte reader when it (the 
>code produced by my 
> transform) is passed to another invocation of opt?

There's only two explanations for that:

1. The verifier isn't catching something it should
2. There's a bug in the bytecode reader/writer.

Reid.

> 
> Ryan M. Lefever wrote:
>> 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]
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list