Page MenuHomePhabricator

[CGDebugInfo] Emit subprograms for decls when AT_tail_call is understood
ClosedPublic

Authored by vsk on Fri, Nov 1, 5:57 PM.

Details

Summary

Currently, clang emits subprograms for declared functions when the
target debugger or DWARF standard is known to support entry values
(DW_OP_entry_value & the GNU equivalent).

Treat DW_AT_tail_call the same way to allow debuggers to follow cross-TU
tail calls.

Pre-patch debug session with a cross-TU tail call:

* frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt]
  frame #1: 0x0000000100000f99 main`main at a.c:8:10 [opt]

Post-patch (note that the tail-calling frame, "helper", is visible):

* frame #0: 0x0000000100000fa4 main`target at b.c:4:3 [opt]
  frame #1: 0x0000000100000f80 main`helper [opt] [artificial]
  frame #2: 0x0000000100000f99 main`main at a.c:8:10 [opt]

rdar://46577651

Diff Detail

Event Timeline

vsk created this revision.Fri, Nov 1, 5:57 PM
vsk edited the summary of this revision. (Show Details)Fri, Nov 1, 8:18 PM
djtodoro accepted this revision.Mon, Nov 4, 2:16 AM

@vsk Thanks for this!
(lgtm)

This revision is now accepted and ready to land.Mon, Nov 4, 2:16 AM
aprantl accepted this revision.Mon, Nov 4, 12:31 PM

What's the extra DWARF that's emitted from the backend? Is there a corresponding LLVM code change/test, or is the functionality there but dormant in this particular case? (& already running/tested in other cases, such as when fn1 is defined in the same CU)

vsk added a comment.Mon, Nov 4, 1:43 PM

What's the extra DWARF that's emitted from the backend? Is there a corresponding LLVM code change/test, or is the functionality there but dormant in this particular case? (& already running/tested in other cases, such as when fn1 is defined in the same CU)

The extra DWARF would look like:

DW_TAG_subprogram
                DW_AT_name	("fn1")
                DW_AT_declaration	(true)

This clang change has no corresponding llvm logic change. The functionality to emit a subprogram for a declaration is already present & tested in llvm, as is the logic to use such a subprogram to create a TAG_call_site (llvm/test/DebugInfo/X86/dwarf-callsite-related-attrs.ll is a test, and the logic is in DwarfDebug::constructCallSiteEntryDIEs). That test should cover the case where a function has no subprogram, though.

vsk updated this revision to Diff 227774.Mon, Nov 4, 1:44 PM
vsk edited the summary of this revision. (Show Details)
  • Add coverage for a callee without a subprogram in llvm/test/DebugInfo/X86/dwarf-callsite-related-attrs.ll.
Herald added a project: Restricted Project. · View Herald TranscriptMon, Nov 4, 1:44 PM
In D69743#1733101, @vsk wrote:

What's the extra DWARF that's emitted from the backend? Is there a corresponding LLVM code change/test, or is the functionality there but dormant in this particular case? (& already running/tested in other cases, such as when fn1 is defined in the same CU)

The extra DWARF would look like:

DW_TAG_subprogram
                DW_AT_name	("fn1")
                DW_AT_declaration	(true)

This clang change has no corresponding llvm logic change. The functionality to emit a subprogram for a declaration is already present & tested in llvm, as is the logic to use such a subprogram to create a TAG_call_site (llvm/test/DebugInfo/X86/dwarf-callsite-related-attrs.ll is a test, and the logic is in DwarfDebug::constructCallSiteEntryDIEs). That test should cover the case where a function has no subprogram, though.

OK, thanks for the context!

This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMon, Nov 4, 3:15 PM