From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21438 invoked by alias); 25 Nov 2003 04:22:34 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21431 invoked from network); 25 Nov 2003 04:22:33 -0000 Received: from unknown (HELO hall.mail.mindspring.net) (207.69.200.60) by sources.redhat.com with SMTP; 25 Nov 2003 04:22:33 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AOUic-0003V5-00; Mon, 24 Nov 2003 23:22:30 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id F29A34B409; Mon, 24 Nov 2003 23:22:39 -0500 (EST) To: carlton@kealia.com, mec.gnu@mindspring.com Subject: Re: [rfc/testsuite/c++] c2.exp, new script for class lookup Cc: gdb-patches@sources.redhat.com Message-Id: <20031125042239.F29A34B409@berman.michael-chastain.com> Date: Tue, 25 Nov 2003 04:22:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2003-11/txt/msg00554.txt.bz2 dc> What else are you going to add? How about cast-classes or subclasses dc> or something like that? Well, I started out by picking up PR gdb/186, because it was in my big directory of incomplete gdb stuff that I'm working on. The issue with gdb/186 is: . program has base class "A", derived class "B" . program has an object of type "B" . program has "A *" and "B *" pointers to the "B" object . user puts breakpoint on closing "}" of function . this is after the destructors are called! . "print *b_p" does bad things after the destructor happens . because, as we figured out, B::~B changes the vptr This PR is several years old so it's not something you broke. :) So I reproduced the PR and I was writing a test case, gdb186.exp. I figured that I should put in some simple tests before the destructor happens to show that gdb is working fine in that instance. And, well, the simple tests revealed a simpler problem, without any of the destructor-changes-vptr issues. So once the immediate problem gets fixed, I can get back to worrying about "print *b_p" after B::~B is called. Also virtfunc.exp has another regression since 6.0 (PR gdb/1405, virtual baseclass botch). I wish it was related, but the dates don't match up -- it manifested on 2003-10-02. When I crack open gdb/1405 I might find that class2.exp is a good place for an explicit test. And I'll probably throw in any other class-related stuff that I come across because it's easier to work with gdb_test_multiple, kfail, test_compiler_info, and all that good stuff. Michael C