patch for PR gdb/574

patch for PR gdb/574

[david carlton]

For various reasons, I decided to delve into GDB recently, so I picked
bug 574 somewhat at random and decided to try to fix it.  Here's a
patch.

The problem: GDB tries to access an improper memory location while
trying to find run time type info on certain code compiled with G++
2.something.  In the situation in question, GDB is trying to find the
vptr of an object that is a subclass of a class with virtual functions
and static member data.  It looks for the information about the vptr
at a place where information about the static member data is actually
stored.  This is a data structure with a useless (and very large)
bitpos field; adding this bitpos to a pointer causes that pointer to
point to the middle of nowhere.  Oops.

The solution: Get rid of the check for

  if (VALUE_ENCLOSING_TYPE(v) != VALUE_TYPE(v))

and the surrounding code in gnu-v2-abi.c(gnuv2_value_rtti_type).

Some comments:

* gnu-v3-abi.c(gnuv3_rtti_type) doesn't have any such code, so I don't
  think this fix is likely to break anything that isn't also broken in
  gnu-v3-abi.c.

* It doesn't seem to cause any testsuites to fail that didn't fail
  before.  (In fact, when I ran it, it turned gdb.base/selftest.exp
  from a FAIL into a pass, for what that's worth; I don't know if my
  changes are relevant to that, though.)  I'm not too used to working
  the testsuites; please rerun them to make sure.

* In the test case in question, the only reason why that check matched
  was because a call to value_cast earlier in the function set the
  enclosing type to differ from the type.

* There are other problems in the surrounding code that are unrelated
  to this.  When I compiled my test program under g++-3.1, I got an
  unrelated bad memory access from inside gnu-v3-abi.c.  Also (and
  this may be related to that bad memory access), there seems to be a
  difference of opinion among various pieces of code as to whose job
  it is to demangle symbols that you want to look up in symbol
  tables.  I'll try to spend some time over the next week or two
  sorting this out.

* I'm not convinced that the code I deleted wouldn't be useful in some
  circumstances (where we had a pointer to something in the middle of
  a class); I'll try to spend some time over the next week or two
  coming up with test cases to see cause the code to fail, and to see
  if there's a better fix around somewhere.  Nonetheless, given that
  my patch does fix a known problem and, if there is a problem with
  enclosing_type, then the current gnu-v3-abi.c code probably has it
  as well, I think it should be committed.

* I haven't contacted the submitter of the bug report, but I'd be
  happy to do so if that is appropriate.

I'm including a sample program that demonstrates the bug (though the
submitter of the bug report also submitted a more elaborate test case
that has some other interesting features; hurrah for good bug
reports), a ChangeLog entry, and the patch; all will follow my
signature.

David Carlton
carlton@math.stanford.edu

/*
  An attempt to replicate GDB bug 574 with a shorter program.

  g++ -g test.cc  # no optimization, else we'd need to split into 2 files
  gdb a.out
  (gdb) b main
  (gdb) r
  (gdb) n
  (gdb) p *theB
*/

class A {
public:
  virtual void foo() {};		// Stick in a virtual function.
  static const int bar;			// Stick in a static data member.
};

class B : public A {
  static const int bar = 1;
};

int main()
{
  B *theB = new B;
}


2002-07-22  david carlton  <carlton@math.stanford.edu>

	* gnu-v2-abi.c (gnuv2_value_rtti_type): Eliminate test for being
	enclosed.  Fix PR gdb/574.


Index: gnu-v2-abi.c
===================================================================
RCS file: /cvs/src/src/gdb/gnu-v2-abi.c,v
retrieving revision 1.6
diff -c -p -r1.6 gnu-v2-abi.c
*** gnu-v2-abi.c	4 Jan 2002 18:20:19 -0000	1.6
--- gnu-v2-abi.c	22 Jul 2002 18:22:05 -0000
*************** gnuv2_value_rtti_type (struct value *v, 
*** 189,195 ****
    struct type *rtti_type;
    CORE_ADDR coreptr;
    struct value *vp;
-   int using_enclosing = 0;
    long top_offset = 0;
    char rtti_type_name[256];
    CORE_ADDR vtbl;
--- 189,194 ----
*************** gnuv2_value_rtti_type (struct value *v, 
*** 244,268 ****
    if (VALUE_ADDRESS (value_field (v, TYPE_VPTR_FIELDNO (known_type))) == 0)
      return NULL;
  
!   /*
!     If we are enclosed by something that isn't us, adjust the
!     address properly and set using_enclosing.
!   */
!   if (VALUE_ENCLOSING_TYPE(v) != VALUE_TYPE(v))
!     {
!       struct value *tempval;
!       int bitpos = TYPE_BASECLASS_BITPOS (known_type,
!                                           TYPE_VPTR_FIELDNO (known_type));
!       tempval=value_field (v, TYPE_VPTR_FIELDNO(known_type));
!       VALUE_ADDRESS(tempval) += bitpos / 8;
!       vtbl=value_as_address (tempval);
!       using_enclosing=1;
!     }
!   else
!     {
!       vtbl=value_as_address(value_field(v,TYPE_VPTR_FIELDNO(known_type)));
!       using_enclosing=0;
!     }
  
    /* Try to find a symbol that is the vtable */
    minsym=lookup_minimal_symbol_by_pc(vtbl);
--- 243,249 ----
    if (VALUE_ADDRESS (value_field (v, TYPE_VPTR_FIELDNO (known_type))) == 0)
      return NULL;
  
!   vtbl=value_as_address(value_field(v,TYPE_VPTR_FIELDNO(known_type)));
  
    /* Try to find a symbol that is the vtable */
    minsym=lookup_minimal_symbol_by_pc(vtbl);
*************** gnuv2_value_rtti_type (struct value *v, 
*** 304,311 ****
        if (full)
          *full=1;
      }
-   if (using_enc)
-     *using_enc=using_enclosing;
  
    return rtti_type;
  }
--- 285,290 ----

Re: patch for PR gdb/574

[Daniel Jacobowitz]

On Mon, Jul 22, 2002 at 11:42:58AM -0700, david carlton wrote:
> For various reasons, I decided to delve into GDB recently, so I picked
> bug 574 somewhat at random and decided to try to fix it.  Here's a
> patch.
> 
> The problem: GDB tries to access an improper memory location while
> trying to find run time type info on certain code compiled with G++
> 2.something.  In the situation in question, GDB is trying to find the
> vptr of an object that is a subclass of a class with virtual functions
> and static member data.  It looks for the information about the vptr
> at a place where information about the static member data is actually
> stored.  This is a data structure with a useless (and very large)
> bitpos field; adding this bitpos to a pointer causes that pointer to
> point to the middle of nowhere.  Oops.
> 
> The solution: Get rid of the check for
> 
>   if (VALUE_ENCLOSING_TYPE(v) != VALUE_TYPE(v))
> 
> and the surrounding code in gnu-v2-abi.c(gnuv2_value_rtti_type).

I'll review this properly later this evening, but first of all, some
comments of my own.

First, do you have an FSF copyright assignment on file?  I'm not going
to look too closely at your patch until you do, although I can
duplicate your fix from your excellent description without having
copyright problems.

Second of all, VALUE_ENCLOSING_TYPE is a bad idea, as far as I'm
concerned.  Look for it in the ChangeLog and you'll see two entries:
one fixing a bug regarding it, and the other introducing it.  It's in
ChangeLog-1998.  The entry in question is 2569 lines long, and
represents most of the periodically-mentioned HP merge.  There's a lot
of good work in there, and a lot of things that weren't quite such a
good idea in the long run.

Proper fixes for this sort of problem will probably involve removing or
at least substantially modifying the meaning of VALUE_ENCLOSING_TYPE.
I wouldn't have done it at all the same way.... and v3 support has been
getting by without setting it in this case, anyway, as you noticed.

> Some comments:
> 
> * gnu-v3-abi.c(gnuv3_rtti_type) doesn't have any such code, so I don't
>   think this fix is likely to break anything that isn't also broken in
>   gnu-v3-abi.c.
> 
> * It doesn't seem to cause any testsuites to fail that didn't fail
>   before.  (In fact, when I ran it, it turned gdb.base/selftest.exp
>   from a FAIL into a pass, for what that's worth; I don't know if my
>   changes are relevant to that, though.)  I'm not too used to working
>   the testsuites; please rerun them to make sure.

Selftest tends to change based on the optimization level you build GDB
with, among other things.  That's probably why.

> * There are other problems in the surrounding code that are unrelated
>   to this.  When I compiled my test program under g++-3.1, I got an
>   unrelated bad memory access from inside gnu-v3-abi.c.  Also (and
>   this may be related to that bad memory access), there seems to be a
>   difference of opinion among various pieces of code as to whose job
>   it is to demangle symbols that you want to look up in symbol
>   tables.  I'll try to spend some time over the next week or two
>   sorting this out.

The former is more immediately interesting to me.  I'll take a look
later.  For the latter, generally one should look up demangled names.
Especially now that I've hashed the symbol tables based on the
demangled name!

> * I'm not convinced that the code I deleted wouldn't be useful in some
>   circumstances (where we had a pointer to something in the middle of
>   a class); I'll try to spend some time over the next week or two
>   coming up with test cases to see cause the code to fail, and to see
>   if there's a better fix around somewhere.  Nonetheless, given that
>   my patch does fix a known problem and, if there is a problem with
>   enclosing_type, then the current gnu-v3-abi.c code probably has it
>   as well, I think it should be committed.
> 
> * I haven't contacted the submitter of the bug report, but I'd be
>   happy to do so if that is appropriate.
> 
> I'm including a sample program that demonstrates the bug (though the
> submitter of the bug report also submitted a more elaborate test case
> that has some other interesting features; hurrah for good bug
> reports), a ChangeLog entry, and the patch; all will follow my
> signature.
> 
> David Carlton
> carlton@math.stanford.edu

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: patch for PR gdb/574

[david carlton]

On Mon, 22 Jul 2002 15:02:20 -0400, Daniel Jacobowitz <drow@mvista.com> said:

> First, do you have an FSF copyright assignment on file?

It's in the mail.

> Second of all, VALUE_ENCLOSING_TYPE is a bad idea, as far as I'm
> concerned.

Thanks for the feedback; I'll poke around some more in the ChangeLog.

> On Mon, Jul 22, 2002 at 11:42:58AM -0700, david carlton wrote:

>> Also (and this may be related to that bad memory access), there
>> seems to be a difference of opinion among various pieces of code as
>> to whose job it is to demangle symbols that you want to look up in
>> symbol tables.

> For the latter, generally one should look up demangled names.
> Especially now that I've hashed the symbol tables based on the
> demangled name!

symtab.c(lookup_symbol) still tries to demangle the symbol name.  I
poked around with this a bit last Friday, and I'm pretty sure that
this caused a problem (note that the rtti function was demangling the
name itself, and even demangling it beyond what cplus_demangle does).
I don't have enough of a feel for whose job it is to do what here to
be sure which functions are demangling inappropriately, but I'm pretty
sure that one of them is.

David Carlton
carlton@math.stanford.edu

Re: patch for PR gdb/574

[Jim Blandy]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]


A while back I spent some time looking at some confusing behavior
related to GDB values with different static and dynamic times; that's
in the same neighborhood as the VALUE_ENCLOSING_TYPE stuff, so this
might be helpful.  I wanted to fix this myself, but I never had the
time.


[-- Attachment #2.1: Type: text/plain, Size: 52 bytes --]

Subject: Topics

Topics:
   the address of a value


[-- Attachment #2.2: Type: text/plain, Size: 5125 bytes --]

Date: Sun, 20 May 2001 02:19:41 -0500 (EST)
From: Jim Blandy <jimb@zwingli.cygnus.com>
To: gdb@sources.redhat.com, Daniel Berlin <dan@cgsoftware.com>
Subject: the address of a value
Message-Id: <20010520071941.811A35E9D7@zwingli.cygnus.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-length: 4801


I'd like to make what seems to me like a rather modest proposal:
that VALUE_ADDRESS (VALUE) should be VALUE's address.

This isn't true today.  In fact, there is little consensus within GDB
on how one *should* go about finding a value's address.  At bottom
I've included a catalog of the various assumptions currently made in
GDB's code.  Things only generally work because values with non-zero
offsets, and values whose types are different from their enclosing
types, are rare.

Probably the most correct assumption in today's code is that:

- a value v's address is VALUE_ADDRESS (v) + VALUE_OFFSET (v) +
  VALUE_EMBEDDED_OFFSET (v), and 

- for values representing C++ embedded subobjects, VALUE_ADDRESS (v) +
  VALUE_OFFSET (v) is the address of VALUE_CONTENTS_ALL (v).

(These aren't really independent; each is a consequence of the other.)

Code following these assumptions will work nicely with values that
hold both a C++ subobject and its surrounding full object, as well as
more ordinary values.  (If you're unfamiliar with the embedded offset
stuff, see my recent doc fix for value.h, posted to gdb-patches but
not yet committed.)

I'm suggesting that, instead:

- a value v's address should be VALUE_ADDRESS (v), and

- for values representing C++ embedded subobjects, VALUE_ADDRESS (v) -
  VALUE_EMBEDDED_OFFSET (v) should be the address of
  VALUE_CONTENTS_ALL (v).

This seems straightforward and simple.  Code which simply wants to
access the value need not worry about embedded objects, enclosing
types, etc.  The complexity of VALUE_EMBEDDED_OFFSET and
VALUE_ENCLOSING_TYPE is confined to code which actually wants to deal
with such things.

Implementing that suggestion would be a large change, but given the
state of the code described below, making the code consistent with any
single interpretation will be a large change.

There are some functions (notably, those for accessing structure
members and (sometimes) array elements) which adjust VALUE_OFFSET,
rather than VALUE_ADDRESS.  This allows them to work consistently on
values whose VALUE_LVAL are `lval_memory', `lval_register',
`lval_internalvar_component', or `lval_reg_frame_relative'.  Under my
suggested change, these functions would need conditionals to decide
whether to adjust VALUE_OFFSET or VALUE_ADDRESS, since consumers of
`lval_memory' values would no longer consult VALUE_OFFSET.  However,
another change, independent of the one I'm proposing here, could
eliminate VALUE_OFFSET altogether, and remove this additional
complexity in the process.  So this additional complexity needn't be
permanent.

And yes, I'm volunteering to do the work.  :)




----



Here are the various ways different parts of GDB go about computing a
value's address.  I made this list by grepping for VALUE_ADDRESS.

- The following functions assume that VALUE_ADDRESS gives a value's
  address:

    mips_push_arguments
    print_formatted (when setting next_address)
    x_command (same)
    print_frame_args
    v850-tdep.c (*yawn*)
    c_value_of_variable

- Some code assumes that VALUE_ADDRESS + VALUE_EMBEDDED_OFFSET is the
  value's address:

    c_value_print and cp_print_static_field, at the final calls to val_print
    cp_print_static_field, at the final call to cp_print_value_fields

- Other code suggests that VALUE_ADDRESS + VALUE_OFFSET is a value's
  address:

    insert_breakpoints
    remove_breakpoints
    bpstat_stop_status
    can_use_hardware_watchpoint
    evaluate_subexp_standard (as it creates the `this' parameter for
        a method call, near line 829)
    value_as_pointer
    value_assign (various cases, probably not all)
    value_subscript (when subscripting bitstrings)
    value_subscripted_rvalue
    value_cast (when casting memory lvalues of differing lengths(?))

- Still other code suggests that a value's address is VALUE_ADDRESS +
  VALUE_OFFSET + VALUE_EMBEDDED_OFFSET:

    value_ind
    value_addr
    value_repeat
    value_fetch_lazy
    search_struct_field
    search_struct_method
    find_method_list
    value_full_object

I'm omitting code that seems like an unreliable witness.  For example,
at valops.c:356 we see code manipulating aligner.contents directly,
thereby assuming in one fell swoop that host == target, and that host
sizeof(long) == target sizeof (data *).  This code is crap.

I'm also omitting code that seems to be taking advantage of special
knowledge about the value it's dealing with.  For example, one could
say that c_val_print assumes that VALUE_ADDRESS is the value's
address, or one could say it's assuming that value_at always returns a
value whose VALUE_OFFSET and VALUE_EMBEDDED_OFFSET are zero, so the
adjustments can be omitted.  This happens to be true, although it
would be easy enough not to assume this, since it makes the code
obscure.

Re: patch for PR gdb/574

[Daniel Jacobowitz]

On Mon, Jul 22, 2002 at 11:42:58AM -0700, david carlton wrote:
> For various reasons, I decided to delve into GDB recently, so I picked
> bug 574 somewhat at random and decided to try to fix it.  Here's a
> patch.
> 
> The problem: GDB tries to access an improper memory location while
> trying to find run time type info on certain code compiled with G++
> 2.something.  In the situation in question, GDB is trying to find the
> vptr of an object that is a subclass of a class with virtual functions
> and static member data.  It looks for the information about the vptr
> at a place where information about the static member data is actually
> stored.  This is a data structure with a useless (and very large)
> bitpos field; adding this bitpos to a pointer causes that pointer to
> point to the middle of nowhere.  Oops.
> 
> The solution: Get rid of the check for
> 
>   if (VALUE_ENCLOSING_TYPE(v) != VALUE_TYPE(v))
> 
> and the surrounding code in gnu-v2-abi.c(gnuv2_value_rtti_type).


> 2002-07-22  david carlton  <carlton@math.stanford.edu>
> 
> 	* gnu-v2-abi.c (gnuv2_value_rtti_type): Eliminate test for being
> 	enclosed.  Fix PR gdb/574.

This patch is approved.  When your FSF papers have been processed, I
would like to see you get write-after-approval access and commit it
yourself; Andrew, does this count as "one good patch"?

Also, I'd appreciate it if you would submit a testsuite patch to run the
reduced testcase you wrote.  More tests are always good.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: patch for PR gdb/574

[David Carlton]

In article <20020816032649.GA30528@nevyn.them.org>, Daniel Jacobowitz <drow@mvista.com> writes:

> This patch is approved.  When your FSF papers have been processed, I
> would like to see you get write-after-approval access and commit it
> yourself; Andrew, does this count as "one good patch"?

They seem to have been processed: I've gotten back the copy signed by
the FSF.

> Also, I'd appreciate it if you would submit a testsuite patch to run
> the reduced testcase you wrote.  More tests are always good.

Great, I'll try to put together a few testsuite cases corresponding to
some of my recent patches.

David Carlton
carlton@math.stanford.edu

[rfa/c++testsuite] (was Re: patch for PR gdb/574)

[David Carlton]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

In article <20020816032649.GA30528@nevyn.them.org>, Daniel Jacobowitz
<drow@mvista.com> writes:

> Also, I'd appreciate it if you would submit a testsuite patch to run
> the reduced testcase you wrote.  More tests are always good.

Here it is.  The bug seemed idiosyncratic enough to not really fit
into any of the files or into any other general schema that I could
think of, so I just put it in a new file named after the bug number.

David Carlton
carlton@math.stanford.edu

2002-08-16  David Carlton  <carlton@math.stanford.edu>

	* gdb.c++/pr-574.exp: New file.
	* gdb.c++/pr-574.cc: New file.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pr-574.exp; new file --]
[-- Type: text/x-patch, Size: 2241 bytes --]

--- /dev/null	Thu Apr 11 07:25:15 2002
+++ pr-574.exp	Fri Aug 16 16:00:06 2002
@@ -0,0 +1,71 @@
+# Copyright 2002 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+# Tests for the bug mentioned in PR gdb/574.  It's a bit
+# idiosyncratic, so I gave it its own file.
+
+# 2002-08-16  David Carlton <carlton@math.stanford.edu>
+
+# This file is part of the gdb testsuite
+
+if $tracelevel then {
+        strace $tracelevel
+        }
+
+if { [skip_cplus_tests] } { continue }
+
+#
+# test running programs
+#
+set prms_id 0
+set bug_id 0
+
+set testfile "pr-574"
+set srcfile ${testfile}.cc
+set binfile ${objdir}/${subdir}/${testfile}
+
+if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug c++}] != "" } {
+     gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
+}
+
+if [get_compiler_info ${binfile} "c++"] {
+    return -1
+}
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+gdb_load ${binfile}
+
+
+if ![runto_main] then {
+    perror "couldn't run to breakpoint"
+    continue
+}
+
+# One.
+gdb_test "break 20" "Breakpoint \[0-9\]*.*line 20\\."
+gdb_test "continue" "Continuing\\.\r\n\r\nBreakpoint.*at.*pr-574\\.cc:20\r\n.*" "continue to 20"
+
+# This failed, as long as the code was compiled with GCC v. 2.
+
+# Different compilers order the data for <A> differently, so I'm not
+# matching the result exactly.
+
+gdb_test "print *theB" "\\$\[0-9\]* = {<A> = {\[^}\]*}, static b = <optimized out>}" "PR gdb/574"
+
+gdb_exit
+return 0

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: pr-574.cc; new file --]
[-- Type: text/x-patch, Size: 486 bytes --]

--- /dev/null	Thu Apr 11 07:25:15 2002
+++ pr-574.cc	Fri Aug 16 15:21:49 2002
@@ -0,0 +1,20 @@
+/*
+  An attempt to replicate PR gdb/574 with a shorter program.
+
+  Printing out *theB failed if the program was compiled with GCC 2.95.
+*/
+
+class A {
+public:
+  virtual void foo() {};		// Stick in a virtual function.
+  int a;				// Stick in a data member.
+};
+
+class B : public A {
+  static int b;				// Stick in a static data member.
+};
+
+int main()
+{
+  B *theB = new B;
+}

Re: [rfa/c++testsuite] (was Re: patch for PR gdb/574)

[David Carlton]

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

In article <ro13ctewgca.fsf_-_@jackfruit.Stanford.EDU>, David Carlton <carlton@math.Stanford.EDU> writes:
> In article <20020816032649.GA30528@nevyn.them.org>, Daniel Jacobowitz
> <drow@mvista.com> writes:

>> Also, I'd appreciate it if you would submit a testsuite patch to run
>> the reduced testcase you wrote.  More tests are always good.

> Here it is.  The bug seemed idiosyncratic enough to not really fit
> into any of the files or into any other general schema that I could
> think of, so I just put it in a new file named after the bug number.

Here's a slightly revised version.

David Carlton
carlton@math.stanford.edu

2002-08-22  David Carlton  <carlton@math.stanford.edu>

	* gdb.c++/pr-574.exp: New file.
	* gdb.c++/pr-574.cc: New file.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: new file: pr-574.exp --]
[-- Type: text/x-patch, Size: 2107 bytes --]

--- /dev/null	Thu Apr 11 07:25:15 2002
+++ pr-574.exp	Thu Aug 22 09:34:04 2002
@@ -0,0 +1,69 @@
+# Copyright 2002 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+# Tests for the bug mentioned in PR gdb/574.  It's a bit
+# idiosyncratic, so I gave it its own file.
+
+# 2002-08-16  David Carlton <carlton@math.stanford.edu>
+
+# This file is part of the gdb testsuite
+
+if $tracelevel then {
+        strace $tracelevel
+        }
+
+if { [skip_cplus_tests] } { continue }
+
+#
+# test running programs
+#
+set prms_id 0
+set bug_id 0
+
+set testfile "pr-574"
+set srcfile ${testfile}.cc
+set binfile ${objdir}/${subdir}/${testfile}
+
+if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug c++}] != "" } {
+     gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
+}
+
+if [get_compiler_info ${binfile} "c++"] {
+    return -1
+}
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+gdb_load ${binfile}
+
+
+if ![runto_main] then {
+    perror "couldn't run to breakpoint"
+    continue
+}
+
+gdb_test "next" "" "next"
+
+# This failed, as long as the code was compiled with GCC v. 2.
+
+# Different compilers order the data for <A> differently, so I'm not
+# matching the result exactly.
+
+gdb_test "print *theB" "\\$\[0-9\]* = {<A> = {\[^}\]*}, static b = <optimized out>}" "PR gdb/574"
+
+gdb_exit
+return 0

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: new file: pr-574.cc --]
[-- Type: text/x-patch, Size: 501 bytes --]

--- /dev/null	Thu Apr 11 07:25:15 2002
+++ pr-574.cc	Tue Aug 20 16:27:07 2002
@@ -0,0 +1,22 @@
+/*
+  An attempt to replicate PR gdb/574 with a shorter program.
+
+  Printing out *theB failed if the program was compiled with GCC 2.95.
+*/
+
+class A {
+public:
+  virtual void foo() {};		// Stick in a virtual function.
+  int a;				// Stick in a data member.
+};
+
+class B : public A {
+  static int b;				// Stick in a static data member.
+};
+
+int main()
+{
+  B *theB = new B;
+
+  return 0;
+}

Re: [rfa/c++testsuite] (was Re: patch for PR gdb/574)

[Andrew Cagney]

> 2002-08-22  David Carlton  <carlton@math.stanford.edu>
> 
> 	* gdb.c++/pr-574.exp: New file.
> 	* gdb.c++/pr-574.cc: New file.
> 

Suggest a rename to c++/gdb574.*.  MI's using that and got in just a 
tiny bit earlier :-)

Andrew

Re: [rfa/c++testsuite] (was Re: patch for PR gdb/574)

[David Carlton]

On Fri, 27 Sep 2002 19:20:14 -0400, Andrew Cagney <ac131313@redhat.com> said:

>> 2002-08-22  David Carlton  <carlton@math.stanford.edu>
>> * gdb.c++/pr-574.exp: New file.

>> * gdb.c++/pr-574.cc: New file.
>> 

> Suggest a rename to c++/gdb574.*.  MI's using that and got in just a
> tiny bit earlier :-)

Grump, grump, grump.  Being a lazy person, I will give the following
justification for my naming scheme: you're proposing to change the PR
naming category so that that PR would turn into c++574.  (Or do
existing closed PR's not get moved?)  So it would make more sense to
call it gdb.c++/c++574.cc, which sounds silly: the whole directory is
about C++!  And gdb.c++/gdb574.cc is only a little less silly, or
arguably even sillier: every single file in that directory, in its
parent, and in the parent of its parent is about GDB, so putting 'gdb'
in the name of a file is just plain old redundant.  Whereas putting
'pr' in the name of a file isn't redundant at all.

Seriously, though, I'll change it to whatever name you want for
consistency's sake; but if that name involves the PR category, then we
might as well wate until the planned PR category change is completed.

David Carlton
carlton@math.stanford.edu

Re: [rfa/c++testsuite] (was Re: patch for PR gdb/574)

[Andrew Cagney]

> On Fri, 27 Sep 2002 19:20:14 -0400, Andrew Cagney <ac131313@redhat.com> said:
> 
> 
>>> 2002-08-22  David Carlton  <carlton@math.stanford.edu>
>>> * gdb.c++/pr-574.exp: New file.
> 
> 
>>> * gdb.c++/pr-574.cc: New file.
>>> 
> 
> 
>> Suggest a rename to c++/gdb574.*.  MI's using that and got in just a
>> tiny bit earlier :-)
> 
> 
> Grump, grump, grump.  Being a lazy person, I will give the following
> justification for my naming scheme: you're proposing to change the PR
> naming category so that that PR would turn into c++574.  (Or do
> existing closed PR's not get moved?)  So it would make more sense to
> call it gdb.c++/c++574.cc, which sounds silly: the whole directory is
> about C++!  And gdb.c++/gdb574.cc is only a little less silly, or
> arguably even sillier: every single file in that directory, in its
> parent, and in the parent of its parent is about GDB, so putting 'gdb'
> in the name of a file is just plain old redundant.  Whereas putting
> 'pr' in the name of a file isn't redundant at all.

Arh, the `gdb' is to disguinguish it from gcc, not from other sub 
categories :-)

Andrew