[RFC] 12266 Fallout

[Keith Seitz <keiths at redhat dot com>]

Hi,

I am writing for some maintainer guidance on an issue that has arisen.

The original reporter for c++/12266 reports that the bug is not fixed. 
And indeed, it isn't!

The reporter's test case (C++):

typedef std::string foo;
void calltest (foo) {}

Setting a break at "calltest(foo)" does not work because inspect_type 
(part of 12266 patchset) uses check_typedef, which resolves foo -> 
std::string -> std::basic_string<char, std::char_traits<char>, 
std::alloactor<char> >. But because we are no longer using DMGL_VERBOSE 
in dwarf2_physname (and other places) to do demangling, the symbol table 
actually stores "calltest(std::string)".

Setting a break at "calltest(std::string)" works.

Setting a break at "calltest(std::basic_string<char, ...>)" also does 
not work for the same reason "foo" didn't work.

There are two ways I can see to fix this.
1) Add DMGL_VERBOSE where it is needed so that NO typedefs ever appear 
in a (non-TYPE_CODE_TYPEDEF) symbol's name, i.e, store 
"calltest(std::basic_string<...>)" in the symbol table instead of 
"calltest(std::string)".

2) Add a new version of check_typedef which "stops" at std::string (and 
std::ostream, std::istream, std::iostream), and add logic (somewhere) to 
deal with going from "std::basic_string<...>" back to "std::string" (and 
likewise for the others).

For whatever it may be worth, my preference is for #1. I've always felt 
storing the most fundamental representation of a symbol was the best 
option: it treats all symbols the same.

Along these lines, I have done a quick audit of the code (look for 
DMGL_PARAMS), and the only places where DMGL_VERBOSE needs to be added 
is dwarf2_physname, lookup_symbol_in_language, and 
symbol_find_demangled_name. All other users of DMGL_PARAMS are using it 
for output to the display, and leaving out DMGL_VERBOSE would be preferred.

This will have the immediate side effect of printing symbol names with 
"std::basic_string<...>" instead of the more preferred "std::string".
Actually in this case, the "right" output would be "calltest(foo)", but 
that is a different, but related, problem, for which I developed a patch 
a long time ago, part of the first 12266 patch submissions 
(dwarf2_print_name).

So, I humbly ask maintainers:

- Shall I continue #1 and start submitting patches?
- Shall I start teaching gdb about std::string et al and how to deal 
with them in the environment we have today?
- Have I missed something that would be preferable to anything I've 
mentioned?

Keith