Thema: Programm laden und ausführen

[ehenkes]

Hexzahlen als Ausgabe wären hier eigentlich sinnvoller

ja, sofort erledigt.

Normal hätte ich jetzt an den GDT-Einträgen gezweifelt

Zurecht! ich hatte da noch einen Murks drinnen, nämlich:

Code: [Auswählen]

#ifdef USERMODE   // in os.h
    //gdt_set_gate(3, 0, 0xFFFFFFFF, 0xFA, 0xCF); // User mode code segment
    //gdt_set_gate(4, 0, 0xFFFFFFFF, 0xF2, 0xCF); // User mode data segment
    #endifd.h. gate 3 und 4 waren überhaupt nicht gesetzt!

Nun habe ich das korrigiert:

Code: [Auswählen]

void gdt_install()
{
    /* Setup the GDT pointer and limit */
    gdt_register.limit = (sizeof(struct gdt_entry) * NUMBER_GDT_GATES)-1;
    gdt_register.base  = (ULONG) &gdt;

    /* GDT GATES -  desriptors with pointers to the linear memory address */
    gdt_set_gate(0, 0, 0, 0, 0);                // NULL descriptor
    gdt_set_gate(1, 0, 0xFFFFFFFF, 0x9A, 0xCF); // CODE, privilege level 0 for kernel code
    gdt_set_gate(2, 0, 0xFFFFFFFF, 0x92, 0xCF); // DATA, privilege level 0 for kernel code

    #ifdef KERNELMODE // in os.h
    gdt_set_gate(3, 0, 0xFFFFFFFF, 0x9A, 0xCF); // CODE, privilege level 0 for kernel code
    gdt_set_gate(4, 0, 0xFFFFFFFF, 0x92, 0xCF); // DATA, privilege level 0 for kernel code
    #endif

    #ifdef USERMODE   // in os.h
    gdt_set_gate(3, 0, 0xFFFFFFFF, 0xFA, 0xCF); // User mode code segment
    gdt_set_gate(4, 0, 0xFFFFFFFF, 0xF2, 0xCF); // User mode data segment
    #endif

    write_tss(5, 0x10, 0x0);                    // num, ss0, esp0

    gdt_flush((ULONG)&gdt_register); // inclusive gdt_load() in assembler code
    tss_flush();                     //in flush.asm: privilege level 3 for kernel mode 0x2B
}

Leider ist das noch nicht die Lösung. Nächste Fehlermeldung:

Code: [Auswählen]

TSS log:
esp0: 40212000h ss0: 10h ... es: 10h cs: 08h ss: 10h ds: 10h fs: 10h gs: 10h

err_code: 00000FF4h address(eip): 000082ABh ... cs: 08h ds: 23h es: 23h fs: 23h gs 23h ss 1Bh int_no 13 eflags 00010012h useresp 0000836Ah
General Protection Fault >>> Exception. System Halted! <<<

[kevin]

Normal hätte ich jetzt an den GDT-Einträgen gezweifelt

Zurecht! ich hatte da noch einen Murks drinnen, nämlich:

Code: [Auswählen]

#ifdef USERMODE   // in os.h
    //gdt_set_gate(3, 0, 0xFFFFFFFF, 0xFA, 0xCF); // User mode code segment
    //gdt_set_gate(4, 0, 0xFFFFFFFF, 0xF2, 0xCF); // User mode data segment
    #endifd.h. gate 3 und 4 waren überhaupt nicht gesetzt!

Gut. Dann zweifle ich jetzt zusätzlich noch an deiner Exceptionmeldung, denn ss = 0x23 hätte dann eigentlich auch nicht sein dürfen.

err_code: 00000FF4h address(eip): 000082ABh ... cs: 08h ds: 23h es: 23h fs: 23h gs 23h ss 1Bh int_no 13 eflags 00010012h useresp 0000836Ah

Kannst du eip mal auflösen, wo das genau ist? Ich tippe mal auf das iret. Anscheinend sind wir jetzt immerhin schonmal mit den Segmentregistern im Userspace. Ich würde vermuten, dass das jetzt was mit dem TSS zu tun hat. Vielleicht mal die Intel-Doku anschauen, was dieser Errorcode bedeuten könnte.


Wenn du willst, kannst du auch mal einen Minimalkernel anschauen, den ich letztes Wochenende geschrieben habe, um ein bisschen herumzuexperimentieren. Das ist so ungefähr das minimale, was man für Multitasking mit Ring-3-Tasks braucht.

Was den Taskswitch betrifft, solltest du dich aber besser an das halten, was du schon hast. Das ist zwar eine interessante Variante, die ich da gebastelt habe (und verstehen versuchen schadet sicher nichts), aber sie ist grundlegend kaputt (Interrupts/Exceptions im Kernel gehen nicht).

[ehenkes]

Kannst du eip mal auflösen, wo das genau ist? Ich tippe mal auf das iret.

Ja, stimmt genau: [0x000082ab] 0008:00000000000082ab (unk. ctxt): iretd

Den error code finde ich nicht im Intel Manual. Da steht aber folgendes in 3A:

5.13 ERROR CODE
When an exception condition is related to a specific segment, the processor pushes an error code onto the stack of the exception handler (whether it is a procedure or task). The error code has the format shown in Figure 5-6. The error code resembles a segment selector; however, instead of a TI flag and RPL field, the error code contains 3 flags:

EXTExternal event (bit 0) — When set, indicates that an event external to the program, such as a hardware interrupt, caused the exception.

IDTDescriptor location (bit 1) — When set, indicates that the index portion of the error code refers to a gate descriptor in the IDT; when clear, indicates that the index refers to a descriptor in the GDT or the current LDT.

TIGDT/LDT (bit 2) — Only used when the IDT flag is clear. When set, the TI flag indicates that the index portion of the error code refers to a segment or gate descriptor in the LDT; when clear, it indicates that the index refers to a descriptor in the current GDT. The segment selector index field provides an index into the IDT, GDT, or current LDT to the segment or gate selector being referenced by the error code. In some cases the error code is null (that is, all bits in the lower word are clear). A null error code indicates that the error was not caused by a reference to a specific segment or that a null segment descriptor was referenced in an operation.

FF4h = 111111110100

EXT = 0 (bit0)
IDT = 0 (bit1) ==> indicates that the index refers to a descriptor in the GDT
TI = 1 (bit2) ==> indicates that the index portion of the error code refers to a segment

Schneidet man den Segment-Selektor raus:
111111110 = 1FEh   

Übrigens: ss 1Bh darf doch nicht sein? Das müsste doch entweder 0x10 (data kernelmode) oder 0x23 (data usermode) sein?

Ich setze aber brav:

Code: [Auswählen]

    // data segment registers
    if(privilege == 0) data_segment = 0x10;
    if(privilege == 3) data_segment = 0x23; // 0x20|0x3=0x23

    *(--kernel_stack) = data_segment;
    *(--kernel_stack) = data_segment;
    *(--kernel_stack) = data_segment;
    *(--kernel_stack) = data_segment;

    //setup TSS
    tss_entry.ss0   = 0x10;
    tss_entry.esp0  = new_task->kernel_stack;
    tss_entry.ss    = data_segment;


Ich habe noch task-Strukur und Setzen von TSS-Werten etwas erweitert, bringt aber keine Besserung. 

[ehenkes]

Da ich den entscheidenden Fehler zur Zeit nicht finde (wahrscheinlich suche ich an der falschen Stelle), poste ich mal meinen Code:

http://www.henkessoft.de/OS_Dev/Downloads/36y_user.zip

... in der Hoffnung, dass dies den push zum user mode bringt.

[kevin]

Ich nehme an, ich soll einfach MyOS.bin als Floppy nehmen. Damit kriege ich keinen GPF, sondern er springt einfach irgendwann ins Nirvana. Neu durchbauen kann ich nicht, weil die Makefile offensichtlich für Windows gedacht ist und ich keine Ahnung habe, was die Binärprogramme im Verzeichnis anstellen sollen.

Aber wenn ich es richtig sehe, ist deine TSS-Definition falsch. Bei den 16-Bit-Feldern hast du das reserved und den Eintrag genau falschrum. Zumindest für ss solltest du das ändern, der Rest wird ja nicht benutzt. Das dürfte aber erst beim Rücksprung einen Fehler geben, insofern ist sicher auch noch irgendwas anderes nicht in Ordnung.

Edit: Also eine MyOS.bin habe ich jetzt gebaut bekommen, bootet aber nicht. Keine Ahnung, ob ich was falsch gemacht habe oder einfach der Bootloader nur zufällig bei dir tut. Ich habe jetzt auch keine großartige Lust, das zu debuggen.

[ehenkes]

Da ich bei mir gerade nicht weiter komme, habe ich mir deinen Minimalkernel angeschaut.

Da ist mir aufgefallen, dass ich die Alignment Check Exception anders aufgestzt hatte als bei dir:

Code: [Auswählen]

; 17: Alignment Check Exception (With Error Code!)
_isr17:
    cli
    ;push dword 0  ; correct?
    push dword 17
    jmp isr_common_stub
Ist da so wirklich o.k.?

Ansonsten habe ich eine Unsymmetrie bei mir, bezüglich der ich nicht weiß, ob es stört oder nicht:

Ich habe z.Z. einen fault_handler für die exceptions, über den ich auch den Software Interrupt (0x7F) für die Syscalls abwickle:

Code: [Auswählen]

isr_common_stub:
    ;pusha
    push eax
    push ecx
    push edx
    push ebx
     ;push esp
    push ebp
    push esi
    push edi

    push ds
    push es
    push fs
    push gs

    mov ax, 0x10
    mov ds, ax
    mov es, ax
    mov fs, ax
    mov gs, ax
   
    mov eax, esp
    push eax
    mov eax, _fault_handler
    call eax
    pop eax

    pop gs
    pop fs
    pop es
    pop ds
   
;popa
    pop edi
    pop esi
    pop ebp
       ;pop esp
    pop ebx
    pop edx
    pop ecx
    pop eax

    add esp, 8
    iret 

... auf der anderen Seite habe ich einen _irq_handler1 für IRQ0 bis IRQ15, den ich nach eurem Vorbild aufgebaut habe:

Code: [Auswählen]

irq_common_stub:
    push eax
    push ecx
    push edx
    push ebx
    push ebp
    push esi
    push edi

    push ds
    push es
    push fs
    push gs

    mov ax, 0x10
    mov ds, ax
    mov es, ax
    mov fs, ax
    mov gs, ax

    push esp                  ; parameter of _irq_handler1
    call _irq_handler1    ; 
    global _irq_tail
    _irq_tail:
    mov esp, eax          ; return value: changed or unchanged esp

    pop gs
    pop fs
    pop es
    pop ds
   
    pop edi
    pop esi
    pop ebp
    pop ebx
    pop edx
    pop ecx
    pop eax

    add esp, 8
    iret
In irq_handler1 läuft momentan das direkte task_switching ab.

[ehenkes]

Danke, dass Du es versucht hast. Vielleicht kann PorkChicken mir helfen. Zumindest hat er es das letzte Mal geschafft beim Multitasking. Er ist genial.

Wahrscheinlich verwendest Du einen Linker, der kein aout-Format (wegen 16/32 bit Mischung in kernel.asm) kann.

Mal was anderes:

Code: [Auswählen]

task_t* task5 = create_task (syscall_test, 0);

void test()                   
{
  while(TRUE)
  {
      syscall_puts("5u");
  }

}
Da gibt es bei mir das Problem, das ich mit dem Task_Switching nicht mehr ran komme, also Endlosschleife im fault_handler/syscall.

Nehme ich das while weg,

Code: [Auswählen]

void test()
{
       syscall_puts("5u");
}dann gibt es beim Rücksprung ein Problem auf dem Stack.

44444444444444444444444444444444444444444444444444444444444444444444444444444444
5uPage Fault (page not present) at 123890ABh - EIP: 123890ABh

So etwas hatte ich schon mal, dass die magic number vom heap kommt.
Da war zu wenig auf dem Stack. Dadurch wurde diese Nummer geholt.
Sieht alles nicht gut aus. 
 

Aber wenn ich es richtig sehe, ist deine TSS-Definition falsch. Bei den 16-Bit-Feldern hast du das reserved und den Eintrag genau falschrum.

Umdrehen hat nix gebracht. Aber ich war wirklich sicher, dass es stimmt (habe es gemäß Intel Manual aufgebaut, das höherwertige Byte nach dem niederwertigen). Von daher bin ich nicht sicher, ob Du da wirklich Recht hast. Leider habe ich das so bisher nirgends gesehen, so dass ich nicht vergleichen kann.

[kevin]

Da ich bei mir gerade nicht weiter komme, habe ich mir deinen Minimalkernel angeschaut.

Da ist mir aufgefallen, dass ich die Alignment Check Exception anders aufgestzt hatte als bei dir:

Code: [Auswählen]

; 17: Alignment Check Exception (With Error Code!)
_isr17:
    cli
    ;push dword 0  ; correct?
    push dword 17
    jmp isr_common_stub
Ist da so wirklich o.k.?

Welche Interrupts einen Errorcode haben, habe ich aus dem qemu-Code abgeschrieben, die sollten also eigentlich passen. Das Intel-Manual sagt  für 17 auch "Exception Error Code: Yes (always zero)." Also hier nicht nochmal extra eine 0 draufpushen.

Ansonsten habe ich eine Unsymmetrie bei mir, bezüglich der ich nicht weiß, ob es stört oder nicht:

Wozu ist das denn nötig? Der Code sieht sehr ähnlich aus, mit dem einzigen Unterschied, dass der fault_handler kein neues esp zurückgibt. Oder übersehe ich da noch was? Aber theoretisch dürfte das nicht stören, solange die Faulthandler keinen Taskswitch machen.

[ehenkes]

Aber theoretisch dürfte das nicht stören, solange die Faulthandler keinen Taskswitch machen.

Machen sie nicht.

Zum Compilieren/Linken nehme ich übrigens dies hier unter Windows: http://www.osdever.net/downloads/compilers/DJGPP-Installer-nocpp.exe
(wegen dem Linker, der auch aout kann)

Ich möchte das jetzt wegen eines Tutorials zunächst nicht ändern, weil ich GRUB erst später verwenden will. 

Diese User Mode Geschichte macht mir momentan echt Probleme.

[kevin]

Danke, dass Du es versucht hast. Vielleicht kann Port_Chicken mir helfen. Zumindest hat er es das letzte Mal geschafft beim Multitasking. 

Wahrscheinlich verwendest Du einen Linker, der kein aout-Format (wegen 16/32 bit Mischung in kernel.asm) kann.

Falls du es nicht bemerkt hast, du bist immer noch beim Multitasking.

Dass mein Linker kein a.out kann, würde ich mal ausschließen. Ansonsten hätte er nicht irgendwas produziert, sondern mit einem Fehler abgebrochen. Davon abgesehen ist a.out ja das alte native *nix-Format, das sollte mein Linux-ld also noch viel eher können als dein Windows-ld.

Er kommt ja auch bis zum "loading kernel ..." aber dann geht nichts mehr.

Nehme ich das while weg,

Code: [Auswählen]

void test()
{
       syscall_puts("5u");
}dann gibt es beim Rücksprung ein Problem auf dem Stack.

Dann läuft er ja wieder ins ret anstatt durch einen Syscall beendet zu werden, und auf dem Stack liegt keine Rücksprungadresse. Kann also gar nicht gehen.

Umdrehen hat nix gebracht. Aber ich war wirklich sicher, dass es stimmt (habe es gemäß Intel Manual aufgebaut, das höherwertige Byte nach dem niederwertigen). Von daher bin ich nicht sicher, ob Du da wirklich Recht hast. Leider habe ich das so bisher nirgends gesehen, so dass ich nicht vergleichen kann.

Hm, ich hatte die Grafik anders in Erinnerung...

Ich glaube du hast recht. Mein Minikernel tut ja und der setzt ganze 32-Bit-Words. Intel ist Little Endian, insofern setze ich da die ersten beiden Bytes. Ich nehme also alles zurück und behaupte das Gegenteil, tut mir leid.

[ehenkes]

Dann läuft er ja wieder ins ret anstatt durch einen Syscall beendet zu werden, und auf dem Stack liegt keine Rücksprungadresse. Kann also gar nicht gehen.

Ich rufe test als nicht als test, sondern als syscall_test auf. Das sollte z.B. im user-mode gehen. Die Frage ist, wie sollte ein syscall aussehen, der einen weiteren Task anstößt. Das müsste ein Interrupt sein wie z.B. IRQ0, das einen taskswitch auslöst. Ein syscall löst bei mir bisher keinen Taskswitch aus, nur die Exception-Schiene.

[kevin]

Syscalls sind üblicherweile (Software-)Interrupts.

Übrigens habe ich es mittlerweile hinbekommen, deinen Bootloader den Kernel laden zu lassen - im Linkerskript war rodata nicht berücksichtigt und deswegen ist die Reihenfolge durcheinandergekommen und der Kernel hat nicht mit Code angefangen. Habe ich schonmal erwähnt, dass flache Binaries doof sind?

Funktionieren tut der Kernel trotzdem nicht. Zwei Meldungen kommen am Anfang und dann marschiert eip munter durch den ganzen Speicher. Da ist wohl noch irgendwo ein falscher Sprung.

[ehenkes]

Übrigens habe ich es mittlerweile hinbekommen, deinen Bootloader den Kernel laden zu lassen - im Linkerskript war rodata nicht berücksichtigt und deswegen ist die Reihenfolge durcheinandergekommen und der Kernel hat nicht mit Code angefangen.

Toll! Kannst Du diese Verbesserung im Linker-Script bitte posten. Das kann ich ja bei mir einbauen und testen.

Funktionieren tut der Kernel trotzdem nicht. Zwei Meldungen kommen am Anfang und dann marschiert eip munter durch den ganzen Speicher. Da ist wohl noch irgendwo ein falscher Sprung.

Das musst Du mir mal richtig erklären. 

Syscalls sind üblicherweile (Software-)Interrupts.

Ja, bei mir auch (0x7F). Nur habe ich da den Taskswitch nicht mit verbunden.

Diese Verschachtelung von create_task(syscall_...) läuft daher so nicht. Momentan sehe ich aber auch nicht die Lösung.

[kevin]

Toll! Kannst Du diese Verbesserung im Linker-Script bitte posten. Das kann ich ja bei mir einbauen und testen.

Kein Problem, hier kommt der Patch:

Code: [Auswählen]

--- kernel.ld.orig      2009-04-03 22:16:00.000000000 +0200
+++ kernel.ld   2009-05-21 22:10:14.000000000 +0200
@@ -9,6 +9,9 @@ SECTIONS
   .data  : {
     *(.data)
   }
+  .rodata  : {
+    *(.rodata)
+  }
   .bss  :  {
     *(.bss)
   }

Funktionieren tut der Kernel trotzdem nicht. Zwei Meldungen kommen am Anfang und dann marschiert eip munter durch den ganzen Speicher. Da ist wohl noch irgendwo ein falscher Sprung.

Das musst Du mir mal richtig erklären. 

Hm, viel erklären kann ich nicht, weil ich nicht weiß, was genau passiert. Ich sehe folgende Meldung:

Code: [Auswählen]

Welcome to PrettyOS 0.08
HEAPhole 40081000h hole-size: 0017F0000hUnd dann passiert scheinbar gar nichts mehr. Um rauszukriegen, was er denn macht oder wo er hängt, habe ich dann ein paarmal info registers im qemu-Monitor genommen. Und das zeigt mir, dass er irgendwelchen Code ausführt, wo eigentlich gar nichts liegt.

Syscalls sind üblicherweile (Software-)Interrupts.

Ja, bei mir auch (0x7F). Nur habe ich da den Taskswitch nicht mit verbunden.

Diese Verschachtelung von create_task(syscall_...) läuft daher so nicht. Momentan sehe ich aber auch nicht die Lösung.

Zum Ausgleich verstehe ich das Problem nicht.

An welcher Stelle willst du denn ein create_task(syscall_...) einbauen und was soll das überhaupt bringen? Willst du den Syscall in einem neuem Kernelthread ausführen oder sowas?

[ehenkes]

Ich möchte eine Task im User Mode ausführen. daher habe ich diesen Parameter privilege bei create_task(...) dabei. Bisher klappt das aber noch nicht im User Mode, nur im Kernel Mode.

Ich dachte, das liegt z.B. daran, dass ich eine Funktion im Kernel wie z.B. test(...) direkt aufrufe. Daher habe ich syscall_test in syscall.h/syscall.c deklariert/definiert. Nehme ich die Endlos-while-Schleife, dann bleibt das im syscall "hängen", d.h. der Task kommt nicht zum iret des irq_handlers zurück, weil der iret des syscalls (läuft über fault_handler) nicht ausgelöst wird. Ohne syscall funktioniert das problemlos, weil da kein neuer Interrupt ausgelöst wurde, dann kommt das brav zum iret des irq_handlers zurück.

Lässt man die while-Schleife weg, kommt der iret des syscalls zum Zug, aber dann ist offenbar alles verschoben bezüglich des iret des irq_handlers von create_task. Ich weiß nicht, wie ich das analysieren und vor allem lösen soll

Diese Schachtelung von creat_task(start) - syscall(start) - ... - syscall(ende) - create_task(ende) habe ich also nur gebaut, um endlich mal einen richtigen user mode in Ring 3 zu testen. Wie soll ich das denn sonst machen?

[kevin]

Breakpoint z.B. vor das iret setzen und einfach mal den Stack an dieser Stelle anschauen?

[ehenkes]

Das mit den rodata habe ich eingebaut. Ich habe mal recherchiert und gefunden, dass es zwischen data und rodata (offenbar mingw-spezifisch) auch noch rdata gibt. Soll ich das zur Sicherheit auch noch einbauen? 

[kevin]

Was auch immer das sein soll, aber wenn's hilft... Abgesehen davon benutze ich kein mingw, also brauchst du es wegen mir nicht.

[ehenkes]

Breakpoint

Code: [Auswählen]

direkt vor iret nach irq_tail:

 | STACK 0x4020d7e8 [0x00008330] _surprise  - aufgerufene Fkt. von task 4
 | STACK 0x4020d7ec [0x00000008]
 | STACK 0x4020d7f0 [0x00000202]
 | STACK 0x4020d7f4 [0x00000000]
 | STACK 0x4020d7f8 [0x00000004]
 | STACK 0x4020d7fc [0x00000002]
 | STACK 0x4020d800 [0x123890ab]
 | STACK 0x4020d804 [0x4020cff4]
 | STACK 0x4020d808 [0x123890ab]
 | STACK 0x4020d80c [0x00000001]
 | STACK 0x4020d810 [0x000007ec]
 | STACK 0x4020d814 [0x00000000]
 | STACK 0x4020d818 [0x00000000]
 | STACK 0x4020d81c [0x00000000]
 | STACK 0x4020d820 [0x00000000]
 | STACK 0x4020d824 [0x00000000]

nach task 4 bei iret:

 | STACK 0x402117f4 [0x0000d672]  _syscall_test - aufgerufene Fkt. von task 5
 | STACK 0x402117f8 [0x00000008]
 | STACK 0x402117fc [0x00000202]
 | STACK 0x40211800 [0x123890ab]
 | STACK 0x40211804 [0x40210ff4]
 | STACK 0x40211808 [0x123890ab]
 | STACK 0x4021180c [0x00000001]
 | STACK 0x40211810 [0x000007ec]
 | STACK 0x40211814 [0x00000000]
 | STACK 0x40211818 [0x00000000]
 | STACK 0x4021181c [0x00000000]
 | STACK 0x40211820 [0x00000000]
 | STACK 0x40211824 [0x00000000]
 | STACK 0x40211828 [0x00000000]
 | STACK 0x4021182c [0x00000000]
 | STACK 0x40211830 [0x00000000]

vor nop in test (task 5):

 | STACK 0x40211710 [0x0000839b] ?? nicht in kernel.map  0x0000836e  test
 | STACK 0x40211714 [0x0000836a] ??
 | STACK 0x40211718 [0x00000000]
 | STACK 0x4021171c [0x00000000]
 | STACK 0x40211720 [0x00000000]
 | STACK 0x40211724 [0x00000000]
 | STACK 0x40211728 [0x00000000]
 | STACK 0x4021172c [0x40211770]
 | STACK 0x40211730 [0x0000d6cc]
 | STACK 0x40211734 [0x00000000]
 | STACK 0x40211738 [0x00000000]
 | STACK 0x4021173c [0x00000000]
 | STACK 0x40211740 [0x00000000]
 | STACK 0x40211744 [0x00000000]

vor dem ret von test:

 | STACK 0x40211730 [0x0000d6cc]  ??
 | STACK 0x40211734 [0x00000000]
 | STACK 0x40211738 [0x00000000]
 | STACK 0x4021173c [0x00000000]
 | STACK 0x40211740 [0x00000000]
 | STACK 0x40211744 [0x00000000]
 | STACK 0x40211748 [0x00000000]
 | STACK 0x4021174c [0x00000000]
 | STACK 0x40211750 [0x00000000]
 | STACK 0x40211754 [0x00000000]
 | STACK 0x40211758 [0x00000000]
 | STACK 0x4021175c [0x00000000]
 | STACK 0x40211760 [0x0000836e]
 | STACK 0x40211764 [0x00000000]
 | STACK 0x40211768 [0x402117bc]
 | STACK 0x4021176c [0x00000000]

vor noch einem ret ???

 | STACK 0x40211774 [0x00009668]  ??
 | STACK 0x40211778 [0x402117bc]
 | STACK 0x4021177c [0x00000000]
 | STACK 0x40211780 [0x00000000]
 | STACK 0x40211784 [0x00000000]
 | STACK 0x40211788 [0x00000000]
 | STACK 0x4021178c [0x00000000]
 | STACK 0x40211790 [0x00000000]
 | STACK 0x40211794 [0x00000000]
 | STACK 0x40211798 [0x00000000]
 | STACK 0x4021179c [0x00000000]
 | STACK 0x402117a0 [0x00000000]
 | STACK 0x402117a4 [0x00000000]
 | STACK 0x402117a8 [0x00000000]
 | STACK 0x402117ac [0x00000000]
 | STACK 0x402117b0 [0x402117fc]

und vor noch einem ret???

 | STACK 0x402117b4 [0x000081f6] ??
 | STACK 0x402117b8 [0x402117bc]
 | STACK 0x402117bc [0x00000010]
 | STACK 0x402117c0 [0x00000010]
 | STACK 0x402117c4 [0x00000010]
 | STACK 0x402117c8 [0x00000010]
 | STACK 0x402117cc [0x00000000]
 | STACK 0x402117d0 [0x00000000]
 | STACK 0x402117d4 [0x402117fc]
 | STACK 0x402117d8 [0x00000000]
 | STACK 0x402117dc [0x00000000]
 | STACK 0x402117e0 [0x00000000]
 | STACK 0x402117e4 [0x00000086]
 | STACK 0x402117e8 [0x0000007f]
 | STACK 0x402117ec [0x00000000]
 | STACK 0x402117f0 [0x0000d67c]
 | STACK 0x40211748 [0x00000000]
 | STACK 0x4021174c [0x00000000]

vor dem iret des syscalls:
(0) [0x00008207] 0008:0000000000008207 (unk. ctxt): iretd

 | STACK 0x402117f0 [0x0000d67c]  ??
 | STACK 0x402117f4 [0x00000008]
 | STACK 0x402117f8 [0x00000202]
 | STACK 0x402117fc [0x00000000]
 | STACK 0x40211800 [0x123890ab]
 | STACK 0x40211804 [0x40210ff4]
 | STACK 0x40211808 [0x123890ab]
 | STACK 0x4021180c [0x00000001]
 | STACK 0x40211810 [0x000007ec]
 | STACK 0x40211814 [0x00000000]
 | STACK 0x40211818 [0x00000000]
 | STACK 0x4021181c [0x00000000]
 | STACK 0x40211820 [0x00000000]
 | STACK 0x40211824 [0x00000000]
 | STACK 0x40211828 [0x00000000]
 | STACK 0x4021182c [0x00000000]

noch ein ret???

 | STACK 0x40211800 [0x123890ab] magic number of heap
 | STACK 0x40211804 [0x40210ff4]
 | STACK 0x40211808 [0x123890ab]
 | STACK 0x4021180c [0x00000001]
 | STACK 0x40211810 [0x000007ec]
 | STACK 0x40211814 [0x00000000]
 | STACK 0x40211818 [0x00000000]
 | STACK 0x4021181c [0x00000000]
 | STACK 0x40211820 [0x00000000]
 | STACK 0x40211824 [0x00000000]
 | STACK 0x40211828 [0x00000000]
 | STACK 0x4021182c [0x00000000]
 | STACK 0x40211830 [0x00000000]
 | STACK 0x40211834 [0x00000000]
 | STACK 0x40211838 [0x00000000]
 | STACK 0x4021183c [0x00000000]

(0).[41500949] ??? (physical address not available) // hier scheint schon alles zu spät

nun kommt noch der fault_handler ....



Code: [Auswählen]

void test()
{
      syscall_puts("5u");syscall_puts("5u");syscall_puts("5u");
      nop();
}

Code: [Auswählen]

task_t* task5 = create_task (syscall_test, 0);
Irgendwie noch nicht zielführend.   

[Jidder]

| STACK 0x40211710 [0x0000839b] ?? nicht in kernel.map

Da musst du die größte Adresse suchen, die kleiner ist als diese (oder gleich). Würdest du nicht ein flaches Binärformat nutzen, könntest du auch den Kernel disassemblieren und diese Adresse suchen. (Wenn du ihn jetzt einfach disassemblierst, dann musst du halt irgendwie so den Funktionsanfang finden und in kernel.map nachschauen.)