From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31204 invoked by alias); 23 Jan 2006 15:00:11 -0000 Received: (qmail 31173 invoked by uid 22791); 23 Jan 2006 15:00:08 -0000 X-Spam-Check-By: sourceware.org Received: from mail.math.TU-Berlin.DE (HELO mail.math.TU-Berlin.DE) (130.149.12.212) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 23 Jan 2006 15:00:03 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.math.TU-Berlin.DE (8.13.5/8.13.3) with ESMTP id k0NExs4r018639; Mon, 23 Jan 2006 15:59:54 +0100 (MET) Received: from mail.math.TU-Berlin.DE ([127.0.0.1]) by localhost (mail.math.tu-berlin.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18521-04; Mon, 23 Jan 2006 15:59:52 +0100 (MET) Received: from mersenne.math.TU-Berlin.DE (mersenne.math.TU-Berlin.DE [130.149.14.233]) by mail.math.TU-Berlin.DE (8.13.5/8.13.3) with ESMTP id k0NExoGR018632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Jan 2006 15:59:50 +0100 (MET) Received: from mersenne.math.TU-Berlin.DE (localhost [127.0.0.1]) by mersenne.math.TU-Berlin.DE (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k0NExoog009813; Mon, 23 Jan 2006 15:59:50 +0100 Received: (from thor@localhost) by mersenne.math.TU-Berlin.DE (8.13.3/8.13.3/Submit) id k0NExoA9009812; Mon, 23 Jan 2006 15:59:50 +0100 From: Thomas Richter Message-Id: <200601231459.k0NExoA9009812@mersenne.math.TU-Berlin.DE> Subject: Re: C++ support improvement patch In-Reply-To: <20060123141344.GA13883@nevyn.them.org> To: Daniel Jacobowitz Date: Mon, 23 Jan 2006 15:00:00 -0000 CC: gdb-patches@sourceware.org, gdb@sourceware.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00323.txt.bz2 Hi Daniel, > Thanks for the patch. There's a lot of bits that just change formatting > or comments; it's making it a little hard for me to work out what > changes do what. I think parts of the comments are useful to understand what's going on here. The most sensitive part is in symtab.c. > > o) GDB finds now members within the multiple-inheritance hierarchy of > > a class. That is, if "this" points to a class "Foo" inherited from > > "Bar" and "Baz", and "Baz" contains a member "me", then "print me" > > will succeed now. gdb 6.4 and before just returned an "unknown symbol" > > here, erraneously. This is because it was confused by a "class typedef" > > g++ inserted here for subclasses in the dwarf-2 symbol table, which is > > now cleverly avoided. The patch then, however, needs to be clever to > > resolve expressions like this->Subclass::member, which - after a bit > > of work - now works nicely as it should. It seems to me that it worked > > more or less by accident before (Subclass was resolved as the constructor > > name, not as the class name.) > > Can you give a testcase for this problem? It should already work, > and if it doesn't I want to know why! It doesn't. Sorry, the code where it doesn't is part of a larger code project I wouldn't really be able to send (and you wouldn't be willing to check, either ;-), but I'll see whether I'll be able to setup a minimal testcase. > Also, what version of GCC were you testing against? That's g++ 3.4.4, the g++ in Debian stable. > > o) For TAB-expansion, it removes the ":" as word-delimiter for > > readline, thus allowing to find names in namespaces. The current > > behaivour here is completely unusable for C++. The patch could > > be better, though, it should read template argument delimiters < > > > and function argument delimiters ( ) as "quotation characters", > > though it doesn't. Though it's a huge improvement compared to > > previous versions where TAB expansion was just not usable for C++. > > This isn't the right fix, though. Someone posted (Pierre Muller, a > long time ago - April 2002!) an initial patch to make tab completion > context sensitive (for Pascal) - tab complete to the colon, type the > colon, and then tab complete structure members after the colon. > > It isn't suitable as-is and no one ever had time to go back and improve > it but that's what ought to be done. Thanks for letting me know that this is being worked on. I agree that the given patch is pretty much a "hands on" approach. If there's a better way to do it, please do. Otherwise, the patch is "better than nothing". > > o) GDB now avoids to set multiple breakpoints to the same location. > > This goes in conjunction with another bug, namely that of being unable > > to find constructors of multiply-inherited classes. Without the current > > patch, setting a breakpoint for a constructor results in multiple breakpoint > > locations found, all of them identical, and none of them actually > > beeing breaked on. With the patch applied, GDB at least finds only one > > of the locations (good), but still doesn't break there (bad). This bug > > seems partially caused by g++ not emmiting mangled names for constructors. > > Would be better not to return duplicates, instead of not putting > duplicates on the list... we know exactly why this happens. It's > all part of the multiple constructors issue that you mentioned below, > and you can find more information about this in the gdb@ list archives. Could you provide a reference, please? Currently, the found symbols are identically (in fact, it's even the same structure using the same pointer), so I don't quite see what's the benefit as there's no chance of telling them apart later. I get two breakpoints at the same location (then, breaking nothing). In the long run, though, I agree and the problem should be fixed, not the symptom. > > o) GDB does no longer print the character and the value for integer values > > of size one. It only prints the character. The reason for this is that > > with the ddd frontend, ddd parses the output of "info breakpoints" to > > set or reset breakpoints (e.g. when moving them in the sources). Without > > the patch, the syntax of the output is no longer valid, and is not parsable > > by gdb again. > > This is what GDB has always done. I admit it's strange in expressions. > What I'd like to see would be only the value in expression printouts, > without changing the (useful) output of "print 'c'". Thus, a similar patch applied higher in the calling chain, within "info"? > > i) gdb relies on the "MIPS linkage name" of members, though according to > > the g++ folks it should not, > > I have patches to remove this dependence that I will be revisiting in > 2006. I personally wouldn't care unless I would be able to set breakpoints. (-; > > ii) g++ may create separate constructors depending on whehter the class is > > constructed by itself, or as part of a subclass. gdb seems to be unaware > > of this. I've no idea how to resolve this. > > As I mentioned above, please see the GDB list archives. It was just > discussed again recently and I have some hope that 2006 will see a > solution. That would be great! So long, and thanks for the comments. Thomas Richter