Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Hui Zhu <teawater@gmail.com>
Cc: gdb-patches@sourceware.org, msnyder@vmware.com
Subject: Re: [Precord RFA/RFC] Check Linux sys_brk release memory in process	record and replay.
Date: Wed, 06 May 2009 03:14:00 -0000	[thread overview]
Message-ID: <833abiexcc.fsf@gnu.org> (raw)
In-Reply-To: <daef60380905051913q7579eed8pe8b514e72145859c@mail.gmail.com>

> Date: Wed, 6 May 2009 10:13:15 +0800
> From: Hui Zhu <teawater@gmail.com>
> Cc: gdb-patches@sourceware.org, msnyder@vmware.com
> 
> If inferior release some memory, the replay will got big error because
> prec will set memory old value to this memory.

Yes, I understand that, but why will this cause an error?

> >>       * gdbarch.sh (process_record_reset): This interface point to
> >>       the function that reset the architecture process record and
> >>       replay.
> >
> > I think "reset" is not the best name for this.  How about
> > "initialize"?
> 
> This interface will be call each time when prec open, so it will reset
> the old value.
> I think initialize looks like just call once.  For example
> "_initialize_infcall".

"reset" has the opposite problem: the first time you call it, it has
no old state to reset.

If you don't like "initialize", perhaps "reinitialize" or "reinit" is
okay?  It is still better than "reset", IMO, because "reset" is very
ambiguous in the context of tracking machine instructions.  It took me
several minutes to understand what is that all about and why are you
introducing such an interface together with the sbrk handling.

Or maybe "prepare" is better?


  reply	other threads:[~2009-05-06  3:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-05 13:07 Hui Zhu
2009-05-05 13:09 ` Hui Zhu
2009-05-05 18:41 ` Eli Zaretskii
2009-05-06  2:13   ` Hui Zhu
2009-05-06  3:14     ` Eli Zaretskii [this message]
2009-05-06  3:35       ` Hui Zhu
2009-05-06 18:28         ` Eli Zaretskii
2009-05-07  2:21           ` Hui Zhu
2009-05-07  3:20             ` Eli Zaretskii
2009-05-11  7:06               ` Hui Zhu
2009-06-09  2:17                 ` Hui Zhu
2009-06-13 22:56                   ` Michael Snyder
2009-06-14  9:26                     ` Hui Zhu
2009-06-14 17:42                       ` Michael Snyder
2009-06-15  8:04                         ` Hui Zhu
2009-06-15 17:52                           ` 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=833abiexcc.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    --cc=msnyder@vmware.com \
    --cc=teawater@gmail.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