Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Nathan Sidwell <nathan@codesourcery.com>
Cc: gdb-patches@sources.redhat.com,
	Paul Brook <paul@codesourcery.com>,
	Michael Snyder <msnyder@redhat.com>
Subject: Re: [PATCH] Some tracepoint fixes
Date: Sun, 27 Feb 2005 01:20:00 -0000	[thread overview]
Message-ID: <20050227002309.GA19138@nevyn.them.org> (raw)
In-Reply-To: <4209D595.7010602@codesourcery.com>

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


  reply	other threads:[~2005-02-27  0:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-09 11:00 Nathan Sidwell
2005-02-27  1:20 ` Daniel Jacobowitz [this message]
2005-03-08 10:06   ` Nathan Sidwell

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=20050227002309.GA19138@nevyn.them.org \
    --to=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=msnyder@redhat.com \
    --cc=nathan@codesourcery.com \
    --cc=paul@codesourcery.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