From: root AT jacob DOT remcomp DOT fr (root) Subject: gdb 12 Oct 1998 10:58:53 -0700 Message-ID: Content-Type: text To: gnu-win32 AT cygnus DOT com gdb gdb... I have some problems with this software. 1) When I issue the disassemble command, it will disassemble a bit and then tells me: 0x452565 : cmpl $0x1,%eax 0x452568 : jne 0x452571 ---Type to continue, or q to quit--- Beware of typing q ... It will crash immediately. Has anyone else experienced this bug? I am debugging a windows program. 2) When I set a breakpoint in some callback function, gdb will crash. Using another debugger, I have been able to see that the crash is in the assembler procedure of gdb: movl 4(%esp),%eax ;;put first argument in eax movl (%eax),%eax ;; dereference it and return ret For me it is obvious what gdb is trying to do: following the ebp chain, and dereferencing the stack frames. What is astounding is the total lack of error checking!!! In a debugger, when following the ebp chain, it should be obvious that ebp can't be followed like THAT!!! A little checking there would allow gdb to issue its famous: corrupted stack instead of plainly crashing me in the face!!! Well, it doesn't matter. With the other debugger I just set the EIP to the ret instruction, returning NULL. This works, and gdb continues to run... Result: When using gdb, its not a bad idea to have another debugger around :-( 3) gdb is unable to follow the stack when there is a trap in a system call. I have developed recently an algorithm for doing this. It wouldn't be a bad idea if gdb would improve this situation. It is not at all that difficult. 4) The command line interface is... well forget it. 5) It is difficult to follow the program execution at the assembly level. The command works, but instead of showing me the assembly instruction that will be executed, it insists in showing me the source line... So I am blind as to what the hell the machine is doing. 6) You can't set a breakpoint when the program is running. In general, gdb is freezed when the program is running. Now, doing this is not specially difficult: you just stop the running thread, set the breakpoint, and then you resume... not rocket science really. 7) There is no way to stop the program. The 'kill' command is kind of useless, since you can't type anything into gdb unless the program is stopped!!! Gdb reminds me of those days when I used the "debug" command line debugger from MS-DOS. Now I understand better this lines: (I quote 'gdb'): For non customers, gdb has NO WARRANTY. The entire risk as to the quality and performance of the software is with you. That's very clear. -- Jacob Navia Logiciels/Informatique 41 rue Maurice Ravel Tel 01 48.23.51.44 93430 Villetaneuse Fax 01 48.23.95.39 France - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".