From: Daniel Jacobowitz <dan@codesourcery.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: Ken Werner <ken@linux.vnet.ibm.com>,
gdb-patches@sourceware.org,
Joel Brobecker <brobecker@adacore.com>
Subject: Re: [patch] fix pre-/post- in-/decrement
Date: Mon, 04 Oct 2010 22:59:00 -0000 [thread overview]
Message-ID: <20101004225938.GZ6985@caradoc.them.org> (raw)
In-Reply-To: <201010042157.o94LvlhY018611@d12av02.megacenter.de.ibm.com>
On Mon, Oct 04, 2010 at 11:57:47PM +0200, Ulrich Weigand wrote:
> It would appear that even the current behavior, as shown in your trace,
> already contains an unnecessary load. There should be no need to perform
> a memory read to evaluate "print *$p = 1".
In fact, we rely on this unintuitive behavior. If you write to any
kind of memory other than RAM, then it's not possible for GDB to
predict what value was actually written. Suppose you write a value to
ROM with "print"; GDB should show the old value, to reflect that the
variable was not modified.
I can't think of a good way to test this other than by matching debug
output...
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2010-10-04 22:59 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-17 12:58 [patch] GNU vector unop support Ken Werner
2010-09-28 16:04 ` Ken Werner
[not found] ` <20100930185634.GC6213@adacore.com>
2010-10-01 17:45 ` [patch] fix pre-/post- in-/decrement Ken Werner
2010-10-04 13:01 ` Ulrich Weigand
2010-10-04 19:47 ` Ken Werner
2010-10-04 20:45 ` Daniel Jacobowitz
2010-10-04 21:58 ` Ulrich Weigand
2010-10-04 22:59 ` Daniel Jacobowitz [this message]
2010-10-04 23:25 ` Ulrich Weigand
2010-10-05 1:17 ` Daniel Jacobowitz
2010-10-05 13:28 ` Ulrich Weigand
2010-10-05 13:42 ` Daniel Jacobowitz
2010-10-06 18:59 ` [rfc] Fix value_assign return value (Re: [patch] fix pre-/post- in-/decrement) Ulrich Weigand
2010-10-26 13:42 ` Daniel Jacobowitz
2010-12-01 16:51 ` Ulrich Weigand
2010-10-06 20:55 ` [patch] fix pre-/post- in-/decrement Vladimir Prus
2010-10-07 12:38 ` Ken Werner
2010-10-12 23:00 ` Tom Tromey
2010-10-13 8:45 ` Andreas Schwab
2010-10-13 9:23 ` Ken Werner
2010-10-13 16:07 ` Daniel Jacobowitz
2010-10-13 19:01 ` Tom Tromey
2010-10-19 7:38 ` Ken Werner
2010-11-02 8:23 ` Ken Werner
2010-11-02 20:31 ` Tom Tromey
2010-11-03 13:52 ` Ken Werner
2010-10-04 20:52 ` [patch] GNU vector unop support Ken Werner
2010-10-06 23:27 ` Joel Brobecker
2010-10-07 16:23 ` Ken Werner
2010-11-03 14:07 ` Ken Werner
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=20101004225938.GZ6985@caradoc.them.org \
--to=dan@codesourcery.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=ken@linux.vnet.ibm.com \
--cc=uweigand@de.ibm.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