Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Vladimir Prus <ghost@cs.msu.su>
To: gdb@sources.redhat.com
Subject: read watchpoints broken with remote targets?
Date: Fri, 11 Nov 2005 13:21:00 -0000	[thread overview]
Message-ID: <200511111621.03372.ghost@cs.msu.su> (raw)


Hi,
are read watchpoints supposed to work with remote targets?
When I try to set read watchpoint with my custom remote server, even "next" 
does not work. Gdb sends "make a single asm step" command to remote server,
server responds with "S.." packet (stopped), but gdb thinks it's read 
watchpoint that fired, turns off single stepping and reports read watchpoint.

Here's exactly what happens:

1. handle_inferior_event (infrun.c) is called.

2. It contains:
   int stopped_by_watchpoint = -1;

3. The following code is executed:

   if (HAVE_CONTINUABLE_WATCHPOINT)
    stopped_by_watchpoint = STOPPED_BY_WATCHPOINT (ecs->ws);

   For remote targets, and for pretty much all other targets,
   HAVE_CONTINUABLE_WATCHPOINT is 0, so value of stopped_by_watchpoint
   is still -1

4. Function bpstat_stop_status (breakpoint.c) is called, and
   stopped_by_watchpoint is passed to it (the value is still -1).

5. bpstat_stop_status tries to create a list of stop reasons, by iterating
   over all breakpoints and trying to check if that's breakpoint that's
   fired. For read wathcpoints we arrive at this:

      if ((b->type == bp_hardware_watchpoint
	   || b->type == bp_read_watchpoint
   	   || b->type == bp_access_watchpoint)
           && !stopped_by_watchpoint)
        continue;

   since stepped_by_watchpoint is -1 we continue with the loop body, and
   arrive at this:

      bs = bpstat_alloc (b, bs);	/* Alloc a bpstat to explain stop */

   this adds a new element to the list of stop reasons.

6. We execute this code:

   	if (!target_stopped_data_address (&current_target, &addr))
	  continue;

    since there were no watchpoint, "continue" is executed. But the stop
    reasons list still has a new element corresponding to read
    watchpoint. 

7.  We return to handle_inhefiour_event, which notices the stop reasons list 
    and stops stepping.

I've fixed this by replacing code in (6) with:

	if (!target_stopped_data_address (&current_target, &addr))
        {
          bs->print_it = print_it_noop;
   	  bs->stop = 0;
	  continue;
        }

Could somebody comment if this is the right fix?

BTW, HAVE_CONTINUABLE_WATCHPOINT is only set for x86, it seems, so read 
watchpoint might be broken for more targets then just remote.

- Volodya





             reply	other threads:[~2005-11-11 13:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-11 13:21 Vladimir Prus [this message]
2005-11-11 17:39 ` Eli Zaretskii
2005-11-13 17:09   ` Daniel Jacobowitz
2005-11-14  6:23     ` Johan Rydberg
2005-11-14  8:21       ` Vladimir Prus

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=200511111621.03372.ghost@cs.msu.su \
    --to=ghost@cs.msu.su \
    --cc=gdb@sources.redhat.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