Thema: DPF gefolgt von GPF bei der GDT-Initialisierung

[MNemo]

wie kann ich das am besten machen mit CS:eip?

du suchst in der log-datei von qemu(wieder mit '-d int') nach der ersten Exception und
guckst im darauf folgenden register dump.

Das objdump kann ich wahrscheinlioch mit dem gdb machen, oder?

em… wieso, hast du kein 'objdump'? das ist iirc sogar bei mingw dabei. mit dem gdb kenn ich mich nicht aus.

[rizor]

Mir ist grad aufgefallen, dass es eine Funktion bei Linux ist.
Wusste ich vorher nicht.
Ich schaue dann gleich mal nach.

[rizor]

Wie lese ich denn das cs:eip?
Da stehen folgende Werte:
CS=0008 00000000 ffffffff 00cf9a00
EIP=00100347

[MNemo]

Wie lese ich denn das cs:eip?
Da stehen folgende Werte:
CS=0008 00000000 ffffffff 00cf9a00
EIP=00100347

cs:eip = 0x08:0x00100347(was da sonst noch steht ist base,limit und type des segments)

aber cs ist eigentlich egal. wichtig ist die 0x00100347, danach musst du in der ausgabe von 'objdump' suchen.

[rizor]

Hab die Fehlerhafte Stelle gefunden.
Es ist der iret.
Der Handler sieht wie folgt aus:

Code: [Auswählen]

  10031c:       60                      pusha 
  10031d:       1e                      push   ds
  10031e:       06                      push   es
  10031f:       0f a0                   push   fs
  100321:       0f a8                   push   gs
  100323:       fc                      cld     
  100324:       66 b8 10 00             mov    ax,0x10
  100328:       8e d8                   mov    ds,eax
  10032a:       8e c0                   mov    es,eax
  10032c:       54                      push   esp   
  10032d:       e8 62 0c 00 00          call   100f94 <int_dispatcher>
  100332:       81 c4 04 00 00 00       add    esp,0x4               
  100338:       89 c4                   mov    esp,eax               
  10033a:       0f a9                   pop    gs                     
  10033c:       0f a1                   pop    fs                     
  10033e:       07                      pop    es                     
  10033f:       1f                      pop    ds                     
  100340:       61                      popa                         
  100341:       81 c4 08 00 00 00       add    esp,0x8               
  100347:       cf                      iret       


[MNemo]

dann ist vermutlich der Stack kaputt.

tritt der fehler auch noch auf wenn dein int_dispatcher einfach das gleiche esp returned wie es als parameter bekommt?

wessen iret ist es denn? der erste timer-interrupt?

was sagt denn der error code?

Code: [Auswählen]

check_exception old: 0xffffffff new 0xd
     1: v=0d e=???? […]

[rizor]

Es ist der erste Timer-IRQ.
An sich müsste es lso der gleiche ESP sein.

[MNemo]

Es ist der erste Timer-IRQ.
An sich müsste es lso der gleiche ESP sein.

d.h. bei dir funktionieren wahrscheinlich noch keine Interrupts richtig.?

wie sieht den dein int_0x20 stub aus?

Code: [Auswählen]

int_0x20:
  push 0
  push 0x20
  jmp 0x10031c
was für ein error code wird denn der exception mitgegeben?
bzw. poste mal den kompletten register-dump der zu der exception gehört

[rizor]

genau so sieht der stub aus.
Der Error-Code ist 0, der mit dem GPF gegeben wird.
Woran kann es liegen, dass der iret Fehler auslöst?

[MNemo]

Iret kann aus vielen verschiedenen gründen ein #GP auslösen

ErrorCode: 0
1. Null Selektor für Code oder Stacksegment
2. Adressierung außerhalb der Segment Grenzen

ErrorCode: Selector {nicht wirklich relevant}
fehlerhafte/inkompatible privileglevel, selectoren außerhalb der GDT, und andere

Edit: Bist du dir sicher das es ein #GP(0x0d) ist. Alle möglichen Ursachen scheine für mich mit dem ErrorCode 0 ausgeschlossen zu sein.

Edit2:
Wenn du willst kann ich mir das auch mal angucken(bräuchte nur ein image, zeit hab ich). Ich wüsste sonst echt nicht woran es liegt.

[rizor]

Ja, da bin ich mir sicher.
Es erzählt mir zumindest das logile von qemu.

Der Link zu meinem Image:
http://rizor.bplaced.net/rizor-OS-0.1-Alpha.img

Danke für deine Hilfe.

[rizor]

Mir ist etwas aufgefallen.
Wieso wird in tyndur 0x28 ins TR geschrieben?
Muss im TR nicht eher die Adresse des TSS stehen?

[kevin]

Nein, da steht ein Selektor, der eben auf einen GDT-Eintrag verweist. TR ist im weitesten Sinn auch nur ein Segmentregister.

[rizor]

Okay.
Dann mal eine andere Frage:
Ich mache es momentan so, dass ich den GDT initialisiere und sobald ich Multitasking aktiviere den TSS setze.
Könnte es sein, dass ich damit irgendwelche Probleme erzeuge?

[kevin]

Wenn du es richtig machst nicht.

[rizor]

An sich sollte es passen.
Habe nur eine Frage:
Wieso wird in esp0 eine 0 geschrieben (habe ich mir nur ab geguckt)?
Sollte da nicht eigentlich der stackpointer stehen?

So sieht es momentan aus:

Code: [Auswählen]

memset(&krn_tss , 0 , sizeof(tss_t));
krn_tss.ss0 = SYSTEM_DATA_SELECTOR;
krn_tss.esp0 = 0x0;
krn_tss.ss = 0x10;
krn_tss.ds = 0x10;
krn_tss.es = 0x10;
krn_tss.fs = 0x10;
krn_tss.gs = 0x10;

[kevin]

Da sollte ein Stackpointer stehen, ja. Wo hast du denn abgeschrieben? Sicher, dass der Wert nicht später noch auf was vernünftiges gesetzt wird?

[MNemo]

dein int_dispatcher returned nicht esp, sondern die interrupt nummer

[rizor]

Das war aus einem Tut, weiß leider nicht mehr welches.
Habe da jetzt den aktuellen ESP-Wert eingetragen.
Das sollte jetzt stimmen, oder?

@MNemo:
Bist du dir da sicher?
Habe mir mal den Stack aufgeschrieben.
Ich sehe da keinen Fehler?
Was sollte deiner Meinung nach denn wegfallen in dem Code?

[rizor]

Das Problem hat sich gelöst.
Manchmal bin ich wie vernagelt...
Habe anstatt esp + 8, esp + 4 gemacht.

Stimmt das mit dem esp0 denn, wenn ich den aktuellen esp nehme?