From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28864 invoked by alias); 21 Apr 2003 16:47:14 -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 28822 invoked from network); 21 Apr 2003 16:47:12 -0000 Received: from unknown (63.119.183.65) by sources.redhat.com with QMTP; 21 Apr 2003 16:47:12 -0000 Received: (qmail 4750 invoked from network); 21 Apr 2003 16:49:56 -0000 Received: from cpe-24-221-209-215.co.sprintbbd.net (HELO doc.com) (24.221.209.215) by external1 with SMTP; 21 Apr 2003 16:49:56 -0000 Date: Mon, 21 Apr 2003 16:47:00 -0000 Subject: Re: [PATCH] Handle ObjC OPS in eval.c Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Elena Zannoni , Michael Snyder , GDB Patches To: Daniel Jacobowitz From: Adam Fedor In-Reply-To: <20030421041353.GA18918@nevyn.them.org> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00371.txt.bz2 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.