DIBuilder - what's with the null compile units?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

DIBuilder - what's with the null compile units?

Talin-3
Sometime about two months ago, something changed in LLVM that broke my frontend's ability to generate debug info. This was around the time that the requirement to call DIBuilder::finalize() was added (and yes, I am calling it.) Specifically, what I am seeing is an assertion failure in llc because it can't find the compile unit for a subroutine.

I took a look at the code in DIBuilder.cpp, and I see that indeed it is setting the compile unit to null for all of the various descriptors being created. I assume that the intent is that these references would be filled in later - but apparently this is not happening in my case. Any idea what could be wrong?

--
-- Talin

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DIBuilder - what's with the null compile units?

Devang Patel

On Sep 23, 2011, at 12:39 PM, Talin wrote:

> Sometime about two months ago, something changed in LLVM that broke my frontend's ability to generate debug info. This was around the time that the requirement to call DIBuilder::finalize() was added (and yes, I am calling it.) Specifically, what I am seeing is an assertion failure in llc because it can't find the compile unit for a subroutine.
>
> I took a look at the code in DIBuilder.cpp, and I see that indeed it is setting the compile unit to null for all of the various descriptors being created. I assume that the intent is that these references would be filled in later - but apparently this is not happening in my case.

They are not needed any more. During DIBuilder::finalize() the CompileUnit itself collects all required info, which is good enough for CodeGen DwarfWriter. The reason we inverted this graph is because it lets llvm linker unify mdnodes during LTO.

> Any idea what could be wrong?
>
> --
> -- Talin
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DIBuilder - what's with the null compile units?

Devang Patel
In reply to this post by Talin-3

On Sep 23, 2011, at 12:39 PM, Talin wrote:

> Sometime about two months ago, something changed in LLVM that broke my frontend's ability to generate debug info. This was around the time that the requirement to call DIBuilder::finalize() was added (and yes, I am calling it.) Specifically, what I am seeing is an assertion failure in llc because it can't find the compile unit for a subroutine.

I forgot to say earlier, that's a bug. Please file a PR with a test case.
-
Devang

>
> I took a look at the code in DIBuilder.cpp, and I see that indeed it is setting the compile unit to null for all of the various descriptors being created. I assume that the intent is that these references would be filled in later - but apparently this is not happening in my case. Any idea what could be wrong?
>
> --
> -- Talin
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DIBuilder - what's with the null compile units?

James Molloy-3
Hi,

Thanks for bringing this up, I'm just about to investigate an identical case which has broken our front-end. Both ours and clang generate subroutineinfo with null compilationunits, but ours asserts and clang's doesn't.

I'll take a look at this on Monday, if it is a bug in LLVM.

Cheers,

James

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Devang Patel
Sent: 23 September 2011 21:06
To: Talin
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] DIBuilder - what's with the null compile units?


On Sep 23, 2011, at 12:39 PM, Talin wrote:

> Sometime about two months ago, something changed in LLVM that broke my frontend's ability to generate debug info. This was around the time that the requirement to call DIBuilder::finalize() was added (and yes, I am calling it.) Specifically, what I am seeing is an assertion failure in llc because it can't find the compile unit for a subroutine.

I forgot to say earlier, that's a bug. Please file a PR with a test case.
-
Devang

>
> I took a look at the code in DIBuilder.cpp, and I see that indeed it is setting the compile unit to null for all of the various descriptors being created. I assume that the intent is that these references would be filled in later - but apparently this is not happening in my case. Any idea what could be wrong?
>
> --
> -- Talin
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DIBuilder - what's with the null compile units?

James Molloy-3
Hi Talin,

Followup as promised: in our case we weren't calling finalize(). As this manifests itself as exactly the same assertion failure as yours I suggest you double-check you are actually calling it before any passes run on the Module.

Functionally, instead of maintaining a pointer to the CU in all Debug nodes, the main CompilationUnit node has a list of subprogram nodes. It is from this that a map gets generated of Subprogram -> CU. If such a mapping doesn't exist, the assertion you see (assuming it is the same as ours) fires.

First thing I'd do is check the generated metadata. Is second-to-last parameter of the DW_TAG_subprogram metadata pointing at a pointer to NULL, or is it pointing at a pointer to DW_TAG_subprogram?

If the former, finalize() is not being run (or something is failing at that point). If the latter, your problem is different to ours.

Hope this helps,

James

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of James Molloy
Sent: 24 September 2011 09:38
To: Devang Patel; Talin
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] DIBuilder - what's with the null compile units?

Hi,

Thanks for bringing this up, I'm just about to investigate an identical case which has broken our front-end. Both ours and clang generate subroutineinfo with null compilationunits, but ours asserts and clang's doesn't.

I'll take a look at this on Monday, if it is a bug in LLVM.

Cheers,

James

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Devang Patel
Sent: 23 September 2011 21:06
To: Talin
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] DIBuilder - what's with the null compile units?


On Sep 23, 2011, at 12:39 PM, Talin wrote:

> Sometime about two months ago, something changed in LLVM that broke my frontend's ability to generate debug info. This was around the time that the requirement to call DIBuilder::finalize() was added (and yes, I am calling it.) Specifically, what I am seeing is an assertion failure in llc because it can't find the compile unit for a subroutine.

I forgot to say earlier, that's a bug. Please file a PR with a test case.
-
Devang

>
> I took a look at the code in DIBuilder.cpp, and I see that indeed it is setting the compile unit to null for all of the various descriptors being created. I assume that the intent is that these references would be filled in later - but apparently this is not happening in my case. Any idea what could be wrong?
>
> --
> -- Talin
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DIBuilder - what's with the null compile units?

Talin-3
Just a follow up on this - I am still having problems, I never did figure out a solution. (I've been running with debug off for the last month so that I could get work done.)

Here's what I am seeing: I am definitely calling DIBuilder::finalize(). I even put a debug print statement right after it, so that I could be sure that the code was being executed. I also insured that it was getting called before the module was written out, and that no additional debug information gets added after it has been called.

Yet despite this, the second-to-last parameter for DW_TAG_subprogram metadata is in fact null in the module dissassembly.

So essentially I am completely stumped.

On Mon, Sep 26, 2011 at 8:01 AM, James Molloy <[hidden email]> wrote:
Hi Talin,

Followup as promised: in our case we weren't calling finalize(). As this manifests itself as exactly the same assertion failure as yours I suggest you double-check you are actually calling it before any passes run on the Module.

Functionally, instead of maintaining a pointer to the CU in all Debug nodes, the main CompilationUnit node has a list of subprogram nodes. It is from this that a map gets generated of Subprogram -> CU. If such a mapping doesn't exist, the assertion you see (assuming it is the same as ours) fires.

First thing I'd do is check the generated metadata. Is second-to-last parameter of the DW_TAG_subprogram metadata pointing at a pointer to NULL, or is it pointing at a pointer to DW_TAG_subprogram?

If the former, finalize() is not being run (or something is failing at that point). If the latter, your problem is different to ours.

Hope this helps,

James

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of James Molloy
Sent: 24 September 2011 09:38
To: Devang Patel; Talin
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] DIBuilder - what's with the null compile units?

Hi,

Thanks for bringing this up, I'm just about to investigate an identical case which has broken our front-end. Both ours and clang generate subroutineinfo with null compilationunits, but ours asserts and clang's doesn't.

I'll take a look at this on Monday, if it is a bug in LLVM.

Cheers,

James

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Devang Patel
Sent: 23 September 2011 21:06
To: Talin
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] DIBuilder - what's with the null compile units?


On Sep 23, 2011, at 12:39 PM, Talin wrote:

> Sometime about two months ago, something changed in LLVM that broke my frontend's ability to generate debug info. This was around the time that the requirement to call DIBuilder::finalize() was added (and yes, I am calling it.) Specifically, what I am seeing is an assertion failure in llc because it can't find the compile unit for a subroutine.

I forgot to say earlier, that's a bug. Please file a PR with a test case.
-
Devang

>
> I took a look at the code in DIBuilder.cpp, and I see that indeed it is setting the compile unit to null for all of the various descriptors being created. I assume that the intent is that these references would be filled in later - but apparently this is not happening in my case. Any idea what could be wrong?
>
> --
> -- Talin
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.




--
-- Talin

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DIBuilder - what's with the null compile units?

Devang Patel

On Oct 23, 2011, at 12:03 AM, Talin wrote:

Just a follow up on this - I am still having problems, I never did figure out a solution. (I've been running with debug off for the last month so that I could get work done.)

Here's what I am seeing: I am definitely calling DIBuilder::finalize(). I even put a debug print statement right after it, so that I could be sure that the code was being executed. I also insured that it was getting called before the module was written out, and that no additional debug information gets added after it has been called.

Yet despite this, the second-to-last parameter for DW_TAG_subprogram metadata is in fact null in the module dissassembly.

So essentially I am completely stumped.

If you're using DIBuilder to create your subprogram then you'll see that it puts new node in AllSubprograms.

  // Create a named metadata so that we do not lose this mdnode.                                                                                                                
  AllSubprograms.push_back(Node);

And follow AllSubprograms in DIBuilder::finalize()

-
Devang

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DIBuilder - what's with the null compile units?

Talin-3
On Mon, Oct 24, 2011 at 9:17 AM, Devang Patel <[hidden email]> wrote:

On Oct 23, 2011, at 12:03 AM, Talin wrote:

Just a follow up on this - I am still having problems, I never did figure out a solution. (I've been running with debug off for the last month so that I could get work done.)

Here's what I am seeing: I am definitely calling DIBuilder::finalize(). I even put a debug print statement right after it, so that I could be sure that the code was being executed. I also insured that it was getting called before the module was written out, and that no additional debug information gets added after it has been called.

Yet despite this, the second-to-last parameter for DW_TAG_subprogram metadata is in fact null in the module dissassembly.

So essentially I am completely stumped.

If you're using DIBuilder to create your subprogram then you'll see that it puts new node in AllSubprograms.

  // Create a named metadata so that we do not lose this mdnode.                                                                                                                
  AllSubprograms.push_back(Node);

And follow AllSubprograms in DIBuilder::finalize()

I traced through the code in DIBuilder::finalize():
  for (unsigned i = 0, e = SPs.getNumElements(); i != e; ++i) {
    DISubprogram SP(SPs.getElement(i));
    if (NamedMDNode *NMD = getFnSpecificMDNode(M, SP)) {
      SmallVector<Value *, 4> Variables;
      for (unsigned ii = 0, ee = NMD->getNumOperands(); ii != ee; ++ii)

It looks as if getFnSpecificMDNode() is always returning NULL in my case -  the body of the if statement never gets executed.

--
-- Talin

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DIBuilder - what's with the null compile units?

Talin-3
On Thu, Oct 27, 2011 at 10:39 PM, Talin <[hidden email]> wrote:
On Mon, Oct 24, 2011 at 9:17 AM, Devang Patel <[hidden email]> wrote:

On Oct 23, 2011, at 12:03 AM, Talin wrote:

Just a follow up on this - I am still having problems, I never did figure out a solution. (I've been running with debug off for the last month so that I could get work done.)

Here's what I am seeing: I am definitely calling DIBuilder::finalize(). I even put a debug print statement right after it, so that I could be sure that the code was being executed. I also insured that it was getting called before the module was written out, and that no additional debug information gets added after it has been called.

Yet despite this, the second-to-last parameter for DW_TAG_subprogram metadata is in fact null in the module dissassembly.

So essentially I am completely stumped.

If you're using DIBuilder to create your subprogram then you'll see that it puts new node in AllSubprograms.

  // Create a named metadata so that we do not lose this mdnode.                                                                                                                
  AllSubprograms.push_back(Node);

And follow AllSubprograms in DIBuilder::finalize()

I traced through the code in DIBuilder::finalize():
  for (unsigned i = 0, e = SPs.getNumElements(); i != e; ++i) {
    DISubprogram SP(SPs.getElement(i));
    if (NamedMDNode *NMD = getFnSpecificMDNode(M, SP)) {
      SmallVector<Value *, 4> Variables;
      for (unsigned ii = 0, ee = NMD->getNumOperands(); ii != ee; ++ii)

It looks as if getFnSpecificMDNode() is always returning NULL in my case -  the body of the if statement never gets executed.

Tracing further, it appears that there are only 4 named MDNodes in the module:

!llvm.dbg.cu = !{!0}
!tart.module_deps = !{!349}
!roots.TraceTest = !{!350, !351, !352}
!tart.xdef.TraceTest = !{!112, !353, !354, !373, !374, !375}

In other words, the MDNodes that it is looking for never got created.
 
--
-- Talin



--
-- Talin

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DIBuilder - what's with the null compile units?

Devang Patel
In reply to this post by Talin-3

On Oct 27, 2011, at 10:39 PM, Talin wrote:

On Mon, Oct 24, 2011 at 9:17 AM, Devang Patel <[hidden email]> wrote:

On Oct 23, 2011, at 12:03 AM, Talin wrote:

Just a follow up on this - I am still having problems, I never did figure out a solution. (I've been running with debug off for the last month so that I could get work done.)

Here's what I am seeing: I am definitely calling DIBuilder::finalize(). I even put a debug print statement right after it, so that I could be sure that the code was being executed. I also insured that it was getting called before the module was written out, and that no additional debug information gets added after it has been called.

Yet despite this, the second-to-last parameter for DW_TAG_subprogram metadata is in fact null in the module dissassembly.

So essentially I am completely stumped.

If you're using DIBuilder to create your subprogram then you'll see that it puts new node in AllSubprograms.

  // Create a named metadata so that we do not lose this mdnode.                                                                                                                
  AllSubprograms.push_back(Node);

And follow AllSubprograms in DIBuilder::finalize()

I traced through the code in DIBuilder::finalize():
  for (unsigned i = 0, e = SPs.getNumElements(); i != e; ++i) {
    DISubprogram SP(SPs.getElement(i));
    if (NamedMDNode *NMD = getFnSpecificMDNode(M, SP)) {
      SmallVector<Value *, 4> Variables;
      for (unsigned ii = 0, ee = NMD->getNumOperands(); ii != ee; ++ii)

It looks as if getFnSpecificMDNode() is always returning NULL in my case -  the body of the if statement never gets executed.

The two lines above this for loop is 

  DIArray SPs = getOrCreateArray(AllSubprograms);
  DIType(TempSubprograms).replaceAllUsesWith(SPs);

This should populate your CompieUnit's   node that holds top level subprograms.
-
Devang


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: DIBuilder - what's with the null compile units?

Talin-3
On Fri, Oct 28, 2011 at 9:21 AM, Devang Patel <[hidden email]> wrote:

On Oct 27, 2011, at 10:39 PM, Talin wrote:

On Mon, Oct 24, 2011 at 9:17 AM, Devang Patel <[hidden email]> wrote:

On Oct 23, 2011, at 12:03 AM, Talin wrote:

Just a follow up on this - I am still having problems, I never did figure out a solution. (I've been running with debug off for the last month so that I could get work done.)

Here's what I am seeing: I am definitely calling DIBuilder::finalize(). I even put a debug print statement right after it, so that I could be sure that the code was being executed. I also insured that it was getting called before the module was written out, and that no additional debug information gets added after it has been called.

Yet despite this, the second-to-last parameter for DW_TAG_subprogram metadata is in fact null in the module dissassembly.

So essentially I am completely stumped.

If you're using DIBuilder to create your subprogram then you'll see that it puts new node in AllSubprograms.

  // Create a named metadata so that we do not lose this mdnode.                                                                                                                
  AllSubprograms.push_back(Node);

And follow AllSubprograms in DIBuilder::finalize()

I traced through the code in DIBuilder::finalize():
  for (unsigned i = 0, e = SPs.getNumElements(); i != e; ++i) {
    DISubprogram SP(SPs.getElement(i));
    if (NamedMDNode *NMD = getFnSpecificMDNode(M, SP)) {
      SmallVector<Value *, 4> Variables;
      for (unsigned ii = 0, ee = NMD->getNumOperands(); ii != ee; ++ii)

It looks as if getFnSpecificMDNode() is always returning NULL in my case -  the body of the if statement never gets executed.

The two lines above this for loop is 

  DIArray SPs = getOrCreateArray(AllSubprograms);
  DIType(TempSubprograms).replaceAllUsesWith(SPs);

This should populate your CompieUnit's   node that holds top level subprograms.
-
Devang

I created a bug (http://llvm.org/bugs/show_bug.cgi?id=11271) with some small example files that demonstrate the problems I am having. At this point I do not know whether the problem is in my frontend or in llc. An examination of the samples I uploaded might be able to determine at least that much: If the bitcode is correct, then it's a problem with llc; If the bitcode is wrong, then it's a problem in my frontend.

I've been attempting to trace through DIBuilder::finalize() in the debugger in order to determine what might be going wrong. Unfortunately, the code in that section is not easy to debug, because the various collection classes involved aren't very easy to examine in the debugger. (For example, it's hard to see in the debugger what the effect of replaceAllUses... is.)

--
-- Talin

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev