This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] fix pre-/post- in-/decrement
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