This is the mail archive of the 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: [Discussion/Prec] The record speed up plan (Make speed like without prec)


This is a demo.

Still not support segment register, system call and some others.


On Fri, Apr 30, 2010 at 21:23, Hui Zhu <> wrote:
> Hello,
> I think the record speed is the biggest trouble of prec.
> After I did a long think and a lot of test around with it. ÂI got a
> idea. ÂActually, I have began the code work.
> I found that the big trouble is prec let the inferior just step. ÂIt
> make inferior speed very low. ÂBecause the setp need a lot of context
> works.
> So I think let inferior continue can make it speed up. ÂBut How to
> record the change of each step?
> Some physicists said all the things in the world have execution rules.
> ÂSo use the current stat of this thing, we will get what will happen
> in the future. ÂLooks most of rules are still not found. Â:)
> 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.
> So if we can record the all the value of a inferior A(or all the value
> that will be change, but to get it will need parse the insns that will
> be exec, this is not easy.) , we can let the inferior exec without
> step. ÂIf the user want reverse exec, get the each step value from A.
> Then the record speed will very faster than before.
> But this way have a 2 question.
> 1. ÂHow to record all the status of a inferiorï For the linux,
> checkpoint already use fork to record the inferior. ÂSo prec will use
> it too.
> And when we want get the old status of inferior step by step, we can
> let the forked process step by step. ÂThat will easy by parse the insn
> and know what will happen.
> 2. ÂHow to handle special insns that we will not know what will happen
> after it exec?
> The first type of this insns is system call. ÂLinux have catchpoint
> that make inferior stop before and after syscall. ÂThen we can record
> the change after the system call.
> The other insn is like rdtsc, I don't know howto get the feature value
> of this type. ÂMy current idea with them is give up all the record
> after this insn.
> If user need, insert special breakpoint for it. ÂNext time, inferior
> will stop on this insn, then prec can record the value after it exec.
> BTW, I call this new function pre_record, I agree with you if you said
> this name is ugly. :)
> Please tell me your opinions about my idea. ÂThat will help me a lot. ÂThanks.
> Thanks,
> Hui

Attachment: record_disable.txt
Description: Text document

Attachment: pre-prec.txt
Description: Text document

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