This is an archive of the discontinued LLVM Phabricator instance.

[clang] Don't emit debug vtable information for consteval functions
ClosedPublic

Authored by luken-google on Aug 29 2022, 11:08 AM.

Diff Detail

Event Timeline

luken-google created this revision.Aug 29 2022, 11:08 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 29 2022, 11:08 AM
luken-google requested review of this revision.Aug 29 2022, 11:08 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 29 2022, 11:08 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

Note that there's still an underlying issue where the linker complains of missing vtable information for both Base and Derived, which I'm treating as a separate issue and will either file or de-dup against an existing issue.

Maybe @aprantl you want to take a look at this.

clang/lib/CodeGen/CGDebugInfo.cpp
1762

It is not clear to me if this is the core issue or not. Can you explain this a little better.

clang/test/CodeGenCXX/cxx20-consteval-crash.cpp
95

Please add the newline back.

luken-google marked an inline comment as done.Aug 30 2022, 6:04 AM
luken-google added inline comments.
clang/lib/CodeGen/CGDebugInfo.cpp
1762

Thanks for the feedback!

Sure, here's what I'm thinking. This code calls ItaniumVTableContext::getMethodVTableIndex(GlobalDecl) on line 1771 below. That method asserts in VTableBuilder.cpp:2281 because it tries to look up a vtable entry for the consteval method and fails to do so. Any consteval methods are prevented from gaining vtable entries by the logic in VTableContextBase::hasVtableSlot(const CXXMethodDecl *MD):

bool VTableContextBase::hasVtableSlot(const CXXMethodDecl *MD) {
  return MD->isVirtual() && !MD->isConsteval();
}

This call is peppered throughout the VTableBuilder code, but the relevant call for our purposes is in ItaniumVTableBuilder::AddMethods() in VTableBuilder.cpp:1492, which causes any consteval method to be skipped when the code is iterating through all virtual member functions and adding them to the vtable.

My fix mirrors the logic in VTableContextBase::hasVtableSlot here, because the code assumes that if the method is virtual it has a vtable index, which consteval functions don't. Writing this, I've convinced myself it's better to just call that method directly, so I've refactored the code to avoid the duplicate logic.

Change to method call.

shafik accepted this revision.Aug 30 2022, 9:44 AM

LGTM

clang/lib/CodeGen/CGDebugInfo.cpp
1762

Thank you, that makes sense. Using the function call is much better, it avoids logic duplication and assures that if the logic is updated this section will stay in sync.

This revision is now accepted and ready to land.Aug 30 2022, 9:44 AM
dblaikie added inline comments.Sep 8 2022, 2:10 PM
clang/lib/CodeGen/CGDebugInfo.cpp
1763–1766

Seems this change means the virtual/pure virtual flags would be missed for these virtual-but-not-vtable functions? What does GCC do in terms of debug info for these functions? (I guess it's not super important/especially material - since these consteval functions probably can't ever get code generated for them, so a user can never call them & maybe it's more likely to be good for debuggers not to think of them as virtual functions (because they might expect vtable indexes, etc))