Diskussion:LF OS/LFX

Ich hab mal ein paar Fragen zu Deinem Datei-Format:
31 Zeichen für einen Programm-Namen und 79 Zeichen für eine Programm-Beschreibung erscheinen mir etwas wenig, warum das nicht in einer String-Arrea o.ä. unterbringen wo die einzelnen Strings quasi unbegrenzt groß sein dürfen?
Wo ist der "normale" Entry-Point? (das scheint ein Standard-Fehler zu sein ;) den hab ich auch gemacht)
Es gibt offensichtlich keine Sectionen, wie trennst Du Code, Daten (.data und .bss), Relocations-Infos, Debug-Infos und all das andere Zeugs was man so braucht voneinander?
Mit welchen Programm sollen diese Dateien erzeugt werden? Von LD würde ich eher abraten, das Ding ist riesig, dem LD ein neues Datei-Format beizubringen dürfte ein X-faches an Zeit (X ist min 2-Stellig) kosten als einen recht komfortablen ELF-Loader selber zu schreiben (eigentlich reicht zusammenkopieren, gibt ja schließlich alles).
Versteh mich nicht falsch, ich will Dir nicht die Freude an einem eigenen Datei-Format verderben aber Du solltest Dir erst mal Gedanken über die gesamte Tool-Kette machen die dafür erforderlich ist. Wenn Du eh auf x86 bleiben möchtest gibt es IMHO nichts besseres als ELF. ELF ist das Executable-Format, auf allen Plattformen (von 8/16 Bit µC mal abgesehen) und unter allen Betriebssystemen (von Windows mal abgesehen). ELF ist hervorragend gut Dokumentiert, alle Aspekte sind gut durchdacht und es gibt Haufenweise Source-Code dafür. --Erik.vikinger 17:11, 9. Okt. 2010 (CEST)

Als erstes: einen ELF Loader hab ich schon eingebaut, er funktioniert auch problemlos ;)

braucht man die ganzen Sections eigentlich unbedingt? Ich dachte daran an den Header direkt den Maschinencode zu hängen, wo die Adressen innerhalb der Datei komplett aufgelöst sind. Dann würden sie doch eigentlich wegfallen, oder?

Zu den Strings: Mir war es erstmal wichtig überhaupt etwas direkt in der Datei speichern und einfach darauf zugreifen zu können. 31 Zeichen finde ich Eigentlich ausreichend, früher ging auch alles mit 8.3 Dateinamen, dass die Beschreibung etwas knapp werden könnte seh ich ein.

Der normale Entry-Point ist direkt nach dem Dateiheader. Alles danach wird an die Ladeadresse kopiert und dann ausgeführt.

Rolcations-Infos sollen dann später einen extra Header dranhängen, Debuginfos werden hintendrangehangen.

Momentan müssen die Dateien von Hand erzeugt werden, der Header kann von meinem Beispielprogramm erzeugt werden. Dann einfach den Maschinencode vom Assembler anhängen.

Das müsste jetzt alles gewesen sein, wenn nicht, nochmal melden ;)

Trotzdem Danke das du es dir angeschaut hast --Littlefox 22:35, 9. Okt. 2010 (CEST)

Wenn Du schon einen ELF-Loader hast wozu dann noch einen weiteren Loader? Welches Ziel möchtest Du damit erreichen?
Die Sectionen wirst Du brauchen, spätestens wenn Du DWARF haben möchtest. Auch das trennen von Code und Daten ist extrem sinnvoll. Zusätzlich wäre es gut wenn 0-Daten (.bss) nicht zwangsläufig in der Executable mit drin sein müssen, es wäre also gut wenn das Layout im Speicher anders sein kann als das in der Datei.
Das der Entry-Point direkt am 0-ten Byte liegt musst Du dann aber beim linken garantieren können, da bin ich mir nicht sicher ob das zuverlässig unter allen Umständen geht.
Wenn ich Dich richtig verstanden habe machst Du mit diesem Header aus einer Plain-Binary eine simple Executable, ich bin mir nicht sicher ob das der richtige Weg ist. Für alles was ein Compiler erzeugt wird es IMHO so wie es jetzt ist wohl nicht reichen. Auch ohne Relocationen wirst Du IMHO nicht lange glücklich.
Das mit den Strings ist ne sehr gute Idee aber mit diesen Größenbeschränkungen wirst Du nicht viel Spaß haben, auch hier wären Sectionen gut. Da könnte man eine extra Section für nehmen und dort dann vielleicht noch sowas wie ein Icon o.ä. rein packen.
Ich lese mir sowas gern durch, für meine eigene Plattform muss ich auch ein eigenes Executable-Format entwickeln, ELF taugt da leider nicht. --Erik.vikinger 00:12, 10. Okt. 2010 (CEST)

Du kannst ja den Beschreibungsstring ohne Nullterminierung machen, dann hättest du ein Byte mehr zur Verfügung. --Tev 22:39, 9. Okt. 2010 (CEST)

Ich scheine gerade alle Eure Änderungen überschrieben zu haben, sorry, die waren nicht drin als ich angefangen hab zu antworten (was etwa gegen 0 Uhr war, schon ziemlich merkwürdig, könnte da ein Bug im Wiki sein?) und ich wurde auch nicht gewarnt. Ich hoffe ihr seit mir jetzt nicht böse. Über 2 Bytes zu streiten bringt IMHO auch nichts. --Erik.vikinger 00:16, 10. Okt. 2010 (CEST)

Die müssen schon drin gewesen sein, 23.30 Uhr war die letzte Antwort, ist aber nicht schlimm. (meiner Meinung nach) --Littlefox 11:45, 10. Okt. 2010 (CEST)

Eigentlich könnte man die ganzen Informationen auch an eine ELF Datei anhängen, oder? Das wäre ja eine andere (bessere) Variante. Bleiben das dann noch ELF Dateien die von allen ELF Loadern erkannt werden? --Littlefox 11:45, 10. Okt. 2010 (CEST)

Wie anhängen? Kannst du das mal etwas genauer erklären wie du das meinst. Das ist jetzt nicht Böse gemeint aber so verstehe ich nicht, was du wo anhängen willst. --Programm Noob 10:49, 11. Okt. 2010 (CEST)

Wenn Du mit "anhängen" meinst das Deine zusätzlichen Infos in eine neue zusätzliche Section gepacken werden sollen dann geht das immer und es bleiben auch valide ELF-Dateien (falls Du nichts kaputt machst). Alle normalen ELF-Tools ignorieren einfach alle Sektionen die sie nicht kennen bzw. nutzen nur die die sie kennen. --Erik.vikinger 12:15, 11. Okt. 2010 (CEST)

Genau das meine ich. Könnte man auch ein reserviertes Byte aus dem ELF Header benutzen um anzuzeigen ob diese Sektion vorhanden ist? Oder machen die ELF Tools dann Probleme? --Littlefox 20:26, 13. Okt. 2010 (CEST)

Also reservierte Bytes sind, wie der Name schon sagt, reserviert und damit nicht für Dich. Alle Sectionen haben einen individuellen Namen, denke Dir einfach einen schönen Namen für Deine Section aus (sowas wie ".demKleinenFuchsSeineInfos") und schon fast die niemand an und Du kannst diese eindeutig identifizieren. --Erik.vikinger 20:36, 13. Okt. 2010 (CEST)