Category Archives: Uncategorized

On i386, Nanojit has two basic modes of operation:  SSE, and non-SSE.  Non-SSE is for old machines that don’t support SSE instructions.  (It might actually be SSE2 instructions, I’m not sure.)  My two machines both support SSE and so the non-SSE is never exercised unless I specify the environment variable X86_FORCE_SSE=no.  Since this invocation doesn’t exactly roll off the fingertips, I don’t do it often.  It’s also easy to mistype, in which case the normal SSE code will be run but I probably won’t notice and so I’m testing something different to what I think I am testing.

I recently committed a patch (bug 516348) that broke the non-SSE mode.  (It may have also broken the SSE mode, but in a less obvious way.)  Whenever I land a patch that breaks something, I try to work out if I could have avoided the breakage through a better process.  In this case I could have, through automation.  I now have the following set of aliases and functions in my .bashrc:

alias jstt_prefix="python trace-test/trace-test.py"
JSTTARGS32="--no-slow -f -x sunspider/check-date-format-tofte.js"
JSTTARGS64="$JSTTARGS32"

alias jsdtt32="                   jstt_prefix debug32/js $JSTTARGS32"
alias jsott32="                   jstt_prefix opt32/js   $JSTTARGS32"
alias jsdtt32b="X86_FORCE_SSE2=no jstt_prefix debug32/js $JSTTARGS32"
alias jsott32b="X86_FORCE_SSE2=no jstt_prefix opt32/js   $JSTTARGS32"
alias jsott64="                   jstt_prefix opt64/js   $JSTTARGS64"
alias jsdtt64="                   jstt_prefix debug64/js $JSTTARGS64"

function jsatt
{
  if [ -d debug32 ] && [ -d debug64 ] && [ -d opt32 ] && [ -d opt64 ] ; then
    cd debug32 && mq && cd .. && \
    cd debug64 && mq && cd .. && \
    cd opt32 && mq && cd .. && \
    cd opt64 && mq && cd ..

    if [ $? -eq 0 ] ; then
      echo
      echo "debug32"          && jsdtt32   && echo
      echo "debug32 (no SSE)" && jsdtt32b  && echo
      echo "debug64"          && jsdtt64   && echo
      echo "opt32"            && jsott32   && echo
      echo "opt32 (no SSE)"   && jsott32b  && echo
      echo "opt64"            && jsott64   && echo
    fi
  else
    echo "missing one of debug32/debug64/opt32/opt64"
  fi
}

The code is boring.  For those reading closely, it relies on the fact that I always put different builds in the directories debug32/, opt32/, debug64/, opt64/.  And I skip check-data-format-tofte.js because it fails if you’re in a non-US timezone, see bug 515214.

I already had ‘jsdtt32′ et al, each of which tests a single configuration.  But now with a single command ‘jsatt’ (which is short for “JavaScript All trace-tests”) I can run the JS trace-tests on 6 different configurations on a single x86-64 machine: 32-bit debug (SSE), 32-bit debug (non-SSE), 64-bit debug, 32-bit optimised (SSE), 32-bit optimised (non-SSE), 64-bit optimised.  And it builds them to make sure they’re all up-to-date.

It’s only a small process change for me, but it means that it’s unlikely I will break any of these configurations in the future, or at least, not in a way that shows up in the trace-tests.

With the Valgrind-on-Mac support coming along nicely, it’s worth addressing another widely-used platform:  Windows.  Will Valgrind work on Windows any time soon?  There are actually two answers:  (a) hell no, and (b) it already does (sort of).

The patch I merged from the Darwin branch onto the trunk yesterday was 28,300 lines.  And that was almost entirely new code, because I’d done a lot of work to synchronize the branch and trunk so that all non-addition changes had been dealt with.  Greg Parker spent over four years, off and on, working on the original port, and I spent close to three months full time cleaning it up, and Julian Seward also pitched in a bit.  I roughly estimate the Darwin port represents at least 1,000 person-hours of work, possibly much more.

And Mac OS X is a lot closer to Linux than Windows is.  Also, the Mac OS X kernel is open source, which makes a port much easier.  A Valgrind-on-Windows port would therefore be an enormous undertaking, one that is unlikely to happen soon, if ever.  That is how we get answer (a) above.

However, although Valgrind doesn’t run on Windows, it is possible to run Windows programs under Valgrind, thanks to Wine — you run the Windows program under Wine, and Wine under Valgrind.  The development (trunk) versions of both Valgrind and Wine now have enough awareness of each other that they can apparently be used together.  I say “apparently” because I haven’t tried it myself, but I know that others have had some success.  But please note that this is fairly new and experimental, and should only be tried by those not afraid to get their hands dirty (this page has more details). And that’s how we get the answer (b) above.

You gotta start somewhere.

Update (Jan 19): Hmm, I wasn’t expecting this post to make it onto Planet Mozilla, as I wrote it two days before I requested that my blog be syndicated.  Well, at least it didn’t take you long to read