Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Salter <msalter@redhat.com>
To: eliz@is.elta.co.il
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH]: Make Linux use the new unified x86 watchpoint support
Date: Thu, 29 Mar 2001 12:03:00 -0000	[thread overview]
Message-ID: <200103291314.f2TDEvB02946@deneb.localdomain> (raw)
In-Reply-To: <Pine.SUN.3.91.1010329111932.3269K-100000@is>

>>>>> Eli Zaretskii writes:

> On Wed, 28 Mar 2001, Mark Salter wrote:

>> > Is there any reason that you can't define HAVE_NONSTEPPABLE_WATCHPOINT 
>> > (or some of its other brethren; see infrun.c) and get GDB to DTRT for 
>> > your target?
>> 
>> Hmm. So, what are the meanings of HAVE_NONSTEPPABLE_WATCHPOINT and
>> HAVE_STEPPABLE_WATCHPOINT? It seems if you have one, you don't have
>> the other, but infrun.c doesn't see it that way.

> IMVHO, infrun.c is somewhat messy in this area; see the comments around 
> that code.  A target should have either of these two or none, but not 
> both.  However, in practice, if you don't define any of these constants, 
> it automatically gets defined to zero by infrun.c (see the beginning of 
> the file), so the compiler will simply optimize the wrong if clauses out 
> of existence when you build GDB.

I looked at that a little further and it seems that if one of those is
defined, then GDB will step the target. It looks like one of those
should be defined iff GDB needs to step past the insn causing the
watchpoint. That is the case for architectures where the watchpoint
is triggered before the insn executes. On the architecture I'm working
with, the insn executes before the watchpoint triggers, so GDB doesn't
need to step.

>> int foo = 3;
>> 
>> main()
>> {
>> printf("%d\n", foo);
>> }
> [...]
>> If I define HAVE_NONSTEPPABLE_WATCHPOINT, I get:
>> 
>> (gdb) c
>> Continuing.
>> Hardware read watchpoint 1: foo
>> 
>> Value = 3
>> 0xa0020c4c in printf () at ....
>> (gdb)

> This looks like what you should get.

>> Note that gdb stopped inside printf. This seems suboptimal but at least
>> there's not error.

> Why suboptimal?  Does disassembly show that the debuggee stopped on a 
> wrong insn?  That is, do you indeed see an instruction before 0x0020c4c 
> which accesses the value of `foo'?  Can you show the instructions near 
> this point?

0xa0020024 <main+24>:	ldr	r1, [r3]
0xa0020028 <main+28>:	bl	0xa0020c4c <printf>

So here, the 'ldr' insn reads the foo variable, then the bl insn calls printf.
The PC is at 0xa0020028 when the wathcpoint is reported to GDB. If I don't
define HAVE_NONSTEPPABLE_WATCHPOINT, then gdb reports the read error and the
target PC is left at 0xa0020028. If I define HAVE_NONSTEPPABLE_WATCHPOINT,
then GDB steps the target which causes it to branch into printf. No read
error is reported, but the PC is in printf.

--Mark


  reply	other threads:[~2001-03-29 12:03 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-21 18:47 Mark Kettenis
2001-03-26 18:14 ` Michael Snyder
2001-03-27  0:46   ` Mark Kettenis
2001-03-27  8:45     ` Michael Snyder
2001-04-17 17:26     ` Michael Snyder
2001-04-17 23:58       ` Mark Kettenis
2001-03-26 18:35 ` Michael Snyder
2001-03-26 22:57   ` Eli Zaretskii
2001-03-27  1:13     ` Mark Kettenis
2001-03-27  1:31       ` Eli Zaretskii
2001-03-27  2:09         ` Mark Kettenis
2001-03-27  2:20           ` Eli Zaretskii
2001-03-27 10:58             ` Mark Salter
2001-03-28  1:19               ` Eli Zaretskii
2001-03-28  5:10                 ` Mark Salter
2001-03-28  5:39                   ` Eli Zaretskii
2001-03-28  8:06                     ` Mark Salter
2001-03-29 12:06                       ` Eli Zaretskii
2001-03-29 12:03                         ` Mark Salter [this message]
2001-03-27  8:55         ` Michael Snyder
2001-03-27  9:46           ` Eli Zaretskii
2001-03-27  9:55             ` Fernando Nasser
2001-03-27 11:59               ` Michael Snyder
2001-03-27 12:04                 ` Fernando Nasser
2001-03-27 11:58             ` Michael Snyder
2001-03-28  1:31               ` Eli Zaretskii
2001-03-28  2:03               ` Mark Kettenis
2001-03-27  8:52       ` Michael Snyder
2001-03-27 15:51         ` Mark Kettenis
2001-03-27 10:03       ` Andrew Cagney
2001-03-27  8:48     ` Michael Snyder
2001-03-27  9:43       ` Eli Zaretskii
2001-03-27 11:57         ` Michael Snyder
2001-03-28  1:30           ` Eli Zaretskii
2001-03-28 11:53             ` Michael Snyder
2001-03-29 12:06               ` Eli Zaretskii
     [not found] <Pine.SUN.3.91.1010329160617.4915G-100000@is>
2001-03-29 18:15 ` Mark Salter

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=200103291314.f2TDEvB02946@deneb.localdomain \
    --to=msalter@redhat.com \
    --cc=eliz@is.elta.co.il \
    --cc=gdb-patches@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