[Kos-misc] Waouh...

d2 David.Decotigny@irisa.fr
01 Mar 2002 17:38:53 +0100


Bonjour,

Alors la, calmé. Je suis calmé :
   http://developer.kde.org/~sewardj/docs/manual.html#howitworks

Il s'agit d'un detecteur d'acces memoires invalides ou non initialises
pour processus user normal, sous Linux/x86. Un joujou classique,
quoi. Mais il y a un truc (central) en plus...

« The JITter translates basic blocks -- blocks of straight-line-code
  -- as single entities. To minimise the considerable difficulties of
  dealing with the x86 instruction set, x86 instructions are first
  translated to a RISC-like intermediate code, similar to sparc code,
  but with an infinite number of virtual integer registers. Initially
  each insn is translated seperately, and there is no attempt at
  instrumentation.

  The intermediate code is improved, mostly so as to try and cache the
  simulated machine's registers in the real machine's registers over
  several simulated instructions. This is often very effective. Also,
  we try to remove redundant updates of the simulated machines's
  condition-code register.

  [...]

  Then, and only then, is the final x86 code emitted. The intermediate
  code is carefully designed so that x86 code can be generated from it
  without need for spare registers or other inconveniences. »

Et le gars il te pond ca en 30 fichiers. Les p'tits gars de bochs ont
qu'a bien se tenir...

A la base, c'est pourtant pas complique le truc : un purify, eletric
fence, ou dmalloc de plus. A la base, rien de
revolutionnaire. Seulement voila, le truc va un pas plus loin : il
detecte toutes les operations "not initalised", meme ca :

  for (i = 0; i < 10; i++) {
    j += a[i];
  }
  if (j == 77)
     printf("hello there\n");  

Pour le "if (j == 77)", il voit qu'on accede aux bits 4..31 qui n'ont
jamais ete initialises dans j, et donc signale une erreur !

Bref, je suis calmé. Je pige toujours pas pourquoi il a eu besoin de
faire son JIT + instrumentation + re-JIT-a-l'envers, mais je suis
calmé. On doit bien pouvoir verrouiller l'espace processus "normal"
(ie tout sauf la bibliotheque valgrind) en PROT_NONE, et recuperer
tous les acces memoire et verifier a la granularite du bit (plutot que
de l'octet ou du mot comme c'est fait habituellement), non ? Ie on
doit toujours puvoir continuer d'utiliser le processeur "normal" et
derouter (presque : sauf ceux du handler de SEGV) tous les acces
memoire pour les verifier, non ? Je vois qu'une explication : il
voulait surement que le processus normal ne voit pas son
instrumentation, jamais, et etre sur qu'il n'empiete jamais sur la
zone reservee au suivi de l'instrumentation. Ca doit etre ca, mais
c'est violent. Juste tres bien compense par un JIT de folie.

Bonne journee,

-- 
d2