[llvm] r214761 - Reapply "DebugInfo: Ensure that all debug location scope chains from instructions within a function, lead to the function itself."

Reid Kleckner rnk at google.com
Mon Oct 6 14:16:53 PDT 2014


Aha, this asserts on both Windows and Linux.

On Mon, Oct 6, 2014 at 11:50 AM, Reid Kleckner <rnk at google.com> wrote:

> On Mon, Oct 6, 2014 at 11:39 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
>> That would be mighty unfortunate... :/ Perhaps we can find some
>> assertions to put in to stabilize the failure, though I haven't a clue what
>> they'd be just yet.
>>
>
> I'm staring at the .ll file diff, trying to figure out what went wrong.
> There are several small differences, and I wonder if they are for things
> like order of evaluation, where the only difference is a use-list order
> change.
>
> Yep, that test case doesn't produce an assertion for me. Crud. What's a
>> useful way for me to debug this on a Windows machine? Am I just going to
>> have to sit with you/someone - or can I get remote access somehow (from
>> Linux, ideally?)?
>>
>
> Most Windows remote access solutions tend to take over the primary screen,
> unless you have some server OS variant, so if you want to debug it directly
> you'd want to rig up a local VM. This is doable, there are gwindows images
> you can fetch, but I'll let you know why I give up over here. :)
>
> Here's the function we assert on:
>
> ; Function Attrs: noreturn nounwind
> define internal void @"\01??$assert_cast at PAVRedeclarableTemplateDecl@clang@@@@YAPAVRedeclarableTemplateDecl at clang@@ZZ"() #4 {
> entry:
>   tail call void @"\01?llvm_unreachable_internal at llvm@@YAXPBD0I at Z"(i8* getelementptr inbounds ([16 x i8]* @"\01??_C at _0BA@OELEAIJA at bad?5assert_cast?$AA@", i32 0, i32 0), i8* getelementptr inbounds ([51 x i8]* @"\01??_C at _0DD@BABLEMGH@?4?4?2tools?2clang?2lib?2Serialization@", i32 0, i32 0), i32 2108) #12, !dbg !34160
>   unreachable, !dbg !34160
> }
>
> There are no diffs in the code, but here's some related debug info that is
> suspiciously different:
>
> -!1590 = metadata !{metadata !"0x2e\00assert_cast<clang::NamespaceDecl *>\00assert_cast<clang::NamespaceDecl *>\00\002107\001\001\000\000\00256\001\002107", metadata !13, metadata !14, metadata !7, null, void ()* @"\01??$assert_cast at PAVRedeclarableTemplateDecl@clang@@@@YAPAVRedeclarableTemplateDecl at clang@@ZZ", null, null, metadata !2}
> +!1590 = metadata !{metadata !"0x2e\00assert_cast<clang::NamespaceDecl *>\00assert_cast<clang::NamespaceDecl *>\00\002107\001\001\000\000\00256\001\002107", metadata !13, metadata !14, metadata !7, null, null, null, null, metadata !2} ; [ DW_TAG_subprogram ] [line 2107] [local] [def] [assert_cast<clang::NamespaceDecl *>]
>
> Thoughts?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141006/265e5147/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.cpp
Type: text/x-c++src
Size: 485 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141006/265e5147/attachment.cpp>


More information about the llvm-commits mailing list