This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Fix debug info for imported declarations of inlined functions
AbandonedPublic

Authored by ellis on Sep 22 2021, 3:25 PM.

Details

Reviewers
dblaikie
Summary

When searching for a subprogram DIE in getOrCreateSubprogramDIE(), also search through the abstract origin DIEs by default. This fixes imported declarations that reference inlined functions which are also removed.

The exception is in updateSubprogramScopeDIE() where we do not want to add pc attributes to abstract origin SPs.

Special thanks to @krisb for finding this bug in https://reviews.llvm.org/D109703#2998350.

Fixes https://bugs.llvm.org/show_bug.cgi?id=52159

Event Timeline

ellis created this revision.Sep 22 2021, 3:25 PM
ellis requested review of this revision.Sep 22 2021, 3:25 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 22 2021, 3:25 PM
krisb added a subscriber: krisb.Sep 23 2021, 2:58 AM

Thank you for the patch! I thought about exactly the same change :)
But I also started thinking that we may have similar problems for other entities that have inlined function as a scope.
For example, a type defined within a function will also have an empty parent subprogram:

inline __attribute__((always_inline))
int foo() {
  struct S { int a; int b; };
  S s({4,5});
  return s.a;
}

int main() {
  return foo();
}

It would be great if we could fix all the issues with inlined functions here.

There have been a few different patches going around related to mis-scoped things - imported entities and types, maybe other things too? (static variables? Or has that already been fixed now) Perhaps some summary of the state of all these patches sent to llvm-dev/linked from the various reviews would be helpful? It'd be good to know if/how all these patches are hopefully aiming for some unified solution.

ellis updated this revision to Diff 376645.Oct 1 2021, 3:34 PM

Make the solution more general

ellis retitled this revision from [DebugInfo] Fix imported declarations of inlined subprograms to [DebugInfo] Fix debug info for imported declarations of inlined functions.Oct 1 2021, 3:45 PM
ellis edited the summary of this revision. (Show Details)
ellis edited the summary of this revision. (Show Details)

I don't think this is the right approach - because it depends on the abstract SP being created before the query - and would produce a different result if the abstract SP is created after the query. Abstract SPs are created only once an inlined subroutine is discovered, I believe - so the DWARF would be different depending on function ordering - in some cases having things attached to the abstract DIE, in some cases to the concrete DIE. That's not ideal.

Looking at the callers, for instance - constructCallSiteEntryDIE looks like it could have that issue with the new getOrCreateSubprogramDIE behavior - depending on whether the call site is before or after the first inlining of the caller, the DWARF would point to the abstract origin or the (possibly incorrect/invalid/weird-empty) concrete subprogram DIE, perhaps?

ellis added a comment.Oct 12 2021, 5:26 PM

I don't think this is the right approach - because it depends on the abstract SP being created before the query - and would produce a different result if the abstract SP is created after the query. Abstract SPs are created only once an inlined subroutine is discovered, I believe - so the DWARF would be different depending on function ordering - in some cases having things attached to the abstract DIE, in some cases to the concrete DIE. That's not ideal.

Looking at the callers, for instance - constructCallSiteEntryDIE looks like it could have that issue with the new getOrCreateSubprogramDIE behavior - depending on whether the call site is before or after the first inlining of the caller, the DWARF would point to the abstract origin or the (possibly incorrect/invalid/weird-empty) concrete subprogram DIE, perhaps?

I found that constructCallSiteEntryDIE() is actually called in endFunctionImpl() after constructAbstractSubprogramScopeDIE() is called for each scope in the function, so those inlined SPs will have abstract origins.

But regardless, I kind of agree with you since there are several call sites and I'm not sure I've considered all cases. For now, I'm going to update D108492 so that it doesn't depend on this and I'll also send an email to the llvm-dev explaining what I know about this. Thanks!

ellis planned changes to this revision.Oct 13 2021, 2:49 PM
ellis edited the summary of this revision. (Show Details)