[LLVMdev] opt -verify

Devang Patel dpatel at apple.com
Thu Feb 22 14:32:16 PST 2007


On Feb 22, 2007, at 2:17 PM, 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.

If verifyFunction() return false then it means  it is not broken. I  
think you want
to use verifyModule() for your case.

-
Devang


>   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