From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18547 invoked by alias); 21 Apr 2003 18:23:32 -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 18531 invoked from network); 21 Apr 2003 18:23:32 -0000 Received: from unknown (63.119.183.65) by sources.redhat.com with QMTP; 21 Apr 2003 18:23:32 -0000 Received: (qmail 16526 invoked from network); 21 Apr 2003 18:26:12 -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 18:26:12 -0000 Date: Mon, 21 Apr 2003 18:23: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: Daniel Jacobowitz , Michael Snyder , GDB Patches To: Elena Zannoni From: Adam Fedor In-Reply-To: <16036.9937.695502.618066@localhost.redhat.com> Message-Id: <561D8A7E-7426-11D7-BCE4-000A277AC1A4@doc.com> Content-Transfer-Encoding: 7bit X-SW-Source: 2003-04/txt/msg00375.txt.bz2 On Monday, April 21, 2003, at 11:13 AM, Elena Zannoni wrote: > Adam Fedor writes: >> >> 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. > > Ah, that. Ok, but this has nothing to do with the patch in this thread. > You can commit this patch omitting the if0-ed part. > No. gdb won't link with the patch included without objc-lang.o linked in.