From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2724 invoked by alias); 21 Apr 2003 16:51:30 -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 2629 invoked from network); 21 Apr 2003 16:51:26 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 21 Apr 2003 16:51:26 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 197eVq-0002e0-00; Mon, 21 Apr 2003 11:51:26 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 197eVa-0007CV-00; Mon, 21 Apr 2003 12:51:10 -0400 Date: Mon, 21 Apr 2003 16:51:00 -0000 From: Daniel Jacobowitz To: Adam Fedor Cc: Elena Zannoni , Michael Snyder , GDB Patches Subject: Re: [PATCH] Handle ObjC OPS in eval.c Message-ID: <20030421165110.GA25731@nevyn.them.org> Mail-Followup-To: Adam Fedor , Elena Zannoni , Michael Snyder , GDB Patches References: <20030421041353.GA18918@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00373.txt.bz2 On Mon, Apr 21, 2003 at 10:47:07AM -0600, Adam Fedor wrote: > > On Sunday, April 20, 2003, at 10:13 PM, Daniel Jacobowitz wrote: > > >On Sat, Apr 19, 2003 at 09:42:49PM -0600, Adam Fedor wrote: > >> > >>The larger problem I have, though, is changing the patch so that I can > >>call the objc-lang functions indirectly, so that objc-lang.o does not > >>have to be linked in. That seems like a pain. > >> > >>I think it would be easier to split objc-lang.c into two parts. One > >>that > >>is architecture independant that I could link in now, and the other > >>acitecture dependant part (which is already handled via the language > >>vector). Anything wrong with that? > > > >What would go in the architecture dependant part? That shouldn't > >involve te _language_ vector, it should involve the _gdbarch_ vector, > >and go in the already-existing arch files. I think. > > > > > > Currently, objc-lang.c has code for determining if an address is the > address of one of the Objective-C method dispatch functions. It > currently depends on some code that has only been implemented on a few > architectures (Aside: This code is only used if gdb is debugging an > Objective-C program using the Apple runtime not the GNU runtime, so > it's basically only useful on MacOSX/Darwin). > > Andrew had suggested that we put the objc language calls in the > language vector so that we could conditionally compile in objc-lang.o > on certain architectures until the architecture dependant code gets > fixed (or ported?). Basically it's just a temporary solution to get > Objective-C support into gdb. I've already put the architecture > dependant calls in the language vector (skip_language_trampoline). > > I'm not positive what Andrew had intended, but I guess I would have to > put all the other Objective-C language functions in a vector as well. > However, I think it would be easier just to separate out the > architecture dependant part which is, again, conditionally compiled in, > while the rest of objc-lang.c is compiled in by default. This is FETCH_ARGUMENT and friends. They should go in the gdbarch vector, and nothing objc-related at all. As we discussed, it should probably become FETCH_POINTER_ARGUMENT also. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer