[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] Program flow problems when including stdlib.h
From: |
Joerg Wunsch |
Subject: |
Re: [avr-gcc-list] Program flow problems when including stdlib.h |
Date: |
Fri, 28 Mar 2003 10:43:51 +0100 (MET) |
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/