Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: bscreator 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
-
Und wir sollen jetzt erraten, wie dein Kernel aussieht oder in welcher Sprache er überhaupt geschrieben ist?
-
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
-
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
-
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...
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.
-
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
-
alles was includiert wird Teil der betreffenden Übersetzungs-Einheit,
Ganz genau das dachte ich auch
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
-
bochs und qemu können beide debuggen. Ersterer hat auch was eingebautes, glaube ich, bei letzterem benutzt man den gdb-Stub.
-
Und sowas wie "objdump" gibts das auch für Windows ?
Kann man mit BOCHS (bzw. mit QEMU) auch ím Einzelschrittmodus arbeiten ?
-
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.
-
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
-
Das mit Bochs hat sich erledigt.
Aber so wie es aussieht, ist jidders crosscompiler oder mingw nur für Windows-C-Programme geeignet, oder ?
-
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
-
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.
-
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.
-
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.
-
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 ? :?
-
Wenn du mal den ganzen Sourcecode zusammenpackst dann könnte ich mir das anschauen, aber so ist das reines Raten.
-
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 fr 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 fr 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
-
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
-
Klar, hab ich vergessen
Hier der Bootloader :
BOOT.ASM :
[BITS 16]
[ORG 0x7C00]
start:
;set stack segment
cli
mov ax,0x7c0
mov ss,ax
mov sp,0x03fe
sti
;set data segment
xor ax,ax
mov ds,ax
;print message
lea si,[msg_load]
call print_string
;load kernel at 0x0800:0x0000
call load_kernel
;jump to kernel
push es
push bx
retf
;+++++++++++++++++++++++++
msg_load db 'Loading...',0
;+++++++++++++++++++++++++
load_kernel:
mov ah,0x02
mov al,2
mov ch,0
mov cl,2
mov dh,0
mov bx,0x0800
mov es,bx
xor bx,bx
int 0x13
jmp processed
print_string:
lodsb
or al,al
jz processed
mov ah,0x0E
mov bx,0x0007
int 0x10
jmp print_string
processed:
ret
times 510-($-$$) db 0
dw 0xAA55
Compiliert hab ich das ganze mit NASM, mit
nasm -f bin -o boot.bin boot.asm
nasm -f bin -o kernel.bin kernel.asm
nasm -f bin -o proc.bin proc.asm
copy boot.bin+kernel.bin+proc.bin myos.img
-
Das wird zwar erstmal mit dem Problem nichts zu tun haben, aber warum meinst du die proc.asm noch assemblieren zu müssen? Du solltest dir mal genau anschauen was %include macht. :wink:
-
Soviel ich weiss, bindet %include den Code der Datei, welche mit include angegeben wurde, in das "Hauptprogramm" mit ein .
Ob ich die assembliere oder nicht, denk ich mal dass das nichts damit zu tun hat, da es ohne die print-Funktion ja funktioniert, auch wenn ich es assembliere und in eine bin-Datei umwandle...oder ?