Re: [Discussion/Prec] The record speed up plan (Make speed like without prec)

[Hui Zhu <teawater@gmail.com>]

BTW, for the name pre_record.  Do you have more better idea?

Thanks,
Hui

On Wed, May 5, 2010 at 09:53, Hui Zhu <teawater@gmail.com> wrote:
> On Wed, May 5, 2010 at 01:50, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: Hui Zhu <teawater@gmail.com>
>>> Date: Tue, 4 May 2010 10:44:17 +0800
>>> Cc: gdb@sourceware.org, msnyder@vmware.com
>>>
>>> On Sat, May 1, 2010 at 01:52, Eli Zaretskii <eliz@gnu.org> wrote:
>>> >
>>> > > From: Hui Zhu <teawater@gmail.com>
>>> > > Date: Fri, 30 Apr 2010 21:23:20 +0800
>>> > > Cc: Michael Snyder <msnyder@vmware.com>
>>> > >
>>> > > But lucky for us that insns exec rules we know.  So most of insns
>>> > > (There a some special, I will talk it later), if we have the a
>>> > > inferior value(memory and reg), we can get the each value of next
>>> > > insn.
>>> >
>>> > I don't see how you can do that, unless you first read the entire
>>> > memory of the inferior.  Otherwise, when an instruction references
>>> > some address, how do you know what value is stored at that address?
>>> >
>>>
>>> You mean before or after the insn?
>>
>> Before, of course.
>>
>>> For the before, we do something like fork to record all of them.
>>
>> "Record" where? in GDB's memory?
>
> fork a new process....
>
>>
>>> > Also, what do you do with features such as shared memory, where the
>>> > value at a given address can change beyond control of the current
>>> > inferior, and change the result of some instruction which references
>>> > that address?
>>>
>>> Agree, but we can give up of them like we give up the released memory now.
>>
>> IMHO, that'd be giving up too much.  Prec is supposed to be a
>> general-purpose tool, so designing it along an idea that has severe
>> limitations from the get-go is not something I'd recommend.
>>
>
> About this issue:
> 1. We have a switch for pre-record to close it.  The people can choice
> to open or close it.
> 2. The increase need step by step.  I am not a superman.  :)
> We will find good way to handle every limit like x86 segment reg.
>
> Thanks,
> Hui
>