Welche GDB Kommandos gibt es?

GDB Reference Card
http://www.cs.dal.ca/studentservices/refcards/gdbref.pdf

Florian wrote:

> Jedoch steht da nichts zum "range Break Point"
> Oder ist das mit dem gdb nicht möglich?

Der GDB nennt das einen watchpoint.  Der range breakpoint, den manche
ICEs beherrschen, ist eine sehr stark eingeschränkte Version eines
watchpoints, bei der man eine Basisadresse und eine Bitmaske angibt,
wobei die Basisadresse alle Maskenbits 0 hat.  Der Watchpoint des
GDB orientiert sich stärker an den Belangen der Hochsprache, indem die
Intention ist, dass man ihn auf eine bestimmte Variable ansetzt, die
man überwachen will (egal, wie groß sie ist).  Daraus entsteht natür-
lich das Dilemma, dass nicht alle möglichen Watchpoints in der
Hardware des ICE abgebildet werden können.  Die anderen kann der GDB
zwar trotzdem noch über eine Emulation benutzen, aber sowas will man
schon auf einem schnellen PC nicht wirklich haben, auf einem Controller
mit einem ICE dazu würde das Debuggen damit wahrscheinlich Wochen in
Anspruch nehmen.

Man kann aber GDB-typisch ja völlig beliebige Ausdrücke für den
Watchpoint angeben und auf diese Weise auch einen Datentyp der
entsprechenden Größe per typecast auf die gewünschte Adresse ansetzen.

watch *(uint32_t *)0x800060

würde ich mal aus dem Hut sagen.  Kann's auch gerade nicht testen.

Florian wrote:

> Durch einsetzen von (uint32_t) oder (uint32_t*) ändert sich nur, wie
> gdb den Inhalt von uart_tx_buffer[0] darstellt.

watch *(uint32_t *)uart_tx_buffer

Wird aber nicht funktionieren, weil das ICE das nicht kann:

> Wenn uart_tx_buffer im Sram ab adresse 0x9e liegt dann sollte
> mit watch *0x80009e

0x9e kann man nämlich bestenfalls mit einer Maske von 0x01 (also als
uint16_t) zu einem range breakpoint erweitern, mehr geht nicht.  Das
ist das Dilemma der einfachen Implementierung im ICE als Offset +
Maske: der AVR selbst benötigt ja kein Alignment für seine Daten
(sodass der Compiler auch keins benutzt), aber die range breakpoints
benötigen Daten, die sauber ausgerichtet sind, sonst kann man sie
nicht benutzen, da die Objektgrenze über einen darstellbaren range
hinaus geht.

Florian wrote:

> Ich verstehe aber immer noch nicht wie ich das in den gdb eingeben muss.
> Laut avarice debug Ausgaben sind diese breakpoints identisch

> watch *(uint32_t)0x80009c

Ich meinte auch *(uint32_t *)0x80009c

Aber: jetzt sitze ich selbst vorm GDB, und er kann in der Tat
offenbar nicht mehr als 16 bits auf einmal in einen hardware
watchpoint nehmen.  Er fragt auch gar nicht erst das AVaRICE,
an diesem kann es also nicht liegen.  Nun habe ich mich mal durch
den GDB-Code gehangelt, und es sieht mir so aus, als hätte niemand
da je eine Anpassung für den AVR geschrieben.  Damit fällt das
Ganze letztlich zurück auf das hier (in target.c):

1

static int

2

default_region_size_ok_for_hw_watchpoint (int byte_count)

3

{

4

  return (byte_count <= TYPE_LENGTH (builtin_type_void_data_ptr));

5

}

Damit ist klar, warum man nur 1- oder 2-Byte-Bereiche als
Hardware-Watchpoint aktiviert bekommt. :-/  Da außerdem das
default-Scenario nur die Länge, nicht aber die Adresse des
watchpoints betrachtet, genügt das für den AVR und das JTAG ICE
ohnehin nicht.  Es gibt aber einen Makro
TARGET_REGION_OK_FOR_HW_WATCHPOINT, den man offensichtlich
irgendwie unter gdb/config/avr/nm-avr(?).h setzen kann um
anzuzeigen, was man tatsächlich als hardware watchpoint
unterstützen kann.  Das könnte man sich ja mal ansehen...

> in jtag2bp.cc scheint in Zeile 287 ein Tippfehler zu sein.
> Oder soll da eine Zuweisung im if sein?

Wo du Recht hast, hast du Recht.  OK, danke sehr, ist repariert.