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: GDB record patch 0.1.3.1 for GDB-6.8 release


I think the good way is let user choice. When the user goes back a few
insns and he want to change the values of memory or register. The GDB
willtalk clear what will happen such as the future record will
destory, and ask user if he want to continue or not.
Then user can choice with himself.

How do you think?
teawatert




On Thu, May 22, 2008 at 4:38 AM, Thiago Jung Bauermann
<bauerman@br.ibm.com> wrote:
> On Wed, 2008-05-21 at 14:45 -0400, Daniel Jacobowitz wrote:
>> On Wed, May 21, 2008 at 03:35:16PM -0300, Thiago Jung Bauermann wrote:
>> > Right. And that's very easy to implement right? Just throw away the
>> > recorded entries "in the future". Or am I being to naïve?
>>
>> It depends... hey, weren't you at my talk about this last June? :-)
>
> Ahem. :-)
>
>> I don't remember if I went into this part but there's a section in the
>> proceedings.
>
> IIRC, you did talk about the printf example and an event log.
>
>>   Continuing forward from a modified point depends on
>> being able to synchronize external and recorded state.  Just
>> destroying the recorded state would work if you could detect
>> relevant modifications - it's made slightly tricky by memory
>> breakpoints but you're right, it's not too hard.
>
> Yeah, I was ignoring the external world. Since the record patch also
> ignores it, I guess it's okay for now...
>
> That would probably be the meat of GDB record Mark II or something.
> --
> []'s
> Thiago Jung Bauermann
> Software Engineer
> IBM Linux Technology Center
>
>


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