Re: [avr-gcc-list] Program flow problems when including stdlib.h

[Joerg Wunsch]

Wallace White <address@hidden> wrote:

> I took a look at the gdb and AVaRICE docs. It sounds like they do
> not offer some of the conveniences of AVR Studio, like windows for
> watch, processor, code, etc. So I'd like to continue to use the AVR
> Studio for debugging. Is this possible--or advisable?

Should be possible, but it's IMHO not advisable.  If you've got the
JTAG ICE anyway, if i were you, i'd use GDB.  The COFF debugging
information is /way/ inferior compared to what ELF + stabs are
delivering.  In particular, your mentioned problem might fall into
this category: COFF debugging cannot handle included files.  If one of
your include files is contributing code (e. g. from an inlined
function), you're completely at a loss with COFF.  Also, our current
toolchain (i. e., objtool) is not exactly doing a perfect job in the
ELF + stabs -> COFF translation, so that might cause additional
problems.

OTOH, handling GDB is certainly not what everbody would like to do.
It's as with many other of the Unix tools: it does a very powerful
job.  I have yet to see another debugger where i can say:

set $p = (my very twisted type *)0xf00;
disp $p->some field of my twisted type

i. e. where i can /force/ the debugger into interpreting a particular
memory location using a type of my very own choice, store that in a
variable that is internal to the debugger, and use it in a reference
display on each step/breakpoint.  That's only one example, there are
many other things.

But then, there are a number of graphical frontends to GDB.  Maybe one
of them would be fine for you?  I never used some of them myself
though, so maybe others could recommend.
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/