From: cgf AT cygnus DOT com (Christopher G. Faylor) Subject: Re: gdb 13 Oct 1998 19:52:15 GMT Message-ID: <700b1f$drq$1@cronkite.cygnus.com> References: X-Newsreader: trn 4.0-test63 (15 March 1998) In article , root wrote: >gdb gdb... >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. I Haven't experienced this. >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. Enlightenment would be gratefully accepted. >4) The command line interface is... well forget it. I use the command line interface routinely without problem. If you have a specific complaint let's hear 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. display /i $pc >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. Not sure what you want here. Do you want to be able to stop the running program with CTRL-C maybe? >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. Patches to correct this behavior would be gratefully accepted. -- cgf AT cygnus DOT com http://www.cygnus.com/