From:	root AT jacob DOT remcomp DOT fr (root)
Subject:	gdb
12 Oct 1998 10:58:53 -0700 :
Message-ID:	<m0zSSij-0002fdC.cygnus.gnu-win32@jacob.remcomp.fr>
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 <GetInitializationData+373>:   cmpl   $0x1,%eax
0x452568 <GetInitializationData+376>:
    jne    0x452571 <GetInitializationData+385>
---Type <return> to continue, or q <return> to quit---

Beware of typing q <return>... 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 <nexti> 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".

- Raw text -