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

[Adam Fedor <fedor@doc.com>]

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.