Hi,
Das Interessante hier ist nicht der Befehl selbst, sondern der Zustand der CPU. Der Wert des Befehlszählers (RIP bzw. EIP) ist 00000000006f0018, was weit ab von deinem Programm ist.
Als du die Ausgabe entfernt hast, hast du auch diesen String aus deinem Programm entfernt. Dann war der Datenbereich deines Programms leer und wieder der Code das erste in deinem Progamm. Das Fehler liegt also in dem Prozess, wie du den Kernel erstellst, nicht am Code des Kernels.
Der String landet in der *(.rodata) oder *(.rdata) Sektion je nach Compiler. Änder mal dein Linkerskript so, dass du die Sektionen erwähnst:
Außerdem würde ich dir mal empfehlen, dich mehr mit den Werkzeugen auseinander zu setzen. objdump kann dir viele Informationen über deine Objekt-Dateien (und über deinen Kernel solange er nicht eine Binärdatei ist) liefern, mit ndisasm, welches bei NASM dabei ist, kannst du den Kernel, wenn er eine flache Binärdatei ist, disassemblieren. Außerdem könntest du dich mal mit dem Debugger von Bochs auseinander setzen. Mit lb 0x7c00 kannst du da einen Breakpoint an den Anfang des Bootloaders setzen, mit c kommst du dann bis zu diesem Breakpoint, mit s kannst du single steppen und mit n kannst du einen step over (z.B. über BIOS Interrupts) machen.
All diese Programme haben außerdem Handbücher, die online verfügbar sind.
Wenn du den Code nicht als deinen erkennst, dann heißt das, dass dein Bootloader/Kernel irgendwo ins Nirvana springt, oder dass sich dein Kernel nicht an der Stelle befindet, wo der Bootloader hinspringt. Ich vermute letzteres.Code: [Auswählen]00065895575-i-@006f0018-[CPU0 ] >> add dword ptr ds:[eax], eax : 0100
ausgeführt wurde. Also muss da der Fehler sein.
Jedoch finde ich im Assembler-Code (boot.asm) kein
"add", aber den Register "eax".
Zitat
Die 0100 ähnelt der AddresseHinter dem Assemblerbefehl steht immer der Maschinencode in Hexadezimaldarstellung. Die Ähnlichkeit mit irgendwelchen Adressen hat an dieser Stelle nichts zu bedeuten. Wenn dein Programmfluss irgendwo im Nirvana landet, dann ist dieser Speicher einfach mit zufälligen Werten, je nach Art des Speichers auch mit Nullen (0x00) oder Einsen (0xFF) gefüllt.
dess Kernels, fehlt halt eine Null, die habe ich anschließend rangehängt
also beim jmp, jetzt siehts so aus:
Das Interessante hier ist nicht der Befehl selbst, sondern der Zustand der CPU. Der Wert des Befehlszählers (RIP bzw. EIP) ist 00000000006f0018, was weit ab von deinem Programm ist.
Zitat
Dies mal ist der Maschinencode wesentlich interessanter. 6520746F20 sieht aus wie ASCII Code und zwar entspricht der genau dem "e to " aus deinem "Welcome to Protected Mode". Das heißt die CPU versucht die Daten auszuführen, weil die Daten in deiner Binärdatei vor dem Code liegen.Code: [Auswählen]00002609039-i-@00010006-[CPU0 ] >> and byte ptr gs:[edi+ebp*2+0x20], dh : 6520746F20
00002609039-e-@00010006-[CPU0 ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting
Als du die Ausgabe entfernt hast, hast du auch diesen String aus deinem Programm entfernt. Dann war der Datenbereich deines Programms leer und wieder der Code das erste in deinem Progamm. Das Fehler liegt also in dem Prozess, wie du den Kernel erstellst, nicht am Code des Kernels.
Der String landet in der *(.rodata) oder *(.rdata) Sektion je nach Compiler. Änder mal dein Linkerskript so, dass du die Sektionen erwähnst:
Code: [Auswählen]
INPUT("kernel.o")
ENTRY(_begin)
SECTIONS
{
.text 0x10000 :
{
*(.text)
*(.rdata)
*(.rodata)
}
.data :
{
*(.data)
}
.bss :
{
*(.bss)
}
}Außerdem würde ich dir mal empfehlen, dich mehr mit den Werkzeugen auseinander zu setzen. objdump kann dir viele Informationen über deine Objekt-Dateien (und über deinen Kernel solange er nicht eine Binärdatei ist) liefern, mit ndisasm, welches bei NASM dabei ist, kannst du den Kernel, wenn er eine flache Binärdatei ist, disassemblieren. Außerdem könntest du dich mal mit dem Debugger von Bochs auseinander setzen. Mit lb 0x7c00 kannst du da einen Breakpoint an den Anfang des Bootloaders setzen, mit c kommst du dann bis zu diesem Breakpoint, mit s kannst du single steppen und mit n kannst du einen step over (z.B. über BIOS Interrupts) machen.
All diese Programme haben außerdem Handbücher, die online verfügbar sind.

Übersicht
Wiki
Hilfe
Suche
Einloggen
Registrieren
Drucken

Gespeichert

.
