This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Handle ObjC OPS in eval.c


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]