Question about abstract subprograms in debug info

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

Question about abstract subprograms in debug info

Manman Ren

Hi,

I am working on an issue where a subprogram created here is having abstract_origin pointing to nowhere.
DIE *DwarfDebug::updateSubprogramScopeDIE(CompileUnit *SPCU,
                                          const MDNode *SPNode) {
  DIE *SPDie = SPCU->getDIE(SPNode);

  assert(SPDie && "Unable to find subprogram DIE!");
  DISubprogram SP(SPNode);

  // If we're updating an abstract DIE, then we will be adding the children and
  // object pointer later on. But what we don't want to do is process the
  // concrete DIE twice.
  if (DIE *AbsSPDIE = AbstractSPDies.lookup(SPNode)) {
    // Pick up abstract subprogram DIE.
    SPDie = new DIE(dwarf::DW_TAG_subprogram);
    SPCU->addDIEEntry(SPDie, dwarf::DW_AT_abstract_origin,
                      dwarf::DW_FORM_ref4, AbsSPDIE);
    SPCU->addDie(SPDie);
  }

}

The compile unit DIE where AbsSPDIE belongs to is different from the compile unit DIE SPCU->getCUDie().
So it is not legal to use a FORM_ref4 here.

Why do we create these subprogram DIEs here? They are added to SPCU, but not inserted via insertDIE, so they are not in the MDNodeToDieMap of the CU.

Another question is how to fix this if we need to create these subprograms.
Should we use FORM_ref_addr here? FORM_ref_addr is not supported yet, I am wondering whether that will break any debugger.
Another fix seems to be copying the attributes of the origin instead of using abstract_origin.

Thanks,
Manman
_______________________________________________
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: Question about abstract subprograms in debug info

Manman Ren

On Mar 8, 2013, at 5:49 PM, Manman Ren <[hidden email]> wrote:

>
> Hi,
>
> I am working on an issue where a subprogram created here is having abstract_origin pointing to nowhere.
> DIE *DwarfDebug::updateSubprogramScopeDIE(CompileUnit *SPCU,
>                                          const MDNode *SPNode) {
>  DIE *SPDie = SPCU->getDIE(SPNode);
>
>  assert(SPDie && "Unable to find subprogram DIE!");
>  DISubprogram SP(SPNode);
>
>  // If we're updating an abstract DIE, then we will be adding the children and
>  // object pointer later on. But what we don't want to do is process the
>  // concrete DIE twice.
>  if (DIE *AbsSPDIE = AbstractSPDies.lookup(SPNode)) {
>    // Pick up abstract subprogram DIE.
>    SPDie = new DIE(dwarf::DW_TAG_subprogram);
>    SPCU->addDIEEntry(SPDie, dwarf::DW_AT_abstract_origin,
>                      dwarf::DW_FORM_ref4, AbsSPDIE);
>    SPCU->addDie(SPDie);
>  }
> …
> }
>
> The compile unit DIE where AbsSPDIE belongs to is different from the compile unit DIE SPCU->getCUDie().
> So it is not legal to use a FORM_ref4 here.
>
> Why do we create these subprogram DIEs here? They are added to SPCU, but not inserted via insertDIE, so they are not in the MDNodeToDieMap of the CU.
>
> Another question is how to fix this if we need to create these subprograms.
> Should we use FORM_ref_addr here? FORM_ref_addr is not supported yet, I am wondering whether that will break any debugger.
Sorry, FORM_ref_addr is already there under lib/DebugInfo/, it is just not used in lib/CodeGen/.
I am checking whether using it instead of FORM_ref_4 will work.

Thanks,
Manman
> Another fix seems to be copying the attributes of the origin instead of using abstract_origin.
>
> Thanks,
> Manman


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