Thema: Externe Unterprogramme mit NASM

[bscreator]

Hallo,
ich wollt gestern meine 'putstr-Funktion' in eine seperate Datei (als externes Unterprogramm) schreiben und dann anderen Dateien freigeben:

Das externe Unterprogramm PROC.ASM:

Code: [Auswählen]

global putstr

putstr:
lodsb
or al,al
jz putstr_end
mov ah,0x0E
mov bx,0x0007
int 0x10
jmp putstr

putstr_end:
retn

Das Hauptprogramm TK.ASM :

Code: [Auswählen]

BITS 16 ;Set code generation to 16 bit mode

extern putstr

jmp start

msg_succ  db 'successful',13,10,0
msg_welc  db 'Welcome to RM-OS',13,10,0

start:
mov ax,0x0800
mov ds,ax
mov si,msg_succ
call putstr
mov si,msg_welc
call  putstr
mov si,creboot
call putstr
retn

Das kompilieren der PROC.ASM funktioniert ohne Fehler.
Das kompilieren der TK.ASM bringt beim assemblieren den folgenden Fehler:
error: binary output format does not support external references
Dieser Fehler tritt bei den Zeilen

Code: [Auswählen]

call putstr auf.

Habs schon mit jmp putstr versucht, ein FAR ans global angehängt, nichts funktioniert. Und das was im WIKI steht, über NASM-Unterprogramme funktioniert ebenfalls nicht.

Wisst ihr, wie man ein externes Unterprogramm (in NASM geschrieben) mit NASM aufruft ?

Vielen Dank,
bsc

[kevin]

Vermutlich solltest du einfach mal die Fehlermeldung lesen:

error: binary output format does not support external references

Mit flachen Binaries gehen externe Symbole irgendwie schlecht, weil in der Ausgabedatei keine Symbole landen. Wenn du das machen willst, brauchst du ein ordentliches Binärformat wie ELF.

[bscreator]

Geht das dann mit NASM, bzw. unterstützt NASM dieses Binärformat ?

Ach: Ich hab ja gar keine Binärdatei daraus gemacht, habs ja nur assembliert. Wie kommt dann der auf binary output format ?

[FreakyPenguin]

Geht das dann mit NASM, bzw. unterstützt NASM dieses Binärformat ?

Also ELF wird von NASM unterstützt.

[bscreator]

Das schon, aber nur für 32-bit Code, soviel ich weiss.
Also kann ich gar keine externen Unterprogramme für mein 16-bit OS verwenden.

[bluecode]

Du könntest "a.out", "obj" oder "coff" versuchen, aber ob das tut weiß ich nicht wirklich, siehe auch "nasm -hf" btw.

[bscreator]

Bei mir war als Output-Format das COM-executable binary file - Format eingestellt. Deswegen hat er die Fehlermeldung gebracht. Mit dem Format "DOS 16 bit OMF object file" geht es, aber kann ich einen Bootloader auch in diesem Format schreiben?
Ist für einen Bootloader keine Binärdatei erforderlich (*.bin) ?

[kevin]

Für einen Bootsektor schon. Aber da sehe ich auch keinen Grund, das bisschen Code, das dort reinpasst, auf mehrere Dateien zu verteilen. Ansonsten könntest du immer noch erst ein richtiges Binärformat für die Objektdateien benutzen und erst dem Linker sagen, dass er daraus eine flache Binary basteln soll.

[bscreator]

Aber da sehe ich auch keinen Grund, das bisschen Code, das dort reinpasst, auf mehrere Dateien zu verteilen.

Nene, ich will ja meine Kernelfunktionen auf mehrere Dateien verteilen.

Ansonsten könntest du immer noch erst ein richtiges Binärformat für die Objektdateien benutzen und erst dem Linker sagen, dass er daraus eine flache Binary basteln soll.

Ok, so ganz verstanden hab ich das nicht


Habs grad so versucht:
Aus dem Bootloader ne ganz normale Binärdatei gemacht (nasm -f bin -o ...)
Und anschließend das ganze zu nem IMG zusammengebunden.
copy boot.bin+tk.obj+proc.obj myos.img
Aber wenn ich das ganze dann ausführ, kommt leider nur das "Loading..." aus dem Bootloader. Kann das so eigentlich funktionieren ?

[kevin]

Naja, kommt auf deinen Bootloader an. Wenn der einen Linker eingebaut hat, geht das vielleicht schon, aber ansonsten eher nicht.

Du musst die beiden Objektdateien zusammenlinken - in was für ein Format, hängt wiederum von deinem Bootloader ab. Ich vermute, dass es der typische notlösungsmäßige Bootloader ist, der eine flache Binary braucht. Aber das solltest du selbst am besten wissen. Wenn du es nicht weißt, wäre unsere Standardempfehlung einen Bootloader zu nehmen, von dem bekannt ist, dass er tut und dass er auch ein paar Sachen mehr unterstützt - in der Regel also GRUB.

[bscreator]

Naja, kommt auf deinen Bootloader an. Wenn der einen Linker eingebaut hat, geht das vielleicht schon, aber ansonsten eher nicht.

Naja, ich verwend den "Standard-Bootloader" vom LowLevel-Magazin 1. Also hat der mit Sicherheit keinen Linker dabei. Also mein Bootloader verwendet das "normale" Binary-Format.

Du musst die beiden Objektdateien zusammenlinken - in was für ein Format, hängt wiederum von deinem Bootloader ab.

Ist es eventuell möglich,
1. die beiden Object-Dateien (TK.OBJ und PROC.OBJ) mit NASM zusammenzulinken (copy tk.obj+proc.obj myos.obj)
2. diese myos.obj dann mit einem anderen Linker in eine Binary umzuwandeln ?
3. Diese entstehende myos.bin dann wiederum mit der boot.bin zu verlinken?

Denn auf einen eigenen Bootloader will ich nicht verzichten...
 

Funktioniert das zusammenlinken eigentlich mit dem NASM-copy Befehl ?

[bluecode]

1. die beiden Object-Dateien (TK.OBJ und PROC.OBJ) mit NASM zusammenzulinken (copy tk.obj+proc.obj myos.obj)

copy ist nicht nasm. Abgesehen davon geht es mit copy nicht. Du brauchst einen richtigen Linker (der .obj kann). Das kann ein crosscompilierter ld aus den binutils (macht keinen Spaß, va. nicht unter Windows, falls du doch ELF nimmst kann du allerdings Jidders Crosscompiler runterladen/verwenden, siehe Wiki) oder Microsoft Linker (aus Visual Studio oder was auch immer, da darfst du dann das Manual selbst lesen/verstehen). Wahrscheinlich gibt es auch mehrere kleinere Linker aus der osdev-Community, z.B. irgendwas names jloc von John fine (uralt, schlecht gewartet, etc...).

2. diese myos.obj dann mit einem anderen Linker in eine Binary umzuwandeln ?

Der Linker ist dafür zuständig aus deinen *.obj eine Binary zu machen (und dabei Symbole aufzulösen).

[bscreator]

Also kann ich mit Jidders Crosscompiler (oder JLOC) aus meinen (aus NASM erzeugten) OBJ-Dateien ELF-Binarys machen. Also boot.ELF, tk.ELF, PROC.ELF.

Und Jidders Crosscompiler bzw. JLOC machen dann gleichzeitig aus diesen 3 Files eine einzige Datei, die ich dann mit RawWrite auf ne Floppy schreiben kann, oder ?

[Svenska]

In den OBJs sollten die Symbole ja drin stehen, also kannst du mit einem Linker aus diesen OBJs eine Binärdatei (ELF) erzeugen. Der Linker nimmt sich also die OBJs, du brauchst da keine einzelnen ELFs draus machen.

Diese kannst du später in eine flat binary umwandeln oder vom Linker direkt erzeugen lassen.

Wichtig ist, dass dein NASM als Ausgabe ein richtiges Object-File erzeugt.

[bluecode]

Wichtig ist, dass dein NASM als Ausgabe ein richtiges Object-File erzeugt.

Und dass der benutzte Linker auch dieses Format unterstützt (und auch so kompiliert wurde, dass Format unterstützt wird).

[bscreator]

Wichtig ist, dass dein NASM als Ausgabe ein richtiges Object-File erzeugt.

Und wie kann ich nachprüfen, ob mein NASM ein "richtiges" Object-File erzeugt ?

Und dass der benutzte Linker auch dieses Format unterstützt (und auch so kompiliert wurde, dass Format unterstützt wird). 

Aber mit Jidders oder JLOC kann man doch ELF-Binarys erzeugen. Also unterstützen diese Linker doch dieses Format, oder meinst Du was anderes ?

[bluecode]

Wichtig ist, dass dein NASM als Ausgabe ein richtiges Object-File erzeugt.

Und wie kann ich nachprüfen, ob mein NASM ein "richtiges" Object-File erzeugt ?

Indem du es mit -f <formatname> angibst?

Und dass der benutzte Linker auch dieses Format unterstützt (und auch so kompiliert wurde, dass Format unterstützt wird). 

Aber mit Jidders oder JLOC kann man doch ELF-Binarys erzeugen. Also unterstützen diese Linker doch dieses Format, oder meinst Du was anderes ?

1. jloc kann kein ELF
2. Was ich damit meine ist, dass ld zB unglaublich viele Formate unterstützt, aber wenn man dann zB ld konkret für Linux kompiliert, bleiben nurnoch ein paar wenige übrig, weil er eben so konfiguriert ist, dass nur die Formate einkompiliert werden, mit denen das Host-OS was anfangen kann ("Wer braucht schon ELF unter Windows oder exe unter Linux?").

[bscreator]

Achso, das sollt ich vielleicht noch hinzufügen :
Alle Programme, die ich zur Betriebssystementwicklung brauch (NASM, RawWrite, Hex-Editor, virtuelle Maschinen) laufen alle bei mir unter Windows.

Kennt jemand von euch die Befehle, mit denen man ELF oder "normale" Binarys aus Programmcode mit Jidders CC erstellen kann ?

[bluecode]

Kennt jemand von euch die Befehle, mit denen man ELF oder "normale" Binarys aus Programmcode mit Jidders CC erstellen kann ?

In welcher Sprache soll denn der Sourcecode sein? Ich bin ehrlich gesagt etwas verwirrt. Auf was ich oben eigentlich verwiesen habe ist ld, dass Objektdateien (das Objektdateien bezieht sich nicht auf das Dateiformat ".obj", sondern darauf, dass sie sie kompilierten Code enthalten aber noch nicht gelinkt sind) zusammenlinkt (das heißt primäre Symbolereferenzen aus verschiedenen Objektdateien richtig auflösen). btw. du solltest dir mal anschauen wie das C/C++ Compile/Link-Modell aussieht, dann verstehst du vielleicht besser was wir mit Linken meinen (ich hatte nicht so das Gefühl, dass das angekommen ist)...

[bscreator]

In welcher Sprache soll denn der Sourcecode sein?

Da das BIN-Format die entsprechende Syntax (zum Einbinden externer Unterprogramme) nicht kannte, hab ich das andere Format, genannt DOS 16 bit OMF object file als Zieldatei ausgewählt, das dann, zum assemblieren, funktioniert hat. Quellsprache NASM.

Auf was ich oben eigentlich verwiesen habe ist ld, dass Objektdateien zusammenlinkt

Also ist ld der entsprechende Jidders-CC-Befehl, oder ?


Etwas verwirrt bin ich schon, denn ich will ja keinen Code von Windows auf Linux oder andersherum portieren, sondern nur erreichen, dass ich mit NASM extere Unterprogramme (die auch in NASM geschrieben sind) durch Verwendung von GLOBAL und EXTERN einbinden kann.