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

[Hui Zhu <teawater@gmail.com>]

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