This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 ...


  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]