From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15407 invoked by alias); 21 Apr 2003 04:14:11 -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 15400 invoked from network); 21 Apr 2003 04:14:10 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 21 Apr 2003 04:14:10 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 197Sgy-0001X5-00; Sun, 20 Apr 2003 23:14:08 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 197Sgj-0004wn-00; Mon, 21 Apr 2003 00:13:53 -0400 Date: Mon, 21 Apr 2003 04:14: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: <20030421041353.GA18918@nevyn.them.org> Mail-Followup-To: Adam Fedor , Elena Zannoni , Michael Snyder , GDB Patches References: <3E15F21B.6010101@doc.com> <3E39E887.AB98ECA4@redhat.com> <3E4B195D.2000200@doc.com> <15955.58501.106665.997721@localhost.redhat.com> <3E6585AA.7040602@doc.com> <16021.59784.477170.598470@localhost.redhat.com> <3EA21739.2030403@doc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EA21739.2030403@doc.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00366.txt.bz2 On Sat, Apr 19, 2003 at 09:42:49PM -0600, Adam Fedor wrote: > > > Elena Zannoni wrote: > >Adam Fedor writes: > > > > > > > > > Elena Zannoni wrote: > > > [...] > > > > > > > > I think we need more comments, I guess stret means structure return? > > > > What are these methods used for? Also can you add a high level > > > > description of how these dispatchers get into the picture? > > > > > > > > > > Here's a better documented and slightly cleaned-up patch. > > > 2003-03-04 Adam Fedor > > > >I think it's ok. Except I don't like to introduce more #if0 code with new > >code. > >Do we really need that part? > > > > I bet no one would complain if I took it out. > > 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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer