(anomaly) Re: [Valgrind-developers] lazy eflags seems to work now

[Julian S. <js...@ac...>]

> > Hmm.  This is very odd.  I'm wondering if there is some problem with the
> > non-D flags (OSZACP) causing "if (res > 0) {" at line 2636 never to
> > get into the then-clause.  Except that if there was such a problem,
> > most programs wouldn't work (I'd guess).
>
> I think that's a red herring. 

I agree.

Re my analysis of stack-clearing add, I can't be exactly right, since
VG_(emit_add_lit_to_esp) begins with the correct call to new_emit.

So perhaps the analysis didn't think that we were in a UPD_Real state
at the point of the call to vgPlain_helper_SAHF.  Except that as soon as 
it has CLEARed the stack, it then acts to get into UPD_Simd/Both in
preparation for the conditional jump:

1: x/i $eip  0x42377bd2:        pushf  
1: x/i $eip  0x42377bd3:        popl   0x20(%ebp)

Odd.


> In OO's case, thread 3 is polling on IO
> (I presume to the X server), thread 2 is blocked in a condvar_wait, and
> thread 1 is spinning CPU-bound.  I'm guessing that thread 2 is waiting
> for either thread 1 or 3 to do something, and thread 1 is expected to do
> something but isn't.

Yes, so that fits together; at least we have a plausible explaination of
why it was spinning, if the moz problem also afflicts OO.

J