From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18794 invoked by alias); 1 Apr 2009 23:48:42 -0000 Received: (qmail 17471 invoked by uid 22791); 1 Apr 2009 23:48:36 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62,J_CHICKENPOX_73,J_CHICKENPOX_83,J_CHICKENPOX_92,J_CHICKENPOX_93,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Apr 2009 23:48:24 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n31NkNhI031781; Wed, 1 Apr 2009 19:46:23 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n31NkNkK031696; Wed, 1 Apr 2009 19:46:23 -0400 Received: from lindt.uglyboxes.com (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n31NkJjJ012087; Wed, 1 Apr 2009 19:46:20 -0400 Message-ID: <49D3FCC9.7090505@redhat.com> Date: Wed, 01 Apr 2009 23:48:00 -0000 From: Keith Seitz User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Pedro Alves CC: gdb-patches@sourceware.org Subject: Re: [RFC] Special casing dtors? References: <49CAB139.8010100@redhat.com> <49CD2F0F.8040203@redhat.com> <49CDD4C1.1080306@redhat.com> <200903301658.16807.pedro@codesourcery.com> In-Reply-To: <200903301658.16807.pedro@codesourcery.com> Content-Type: multipart/mixed; boundary="------------090209010805080504080409" X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00022.txt.bz2 This is a multi-part message in MIME format. --------------090209010805080504080409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 4674 I apologize ahead of time for the lengthy treatise here... I am not trying to be argumentative or anything, I just want to explain as best and fully as I can what I've discovered. Thank you to anyone that actually reads all of this. :-) Pedro Alves wrote: > I mentioned that these tests pass on *4.2*, and that you see them > failing on 4.3. It isn't much of a surprise that they fail on > gcc head. Actually, they PASS on gcc HEAD, too. At least, they did here. O:-) > I just tried the templates.exp test with both the top of the gcc 4.2 > branch, and with current gcc head, both on stabs, x86_64. Here's the > result difference: [big snip] I have run with gcc 4.2.0, 4.2.4, and gcc 4.3.2 releases (well, F10 w/4.3.2), and I was finally able to reproduce the failures you mention with -gstabs+ (on the 4.2.x compilers). After digging into this for quite some time, I am convinced this happens not because of my patch, but because stabs is just really broken in gdb. For example: Consider the much simpler case of setting a breakpoint on a ctor/dtor (non-template) -- for which there is not ONE single test in gdb's testsuite: $ cat simple.cc #include using namespace std; class aclass { public: aclass (void) { cout << "ctor" << endl; }; ~aclass (void) { cout << "dtor" << endl; }; }; int main (int argc, char *argv[]) { aclass* ac = new aclass(); delete ac; return 0; } Compile this with gcc-4.2.4 with -gstabs+ (or DWARF, it doesn't matter) and run this under FSF gdb CVS HEAD (from a few days ago) : (gdb) break aclass::~aclass the class `aclass' does not have destructor defined Hint: try 'aclass::~aclass or 'aclass::~aclass (Note leading single quote.) Run this under my proposed patch: (gdb) break aclass::~aclass Breakpoint 1 at 0x80489fe: file simple.cc, line 9. [Anecdote: With the templates.exp dtor test, while gdb is able to set a breakpoint, it never actually hits it. At all. It does with my patch.] So clearly, things are as complicated as we've discovered. The actual templates.exp tests which are/are not failing are template ctor and dtor tests -- ones I could also not reduce to simpler test cases. So I had a look specifically at templates.cc -- it has been over a decade since I looked at stabs output! -- and I discovered that the stabs info DOES define TWO ctors and TWO dtors. So I stepped the patched and unpatched gdbs side-by-side until I found something different. While I claim neither to understand everything behind this nor why fixing the difference I did find caused such a massive positive change in test results, it is clear that something changed in gcc somewhere, and the corresponding change never got to gdb. I've attached a secondary patch for stabsread.c which not only fixes the failing tests you found (with -gstabs+), but also fixes tons of other failures in classes.exp and virtfunc.exp (and more). Again, don't ask me why. The fix seems innocently isolated enough, but it just reduces the number of failed tests from >400 to just over 300. Can you apply the attached patch to your tree and try again? > I don't know how much we care for stabs on 4.2. Certainly on > linux it isn't that important, but other platforms are still a > bit stuck with it. Note that I'm not objecting to you applying > your patch. The failure mode it introduces on stabs isn't that > critical. I think that what is simply happening here is that there is some severe stabs breakage in gdb (and no one noticed/tested/complained?). It just so happens that some of these failures were being hidden by what I suspect is very old code. By removing the old code, the (or a) real problem was exposed. I have no doubt that there are many more undiscovered bugs w.r.t. C++ and stabs. > I was merely trying to be helpful, and I didn't > expect that we'd find this. In any case, it is always good to > try out several compilers, not just the tip of the trunk. GDB > has to cope with code produced from older compilers as well. I certainly understand (and appreciate) that you are trying to be helpful -- and you are! I never felt otherwise. So, I guess my position is that since stabs is so darn broken any way, we might as well apply the patch and deal with the fallout. At least then we'll know (and hopefully document) WHY all this special casing of dtors is necessary. Keith PS. I still don't understand how you are getting DWARF2 failures. I've run these tests on gcc 4.2.0, 4.2.4, 4.3.2, and 4.4.0, and NONE of those compilers demonstrate any failures after the patch; they all fail BEFORE the patch is applied. I guess I'll deal with this next. --------------090209010805080504080409 Content-Type: text/plain; name="ignore-__base_dtor-ctor.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ignore-__base_dtor-ctor.patch" Content-length: 745 Index: stabsread.c =================================================================== RCS file: /cvs/src/src/gdb/stabsread.c,v retrieving revision 1.113 diff -u -p -r1.113 stabsread.c --- stabsread.c 21 Feb 2009 16:14:49 -0000 1.113 +++ stabsread.c 1 Apr 2009 23:03:22 -0000 @@ -2408,8 +2408,8 @@ read_member_functions (struct field_info /* Skip GCC 3.X member functions which are duplicates of the callable constructor/destructor. */ - if (strcmp (main_fn_name, "__base_ctor") == 0 - || strcmp (main_fn_name, "__base_dtor") == 0 + if (strcmp_iw (main_fn_name, "__base_ctor ") == 0 + || strcmp_iw (main_fn_name, "__base_dtor ") == 0 || strcmp (main_fn_name, "__deleting_dtor") == 0) { xfree (main_fn_name); --------------090209010805080504080409--