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

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

[anonyme_uprh at hotmail dot com]

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

           Summary: Typedefs are not expanded to their base types in
                    breakpoint definitions
           Product: gdb
           Version: 7.2
            Status: NEW
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned@sourceware.org
        ReportedBy: anonyme_uprh@hotmail.com


Hello everyone.


I seem to have found a bug / feature in GDB 7.2 for C++. The problem is that 
typedefs are not converted to their base type when one tries to set a 
breakpoint into a function that has a typedef'd type as parameter.

Here's a simple program that triggers this bug:

main.cpp
- - - - - - - - - - - - - - - - - - - - - - - - -
#include <string>

typedef std::string foo;

void calltest(foo val) {}

int main() {
    calltest(foo(""));
}
- - - - - - - - - - - - - - - - - - - - - - - - -
Compiled with: "g++ -O0 -g main.cpp -o a.out"

Now, when you start the program with gdb 7.2, you'll get the following 
whatis replies:

- - - - - - - - - - - - - - - - - - - - - - - - -
(gdb) whatis foo
type = std::string
(gdb) whatis calltest
type = void (foo)
- - - - - - - - - - - - - - - - - - - - - - - - -

But now, try to set a breakpoint. Once with "foo" and once with 
"std::string"; which should be equal, as whatis has just told us.

- - - - - - - - - - - - - - - - - - - - - - - - -
(gdb) break calltest(foo)
Breakpoint 1 at 0x80485e7: file main.cpp, line 5.

(gdb) break calltest(std::string)
   Can't find member of namespace, class, struct, or union
   named "calltest(std::string)"
   Hint: try 'calltest(std::string)<TAB> or
   'calltest(std::string)<ESC-?>
   (Note leading single quote.)
Make breakpoint pending on future shared library load? (y or [n]) n
- - - - - - - - - - - - - - - - - - - - - - - - -

So, you might try to see the expansion. This is what GDB returns on Tab:

- - - - - - - - - - - - - - - - - - - - - - - - -
(gdb) break calltest<TAB>
[...]
calltest(foo)
calltest(std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >)
[...]
- - - - - - - - - - - - - - - - - - - - - - - - -

So, among the massive amounts of text, we find both foo, and the full 
"std::string" typedef-expansion. Okay, so we try to set the breakpoint 
accordingly:

- - - - - - - - - - - - - - - - - - - - - - - - -
(gdb) whatis calltest(std::string)
type = void (foo)

(gdb) whatis calltest(std::basic_string<char,
        std::char_traits<char>, std::allocator<char> >)
type = void (foo)

(gdb) break calltest(std::basic_string<char,
        std::char_traits<char>, std::allocator<char> >)
Can't find member of namespace, class, struct, or union named
[...]
Make breakpoint pending on future shared library load? (y or [n]) n
- - - - - - - - - - - - - - - - - - - - - - - - -

So ... what this tells me is that "whatis" reads the symbol table correctly, 
but "break" somehow doesn't.


But wait, it gets even better. Now quit GDB and restart it. This is what you 
get when you issue the "break" as the very first command:

- - - - - - - - - - - - - - - - - - - - - - - - -
(gdb) break calltest(foo)
Function "calltest(foo)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n

(gdb) whatis foo
type = std::string

(gdb) break calltest(foo)
Breakpoint 1 at 0x80485e7: file main.cpp, line 5.
- - - - - - - - - - - - - - - - - - - - - - - - -

Interesting, isn't it? Do note that you can substitute the "whatis" with a 
range of commands; for example "break main", or "list" and the second call 
will still work. But not all commands, observe:

- - - - - - - - - - - - - - - - - - - - - - - - -
(gdb) break calltest(foo)
Function "calltest(foo)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n

(gdb) break calltest(foo)
Function "calltest(foo)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n

- - - - - - - - - - - - - - - - - - - - - - - - -

Furthermore, starting with a fresh GDB will also change what the 
tab-expansion shows. Instead of lots and lots of types, it only shows the 
two "calltest" function entries; but at the same time, it shows
"std::string" instead of the full typedef-expansion for std::string in the
second entry.


Anyway, here's the platform and program versions I used for testing:

OS: Ubuntu 10.10
gdb: 7.2-ubuntu
g++: (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5


I've tested the same program with an older, self-compiled GDB 7.1, and there 
I get this:

- - - - - - - - - - - - - - - - - - - - - - - - -
(gdb) break calltest(foo)
Function "calltest(foo)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n

(gdb) whatis foo
type = std::string

(gdb) break calltest(foo)
Function "calltest(foo)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n

(gdb) break calltest(std::string)
Breakpoint 1 at 0x8048627: file main.cpp, line 5.

- - - - - - - - - - - - - - - - - - - - - - - - -



Basically, I have no clue what could trigger this strange behaviour. It 
almost seems to me as if GDB 7.2 added support for typedef'd variables, but 
broke the "break" statement in a way that causes it to not read the 
symbol-table correctly anymore, but I could be a mile off with that 
suspicion.


Any help would be appreciated, thanks,
    Martin Schröder.

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

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

[keiths at redhat dot com]

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

Keith Seitz <keiths at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |11734
         AssignedTo|unassigned at sourceware    |keiths at redhat dot com
                   |dot org                     |

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

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

[anonyme_uprh at hotmail dot com]

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

Martin Schröder <anonyme_uprh at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anonyme_uprh at hotmail dot
                   |                            |com

--- Comment #1 from Martin Schröder <anonyme_uprh at hotmail dot com> 2011-01-31 13:09:49 UTC ---
Hello everyone.


I just wanted to ask whether there was any progress on fixing this bug? I also
watched Bug #11734 which this bug was marked as being dependent on, but it
doesn't seem to be solved either.

Thanks,
    Martin.

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

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

[keiths at redhat dot com]

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

Keith Seitz <keiths at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #2 from Keith Seitz <keiths at redhat dot com> 2011-02-17 21:08:46 UTC ---
Another patchset has been put up for review. Actually, I'm not entirely certain
this isn't just a duplicate of 11734 again, since in my current working tree,
this appears to now work (with the 11734 & 12273 patchset included):

gdb -nx -q ~/tmp/12266
Reading symbols from /home/keiths/tmp/12266...done.
(gdb) b calltest(foo)
Breakpoint 1 at 0x40075c: file main.cpp, line 6.

If you are desperate, I would grab the patch that I posted this morning. But be
advised this has not yet been accepted to mainline. [Although I don't think
that having this patchset in your tree will adversely affect anything. It just
might change a little before it is finally committed.]

http://sourceware.org/ml/gdb-patches/2011-02/msg00428.html

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

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

[anonyme_uprh at hotmail dot com]

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

--- Comment #3 from Martin Schröder <anonyme_uprh at hotmail dot com> 2011-02-18 10:25:44 UTC ---
Created attachment 5251
  --> http://sourceware.org/bugzilla/attachment.cgi?id=5251
Patchset from gdb-7.2.50.20110218.tar.bz2

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

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

[anonyme_uprh at hotmail dot com]

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

--- Comment #4 from Martin Schröder <anonyme_uprh at hotmail dot com> 2011-02-18 10:26:53 UTC ---
Hello Keith,


I've just tried the patchset you've linked to. I've applied it against the
snapshot gdb-7.2.50.20110218.

Unfortunately, it still doesn't work right. I start the debugger for my test
case and issue the following commands:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
(gdb) break calltest(foo)
Function "calltest(foo)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n

(gdb) break calltest(std::string)
Function "calltest(std::string)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n

(gdb) break calltest(string)
Function "calltest(string)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 


Then, I try to register the breakpoint with the fully expanded typedef:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
(gdb) break calltest(std::basic_string<char, std::char_traits<char>,
std::allocator<char> >)
Breakpoint 1 at 0x4013c3: file typedef.c, line 5.
(gdb) inf br
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x004013c3 in calltest(foo) at typedef.c:5
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 


As you can see, using the exanded type works. Afterwards, I tried the above
three commands again:


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
(gdb) break calltest(foo)
Note: breakpoint 1 also set at pc 0x4013c3.
Breakpoint 2 at 0x4013c3: file typedef.c, line 5.

(gdb) break calltest(std::string)
Function "calltest(std::string)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n

(gdb) break calltest(string)
Function "calltest(string)" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n

(gdb) inf br
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x004013c3 in calltest(foo) at typedef.c:5
2       breakpoint     keep y   0x004013c3 in calltest(foo) at typedef.c:5
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

As you can see, now the root of the typedef-chain (foo) works, but not its
first expansion to std::string.


So, the bug still exists. Before you register any breakpoints, execute any
actions or start the program, only the leaf of the typedef-chain (the full type
expansion) works.

After an action, the root and leaf work, but none of the intermediate stages
do.


So, I guess that even though 11734 & 12273 might be fixed, my error seems to
persist.



Of course, I might have misapplied your diff, so just to be on the safe side,
I've added a diff from the gdb-7.2.50.20110218 snapshot to your patchset.

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

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

[keiths at redhat dot com]

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

--- Comment #5 from Keith Seitz <keiths at redhat dot com> 2011-03-17 18:07:41 UTC ---
Since I have committed the patchset for 11734 and 12273, I am now revisiting
this bug...

There /appear/ to be multiple problems with symbol lookup that cause this
failure.  I have further reduced the test case to:

#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;
}


Breaking on "test(my_other_type)" works, but breaking on either "test(my_type)"
or "test(const char* const*)" does not.  This partly occurs because
dwarf2_physname calls c_type_print_args, and that function does not do any
typedef resolution (which it should when it is used to compute physnames). 
Unfortunately, fixing that still doesn't work right, either.

But I just wanted to update this bug to let anyone watching it know that I am
taking a look at it.

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

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

[anonyme_uprh at hotmail dot com]

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

--- Comment #6 from Martin Schröder <anonyme_uprh at hotmail dot com> 2011-03-23 17:33:15 UTC ---
Thanks for the update Keith. I greatly appreciate your work on this bug.

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

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

[keiths at redhat dot com]

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

Bug 12266 depends on bug 11734, which changed state.

Bug 11734 Summary: break c::bar() broken, can't find bar
http://sourceware.org/bugzilla/show_bug.cgi?id=11734

           What    |Old Value                   |New Value
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

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

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

[keiths at redhat dot com]

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

--- Comment #7 from Keith Seitz <keiths at redhat dot com> 2011-08-01 20:21:38 UTC ---
I've submitted patch #4 on this... I have high(er?) expectations for this one.

See http://sourceware.org/ml/gdb-patches/2011-07/msg00795.html

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

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

[anonyme_uprh at hotmail dot com]

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

--- Comment #8 from Martin Schröder <anonyme_uprh at hotmail dot com> 2011-08-02 17:17:18 UTC ---
(In reply to comment #7)
> I've submitted patch #4 on this... I have high(er?) expectations for this one.
> 
> See http://sourceware.org/ml/gdb-patches/2011-07/msg00795.html

Thanks Keith.

I'll take a look at it and check if fixes the issues reported by me.

Although I must admit that your comment of "A reminder about this
bug/enhancement request: linespecs can't deal with typedefs." does seem to
indicate that I should probably not expect a full fix. :p

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

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

[keiths at redhat dot com]

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

--- Comment #9 from Keith Seitz <keiths at redhat dot com> 2011-08-02 17:23:35 UTC ---
On 08/02/2011 10:17 AM, anonyme_uprh at hotmail dot com wrote:
> I'll take a look at it and check if fixes the issues reported by me.

I'd appreciate it... It doesn't hurt to have outside independent 
verification. Be forewarned, this patch is changing slightly.

> Although I must admit that your comment of "A reminder about this
> bug/enhancement request: linespecs can't deal with typedefs." does seem to
> indicate that I should probably not expect a full fix. :p

Actually, you should expect a full fix. That is exactly what I've been 
working on these (far too) many weeks.

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.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> 2011-08-18 16:17:46 UTC ---
CVSROOT:    /cvs/src
Module name:    src
Changes by:    kseitz@sourceware.org    2011-08-18 16:17:39

Modified files:
    gdb            : ChangeLog cp-name-parser.y cp-support.c 
                     cp-support.h linespec.c 
    gdb/python     : py-type.c 

Log message:
    PR c++/12266
    * cp-name-parser.y (struct demangle_info): Remove unused
    member PREV.
    (d_grab): Likewise.
    (allocate_info): Change return type to struct demangle_info *.
    Always allocate a new demangle_info.
    Remove unused PREV pointer.
    (cp_new_demangle_parse_info): New function.
    (cp_demangled_name_parse_free): New function.
    (do_demangled_name_parse_free_cleanup): New function.
    (make_cleanup_cp_demangled_name_parse_free): New function.
    (cp_demangled_name_to_comp): Change return type to
    struct demangle_parse_info *.
    Allocate a new storage for each call.
    (main): Update usage for cp_demangled_name_to_comp
    API change.
    * cp-support.h (struct demangle_parse_info): New structure.
    (cp_demangled_name_to_comp): Update API change for
    return type.
    (cp_new_demangle_parse_info): Declare.
    (make_cleanup_cp_demangled_name_parse_free): New declaration.
    (cp_demangled_name_parse_free): Declare.
    * cp-support.c (cp_canonicalize_string): Update API
    change for cp_demangled_name_to_comp.
    (mangled_name_to_comp): Likewise.
    Return struct demangle_parse_info, too.
    (cp_class_name_from_physname): Update mangled_name_to_comp
    API change.
    (method_name_from_physname): Likewise.
    (cp_func_name): Update API change for cp_demangled_name_to_comp.
    (cp_remove_params): Likewise.
    * python/py-type.c (typy_legacy_template_argument): Likewise.

    * cp-support.h (cp_canonicalize_string_no_typedefs): Declare.
    (cp_merge_demangle_parse_infos): Declare.
    * cp-support.c (ignore_typedefs): New file global.
    (copy_string_to_obstack): New function.
    (inspect_type): New function.
    (replace_typedefs): New function.
    (replace_typedefs_qualified_name): New function.
    (cp_canonicalize_string_no_typedefs): New function.
    * cp-name-parser.y (cp_merge_demangle_parse_infos): New function.
    (cp_new_demangle__parse_info): Allocate and initialize the obstack.
    * linespec.c (find_methods): Use cp_canonicalize_string_no_typedefs
    instead of cp_canonicalize_string.
    (find_method): Likewise.
    (decode_compound): Before looking up the name, call
    cp_canonicalize_string_no_typedefs.
    (decode_variable): Likewise.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.13272&r2=1.13273
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/cp-name-parser.y.diff?cvsroot=src&r1=1.21&r2=1.22
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/cp-support.c.diff?cvsroot=src&r1=1.49&r2=1.50
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/cp-support.h.diff?cvsroot=src&r1=1.44&r2=1.45
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/linespec.c.diff?cvsroot=src&r1=1.128&r2=1.129
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/python/py-type.c.diff?cvsroot=src&r1=1.19&r2=1.20

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

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

[anonyme_uprh at hotmail dot com]

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

--- Comment #11 from Martin Schröder <anonyme_uprh at hotmail dot com> 2011-08-18 21:44:40 UTC ---
Hello Keith!

I've finally found the time to examine this bug again, and I can report that,
indeed, some things work better, but not across the board.

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.

Unfortunately, the compilation failed. After that, I checked out the CVS head
(because I interpret your recent posting to mean that you merged your changes
into the mainline). Anyway, that version compiled and I started to test it.

First, I selected my own initial test code:
==========================================================
#include <string>

typedef std::string foo;

void calltest(foo val) {}

int main() {
    calltest(foo(""));
}
==========================================================

The good news is that "whatis" still correctly reports both "foo" and
"std::string". It tells us that foo maps to string and string to basic_string.

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.


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.




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.

With the CVS HEAD, the situation looks even worse. Only "break test" works; but
nothing else. Of course, both "whatis" and "ptype" still report things
correctly, according to their differing type-depth expansion styles:

============================================================
(gdb) whatis test
type = void (my_other_type)

(gdb) whatis my_other_type
type = my_type

(gdb) whatis my_type
type = const char * const *

(gdb) ptype test
type = void (my_other_type)

(gdb) ptype my_type
type = const char * const *

(gdb) ptype my_other_type
type = const char * const *
============================================================




So, as long as I am correct in presuming that the CVS Head contains your
changes, I can only say that some things are improved, but some things still
don't work right.

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.




Thanks again for your continued work and patience with this nasty bug,
    Martin.

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

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

[keiths at redhat dot com]

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.