Thema: Software Multitasking

[ehenkes]

error: action=report
info: action=report
debug: action=ignore

steht da bei mir.

Ja. ignore ist eben weniger Ausgabe als report.

Ich habe Report verwendet, ergibt mehrere 10000 Seiten Report. 

[ehenkes]

esp bei task A -> task A 

Code: [Auswählen]

      0018FFC4h
    0018FFC0h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
      0018FFC4h
        0018FFC8h
      0018FFC4h
      0018FFC4h
        0018FFC8h
      0018FFC4h
    0018FFC0h
0018FFB8h
0018FFB8h
    0018FFC0h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
      0018FFC4h
         0018FFC8h
0018FFB8h
      0018FFC4h
        0018FFC8h
      0018FFC4h
    0018FFC0h
0018FFB8h
      0018FFC4h
    0018FFC0h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
      0018FFC4h
        0018FFC8h
      0018FFC4h
      0018FFC4h
        0018FFC8h
      0018FFC4h
    0018FFC0h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
      0018FFC4h
        0018FFC8h
0018FFB8h
      0018FFC4h
        0018FFC8h
      0018FFC4h
    0018FFC0h
0018FFB8h
      0018FFC4h
    0018FFC0h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
      0018FFC4h
0018FFB8h
0018FFB8h
      0018FFC4h
        0018FFC8h
      0018FFC4h
    0018FFC0h
        0018FFC8h
      0018FFC4h
    0018FFC0h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
0018FFB8h
      0018FFC4h
        0018FFC8h
0018FFB8h
Für mich kein Muster erkennbar.

Ich poste mal den gesamten Sourcecode:
http://www.henkessoft.de/OS_Dev/Downloads/36m.zip
Vielleicht kann mir mal jemand genau erklären, wie man mit dem Bochs Debugger heraus bekommt, wo und warum diese Ereignisse ablaufen?

Ich komme da mit der Schritt-Technik einfach nicht an die wirklich interessanten Stellen, z.B. im asm-Stub und im task_switch. Wie macht ihr das genau? Setzt man da irgendwelche Haltepunkte im Code selbst oder läuft das über Adressen? Wenn ja woher bekommt man diese?

Vielleicht liegt der Fehler auch in den 5 Gates (Code, Daten, Code, Daten, TSS): siehe gdt.c, flush.asm, descriptor_tables.c, task.c

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

    //Kernel Mode:
    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

    //User Mode:
    //gdt_set_gate(3, 0, 0xFFFFFFFF, 0xFA, 0xCF); // CODE, privilege level 3 for user code
    //gdt_set_gate(4, 0, 0xFFFFFFFF, 0xF2, 0xCF); // DATA, privilege level 3 for user code

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

    gdt_flush((ULONG)&gdt_register); // inclusive gdt_load() in assembler code

    tss_flush(); //privilege level 3 for user mode 0x2B // in flush.asm
                 //privilege level 0 for kernel mode 0x28
}Gate 3 und 4 werden z.Z. noch im kernel mode (privilege 0) betrieben, sollen später aber auf 3 umgesetzt werden. TSS habe ich in flush.asm auch auf Privileg 0 gesetzt?! Mit 3 geht es aber auch nicht.
Syscalls gehen auch schon, daher wurde der user mode bereits getestet, muss aber auf Privileg 0 bleiben, da ich kernel code verwende und nicht nurFunktionen über syscall aufrufe. Mit den kernel stacks und user stacks komme ich konzeptionell auch noch nicht ganz klar.
Könnte da mal jemand rein schauen? Task switch erfolgt in task_switch1 (ganz unten in task.c).

[Jidder]

Für mich kein Muster erkennbar.

Sollte man auch nicht.

Ich poste mal den gesamten Sourcecode:
http://www.henkessoft.de/OS_Dev/Downloads/36m.zip

Hm, da ist ja eine Menge Zeug drin. Das müsste man ausgemistet werden. Ich steig da auf jeden Fall nicht durch. Ich würde vorschlagen nicht alles aus den Tutorials/anderen Systemen in einziges Programm zu stecken.

Vielleicht kann mir mal jemand genau erklären, wie man mit dem Bochs Debugger heraus bekommt, wo und warum diese Ereignisse ablaufen?

Ich komme da mit der Schritt-Technik einfach nicht an die wirklich interessanten Stellen, z.B. im asm-Stub und im task_switch. Wie macht ihr das genau? Setzt man da irgendwelche Haltepunkte im Code selbst oder läuft das über Adressen? Wenn ja woher bekommt man diese?

Mit einer Map-Datei. Die bekommst du, wenn du ld den Parameter -Map kernel.map übergibst. Dann stehen in der Datei kernel.map alle globalen Symbole. Da kannst du dir z.B. irq0 oder task_switch (oder isr_common_stub/irq_common_stub, wenn du diese global deklarierst) raussuchen, und die Adresse merken. Bei mir ist irq0 zum Beispiel 0x0000816a.

Wenn du in bochs im Debugger bist, kannst du da dann einen breakpoint mittels "lb 0x816a" setzen. Mit c kommst du dahin, und kannst dann mit s durchsteppen.

[ehenkes]

-Map kernel.map ... globale Symbole. ... irq0 zum Beispiel 0x0000816a ... bochs im Debugger bist, ... breakpoint mittels "lb 0x816a" setzen. Mit c kommst du dahin, und kannst dann mit s durchsteppen.

Super! Danke für den Tipp mit -Map. Musste ich bisher noch nicht so intensiv machen.

Hm, da ist ja eine Menge Zeug drin.

Fast nichts. Das soll ein OS werden. 

Ich steig da auf jeden Fall nicht durch.

Schade.  Bisher hast Du mir auf jeden Fall gut weiter geholfen.

[ehenkes]

EIP=9a07 ...

Ich weiß nicht, wohin du deinen Kernel legst (du benutzt ja kein GRUB), aber normal würde ich das als einen kaputten Wert ansehen.

PorkChicken:

Bei mir ist irq0 zum Beispiel 0x0000816a.

 

Es scheint noch mehr Leute zu geben, die ihren Kernel ziemlich direkt hinter dem bootloader anbringen.

[Jidder]

EIP=9a07 ...

Ich weiß nicht, wohin du deinen Kernel legst (du benutzt ja kein GRUB), aber normal würde ich das als einen kaputten Wert ansehen.

PorkChicken:

Bei mir ist irq0 zum Beispiel 0x0000816a.

 

Es scheint noch mehr Leute zu geben, die ihren Kernel ziemlich direkt hinter dem bootloader anbringen.

Ne, das ist dein OS. Nach dem Austausch deiner als Makefile getarnten Batch-Datei, war das doch recht einfach zum Laufen zu bringen

[ehenkes]

war das doch recht einfach zum Laufen zu bringen

Na super.  leider nur die Version mit task A -> task A in task_switch1
Darf ich mal fragen mit welchem Compiler Du dabei arbeitest, weil wir noch das Problem mit dem notwendigen aout-Format und dem Linker haben.

Ich habe nun das Debugging beim echten task_switch entsprechend deinem Vorschlag durchgeführt, habe _irq0 und _task_switch1 als breakpoint gesetzt, bin aber nicht an die Stelle gekommen, wo der GPF direkt auftritt. Das bringt mich momentan irgendwie nicht weiter, sitze wirklich fest.

[Jidder]

Ich verwende einen Cross Compiler für ELF unter Windows (gcc 4.3.1), den ich selbst gebaut habe. Ich habe bei mir deswegen auch bei den Assembler-Aufruf aout durch elf ersetzt.

edit: verlesen -.-

[ehenkes]

Ich verwende einen Cross Compiler für ELF unter Windows (gcc 4.3.1), den ich selbst gebaut habe. Ich habe bei mir deswegen auch bei den Assembler-Aufruf aout durch elf ersetzt.

Hast Du das irgendwo beschrieben, wie man das macht? Denn das wäre wirklich interessant.

[Jidder]

Ich hab die Anleitung auf osdev.org befolgt. In unserem Wiki ist aber auch eine, die genauso gut ist: http://lowlevel.brainsware.org/wiki/index.php/Cross-Compiler

Beide sollten ohne große Änderungen in einer aktuellen MinGW/MSYS Umgebung funktionieren.

[ehenkes]

Danke für die Links!

Ich habe deinen Rat befolgt und entrümpelt (VFS, RAM disk, User Gates, Syscall alles weg): http://www.henkessoft.de/OS_Dev/Downloads/36n.zip

Die Reaktion ist noch gleich: GPF
Beim diesbezüglichen Error-Log stimmt etwas nicht mit den Daten in regs.
Nun gibt es nur noch paging, heap, tasking.
Vielleicht findest Du nun leichter durch und damit den entscheidenden Fehler.

 

[Jidder]

Hm, mal schauen. Also ich hab natürlich noch viel mehr gefunden, was da raus kann. Ohne jetzt tief in deinem Code bohren zu wollen, hab ich einfach mal meine Entfernen-Taste etwas strapaziert und Funktion-/Block-/Zeilenweise deinen Code gelöscht. Deine main-Methode ist ein 10-Zeiler und kernel.asm ist auch nur noch ein Schatten seiner selbst.

Also ich habs soweit reduziert, dass für mich das fork() als der Übeltäter aussieht. Im Kernel forkt man nicht. Das macht auch irgendwie keinen Sinn. Ich sehe da außerdem nicht, wo du den Stack kopierst. Das kernel_directory->tables == src->tables ist auch falsch, weil die CPU in deinem aktuellen Page Directory das Dirty Flag setzen kann. (Oder wie auch immer das heißt.)

Im allgemeinen ist fork() sowieso zu kompliziert. Ein create_task tuts auch.  (Erstellt einen neuen Task, für den nur der Einsprungspunkt vorgegeben ist, nicht der ganze Prozess)

Bei mir funktionieren folgende Änderungen (an 36n.zip):

ckernel.c

Code: [Auswählen]

#include "os.h"
#include "kheap.h"
#include "task.h"

extern page_directory_t* current_directory;
extern task_t* current_task;
extern tss_entry_t tss_entry;
extern ULONG read_eip();

void moo()
{
while(1) printformat("MOO %d", getpid()); // <-- kuh
}

void baa()
{
while(1) printformat("BAA %d", getpid()); // <- schaf
}

int main()
{
    printformat("Welcome to PrettyOS 0.07\n");

    // GDT, IDT, ISRS, IRQ, timer, keyboard, paging, enable interrupts, RAM disk, multitasking
    gdt_install();
    idt_install();
    isrs_install();
    irq_install();
    initODA();
    timer_install();
    keyboard_install();
    sti();
    paging_install();
    tasking_install();

create_task(moo);
create_task(baa);

    pODA->ts_flag = 1;

while(1) printformat("%d", getpid());
return 0;
}
task.c neue Funktion:

Code: [Auswählen]

extern void irq_tail();
void create_task(void *entry)
{
    task_t* parent_task = (task_t*)current_task;
    page_directory_t* directory = clone_directory(current_directory);
    task_t* new_task = (task_t*)k_malloc(sizeof(task_t),0,0);

    new_task->id  = next_pid++;
    new_task->page_directory = directory;
    new_task->kernel_stack = k_malloc(KERNEL_STACK_SIZE,1,0)+KERNEL_STACK_SIZE;
    new_task->next = 0;

    task_t* tmp_task = (task_t*)ready_queue;
    while (tmp_task->next)
        tmp_task = tmp_task->next;
    tmp_task->next = new_task; // ... and extend it

unsigned int *kernel_stack = (unsigned int*)new_task->kernel_stack;

    //*(--kernel_stack) = 0x23; // ss
    //*(--kernel_stack) = USER_STACK_VIRT + USER_STACK_SIZE - 0x4;
    *(--kernel_stack) = 0x0202; // eflags = interrupts aktiviert und iopl = 0
    *(--kernel_stack) = 0x08; // cs
    *(--kernel_stack) = (unsigned int)entry; // eip

    *(--kernel_stack) = 0; // interrupt nummer
    *(--kernel_stack) = 0; // error code

    // general purpose registers
    //*(--kernel_stack) = 0; // eins von denen ist esp
    *(--kernel_stack) = 0;
    *(--kernel_stack) = 0;
    *(--kernel_stack) = 0;
    *(--kernel_stack) = 0;
    *(--kernel_stack) = 0;
    *(--kernel_stack) = 0;
    *(--kernel_stack) = 0;

    // segment registers
    *(--kernel_stack) = 0x10;
    *(--kernel_stack) = 0x10;
    *(--kernel_stack) = 0x10;
    *(--kernel_stack) = 0x10;
   
new_task->ebp = 0xd00fc0de;
new_task->esp = (unsigned int)kernel_stack;
new_task->eip = irq_tail;
}*hust* Stackaufbau aus tyndur ^^

In isr.asm in irq_common_stub vor das mov esp, eax

Code: [Auswählen]

global irq_tail
irq_tail:
Edit: Sorry, dass ich schon wieder eine neue Funktion/Methode vorschlage. Aber beim OS-Dev in dem Stadium ist der Weg das Ziel.

[ehenkes]

Zuerst mal vielen Dank für Deine Mühe!  Das ist echt super.

Habe alles eingebaut und folgenden Ausdruck erhalten:

ts:
id: 1 ebp: 00000000h esp: 001FFE9Ch eip: 00000000h PD: 00000000h k_stack: 40101800h next: 40101814h

ts:
id: 2 ebp: D00FC0DEh esp: 401056E4h eip: 00008495h PD: 40102000h k_stack: 40105800h next: 40101844h

ts:
id: 3 ebp: D00FC0DEh esp: 401096BCh eip: 00008495h PD: 40106000h k_stack: 40109800h next: 00000000h


3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA

Manchmal sieht es auch so aus:

ts:
id: 3 ebp: D00FC0DEh esp: 401096E0h eip: 00008495h PD: 40106000h k_stack: 40109800h next: 00000000h

ts:
id: 1 ebp: 00000000h esp: 001FFEC0h eip: 00000000h PD: 00000000h k_stack: 40101800h next: 40101814h

ts:
id: 2 ebp: D00FC0DEh esp: 401056DCh eip: 00008495h PD: 40102000h k_stack: 40105800h next: 40101844h

ts:
id: 3 ebp: D00FC0DEh esp: 401096E0h eip: 00008495h PD: 40106000h k_stack: 40109800h next: 0000FC0DEh

ts:
id: 1 ebp: 00000000h esp: 001FFEC0h eip: 00000000h PD: 00000000h k_stack: 40101800h next: 40101814h

1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

Ich wundere mich gerade, dass das MOO nicht auftaucht.

Wo kommt eigentlich diese Adresse her?

Code: [Auswählen]

new_task->ebp = 0xd00fc0de;
Bin echt begeistert. Es "multitaskt" 
Vielen Dank für die Starthilfe bei diesem Thema.

[Jidder]

MOO sollte in Kombinationen mit 2en aufreten. Du könntest mal in task_switch1 das task_log auskommentieren. Dann ist diese Zeile vielleicht leichter zu finden. Wenn sie gar nicht zu finden ist, haben wir noch ein Problem.

Die Variable new_task->ebp wird zur Zeit (so wie ich das sehe) nicht verwendet, deswegen hab ich sie mit irgendwas deutlich ungültigem geladen. Dann knallts wenigstens laut, wenn sie doch mal verwendet wird. Diese Adresse ist übrigens in leetspeak kodiert

[ehenkes]

11111111111111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111
                                               2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MO
O 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MO
 BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA
3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3B11111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
O 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2M1111111111111111
O 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MO
O 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MO
O 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MO
 A 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3B
AA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3B
AA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA
                                          11111111111111111111111111111111111111
11111111111111111111111111111111111111111111111111111111111111111111111111111111
111111111111111111111111111111111111111111111
                                             O 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MO
O 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MO
O 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MOO 2MO
 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA
 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA
 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 3BAA 311111111111111111111111111111111111111
111111111111111111111111111111

No Problem. Doch kein DOOFCODE. 

[ehenkes]

Kannst Du dazu bitte noch etwas sagen?

Code: [Auswählen]

*(--kernel_stack) = 0x0202; // eflags = interrupts aktiviert und iopl = 0
0x0202 = 1000000010

Warum wurde Bit 1 gesetzt?

Bit 0: Carry-Flag (CF)
Bit 1: unbelegt
Bit 2: Parity-Flag (PF)
Bit 3: unbelegt
Bit 4: Auxiliary-Flag (AF)
Bit 5: unbelegt
Bit 6: Zero-Flag (ZF)
Bit 7: Sign-Flag (SF)
Bit 8: Trap-Flag (TF)
Bit 9: Interrupt-Flag (IF)
Bit 10: Direction-Flag (DF)
Bit 11: Overflow-Flag (OF)
Bit 12 und 13: I/O-Privilege Field-Flag (IOPL)
Bit 14: Nested-Task-Flag (NT)
Bit 15: unbelegt
Bit 16: Resume-Flag (RF)
Bit 17: Virtual-8086-Mode-Flag (VM)
Bit 18: Alignment Check-Flag (AC)
Bit 19: Virtual-Interrupt-Flag (VIF)
Bit 20: Virtual-Interrupt-Pending-Flag (VIP)
Bit 21: Identification-Flag (IF)
Bit 22-31: unbelegt

Hier ist auch eine interessante Seite zum Thema Multitasking:
http://www.osdever.net/tutorials/multitasking.php

[Jidder]

Bit 1 hat zwar keine besondere Bedeutung, aber es ist immer fest auf 1 gesetzt. Ich hätte auch 0x200 nehmen können, die CPU hätte trotzdem Bit 1 gesetzt.

[ehenkes]

Danke für die Hilfe und die Informationen.

Ich lade den funktionsfähigen Code dieser Multitasking-Versuchsversion hoch, falls andere da mal mit spielen wollen:
http://www.henkessoft.de/OS_Dev/Downloads/36p.zip

[kevin]

Wo kommt eigentlich diese Adresse her?

Code: [Auswählen]

new_task->ebp = 0xd00fc0de;

Ich fordere Lizenzzahlungen, das ist meine!

[ehenkes]

Baust du das mit dem Multitasking auch ein?

Dieses Thema ist absolut faszinierend, also gehört es ins PrettyOS Tutorial. Ich möchte es aber erst verarbeiten, wenn ich die Zusammenhänge komplett verstanden habe. Der Code von James Molloy ist für eigene Versuche nicht verwertbar. Daher wurde er hier zu Recht weitgehend auf den Müll geworfen. 

@PorkChicken: Du hast geschrieben, dass Du auch mein kernel.asm reduziert hast. Kannst Du das mal zeigen, oder hast Du ckernel.c gemeint?

Auf jeden Fall werde ich diesem Forum hier treu bleiben. Das Forum und die vorbildhafte Hilfestellung PorkChicken's habe ich hier gewürdigt:
http://www.henkessoft.de/OS_Dev/OS_Dev1.htm#mozTocId64850