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

[paawan oza <paawan1982 at yahoo dot com>]

Hi Hui,

would you please explain the idea of following lines ?

if (lookup_minimal_symbol ("fork", NULL, NULL) != NULL) 
    fork_fn = find_function_in_inferior ("fork", &fork_objf); 
if (!fork_fn) 
    if (lookup_minimal_symbol ("_fork", NULL, NULL) != NULL) 
      fork_fn = find_function_in_inferior ("fork", &fork_objf); 
      if (!fork_fn) +    return -1; +  ret = value_from_longest (builtin_type (gdbarch)->builtin_int, 0); 
 /* Tell record.c that the following inferior change doesn't need record. */ 
      old_cleanups = record_disable_set (); + +  
 /* Tell target that this is linux pre-record.  */ 
      self_cleanups = make_cleanup_restore_integer      (&linux_pre_recording); +  linux_pre_recording = 1; 
      ret = call_function_by_hand (fork_fn, 0, &ret); + +  do_cleanups (self_cleanups);


PS: I am unable to find some definations e.g. find_function_in_inferior

please comment.

Regards,
Oza.




----- Original Message ----
From: Hui Zhu <teawater@gmail.com>
To: gdb@sourceware.org
Cc: Michael Snyder <msnyder@vmware.com>; paawan oza <paawan1982@yahoo.com>; Eli Zaretskii <eliz@gnu.org>
Sent: Wed, May 19, 2010 12:48:50 PM
Subject: Re: [Discussion/Prec] The record speed up plan (Make speed like  without prec)

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
>