Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vtable symbols are not marked artificial in DWARF #125126

Open
tromey opened this issue May 14, 2024 · 2 comments
Open

vtable symbols are not marked artificial in DWARF #125126

tromey opened this issue May 14, 2024 · 2 comments
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-debugging Working group: Bad Rust debugging experiences

Comments

@tromey
Copy link
Contributor

tromey commented May 14, 2024

I tried this code, from the gdb testsuite:

fn empty () {
}

fn main () {
    let array = [1,2,3,4];
    let slice = &array[1..2];
    let hello = "hello";

    empty();			// STOP
}

I compiled with -g.

Examining the resulting DWARF, I see:

 <1><2a>: Abbrev Number: 2 (DW_TAG_variable)
    <2b>   DW_AT_name        : (indirect string, offset: 0xf3): <std::rt::lang_start::{closure_env#0}<()> as core::ops::function::Fn<()>>::{vtable}
    <2f>   DW_AT_type        : <0x3d>
    <33>   DW_AT_location    : 9 byte block: 3 80 24 5 0 0 0 0 0 	(DW_OP_addr: 52480)

I think this should be marked with DW_AT_artificial, as it does not correspond to any user-written code in the CU. This will let gdb filter out these variables when displaying globals from a CU.

@tromey tromey added the C-bug Category: This is a bug. label May 14, 2024
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label May 14, 2024
@jieyouxu jieyouxu added A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-debugging Working group: Bad Rust debugging experiences and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels May 14, 2024
@cuviper
Copy link
Member

cuviper commented May 17, 2024

We have tests/codegen/debug-vtable.rs making sure that the type is artificial, and I also see that your example has DIFlagArtificial in the LLVM IR:

!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
!1 = distinct !DIGlobalVariable(name: "<std::rt::lang_start::{closure_env#0}<()> as core::ops::function::Fn<()>>::{vtable}", scope: null, file: !2, type: !3, isLocal: true, isDefinition: true)
!2 = !DIFile(filename: "<unknown>", directory: "")
!3 = !DICompositeType(tag: DW_TAG_structure_type, name: "<std::rt::lang_start::{closure_env#0}<()> as core::ops::function::Fn<()>>::{vtable_type}", file: !2, size: 384, align: 64, flags: DIFlagArtificial, elements: !4, vtableHolder: !14, templateParams: !23, identifier: "83627f9f9db11820e9b7128180480645")

But there's no sign of that in the output DWARF, neither on the variable nor its type:

 <1><2a>: Abbrev Number: 2 (DW_TAG_variable)
    <2b>   DW_AT_name        : (indirect string, offset: 0x7f): <std::rt::lang_start::{closure_env#0}<()> as core::ops::function::Fn<()>>::{vtable}
    <2f>   DW_AT_type        : <0x3d>
    <33>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0 	(DW_OP_addr: 0)
 <1><3d>: Abbrev Number: 3 (DW_TAG_structure_type)
    <3e>   DW_AT_containing_type: <0xb5>
    <42>   DW_AT_name        : (indirect string, offset: 0x14d): <std::rt::lang_start::{closure_env#0}<()> as core::ops::function::Fn<()>>::{vtable_type}
    <46>   DW_AT_byte_size   : 48
    <47>   DW_AT_alignment   : 8

@cuviper
Copy link
Member

cuviper commented May 17, 2024

For regular variables, the flag is applied here, because that Var.isArtificial() checks both the variable and the type. I don't see anything like that for global varables, so I tried adding this:

--- a/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
+++ b/llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp
@@ -200,6 +200,9 @@ DIE *DwarfCompileUnit::getOrCreateGlobalVariableDIE(
   else
     addGlobalName(GV->getName(), *VariableDIE, DeclContext);

+  if (GTy && GTy->isArtificial())
+    addFlag(*VariableDIE, dwarf::DW_AT_artificial);
+
   addAnnotation(*VariableDIE, GV->getAnnotations());

   if (uint32_t AlignInBytes = GV->getAlignInBytes())

And now I do see it in DWARF:

 <1><2a>: Abbrev Number: 2 (DW_TAG_variable)
    <2b>   DW_AT_name        : (indirect string, offset: 0x63): <std::rt::lang_start::{closure_env#0}<()> as core::ops::function::Fn<()>>::{vtable}
    <2f>   DW_AT_type        : <0x3d>
    <33>   DW_AT_artificial  : 1
    <33>   DW_AT_location    : 9 byte block: 3 0 0 0 0 0 0 0 0 	(DW_OP_addr: 0)

I'll try an LLVM PR with this change soon.

@cuviper cuviper added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label May 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-debugging Working group: Bad Rust debugging experiences
Projects
None yet
Development

No branches or pull requests

4 participants