Hallo, ich suche eine geanue Beschreibung des Formats der .o Object-Dateien, die vom (avr-)gcc erzeugt werden. Kennt sich da jemand aus? MfG Mark
Gugel mal nach ELF (excutable and linking format).
Danke, zu ELF finden sich deutlich mehr Informationen als zu .o. Hab ich es richtig verstanden, dass man aus derselben ELF-Datei Code erzeugen kann, der an verschiedenen stellen im Flash liegt (auf AVRs bezogen)? Ich möchte eine Art Dateisystem im Flash des AVRs implementieren, sodass man dort mehrere von einander komplett unabhängige Programme unterbringen und ausführen kann. Dabei ergibt sich das Problem mit absoluten Adressen, die ja erst beim Speichern des Programms auf den Controller bekannt sein würden. Deshalb soll der AVR aus den einzelnen Object files oder aus der elf, die vermutlich auf einer SD-Karte od. änlichem liegen, sich den entgültigen Opcode selber erstellen. MfG Mark
ELF ist nicht gleich ELF. Es gibt `relocatable object files', das sind die, die gewöhnlich mit .o bezeichnet werden. Diese enthalten für alle externen Referenzen sogenannte relocation records (Verschieblichkeits- beschreibungen), die dann vom Linker durch die tatsächlichen Adressen des jeweiligen Ziels ersetzt werden. Damit ist es der Linker, der die endgültige Lage im Adressraum festlegt. Der wiederum produziert eine weitere ELF-Datei als Ausgabe (unter Unix hat sie typischerweise keinen Suffix mehr, da sie direkt als Kommandoname benutzt wird, im embedded- Bereich bekommt sie oft die Endung .out oder .elf oder sowas). Diese ELF-Datei ist aber im Adressraum nicht mehr verschieblich. Außerdem bieten manche Targets noch die Option, positionsunabhängigen Code (PIC, position independent code) zu erzeugen, bei denen der Compiler statt fester Adressen eine Berechnung der tatsächlichen Adresse zur Laufzeit vornimmt. Das ist etwas weniger effektiv, aber notwendig, wann man beispielsweise eine shared library (Windows-Speak: DLL) bauen möchte. Erzeugt wird derartiger Code mit der Option -fpic oder -fPIC, aber für das AVR-Target ist das meines Wissens nicht implementiert worden, da shared libs im Kontext eines (kleinen) Flash-ROMs nicht viel Sinn haben. (Der dynamische Linker müsste ja ebenfalls noch in den ROM passen.)
Bitte 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.