Discussion :

[yan]

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 )

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)


pour votre expérience.

[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.

[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...

[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

[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.

[yan]

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.

[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.

[yan]

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

[Mac LAK]

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.

[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...

[Mac LAK]

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.

[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

[Mac LAK]

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.

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.

[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.

[white_tentacle]

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.

[Mac LAK]

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.

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".

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.