Le 30/07/2025 à 15:06, Basile Starynkevitch a écrit :
Bonjour la liste,
Sur un Debian/Linux/x86-64 (Trixie) j'ai
gdb --version
GNU gdb (Debian 16.3-1) 16.3
que j'utilise sur RefPerSys (un moteur d'inférences libres, sur github, en C++)
compilé par GCC 15
J'utilise souvent la commande watch de GDB, en sachant empiriquement:
1. watch marche bien pour 4 watchpoints sur des mots de 64 bits (alignés sur 8
octets), et cette limite de 4 watchpoints est dûe au matériel: les "debug
registers" DR0 à DR3 de
https://wiki.osdev.org/CPU_Registers_x86-64#Debug_Registers
(c'est d'ailleurs un peu dommage qu'avec un milliard de transistors sur un
processeur récent, Intel ou AMD n'en aient pas rajouté d'autres)
2. probablement un unique watch sur une structure de 4 mots de 64 bits serait
traduit (par GDB) en les 4 watchpoints élémentaires.
Dans de rares cas j'ai besoin de faire un watch sur une structure un peu plus
grosse (disons 16 mots de 64 bits).
Dans ces cas, le débogueur est considérablement ralenti. L'intuition est un
facteur x100 à x1000 plus lent. C'est désagréable et surprenant.
Avez vous des conseils pratiques à me donner pour accélérer ce déboguage?
Merci
NB. Peut-être qu'une solution pourrait être d'adopter une machine virtuelle
octet (bytecode, comme Ocaml ou JVM savent faire) et de compiler mon RefPerSys
vers cette machine virtuelle. Existe-t-il des machines virtuelles libres et
compatibles avec un compilateur croisé GCC 15? En théorie une telle approche
verrait un ralentissement d'un facteur x20 et pas x100 ou x1000.
https://fr.wikipedia.org/wiki/Emscripten peut-être?
Bonjour Basile,
avertissement: mes compétences sur le sujet se rapprochant
dangereusement de zéro, je t'encourage à mettre en doute ce qui suit :-)
- pour une machine virtuelle bytecode, je suis peut-être à côté de la
plaque mais je suppose qu'il n'y a pas d'avantage à retirer concernant
la rapidité de surveillance des points d'arrêt, les seuls registres de
débogage disponibles restant ceux du matériel sous-jacent. Donc le
ralentissement dû à la bascule par GDB vers des points d'arrêt logiciels
au lieu de matériels resterait peu ou prou identique? (si j'ai compris
correctement le morceau de doc GDB que j'ai parcouru)
- Je ne sais pas si ça existe (ni si ce qui suit n'est pas une grosse
bêtise) mais à supposer qu'une architecture matérielle couverte par
Debian possède un nombre de registres de débogage plus élevé que celui
de l'architecture amd64, ça vaudrait peut-être le coup de
cross-compiler/cross-debugger
- A supposer que le bytecode puisse apporter un avantage quelconque,
j'ai entendu dire que la compilation LLVM l'utilise de manière
intermédiaire, donc peut-être que LDB (je ne sais plus si c'est ça le
nom du debugger attitré de LLVM) pourrait en tirer parti. A supposer
aussi que changer, au moins temporairement, GCC pour LLVM, soit
envisageable pour toi vu que c'est de la compilation dynamique...
Désolé du niveau de mon intervention: j'y connais rien :-)
