Re: [PATCH] c++/8218: Destructors w/arguments.

[Keith Seitz <keiths@redhat.com>]

On 03/09/2017 07:04 AM, Pedro Alves wrote:
> That's quite surprising. 

Sorry, I meant there are no differences in the test suite. I did not
test by hand, believing also that it would manifest as you indicated.

> But, in reality, it's the opposite.  The difference between stabs and dwarf,
> is that stabs goes through the (demangled_name != NULL) path while DWARF
> goes through the "fallback" (demangled_name == NULL) path.  Because:
> 
> Stabs:
> 
>  (top-gdb) p mangled_name
>  $1 = 0x2fb3940 "_ZN1A3fooEi"
>  (top-gdb) p demangled_name
>  $2 = 0x2fc80b0 "A::foo(int)"
>  (top-gdb) 
> 
> DWARF:
> 
>  (top-gdb) p mangled_name
>  $1 = 0x2fcdfe0 "A::foo(int)"
>  (top-gdb) p demangled_name
>  $2 = 0x0
> 
> Eh, "mangled_name" is fetched from "TYPE_FN_FIELD_PHYSNAME (f, j)"
> just above.  And PHYSNAME is the demangled name in DWARF/C++...
> 
> I never quite got why that is (why PHYSNAME is the demangled
> name in C++), and there are still comments all over the place that
> suggest that PHYSNAME is the mangled name.  Plus the variables names
> suggest that too.  It's ... confusing.

Long story short: the symbol tables only stored linkage names. That
means every time we attempt to match a name to a symbol (every time we
call strcmp_iw essentially), we need to demangle. Every time we print
out a symbol, we demangle. Every time we do anything with any symbol, we
demangle it. I originally had a working code base to do this. As you can
imagine, it was terribly slow.

Users don't typically type "b _ZN1AD0Ev". They type "b A::~A". If we
could convince users to use only linkage names, we'd be in great shape.

If we didn't care about memory footprint, we'd be in great shape.

If we had access to the same mangler the compiler uses, we'd be in great
shape.

But we have none of those things.

Do maintainers want to reassess this?

> This got to be the multiple destructors.  (not-in-charge / charge)

Sure is. [I apologize, my post was not explicit on that point.]

>> I've no explanation as to why we don't hide these implementation details
>> other than to offer a truly pedantic view of the code.
> 
> I can see value in being able to refer to to the artificial arguments
> and distinguish the different overloads.  E.g., if one is trying to debug
> one of the multiple ctor/dtors:
> 
> (gdb) b VA3::~VA3
> Breakpoint 2 at 0x40098c: VA3::~VA3. (3 locations)
> (gdb) info breakpoints 
> Num     Type           Disp Enb Address            What
> 2       breakpoint     keep y   <MULTIPLE>         
> 2.1                         y     0x000000000040098c in VA3::~VA3() at virtual.cc:5
> 2.2                         y     0x00000000004009f6 in VA3::~VA3() at virtual.cc:5
> 2.3                         y     0x0000000000400a58 in VA3::~VA3() at virtual.cc:5
> (gdb) r
> Starting program: /home/pedro/tmp/virtual 
> 
> Breakpoint 2, VA3::~VA3 (this=0x602128 <va2_3+8>, __vtt_parm=0x400de8 <VTT for VA2_3+24>, __in_chrg=<optimized out>) at virtual.cc:5
> 5       struct VA3 : public virtual VA { virtual ~VA3() {} };
> (gdb) c
> Continuing.
> 
> Breakpoint 2, VA3::~VA3 (this=0x602118 <va3>, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at virtual.cc:5
> 5       struct VA3 : public virtual VA { virtual ~VA3() {} };
> (gdb) c
> Continuing.
> [Inferior 1 (process 30836) exited normally]
> 
> But that's more of a run-time engineer thing.  And such users can
> always use the mangled names directly, for example:
> 
>  (gdb) ptype _ZN1AD0Ev
>  type = void (A * const)
> 
> A regular user wouldn't ever want to see these artificial things,
> I suppose.

Yeah, I figure the way forward would really be to offer all-or-nothing.
Hide all artificial members or hide none. We now do a mish-mash of both,
confusing nearly everybody. /me notes future cleanup/feature

> Maybe it'd be preferable to print the type of non-static methods
> In a more C++-ish way, even, like, given:
> 
>  struct A { void foo(); };
> 
> instead of the current:
> 
>  (gdb) ptype A::foo
>  type = void (A * const)
> 
> print:
> 
>  (gdb) ptype A::foo
>  type = void (A::)();

Ooohh... That would be nice...

>> Did any of that actually answer your question?
> 
> It sure helped, but I for me it was important to understand
> why _didn't_ stabs get broken.

Sorry about that. I should have asked for further clarification.

> This new version is OK.

Thank you, committed.

Keith