Thema: Eure Entwicklungseinrichtung auf Windows Systemen

[kernel64]

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

[ehenkes]

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)

[ChristianF]

Moin,
trotz meines installierten Debians möchte ich mal eine Entwicklungsumgebung unter Windows einrichten  . 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):

Code: [Auswählen]

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

[Jidder]

Wenn du den Cross Compiler nutzt, solltest du keine _ vor den Funktionsnamen im Assemblercode machen.

[ChristianF]

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

[matheguru]

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.

[AcidIO]

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.

[bluecode]

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?

[ChristianF]

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 )

[matheguru]

Ist es auch aber schon seit längerem, war aber eine einfache IDE, gut für einsteiger

[bluecode]

Nur schade, dass das Projekt scheinbar tot ist (ich meine Dev-Cpp )

Blödsinn, im Vergleich zu djgpp ist das doch quicklebendig.

[ehenkes]

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/

[kevin]

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.

[ChristianF]

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:

Code: [Auswählen]

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

[Jidder]

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.

[ChristianF]

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

[Jidder]

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.

[ChristianF]

Habe ich mal gemacht und es funktioniert...
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)

[Coffee]

Ich nutze:

-Dev-Cpp & NASM zum OS-DEV
-sonst MS Visual Studio 2008 Professional

liebe Grüße

[ChristianF]

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