Re: [patch] fix pre-/post- in-/decrement

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Daniel Jacobowitz wrote:
> 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.

Well, this behavior clearly seems an accident in the current code;
you get this only if the target of the assignment happened to be
a lazy value before value_assign.  For example, while you do get
the extra read after:
   print *$p = 1
you get *no* extra read after:
   print *$p += 1

This seems inconsistent, at the very least.

In any case, I'm wondering a bit why you prefer this behavior; this
seems to have quite unexpected consequences to me:

- If you execute "set *$p = *$q = 0" and the write to *$q fails,
  do you really expect *$p to be set to the old value of *$q
  instead of to 0?

- If *$p is a memory-mapped register where reading and writing have
  different effects, should assigning to *$p really trigger *both*
  a write and a read cycle, even though a C assignment wouldn't?

- In the case you refer to where writing to ROM fails, shouldn't
  we actually get an error thrown anyway?  Writing to an unmapped
  address does that as well ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com