This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] Handle ObjC OPS in eval.c
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Adam Fedor <fedor at doc dot com>
- Cc: Elena Zannoni <ezannoni at redhat dot com>,Michael Snyder <msnyder at redhat dot com>,GDB Patches <gdb-patches at sources dot redhat dot com>
- Date: Mon, 21 Apr 2003 12:51:10 -0400
- Subject: Re: [PATCH] Handle ObjC OPS in eval.c
- References: <20030421041353.GA18918@nevyn.them.org> <E3C38D67-7418-11D7-BCE4-000A277AC1A4@doc.com>
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