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]

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


Are you use gdb-cvs-head?

Hui

On Fri, May 21, 2010 at 13:33, paawan oza <paawan1982@yahoo.com> wrote:
> 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
>>
>
>
>
>
>


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