Peterle Anonym schrieb:
> Hallo,
>
> ich habe mal eine Verständnisfrage zum oben genannten Format. Ich rede
> jetzt mal von einem cross kompilierten ELF file zB für einen ARM9.
> Dieses enthält ja mehr Infos als nötig, zB als das reine BIN file. Wenn
> ich mittels GDB ein ELF file lade um zB zu debuggen, wird doch trotzdem
> nur die reine Applikation zum device übertragen oder?
Richtig.
> Die
> Zusatzinformation im ELF file sind doch nur für den Debugger relevant?
> Habe mal mittels "readelf" mir ein file angeschaut. Den code selbst sehe
> ich nicht, nur die Symboltabelle mit Verknüpfungen von Adressen und
> Funktionen.
Was Du siehst haengt von den Optionen ab, die Du readelf gibst. Mit der
Option '-S' bekommst Du eine Liste der Sektionen. Sectionen mit den
Flags 'A' werden allociert, d.h. geladen. Es gibt allerdings auch
Sektionen, fuer die keine Daten in der Datei enthalten sind, da sie eh
komplett aus 0 bestehen. Diese sind vom Typ NOBITS, z.b. die BSS
Sektion.
Die Debug-Information liegt bei ARM eigentlich immer im DWARF Format
vor. Sie ist in den Sektionen enthalten die mit ".debug_" anfangen.
Wie Du richtig vermutest gibt es unter anderem eine Zuordnung von
Source-Zeilen und Code-Adressen. Neben der Anzeige der gerade aktuellen
Sourcode-Zeile wird diese Information auch benutzt, um Code-breakpoints
zu setzen wenn der User eine Source-Zeile "anklickt".
Es gibt aber weitere Debug-Information:
- An welchen Adressen sind globale Variablen im Speicher abgelegt.
- Wo befinden sich, bzw. wie ermittelt man den Wert von lokalen
Variablen (sie koennen sowohl in Registern, als auch auf dem Stack
gehalten werden)
- Wie ist der Stack zu interpretieren, z.b. um die Hierarchie der gerade
aktiven Funktionen zu bestimmen.
- Makro-Definitionen
Genaueres steht im DWARF Standard, ist allerdings nicht ganz trivial.
Readelf kann diese Debug-Information mit der Option -w anzeigen.
> Dient das nur dazu, um das Debuggen visuell zu unterstützen,
> praktisch um die Adresse bei einem "breakpoint hit" an die richtige
> Stelle im Code zu linken?
>
> Wie läuft das ab: Der ICE des ARMs hat ein Register in dem steht die
> Adresse für den breakpoint. Bei einem "hit" wird der Core angehalten und
> der debugger informiert?
Ja, so koennte es gehen. Da nur eine (von der Hardware abhaenige)
begrenzte Anzahl von Breakpoint-Registern zur Verfuegung stehen werden
alternativ auch Instruktionen im RAM mit Breakpoint-Instruktionen
ersetzt. Manche Debugger koennen das auch fuer Flash-ROM machen. Wird
diese Stelle erreicht, so wird in den Debugger verzweigt. Soll das
Programm dann weiterlaufen, so muss die Breakpoint-Instruktion
kurzzeitig wieder durch die eigentliche Instruktion ersetzt werden.
Alles das macht der Debugger fuer Dich.
