From: Daniel Jacobowitz <drow@false.org>
To: Michael Snyder <msnyder@redhat.com>
Cc: GDB Patches <gdb-patches@sources.redhat.com>
Subject: Re: [RFA] Reverse debugging, part 1/3: target interface
Date: Thu, 20 Apr 2006 19:58:00 -0000 [thread overview]
Message-ID: <20060420195824.GC22563@nevyn.them.org> (raw)
In-Reply-To: <4447E406.5050006@redhat.com>
On Thu, Apr 20, 2006 at 12:41:58PM -0700, Michael Snyder wrote:
> > Also, it
> >might be nice to use the new style rather than using INHERIT (search
> >the vector at call time; see the "do not inherit" comments); that makes
> >the debugging output nicer, too.
>
> OK, I think I know what you mean (the ->beneath business) --
> but why is this better?
It's easier to deal with because we can figure out which target is
implementing the method (e.g. if it wants to get at target-specific
data). Also, "set debug target 1" takes effect right away if you do
this - not the next time you connect.
> >... but these _execution_direction methods. Please choose one or the
> >other; it makes it simpler to find the uses and implementations at the
> >same time.
>
> ... are you referring to the choices of names?
>
> I made the names of the macros more verbose because they're
> more visible, and used in a context where any aid to understanding
> is desireable. For the struct members themselves, I used shorter
> names because they're *not* all that visible, are used in a context
> where it's not all that critical to understand precisely what they
> do, and longer names are cumbersome. For instance, they would make
> the declarations in target.h really long.
>
> Do you still think I should change it?
I do. The problem is, what are people going to call the target
implementations of these? They implement
target_get_execution_direction, but they get assigned to
to_get_execdir. So whichever one you pick, some of the people
searching for it aren't going to find it.
I don't really care which one you use, though.
> >>+ remote_ops.to_get_execdir = remote_get_execdir;
> >>+ remote_ops.to_set_execdir = remote_set_execdir;
> >
> >
> >What about the other remote ops vectors? At least one isn't copied
> >from here.
>
> Right, well, I figured get it accepted in one vector, then
> worry about extending it into others. Basically, as of this
> patch, it will work with "target remote" only (and I guess
> only in non-async mode).
I guess. I really want to kill the extra vectors; but we can leave
this as one more inconsistency to clean up between them. But the bits
you're adding to remote.c don't seem that they'd need anything new to
handle async.
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2006-04-20 19:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <442DAA70.5070203@redhat.com>
2006-04-01 12:23 ` Eli Zaretskii
2006-04-17 23:37 ` Michael Snyder
2006-04-18 12:58 ` Daniel Jacobowitz
2006-04-18 15:24 ` Daniel Jacobowitz
2006-04-18 22:08 ` Michael Snyder
2006-04-19 8:48 ` Eli Zaretskii
2006-04-19 18:26 ` Michael Snyder
2006-04-20 9:18 ` Eli Zaretskii
2006-04-20 13:43 ` Daniel Jacobowitz
2006-04-20 19:22 ` Michael Snyder
2006-04-20 19:50 ` Daniel Jacobowitz
2006-04-20 23:53 ` Michael Snyder
2006-04-24 20:55 ` Daniel Jacobowitz
2006-04-18 18:59 ` Michael Snyder
2006-04-20 13:58 ` Daniel Jacobowitz
2006-04-20 19:42 ` Michael Snyder
2006-04-20 19:58 ` Daniel Jacobowitz [this message]
2006-04-01 16:39 Michael Snyder
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=20060420195824.GC22563@nevyn.them.org \
--to=drow@false.org \
--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