Aktuelle Bugs: Wer ihn findet, darf ihn behalten!

[Dirty Oerti]

Ich bin nun der Überzeugung, dass es definitiv nicht an bochs liegt.
Habe aber leider trotzdem keinen Plan, warum die Fehler auftreten (bochs steigt einfach aus).

[Dirty Oerti]

-------------------------------------------------

Ok, anderes Problem:
Ich habe nun versucht, eine Funktion zum mappen von virtuellen Speicher auf physischen einzubauen.
Die sollte eigntl auch ganz gut funktionieren.
Einziges Problem:

Wenn ich die Aufrufe (die Funktioniert GENAUSO wie das im PageFault Handler) kommen lustige Sachen:

00025674902i[CPU0 ] LOCK prefix unallowed (op1=0xac, attr=0x400, mod=0x0, nnn=0)
00025674937i[CPU0 ] LOCK prefix unallowed (op1=0xac, attr=0x400, mod=0x0, nnn=0)
00025674972i[CPU0 ] LOCK prefix unallowed (op1=0xac, attr=0x400, mod=0x0, nnn=0)
00025675007i[CPU0 ] LOCK prefix unallowed (op1=0xac, attr=0x400, mod=0x0, nnn=0)
00025675042i[CPU0 ] LOCK prefix unallowed (op1=0xac, attr=0x400, mod=0x0, nnn=0)

Frage: Was ist das für eine Anweisung, 0xac ?
Und: Kann mir jemand die Sache mit dem Lock genauer erklären?

Ich hab mich natürlich auch schon im Internet umgehört, und nun nähere ich mich langsam der Auffassung, das bochs vllcht nicht unbedingt der ideale Emulator ist.
Ich werde den Kernel nun mal unter Qemu testen...

MfG
Daniel

[Dirty Oerti]

*Verzweifel*

Bugs, Fehler etc überall.
Ich musste zwischendurch sogar überprüfen, ob die GDT überhaupt richtig geladen wurde.
Evtl nehme ich zu Testzwecken das Multitasking mal wieder raus und bringe erst alles vollkommen in Schuß.
Da gibt es anscheinend einige Probleme. (einige = sehr viele)

MfG
Daniel

[Xin]

Low-Level-Programmierung gehörte noch nie zu den einfachsten Sachen... zumal Du nicht so schön debuggen einfach kannst.

[Dirty Oerti]

Ja, da liegt ein großes Problem.
Die bochs-Ausgabe ist zwar ganz nett, es befindet sich aber nirgends eine Anleitung/Dokumentation, um die Ausgaben verstehen zu können.
Teilweise habe ich mir schon den SourceCode von bochs durchgeschaut, um versuchen zu verstehen, woher die Fehler kommen bzw was die Ursache dafür ist.

Ich hab mich jetzt mal schon ein bisschen mit Qemu vertraut gemacht.
Das scheint eine Möglichkeit zu bieten, mit gdb zu debuggen.
Allerdings ist die LOG-Ausgabe von Qemu lächerlich...

[Dirty Oerti]

Achje...man kann davon nicht genug bekommen:

Code: Alles auswählen

void Init_Multitasking()
{
    DEBG;
    asm volatile("cli");
    DEBG;
    MoveStack(0xE0000000, 0x2000);
//  Inhalt von  Makro DEBG :
    K_PERROR("Debugpunkt: ");K_PSUCCESS(__FILE__);PEN(__LINE__);
}

Funktioniert traumhaft. Zumindest solange nichts weiter mehr in dieser Funktion drinnen steht^^
Lustig:
Sieht der Code so aus (das Makro DEBG enthält wirklich nur Debugausgaben):

Code: Alles auswählen

void Init_Multitasking()
{
    DEBG;
    asm volatile("cli");
    DEBG;
    MoveStack(0xE0000000, 0x2000);
//  Inhalt von  Makro DEBG :
//    K_PERROR("Debugpunkt: ");K_PSUCCESS(__FILE__);PEN(__LINE__);
}

Dann bekomme ich einen PageFault für irgendeine komische Adresse...

Origin: 0x1C107902
Error Code: 0x2

CS: 0x8
EIP: 0x10400B

Qemu ist dann übrigens der gleichen Ansicht, bochs ist also Unschuldig...
Kurze Erklärung:
Origin beschreibt die Adresse, auf die zugegriffen wurde. Der Error Code verrät uns, dass es sich um einen Fehler durch eine nicht presente Seite bei einem Schreibezugriff aus dem Supervisor Mode (Ring 0) heraus handelt.
CS gibt das aktuelle Codesegement an. Der Wert 0x8 ist vollkommen ok. EIP ist der Instruction Pointer und verrät uns, an welcher Stelle im Code der Fehler auftrat.

Ein Auszug aus der entsprechenden Stelle:

Code: Alles auswählen

00103fe9 <find_first_free>:
  103fe9:	55                   	push   %ebp
  103fea:	89 e5                	mov    %esp,%ebp
  103fec:	83 ec 14             	sub    $0x14,%esp
  103fef:	a1 84 6b 10 00       	mov    0x106b84,%eax
  103ff4:	89 45 f0             	mov    %eax,-0x10(%ebp)
  103ff7:	c7 45 f4 00 00 00 00 	movl   $0x0,-0xc(%ebp)
  103ffe:	c7 45 f8 00 00 00 00 	movl   $0x0,-0x8(%ebp)
  104005:	c7 45 fc 00 00 00 00 	movl   $0x0,-0x4(%ebp)
  10400c:	eb 1e                	jmp    10402c <find_first_free+0x43>
  10400e:	83 45 f4 01          	addl   $0x1,-0xc(%ebp)
  104012:	a1 78 6b 10 00       	mov    0x106b78,%eax
  104017:	39 45 f4             	cmp    %eax,-0xc(%ebp)
  10401a:	72 0c                	jb     104028 <find_first_free+0x3f>
  10401c:	c7 45 ec 00 00 00 00 	movl   $0x0,-0x14(%ebp)
  104023:	e9 cd 00 00 00       	jmp    1040f5 <find_first_free+0x10c>
  104028:	83 45 f0 04          	addl   $0x4,-0x10(%ebp)
  10402c:	8b 45 f0             	mov    -0x10(%ebp),%eax
  10402f:	8b 00                	mov    (%eax),%eax
  104031:	83 f8 ff             	cmp    $0xffffffff,%eax
  104034:	74 d8                	je     10400e <find_first_free+0x25>

Interessant ist, dass der EIP nicht auf eine Anweisung sondern mitten in eine hinein zeigt... (?!?)

Was auch lustig ist: Ich hatte es schonmal so, dass die Angegebene Fehlerquelle fast der (Byte)Code der folgenden Anweisungen war. Zufall oder eher nicht?

Irgendjemand eine Idee, einen Kommentar oder sonst etwas was mir weiterhilft oder auch nicht?
MfG
Daniel

[Dirty Oerti]

Ok, ich hab jetzt ne Lösung, zufrieden bin ich aber trotzdem nicht.
Ich habe die Compileroptionen mal verändert.... :

So waren sie vorher und so gab es Fehler:

CCFLAGS = -m32 -fno-builtin -fno-leading-underscore -fno-strict-aliasing -fno-stack-protector -Wall -O0 -c -I../inc/

Und nun sind sie so und es funktioniert alles einwandfrei:

CCFLAGS = -m32 -fno-builtin -fno-leading-underscore -fno-strict-aliasing -fno-stack-protector -Wall -O -c -I../inc/

Kann mir das jemand erklären?

[Xin]

Achje...man kann davon nicht genug bekommen:

Dann bekomme ich einen PageFault für irgendeine komische Adresse...

Origin: 0x1C107902
Error Code: 0x2

CS: 0x8
EIP: 0x10400B

Qemu ist dann übrigens der gleichen Ansicht, bochs ist also Unschuldig...
Kurze Erklärung:
Origin beschreibt die Adresse, auf die zugegriffen wurde. Der Error Code verrät uns, dass es sich um einen Fehler durch eine nicht presente Seite bei einem Schreibezugriff aus dem Supervisor Mode (Ring 0) heraus handelt.
CS gibt das aktuelle Codesegement an. Der Wert 0x8 ist vollkommen ok. EIP ist der Instruction Pointer und verrät uns, an welcher Stelle im Code der Fehler auftrat.
Interessant ist, dass der EIP nicht auf eine Anweisung sondern mitten in eine hinein zeigt... (?!?)

Wandert der EIP nicht gleich weiter, wenn er etwas gelesen hat? In dem Fall knallt er vor JMP.
104005: c7 45 fc 00 00 00 00 movl $0x0,-0x4(%ebp)
Scheinbar ist ebp nicht korrekt gesetzt?

Ok, ich hab jetzt ne Lösung, zufrieden bin ich aber trotzdem nicht.
Ich habe die Compileroptionen mal verändert.... :

So waren sie vorher und so gab es Fehler:

CCFLAGS = -m32 -fno-builtin -fno-leading-underscore -fno-strict-aliasing -fno-stack-protector -Wall -O0 -c -I../inc/

Und nun sind sie so und es funktioniert alles einwandfrei:

CCFLAGS = -m32 -fno-builtin -fno-leading-underscore -fno-strict-aliasing -fno-stack-protector -Wall -O -c -I../inc/

Kann mir das jemand erklären?

O0 optimiert nicht, wenn ich mich recht entsinne, O schon. Vielleicht geht bei der Optimierung an der Stelle etwas verloren?
Wenn Du die Assemblercodes an der Stelle vergleichst, gibt es da Unterschiede?

[Dirty Oerti]

Tag

Wandert der EIP nicht gleich weiter, wenn er etwas gelesen hat? In dem Fall knallt er vor JMP.
104005: c7 45 fc 00 00 00 00 movl $0x0,-0x4(%ebp)
Scheinbar ist ebp nicht korrekt gesetzt?

Der gegebene EIP ist abhängig vom Interrupt, der Auftritt. Bei einem PageFault zeigt er auf die Anweisung, die den Fehler hervorgerufen hat:

To allow the restarting of program or task following the handling of an exception or
an interrupt, all exceptions (except aborts) are guaranteed to report exceptions on
an instruction boundary. All interrupts are guaranteed to be taken on an instruction
boundary.
For fault-class exceptions, the return instruction pointer (saved when the processor
generates an exception) points to the faulting instruction.

Mich wundert nur, warum der EIP mitten in eine Anweisung hinein zeigt und nicht auf sie, wie es normalerweise sein sollte....

O0 optimiert nicht, wenn ich mich recht entsinne, O schon. Vielleicht geht bei der Optimierung an der Stelle etwas verloren?
Wenn Du die Assemblercodes an der Stelle vergleichst, gibt es da Unterschiede?

Ja, da gibt es gewaltige Unterschiede.
Nur als Anmerkung, zum Verdeutlichen:

Bei O0, wenn also nicht opitmiert wird, kommen Fehler.
Verwende ich nur O, funktioniert alles einwandfrei.
Dann sieht der Assemblercode an der Stelle auch ganz anders aus. Auf jedenfall gibts dann deutlich weniger Assemblercode (insgesamt).

Das ist gerade das, was mich wundert. Das es beim "Nichtoptimieren" kracht.

-----------------Edit:
Hatte einen kleinen Unfall (Ordner auf die Tastatur gedrückt => Enter Taste dauernd an.)
Danach (ich habe eigntl alles wieder zusammengebastelt) ging erstmal nichts mehr.
Bzw es kamen die gleichen Fehler wie zuvor, es wurde aber wirklich nichts verändert.


Habe nun auch im Makefile im Ordner basic-kernel (das makefile für basic-kernel.c) verändert (siehe oben).
Nun geht wieder alles als wär nichts gewesen?
Ich versteh die Welt nicht mehr...

[Xin]

Was passiert denn, wenn man ein paar Mal Return drückt!? Ist das so schlimm!?
Was verändert sich da? Es werden ein paar Zeilen eingefügt und dann macht man sie wieder weg und fertig?