This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On 03/10/2017 06:33 PM, Keith Seitz wrote:

>> 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. 

Or mangle the lookup name and compare that.  But it wouldn't work
for my WIP linespec/completion branch, so I'm not proposing that.  :-)

> 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.

Yeah, understood, thanks.  Ada still does something like that, by
using "encoded names" as symbol search names.

Regardless, I think a global demangled<->mangled map/hash
to avoid doing the work twice would help.  I've been pondering that
on and off.  I think there's a PR open about how we end up demangling
the same symbols more than once, due to minsyms vs symbols.
 
> 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.

Understood, thanks.

> Do maintainers want to reassess this?

No, no, no.  I was honestly confused by this, not calling for
a redesign.  I think the main problem is one of nomenclature
(what exactly is a physical name), of old stale comments and
old variable names.  E.g., comments in gdbtypes.h about physname
things only talk about mangled names.

> 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

Yeah.  We could have a "show me artificial things" / "give me the ABI view"
switches or format parameter to print/ptype, or some such.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]