<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:dblaikie@gmail.com" title="David Blaikie <dblaikie@gmail.com>"> <span class="fn">David Blaikie</span></a>
</span> changed
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - Inlining corrupts debug locations if call-site's debug location is unknown"
href="http://llvm.org/bugs/show_bug.cgi?id=20907">bug 20907</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>NEW
</td>
<td>RESOLVED
</td>
</tr>
<tr>
<td style="text-align:right;">Resolution</td>
<td>---
</td>
<td>INVALID
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - Inlining corrupts debug locations if call-site's debug location is unknown"
href="http://llvm.org/bugs/show_bug.cgi?id=20907#c8">Comment # 8</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - Inlining corrupts debug locations if call-site's debug location is unknown"
href="http://llvm.org/bugs/show_bug.cgi?id=20907">bug 20907</a>
from <span class="vcard"><a class="email" href="mailto:dblaikie@gmail.com" title="David Blaikie <dblaikie@gmail.com>"> <span class="fn">David Blaikie</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=20907#c7">comment #7</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=20907#c6">comment #6</a>)
> > That would be ideal - for you and for me. Once you add a debug location to
> > the call site then you won't have to strip all the debug info out of the
> > debug function that's called from the glue - and if the glue is inlined
> > (along with the debug function already inlined into the glue) you should get
> > an inlined scope for the inner debug function in the outer debug function -
> > the glue will just be un-attributed instructions in the outer function.
>
> OK, we'll do that then.</span >
Great!
<span class="quote">> > > However, it would be nice to at least provide an earlier assertion in the
> > > inlining pass that makes sure that this kind of thing doesn't occur. It was
> > > rather time-consuming to find out what the actual problem was. Just some
> > > kind of hint that call-sites must have debug info if their call is inlined
> > > and the inlined instructions *do* have debuginfo.
> >
> > Agreed - I debugged several of these issue & they were painful to varying
> > degrees.
> >
> > You'll see that in the patch that was reverted, there's a change to the
> > debug info verifier. This can be enabled (I forget how, exactly) in LLVM and
> > run between each optimization pass - so it should diagnose the pass that
> > violates the desired invariant (that any instruction in a debug-having
> > function, has a scope chain that leads back to that function, not any other
> > functioN)
>
> That sounds incredibly useful :)</span >
Yep - it should be accessible, I think, via "-mllvm -verify-debug-info" (you
could try locally unreverting my patch and using those flags to see if they
diagnose the problem you have)</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>