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

[Daniel Jacobowitz <dan at codesourcery dot com>]

On Tue, Oct 05, 2010 at 01:24:51AM +0200, Ulrich Weigand wrote:
> 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.

Yes, yes it is.  I was not aware of this.  I think Vladimir has also
fixed some bugs in this area for varobjs; I don't know if that was
posted yet.

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

Yes, I would expect that.  To me, this is roughly "the debugger treats
all pointers as volatile".

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

If you say "print", yes.  If you don't want this behavior - often I
don't - then use set.

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

Well, possibly.  It depends on the system.  It's very useful to be
able to use GDB to generate bus cycles.  And, for instance, I
sometimes use GDB to poke at a flash device; it's programmable, but
not in the straightforward write-to-memory way that RAM is.

-- 
Daniel Jacobowitz
CodeSourcery