This is the mail archive of the
cygwin@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: gdb
- To: gnu-win32 at cygnus dot com
- Subject: Re: gdb
- From: cgf at cygnus dot com (Christopher G. Faylor)
- Date: 13 Oct 1998 19:52:15 GMT
- Newsgroups: cygnus.gnu-win32
- Organization: Cygnus Solutions
- References: <m0zSSij-0002fdC.cygnus.gnu-win32@jacob.remcomp.fr>
- Stamped: newsgate-cygnus
In article <m0zSSij-0002fdC.cygnus.gnu-win32@jacob.remcomp.fr>,
root <root@jacob.remcomp.fr> wrote:
>gdb gdb...
>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.
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 <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.
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@cygnus.com
http://www.cygnus.com/
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".