Thema: Syscall wird nicht aufgerufen

[Savatage]

Hallo Team,

ich schaffe es einfach nicht einen Syscall von einem externen Programm auszulösen.
Die Initialisierung über Interrupt 48 sollte vollständig sein. In meinem Interrupt Handler fange ich den Syscall ab und leite ihn an die eigentliche Syscall Funktion weiter. Ich habe zunächst einen Syscall von einem externen Programm ausgelöst, und weil das nicht geklappt hat versuche ich nun von meiner init-Funktion des Kernels, nach der Initialisierung einen Syscall auszulösen:

Code: [Auswählen]

asm("int $0x30" : : "a" (0), "b" ('0' + 1));
Das sollte ja einfach nur eine 1 ausgeben.
Zum Test habe ich mir im Interrupt-Handler mal ausgegeben welche Interrupts ausgelöst werden. Interrupt 0x30 ist jedoch nicht dabei. Es wird nur ständig der PIT (0x20) ausgelöst.

Kann es sein, dass der PIT sooft ausgelöst wird, das mein Syscall gar keine Chance hat an die Reihe zukommen? Ich habe dafür testweise den Syscall-Aufruf in der init-Funktion in eine Whileschleife gepackt um ihn immer wieder auszulösen. Allerdings wird der Syscall immer noch nicht ausgeführt.
Ich schaue jetzt noch mal die ganze Interrupt Initialisierung durch, weil doch eigentlich nur dort der Fehler sein kann, oder?

Gruß
Sava

[kevin]

Also wenn die int-Instruktion ausgeführt wird, passiert auf jeden Fall etwas. Falls dein IDT-Eintrag für Interrupt 0x30 nicht gültig wäre, würdest du zumindest einen GPF bekommen (oder wenn auch das nicht klappt, Double Fault oder Triple Fault). Wenn du gar kein Anzeichen für irgendeinen Interrupt oder eine Exception siehst, dann würde ich behaupten, dass der Code gar nicht erst ausgeführt wird.

Zwischen zwei PIT-Interrupts müsste normal genug Zeit sein, um ordentlich Code ausführen zu können. Wenn du allerdings die ganze Zeit im Interrupthandler bleibst, könnte es natürlich passieren, dass der unterbrochene Code nie fortgesetzt wird. Halte ich für unwahrscheinlich.

Schau dir mal die Binärdatei an, ob der Compiler deine asm-Zeile nicht vielleicht sogar einfach weg"optimiert" hat. Wenn das das Problem ist, könnte ein asm volatile helfen.

Ansonsten qemu -d int und genau anschauen, welche Funktionen jeweils vom PIT-Interrupt unterbrochen werden und ob das die Stellen sind, von denen du erwartest, dass sie gerade laufen.

[Savatage]

Wie immer danke für die schnelle Antwort.

Wenn du gar kein Anzeichen für irgendeinen Interrupt oder eine Exception siehst, dann würde ich behaupten, dass der Code gar nicht erst ausgeführt wird.

Das bestätigt mich immerhin das meine Interruptabhandlung funktioniert und ich da nicht weiter suchen brauche.

Wenn du allerdings die ganze Zeit im Interrupthandler bleibst, könnte es natürlich passieren, dass der unterbrochene Code nie fortgesetzt wird. Halte ich für unwahrscheinlich.

Dies halte ich auch für unwahrscheinlich, weil meine Tastatureingaben reagieren und der entsprechende Interrupt für einen Tastenanschlag ausgeführt wird.

Wenn das das Problem ist, könnte ein asm volatile helfen.

Ein asm volatile ändert leider gar nichts. Das wäre natürlich schön einfach gewesen

Ansonsten qemu -d int und genau anschauen, welche Funktionen jeweils vom PIT-Interrupt unterbrochen werden und ob das die Stellen sind, von denen du erwartest, dass sie gerade laufen.

qemu -d int zeigt mir die Kernel Register und gefühlt 1000 andere Dinge? Das habe ich noch nie benutzt und muss mich da erst mal durch kämpfen. Wenn ich diesbezüglich weitere Infos habe, melde ich mich wieder. Bis dahin bin ich über weitere Tipps dankbar.

Gruß
Sava

[kevin]

qemu -d int zeigt mir die Kernel Register und gefühlt 1000 andere Dinge?

Es zeigt dir für den jeden Interrupt die Details zu diesem Interrupt an (also Vektor, Error Code, usw.) und zusätzlich einen CPU-Dump. Aus dem CPU-Dump interessiert dich im Moment wahrscheinlich eip, also die Adresse, an der gerade Code ausgeführt wurde als der Interrupt ausgelöst wurde.

[Savatage]

Problem gelöst.
Die For-Schleife war nicht richtig, sodass der Code nicht ausgeführt wurde.
Allerdings bin ich mit der Ausgabe noch nicht so recht zufrieden. Das ist die Schleife:

Code: [Auswählen]

int i;
for (i = 0; i < 5; i++) {
asm("int $0x30" : : "a" (0), "b" ('0' + i));
}
Also erwarte ich als Ausgabe: 01234
Die tatsächliche Ausgabe ist aber:
t
0t
1t
2t
3t
4t

Nach jedem Syscall kommt irgendwo hier noch ein t und ein \n.
Es scheint wohl dass mein Konsolentreiber noch nicht ganz rund läuft. Da schau ich jetzt noch mal drüber.

Danke bisher erstmal.

[Savatage]

ich kriege das Problem mit dem zusätzlichen t in der Ausgabe nicht gelöst. Das Register ebx ist korrekt gefüllt und ist doch eigentlich nichts anderes als ein Hex-wert.

[kevin]

Also der gepostete Code befüllt nicht ebx, sondern nur bl, falls das für deinen Kernel irgendeinen Unterschied machen sollte.

Hast du ebx denn mal als Hexzahl im Kernel ausgeben lassen?

[Savatage]

ich habe mittels qemu -d int geschaut was jeweils zum Syscall Aufruf in ebx drin steht.
ich dachte der erste Parameter im asm Befehl wird in eax geschrieben ( die 0 ) und der zweite in ebx?
Was genau meinst du mit bl?

Ich  glaube so langsam fällt es auf, dass ich nicht 100% verstanden habe wie der asm Befehl funktioniert. Ich werde mich mal schlau machen und hoffe dabei auf die Lösung zu stoßen. 

[OsDevNewbie]

bl ist das erste Byte im ebx-Register. Es wird nur dieses befüllt, weil '0' nur 1 Byte entspricht und somit '0'+x auch nur ein Byte belegt. Daher wäre es nicht falsch anzunehmen, dass der Compiler nur das bl-Register beschreibt. Durch das beschreiben, des bl-Registers wird der Inhalt des restlichen Register aber nicht gelöscht und deshalb kann dort noch "Abfall" enthalten sein.

[Savatage]

ah, ok! Vielen Dank.
Wenn ich

Code: [Auswählen]

asm("int $0x30" : : "a" (0), "b" ('0' + 3));ausführe steht in ebx: 00000033
Führe ich hingegen

Code: [Auswählen]

asm("int $0x30" : : "a" (0), "b" (3));aus steht in ebx: 00000003

Also steht im 2. Byte von ebx immer noch eine 3 - sozusagen als Abfall.

Meine Ausgabe (kprintf("%c", cpu->ebx)) im ersten Fall ist:
t
3t
3t
...
oder (kprintf("%d", cpu->ebx)):
t
51t
51t
...


im Zweiten Fall
t
 t
 t
...


Die 51 passt ja schon mal weil 33h = 51d. Trotzdem verstehe ich nicht wo das t herkommt.

[Savatage]

ich Esel... Einfach ignorieren... hatte tatsächlich noch zum debuggen ein t\n ausgegeben. Kaum nimmt man es raus, schon funktionierts.

trotzdem sehr hilfreich sich dem asm Befehl mal genau anzusehen.

[kevin]

Also steht im 2. Byte von ebx immer noch eine 3 - sozusagen als Abfall.

Nicht ganz.

Ein Byte hat 8 Bit, also zwei Hexziffern, nicht nur eine. 0x33 ist der Inhalt des ersten Bytes. Und das ist der ASCII-Code für das Zeichen '3', also passt genau.