Mail Archives: djgpp/1995/05/19/14:13:24
>>>>> "Damian" == Damian Frank <damianf AT WPI DOT EDU> writes:
>> If you're looking for a source level debugging environment like
>> CV or Borland C, you'll be dissapointed. GDB provides source
>> code information i.e it will give you the line that a
>> particular section of the assembler corresponds to (this is
>> implicit in the symbol table of the code), but any form of
>> stepping at source level is not available. The GDB does not
>> present itself very well, everything being command line driven
>> (i.e no menus etc..).
Damian> What ARE you talking about? It's quite possible to step
Damian> through code at the source level with GDB - even with
Damian> DJGPP. All you have to do is compile your code with -g,
Damian> and then you can set breakpoints with the break command,
Damian> and then step or trace through with next or trace. GDB is
Damian> quite versatile.
gdb also has the ability to evaluate arbitrarily complicated C
expressions (including function calls), maintain your own debugger
variables, implement loops and if statements (new with gdb 4.14),
write user-defined commands (that can take arguments in 4.14),
establish arbitrarily complex conditional breakpoints, break when
arbitrary C expressions become true, use hardware watchpoints (under
OS's that support them), etc. You can also write scripts for gdb to
execute. I wrote a useful disassembler this way.
Furthermore, if you run gdb under emacs (I'd guess you can't do that
under DOS yet, which is a shame...maybe it works in V2?) it brings up
the file you are stepping through in another emacs buffer and always
marks the current line with an "=>". You can set a breakpoint on code
you are looking at with a few keystrokes.
gdb is incredibly powerful if you know how to use it; it's the best
debugger I've ever seen. Sure, it doesn't pop up little windows with
friendly buttons (unless you are running one of the graphical front
ends under Unix), but who cares?
-Mat
- Raw text -