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 | else if (...-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?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.