[RFA] Reverse debugging, part 1/3: target interface

Daniel Jacobowitz drow@false.org
Thu Apr 20 19:58:00 GMT 2006


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



More information about the Gdb-patches mailing list