Nachrichten

41

Lowlevel-Coding / Re: globale Variablen im C++ Kernel funktionieren nicht

« am: 01. August 2013, 16:00 »

Neuere GCC Versionen erzeugen keine ctros-sections mehr sondern init_array und fini_array sections. D.h. deine ctors liste bleibt vermutlich leer (start/end-ctors sind gleich).

Code: [Auswählen]

nm kernel.elf | grep ctors
Du kannst dir die ctors / dtors etwa so in deinem linkscript zusammen sammeln. (statt dem .ctors* .*dtors zeug wie es im Tutorial steht)

Code: [Auswählen]

       __init_array = .;
       KEEP(*( .init_array ));
       KEEP(*(SORT_BY_INIT_PRIORITY( .init_array.* )));
       __init_array_end = .;
 
        /* List all Destructors here */
       __fini_array = .;
       KEEP(*( .fini_array ));
       KEEP(*(SORT_BY_INIT_PRIORITY( .fini_array.* )));
       __fini_array_end = .;
__init_array entspricht dann start_ctors etc.

42

Lowlevel-Coding / Re: Interrupts überschreiben lokale Variablen?

« am: 31. July 2013, 15:34 »

Warum kann sich der DOuble Fault keinen Stack teilen?

Weil der Double Fault ausgelöst wird, wenn der Exception handler einer anderen Exception eine weitere Exception auslöst. Der Stack wird also schon benutzt, und würde überschrieben werden. Wenn man den Stack von der Original Exception nicht mehr braucht, weil man so wieso nur noch den Bildschirm rot macht, ist das kein Problem. Aber wenn man den Stack evtl. noch für nen StackTrace braucht, wäre es schlecht den zu überschreiben.
Edit: Ok. Ist natürlich zum größten teil Blödsinn. Einen #DF wohl nur wenn es noch vor dem eigentlichen Exception-Handler noch eine Weitere Exception gibt. Lange pausen im OS-dev sind einfach nicht gut.

Noch eine Frage nebenbei: Wie gross macht ihr euren Stack für den Kernel? Der wird ja eigentlich nur zum Initialisieren benutzt und später nicht mehr. Bei ist er 1MB gross. Könnte man den noch verkleinern? Wie stellt man fest, wieviel maximal vom Stack gebraucht wird? Wie gross sind eure Interrupts-Stacks?

Ich mache meine immer 4k groß. Bis jetzt war das (glaub) ich auch immer genug (aber so komplex ist mein Kernel auch nicht). Aber wie viel ich wirklich brauche weiß ich auch nicht.

43

Lowlevel-Coding / Re: Interrupts überschreiben lokale Variablen?

« am: 31. July 2013, 14:46 »

Eigentlich ist es für Exceptions relativ einfach. Bis auf den DoubleFault können die sich alle den selben Stack teilen.

Edit: Schein bar habe ich da den Double Fault falsch verstanden. Damit ist dass dann doch nicht so einfach wie ich dachte. Außer man schreibt einfach fehlerfreie Exception-Handler  .

44

Lowlevel-Coding / Re: Interrupts überschreiben lokale Variablen?

« am: 31. July 2013, 13:16 »

Auch für den Kernel kann man im LM einen Stackwechsel erreichen. Man kann über die IST (Interrupt Stack Table) jedem Interrupt einen von insgesamt bis zu 7 festen Stacks zuweisen. Dann muss man nur sicherstellen, dass sich nie zwei Interrupts mit dem selben Stack in die Quere kommen.

45

Lowlevel-Coding / Re: IRQ 11 auf Hardware

« am: 23. July 2013, 18:19 »

Ich war mir sicher das GCC in so einem Fall warnt. Aber das tut er scheinbar nur wenn die shift-Weite >= 32 ist, egal ob u8 oder char.
Darunter wird das tatsächlich still und heimlich zu einer 0 optimiert. 

46

Lowlevel-Coding / Re: Eigene Codepage im eigenen OS

« am: 01. June 2013, 11:23 »

Außerdem geht es mit nicht um eine spezielle Font […], sondern das direkte ändern der Codepage durch das BIOS.

Was verstehst du denn genau unter Codepage? Der/Die/Das Font ordnet dir zu jedem Byte-Wert eine Pixelgraphik zu, ist das nicht genau das was du haben willst? Dein Symbol als Pixelgraphik für Wert 0x41.

47

Softwareentwicklung / Re: ld: "cannot find object file"?

« am: 01. June 2013, 11:02 »

Erwähnst du die Datei evtl. in linkconf.ld?

48

Lowlevel-Coding / Re: ACPI-Version

« am: 01. June 2013, 10:54 »

Welchem Feld genau entnimmst du denn das es sich um ACPI 1.0 handelt. Dann kann ich das evtl. mal schnell nach gucken. Ist aber denke ich nicht ungewöhnlich, dass das die ACPI Versionen uralt sind. Falls es RSDP.revision ist, dann gibt es nur an welche Felder in der RSDP vorhanden sind. Wenn die Tabellen in den unteren 4 GiB gehalten werden brauchst du keine 64 Bit Adressen und revision 0 ist vollkommen ausreichend. Und lässt nicht auf die ACPI Version schließen.

Ich habe auch noch mal gerade nach einem neuen 120 € Mainbord geguckt, das Ding unterstützt laut Beischreibung sogar ACPI v1.0b ^^

49

Softwareentwicklung / Re: fprintf Funktioniert nicht

« am: 23. March 2013, 10:27 »

Wie sehen den deine va_arg-Makros aus?
Die sollten auf die builtins von GCC verweisen, da Parameter bei AMD64 nicht alle auf dem Stack landen, und die Makros etwas komplizierter werden.
[edit]Ok. Dem disassmblierten code zufolge verwendest du wohl die richtigen Makros[/edit]

Abgesehen davon verwendest du nicht die selben Funktionen um Zahlen in strings zu verwandeln.

Code: [Auswählen]

itoa(int, char[])    // printf
/* bzw. */
utoa(unsigned int, char[]);
/* vs. */
itoa(int)            // Ausgabe der PCI-Geräte
[edit]
Ich kann sonst nichts fehlerhaftes finden und würde wie folgt vorgehen.

• in der vprintf statt der zahl erst mal "INT" ausgeben, um zu gucken ob der Code überhaupt ausgeführt wird.
  
• überprüfen ob der richtige parameter wert ankommt, printf("%u", 1337); und in der vprintf if(va_arg(…) == 1337) puts("OK"); else puts("Fail");

50

Lowlevel-Coding / Re: Interrupt-Stackzustand (speziell Errorcode) im Long Mode

« am: 02. March 2013, 17:46 »

Nee neem, es passt jetzt schon.

Mich interessiert jetzt aber was genau es war. Am Limit wird es nicht gelegen haben, oder?

Das Tutorial gehört übrigens verboten (Create Long Mode Kernel oder sowas auf os-dev.org), ist jetzt schon der dritte schwerwiegende Fehler im Code.

Ist ein Wiki oder?

Kann sich jemand einen Reim drauf machen, warum QEMU DS16 ausspuckt?

Im LM wird der descriptor fast vollständig ignoriert, der würde im PM wohl als 16 bit daten segment interpretiert werden.

51

Lowlevel-Coding / Re: Interrupt-Stackzustand (speziell Errorcode) im Long Mode

« am: 02. March 2013, 17:15 »

Edit: Den Long Mode hab ich aus einem Tut genommen, der ist aber... ääh.... Limit = 0, kein Kommentar.

Limit wird im LM ignoriert. Wenn du in den LM switchst, lädst du vermutlich DS, ES usw. ? lade da auch mal das SS neu.

52

Lowlevel-Coding / Re: Interrupt-Stackzustand (speziell Errorcode) im Long Mode

« am: 02. March 2013, 16:50 »

0x0d ist ein #GP fault und kein #PF, der Auftritt weil etwas mit deinem datensegment 0x10 (e = 0x10) nicht stimmt.
Es sieht auch merkwürdig aus, das sich die Beschreibungen trotz gleicher Selektoren unterscheiden:

SS =0010 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0010 0000000000000000 00000000 00009100 DPL=0 DS16 [--A]
FS =0010 0000000000000000 00000000 00009100 DPL=0 DS16 [--A]
GS =0010 0000000000000000 00000000 00009100 DPL=0 DS16 [--A]

Außerdem gibt es im LongMode noch ein paar mehr Register (r8-r15), die du evtl. sichern solltest. Ein paar werden zwar sind laut abi zwar für den caller reserviert, aber ich glaube das sind nicht alles r8-r15.

53

Offtopic / Re: Logisim CPU

« am: 11. February 2013, 16:05 »

Hier gibt es einen Folien Satz zu einer Vorlesung die den Aufbau schritt für schritt erklärt: MIPS-PDF (Webseite)

PC steht für Program-Counter und entspricht dem i386 Instruction-Pointer (E)IP

54

Lowlevel-Coding / Re: conflicting types for built-in function ‘printf’ trotz -nostdinc

« am: 02. February 2013, 13:46 »

-nostdinc¹ sagt nur wo nach header-dateien gesucht werden soll, und hat nix mit built-in funktionen zu tun.
Das flag das du brauchst heißt -ffreestanding²

55

Lowlevel-Coding / Re: Keyboard Controller Capslock

« am: 02. February 2013, 12:44 »

Der Cursor passt sich an die Farbattribute des jeweiligen Feldes an, an dem er steht. Da du den Bildschirm vermutlich mit Nullen leerst hast du schwarz auf schwarz, und siehst den Cursor nicht.

56

Lowlevel-Coding / Re: BIOS Data Area auf capslock überprüfen

« am: 30. January 2013, 09:14 »

Jetzt verstehe ich nur nicht so ganz wieso ich noch das CS mit 0 initialisieren sollte, wird das auch noch mit verwendet bei der Adressberechnung für die Adresse die ich auslesen will?

Es wird für den Code gebraucht. Also ein CALL Print ist z. B. ein CALL CS:Print. Und wenn sich der BIOS Hersteller gedacht hat, es ist toller wenn der Bootsektor bei Segment Offset 0 anfängt dann Startet dein Code bei 0x07C0:0x0000 = 0x7C00, wegen ORG 0x7C00 ist dein Print-lable aber 0x7C00 + X und du würdest mit 0x07C0:0x7C00 + X = 0xF800 + X nicht mehr bei deinem Code landen.

57

Lowlevel-Coding / Re: BIOS Data Area auf capslock überprüfen

« am: 29. January 2013, 09:42 »

Im Datensegmentregister ist (wie der name es eigentlich schon sagen sollte) die Segmentadresse gespeichert, die benutzt wird um auf Daten zuzugreifen. Kann man das so Sagen?

Ja, so in etwa. DS wird automatisch für alle Daten Zugriffe verwendet. SS für alle Zugriffe mit Hilfe von SP oder BP und CS für den Code. Wie sich die tatsächliche Adresse dann zu sammen setzt kannst du hier nachlesen „Real Mode Speicheradressierung“

Ich hab diese eigenartige Methode auch nur benutzt, weil in dem Wikipedia Buch "Assembler Programmierung für x86 Prozessoren" drin steht, dass man die Adressregister nicht direkt verändern kann.

Damit ist gemeint das ein "mov ds, 0" nicht funktioniert.

Jedenfalls funktioniert es jetzt

Das ist leider noch ein wenig Zufällig, weil du nicht nur beim DatenSegment nicht weißt welcher Wert drin steht. Du solltest auch das CS mit einem Wert initialisieren.

Code: [Auswählen]

[org 0x7C00]
jmp 0x00:jetzt_ist_CS_null
jetzt_ist_CS_null:

// DS null setzen, und loslegen


58

Lowlevel-Coding / Re: outb

« am: 24. January 2013, 09:11 »

nicht in Form von Funktionen. Weil die würdest du dann ja mehrfach haben, und Probleme beim Linken bekommen.

wenn du aber so Makros wie FOR_EACH_foobar(LIST) haben willst, dann könnten die auch in Headern Sinn machen.

59

Lowlevel-Coding / Re: outb

« am: 23. January 2013, 19:07 »

Ja. Nur, dass im Fall von in/out wohl eher weniger Opcodes erzeugt werden.

Code: [Auswählen]

push ARG1
push ARG2
call outb
add esp, 8vs.

Code: [Auswählen]

mov al, ARG1
outb ARG2, al

60

Lowlevel-Coding / Re: Qemu

« am: 22. January 2013, 20:32 »

Alles klar, jetzt hab ich GRUB 1.99, aber immer noch kein el torito in sicht 

GRUB 1 bzw. GRUB legacy geht bis version 0.99 oder so.
GRUB 2 fängt etwa bei GRUB 1.98 oder so an.

Das ist also immer noch GRUB 2.