From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31941 invoked by alias); 24 Dec 2002 07:15:53 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31933 invoked from network); 24 Dec 2002 07:15:51 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by 209.249.29.67 with SMTP; 24 Dec 2002 07:15:51 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id gBO7FdP21492; Tue, 24 Dec 2002 01:15:39 -0600 Date: Mon, 23 Dec 2002 23:15:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200212240715.gBO7FdP21492@duracef.shout.net> To: josh@carbondesignsystems.com Subject: Re: gdb 5.3 issues with g++ 3.2 on RedHat 7.3 & Solaris 9. Cc: gdb@sources.redhat.com X-SW-Source: 2002-12/txt/msg00313.txt.bz2 Hello Josh, I notice that you didn't list any binutils versions. Are you just using the system binutils? If so, try building binutils 2.13.1, and then building gcc with "--with-as" and "--with-ld" flags. Red Hat Linux 7.3 shipped with binutils-2.11.93.0.2. I've seen gdb test failures with binutils versions 2.11.2, 2.12, and 2.12.1 that were fixed in binutils 2.13 and later. Constructors have a big gotcha with gcc v3: the source code of a constructor is compiled into 2 or 3 different versions of object code. These versions have unique mangled names (they have to, in order for linking to work), but they have identical source code names, which leads to a great deal of confusion. What is likely happening is that gdb sets the breakpoint in one version of the constructor but then the program is executing a different version. (BTW, PR gdb/892 is the same problem). Do this: compile this program with "gcc -S" and look at the generated assembly code: // ctor.cc class Foo { public: Foo (); }; extern "C" void my_marker_function (); Foo::Foo () { my_marker_function (); } You will see two assembly language functions with slightly different names, each with a call to the distinctive "my_marker_function". There really are two functions there and gdb has trouble with that. (There are two functions in order to implement virtual base class initialization properly -- they are the "in-charge" constructor and "not-in-charge" constructor -- there is a lot of detail behind that which needs documenting). As far as versions go, I would go with gdb 5.3, gcc 3.2.1, and binutils 2.13.1. I would try "-gdwarf-2" first and then "-gstabs+". Note the "+" in "-gstabs+"; the plain "-gstabs" does not support C++ very all at all. Also, "-ggdb" is always an alias for some other format, not a format of its own, so you can drop it from your testing. You're already on the best released gdb (5.3) and the best compiler (gcc 3.2.1) and the two good debug formats (-gdwarf-2 and -gstabs+), and the binutils change is minor (mostly it improved line number records). So configuration-wise, you are close to the best configurations already, such as they are in December 2002. Bring on the test cases and bug reports. Michael C