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)


> 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?

> > 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.


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