Hallo,
ich versuche gerade ein Map File zu analysieren das der avr-gcc
ausgespuckt hat. Ziel ist es später vielleicht, einen Parser zu
schreiben um z.B. die Adresse einer (globalen) Variable herauszufinden.
Gibt es dazu irgendwo im Netz Informationen? Also betreffend Aufbau,
verschiedene Formate, etc. Die google-Suche spuckt da relativ viel
unnützes aus...
Oder finde ich die Informationen die ich benötige eher im .elf File?
Dieses ist ja eine Binärdatei, aber imho stecken da noch irgendwo auch
die Bezeichner(="Namen") der Symbole drin, richtig?
Viele Grüße,
Karlo
Karlo schrieb:> ich versuche gerade ein Map File zu analysieren das der avr-gcc> ausgespuckt hat.
Vergebliche Liebesmüh'.
Wenn du nicht gerade den Linker debuggen willst, dann vergiss das
Mapfile ganz schnell.
> Ziel ist es später vielleicht, einen Parser zu> schreiben um z.B. die Adresse einer (globalen) Variable herauszufinden.
Was du brauchst, ist das Kommando »nm« (bzw. hier »avr-nm«). Das
gibt dir die Symboltabelle aus, und darin findest du dann auch die
Adresse deiner Variablen ganz schnell.
>Was du brauchst, ist das Kommando »nm« (bzw. hier »avr-nm«). Das>gibt dir die Symboltabelle aus, und darin findest du dann auch die>Adresse deiner Variablen ganz schnell.
Die sich nach ein paar Codeänderungen auch ganz schnell ändern kann;)
holger schrieb:> Die sich nach ein paar Codeänderungen auch ganz schnell ändern kann;)
Yep. Genau deswegen würde ich gerne den Compiler (bzw Linker) Output
parsen um automatisch die Adressen aktuell zu halten.
Der Tip von Jörg Wunsch mit avr-nm funktioniert perfekt, damit kann ich
erstmal weiterexperimentieren.
Dazu noch eine Frage: mit -S bekomme ich zwar die Größe in Byte
mitgeliefert, auf den Datentyp kann ich so allerdings nicht schließen.
Ebenso würde mich der Aufbau von Strukturen oder Arrays interessieren.
Warum ich frage: im Automotive-Umfeld gibt es ja CANape um Steuergeräte
zu diagnostizieren. CANape kann aus der .elf Datei sämtliche Angaben
dazu herauslesen.
Das Format dieser .elf-Dateien ist übrigens ELF/Dwarf_32Bit.
Ich würde das gerne als Bastelei mit avr-gcc Binaries auch machen
können. Stecken diese Infos da irgendwo drin? Welches Format haben
avr-gcc-.elf-Dateien?
Danke bisher & Viele Grüße,
Karlo
Karlo schrieb:> Ich würde das gerne als Bastelei mit avr-gcc Binaries auch machen> können. Stecken diese Infos da irgendwo drin?
Ja, sofern du das dem Compiler sagst (avr-gcc -g...).
> Welches Format haben avr-gcc-.elf-Dateien?
Steht ja da, ELF. :)
http://wiki.osdev.org/ELF
Ich denke der vielversprechendste Ansatz wäre das Parsen von Debugging
Informationen. Wenn ich mir allerdings die DWARF Spec anschaue wird mir
schwindlig, 100+ Seiten PDF... Vlt. gibt's dafür ja bereits einen
Parser? Im schlimmsten Fall kannste ja den gdb bemühen, oder mal in den
Source reinschauen.
>> Die sich nach ein paar Codeänderungen auch ganz schnell ändern kann;)>Yep. Genau deswegen würde ich gerne den Compiler (bzw Linker) Output>parsen um automatisch die Adressen aktuell zu halten.
Ich frag mich nur wozu du das brauchst? Die Adresse einer
Konstanten im Flash zu bestimmen um da was rein zu patchen
würde ich ja noch verstehen. Aber auch das geht besser über
Linker Sections. Wozu braucht man die Adresse einer Variablen?
Willst du dir selber einen Debugger bauen;)
Ganz simpel ausgedrückt: ich will dem Controller irgendwie (zB per Uart)
eine Adresse übermitteln. Auf dem Controller läuft ein neben der
eigentlichen Software ein kleiner Interpreter, der mir mit dem Inhalt
der angeforderten Adresse antwortet.
Sinnvollerweise müsste man aber dazu neben Adresse und Größe auch
Datentyp und Struktur kennen, um die Antwort interpretieren zu können.
>Ganz simpel ausgedrückt: ich will dem Controller irgendwie (zB per Uart)>eine Adresse übermitteln. Auf dem Controller läuft ein neben der>eigentlichen Software ein kleiner Interpreter, der mir mit dem Inhalt>der angeforderten Adresse antwortet.
Wenn du eine Adresse überträgst und dein Interpreter den Inhalt
der Adresse zurücksendet brauchst du doch den Namen der Variablen
nicht mehr.
Wenn du den Inhalt einer Variablen haben möchtest, warum sendest
du nicht einfach "Gib mir den Inhalt von blabla" und dann sendet
dein Interpreter den Inhalt von blabla zurück. Die Adresse musst du
nicht
wissen.
Ich versteh es immer noch nicht wozu das gut sein soll.
Karlo schrieb:> Dazu [nm] noch eine Frage: mit -S bekomme ich zwar die Größe in Byte> mitgeliefert, auf den Datentyp kann ich so allerdings nicht schließen.
Der Datentyp ist auf der Ebene auch nicht bekannt.
> Ebenso würde mich der Aufbau von Strukturen oder Arrays interessieren.
Hier hilft dir Debug-Information, damit kannst zu dann auch
unterscheiden, ob ein 16-Bit Wert ein int, ein unsigned oder ein Zeiger
ist.
Am hilfreichsten dazu sind zeitgemäße Debug-Formate wie DWARF-3 oder
höher. Siehe auch readelf.
> Warum ich frage: im Automotive-Umfeld gibt es ja CANape um Steuergeräte> zu diagnostizieren. CANape kann aus der .elf Datei sämtliche Angaben> dazu herauslesen.> Das Format dieser .elf-Dateien ist übrigens ELF/Dwarf_32Bit.>> Ich würde das gerne als Bastelei mit avr-gcc Binaries auch machen> können. Stecken diese Infos da irgendwo drin?
Hängt davon ab, wie die Binaries erzeugt sind. Im .ihex oder .binary
oder .srec steckt die Info natürlich nicht mehr drin. Verwende .elf mit
DWARF, d.h. die Objekte müssen schon entsprechend erzeugt und dürfen
nicht gestrippt worden sein. Zudem enthält Debug-Info keine Quelle,
sondern nur Referenzen darauf.
Für DWARF gibst du zB an -gdwarf-3, falls dich GNU-Erweiterungen stören,
dann zusätzlich noch -gstrict-dwarf.
Falls dir im elf-Teil Relocs fehlen, hilft u.U. Linken mit --emit-relocs
> Welches Format haben avr-gcc-.elf-Dateien?
elf32-avr
holger schrieb:> Wenn du den Inhalt einer Variablen haben möchtest, warum sendest> du nicht einfach "Gib mir den Inhalt von blabla" und dann sendet> dein Interpreter den Inhalt von blabla zurück. Die Adresse musst du> nicht> wissen.holger schrieb:> Ich versteh es immer noch nicht wozu das gut sein soll.
Wenns dich wirklich interessiert schau dir doch mal die Protokolle CCP
bzw. XCP an. Du kannst dir auch mal die Firmen ansehen, die da im
Standartisierungsgremium sitzen (nennt sich dann ASAM e.V.), anhand
denen sollte man schließen können, dass mein Ansatz, den ich aus diesen
Protokollen übernommen habe, in Ordnung ist.
Aber zu deinem Ansatz, den verstehe ich nämlich nicht:
Wenn ich dem Interpreter einen Variablennamen sende, wie soll mir der
denn den Inhalt zurücksenden? Ich müsste in der Interpretersoftware für
jede Variable, die mich interessieren könnte, eine Fallunterscheidung
vorsehen:
1
...
2
if(...-stringvergleich-...)
3
uart_put(foo);
4
elseif(...-stringvergleich-...)
5
uart_put(bar);
6
...
Oder wie stellst du dir das vor? Da ist das Ansprechen über die Adresse
schon bequemer, generischer und universeller.
Auf dem PC muss die Software halt mehr machen als hartcodierte Kommandos
zu senden. Die muss eben sobald sich der Quellcode ändert ihre
Datenbasis (in der sämtliche Variablen enthalten sind) aktualisieren.
@ Johann L.:
Danke, wie immer sehr informativ, das sollte mir weiterhelfen (sobald
ichs verdaut habe :-))
Nochmal @ Johann L.:
Das mit den Compileroptionen hat wunderbar geklappt. Zumindest CANape
kann die .elf Datei jetzt parsen und die Symbole extrahieren und ihnen
Datentypen zuordnen (ob ich das selber später auch mal kann, mal sehn
:-)).
Nur mit structs und Arrays hab ich noch Probleme. Die kann er
anscheinend nicht auflösen oder findet sie nicht.
Gibts da noch was zu beachten?
Was sind denn diese Relocs? Haben die vielleicht damit zu tun?
Eine eigene Frage?
Dieser Thread ist über 14 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.