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.