From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10897 invoked by alias); 19 Nov 2003 19:51:08 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 10889 invoked from network); 19 Nov 2003 19:51:07 -0000 Received: from unknown (HELO mailgw3a.lmco.com) (192.35.35.7) by sources.redhat.com with SMTP; 19 Nov 2003 19:51:07 -0000 Received: from emss04g01.ems.lmco.com ([166.17.13.122]) by mailgw3a.lmco.com (8.11.6p2/8.11.6) with ESMTP id hAJJobN22309; Wed, 19 Nov 2003 14:50:37 -0500 (EST) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30760) id <0HOM0010174DTV@lmco.com>; Wed, 19 Nov 2003 14:50:37 -0500 (EST) Received: from EMSS04I00.us.lmco.com ([166.17.13.135]) by lmco.com (PMDF V6.1-1X6 #30760) with ESMTP id <0HOM00K7V74C51@lmco.com>; Wed, 19 Nov 2003 14:50:37 -0500 (EST) Received: from EMSS04M11.us.lmco.com ([144.219.10.27]) by EMSS04I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Nov 2003 14:50:30 -0500 Date: Wed, 19 Nov 2003 19:51:00 -0000 From: "Newman, Mark (N-Superior Technical Resource Inc)" Subject: RE: regarding transparent data ranges (in tracepoint support) To: Daniel Jacobowitz Cc: ankit thukral , Jim Blandy , gdb@sources.redhat.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 19 Nov 2003 19:50:30.0158 (UTC) FILETIME=[62DFE2E0:01C3AED6] X-SW-Source: 2003-11/txt/msg00156.txt.bz2 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 wrote: > > > > > > > > > > ankit thukral 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 >