This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [Discussion/Prec] The record speed up plan (Make speed like without prec)
- From: Hui Zhu <teawater at gmail dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb at sourceware dot org, msnyder at vmware dot com
- Date: Wed, 5 May 2010 09:53:38 +0800
- Subject: Re: [Discussion/Prec] The record speed up plan (Make speed like without prec)
- References: <t2sdaef60381004300623zd062f706k85a91e5cb6787934@mail.gmail.com> <83iq78x1yz.fsf@gnu.org> <l2rdaef60381005031944xc84eb055y1247ae8435121911@mail.gmail.com> <83k4rjv9n1.fsf@gnu.org>
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