[rfa/c++] cp_lookup_rtti_type, take 2

[rfa/c++] cp_lookup_rtti_type, take 2

[Michael Elizabeth Chastain]

Here is version #2 of cp_lookup_rtti_type.

Changes since version #1:

  . changed name from lookup_rtti_type to cp_lookup_rtti_type.
  . cp_lookup_rtti_type lives in cp-support.h/cp-support.c
      instead of symtab.h/gdbtypes.c.
  . tweaked one of the warning messages
    . old: "RTTI symbol for class '%s' is not a typedef"
    . new: "RTTI symbol for class '%s' is not a type"

It's still the same basic plan where cp_lookup_rtti_type is a chunk
of code that used to be in gnuv3_rtti_type, with more sanity checking,
and now gnuv2_rtti_type uses it too, so now gnuv2_rtti_type works.

And it still needs this follow-up work:

. The calls to lookup_rtti_type need a proper "block" parameter.
  The old code needed this too; I haven't regressed anything.
  I put FIXME notes in for this.

. hpacc_value_rtti_type has the same buggy code.  I can't change the
  code because I can't test it, but I can put in a big FIXME into it.
  (I wonder if anyone still uses HP aCC with gdb).

. Nested types give a warning and don't work.
  It would be nice to make them work.

. Types with virtual bases appear to work with v3, but give a warning
  and don't work with v2.  "don't work" probably means that they fall back
  to the static type rather than the dynamic type, which probably
  usually works.  Again, this is also a property of the current code.

. rtti.exp needs to recognize a modified message (see below).

The PR's are:

  http://sources.redhat.com/gdb/bugs/1465
  http://sources.redhat.com/gdb/bugs/1377

These bugs are regressions versus gdb 6.0 so they are high priority.

Testing: I tested with gcc v2 and v3, dwarf-2 and stabs+.   
Nothing got worse.  gdb.cp/class2.exp has a specific test for this,
which now passes.  Some tests in gdb.cp/rtti.exp changed their
kfail number so rtti.exp will need an upgrade.

Some tests in virtfunc.exp that broke after the 2003-09-11 namespace
commit started working again:

  http://sources.redhat.com/gdb/bugs/1377
  [regression] g++ 2.95.3, dwarf-2, hand function call: SIGSEGV</tt>

Since I'm not in symtab.h/gdbtypes.c any more, I don't think I need
approval from a symtab maintainer, just a C++ maintainer.  Lart me if
I'm wrong.

Okay to commit?

Michael C

2003-12-01  Michael Chastain  <mec.gnu@mindspring.com>

	Partial fix for PR c++/1465.
	Fix for PR c++/1377.
	* cp-support.h (cp_lookup_rtti_type): New function.
	* cp-support.c (cp_lookup_rtti_type): New function.
	* gnu-v2-abi.c: Update copyright years.
	(gnuv2_rtti_type): Call cp_lookup_rtti_type.
	* gnu-v3-abi.c: Update copyright years.
	(gnuv3_rtti_type): Call cp_lookup_rtti_type.

Index: cp-support.h
===================================================================
RCS file: /cvs/src/src/gdb/cp-support.h,v
retrieving revision 1.9
diff -c -3 -p -r1.9 cp-support.h
*** cp-support.h	25 Sep 2003 16:39:38 -0000	1.9
--- cp-support.h	1 Dec 2003 20:03:35 -0000
*************** struct symbol;
*** 34,39 ****
--- 34,40 ----
  struct obstack;
  struct block;
  struct objfile;
+ struct type;
  
  /* This struct is designed to store data from using directives.  It
     says that names from namespace INNER should be visible within
*************** extern unsigned int cp_find_first_compon
*** 60,65 ****
--- 61,69 ----
  extern unsigned int cp_entire_prefix_len (const char *name);
  
  extern struct symbol **make_symbol_overload_list (struct symbol *);
+ 
+ extern struct type *cp_lookup_rtti_type (const char *name,
+ 					 struct block *block);
  
  /* Functions/variables from cp-namespace.c.  */
  
Index: cp-support.c
===================================================================
RCS file: /cvs/src/src/gdb/cp-support.c,v
retrieving revision 1.9
diff -c -3 -p -r1.9 cp-support.c
*** cp-support.c	14 Sep 2003 16:32:12 -0000	1.9
--- cp-support.c	1 Dec 2003 20:03:36 -0000
***************
*** 33,38 ****
--- 33,39 ----
  #include "symtab.h"
  #include "block.h"
  #include "complaints.h"
+ #include "gdbtypes.h"
  
  /* Functions related to demangled name parsing.  */
  
*************** make_symbol_overload_list (struct symbol
*** 582,587 ****
--- 583,630 ----
    return (sym_return_val);
  }
  
+ /* Lookup the rtti type for a class name. */
+ 
+ struct type *
+ cp_lookup_rtti_type (const char *name, struct block *block)
+ {
+   struct symbol * rtti_sym;
+   struct type * rtti_type;
+ 
+   rtti_sym = lookup_symbol (name, block, STRUCT_DOMAIN, NULL, NULL);
+ 
+   if (rtti_sym == NULL)
+     {
+       warning ("RTTI symbol not found for class '%s'", name);
+       return NULL;
+     }
+ 
+   if (SYMBOL_CLASS (rtti_sym) != LOC_TYPEDEF)
+     {
+       warning ("RTTI symbol for class '%s' is not a type", name);
+       return NULL;
+     }
+ 
+   rtti_type = SYMBOL_TYPE (rtti_sym);
+ 
+   switch (TYPE_CODE (rtti_type))
+     {
+     case TYPE_CODE_CLASS:
+       break;
+     case TYPE_CODE_NAMESPACE:
+       /* chastain/2003-11-26: the symbol tables often contain fake
+ 	 symbols for namespaces with the same name as the struct.
+ 	 This warning is an indication of a bug in the lookup order
+ 	 or a bug in the way that the symbol tables are populated.  */
+       warning ("RTTI symbol for class '%s' is a namespace", name);
+       return NULL;
+     default:
+       warning ("RTTI symbol for class '%s' has bad type", name);
+       return NULL;
+     }
+ 
+   return rtti_type;
+ }
  
  /* Don't allow just "maintenance cplus".  */
  
Index: gnu-v2-abi.c
===================================================================
RCS file: /cvs/src/src/gdb/gnu-v2-abi.c,v
retrieving revision 1.13
diff -c -3 -p -r1.13 gnu-v2-abi.c
*** gnu-v2-abi.c	16 Sep 2003 18:56:35 -0000	1.13
--- gnu-v2-abi.c	1 Dec 2003 20:03:37 -0000
***************
*** 1,6 ****
  /* Abstraction of GNU v2 abi.
  
!    Copyright 2001, 2003 Free Software Foundation, Inc.
  
     Contributed by Daniel Berlin <dberlin@redhat.com>
  
--- 1,6 ----
  /* Abstraction of GNU v2 abi.
  
!    Copyright 2001, 2002, 2003 Free Software Foundation, Inc.
  
     Contributed by Daniel Berlin <dberlin@redhat.com>
  
***************
*** 30,35 ****
--- 30,36 ----
  #include "value.h"
  #include "demangle.h"
  #include "cp-abi.h"
+ #include "cp-support.h"
  
  #include <ctype.h>
  
*************** gnuv2_value_rtti_type (struct value *v, 
*** 259,267 ****
    *(strchr(demangled_name,' '))=0;
  
    /* Lookup the type for the name */
!   rtti_type=lookup_typename(demangled_name, (struct block *)0,1);
! 
!   if (rtti_type==NULL)
      return NULL;
  
    if (TYPE_N_BASECLASSES(rtti_type) > 1 &&  full && (*full) != 1)
--- 260,268 ----
    *(strchr(demangled_name,' '))=0;
  
    /* Lookup the type for the name */
!   /* FIXME: chastain/2003-11-26: block=NULL is bogus.  See pr gdb/1465. */
!   rtti_type = cp_lookup_rtti_type (demangled_name, NULL);
!   if (rtti_type == NULL)
      return NULL;
  
    if (TYPE_N_BASECLASSES(rtti_type) > 1 &&  full && (*full) != 1)
Index: gnu-v3-abi.c
===================================================================
RCS file: /cvs/src/src/gdb/gnu-v3-abi.c,v
retrieving revision 1.19
diff -c -3 -p -r1.19 gnu-v3-abi.c
*** gnu-v3-abi.c	22 Aug 2003 20:45:55 -0000	1.19
--- gnu-v3-abi.c	1 Dec 2003 20:03:37 -0000
***************
*** 1,7 ****
  /* Abstraction of GNU v3 abi.
     Contributed by Jim Blandy <jimb@redhat.com>
  
!    Copyright 2001, 2002 Free Software Foundation, Inc.
  
     This file is part of GDB.
  
--- 1,7 ----
  /* Abstraction of GNU v3 abi.
     Contributed by Jim Blandy <jimb@redhat.com>
  
!    Copyright 2001, 2002, 2003 Free Software Foundation, Inc.
  
     This file is part of GDB.
  
***************
*** 23,28 ****
--- 23,29 ----
  #include "defs.h"
  #include "value.h"
  #include "cp-abi.h"
+ #include "cp-support.h"
  #include "demangle.h"
  #include "gdb_assert.h"
  #include "gdb_string.h"
*************** gnuv3_rtti_type (struct value *value,
*** 196,202 ****
    struct minimal_symbol *vtable_symbol;
    const char *vtable_symbol_name;
    const char *class_name;
-   struct symbol *class_symbol;
    struct type *run_time_type;
    struct type *base_type;
    LONGEST offset_to_top;
--- 197,202 ----
*************** gnuv3_rtti_type (struct value *value,
*** 255,280 ****
    class_name = vtable_symbol_name + 11;
  
    /* Try to look up the class name as a type name.  */
!   class_symbol = lookup_symbol (class_name, 0, STRUCT_DOMAIN, 0, 0);
!   if (! class_symbol)
!     {
!       warning ("can't find class named `%s', as given by C++ RTTI", class_name);
!       return NULL;
!     }
! 
!   /* Make sure the type symbol is sane.  (An earlier version of this
!      code would find constructor functions, who have the same name as
!      the class.)  */
!   if (SYMBOL_CLASS (class_symbol) != LOC_TYPEDEF
!       || TYPE_CODE (SYMBOL_TYPE (class_symbol)) != TYPE_CODE_CLASS)
!     {
!       warning ("C++ RTTI gives a class name of `%s', but that isn't a type name",
! 	       class_name);
!       return NULL;
!     }
! 
!   /* This is the object's run-time type!  */
!   run_time_type = SYMBOL_TYPE (class_symbol);
  
    /* Get the offset from VALUE to the top of the complete object.
       NOTE: this is the reverse of the meaning of *TOP_P.  */
--- 255,264 ----
    class_name = vtable_symbol_name + 11;
  
    /* Try to look up the class name as a type name.  */
!   /* FIXME: chastain/2003-11-26: block=NULL is bogus.  See pr gdb/1465. */
!   run_time_type = cp_lookup_rtti_type (class_name, NULL);
!   if (run_time_type == NULL)
!     return NULL;
  
    /* Get the offset from VALUE to the top of the complete object.
       NOTE: this is the reverse of the meaning of *TOP_P.  */

Re: [rfa/c++] cp_lookup_rtti_type, take 2

[Daniel Jacobowitz]

On Mon, Dec 01, 2003 at 04:40:39PM -0500, Michael Chastain wrote:
> Here is version #2 of cp_lookup_rtti_type.

This patch is OK.  I have a couple of comments, but none of them
require changing it.

> And it still needs this follow-up work:
> 
> . The calls to lookup_rtti_type need a proper "block" parameter.
>   The old code needed this too; I haven't regressed anything.
>   I put FIXME notes in for this.

I'm not as sure as you are about this - certainly we do _not_ want a
block that came down the call chain; think about what dynamic type is. 
The only reason we can do it by symbol lookup at all is the One
Definition Rule, and we should probably be restricting ourselves to the
objfile in which we found the minimal symbol.  Searching STRUCT_DOMAIN
works because every class with debug info will be entered in both
STRUCT_DOMAIN and VAR_DOMAIN, and there should only be one entry in
STRUCT_DOMAIN for a non-POD type in a given objfile (or you'll get link
errors from the multiple vtables!  Ignoring anonymous namespaces for
now.)

> . hpacc_value_rtti_type has the same buggy code.  I can't change the
>   code because I can't test it, but I can put in a big FIXME into it.
>   (I wonder if anyone still uses HP aCC with gdb).

I would be dumbfounded if it still worked right.  Note that this is aCC
only, not GCC on HP/UX; and I believe that newer HP/UX compilers will
use the Itanium C++ ABI, which means roughly the same as GNU v3.

Now that we've had another major release of GDB I am extremely tempted
to rip out aCC C++ support.  If you really want to experiment, the HP
TestDrive systems do have aCC installed; www.testdrive.hp.com and
spe191.testdrive.hp.com:telnet.  But they're a real nuisance to run
tests on due to the lack of usable (to me) tools, and the restrictive
firewall.  And if we found problems, there wouldn't be anyone motivated
to fix them.

> . Nested types give a warning and don't work.
>   It would be nice to make them work.

It's a pain.  I spent quite some time trying to sort out the issues. 
I'll give it a shot again after more of David's patches have been
merged.

> 2003-12-01  Michael Chastain  <mec.gnu@mindspring.com>
> 
> 	Partial fix for PR c++/1465.
> 	Fix for PR c++/1377.
> 	* cp-support.h (cp_lookup_rtti_type): New function.
> 	* cp-support.c (cp_lookup_rtti_type): New function.
> 	* gnu-v2-abi.c: Update copyright years.
> 	(gnuv2_rtti_type): Call cp_lookup_rtti_type.
> 	* gnu-v3-abi.c: Update copyright years.
> 	(gnuv3_rtti_type): Call cp_lookup_rtti_type.


> !   /* Make sure the type symbol is sane.  (An earlier version of this
> !      code would find constructor functions, who have the same name as
> !      the class.)  */

The "earlier version" used VAR_DOMAIN, FYI.  It was presumably based on
the code in gnu-v2-abi.c, but because gnu-v2-abi.c didn't show the
problem I encountered at the time I didn't update it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa/c++] cp_lookup_rtti_type, take 2

[David Carlton]

On Thu, 4 Dec 2003 22:29:59 -0500, Daniel Jacobowitz <drow@mvista.com> said:
> On Mon, Dec 01, 2003 at 04:40:39PM -0500, Michael Chastain wrote:

>> . The calls to lookup_rtti_type need a proper "block" parameter.
>> The old code needed this too; I haven't regressed anything.
>> I put FIXME notes in for this.

> I'm not as sure as you are about this - certainly we do _not_ want a
> block that came down the call chain; think about what dynamic type
> is. 

Good point.  Oops.

> Ignoring anonymous namespaces for now.)

Yes...

> Now that we've had another major release of GDB I am extremely
> tempted to rip out aCC C++ support.

You'll get no complaints from me.

>> . Nested types give a warning and don't work.
>> It would be nice to make them work.

> It's a pain.  I spent quite some time trying to sort out the issues.
> I'll give it a shot again after more of David's patches have been
> merged.

I think they should work okay after my patch that is waiting for
approval gets applied?

David Carlton
carlton@kealia.com

Re: [rfa/c++] cp_lookup_rtti_type, take 2

[Daniel Jacobowitz]

On Fri, Dec 05, 2003 at 08:57:56AM -0800, David Carlton wrote:
> On Thu, 4 Dec 2003 22:29:59 -0500, Daniel Jacobowitz <drow@mvista.com> said:
> > On Mon, Dec 01, 2003 at 04:40:39PM -0500, Michael Chastain wrote:
> 
> >> . The calls to lookup_rtti_type need a proper "block" parameter.
> >> The old code needed this too; I haven't regressed anything.
> >> I put FIXME notes in for this.
> 
> > I'm not as sure as you are about this - certainly we do _not_ want a
> > block that came down the call chain; think about what dynamic type
> > is. 
> 
> Good point.  Oops.
> 
> > Ignoring anonymous namespaces for now.)
> 
> Yes...
> 
> > Now that we've had another major release of GDB I am extremely
> > tempted to rip out aCC C++ support.
> 
> You'll get no complaints from me.
> 
> >> . Nested types give a warning and don't work.
> >> It would be nice to make them work.
> 
> > It's a pain.  I spent quite some time trying to sort out the issues.
> > I'll give it a shot again after more of David's patches have been
> > merged.
> 
> I think they should work okay after my patch that is waiting for
> approval gets applied?

Perhaps.  I was working with stabs at the time.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa/c++] cp_lookup_rtti_type, take 2

[Daniel Jacobowitz]

On Fri, Dec 05, 2003 at 09:38:52AM -0800, David Carlton wrote:
> On Fri, 5 Dec 2003 12:16:58 -0500, Daniel Jacobowitz <drow@mvista.com> said:
> 
> > How do you suggest we do it?  Some new addition to the debug info?  I
> > don't believe we have anything at the moment that fills this need.
> 
> Hmm.  I thought I'd seen something appropriate in the debug info, but
> now I realize that I was looking for the slot for the vtable in the
> class, which is a quite different matter.
> 
> Well, here's what I see when looking for a vtable symbol in a sample
> file:
> 
> 	.uleb128 0x1d	# (DIE (0x20d) DW_TAG_variable)
> 	.long	.LC9	# DW_AT_name: "_ZTI1C"
> 	.long	0x21e	# DW_AT_type
> 	.byte	0x1	# DW_AT_external
> 	.byte	0x1	# DW_AT_artificial
> 	.byte	0x5	# DW_AT_location
> 	.byte	0x3	# DW_OP_addr
> 	.long	_ZTI1C
> 
> So DW_TAG_variable + DW_AT_artificial is a start - looking for that
> (plus perhaps guiltily peeking at the demanged name just to make sure
> it starts with 'typeinfo') lets us find the vtable symbols.  But that
> doesn't help - the DW_AT_type doesn't actually lead us to the type
> that it's the vtable for, and certainly none of the other attributes
> are going to help.
> 
> Sigh.

If you think this _should_ be in the debug info, you may want to draft
a proposed extension.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa/c++] cp_lookup_rtti_type, take 2

[David Carlton]

On Fri, 5 Dec 2003 12:16:58 -0500, Daniel Jacobowitz <drow@mvista.com> said:

> How do you suggest we do it?  Some new addition to the debug info?  I
> don't believe we have anything at the moment that fills this need.

Hmm.  I thought I'd seen something appropriate in the debug info, but
now I realize that I was looking for the slot for the vtable in the
class, which is a quite different matter.

Well, here's what I see when looking for a vtable symbol in a sample
file:

	.uleb128 0x1d	# (DIE (0x20d) DW_TAG_variable)
	.long	.LC9	# DW_AT_name: "_ZTI1C"
	.long	0x21e	# DW_AT_type
	.byte	0x1	# DW_AT_external
	.byte	0x1	# DW_AT_artificial
	.byte	0x5	# DW_AT_location
	.byte	0x3	# DW_OP_addr
	.long	_ZTI1C

So DW_TAG_variable + DW_AT_artificial is a start - looking for that
(plus perhaps guiltily peeking at the demanged name just to make sure
it starts with 'typeinfo') lets us find the vtable symbols.  But that
doesn't help - the DW_AT_type doesn't actually lead us to the type
that it's the vtable for, and certainly none of the other attributes
are going to help.

Sigh.

David Carlton
carlton@kealia.com

Re: [rfa/c++] cp_lookup_rtti_type, take 2

[Daniel Jacobowitz]

On Fri, Dec 05, 2003 at 09:12:37AM -0800, David Carlton wrote:
> > We've got a vtbl pointer, and we want type information for it.
> > So we translate:
> 
> >   vtbl address -> minsym
> >   minsym -> mangled name
> >   mangled name -> demangled name
> >   demangled name -> prefix
> >   prefix -> symbol
> >   symbol -> type
> 
> > Maybe we should just go from the vtbl address to the symbol without
> > converting to a name and back again?!
> 
> It would be nice if we could eventually short-circuit much or all of
> this.  As Daniel likes to point out, we should try to reduce our
> demangler dependencies wherever possible, and this is a particularly
> unpleasant one.

How do you suggest we do it?  Some new addition to the debug info?  I
don't believe we have anything at the moment that fills this need.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa/c++] cp_lookup_rtti_type, take 2

[David Carlton]

On Thu, 4 Dec 2003 23:22:37 -0500 (EST), mec.gnu@mindspring.com
(Michael Elizabeth Chastain) said:

>> The only reason we can do it by symbol lookup at all is the One
>> Definition Rule, and we should probably be restricting ourselves to the
>> objfile in which we found the minimal symbol.

> Yes, it's still very flaky.  The only reason it works now is that
> there is a low-priority "fallback" search over all static blocks.
> That is just more trouble waiting to happen.

Yeah, but my current patch awaiting approval fixes that.  Those
symbols shouldn't be static in the first place.

> We've got a vtbl pointer, and we want type information for it.
> So we translate:

>   vtbl address -> minsym
>   minsym -> mangled name
>   mangled name -> demangled name
>   demangled name -> prefix
>   prefix -> symbol
>   symbol -> type

> Maybe we should just go from the vtbl address to the symbol without
> converting to a name and back again?!

It would be nice if we could eventually short-circuit much or all of
this.  As Daniel likes to point out, we should try to reduce our
demangler dependencies wherever possible, and this is a particularly
unpleasant one.

> In retrospect, my new lookup_rtti_type should take the domain as a
> parameter.

I think that would be more confusing.

David Carlton
carlton@kealia.com

Re: [rfa/c++] cp_lookup_rtti_type, take 2

[Michael Elizabeth Chastain]

mec> Maybe we should just go from the vtbl address to the symbol without
mec> converting to a name and back again?!

drow> We don't have any information to do that, unless you know something I
drow> don't.

No, I know much less than you about symtabs.  Rats.  :(

drow> You may have to start bootstrap a little further back than usual. 
drow> You'll need at least GNU Make... HP-UX's make is incredibly annoying.

Migchain starts with gnu make, which bootstraps with no "make" at all
(just a shell script with two dozen "cc ..." lines in it.  You probably
knew that).  I brought it up on an impovershed solaris machine about a
year ago.  So I'm ready for this part.

But now I gotta get back to all those other little pieces of work
I said I would do after this patch went in.

Michael C

Re: [rfa/c++] cp_lookup_rtti_type, take 2

[Daniel Jacobowitz]

On Thu, Dec 04, 2003 at 11:22:37PM -0500, Michael Chastain wrote:
> Cool, I will commit this patch now.
> 
> > The only reason we can do it by symbol lookup at all is the One
> > Definition Rule, and we should probably be restricting ourselves to the
> > objfile in which we found the minimal symbol.
> 
> Yes, it's still very flaky.  The only reason it works now is that
> there is a low-priority "fallback" search over all static blocks.
> That is just more trouble waiting to happen.

Trouble doesn't generally happen, though, because of the ODR.

> We've got a vtbl pointer, and we want type information for it.
> So we translate:
> 
>   vtbl address -> minsym
>   minsym -> mangled name
>   mangled name -> demangled name
>   demangled name -> prefix
>   prefix -> symbol
>   symbol -> type
> 
> Maybe we should just go from the vtbl address to the symbol without
> converting to a name and back again?!

We don't have any information to do that, unless you know something I
don't.

> > Now that we've had another major release of GDB I am extremely tempted
> > to rip out aCC C++ support.  If you really want to experiment, the HP
> > TestDrive systems do have aCC installed; www.testdrive.hp.com and
> > spe191.testdrive.hp.com:telnet.  But they're a real nuisance to run
> > tests on due to the lack of usable (to me) tools, and the restrictive
> > firewall.
> 
> That's in my area.  "Get into testdrive" is a task for me, and "set up
> migchain/migbat" is another task.  I can handle the lack of tools as
> long as there is lots of disk space, because I bootstrap the whole
> toolchain.  I'll have to see how restrictive the firewall is.

You may have to start bootstrap a little further back than usual. 
You'll need at least GNU Make... HP-UX's make is incredibly annoying.

> > And if we found problems, there wouldn't be anyone motivated
> > to fix them.
> 
> Well, it would be useful to get enough hpux running to clean up
> all the hp/acc special code in the test suite.  It would be great
> if acc is completely getting replaced, too.
> 
> > The "earlier version" used VAR_DOMAIN, FYI.  It was presumably based on
> > the code in gnu-v2-abi.c, but because gnu-v2-abi.c didn't show the
> > problem I encountered at the time I didn't update it.
> 
> Aha, the history is falling into place.
> 
> In retrospect, my new lookup_rtti_type should take the domain as a parameter.

I don't really think so.  You're always (?) looking for aggregate types
STRUCT_DOMAIN is the most useful place to find them.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa/c++] cp_lookup_rtti_type, take 2

[Michael Elizabeth Chastain]

Cool, I will commit this patch now.

> The only reason we can do it by symbol lookup at all is the One
> Definition Rule, and we should probably be restricting ourselves to the
> objfile in which we found the minimal symbol.

Yes, it's still very flaky.  The only reason it works now is that
there is a low-priority "fallback" search over all static blocks.
That is just more trouble waiting to happen.

We've got a vtbl pointer, and we want type information for it.
So we translate:

  vtbl address -> minsym
  minsym -> mangled name
  mangled name -> demangled name
  demangled name -> prefix
  prefix -> symbol
  symbol -> type

Maybe we should just go from the vtbl address to the symbol without
converting to a name and back again?!

> Now that we've had another major release of GDB I am extremely tempted
> to rip out aCC C++ support.  If you really want to experiment, the HP
> TestDrive systems do have aCC installed; www.testdrive.hp.com and
> spe191.testdrive.hp.com:telnet.  But they're a real nuisance to run
> tests on due to the lack of usable (to me) tools, and the restrictive
> firewall.

That's in my area.  "Get into testdrive" is a task for me, and "set up
migchain/migbat" is another task.  I can handle the lack of tools as
long as there is lots of disk space, because I bootstrap the whole
toolchain.  I'll have to see how restrictive the firewall is.

> And if we found problems, there wouldn't be anyone motivated
> to fix them.

Well, it would be useful to get enough hpux running to clean up
all the hp/acc special code in the test suite.  It would be great
if acc is completely getting replaced, too.

> The "earlier version" used VAR_DOMAIN, FYI.  It was presumably based on
> the code in gnu-v2-abi.c, but because gnu-v2-abi.c didn't show the
> problem I encountered at the time I didn't update it.

Aha, the history is falling into place.

In retrospect, my new lookup_rtti_type should take the domain as a parameter.

This is the major regression from gdb 6.0 to gdb HEAD.  I'd like to get
gdb HEAD to a state where there are no known regressions.  I have a
goal that gdb_6_1-branch will take only 6 weeks from cutting the branch
to the release!

Michael C