[Bug c++/12266] Typedefs are not expanded to their base types in breakpoint definitions

["keiths at redhat dot com" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=12266

--- Comment #12 from Keith Seitz <keiths at redhat dot com> 2011-08-18 22:19:05 UTC ---
Hey, thanks for the note!

On 08/18/2011 02:44 PM, anonyme_uprh at hotmail dot com wrote:

> At first I tried to apply the patches that were linked to in
> http://sourceware.org/ml/gdb-patches/2011-07/msg00795.html to the GDB-7.3 base
> archive. The patches succeeded with minor offsets.

Yeah, that's probably not going to work anymore, but you are correct: I 
did just commit all this.

> Then I tried to execute "break calltest(foo)", "break calltest(std::string)"
> and "break calltest(basic_string...). In GDB 7.1 and earlier all three worked.
> In GDB 7.2/7.3 the break on std::string failed, but the break on foo worked
> after an initial "whatis" query. Without this initial query, only the full
> expansion worked.

Yuck. This is because of a recent change to the symbol reader committed 
by a maintainer. Instead of constructing physnames (which are stored in 
the symbol table), we now "simply" use the demangler to demangle 
DW_AT_MIPS_linkage_name. Unfortunately, maintainers turned off 
"DMGL_VERBOSE", which would turn std::string into std::basic_string<...>.

As a result, my patch ends up looking for 
"calltest(std::basic_string<...>)" and this demangler has returned 
"calltest(std::string)". Not nice, but that's what the maintainers 
chose. So I apparently have to hack around this problem another time.

> The good news is that with your changes, the break on "calltest(std::string)"
> works right out of the box. But unfortunately, now the breaks on
> "calltest(foo)" AND "calltest(basic_string)" don't not work at all -- even
> after a whatis query.

The call to basic_string will not work at all (without the 
aforementioned DMGL_VERBOSE), as I mentioned above. Again, that was a 
decision by maintainers and out of my control.

I'll find some way to work around this mess, though. Don't worry!

> After that, I tried your plain-C test case of:
>
> ===========================================================
> #include<stdlib.h>
>
> typedef const char* const* my_type;
> typedef my_type my_other_type;
>
> void
> test (my_other_type foo) { }
>
> int
> main (void)
> {
>    test (NULL);
>    return 0;
> }
> ============================================================
>
> Here, GDB 7.1 worked with everything whereas GDB 7.2/7.3 only worked halfway
> after whatis coercion.

This is a real mess, since for C source code, DW_AT_MIPS_linkage_name is 
never defined (by the compiler). Additionally, another recent maintainer 
change double-checked that if you did specify overload information 
(regardless of language), it must match EXACTLY. Earlier gdb's never did 
this (if there was a single match, regardless of overload information, 
it would return that match).


> Ideally, the user should be able to use all types interchangeably, because as
> you can see with whatis and ptype, GDB occassionally reports the expanded
> types, instead of the typedefs that were actually used in the code.

Yes, indeed. I will see what I can do.

I'm really sorry about all the delays.

Keith

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.