Re: [Valgrind-developers] Test results, 10 Dec 2002

[Jeremy F. <je...@go...>]

On Tue, 2002-12-10 at 15:35, Julian Seward wrote:
> However, backing out 69- makes it work properly.

Very mysterious.

> So I'm still mystified.  One unedifying explaination is that this translation
> is correct, and the reason it is looping is that some earlier translation has
> written bogus values into memory, which the above loop is picking up and
> looping on.  I don't fancy chasing that down.

Since the only code which cares about flags are the last two
instructions, and they look correct to me, it must be the data they're
operating on...

> I'm going to back out 69- from cvs until we have a clearer picture what's
> going on.  Do shout if you have any ideas at all.  It makes me uneasy that
> I don't know what's going on here.

So, this only happens with Mozilla on RH6.2, compiled with some version
of egcs?  Can you reproduce anything similar with other egcs-generated
code?

> > One possibility I've been thinking about is whether there's any code
> > which depends on the undefined flags behaviour of instructions.  It
> > would be a (compiler?) bug, but it might change the behaviour of real
> > programs.
> 
> Um, that's not good.  Should I be concerned?

Dunno.  It's easy to fix: just add a line into VG_(new_emit)() saying
something like:
	if (set_flags != FlagsEmpty)
		maybe_emit_get_flags();
which would always make sure that if anyone sets the flags, they start
with the simulated flags state in the CPU.

A lot of the arithmetic instructions have an undefined effect on some
set of flags. I interpret that as being the same as setting them (that
is to say, no correct program can rely on them being unchanged by the
instruction, so don't bother to preserve their values).  It may be that
some code "knows" that undefined actually means unchanged, and relies on
that behaviour.  In which case the conservative thing for us to do is
treat undefined as meaning unchanged, and emit considerably more flags
fetches (which basically punts the problem to
Intel/AMD/Via/Transmeta/etc, because the CPU still has to have an
interpretation of what undefined actually means; there's probably a lot
of lore about the detailed behaviour of the instructions which goes way
beyond their formal description in Vol2).

I'm not saying it has any bearing on the present problem, but it would
be an interesting experiment to try.

> Umm, I'm not sure what you mean by good.  Memcheck is probably the most
> demanding in that nearly every original ucode is preceded by instrumentation
> which very likely trashes (real) eflags.  Is that what you meant?
> 
> If there's some way in which you could hack a skin to do a
> stress-test of your flags machinery, that would be very helpful.

Yes.  I might put together a testbed skin.

BTW, I'm having a go at implementing your addrcheck cache idea.  It
isn't working out quite as well as I'd like.

	J