C/C++ Forum :: Memory Managment

abc.w Mitglied 18:25:16 13.03.2010 Titel:

Oder es fehlt einfach irgendwo ein "volatile"...

taljeth Mitglied 18:29:16 13.03.2010 Titel:

Bei Treibern mag das ja regelmäßig vorkommen, aber eine Speicherverwaltung, die volatile braucht, wäre mir suspekt.

Badestrand Mitglied 18:34:41 13.03.2010 Titel:

An der Speicherverwaltung kann es gar nicht liegen, die wird erst später initialisiert, nach dem Crash. Der Code, der bis zum Absturz durchlaufen wird, ist auch relativ überschaubar. Direkt nach dem Eintritt in die main-Funktion wird die "init"-Funktion aufgerufen, die folgende Sachen ausführt:

C/C++ Code:
1 2 3 4 5 6 7 8 9	1 2 3 4 5 6 7 8 9	clear_screen(); settextcolor(14,0); printformat("PrettyOS [Version 0.0.0.221]\n"); gdt_install(); idt_install(); timer_install(); keyboard_install(); syscall_install(); settextcolor(15,0);

C/C++ Code:
1 2 3 4 5 6 7 8 9	clear_screen(); settextcolor(14,0); printformat("PrettyOS [Version 0.0.0.221]\n"); gdt_install(); idt_install(); timer_install(); keyboard_install(); syscall_install(); settextcolor(15,0);

C/C++ Code:
1 2 3 4 5 6 7 8 9	clear_screen(); settextcolor(14,0); printformat("PrettyOS [Version 0.0.0.221]\n"); gdt_install(); idt_install(); timer_install(); keyboard_install(); syscall_install(); settextcolor(15,0);

Auf den ersten Blick in diese Funktionen sieht das alles recht ungefährlich aus. Die Sachen laufen auch gut durch, beim return geht irgendwas schief, scheint also der Stack kaputt zu sein. Bloß woher :confused:

Ich bin schon dabei, zu debuggen und zu disassemblern, ist aber eine eklige Arbeit..

Unregistrierter 19:03:53 13.03.2010 Titel:

Ist eher alles ein Problem mit den Kompilerflags. Folgendes Beispiel:

C/C++ Code:
1 2 3 4 5 6 7 8 9	1 2 3 4 5 6 7 8 9	// ckernel.c Revision 219 int main() { for(;;); // <- Endlosschleife :) init(); (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9	// ckernel.c Revision 219 int main() { for(;;); // <- Endlosschleife :) init(); (...) }

C/C++ Code:
1 2 3 4 5 6 7 8 9	// ckernel.c Revision 219 int main() { for(;;); // <- Endlosschleife :) init(); (...) }

Ohne Flag "-O" stürzt PrettyOS ab, woraus vorerst nur folgen soll, daß die Endlosschleife nicht ausgeführt wurde (also "verschwunden" ist).

Mit Flag "-O" bleibt PrettyOS in der Endlosschleife hängen, was heißt, daß sie nicht "verschwunden" ist.

Daraus folgt, daß der GCC auch ohne Angabe von Optionen zur Optimierung den Quellcode wie auch immer verändert. Insofern wirst Du wahrscheinlich im Quellcode auch keine Fehler finden.

Badestrand Mitglied 19:10:09 13.03.2010 Titel:

Da läuft beim Linken was schief, aber ist der Grund jetzt klar. Der eigentlich als Einstiegscode gedachte "KernelStart" liegt irgendwo in der Mitte des Binaries.

Mit Compiler-Option -O0 wird die "init"-Funktion nicht ge-inline-t und liegt am Anfang des Binaries, d.h. der Code springt direkt in die init-Funktion, ohne vorher in der "main" gewesen zu sein. Logisch, dass dann keine gültige Rücksprungadresse auf dem Stack liegt und es kracht.

Mit -O wird die "init"-Funktion ge-inline-t und die "main"-Funktion liegt direkt am Anfang des Binaries. Damit klappt es zwar, ist aber nicht im Sinne des Erfinders, die "KernelStart"-Funktion gibt es ja nicht umsonst, sie setzt z.B. den Stack auf 0x01900000.

D.h. irgendwie bekommt der Linker es nicht hin, die "KernelMain" an den Anfang des Binaries zu setzen, obwohl die Funktion im Linkerscript als "ENTRY" markiert ist. Hat jemand eine Idee?

edit: Danke, +gjim+!

Badestrand Mitglied 19:17:32 13.03.2010 Titel:

Ok, habs. Im Linkerscript muss STARTUP(kernel.o) gesetzt sein, das ENTRY spielt keine Rolle. Ich comitte.

edit: Was für ein Krampf

XanClic Mitglied 19:49:33 13.03.2010 Titel:

Trotzdem könnte man hier mal anmerken, dass man genau wegen sowas ELF oder ähnliche Formate will (die also einen Entrypoint haben)...

Erhard Henkes Mitglied 21:11:37 21.03.2010 Titel:

Eine Frage aus dem IRC:

Zitat:

ich frag mich, ob es wirklich nötig ist, die page tables für den kernel bereich im voraus zu allokieren.

lk Mitglied 18:08:41 29.07.2011 Titel:

Kann jemand die meory map irgendwie erwitern ? Mehr details wären cool, vielleicht auch graphisch.

Apropo, ich kann auch osdev.org empfehlen.

Mr X Mitglied 18:14:53 29.07.2011 Titel:

Im Repository befindet sich unter /documentation/memory.txt eine detailiertere und aktuellere Übersicht.