ELF-file Format

[Peterle A. (Firma: keine) (wanderameise)]

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? 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. 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?

Bin für jede Info dankbar!

Gruß

[Kai S. (zigzeg)]

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.

[Peterle A. (Firma: keine) (wanderameise)]

bei einem Hardware-debugger wird doch keine code ersetzt, das machen 
doch nur die SW-debugger? Der ARM hat ne richtige Debug unit, die nen 
Adressdekoder am Bus hat oder den PC liest, um den breakpoint 
mitzubekommen - so würde ich es jetzt vermuten, oder verwechsele ich da 
was?

[Kai S. (zigzeg)]

Peterle Anonym schrieb:
> bei einem Hardware-debugger wird doch keine code ersetzt, das machen
> doch nur die SW-debugger?

Hm, SW vs. HW Debugger ? Kenne da eigentlich keinen so klaren 
Unterschied.
Fakt ist dass es immer nur eine Begrenzte Anzahl von Komparatoren gibt, 
um HW Breakpoints zu checken. Wenn der User mehr Breakpoints setzt so 
gibt es zwei Moeglichkeiten:
- Der Debugger sagt: "Fehler, maximale Anzahl von Breakpoints erreicht".
- Der Debugger faellt auf SW Breakpoints zurueck.

> Der ARM hat ne richtige Debug unit, die nen
> Adressdekoder am Bus hat oder den PC liest, um den breakpoint
> mitzubekommen - so würde ich es jetzt vermuten, oder verwechsele ich da
> was?

Das stimmt grob schon, auch wenn es insbesondere bei neueren Prozessoren 
(nach ARM9) in der Praxis nicht ganz so einfach ist (Stichworte MMU, 
Cache, insb. Superskalar).

[Peterle A. (Firma: keine) (wanderameise)]

also der unterschied ist, dass ein HW debugger eine dedizierte hardware 
unit ist, während ein SW debugger eine reine SW Lösung ist, sprich in 
Flash/RAM läuft und zB IRQs benutzt. Wäre jetzt mal meine Vermutung!