This is the mail archive of the gdb-patches@sourceware.org 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


On Tuesday, October 05, 2010 17:42:01 you wrote:
> On Tue, Oct 05, 2010 at 03:28:19PM +0200, Ulrich Weigand wrote:
> > Daniel Jacobowitz wrote:
> > > On Tue, Oct 05, 2010 at 01:24:51AM +0200, Ulrich Weigand wrote:
> > > > - 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".
> > 
> > The thing is, I had interpreted the C standard to read that even if
> > pointers p and q *are* volatile, a statement like "*p = *q = 0" would
> > still just trigger two writes, and no reads.
> 
> You're right, I remember Nathan's recent arguments about this on
> gcc-patches.
> 
> > "Assignments are also expressions and have an rvalue. However when
> > assigning to a scalar volatile, the volatile object is not reread,
> > regardless of whether the assignment expression's rvalue is used or not.
> > If the assignment's rvalue is used, the value is that assigned to the
> > volatile object. [...]  If you need to read the volatile object after an
> > assignment has occurred, you must use a separate expression with an
> > intervening sequence point."
> > 
> > To reduce the potential for confusion, it seems to me GDB ought to mirror
> > that behavior as well ...
> 
> Hmm.
> 
> It seems to me that this is a disruptive change for us, because the "a
> = b" case is more likely to be used than anything fancy (a += b, a = b
> = c).  If we change it, we should document the change.
> 
> Vladimir, would this interact with your recent varobj changes?  We
> worked out exactly which reads we wanted, but I don't remember if
> value_assign is involved.

I don't think value_assign was involved in my changes -- instead, I have
modified varobj_set_value to do a read-back of the value being assigned
to. 

I am not entirely sure whether on CLI, one wants:

	print $io.whatever = 10

to print '10' or the value in $io.whatever. Maybe, following C rules has
some sense here. On the other hand, in GUI there's no assignment
expression, so C standard is probably not a useful analogue.
So, I guess this patch is compatible with our changes.

- Volodya


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