This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Resubmit process record and replay, 6/10


About RECORD_IS_USED, it's mean that record target is used by  GDB.
#define RECORD_IS_USED   \
     (current_target.beneath == &record_ops)


About "record_not_record_set", I told it with Muhael in another
thread. Maybe it will be moved to record_wait in replay mode,
record_insert_breakpoint and record_remove_breakpoint.


Thanks,
Hui


On Wed, Nov 26, 2008 at 07:09, Pedro Alves <pedro@codesourcery.com> wrote:
> On Monday 24 November 2008 03:23:06, teawater wrote:
>> > Not sure if it's "are we recording" or are we "replaying", or
>> > a mix of both.  In any case, could each call site on the common
>> > code be replaced by a new suitable target method/property?
>>
>> Could you give me more message on it? I am not very clear your mean.
>
> What is the property or state that you want to check
> here?  You should export that through the target_ops interface,
> instead of making infrun.c tied to a record.c and
> the record target.
>
> Currently, GDB only distinguises reverse and forward
> execution.  Does it also need to know that replaying is a
> special case of forward execution?
>
> Perhaps you want to check if the current
> target is replaying?
>
>  target_is_replaying()
>
> ?
>
> Note that this would be a proper target_ops method, not
> a reference record_ops, like in your current macro.
>
> But, why do you need to protect `proceed' with the record
> target, while reverse/replay debugging against sid or WMware
> or Virtutech didn't need it?  If they also need it, or will
> need it, what's the check that GDB should do to prevent
> the bad writes from happening in those targets too?
>
> And, why only in `proceed'?
>
> Figuring this out, and knowing *exactly* what is it that this
> check is protecting against will let us know if there's some
> other better way.  Plain ignoring writes may or may not be
> the right thing to do here.  Can you show an example of what
> you're protecting against?
>
> E.g., should you instead prohibit the 'jump ADDR' command at a
> higher layer when replaying or executing backwards?
>
> --
> Pedro Alves
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]