This is an archive of the discontinued LLVM Phabricator instance.

[DWARFVerifier] Allow simplified template names in debug_name
ClosedPublic

Authored by fdeazeve on Jul 19 2023, 9:25 AM.

Details

Summary

LLDB can benefit from having the base name of functions (i.e. without any
template parameters) as an entry into accelerator tables pointing back in the
DIE for the corresponding function specialization. In fact, some LLDB
functionality is only possible when those entries are present.

The DWARFLinker has been adding such entries for a while now, both with
apple_names and with debug_names. However, this has two side effects:

  1. Some LLDB functionality is only possible when dsym bundles are present (i.e.

the linker touched the debug info).

  1. The DWARFVerifier doesn't accept debug_name sections created by the linker,

as such names are (usually) neither the AT_name nor the AT_linkage_name of the
DIE.

Based on recent discussion [1], and because the DWARF 5 spec says that:

A producer may choose to implement additional rules for what names are placed
in the index

This patch relaxes the checks on the verifier to allow for simplified template
names in the accelerator table. To do so, we move some helper functions from
DWARFLinker into the core lib debug info. This addresses the point 2) above.

This patch also enables addressing point 1) in the future, since the helper
function is now visible to other parts of LLVM.

[1]: https://github.com/llvm/llvm-project/issues/58362

Diff Detail

Event Timeline

fdeazeve created this revision.Jul 19 2023, 9:25 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 19 2023, 9:25 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
fdeazeve requested review of this revision.Jul 19 2023, 9:25 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 19 2023, 9:25 AM
fdeazeve edited the summary of this revision. (Show Details)Jul 19 2023, 9:25 AM
aprantl accepted this revision.Jul 19 2023, 9:29 AM
This revision is now accepted and ready to land.Jul 19 2023, 9:29 AM
dblaikie added inline comments.Jul 19 2023, 9:50 AM
llvm/lib/DebugInfo/DWARF/DWARFVerifier.cpp
1361–1363

Could roll this in together

fdeazeve updated this revision to Diff 542095.Jul 19 2023, 10:18 AM

Address review comments

avl accepted this revision.Jul 19 2023, 10:36 AM

LGTM, with small suggestions inside.

llvm/lib/DebugInfo/DWARF/DWARFVerifier.cpp
1354–1355

probably use 3 here as initial size? As it may return three names now.

1363

nit: other places use emplace_back.

fdeazeve added inline comments.Jul 19 2023, 10:39 AM
llvm/lib/DebugInfo/DWARF/DWARFVerifier.cpp
1354–1355

Good call

1363

Other places have a const char*, which is why they emplace, not push. In the grand scheme of things, either will generate the same code, but I think the push here is the more expressive call: we are communicating that we already have a StringRef. Do you agree?

avl added inline comments.Jul 19 2023, 10:55 AM
llvm/lib/DebugInfo/DWARF/DWARFVerifier.cpp
1363

I am not sure that I follow... Other places might also use push_back even if they have const char* and vice versa this place can use emplace_back. It is just looks more uniformly if the single variant is used.

fdeazeve updated this revision to Diff 542124.Jul 19 2023, 11:15 AM

Use SmallVector of size 3 instead of 2.
Use emplace back to match the other uses in getNames.

llvm/lib/DebugInfo/DWARF/DWARFVerifier.cpp
1363

Other places might also use push_back even if they have const char*

Right, that's true because the StringRef(const char*) constructor is not explicit, but it is not generally true for all types. If we push_back(const char*), the StringRef is being implicitly constructed on the call to push_back; when we emplace_back(const char*), the StringRef is constructed inside the implementation of emplace_back.

But as I mentioned previously, this discussion is largely irrelevant for a simple type like StringRef, so I don't feel strongly either way. I'll use emplace_back!

dblaikie added inline comments.Jul 19 2023, 2:21 PM
llvm/lib/DebugInfo/DWARF/DWARFVerifier.cpp
1363

FWIW - +1 from me, that we should prefer push_back/non-direct init (X y = z; rather than X y(z);) whenever possible, because those forms are "less powerful" and make the code easier to read because as a reader you don't have to worry about more powerful operations happening when you see that syntax/function name. (eg: if I see push_back(ptr) I don't have to worry that that's taking ownership - if the contianer was over unique_ptrs then you'd have to pass emplace_back(ptr) and it'd be a clearer marker that memory ownership was happening)

fdeazeve added inline comments.Jul 19 2023, 3:19 PM
llvm/lib/DebugInfo/DWARF/DWARFVerifier.cpp
1363

I think given the trade-offs discussed here of consistency with other methods vs expressiveness of the intent behind {push/emplace}_back, I am going to revert to what I had previously and use push_back.

@dblaikie do you have other concerns with this patch?

fdeazeve updated this revision to Diff 542222.Jul 19 2023, 3:35 PM

Use push_back again

avl added inline comments.Jul 20 2023, 3:26 AM
llvm/lib/DebugInfo/DWARF/DWARFVerifier.cpp
1363

This is a minor issue and I do not ask for doing this way.
Though, I want to clarify my point. In this case, using
emplace_back(const char*) does not indicate that ownership
is taken. emplace_back(const char*) and emplace_back(StringRef)
are equal in that sense. When we have emplace_back() and push_back()
intermixed it looks like there is an important difference
in their usages. My original request was to do things in the same
way. All emplace_back(as in original code) or all push_back.

I think the intention for using emplace_back here was caused by
the desire to not call two constructors: one in push_back parameters (StringRef(const char*))
and another copy constructor inside push_back when placing an item into the vector.
Having all methods to be emplace_back shows that intention.

Having all methods to be push_back would show the intention that David has mentioned: using "less powerful" forms.

avl accepted this revision.Jul 20 2023, 3:27 AM
dblaikie added inline comments.Jul 24 2023, 1:25 PM
llvm/lib/DebugInfo/DWARF/DWARFVerifier.cpp
1363

if other code is using emplace_back where push_back is valid, then I think we should switch that code to use push_back - patches welcome?

(an extra StringRef ctor/move doesn't seem enough to justify a difference - that's pretty trivial)

Sorry, I was on vacation for the past few weeks.
Based on the discussion here, I will commit the patch as it is, and then we can address the push vs emplace consistency issue separately.

Oops, this created a warning in some bots. Will fix