[RFA] Reverse Debugging, 1/5
Michael Snyder
msnyder@vmware.com
Tue Oct 7 00:45:00 GMT 2008
Joel Brobecker wrote:
>>> In infrun, the same as any other user supplied execution state.
>>> For instance the scheduler-locking setting.
>> I'm ok with that, if that's what we decide.
>>
>> But understand -- the target HAS to remember this state,
>> so now we are duplicating state. Unles we go back and
>> reverse that very first design decision and add a parameter
>> to resume -- which will be a lot of work.
>
> I don't think that adding a parameter to resume will be beneficial
> at this point. But I think it would be beneficial to have it in
> infrun instead of having the extra target method - the "target"
> in GDB's sense of the target layer doesn't have to remember the
> direction, since it can query infrun.
All right, I know when I'm licked. ;-)
Before I actually implement this, let me see if we're all
on the same page (Daniel, Joel, Pedro...)
If I put the "exec_direction" state variable in infrun,
then there's no point in having EITHER target vector
(target_set_execdir or target_get_execdir). It'll just
be an ordinary gdb "set" command.
But then I ought to add a new target vector, something like
"to_can_go_backward" (ok, to_can_reverse), because I've
presently overloaded this functionality onto the
target_get/set_execdir methods.
Then, on "set exec-dir reverse", infrun will call
target_can_reverse, and reject accordingly.
The target_ops, such as remote.c, instead of
checking its own local state variable, will call
infrun_get_exec_direction every time target_resume
is called.
Right?
More information about the Gdb-patches
mailing list