This is the mail archive of the
mailing list for the GDB project.
Re: [Precord RFA/RFC] Check Linux sys_brk release memory in process record and replay.
- From: Hui Zhu <teawater at gmail dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org, msnyder at vmware dot com
- Date: Tue, 9 Jun 2009 10:17:31 +0800
- Subject: Re: [Precord RFA/RFC] Check Linux sys_brk release memory in process record and replay.
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
On Mon, May 11, 2009 at 15:06, Hui Zhu<firstname.lastname@example.org> wrote:
> On Thu, May 7, 2009 at 11:20, Eli Zaretskii <email@example.com> wrote:
>>> Date: Thu, 7 May 2009 10:21:04 +0800
>>> From: Hui Zhu <firstname.lastname@example.org>
>>> Cc: email@example.com, firstname.lastname@example.org
>>> > I thought the problem was that replaying the execution log before the
>>> > sbrk point would be impossible, because (I thought) there's no way of
>>> > regaining back the memory the inferior gave up. ?Is this the problem
>>> > you are talking about? ?If so, that is not a fatal limitation, and it
>>> > certainly does not justify stopping the program and asking the user to
>>> > make some grave decision. ?The user just needs to be notified, when
>>> > she tries that, that she cannot reverse-replay the log past this
>>> > point. ?If the user never tries to replay past that point, she never
>>> > needs to know about the problem.
>>> I am not sure make inferior cannot continue is good or not. ?I think
>>> let user choice continue or stop is better.
>> Well, what do others think?