From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10172 invoked by alias); 5 Dec 2003 05:01:25 -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 10040 invoked from network); 5 Dec 2003 05:01:22 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 5 Dec 2003 05:01:22 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AS85e-0003y3-96; Fri, 05 Dec 2003 00:01:18 -0500 Date: Fri, 05 Dec 2003 05:01:00 -0000 From: Daniel Jacobowitz To: Michael Elizabeth Chastain Cc: carlton@kealia.com, gdb-patches@sources.redhat.com Subject: Re: [rfa/c++] cp_lookup_rtti_type, take 2 Message-ID: <20031205050118.GA15159@nevyn.them.org> Mail-Followup-To: Michael Elizabeth Chastain , carlton@kealia.com, gdb-patches@sources.redhat.com References: <20031205042237.56AFD4B35C@berman.michael-chastain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031205042237.56AFD4B35C@berman.michael-chastain.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-12/txt/msg00197.txt.bz2 On Thu, Dec 04, 2003 at 11:22:37PM -0500, Michael Chastain wrote: > Cool, I will commit this patch now. > > > 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. > > Yes, it's still very flaky. The only reason it works now is that > there is a low-priority "fallback" search over all static blocks. > That is just more trouble waiting to happen. Trouble doesn't generally happen, though, because of the ODR. > We've got a vtbl pointer, and we want type information for it. > So we translate: > > vtbl address -> minsym > minsym -> mangled name > mangled name -> demangled name > demangled name -> prefix > prefix -> symbol > symbol -> type > > Maybe we should just go from the vtbl address to the symbol without > converting to a name and back again?! We don't have any information to do that, unless you know something I don't. > > 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. > > That's in my area. "Get into testdrive" is a task for me, and "set up > migchain/migbat" is another task. I can handle the lack of tools as > long as there is lots of disk space, because I bootstrap the whole > toolchain. I'll have to see how restrictive the firewall is. You may have to start bootstrap a little further back than usual. You'll need at least GNU Make... HP-UX's make is incredibly annoying. > > And if we found problems, there wouldn't be anyone motivated > > to fix them. > > Well, it would be useful to get enough hpux running to clean up > all the hp/acc special code in the test suite. It would be great > if acc is completely getting replaced, too. > > > 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. > > Aha, the history is falling into place. > > In retrospect, my new lookup_rtti_type should take the domain as a parameter. I don't really think so. You're always (?) looking for aggregate types STRUCT_DOMAIN is the most useful place to find them. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer