Suche Infos zum Format der Object files des gcc

[Mark .. (mork)]

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

[Jörg W. (dl8dtl) (Moderator)]

Gugel mal nach ELF (excutable and linking format).

[Mark .. (mork)]

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

[Jörg W. (dl8dtl) (Moderator)]

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