Re: [avr-gcc-list] avr-gdb use

[Joerg Wunsch]

Levente Kovacs <address@hidden> wrote:

> I'd like to read the following things:
> 
> * IO block of the device

There's currently no symbolic method for that (ideas what/how to add
the respective debugging information to the symbol table are welcome),
so you have to examine them manually, like:

x/bx 0x800039
print (char *)0x800039

to read back the value of the PINA register (SRAM memory address 0x39
+ 0x800000 offset to indicate SRAM rather than flash ROM).

> in particular the SP register

The stack pointer and PC are special, in that GDB always reads those
back from the target when stopping, so you can access it as

print $SP

> * The registers r0...r31

info reg
print $r0

> * RAM content. Memory dump,

x/32bx 0x800000 (SRAM)
x/32bx 0 (flash ROM)

> and variable watch.

What is "watch" in your opinion?  If you're following the GDB
terminology, it means to stop the program whenever the value of some
memory location changes.  This is done with the "watch" command,
however hardware watchpoint support in the AVR JTAG ICE doesn't allow
you to watch all memory ranges. (*) It's always possible to watch a
byte address, but for larger ranges, the address range must be
expressable as baseaddress + mask, where the mask's digits at
baseaddress must be 0.  Since the AVR architecture itself doesn't
require memory alignment, the compiler would normally not arrange that
for you.

If you think of "watch" in AVR Studio's terminology, this is
equivalent to GDB's "display" command.

Normally, you'd just use the "print" command though, which accepts
arbitrary C language expressions, including access to all variables
that are in scope for the currently visited stackframe(**), and
including C typecast access to arbitrary memory locations.  So a
print statement like this one is completely possible in GDB:

print *(struct cdata_priv *)(listptr->data)

(*) Software watchpoints, while available, are terribly slow and thus
impractical.  They require the debugger to single-step the
application, and manually examine the contents at the watched memory
range after each step.

(**) Unlike AVR Studio, you can walk stackframes up and down, so
different frame's variable come in and get out of scope.

> I couldn't find any in depth tutorial.

I don't believe you that.  Except for the 0x800000 SRAM address
offset, and the IO register access through memory addresses, all of
the above is pretty generic GDB knowledge which is completely
independent of the target architecture.  The very same commands would
be used to debug a native application on your Linux host.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)