Meilleur debuggeur windows

Version imprimable

19/07/2009, 10h52
yan

Meilleur debuggeur windows

Bonjour,
Histoire d'avoir d'autres avis, qu'elle est, pour vous, le meilleur debuggeur sous windows? J'en connait que 2 :
* gdb
* celui de visual (cdb il me semble, ou alors ça fait trois :aie:)

Pour moi c'est celui de visual qui le meilleur sous windows car :
* pas à pas, break points,.. visual est beaucoup plus rapide que gdb.
* visualisation de variable, visual est beaucoup plus puissante que gdb.

Qu'en pensez vous? y as t'il des chose que gdb peut faire et non visual? (et inversement)

:merci: pour votre expérience.
19/07/2009, 10h58
superjaja

Je suis plutot utilisateur du debugger Visual j'ai eu l'occasion d'utiliser gdb sous windows et j'ai trouvé que c'etiat vraiment pas super (Tres lent, on pouvait pas voir le contenu de tout les les types d'objets...). En définitive avec ma petite experience je dirais que le debugger visual sous windows a quand meme une tres tres grosse avance sur gdb...

PS: Yan tu devrais peut etre faire une sondage dans ce poste sur le sujet. ;)
19/07/2009, 13h29
yamashi

Visual aussi puis avec tout les addons qu'on peut trouver, il y en a un très bon qui donne les memory leaks, le fichier, la ligne et meme le nom de la variable qui leak...
19/07/2009, 13h37
buggen25

Bonjour,
J'ai utilisé GDB avec QtCreator, c'est très lent comme debugger, je pense que le debugger GDB est plus adapté à linux, et pour la programmation sans IDE avec kate ou vi.
Cordialement.

ps : meme gdb ne debuggera pas Buggen
19/07/2009, 13h54
r0d

Bonjour,

pour windows, je ne connais rien de mieux que le debugger de visual. Et en fait, je ne pense pas qu'il soit possible de faire mieux: windows reste bien fermé et seuls les developpers de chez microsoft ont accès aux connaissances nécessaires.
19/07/2009, 14h11
yan

Citation:

Envoyé par r0d

Bonjour,

pour windows, je ne connais rien de mieux que le debugger de visual. Et en fait, je ne pense pas qu'il soit possible de faire mieux: windows reste bien fermé et seuls les developpers de chez microsoft ont accès aux connaissances nécessaires.

Je sais pas. Qt ont ajouté un support dans QtCreator qui permet d'afficher correctement le contenu de certaine de leur classe, comme QString. Et ceux pour gdb et cdb.
19/07/2009, 20h29
Mac LAK

En multiprocess, ou lorsque l'on a besoin de breakpoints hardware, il y a aussi WinDbg.... Dans de rares cas, il dépasse en puissance celui de Visual.
19/07/2009, 22h16
yan

Citation:

Envoyé par Mac LAK

En multiprocess, ou lorsque l'on a besoin de breakpoints hardware, il y a aussi WinDbg.... Dans de rares cas, il dépasse en puissance celui de Visual.

ha ok. donc cdb n'est pas celui de visual. Le lien que tu donne, c'est celui que support QtCreator
19/07/2009, 22h23
Mac LAK

Citation:

Envoyé par yan

ha ok. donc cdb n'est pas celui de visual. Le lien que tu donne, c'est celui que support QtCreator

WinDbg est le debugger Microsoft pour (notamment) le mode kernel et le debug d'une machine distante.

Il est moins convivial que celui intégré à Visual, mais permet des choses supplémentaires... Notamment les hardware breakpoints et quelques fioritures de plus sur la gestion des processus.
20/07/2009, 15h08
nicroman

Heu... je croyais que les deux était liés quand même...
D'ailleurs sous visual je debug une machine distante sans problême !

Mais bon... celui de visual est bien pratique... La possibilité de 'customiser' par code son affichage de variables très facile à utiliser (pour afficher l'état des objets par exemple). Le hook immédiat en cas d'exception non gérées...
20/07/2009, 15h25
Mac LAK

Citation:

Envoyé par nicroman

D'ailleurs sous visual je debug une machine distante sans problême !

Oui, une application "normale", en mode utilisateur... Pas quelque chose en mode kernel, pas même en local sur ta machine. De plus, le debugger intégré de Visual (très bien fait, hein, je ne le critique pas !) panique parfois lors du debug simultané de plusieurs processus, alors que WinDbg s'en sort (un peu) mieux.

WinDbg est plus "puissant", mais également un peu plus barbare à utiliser... A réserver quand celui intégré à Visual montre ses limites.
28/07/2009, 20h55
yan

es ce quelqu'un connait la raison de cette différence de puissance entre gdb et les debugger windows?
J'avais entendu un truc comme quoi ca viendrais de la façon dont sont généré les binaires par gcc
28/07/2009, 22h25
Mac LAK

Citation:

Envoyé par yan

es ce quelqu'un connait la raison de cette différence de puissance entre gdb et les debugger windows?

Sûrement le fait qu'il n'est pas vraiment conçu pour Windows... Les systèmes Unix sont axés processus, les systèmes Windows sont axés threads. Mine de rien, ça change pas mal de choses, j'ai déjà vu des portages d'appli Windows "brutaux" sous Linux devenir de vraies bouses à cause des threads, et réciproquement, des applis Linux à base de processus (et de fork(), donc) se comporter minablement sous Windows.

Citation:

Envoyé par yan

J'avais entendu un truc comme quoi ca viendrais de la façon dont sont généré les binaires par gcc

Sous Windows, ça revient au même : c'est un exécutable au format PE, c'est le système d'exploitation qui décide du format à utiliser, pas le compilateur.
28/07/2009, 22h40
jabbounet

tout dépend du compilateur et de ton environnement de dev que tu vas utiliser je pense.

effectivement si tu fait tes dev sous visual studio celui de windows sera très probablement mieux.

maintenant si tu développe avec mingw (gcc) par exemple il vaudrait mieux utiliser gdb.

concernant gdb il existe s'intègre bien dans tout un paquet d'ide et d'éditeurs open source.
30/07/2009, 08h10
white_tentacle

Citation:

des portages d'appli Windows "brutaux" sous Linux devenir de vraies bouses à cause des threads, et réciproquement, des applis Linux à base de processus (et de fork(), donc) se comporter minablement sous Windows

C'est vieux, ça, non ? Depuis la glibc 2.6 et nptl, linux est très efficace sur la création de threads.

Sinon, pour windows, windbg est le must, mais effectivement, très complexe à prendre en oeuvre (et aussi, un peu buggé parfois).

Par contre, il me semble que gcc et visual génèrent les symboles différemment, autrement dit, si tu compiles avec gcc, tu es contraint à gdb, et avec visual, contraint à visual ou windbg.
30/07/2009, 11h40
Mac LAK

Citation:

Envoyé par white_tentacle

C'est vieux, ça, non ? Depuis la glibc 2.6 et nptl, linux est très efficace sur la création de threads.

Moins mauvais plutôt, je dirais... Je trouve toujours, pour l'instant, que le scheduling sous Windows est bien plus efficace que celui sous Linux au niveau threads, notamment en ce qui concerne les changements de contextes sur les changements d'état des objets de synchro.

Citation:

Envoyé par white_tentacle

Sinon, pour windows, windbg est le must, mais effectivement, très complexe à prendre en oeuvre (et aussi, un peu buggé parfois).

Il est en effet "brut de décoffrage".

Citation:

Envoyé par white_tentacle

Par contre, il me semble que gcc et visual génèrent les symboles différemment, autrement dit, si tu compiles avec gcc, tu es contraint à gdb, et avec visual, contraint à visual ou windbg.

Je crois qu'il existe une option pour permettre d'utiliser WinDbg quand même, mais c'est sous réserve... J'ai vu passer sur je ne sais plus quel compilateur Windows la possibilité de créer les symboles suivant plusieurs formats.