mikrocontroller.net

Forum: Compiler & IDEs Suche Infos zum Format der Object files des gcc


Autor: Mark .. (mork)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gugel mal nach ELF (excutable and linking format).

Autor: Mark .. (mork)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.