This is the mail archive of the gdb@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] |
Hi, This is a demo. Still not support segment register, system call and some others. Thanks, Hui On Fri, Apr 30, 2010 at 21:23, Hui Zhu <teawater@gmail.com> 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] |