This is the mail archive of the gdb@sources.redhat.com 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: regarding transparent data ranges (in tracepoint support)


Sorry about the tunnel vision.  When the SUT exits we loose all of the
tracepoint data in target memory. Stopping that from happening is the
next thing on my list after I finish making interrupt work.  After the
program finishes it should not exit without an ok from the engineer.

So Ankit if that is what you are looking to do I agree completely.
However can't gdbserver do something more like the restart that occurs
with a "w" or "x" status after the putpkt in the case statement in
server.c

                                           Mark

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@mvista.com]
> Sent: Wednesday, November 19, 2003 2:39 PM
> To: Newman, Mark (N-Superior Technical Resource Inc)
> Cc: ankit thukral; Jim Blandy; gdb@sources.redhat.com
> Subject: Re: regarding transparent data ranges (in tracepoint support)
> 
> 
> On Wed, Nov 19, 2003 at 02:34:49PM -0500, Newman, Mark 
> (N-Superior Technical Resource Inc) wrote:
> > Guys - again please excuse my ignorance but
> > 
> > I was assuming that transparent memory would either be
> > 
> > In ROM
> > In a write protected page
> > In an unprotected page (for those systems without memory protection)
> > Possibly swapped out to the disk (for those system with a disk)
> > 
> > However definitely readable by "read_inferior_memory".
> > 
> > Why would the data not be loaded into some form of memory?  
> > What kind of data are we talking about?
> 
> Ankit is talking about reading the transparant tracepoint data after
> the program has exited - when its memory isn't there any more.
> 
> > 
> >                              Mark Newman
> > 
> > > -----Original Message-----
> > > From: gdb-owner@sources.redhat.com
> > > [mailto:gdb-owner@sources.redhat.com]On Behalf Of Daniel 
> Jacobowitz
> > > Sent: Wednesday, November 19, 2003 1:56 PM
> > > To: ankit thukral
> > > Cc: Jim Blandy; gdb@sources.redhat.com
> > > Subject: Re: regarding transparent data ranges (in 
> tracepoint support)
> > > 
> > > 
> > > On Wed, Nov 19, 2003 at 08:25:37AM -0800, ankit thukral wrote:
> > > > 
> > > > --- Jim Blandy <jimb@redhat.com> wrote:
> > > > > 
> > > > > ankit thukral <ankit_plug@yahoo.com> writes:
> > > > > 
> > > > > > hi all,
> > > > > >      i read about the transparent data ranges and
> > > > > > learned that data in these ranges are not supposed
> > > > > to
> > > > > > be collected by the remote stub since they belong
> > > > > to
> > > > > > read-only segment of the debuggee.my problem is :
> > > > > a
> > > > > > TSTART would start the debuggee and it may so
> > > > > happen
> > > > > > that the debuggee finishes executing.at this
> > > > > point,if
> > > > > > the GDB requests for some data in the transparent
> > > > > data
> > > > > > range,then how can the remote stub provide it with
> > > > > one
> > > > > > since the debuggee has exited ?
> > > > > 
> > > > > If the target is a gdbserver, then it would need to
> > > > > read the bytes
> > > > > from the executable file.  This is easy to do with
> > > > > BFD, but if I
> > > > > remember right, gdbserver doesn't use BFD at the
> > > > > moment; not sure how
> > > > > to get around that.
> > > > > 
> > > > > If the target is an embedded system, then presumably
> > > > > the transparent
> > > > > data ranges correspond to ROM regions, so the data
> > > > > is still there.
> > > > 
> > > > 
> > > > 
> > > >   how about setting a (internal) breakpoint in the
> > > > debuggee which would prevent it from exiting even
> > > > though it has finished executing main(),and then
> > > > entertain GDB requests for the transparent (or
> > > > read-only) memory regions by reading from the memory
> > > > of the debuggee???
> > > 
> > > That would work (but be wasteful).  At least on Linux, 
> you could read
> > > /proc/pid/maps to find what ranges correspond to where in 
> what file,
> > > and save that information.
> > > 
> > > -- 
> > > Daniel Jacobowitz
> > > MontaVista Software                         Debian 
> GNU/Linux Developer
> > > 
> > 
> 
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 


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