[llvm] r297072 - Verifier: Change Assert to AssertDI.

[Adrian Prantl via llvm-commits]

> On Mar 6, 2017, at 2:45 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Mon, Mar 6, 2017 at 2:36 PM Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>> wrote:
>> On Mar 6, 2017, at 2:21 PM, David Blaikie <dblaikie at gmail.com <mailto:dblaikie at gmail.com>> wrote:
>> 
>> 
>> 
>> On Mon, Mar 6, 2017 at 1:17 PM Adrian Prantl via llvm-commits <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
>> Author: adrian
>> Date: Mon Mar  6 15:05:14 2017
>> New Revision: 297072
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=297072&view=rev <http://llvm.org/viewvc/llvm-project?rev=297072&view=rev>
>> Log:
>> Verifier: Change Assert to AssertDI.
>> This error can be recovered from by stripping debug info.
>> This is NFC for +asserts builds.
>> 
>> Is there no way in a +Asserts build to get the behavior of "if debug info doesn't verify, strip it"? That seems... bad (untestable codepath that someone's relying on?).
> 
> The behavior is still there, but the assertion fires first :-)
> 
> Schrodinger's behavior - it's untested, it might work, might not - who knows?
>  
> We treat debug info verification errors as recoverable by stripping the debug info. But when assertions are enabled, we assert that even the debug info is correct. This allows us to find, e.g., bitcode upgrade bugs with asserts-enabled compilers during compiler qualification.
> 
> It is true that we cannot test the stripping behavior with assertions enabled. I had a vague memory that there was a command line option to force the noasserts behavior for some tools, but I must have misremembered or didn't find it.

Ha! I found it:

cl::opt<bool> LTOStripInvalidDebugInfo(
    "lto-strip-invalid-debug-info",
    cl::desc("Strip invalid debug info metadata during LTO instead of aborting."),
#ifdef NDEBUG
    cl::init(true),
#else
    cl::init(false),
#endif
    cl::Hidden);

with that I should be able to create a testcase for this change, too.

> 
> Please fix this or remove the fallback behavior. I'd personally prefer none of this goes behind an asserts modifier, but have a flag that makes it a "hard stop" or "silently drop" (is the hard stop behavior at all? Would a warning suffice? (a warning that could be promoted to error or demoted to silence would be ideal - but I realize LLVM's tools, etc, don't have that level of warning control, so depending on where/how this is all implemented that may not be practical))

That's pretty much the problem. This typically occurs during LTO where we don't have an amazing level of control, because it is in libLTO and driven by the linker.

-- adrian

> 
> - Dave
>  
> 
> -- adrian
> 
>>  
>> 
>> Modified:
>>     llvm/trunk/lib/IR/Verifier.cpp
>> 
>> Modified: llvm/trunk/lib/IR/Verifier.cpp
>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/IR/Verifier.cpp?rev=297072&r1=297071&r2=297072&view=diff <http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/IR/Verifier.cpp?rev=297072&r1=297071&r2=297072&view=diff>
>> ==============================================================================
>> --- llvm/trunk/lib/IR/Verifier.cpp (original)
>> +++ llvm/trunk/lib/IR/Verifier.cpp Mon Mar  6 15:05:14 2017
>> @@ -2734,9 +2734,9 @@ void Verifier::verifyCallSite(CallSite C
>>    // do so causes assertion failures when the inliner sets up inline scope info.
>>    if (I->getFunction()->getSubprogram() && CS.getCalledFunction() &&
>>        CS.getCalledFunction()->getSubprogram())
>> -    Assert(I->getDebugLoc(), "inlinable function call in a function with debug "
>> -                             "info must have a !dbg location",
>> -           I);
>> +    AssertDI(I->getDebugLoc(), "inlinable function call in a function with "
>> +                               "debug info must have a !dbg location",
>> +             I);
>> 
>>    visitInstruction(*I);
>>  }
>> 
>> 
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170306/098aa951/attachment.html>