This is the mail archive of the
gdb-patches@sourceware.org
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: <daef60380905050607yc499e39n34ac56108225f6ec@mail.gmail.com> <83d4ane6kb.fsf@gnu.org> <daef60380905051913q7579eed8pe8b514e72145859c@mail.gmail.com> <833abiexcc.fsf@gnu.org> <daef60380905052035v2758da1ak27fabfd902dff32d@mail.gmail.com> <83tz3ycchv.fsf@gnu.org> <daef60380905061921k7ced158eu2a74bab604a700e1@mail.gmail.com> <83k54td2el.fsf@gnu.org> <daef60380905110006gaa1ac38r870f6be455a402fc@mail.gmail.com>
Ping.
On Mon, May 11, 2009 at 15:06, Hui Zhu<teawater@gmail.com> wrote:
> PING.
>
> On Thu, May 7, 2009 at 11:20, Eli Zaretskii <eliz@gnu.org> wrote:
>>> Date: Thu, 7 May 2009 10:21:04 +0800
>>> From: Hui Zhu <teawater@gmail.com>
>>> Cc: gdb-patches@sourceware.org, msnyder@vmware.com
>>>
>>> > 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?
>>
>