From: Elena Zannoni <ezannoni@redhat.com>
To: Adam Fedor <fedor@doc.com>
Cc: Daniel Jacobowitz <drow@mvista.com>,
Elena Zannoni <ezannoni@redhat.com>,
Michael Snyder <msnyder@redhat.com>,
GDB Patches <gdb-patches@sources.redhat.com>
Subject: Re: [PATCH] Handle ObjC OPS in eval.c
Date: Mon, 21 Apr 2003 17:09:00 -0000 [thread overview]
Message-ID: <16036.9937.695502.618066@localhost.redhat.com> (raw)
In-Reply-To: <E3C38D67-7418-11D7-BCE4-000A277AC1A4@doc.com>
Adam Fedor writes:
>
> 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.
Ah, that. Ok, but this has nothing to do with the patch in this thread.
You can commit this patch omitting the if0-ed part.
elena
next prev parent reply other threads:[~2003-04-21 17:09 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-03 20:27 Adam Fedor
2003-01-31 3:07 ` Michael Snyder
2003-02-07 18:31 ` Adam Fedor
2003-02-07 22:04 ` Andrew Cagney
2003-02-13 4:05 ` Adam Fedor
2003-02-19 20:05 ` Elena Zannoni
2003-03-05 5:06 ` Adam Fedor
2003-04-10 21:56 ` Elena Zannoni
2003-04-20 3:42 ` Adam Fedor
2003-04-21 4:14 ` Daniel Jacobowitz
2003-04-21 16:26 ` Elena Zannoni
2003-04-21 16:47 ` Adam Fedor
2003-04-21 16:51 ` Daniel Jacobowitz
2003-04-21 17:09 ` Elena Zannoni [this message]
2003-04-21 18:23 ` Adam Fedor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16036.9937.695502.618066@localhost.redhat.com \
--to=ezannoni@redhat.com \
--cc=drow@mvista.com \
--cc=fedor@doc.com \
--cc=gdb-patches@sources.redhat.com \
--cc=msnyder@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox