[Kos-dev] Quelques idées

[d2]

Hello,

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@enix.org> writes:
    Thomas>  * Est-il possible d'utiliser un truc genre Valgrind [1]
    Thomas> pour KOS ? Je me fais souvent avoir par des données non
    Thomas> initialisées, et je pense que ça serait une bonne idée
    Thomas> d'avoir un truc qui peut vérifier ça de manière
    Thomas> systématique. Je ne sais pas comment ça peut marcher, peut
    Thomas> être en plugin pour bochs ?

Utiliser une machine virtuelle pour detecter les acces aux variables
non initialisees dans une machine virtuelle ? Mouf, c'est un peu de
l'empilage violent je trouve. Vaudrait mieux inserer un plugin pour
bochs qui se contente de rajouter une bitmap des adresses physiques,
par defaut toutes positionnees a 0 (non ecrites), puis de
court-circuiter les acces memoire (doit bien y avoir un mem.cc) pour
mettre le bitmap a jour a chaque write, et verifier que le bit
correspondant est a 1 a chaque read (c'est ce que fait valgrind, mais
lui le fait au niveau du bit, pas de l'octet).

    Thomas> à chaque retour de fonction (avant le 'ret'). A chaque
    Thomas> fois, on récupère le compteur de cycles, et hop à partir
    Thomas> de là, on peut faire quelque chose de précis. Quelqu'un
    Thomas> a-t-il une idée pourquoi ce n'est pas fait comme ça ?
    Thomas> Y-a-t-il un obstacle technique pour implémenter ma
    Thomas> proposition ?

gcc -finstrument-functions

    Thomas>  * Avoir un truc pour détecter les fuites de mémoire :
    Thomas> l'OS est petit pour l'instant, ça serait intéressant de
    Thomas> pouvoir tester si des scénarios du type : construction
    Thomas> team construction thread desctruction thread destruction
    Thomas> team engendrent des fuites mémoires.

Tu veux parler des slab ? Car a priori pour les demandes de pages
physiques y'a pas de pb (mappees en VM => on a la liste => on sait
quoi desallouer a la fin de la team). Le principe est toujours le meme
(maintenir une liste ou une hash des objets alloues/supprimes), la
difficulte est que maintenir cette liste necessite des appels a de
l'alloc/liberation (danger oeuf/poule). Faudrait voir, mais ca peut
peut-etre se faire plus simplement en associant a chaque objet du slab
un identifiant (pas un pointeur ! il faut que ca soit persistant apres
la mort du team) vers le team proprietaire (suffirait de parcourir les
slabs pour recuperer les objets qui correspondent a des teams morts) =>
pas de mecanisme parallele (tout integre dans slab).

Bonne journee,

-- 
d2