From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28146 invoked by alias); 15 Aug 2003 16:55:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 28114 invoked from network); 15 Aug 2003 16:55:53 -0000 Received: from unknown (HELO mailgw3a.lmco.com) (192.35.35.7) by sources.redhat.com with SMTP; 15 Aug 2003 16:55:53 -0000 Received: from emss04g01.ems.lmco.com ([166.17.13.122]) by mailgw3a.lmco.com (8.11.6p2/8.11.6) with ESMTP id h7FGtr017420 for ; Fri, 15 Aug 2003 12:55:53 -0400 (EDT) Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1 #40649) id <0HJO00701715U9@lmco.com> for gdb-patches@sources.redhat.com; Fri, 15 Aug 2003 12:55:53 -0400 (EDT) Received: from EMSS04I00.us.lmco.com ([166.17.13.135]) by lmco.com (PMDF V6.1-1 #40649) with ESMTP id <0HJO00DYD713UT@lmco.com> for gdb-patches@sources.redhat.com; Fri, 15 Aug 2003 12:55:51 -0400 (EDT) Received: from EMSS04M11.us.lmco.com ([144.219.10.27]) by EMSS04I00.us.lmco.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 15 Aug 2003 12:55:51 -0400 Date: Fri, 15 Aug 2003 16:55:00 -0000 From: "Newman, Mark (N-Superior Technical Resource Inc)" Subject: FW: bug ???? To: gdb-patches@sources.redhat.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 15 Aug 2003 16:55:51.0665 (UTC) FILETIME=[158CBE10:01C3634E] X-SW-Source: 2003-08/txt/msg00248.txt.bz2 -----Original Message----- From: Michael Snyder [mailto:msnyder@redhat.com] Sent: Thursday, August 14, 2003 4:16 PM To: Newman, Mark (N-Superior Technical Resource Inc) Subject: Re: bug ???? Newman, Mark (N-Superior Technical Resource Inc) wrote: >Michael - > >I am not certain how to handle this. Perhaps you can give me some >insight. I am not familar with GDB internals. > >I appears that the the following is not working correctly in >trace_dump_command > > /* The current frame is a trap frame if the frame PC is equal > to the tracepoint PC. If not, then the current frame was > collected during single-stepping. */ > > stepping_frame = (t->address != read_pc ()); > >The trace address is one less than the read_pc address (I am not >stepping). Either gdbserver needs to adjust the register set so that >the pc is back by one or some adjustment needs to be made to t->address >so it looks at the next address. Should the tracepoint look at the >state prior to executing the instruction at the address or after the >instruction is executed? > Ah, this is the old DECR_PC_AFTER_BREAK problem. I never ran into it because I never had tracepoints working on an x86 target (just about the only one left where it's an issue. Try this: stepping_frame = (t->address != (read_pc () - DECR_PC_AFTER_BREAK); The macro should evaluate to zero if the pc points to the trap instruction, and to (sizeof(trap_instruction) if it points past the trap. If this works, why don't you submit it as a patch to gdb-patches? Cheers, Michael