DWARF regression with impl on nightly

[tromey]

I have a function in an impl like:

pub struct HasMethods {
    value: i32
}

impl HasMethods {
    pub fn take(self) -> HasMethods {
        self
    }
}

With nightly, I get DWARF like this:

 <2><178>: Abbrev Number: 3 (DW_TAG_namespace)
    <179>   DW_AT_name        : (indirect string, offset: 0x3d0): {{impl}}
    <17d>   DW_AT_decl_file   : 1
    <17e>   DW_AT_decl_line   : 40
...
 <3><1c8>: Abbrev Number: 11 (DW_TAG_subprogram)
    <1c9>   DW_AT_low_pc      : 0x54c0
    <1d1>   DW_AT_high_pc     : 0x12
    <1d5>   DW_AT_frame_base  : 1 byte block: 56    (DW_OP_reg6 (rbp))
    <1d7>   DW_AT_linkage_name: (indirect string, offset: 0x481): _ZN7methods8{{impl}}4takeE
    <1db>   DW_AT_name        : (indirect string, offset: 0x49c): take
    <1df>   DW_AT_decl_file   : 1
    <1e0>   DW_AT_decl_line   : 50
    <1e1>   DW_AT_type        : <0x90>

There are a few problems with this.

First, the namespace {{impl}} does not seem very useful. In 1.8 the namespace was named HasMethods, after the struct -- this made it quite easy for gdb to find methods associated with a type.

Second, the {{impl}} in the linkage_name also seems peculiar. This is also another situation where the linkage name attribute differs from the real linkage name -- rendering the attribute useless.

if this change was intentional, then I think gdb will need some other way to find the methods in an impl of a particular type. I don't see any way to get that information now.

[sanxiyn]

Yes, this is intentional, and was done in #32293.

As I understand, the PR added a new (hopefully much better) name generation scheme to rustc, and migrated symbol name generation to the new scheme. Debug name generation still uses the old scheme and needs to be migrated.

[michaelwoerister]

@sanxiyn is right. This is an area where quite a bit of work is happening at the moment because we are restructuring some things for incremental compilation.

We could also think about handling this case of inherent impls/methods like it's done for object oriented languages, i.e. make the method DIE a child entry of the struct DIE.

[tromey]

Making the method DIEs children of struct DIEs would work fine for gdb; and it would be a reasonably clear and faithful translation. So +1 to that.

[michaelwoerister]

OK, so I made a proof of concept for this and LLVM seems to handle it just fine. However, this approach does not scale to trait implementations as one type can implement multiple methods with the same name from different traits...

I'll implement it this way for inherent impls anyway, for now. Still cleaner than the (now broken) "parallel namespace" solution.

[michaelwoerister]

While implementing this properly, I found another wrinkle in the story:
Rust allows methods not just on structs and enums but also on basic types, pointer- and reference types, slices, etc. LLVM seems to translate that well to DWARF (the subroutine DIEs end up as children of the DW_TAG_base_type, DW_TAG_pointer_type, etc DIEs) and GDB also does not seem to have a problem with that. However, I'm not sure that the DWARF standard actually allows for this.

[tromey]

Don't worry too much about what DWARF says. It's fairly normal to extend DWARF in this way; very little is truly forbidden.

One way to look at it is that you're defining what the DWARF binding for Rust should be.

If you'd rather to back to using a namespace, that would also be fine for gdb. The main issue here was that the name of that namespace changed from the type's name to {{{impl}}}, which isn't that useful.