From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18205 invoked by alias); 5 Dec 2003 03:30:02 -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 18197 invoked from network); 5 Dec 2003 03:30:01 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 5 Dec 2003 03:30:01 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AS6fH-0003Xu-ED; Thu, 04 Dec 2003 22:29:59 -0500 Date: Fri, 05 Dec 2003 03:30:00 -0000 From: Daniel Jacobowitz To: Michael Elizabeth Chastain Cc: gdb-patches@sources.redhat.com, carlton@kealia.com Subject: Re: [rfa/c++] cp_lookup_rtti_type, take 2 Message-ID: <20031205032959.GA13165@nevyn.them.org> Mail-Followup-To: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com, carlton@kealia.com References: <20031201214039.7A1504B364@berman.michael-chastain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031201214039.7A1504B364@berman.michael-chastain.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-12/txt/msg00188.txt.bz2 On Mon, Dec 01, 2003 at 04:40:39PM -0500, Michael Chastain wrote: > Here is version #2 of cp_lookup_rtti_type. This patch is OK. I have a couple of comments, but none of them require changing it. > And it still needs this follow-up work: > > . The calls to lookup_rtti_type need a proper "block" parameter. > The old code needed this too; I haven't regressed anything. > I put FIXME notes in for this. I'm not as sure as you are about this - certainly we do _not_ want a block that came down the call chain; think about what dynamic type is. The only reason we can do it by symbol lookup at all is the One Definition Rule, and we should probably be restricting ourselves to the objfile in which we found the minimal symbol. Searching STRUCT_DOMAIN works because every class with debug info will be entered in both STRUCT_DOMAIN and VAR_DOMAIN, and there should only be one entry in STRUCT_DOMAIN for a non-POD type in a given objfile (or you'll get link errors from the multiple vtables! Ignoring anonymous namespaces for now.) > . hpacc_value_rtti_type has the same buggy code. I can't change the > code because I can't test it, but I can put in a big FIXME into it. > (I wonder if anyone still uses HP aCC with gdb). I would be dumbfounded if it still worked right. Note that this is aCC only, not GCC on HP/UX; and I believe that newer HP/UX compilers will use the Itanium C++ ABI, which means roughly the same as GNU v3. Now that we've had another major release of GDB I am extremely tempted to rip out aCC C++ support. If you really want to experiment, the HP TestDrive systems do have aCC installed; www.testdrive.hp.com and spe191.testdrive.hp.com:telnet. But they're a real nuisance to run tests on due to the lack of usable (to me) tools, and the restrictive firewall. And if we found problems, there wouldn't be anyone motivated to fix them. > . Nested types give a warning and don't work. > It would be nice to make them work. It's a pain. I spent quite some time trying to sort out the issues. I'll give it a shot again after more of David's patches have been merged. > 2003-12-01 Michael Chastain > > Partial fix for PR c++/1465. > Fix for PR c++/1377. > * cp-support.h (cp_lookup_rtti_type): New function. > * cp-support.c (cp_lookup_rtti_type): New function. > * gnu-v2-abi.c: Update copyright years. > (gnuv2_rtti_type): Call cp_lookup_rtti_type. > * gnu-v3-abi.c: Update copyright years. > (gnuv3_rtti_type): Call cp_lookup_rtti_type. > ! /* Make sure the type symbol is sane. (An earlier version of this > ! code would find constructor functions, who have the same name as > ! the class.) */ The "earlier version" used VAR_DOMAIN, FYI. It was presumably based on the code in gnu-v2-abi.c, but because gnu-v2-abi.c didn't show the problem I encountered at the time I didn't update it. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer