From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26764 invoked by alias); 6 Oct 2003 15:08:33 -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 26725 invoked from network); 6 Oct 2003 15:08:27 -0000 Received: from unknown (HELO mailgw3a.lmco.com) (192.35.35.7) by sources.redhat.com with SMTP; 6 Oct 2003 15:08:27 -0000 Received: from emss04g01.ems.lmco.com ([166.17.13.122]) by mailgw3a.lmco.com (8.11.6p2/8.11.6) with ESMTP id h96F8Q707434 for ; Mon, 6 Oct 2003 11:08:26 -0400 (EDT) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1X6 #30760) id <0HMC00J01CQ217@lmco.com> for gdb@sources.redhat.com; Mon, 06 Oct 2003 11:08:26 -0400 (EDT) Received: from EMSS04I00.us.lmco.com ([166.17.13.135]) by lmco.com (PMDF V6.1-1X6 #30760) with ESMTP id <0HMC002BECQ17S@lmco.com> for gdb@sources.redhat.com; Mon, 06 Oct 2003 11:08:26 -0400 (EDT) Received: from EMSS04M11.us.lmco.com ([144.219.10.27]) by EMSS04I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 06 Oct 2003 11:08:25 -0400 Date: Mon, 06 Oct 2003 15:08:00 -0000 From: "Newman, Mark (N-Superior Technical Resource Inc)" Subject: FW: tracepoint frames To: gdb@sources.redhat.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 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: 06 Oct 2003 15:08:25.0918 (UTC) FILETIME=[B110CDE0:01C38C1B] X-SW-Source: 2003-10/txt/msg00100.txt.bz2 -----Original Message----- From: Newman, Mark (N-Superior Technical Resource Inc) Sent: Monday, October 06, 2003 11:00 AM To: 'Daniel Jacobowitz' Subject: RE: tracepoint frames Sorry reset outlook to do the reply's this way. > -----Original Message----- > From: Daniel Jacobowitz [mailto:drow@mvista.com] > Sent: Monday, October 06, 2003 10:53 AM > To: Newman, Mark (N-Superior Technical Resource Inc) > Cc: Jim Blandy; gdb@sources.redhat.com > Subject: Re: tracepoint frames > > > On Mon, Oct 06, 2003 at 09:59:46AM -0400, Newman, Mark > (N-Superior Technical Resource Inc) wrote: > > > > First - thanks for the response > > I don't suppose you could use a mail client which quotes normally? > It's hard to see your responses. > > > -----Original Message----- > > From: Daniel Jacobowitz [mailto:drow@mvista.com] > > Sent: Monday, October 06, 2003 9:51 AM > > To: Newman, Mark (N-Superior Technical Resource Inc) > > Cc: Jim Blandy; gdb@sources.redhat.com > > Subject: Re: tracepoint frames > > > > > > On Mon, Oct 06, 2003 at 09:03:03AM -0400, Newman, Mark (N-Superior > > Technical Resource Inc) wrote: > > > > > > Jim - > > > > > > When a trace point is hit some data is collected - certainly at a > > > minimum the data specified by the collect statements. > However from > > some > > > earlier conversations and a converstaion with Ramana that > additional > > > information should be collected. Michael indicated that > he collected > > a > > > "frame" in addition to the registers, data items, etc > specified in the > > > collect commands. > > > > > > Is it necessary to collect enough information to support say a > > > "backtrace" command (after a tfind)? > > > > Well, it would be nice but it's not generally possible. > The backtrace > > logic is pretty hairy and target-dependent; the stub has no > way to find > > out what will be necessary. > > > > > If this is necessary I was thinking that the sub could > collect the whole > > stack. However this seems to be prohibitively expensive in > both size > > and speed. > > Yes, it is. On some architectures it's not even enough. > > > > I have found that simple "print" commands will work and > that "printf" > > > commands will not work unless one sets up the complete > environment. Is > > > there a requirement or a preference on the part of the > community as to > > > what needs to be available when analyzing a tracepoint? > > > > Probably if any additional data ought to be collected that shoud be > > implemented in the GDB client, not silently by the stub. > > > > I thought that the data was collected only in the stub when > a tracepoint > > is hit. GDB never sees the data until a "g" or an "m" > protocol message > > arrives at the stub. > > Right, but GDB could request more information from the stub when it > creates the tracepoint. The stub shouldn't have to collect > anything at > all that GDB didn't tell it to. > That is an interesting point! This could be left up to the user. Would that be acceptable to the community? > > -- > Daniel Jacobowitz > MontaVista Software Debian GNU/Linux Developer >