From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9473 invoked by alias); 27 Feb 2005 00:23:29 -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 9430 invoked from network); 27 Feb 2005 00:23:18 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 27 Feb 2005 00:23:18 -0000 Received: from drow by nevyn.them.org with local (Exim 4.44 #1 (Debian)) id 1D5CDF-00056r-UA; Sat, 26 Feb 2005 19:23:10 -0500 Date: Sun, 27 Feb 2005 01:20:00 -0000 From: Daniel Jacobowitz To: Nathan Sidwell Cc: gdb-patches@sources.redhat.com, Paul Brook , Michael Snyder Subject: Re: [PATCH] Some tracepoint fixes Message-ID: <20050227002309.GA19138@nevyn.them.org> Mail-Followup-To: Nathan Sidwell , gdb-patches@sources.redhat.com, Paul Brook , Michael Snyder References: <4209D595.7010602@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4209D595.7010602@codesourcery.com> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-02/txt/msg00273.txt.bz2 On Wed, Feb 09, 2005 at 09:19:17AM +0000, Nathan Sidwell wrote: > In porting gdb to a new architecture, I came across a number of core gdb > bugs. Here is the first set of them and addresses the following issues, > > 1) we did not allow 'extended-remote' targets to use tracepoints. > > 2) We could only trace architectures with 64 registers, not 256 like > a comment suggested. > > 3) There was an erroneous comment about tracing memory ranges > > 4) If a ^D was entered when entering the 'actions' list, we'd create > a NULL action, which would cause a segfault when tracing started. > > 5) The 'tstatus' command did not actually print any status. testcase > gdb.trace/tfind.exp exepected it to do so. > > 6) Parsing the tfind responses uses strtol to read hex. That reads > 'FFFFFFFF' as '7FFFFFFF' (and sets errno). Using sscanf reads that as > -1, as desired. > > built and tested on i686-pc-linux-gnu, (and on the unreleased architecture > I ported to) ok? Hi Nathan, Some bits of this are OK, some aren't (and I'd want Michael's opinion on them). In particular, the tracepoint remote protocol packets don't appear to be documented; so I'm not sure about the strtol change. Your change is definitely wrong one way or another, because it depends on the size of "long" on the host. You're passing a long* to sscanf where it expects an unsigned long*. If we expect a hex-encoded 32-bit result, then let's parse it that way explicitly. > *************** trace_status_command (char *args, int fr > *** 1873,1878 **** > --- 1877,1886 ---- > > /* exported for use by the GUI */ > trace_running_p = (target_buf[1] == '1'); > + if (trace_running_p) > + printf_filtered ("Trace is running.\n"); > + else > + printf_filtered ("Trace is not running.\n"); > } > else > error ("Trace can only be run on remote targets."); That's really weird. This hasn't been there as far back as the code has been in the FSF repository, but the testsuite definitely tests for it... it's pretty useless in the CLI as it is. Michael, any idea? -- Daniel Jacobowitz CodeSourcery, LLC