Lowlevel
Lowlevel => OS-Design => Thema gestartet von: kernel64 am 26. April 2009, 20:35
-
Hallo, ich bin Anfänger in diesem Gebiet, wollte aber schon immer mal ein Betriebssystem schreiben. Ich arbeite unter Windows XP, nun muss ich die Entwicklungstools installieren und einrichten und hier bräuchte ich eure Hilfe.
Sind folgende Tools vollständig?
- NASM
- MinGW
- Notepad++
- VMware, Bochs
Wofür wird MSYS verwendet?
Damit ich überall auf mein C Compiler zugreifen kann muss ich diesen ja im PATH definieren.
Wie richtet ihr eure Entwicklungsumgebung ein und wie sieht euer Arbeitsverzeichnis aus??
Danke im voraus :-)
-
Das kannst Du z.B. hier nachlesen:
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId440953
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId29572 (gcc)
-
Moin,
trotz meines installierten Debians möchte ich mal eine Entwicklungsumgebung unter Windows einrichten :evil:. Dazu verwende ich den crosscompiler von der Wiki hier. Es funktioniert auch alles, bis auf das Linken des Kernels...
Hier bekomme ich folgende Ausgabe (nur ein kleiner Ausschnitt):
d:\Entwicklung\gcc\i586-elf\bin\ld.exe: warning: cannot find entry symbol start; defaulting to 00100000
./src/gdt.o: In function `gdt_install':
gdt.c:(.text+0xf7): undefined reference to `gdt_flush
./src/idt.o: In function `idt_install':
idt.c:(.text+0x68): undefined reference to `idt_load'
./src/irq.o: In function `irq_install':
irq.c:(.text+0x106): undefined reference to `irq0'
irq.c:(.text+0x119): undefined reference to `irq1'
irq.c:(.text+0x12f): undefined reference to `irq2'
irq.c:(.text+0x142): undefined reference to `irq3'
irq.c:(.text+0x158): undefined reference to `irq4'
irq.c:(.text+0x16b): undefined reference to `irq5'
irq.c:(.text+0x181): undefined reference to `irq6'
irq.c:(.text+0x194): undefined reference to `irq7'
irq.c:(.text+0x1aa): undefined reference to `irq8'
...........
Es hat also den Anschein, dass nasm die Symbole unter Windows nicht richtig, bzw. anders anlegt. Auch habe ich mittlerweile mehrere Versionen durchprobiert und es ist immer wieder der gleiche Fehler aufgetreten.
Woran könnte das denn liegen? Muss ich unter Windows alle Assembler-Dateien anders übersetzen? Momentan ist das so: nasm -felf -o ....
-
Wenn du den Cross Compiler nutzt, solltest du keine _ vor den Funktionsnamen im Assemblercode machen.
-
Wenn du den Cross Compiler nutzt, solltest du keine _ vor den Funktionsnamen im Assemblercode machen.
Und genau da liegt der Hund begraben...
Da ich das ja die ganze Zeit unter Debian assembliert, kompiliert und gelinkt habe, habe ich generell kein _ vor den Funktionsnamen. Und trotzdem werden diese Fehler angezeigt... :?
-
Ich arbeite auch wunderbar mit MinGW und NASM unter meinem XP nutze aber den Editor vom Visual Express Edition C++. Meine paths habe ich hier C:\Programme\MinGW\ und meinen NASM habe ich unter C:\WINDOWS\system32\ dort musste ich die Path nicht anpassen. Das wars auch schon einfaches Prinzip funktioniert und hat Luft. :-D
-
Also ich Benutzer Dev-Cpp unter Windows Vista(ist zwar ein bisschen Buggy aber unter XP läuft perfekt scheint wohl an Vista zu liegen) und hab dort einfach die Compilerpath auf die des Corsscompilers aus dem Wiki gestellt.
Und den NASM hab ich einfach in den Bin-Ordner des Comilers gepackt so das er den auch findet.
-
Wenn du den Cross Compiler nutzt, solltest du keine _ vor den Funktionsnamen im Assemblercode machen.
Und genau da liegt der Hund begraben...
Da ich das ja die ganze Zeit unter Debian assembliert, kompiliert und gelinkt habe, habe ich generell kein _ vor den Funktionsnamen. Und trotzdem werden diese Fehler angezeigt... :?
Werden die Funktionen eventuell nicht über "global irq0" als global sichtbares Symbole markiert?
-
Werden die Funktionen eventuell nicht über "global irq0" als global sichtbares Symbole markiert?
Alle Funktionen in Assembler, die in C genutzt werden, sind zuvor als "global xyz" bekannt gemacht worden, sonst würde das ganze auch unter Debian fehl schlagen.
Also ich Benutzer Dev-Cpp unter Windows Vista(ist zwar ein bisschen Buggy aber unter XP läuft perfekt scheint wohl an Vista zu liegen) und hab dort einfach die Compilerpath auf die des Corsscompilers aus dem Wiki gestellt.
Nur schade, dass das Projekt scheinbar tot ist (ich meine Dev-Cpp ;))
-
Ist es auch aber schon seit längerem, war aber eine einfache IDE, gut für einsteiger
-
Nur schade, dass das Projekt scheinbar tot ist (ich meine Dev-Cpp ;))
Blödsinn, im Vergleich zu djgpp ist das doch quicklebendig. :-D
-
Nur schade, dass das Projekt scheinbar tot ist (ich meine Dev-Cpp Wink)
Da gibt es einen Quasi-Nachfolger: Code::Blocks
http://www.codeblocks.org/
-
Da ich das ja die ganze Zeit unter Debian assembliert, kompiliert und gelinkt habe, habe ich generell kein _ vor den Funktionsnamen. Und trotzdem werden diese Fehler angezeigt... :?
Hm, ich stell mal die ganz blöde Frage: Hast du auch das Kabel eingesteckt... äh... dem Linker alle relevanten Dateien übergeben?
Ansonsten, wie üblich: Code irgendwohin hochladen, dann kann es vielleicht jemand nachvollziehen.
-
Da ich das ja die ganze Zeit unter Debian assembliert, kompiliert und gelinkt habe, habe ich generell kein _ vor den Funktionsnamen. Und trotzdem werden diese Fehler angezeigt... :?
Hm, ich stell mal die ganz blöde Frage: Hast du auch das Kabel eingesteckt... äh... dem Linker alle relevanten Dateien übergeben?
Ansonsten, wie üblich: Code irgendwohin hochladen, dann kann es vielleicht jemand nachvollziehen.
Der Linker bekommt alle Daten, die gebraucht werden. Das Makefile sucht im Verzeichnis "src" nach Dateien mit der Endung ".c" und ".s". Je nach Endung wird dann die Datei kompiliert oder assembliert. Es verwundert mich ja schon, dass der Einsprungspunkt "start" nicht gefunden wird, der ja in der Assembler-Datei "start.s" ist, dessen Objekt beim Aufruf von ld an erster Stelle steht:
ld -T ./link.ld -o kernel.bin ./src/start.o ./src/gdt.o ./src/idt.o ./src/irq.o ./src/isrs.o ./src/kernelheap.o ./src/list.o ./src/main.o ./src/mm.o ./src/panic.o ./src/pmm.o ./src/scrn.o ./src/timer.o ./src/tree.o ./src/vmm.o
Es hat ganz den Anschein, das nasm irgendwas mit den Symbolen falsch macht. Wie dem auch sei, ich habe das ganze mal hochgeladen: http://christianfreitag.ch.funpic.de/DeutschOS.zip
-
Oha, Objektdateien im Archiv ... hast du bei dem Betriebssystemwechsel zufällig mal make clean gemacht bzw. alle Binärdateien gelöscht? Bei mir gibts ohne make clean deinen Fehler und nach einem make clean klappt es.
-
tut mir leid, die sollten eigentlich nicht im Archiv sein. Anscheinend habe ich das make clean vor dem Archivieren vergessen.
Oha, Objektdateien im Archiv ... hast du bei dem Betriebssystemwechsel zufällig mal make clean gemacht bzw. alle Binärdateien gelöscht? Bei mir gibts ohne make clean deinen Fehler und nach einem make clean klappt es.
Nun, im SVN-Repository sind keine Objektdateien, weshalb es auch nicht an diesen liegen kann. Die, die im Archiv sind, wurden unter Windows erzeugt und es läuft irgendwas schief...
-
Also objdump mit deiner start.o zeigt für die Symbole sowas an:
00000000 *UND* 00000000 isr0
und wenn ich sie selbst assembliere:
0000005a g .text 00000000 isr0
Du könntest es mal mit einem mal [section .text] am Anfang probieren.
-
Habe ich mal gemacht und es funktioniert... :-o
Anscheinend macht nasm unter Debian das automatisch wohingegen man das unter Windows explizit sagen muss oder die Version des nasm unter Debian ist uralt... (muss ich mal prüfen) ;)
-
Ich nutze:
-Dev-Cpp & NASM zum OS-DEV
-sonst MS Visual Studio 2008 Professional
liebe Grüße
-
Für gewöhnlich unter Debian nutze ich:
- gvim
- gcc und nasm (mit ner Makefile)
Unter Windows, wenn ich da was mache, nutze ich folgendes:
- Notepad++
- und den crosscompiler aus der Wiki
Ich weiß nicht warum, aber nasm unter Debian scheint das "SECTION .text" automatisch anzuhängen...
-
unter ubuntu:
* Code Blocks
* Nasm
* dd
unter vista
* Notepad ++
* Nasm
* Rawwritewin
-
unter xp:
dd
nasm
gcc
editor: in der cmd einfach mal edit eingeben
ubuntu:
dd
nasm
gcc
nano :-D
-
Nun die cross-tools unter Windows:
http://www.henkessoft.de/OS_Dev/OS_Dev2.htm#mozTocId42018
-
Hast ja doch noch mal die Konvention im forum zusammengefasst, wird langsam kompletter dein Teil2 :-D
-
Thx, als nächstes Kapitel kommt der "echte" user mode, denn bisher hatte ich (angeleitet durch das Tutorial von James Molloy) einen Kernel, der sich im user mode / read-only Zustand befindet. Nur dadurch konnte ich solche Tricks wie create_task (function, privilege) mit privilege = 0 oder 3 durchführen, um die Sinnhaftigkeit von syscalls vorzuführen.
Ich denke aber, dass niemand einen vom user space lesbaren kernel bevorzugt (außer der von mir geschätzte James Molloy). Das wird sich nun ändern. Außer dem Video RAM (nur zu Testzwecken wegen des Assembler-TEST-Programms, das direkt in den Videospeicher schreibt) wird nun alles für die User "zugerammelt". Dann geht allerdings nur noch create_task (function, 0).
Dennoch ein interessantes Feature, finde ich.
-
Ach übrigens, ich glaube, ich habe nur im IRC darauf hingewiesen: Ich habe vor ein, zwei Wochen eine aktuelle git-Version von qemu für Windows gebaut. Man hört ja gelegentlich Klagen, dass es keine aktuellen Win32-Binaries mehr gibt. Ich hoffe sie gehören damit der Vergangenheit an.
Download: http://lowlevel.brainsware.org/download/qemu-0.10.50-i386.tar.bz2
-
Ich habe zwar ein Windoof VIsta bei mir laufen, aber trotzdem die cygwin-Umgebung installiert. nano rocks!
Habe anfangs mit der *ix-Variante von GCC und Co. zu compilieren, habe aber feststellen müssen, dass es Probleme gab.
Jetzt arbeite ich in der cygwin-Konsole (MinTTY) mit den DJGPP-Binaries.
Ist halt Gewohnheitssache.
Als Emulatoren habe ich VMware Workstation, QEMU und virtualBox.
-
Ob Crosscompiler oder DJGPP ist nicht Gewohnheitssache, sondern eher die Frage, was man am Ende haben möchte. Da kommen nämlich unterschiedliche Formate raus. ;)
-
Ich habe zwar ein Windoof VIsta bei mir laufen, aber trotzdem die cygwin-Umgebung installiert. nano rocks!
So dachte ich auch. Did you tried vim? It's amazing, believe me...
-
Ich habe i-wie Probleme mit vi. Selbst mit gvim. Ich bin einfach zu doof :roll:
Ich hatte Probleme mit den *ix-Binaries von cygwin, das ich bei ld kein Binary-Output hatte, wie es bei der DJGPP-Version möglich ist. Und das mit MinGW und Cross-Compiler ist mir um ehrlich zu sein, etwas zu viel Arbeit...
-
http://lowlevel.brainsware.org/wiki/index.php/X86-64_Cross-Compiler
Hier hab ich mal erklärt, wie man einen Cross-Compiler zusammenbaut (allerdings für Linux). Ich behaupte aber einfach mal unter Windows mit Cygwin wird fast analog verfahren. Einfach mal durchlesen, es ist keine große Arbeit.
-
Dieser Wiki-Eintrag ist ja 64-bit betreffend. Ich steh jetzt auf dem Schlauch!
Wieso 64? Sind die Cross-Compiler genau dafür?
Ich wollte eigentlich nen 32-er machen, wenn man das so ausdrücken kann. Bin halt dabei die Tutorials von ehenkes und James Molloy um dann weiter selber zu experimentieren.
-
Ein Cross-Compiler ist ein Compiler, der für eine bestimmte Plattform gebaut ist und Code für eine andere entwickelt, d.h. ich hab z.B. ein 32-Bit-OS und mir einen Cross-Compiler gebaut, der auf 32-Bit läuft und Code für 64-Bit produziert.
Was willst du denn genau?
-
Ich will einfach nur nen Compiler, der mir einfach nen normales 32-bit Sys compilieren kann. Ich habe mein Vista ja nur auf 32.
Ich arbeite momentan, wie schon erwähnt mit dem "Henkes"-Tutorial und war zufrieden. Seitdem ich versuche mit dem cygwin-GCC und LD zu arbeiten habe ich Probleme, weil das LD keine Kernel-"binary" erstellen kann...
Dann habe ich einfach DJGPP genommen. Is zwar etwas drumrum gehen, aber nja...ich kann leider keinen C++-Kernel schreiben weil ich das DJGPP-nocpp installiert habe =)
Ich habe auch versucht mit ELF zu compilieren, nur mochte LD meinen mit NASM generierten Kernel16 (Sprung in PM und Call von C-Kernel [Kernel32]) nicht. Per nasm -felf ... compiliert, aber als Error: File type not recognized oder so.
-
http://lowlevel.brainsware.org/wiki/index.php/Crosscompiler_f%C3%BCr_Windows
;)
-
Heißt das nur unter ~/bin entpacken und ich habe alle Probleme gelöst?
-
Ich habe auch versucht mit ELF zu compilieren, nur mochte LD meinen mit NASM generierten Kernel16 (Sprung in PM und Call von C-Kernel [Kernel32]) nicht. Per nasm -felf ... compiliert, aber als Error: File type not recognized oder so.
Die auf Windows geporteten Versionen von gcc haben meistens irgendwelche Eigenheiten. DJGPP unterstützt nur coff und kein elf (http://www.delorie.com/djgpp/v2faq/faq22_22.html). Wobei coff dann soweit ich weiß kein Mischen von 16 und 32 Bit code erlaubt. Cygwin hat soweit ich weiß standardmäßig auch nur eine recht gestutzte Version von gcc die vor allem unter Windows lauffähige Programme (mit abhängigkeit zur cygwin.dll) erstellt.
Deswegen wird in den Henkes Tutorials auch auf den crosscompiler umgestiegen.
Heißt das nur unter ~/bin entpacken und ich habe alle Probleme gelöst?
Wenn du mit "~/bin" einen Ordner meinst der im PATH steht, ja.
Edit: Ah ich glaub jetzt versteh ich wie du das meintest. Du brauchst kein cygwin oder sonstiges für den crosscompiler. Der wird ganz normal aufgerufen wie ein normales Windows Programm. Daher muss der ordner wo der compiler liegt im PATH von Windows sein.
-
Ich probiere das nachher aus!
Vielen Dank! Ich werde mich melden, wenn es Probleme gibt!
-
Ich wollte mitteilen, dass alles prima klappt! Danke für die Hilfe!
@Tobiking: Ich arbeite wegen vielen Sachen unter cygwin. Das mit den normalen Windows-Apps ist mir klar.