From: Simon Marchi <simon.marchi@polymtl.ca>
To: Tim Newsome <tim@sifive.com>
Cc: gdb <gdb@sourceware.org>
Subject: Re: gdb requires watchpoints to fire after the write
Date: Wed, 29 Aug 2018 15:33:00 -0000 [thread overview]
Message-ID: <3833782b96d47551263798eb78f448bd@polymtl.ca> (raw)
In-Reply-To: <CAGDihen6ipD2pv2QRonBQwjoYpwbu-doL0GPX6JRix=eED8XZQ@mail.gmail.com>
On 2018-08-28 18:08, Tim Newsome wrote:
> The RISC-V Debug Spec suggests that memory write triggers fire before
> the
> access actually takes place. This allows a user to see what the value
> in
> memory is before it's overwritten. This does not play nice with gdb's
> watchpoint expectation, however. When a watchpoint is hit, gdb
> instantly
> reads the memory that it fired on, and if it hasn't changed it silently
> lets execution resume. Since on RISC-V the watchpoint fired before the
> write actually took place, gdb will always miss the first write because
> memory won't have changed yet.
>
> Does that sound right? How should I fix this? With hardware breakpoint
> functionality being generally all over the map, I can't imagine this
> hasn't
> come up before.
I don't have experience with many different architectures, but as far as
I know, the expectation of the GDB is that the watchpoint is reported
after the write. Otherwise it wouldn't need to save the value of the
watched expression. That's also how software watchpoints seem to work.
The easiest way to deal with this would be to match GDB's expectation.
But if you really prefer the behavior of reporting the watchpoint before
the event, I suppose it's always possible to teach GDB about this, but
it's a less trivial task. Especially that when you GDB evaluates
whether the watch expression has changed value, it would need to
consider the not-yet-written value in memory.
I'm also curious to know if other architectures work in this way (report
the event before the write actually take place).
Simon
next prev parent reply other threads:[~2018-08-29 15:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-28 22:08 Tim Newsome
2018-08-29 15:33 ` Simon Marchi [this message]
2018-08-29 15:47 ` Joel Brobecker
2018-08-29 15:56 ` Pedro Alves
2018-08-29 16:02 ` Simon Marchi
2018-08-29 17:29 ` Pedro Alves
2018-08-29 20:13 ` Tim Newsome
2018-08-29 20:58 ` Tom Tromey
2018-08-30 8:05 ` Joel Brobecker
2018-08-31 15:37 ` Pedro Alves
2018-08-31 15:13 ` Pedro Alves
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=3833782b96d47551263798eb78f448bd@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=gdb@sourceware.org \
--cc=tim@sifive.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).