Re: c++/1023: setting a breakpoint on C++ member functions

[David Carlton <carlton at math dot stanford dot edu>]

The following reply was made to PR c++/1023; it has been noted by GNATS.

From: David Carlton <carlton at math dot stanford dot edu>
To: GNATS Filer <gdb-gnats at sources dot redhat dot com>
Cc: zeitler at lucent dot com, Michael Elizabeth Chastain <mec at shout dot net>,
   Daniel Jacobowitz <drow at mvista dot com>
Subject: Re: c++/1023: setting a breakpoint on C++ member functions
Date: 28 Feb 2003 16:27:50 -0800

 I've had a look at this; I'm not at all familiar with stabs (or with
 stabsread.c), but here's what I've found so far.
 
 The stabs for the class declaration says:
 
 .stabs "myClass:T(0,25)=s1operator=::(0,26)=##(0,27)=&(0,25);:__as__7myClassRC7myClass;2A.;myClass::(0,28)=##(0,29)=*(0,25);:RC7myClass;2A.(0,30)=##(0,29);:;2A.(0,31)=#(0,25),(0,21),(0,29),(0,1),(0,21);:_._7myClass;2A.;performUnblocking::(0,32)=##(0,21);:s;2A.;performBlocking::(0,31):i;2A.;;",128,0,0,0
 
 Notice that neither performUnblocking or performBlocking contains a
 mangled name.  But the type for performUnblocking is listed as
 
   (0,32)=##(0,21)
 
 while the type for performBlocking is listed as
 
   (0,31)
 
 In other words, reading the stabs manual, performUnblocking has a type
 that we haven't seen before, while performBlocking has the same type
 as an earlier method.
 
 Now: enter stabsread.c:read_member_functions.  It grabs the type of
 the method in this line:
 
 	      new_sublist->fn_field.type = read_type (pp, objfile);
 
 For performUnblocking, it has to create a new type; for
 performBlocking, it can reuse a type from an earlier method.
 
 But then we get to this part of read_member_functions:
 
 	  if (TYPE_STUB (new_sublist->fn_field.type))
 	    {
 	      if (!TYPE_DOMAIN_TYPE (new_sublist->fn_field.type))
 		TYPE_DOMAIN_TYPE (new_sublist->fn_field.type) = type;
 	      new_sublist->fn_field.is_stub = 1;
 	    }
 	  new_sublist->fn_field.physname = savestring (*pp, p - *pp);
 
 The if clause looks at the type it's just found to see if the current
 method is a stub.  Then, either way, the physname is grabbed from the
 stabs, but code elsewhere in GDB only pays attention to that if we
 think the current method isn't a stub.
 
 The problem is that, while performBlocking is a stub, the earlier
 method that it shared the type with _wasn't_ a stub.  So
 performBlocking is erroneously treated as a non-stub, so the physname
 that is found is treated as the actual mangled name.  Which makes GDB
 think that the mangled name is "i", which is, of course, incorrect.
 
 I'll see if I can come up with a patch (maybe it's correct to set
 new_sublist->fn_field.is_stub based on whether or not an attempt to
 demangle the name works...), but I'm really fumbling around in the
 dark; if this prompts anybody more knowledgeable to find a solution,
 that would doubtless be a much better outcome.