Autor Thema: INCLUDE-Problem  (Gelesen 7421 mal)

bscreator

  • Gast
Gespeichert
« am: 06. April 2010, 21:12 »
Hallo,
ich versuch gerade, einige Dateien aus meinem Kernel zu schmeissen und diese in einer extra Datei namens PROC zu speichern, welche dann über INCLUDE eingebunden wird.

Wenn ich meine ganzen Variablen im Kernel in die PROC-Datei einfüge, dann funktioniert das ganze einwandfrei.
Wenn ich aber die Funktion print (siehe StupidOS) in die PROC-Datei einfüge, dann wird nur "LOADING..." ausgegeben, anstatt "LOADING...successful".

Warum funktioniert das ganze mit print nicht ?

Danke,
bsc

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 06. April 2010, 22:24 »
Und wir sollen jetzt erraten, wie dein Kernel aussieht oder in welcher Sprache er überhaupt geschrieben ist?
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

bscreator

  • Gast
Gespeichert
« Antwort #2 am: 06. April 2010, 22:38 »
Sorry,
der Kernel ist ganz in Assembler geschrieben:

BITS 16 ;Set code generation to 16 bit mode

jmp init

%include 'PROC.ASM'

command: times 5 db 0
msg_succ  db 'successful',13,10,0
msg_welc  db 'Welcome to RM-OS',13,10,0
msg_info  db 13,10,'RM-OS Kernel Version 0.1',0
cinfo     db 'info',0
creboot   db 'exit',0

init:
mov ax,0x0800
mov ds,ax
lea si,[msg_succ]
call print
lea si,[msg_welc]
call print

start:
call input            ;Tastatureingabefunktion

lea si,[cinfo]        ;Lade "exit" in DS:SI
call compare       ;Vergleiche Eingabe mit DS:SI
cmp al,1              ;Strings gleich ?
je info

lea si,[creboot]
call compare
cmp al,1
je reboot

jmp start

Ein kleiner Ausschnitt vom Kernel.
Und wie gesagt, die print-Funktion schaut aus wie im StupidOS.

Danke,
bsc

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 07. April 2010, 09:08 »
Hallo,


[.....]Ein kleiner Ausschnitt vom Kernel.
Der Code sieht eigentlich in Ordnung aus, an den CALLs kann ich nichts anstößiges finden.

.... wie im StupidOS.
Glaubst Du das ein OS mit dem Namen ein sinnvolles Vorbild ist? :wink:
Ich hab mir das jetzt nicht ich im Internet rausgesucht, ein Link auf genau den Code den Du meinst wäre sicherlich recht hilfreich.


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

bscreator

  • Gast
Gespeichert
« Antwort #4 am: 07. April 2010, 21:23 »
Die PROC-Datei:

print:
lodsb
or al,al
jz print_end
mov ah,0x0E
mov bx,0x0007
int 0x10
jmp print

print_end:
ret

Ich dachte, dass eine Datei, die mit INCLUDE eingebunden wird, ein Teil des Programms, in diesem Fall des Betriebssystems wird. Und somit müsste ja das Programm die richtige Meldung ausgeben. Das wundert mich eben...

Zitat
Glaubst Du das ein OS mit dem Namen ein sinnvolles Vorbild ist?
Naja, man sollte vom Namen nicht immer auf den Inhalt schliessen...

PS: Bin für jeden Ratschlag dankbar.
« Letzte Änderung: 07. April 2010, 21:55 von bscreator »

erik.vikinger

  • Beiträge: 1 277
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 07. April 2010, 22:06 »
Hallo,


[......]
Hm, auch da kann ich so nichts ungewöhnliches sehen.

Ich dachte, dass eine Datei, die mit INCLUDE eingebunden wird, ein Teil des Programms, in diesem Fall des Betriebssystems wird. Und somit müsste ja das Programm die richtige Meldung ausgeben. Das wundert mich eben...
Ich verstehe zwar nicht genau was Du meist aber üblicherweise wird alles was includiert wird Teil der betreffenden Übersetzungs-Einheit, ladet also in der selben Object-Datei. Vielleicht solltest Du dort mal mit einem geeignetem Analysetool (z.B. objdump) nachsehen.

PS: Bin für jeden Ratschlag dankbar.
Im Debugger Deines Vertrauens das ganze im Einzelschrittmodus verfolgen. Vielleicht siehst Du dort den Fehler.


Grüße
Erik
Reality is that which, when you stop believing in it, doesn't go away.

bscreator

  • Gast
Gespeichert
« Antwort #6 am: 07. April 2010, 23:18 »
Zitat
alles was includiert wird Teil der betreffenden Übersetzungs-Einheit,
Ganz genau das dachte ich auch

Zitat
Im Debugger Deines Vertrauens das ganze im Einzelschrittmodus verfolgen. Vielleicht siehst Du dort den Fehler.
Ich schreib meine Programme mit NASM. Aber bei NASM ist soviel ich weiss, kein Debugger mit Einzelschrittmodus dabei, nur der "pure" Asssembler.
Oder kennt ihr Debugger mit Einzelschrittmodus für NASM-Programme ?

Gruss,
bsc

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 07. April 2010, 23:26 »
bochs und qemu können beide debuggen. Ersterer hat auch was eingebautes, glaube ich, bei letzterem benutzt man den gdb-Stub.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

bscreator

  • Gast
Gespeichert
« Antwort #8 am: 08. April 2010, 08:22 »
Und sowas wie "objdump" gibts das auch für Windows ?

Kann man mit BOCHS (bzw. mit QEMU) auch ím Einzelschrittmodus arbeiten ?

FreakyPenguin

  • Administrator
  • Beiträge: 301
    • Profil anzeigen
    • toni.famkaufmann.info
Gespeichert
« Antwort #9 am: 08. April 2010, 09:48 »
Jo gibt es, zum Beispiel aus Jidders Crosscompiler im Wiki, oder wenn dir die unterstützten Formate reichen auch aus mingw.

Und ja, können sie.

bscreator

  • Gast
Gespeichert
« Antwort #10 am: 10. April 2010, 14:16 »
Und wie kann man im neuesten Bochs (2.2-1) einen Source Debuggen, bzw. im Einzelschritt durchgehen ?

Hab mal im Internet geschaut, aber nur ein Tutorial für die Bochs Version 2.4-1 gefunden, was bei der neuen Version nicht funktioniert.

Vielen Dank,
bsc
« Letzte Änderung: 10. April 2010, 14:18 von bscreator »

bscreator

  • Gast
Gespeichert
« Antwort #11 am: 10. April 2010, 14:32 »
Das mit Bochs hat sich erledigt.

Aber so wie es aussieht, ist jidders crosscompiler oder mingw nur für Windows-C-Programme geeignet, oder ?
« Letzte Änderung: 10. April 2010, 14:35 von bscreator »

O_mega

  • Beiträge: 9
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 10. April 2010, 14:40 »
Hallo,

wie hat sich das mit Bochs bzw. Qemu erledigt.
Hast du diesen Modus gefunden?
Oder brauchst du das nicht mehr?

Viele Grüße

O_mega

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #13 am: 10. April 2010, 21:32 »
Aber so wie es aussieht, ist jidders crosscompiler oder mingw nur für Windows-C-Programme geeignet, oder ?
Eben genau dafür nicht, deswegen nennt man es Crosscompiler.
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

bscreator

  • Gast
Gespeichert
« Antwort #14 am: 11. April 2010, 13:08 »
Ich hab zuerst mal einen einfachen Bootloader debuggt. Aber irgendwie ist der nie zum Ende gekommen. Der wurde immer wieder fortgeführt, obwohl der Bootloader eigentlich ganz kurz ist.
Aber den INCLUDE-Fehler, glaub ich, kann man mit Bochs nicht finden. Das liegt wahrscheinlich am NASM-Assembler.

Ich wollte nur die print - Funktion zum Ausgeben eines Strings in eine seperate Datei schreiben, damit der OS-Code übersichtlicher bleibt und diese dann mit INCLUDE einbinden.
Aber komischerweise geht es bei print nicht. Leider find ich den Grund dafür nicht.

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #15 am: 11. April 2010, 16:40 »
wie hat sich das mit Bochs bzw. Qemu erledigt.
Hast du diesen Modus gefunden?
Unter Windows dürfte es da eine bochsdbg.exe oder so ähnlich geben. Unter Linux muss man wenn ich mich recht entsinne bochs selbst kompilieren und bei ./configure eben die richtige Option angeben.
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

bscreator

  • Gast
Gespeichert
« Antwort #16 am: 12. April 2010, 09:07 »
Ich hab einfach mal die BOCHS-Debug ausprobiert und die Befehle, die ich gefunden hab, angewandt. Da ich Bochs für Windows verwende, ist das keine grosse Heldentat.

Aber habt ihr vielleicht eine Idee, warum ich die print-Funktion nicht in eine seperate Datei stecken und mit INCLUDE einbinden kann ? :?

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #17 am: 12. April 2010, 12:13 »
Wenn du mal den ganzen Sourcecode zusammenpackst dann könnte ich mir das anschauen, aber so ist das reines Raten.
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

bscreator

  • Gast
Gespeichert
« Antwort #18 am: 12. April 2010, 20:50 »
Im Folgenden ist eine kurze Erläuterung zum KERNEL :

input : Über diese Funktion kann der Benutzer Befehle eingeben
compare : vergleicht 2 Strings miteinander
info : gibt eine kurze Meldung zur Version aus
reboot : selbsterklärend
print : selbsterklärend
Die Funktion "start" ist sozusagen  die main, da diese immer wiederholt wird, bis exit eingegeben wird. Die Variablen befinden sich in der PROC.ASM und werden problemlos eingebunden.

Die Datei KERNEL.ASM :
BITS 16 ;Set code generation to 16 bit mode

jmp init

%include 'PROC.ASM'

init:
mov ax,0x0800
mov ds,ax
lea si,[msg_succ]
call print_string
lea si,[msg_welc]
call print_string

start:
call input         ;Aufruf Input

lea si,[cinfo]       ;Lade "exit" in DS:SI
call compare       ;Funktion vergleichen
cmp al,1           ;Strings gleich ?
je info

lea si,[creboot]
call compare
cmp al,1
je reboot

jmp start


;************************************************
;Funktion fr Tastenein- und -ausgaben
;Erweitert um funktionierende Eingabebeschr„nkung
input:
xor di,di
input_loop:
mov ah,0x00          ;Funktion Tastatureingabe
int 0x16
cmp al,0x0D          ;Carriage-Return ?
je input_end         ;Falls ja, Ende
mov [command+di],al  ;in Array schreiben
mov ah,0x0E          ;Funktion Taste ausgeben
mov bx, 0x0007
int 0x10
inc di               ;n„chstes Byte von command
cmp di,7
je input
jmp input_loop

input_end:
mov al,0
mov [command+di],al
ret
;Ende Funktion fr Tastenein- und -ausgaben
;Erweitert um funktionierende Eingabebeschr„nkung
;************************************************

;************************************************
;Funktion zum Vergleichen zweier Strings
compare:
xor di,di             ;DI=0
compare_loop:
lodsb                 ;Hole Zeichen aus dem durch DS:SI adres. String
mov ah,[command+di]   ;Hole Zeichen aus command
cmp al,ah             ;Zeichen gleich ?
jne compare_false     ;falls nein -> Ende und ungleich
cmp al,0              ;Stringende erreicht ?
je compare_true       ;falls ja -> Ende und gleich
inc di
jmp compare_loop
compare_true:
mov al,1              ;Strings gleich -> al=1
ret
compare_false:
mov al,0              ;Strings ungleich -> al=0
ret
;Ende Funktion zum Vergleichen zweier Strings
;***********************************************

info:
lea si,[msg_info]
call print_string
jmp short start

reboot:
db 0EAh
dw 0000h
dw 0FFFFh



Die Datei PROC.ASM :
command: times 7 db 0  ;Size command-Buffer
size      db 7         ;Anzahl max. Befehlszeichen
msg_succ  db 'successful',13,10,0
msg_welc  db 'Welcome to RM-OS',13,10,0
msg_info  db 13,10,'RM-OS Kernel Version 0.1',0
cinfo     db 'info',0
creboot   db 'exit',0

print_string:
lodsb
or al,al
jz print_string_end
mov ah,0x0E
mov bx,0x0007
int 0x10
jmp print_string

print_string_end:
ret

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #19 am: 12. April 2010, 22:40 »
Wenn du jetzt noch den Bootloader, wie du das ganze assemblierst und wie man ein Image mit Bootloader+Kernel erstellt angibst, könnte ich das fast testen. :-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

 

Einloggen