Re: [Valgrind-developers] Valgrind with Linux 2.5 (and status with Nvidia drivers?)

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

>  I did see a problem though.  I get this if I try to start OO under V in
> 2.5:
>
> ==15504== Nulgrind, a binary JIT-compiler for x86-linux.
> ==15504== Copyright (C) 2002, and GNU GPL'd, by Nicholas Nethercote.
> ==15504== Using valgrind-1.9.1, a program instrumentation system for
> x86-linux. ==15504== Copyright (C) 2000-2002, and GNU GPL'd, by Julian
> Seward. ==15504== Estimated CPU clock rate is 1848 MHz
> ==15504== For more details, rerun with: -v
> ==15504==
>
> valgrind: vg_scheduler.c:475 (vgPlain_save_thread_state): Assertion
> `(void*)vgPlain_threads[tid].ldt == (void*)vgPlain_baseBlock[vgOff_ldt]'
> failed.

Urr.  What distro are you running (== what infrastructure do I need in order
to run with a 2.5 kernel?)


> > My vague and half-baked plan was to figure out a minimal extension to
> > ucode which would allow MMX (MMX, not SSE* or 3DNow!) insns to be
> > expressed. I would add GETMMX/PUTMMX to copy a MMX reg to/from a pair of
> > TempRegs, and then there is the question of the minimal set of extra uops
> > needed to support the packed add/shuffle/etc, whatever that is needed. 
> > If you want to occupy your feverish imagination considering this, that
> > would be cool; I'd like to ship MMX support if possible.  It's going to
> > have to happen sometime, and the lack of it is more and more a problem.
>
> I think a good first step would be to parse the MMX/SSE/3Dnow
> instructions just enough to be able to skip them, and emit illegal
> instructions.  That way the executing binary will behave more like a
> pre-MMX P5, and apps which want to see SIGILLs will get them.
>
> Actually emulating the instructions is much harder.  I think we're going
> to get more bang-for-effort from improving flag handling at the moment.

Well, I'd like to deliver the MMX functionality, even if the result is slow.

You'll see I just committed a simple hack which seems to substantially
mitigate the INCEIP thing; it's a combination of your partial-write idea
and my always-write-never-add idea.

Unfortunately failed to mention in the commit message that an intended
side effect of the change is that INCEIPs no longer change the host condition
codes, so that lazy eflags updating, which I think will be helpful, is 
assisted.  I'm contemplating doing a thing similar to your lazy FPU
save/restore.  Except it needs to be a marginally cleverer; instead of saying
simply "the most recent %EFLAGS state is in memory or in the host %eflags",
it is helpful to distinguish three cases: most recent in memory, most recent 
in %eflags, and both of the above (%flags == memory value).  This 3rd
option allows copy-backs to be NOPd if %eflags hasn't changed.  

(think: %eflags is a write-back cache for %EFLAGS, so it's useful to have
a dirty bit).

J