Page MenuHomePhabricator

[Clang][LLVM] generate btf_tag annotations for DISubprogram types
ClosedPublic

Authored by yonghong-song on Jul 22 2021, 5:27 PM.

Details

Summary

Generate btf_tag annotations for DISubprogram types.
A field "annotations" is introduced to DISubprogram, and
annotations are represented as an DINodeArray, similar to
DIComposite elements. The following example illustrates how
annotations are encoded in IR:

distinct !DISubprogram(..., annotations: !10)
!10 = !{!11, !12}
!11 = !{!"btf_tag", !"a"}
!12 = !{!"btf_tag", !"b"}

Diff Detail

Event Timeline

yonghong-song created this revision.Jul 22 2021, 5:27 PM
yonghong-song requested review of this revision.Jul 22 2021, 5:27 PM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptJul 22 2021, 5:27 PM
  • add more cases in clang test attr-btf_tag-disubprogram.c

@dblaikie could you take a look at this patch? Similar to a couple of previous similar patches, if accepted, I will break the patch into two pieces, one for clang and another for llvm, and commit them separately.

The clang side might benefit from a test with a function declaration, a call to that function, but no definition of it - with optimizations enabled, clang should emit the DISubprogram for that function for the purpose of call site DWARF, I think? (or maybe that behavior got rolled back for now? In which case the nearest thing I can think of/the only other place where we produce DWARF for a declaration would be for a member function declaration in a type DIE - are btf attributes supported there (or are they only supported in C, in which case there's no such thing as a member function)?

The clang side might benefit from a test with a function declaration, a call to that function, but no definition of it - with optimizations enabled, clang should emit the DISubprogram for that function for the purpose of call site DWARF, I think? (or maybe that behavior got rolled back for now? In which case the nearest thing I can think of/the only other place where we produce DWARF for a declaration would be for a member function declaration in a type DIE - are btf attributes supported there (or are they only supported in C, in which case there's no such thing as a member function)?

This is a good point. I missed the extern function invocation may generate function debuginfo. I will fix my code and add a test for that.
For member function, btf_tag is C only, so we can ignore member function for now.

  • add annotations to DISubprogram generated for extern functions called in the current cu and add a test for that.
dblaikie added inline comments.Wed, Aug 25, 7:49 PM
clang/test/CodeGen/attr-btf_tag-disubprogram-2.c
5–14 ↗(On Diff #368789)

Any particular reason this needs to be split out into its own file (perhaps the filename could describe the reason a bit - help explain what's tricky/different about this, rather than being differentiated only by 1 or 2), or could this be rolled into the other test file?

yonghong-song added inline comments.Wed, Aug 25, 9:52 PM
clang/test/CodeGen/attr-btf_tag-disubprogram-2.c
5–14 ↗(On Diff #368789)

The reason is -1 doesn't have any optimization flag and -2 has -O2 in order to generate debuginfo. I will rename the second file with suffix like -callsite to be clear.

  • rename test file names properly
dblaikie accepted this revision.Wed, Aug 25, 10:40 PM

Eh, sure, don't mind about the test either way (the other test cases are optimization agnostic, I think - so they could all be lumped in together - there might also be a flag to turn on call site debug info irrespective of optimization level, which might make the test case more self documenting, perhaps you could check if that's the case?)

This revision is now accepted and ready to land.Wed, Aug 25, 10:40 PM

We have

llvm::DINode::DIFlags CGDebugInfo::getCallSiteRelatedAttrs() const {
  // Call site-related attributes are only useful in optimized programs, and
  // when there's a possibility of debugging backtraces.
  if (!CGM.getLangOpts().Optimize || DebugKind == codegenoptions::NoDebugInfo ||
      DebugKind == codegenoptions::LocTrackingOnly)
    return llvm::DINode::FlagZero;

and getCallSiteRelatedAttrs() is used to check whether debuginfo
should be emitted or not by comparing to llvm::DINode::FlagZero,

// Do not emit a declaration subprogram for a builtin, a function with nodebug
// attribute, or if call site info isn't required. Also, elide declarations
// for functions with reserved names, as call site-related features aren't
// interesting in this case (& also, the compiler may emit calls to these
// functions without debug locations, which makes the verifier complain).
if (CalleeDecl->getBuiltinID() != 0 || CalleeDecl->hasAttr<NoDebugAttr>() ||
    getCallSiteRelatedAttrs() == llvm::DINode::FlagZero)
  return;

So looks like as long as the optimization is not on, the condition
!CGM.getLangOpts().Optimize will be true and the callsite debuginfo
will not be emitted.

This revision was landed with ongoing or failed builds.Thu, Aug 26, 8:25 AM
This revision was automatically updated to reflect the committed changes.