Re: Gros watchpoint dans GDB 16.3

[didier gaumet <didier.gaumet@gmail.com>]

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 :-)