Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Newman, Mark (N-Superior Technical Resource Inc)" <mark.newman@lmco.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: ankit thukral <ankit_plug@yahoo.com>,
	Jim Blandy <jimb@redhat.com>,
	gdb@sources.redhat.com
Subject: RE: regarding transparent data ranges (in tracepoint support)
Date: Wed, 19 Nov 2003 19:51:00 -0000	[thread overview]
Message-ID: <F56FBA314E8E5A41895F0DA8F6716A6D02A1F4@EMSS04M11.us.lmco.com> (raw)

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
> 


             reply	other threads:[~2003-11-19 19:51 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-19 19:51 Newman, Mark (N-Superior Technical Resource Inc) [this message]
2003-11-19 20:22 ` Daniel Jacobowitz
2003-11-20  5:00 ` ankit thukral
  -- strict thread matches above, loose matches on Subject: below --
2003-11-29  6:56 Ramana Radhakrishnan
2003-11-28 17:35 Newman, Mark (N-Superior Technical Resource Inc)
2003-11-28 19:23 ` Daniel Jacobowitz
2003-11-29  1:29   ` Mark Newman
2003-11-29  1:34     ` Daniel Jacobowitz
2003-11-29  2:08       ` Mark Newman
2003-11-29  5:41         ` Daniel Jacobowitz
2003-11-28 17:24 Newman, Mark (N-Superior Technical Resource Inc)
2003-11-28 17:27 ` Daniel Jacobowitz
2003-11-25 16:09 Newman, Mark (N-Superior Technical Resource Inc)
2003-11-21 18:41 Newman, Mark (N-Superior Technical Resource Inc)
2003-11-19 19:35 Newman, Mark (N-Superior Technical Resource Inc)
2003-11-19 19:38 ` Daniel Jacobowitz
2003-11-17 17:26 Newman, Mark (N-Superior Technical Resource Inc)
2003-11-17 18:04 ` Ramana Radhakrishnan
2003-11-14 19:30 async operation Newman, Mark (N-Superior Technical Resource Inc)
2003-11-16  6:32 ` regarding transparent data ranges (in tracepoint support) ankit thukral
2003-11-19  7:40   ` Jim Blandy
2003-11-19 16:25     ` ankit thukral
2003-11-19 18:55       ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F56FBA314E8E5A41895F0DA8F6716A6D02A1F4@EMSS04M11.us.lmco.com \
    --to=mark.newman@lmco.com \
    --cc=ankit_plug@yahoo.com \
    --cc=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    --cc=jimb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox