Autor Thema: Eure Entwicklungseinrichtung auf Windows Systemen  (Gelesen 21419 mal)

kernel64

  • Beiträge: 1
    • Profil anzeigen
Gespeichert
« 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 :-)
« Letzte Änderung: 26. April 2009, 21:14 von kernel64 »

ehenkes

  • Gast
Gespeichert

ChristianF

  • Beiträge: 296
    • Profil anzeigen
    • DeutschOS - Betriebssystem Projekt
Gespeichert
« Antwort #2 am: 12. May 2009, 10:36 »
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 ....

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 12. May 2009, 11:07 »
Wenn du den Cross Compiler nutzt, solltest du keine _ vor den Funktionsnamen im Assemblercode machen.
Dieser Text wird unter jedem Beitrag angezeigt.

ChristianF

  • Beiträge: 296
    • Profil anzeigen
    • DeutschOS - Betriebssystem Projekt
Gespeichert
« Antwort #4 am: 12. May 2009, 13:16 »
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

  • Beiträge: 113
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 12. May 2009, 13:26 »
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
Hacker zu sein bedeutet mehr, als sich nur damit auseinander zu setzen, es ist eine Lebenseinstellung

AcidIO

  • Beiträge: 11
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 12. May 2009, 15:00 »
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.
Wer nichts wagt kann nichts verlieren...

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #7 am: 12. May 2009, 15:44 »
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?
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

ChristianF

  • Beiträge: 296
    • Profil anzeigen
    • DeutschOS - Betriebssystem Projekt
Gespeichert
« Antwort #8 am: 12. May 2009, 16:19 »
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

  • Beiträge: 113
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 12. May 2009, 18:03 »
Ist es auch aber schon seit längerem, war aber eine einfache IDE, gut für einsteiger
Hacker zu sein bedeutet mehr, als sich nur damit auseinander zu setzen, es ist eine Lebenseinstellung

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #10 am: 12. May 2009, 18:05 »
Nur schade, dass das Projekt scheinbar tot ist (ich meine Dev-Cpp ;))
Blödsinn, im Vergleich zu djgpp ist das doch quicklebendig. :-D
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

ehenkes

  • Gast
Gespeichert
« Antwort #11 am: 12. May 2009, 18:57 »
Zitat
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

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 12. May 2009, 19:38 »
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.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

ChristianF

  • Beiträge: 296
    • Profil anzeigen
    • DeutschOS - Betriebssystem Projekt
Gespeichert
« Antwort #13 am: 13. May 2009, 07:48 »
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

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #14 am: 13. May 2009, 11:21 »
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.
Dieser Text wird unter jedem Beitrag angezeigt.

ChristianF

  • Beiträge: 296
    • Profil anzeigen
    • DeutschOS - Betriebssystem Projekt
Gespeichert
« Antwort #15 am: 13. May 2009, 11:45 »
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

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #16 am: 13. May 2009, 12:03 »
Also objdump mit deiner start.o zeigt für die Symbole sowas an:
Zitat
00000000         *UND*  00000000 isr0
und wenn ich sie selbst assembliere:
Zitat
0000005a g       .text  00000000 isr0
Du könntest es mal mit einem mal [section .text] am Anfang probieren.
« Letzte Änderung: 13. May 2009, 12:05 von PorkChicken »
Dieser Text wird unter jedem Beitrag angezeigt.

ChristianF

  • Beiträge: 296
    • Profil anzeigen
    • DeutschOS - Betriebssystem Projekt
Gespeichert
« Antwort #17 am: 13. May 2009, 13:38 »
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) ;)

Coffee

  • Beiträge: 470
    • Profil anzeigen
Gespeichert
« Antwort #18 am: 15. May 2009, 21:06 »
Ich nutze:

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

liebe Grüße

ChristianF

  • Beiträge: 296
    • Profil anzeigen
    • DeutschOS - Betriebssystem Projekt
Gespeichert
« Antwort #19 am: 15. May 2009, 21:14 »
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...

 

Einloggen