Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Mode debug
Ce serait pour savoir si le processeur intel offre la possibilité à un logiciel
de démarrer en mode PAS à PAS (mode debuggage) une session vm86 ?
Une session vm86 (session wmware-machine virtuel) est en sorte un thread mais ce thread est t'il compter dans le gestionnaire de tache "taskmgr.exe (onglet performance)" ou s'agit t'il d'un thread
du noyau qui n'est pas vu par le gestionnaire de tache ?
Merci
le mode debuggage n'est pas lié au type de processeur
tout soft de debuggage est capable d'executer n'importequel soft en mode pas à pas pour le type de proco concerné
il faut quand même que le processeur autorise un mode debug, avec génération d'une interruption à chaque instruction. En ce sens le debugging est directement lié au fonctionnement du processeur... a moins que le debugger fasse une émulation du processeur...Envoyé par vi4ever
VB
je ne connais pas de debugger qui ne fasse pas l'emulation puisque si l'emulation n'est pas faite alors le proco execute des "bouts de code" qui ne sont pas surs c'est d'ailleurs pour ça qu'on debug et donc risque de plantages.... donc tout debugger ne travaillant pas en emulation est aussi risqué que d'executer l'appli sans la debugger bref ça n'a aucun interet et alors son existance meme est discutable....
ha bon ! moi je ne connais que ca sous x86 ! exemple : les debugger de Microsoft, VC++, Borland C, Borland Pascal, même Numega SoftIce ne sont pas des émulateur et travaillent directement avec le mode debug du processeur...
notez que le mode protégé permet de débugger une appli en toute sécurité (ou presque). J'ai rarement planté un Win2000 en debuggant sous VC par exemple, et je fais des trucs très méchant :-))
VB
oui c'est bien ce que je dis que des produits de daube VC (respecte pas les normes C/C++) produits borlands c'est deja mieux mais c'est pas encore ça...ha bon ! moi je ne connais que ca sous x86 ! exemple : les debugger de Microsoft, VC++, Borland C, Borland Pascal, même Numega SoftIce ne sont pas des émulateur et travaillent directement avec le mode debug du processeur...
notez que le mode protégé permet de débugger une appli en toute sécurité (ou presque). J'ai rarement planté un Win2000 en debuggant sous VC par exemple, et je fais des trucs très méchant :-))
VB
bref encore une fois on voit la difference entre les environnements demi-kro$oft et les autres que ce soit unix, linux, bsd, beOS, plan9, vms, tandem etc....etc...
hum, hum... sous ses systèmes, vous trouverez aussi des debugger qui utilisent le processeur x86 de la même manière que sous system microsoft :-)... Faire un émulateur n'est pas facile, et surtout ne permet pas de débugger de manière fiable... j'en ai utilisé dans la programmation de DSP, mais c'était pour dépanner, quand on veux faire une vrai session de debug on le faisait aussi en direct, en utilisant les service du DSP...
Bref, disons le franchement, J'ai comme l'impression que vous vous fourvoyez mon cher, profitez donc de cet hiver pour mettre de l'ordre dans votre boite cranienne ! :-).
VB
non pas du tout je ne fait que dire la verité et comme deja dit le mode protegé n'est pas une bonne solution puisque ce n'est pas le même code qui est executé.
mais des bouts de codes avec interruptions spéciales....
Wow ! ca c'est chouette ! d'un autre côté ca doit être un peu contraignant, toujours dire la vérité c'est difficile non !?
En tout cas, je vous dis bravo, et je vous laisse, car je ne discute pas avec les gens qui dise que la vérité, je n'en suis pas digne. :-)
VB
Bonjour,
La doc de SoftIce explique comment s'effectue le débogage en x86 (et la doc Intel confirme).
Il existe (depuis le 386 j'imagine?) 4 registres recevant chacun une adresse linéaire qui est celle d'un BP. En fait, il existe un "système debug" qui autorise 4 BPs hard simultanés. Ça veut dire 4 BPs dont on ignore l'ordre d'apparition, ce qui signifie qu'on doit pouvoir en gérér un peu plus si on connaît des contraintes sur cet ordre, mais il y a un limite vite atteinte.
Il existe également sur les versions récentes la possibilité de générer une exception sur tel ou tel évènement et certainement d'autres facilités qui m'ont échappé.
Il y a ensuite deux possibilités qui sauf erreur de ma part datent du début de x86:
- le mode pas à pas (positionnement d'un flag). Chaque instruction déclenche l'int0. La gestion du flag est automatique, ce qui permet que le code du débogueur se déroule normalement.
- l'interruption logicielle int3. Elle est placée en tant que BP. Elle est codée sur 1 octet, donc elle peut être placée n'importe où.
Tout ça, ce sont des possibilités gérables sur un machine qui fonctionne normalement, avec un OS et tout le bataclan. Il existe également des possibilités à plus bas niveau, mettant en oeuvre certaines pattes du processeur.
--
Pierre
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager