Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Nachrichten - OS_3000

Seiten: [1] 2 3
1
Softwareentwicklung / Re: In Eclipse OS in Qemu mit GDB debuggen
« am: 04. September 2013, 01:25 »
Ok, werde ich morgen nochmal versuchen, dass über "Remote Application" hinzubekommen.
Vielleicht sind eventuell deine Vermutungen möglicherweise doch nicht so falsch...  :wink:
2
Softwareentwicklung / Re: In Eclipse OS in Qemu mit GDB debuggen
« am: 03. September 2013, 23:24 »
Ok, peinlich.
Mit Debuginformationen wird "init.o" zu groß und verdrängt die magische Zahl in "initasm.o" scheinbar zu weit nach hinten. Wenn man die Beiden Dateien im Script vertauscht, geht es. Schonmal vielen Dank dafür.  :-D

Das mit "Remote" habe ich zuvor bereits ausprobiert.
Allerdings gibt es da zuviele Felder von denen ich überhaupt nicht weiß, was ich eingeben soll.
Ich habe das Gefühl das damit das Remote Debuggen einer Anwendung auf einen anderen System gemeint ist. Nicht das System selber. (Siehe Screen(s) im Anhang)
Auch in dem Tutoriallink von dir zb. wird nicht damit gearbeitet. Das hat mich dann jedenfalls wieder davon abgebracht.
Aktuelle Informationen konnte ich bisher aber nicht finden.
3
Softwareentwicklung / Re: In Eclipse OS in Qemu mit GDB debuggen
« am: 03. September 2013, 22:43 »
Schonmal danke für die Antwort.  :-)

Zitat
Und mit -g?
Auch nicht.

Zitat
Ansonsten müsstest du mal die Ausgabe von objdump -x herzeigen.
Die Ausgabe habe ich angehängt.

Mein Linkerscript ist wie sonst:
ENTRY (loader)
OUTPUT_FORMAT(elf32-i386)
/*OUTPUT_ARCH(i386:i386)*/

SECTIONS
{
  . = 0x00100000;

  kernel_start = .;
  .text :
  {
    init.o;
    initasm.o;
    *(.text)
  }
  . = ALIGN(4096);
  kernel_endofcodesection = .;

  .rodata :
  {
    *(.rodata)
  }

  . = ALIGN(4096);
  kernel_endofreadonlysection = .;

  .data :
  {
    *(.data)
  }
  .bss :
  {
    _sbss = .;
    *(COMMON)
    *(.bss)
    _ebss = .;
  }
  . = ALIGN(4096);
  kernel_end = .;
}

Zitat
Verwendest du ein Tutorial/eine Anleitung wie man Qemu mit Eclipse nutzen kann?
Nein, nicht direkt. Ich habe allerdings auch schon im Internet rumgeschaut.

Zitat
Also beim googeln ist z.b. das hier rausgekommen, das komplett anders eingerichtet ist.
Mein Problem ist das da ganz andere Optionen existieren.
Etwa nach der Mitte der Seite direkt nach den beiden schwarzen Bildschirmen kommt die Einrichtung des Debuggers.
Leider sieht das Dialogfenster etwas anders aus als meins und ich habe nicht alle Einstellungsmöglichkeiten von da.
Wie du sicher selbst siehst, werden dort eine ganze Reihe Einstellungen getätigt die es so bei mir gar nicht gibt (zb. in den angehängten Screens). Vermutlich wurde dort eine ältere Version verwendet... Auf jedenfall bin ich im Moment mit den Einstellungsmöglichkeiten beim Debugen etwas überfordert. Besonders weil eben einige bei mir einfach komplett fehlen.

Zitat
[...] weil ich glaube, dass in deinem Fall Eclipse versucht Qemu oder die .bat-Datei zu debuggen und nicht dein OS.
Das kann gut sein. Aber soll ich dann wählen? Remote Application? Attach to Application?  :?
4
Softwareentwicklung / In Eclipse OS in Qemu mit GDB debuggen
« am: 03. September 2013, 14:36 »
Ich versuche momentan wiedereinmal mein OS zu debuggen.
Vor einiger Zeit habe ich bereits einmal einen Anlauf gestartet:
Softwareentwicklung -> Thema: Kerneldebugging unter Windows mit QEmu & GDB
Inzwischen bin ich auf Eclipse umgestiegen.

Jetzt habe ich im Moment wieder zwei Probleme mit dem Debugging:
1. Wenn ich die Debuginformationen einschalte(egal ob g1, g2 oder g3), kann GRUB den Kernel nicht mehr starten.
Meldung von Grub:
  Booting 'start'
kernel /kernel.bin
Error 13: Invalid or unsupported executable format
Press any key to continue...
Ohne Debuginformationen hat GRUB keine Probleme den Kernel zu starten.

Als Postbuild führe ich noch folgende Befehle aus:
copy "%CD%\kernel.bin" "%CD%\..\cd\kernel.bin"
cd ..
mkisofs -R -J -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -o "cdrom.iso" "cd/"
i586-elf-objcopy --only-keep-debug "cd\kernel.bin" "kernel.sym"
copy "cd\kernel.bin" "kernel.sym"
i586-elf-objcopy --strip-debug "cd\kernel.bin"
Das Problem tritt auch auf, wenn ich die letzten drei Befehle zum extrahieren der Debuginformation auskommentiere.

2. Eclipse weigert sich im Moment beharrlich Qemu zu starten ("${project_loc}\RunDebugQemu.bat") und kommt immer mit einen nichtssagenden Fehlerfenster:
Excetion occurred during lauch
Reason:
Program is not a recognized executable.
Details:
Program is not a recognized executable.
  Program is not a recognized executable.
  Program is not a recognized executable.
Die oben erwähnte Batchdatei startet Qemu im Debugmodus und scheint zu funktionieren.

Im Moment habe ich meine Debug-Konfiguration im Abschnitt "C/C++ Application" erstellt. Vorher habe ich schonmal einen Versuch mit "C/C++ Remote Application" gestartet.

Da es schwierig ist alle möglicherweise wichtigen Einstellungen hier anzugeben, habe ich einen(/mehrere) Screens von den Einstellungen angehängt.
Meine "gdb.gdbinit" sieht so aus:
symbol kernel.sym
target remote 127.0.0.1:1234

Hoffentlich wisst ihr eine Lösung.
Ich bin inzwischen schon sehr genervt von meinen Debuggingproblemen...
5
Softwareentwicklung / Re: ld: "cannot find object file"?
« am: 01. June 2013, 11:58 »
Ja, das war es.  :-D
So einfach kann die Lösung sein.  :roll:
Vielen Dank dafür.
6
Softwareentwicklung / ld: "cannot find object file"?
« am: 31. May 2013, 23:44 »
Weil mir mit zunehmender "Größe" meines Betriebssystems der einfache Texteditor mir immer mehr zu umständlich wird, wollte ich heute mal Eclipse ausprobieren. Ich hab es geschafft die Umgebung passend einzurichten und die Sources richtig kompilieren zu lassen. Aber beim Linken kommt immer ein sehr seltsamer von mir nicht nachvollziehbarer Fehler "cannot find obj\init_S.o".
Bisher habe ich immer so gelinkt: (mit einer BAT)
i586-elf-ld -L "%GCC_PATH%\lib" -L "%GCC_PATH%\lib\gcc\i586-elf\%GCC_VERSION%" -T linkconf.ld -o obj\kernel.bin obj\*.o "%LIBGCC_FILE_NAME%" -Ttext=0x100000
In Eclipse sieht die Kommandozeile dann so aus:
Building target: kernel.bin
Invoking: Cross GCC Linker
i586-elf-ld -nodefaultlibs -nostdlib -static -L"C:\Programmordner\MinGW\OSprogramming\lib" -L"C:\Programmordner\MinGW\OSprogramming\lib\gcc\i586-elf\4.4.0" -Ttext=0x100000 -T "C:/Eigenes/Programmierung/Betriebssystem/System001\linkconf.ld" -o "kernel.bin"  ./stdlib/sysapi/api.o ./stdlib/sysapi/asm.o ./stdlib/sysapi/charconv.o ./stdlib/sysapi/console.o ./stdlib/sysapi/cpuid.o ./stdlib/sysapi/textio.o  ./stdlib/assert.o ./stdlib/errno.o ./stdlib/math.o ./stdlib/stdlib.o ./stdlib/string.o ./stdlib/time.o ./stdlib/uchar.o ./stdlib/wchar.o  ./kernel/api_intr.o ./kernel/com.o ./kernel/cpustate.o ./kernel/gdt.o ./kernel/intr.o ./kernel/lowlevelbeep.o ./kernel/lowlevelconsole.o ./kernel/lowleveltime.o ./kernel/mm.o ./kernel/mmp.o ./kernel/mmv.o ./kernel/pic.o ./kernel/process.o ./kernel/thread.o ./kernel/tss.o  ./init.o   -llibgcc.a
c:\Programmordner\MinGW\OSprogramming\bin\i586-elf-ld.exe: cannot find obj\init_S.o
make: *** [kernel.bin] Error 1


Weshalb sucht der Linker immer nach "init_S.o"?
Es gab vorher mal versehentlich eine so benannte Datei im Projekt, aber die ist schon lange gelöscht und sie taucht ja auch nicht in den Kommandozeilenparametern von Ld auf. Daher erschließt sich mir nicht ganz weshalb der Linker immer meint, er würde immer diese Datei brauchen.

Habt ihr eine Idee woher das kommen kann? Ich habe das Gefühl das ich ziemlich auf den Schlauch stehe.
7
Softwareentwicklung / Re: Binäre Datei auf CD brennen
« am: 01. May 2013, 19:39 »
Schau mal hier:
lowlevel.eu/wiki/GRUB#GRUB_legacy

(Insbesondere "2.3 CD-Image herstellen")
8
Hm also weil die "Affinic Debugger GUI" irgendwie gerade ein Problem hat, kann ich das nicht austesten,
aber in der Kommandozeile scheint es nichts zu bringen.
Es kommt auch genau der selbe Kommentar...
Reading symbols from ?:\*\*\*\System001\kernel.sym...(no debugging symbols found)...done.
... direkt am Anfang.
9
GDB ruft für mich die "Affinic Debugger GUI" auf.
Wieso, gibt es da etwas bestimmtes zu beachten?
10
Hm, hier steht aber das man da so macht:
wiki.osdev.org/How_Do_I_Use_A_Debugger_With_My_OS#Use_gdb_with_Qemu

Ich habe jetzt mal
i586-elf-objcopy --only-keep-debug "obj\kernel.bin" "kernel.sym"
in
copy "obj\kernel.bin" "kernel.sym"
geändert.

Dabei hat sich aber nichts geändert.
Immer noch haargenau die selbe Ausgabe.
11
Hm, leider scheint es immer noch nicht so ganz zu funktionieren.  :|
Ich habe mich nach einer GDB GUI umgesehen die unter Windows nutzbar ist.
Dabei bin ich auf die Affinic Debugger GUI gestoßen. (Wer etwas Besseres kennt - Vorschläge willkommen...)

Der Debugger startet ganz prima.
Durch den Assemblercode steppen ist auch kein Problem.
Im Stacktrace werden sogar die Methodennamen angezeigt.
Leider wird aber nicht der Quellcode angezeigt und wenn ich einen "Single-Line-Step machen" will kommt bloß eine Meldung.
GDB Ausgabe:
(gdb)  cd ?:\*\*\*\System001
Working directory ?:\*\*\*\System001.
(gdb) target remote 127.0.0.1:1234
Remote debugging using 127.0.0.1:1234
0x000090bd in ?? ()
(gdb) symbol-file kernel.sym
Reading symbols from ?:\*\*\*\System001\kernel.sym...(no debugging symbols found)...done.
(gdb) continue
Continuing.

Program received signal SIGINT, Interrupt.
0x001103bc in Mmv_Init ()
(gdb) interrupt
(gdb) next
Single stepping until exit from function Mmv_Init,
which has no line number information

GDB wird so initialisiert:
cd ?:\*\*\*\System001
target remote 127.0.0.1:1234
symbol-file kernel.sym

Kompilieren tu ich mit der Stapelverarbeitungsdatei im Anhang.
Auf das vermutlich Relevante beschränkt in Kurzform:
SET C_COMPILE=i586-elf-gcc -m32 -ffreestanding -Wall -nostdinc -std=gnu99 -I stdlib -O1 -fno-builtin -g
SET ASM_COMPILE=nasm -f elf32 -g

%ASM_COMPILE% -o obj\init_S.o init.S
%C_COMPILE% -o obj\init_c.o -c init.c

%C_COMPILE% -o obj\lowlevelbeep_c.o -c kernel\lowlevelbeep.c
%C_COMPILE% -o obj\lowlevelconsole_c.o -c kernel\lowlevelconsole.c
%C_COMPILE% -o obj\time_c.o -c kernel\lowleveltime.c
%C_COMPILE% -o obj\cpuid_c.o -c kernel\cpuid.c
%C_COMPILE% -o obj\gdt_c.o -c kernel\gdt.c
%C_COMPILE% -o obj\pic_c.o -c kernel\pic.c
%ASM_COMPILE% -o obj\intr_S.o kernel\intr.S
%C_COMPILE% -o obj\intr_c.o -c kernel\intr.c
%C_COMPILE% -o obj\cpustate_c.o -c kernel\cpustate.c
%C_COMPILE% -o obj\thread_c.o -c kernel\thread.c
%C_COMPILE% -o obj\process_c.o -c kernel\process.c
%C_COMPILE% -o obj\tss_c.o -c kernel\tss.c
%C_COMPILE% -o obj\api_intr_c.o -c kernel\api_intr.c
%C_COMPILE% -o obj\mm_c.o -c kernel\mm.c
%C_COMPILE% -o obj\mmp_c.o -c kernel\mmp.c
%C_COMPILE% -o obj\mmv_c.o -c kernel\mmv.c

@REM %C_COMPILE% %C_COMPILE% -E -o stdlib_math_c.i -c stdlib\math.c
@REM %C_COMPILE% -c -S -o stdlib_math_c.S -c stdlib\math.c
%C_COMPILE% -o obj\stdlib_math_c.o -c stdlib\math.c

%C_COMPILE% -o obj\stdlib_string_c.o -c stdlib\string.c
%C_COMPILE% -o obj\stdlib_stdlib_c.o -c stdlib\stdlib.c

%C_COMPILE% -o obj\api_api_c.o -c kernel\api\api.c
%C_COMPILE% -o obj\api_console_c.o -c kernel\api\console.c

i586-elf-ld -L "%GCC_PATH%\lib" -L "%GCC_PATH%\lib\gcc\i586-elf\%GCC_VERSION%" -T linkconf.ld -o obj\kernel.bin obj\*.o "%LIBGCC_FILE_NAME%" -Ttext=0x100000

i586-elf-objcopy --only-keep-debug "obj\kernel.bin" "kernel.sym"
i586-elf-objcopy --strip-debug "obj\kernel.bin"

copy obj\kernel.bin cd\kernel.bin

mkisofs -R -J -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -o cdrom.iso cd/

Ich hoffe, ihr habt vielleicht eine Vermutung was die Ursache sein könnte.  :-)
12
Mit der Version scheint das Debuggen zu funktionieren.

Vielen dank für deine Hilfe.  :wink:
13
Die Version: QEMU emulator version 1.0,1, Copyright (c) 2003-2008 Fabrice Bellard

Die Tastenkombination löst Qemu aus der Erstarrung, aber Debuggen tut sich da nichts.
In GDB kommt immernoch nur langsam sowas (mit leichter Variation)...
(gdb) target remote 127.0.0.1:1234
Remote debugging using 127.0.0.1:1234
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
warning: Invalid remote reply: timeout
Remote communication error.  Target disconnected.: No error.

EDIT:
Ich habe mir gerade von hier(omledom.com) eine aktuellere Version heruntergeladen.
Leider startet die nicht, mit der Meldung... "Could not read keymap file: 'en-us'"
14
Zitat
Das musst du selbst von der Qemu-Console aus tun.
Ich dachte, dass macht macht der Debugger dann automatisch?
Mit "continue" oder so änlich...


Zitat
In die Konsole kommst du mit der Tastenkombination Strg-Alt-F2.
Hm, funktioniert bei mir irgendwie nicht.
Wenn ich das drücke, wird der Curser unsichtbar und nichts passiert.  :|

Nachdem ich in GDB "target remote localhost:1234" eingeben habe, kommen nacheinander die obigen Zeilen in großen Zeitabständen. Und ich kann nichts mehr eingeben.
Manchmal kommt am Ende anstatt ""
15
Da ich vor ein paar Tagen mich wieder der Betriebssystementwicklung zugwandt habe und momentan gerade dabei bin die virtuelle Speicherverwaltung zu implementieren in der einige nicht ganz triviale Algorithmen vorkommen, würde ich jetzt auch gerne Debugger nutzen. Ich habe bereits den Wikieintrag und diesen Forenbeitrag gelesen.

Leider funktioniert das ganze aber noch nicht so recht.  :-(
Qemu verharrt im schwarzen Fenster während GDB folgendes ausgibt...
?:\*\*>gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) target remote 127.0.0.1:1234
Remote debugging using 127.0.0.1:1234
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
warning: Invalid remote reply: timeout

QEmu rufe ich folgendermaßen auf...
SET IMAGENAME=cdrom.iso
SET DEBUGPARAMS=-gdb tcp:127.0.0.1:1234 -S
FOR /f "tokens=*" %%i IN ('cd') DO SET AKTPFAD=%%i
call ..\QemuFolder.bat
qemu-system-i386.exe %DEBUGPARAMS% -m 4 -cdrom "%AKTPFAD%\%IMAGENAME%" -cpu pentium3 -L "%cd%\pc-bios" -localtime -soundhw all -D "%AKTPFAD%\qemu.log" -d int

Der Kernel würde momentan noch ohne Debuginfos erstellt, aber das sollte nicht der Grund sein, weshalb die Konnektion zu GDB fehlschlägt.

Was ich mich aber auch noch frage ist, ob man mit MinGW Binärcode debuggen kann, der mit "i586-elf-gcc" aus dem Wiki erstellt wurde?

EDIT:
Ich sehe gerade, das das Thema wohl eher in die Kategorie "Softwareentwicklung" gepasst hätte.
Vlt kann das bitte nochmal ein freundlicher Moderator verschieben.  :wink:
16
Offtopic / Re: Logisim CPU
« am: 06. December 2012, 14:50 »
Ich selber beschäftige mich schon seit einiger Zeit mit dem "virtuellen Prozessorbau".
Allerdings nicht in einer Logiksimulation sondern in Form von zellulären Automaten.

Derzeit baue ich einen sehr einfachen Neumann 32Bit RISC Prozessor.
Grob inspiriert wurde ich ursprünglich von den Pic-Mikrocontrollern von Microchip. (So änlich wie die Avrs. Ich persönlich verwende ausschießlich solche, was aber hauptsächlich Geschmackssache ist.)

Das Design habe ich als Pdf angehängt. Vielleicht enthält es wiederrum für dich die eine oder andere Inspiration.  :wink:
Spezielle Befehle wie Goto\If\In\Out gibt es darin nicht. Die Peripherie wird auf die selbe Weise angesprochen wie der Speicher. ("Memory-Mapped-Hardware" wie es erik.vikinger genannt hat)

Der Programmcounter ist (fast) ein ganz normales Register. Beim Sprung wird einfach der Registerwert neu gesetzt, genauso wie beim Setzten eines X-beliebigen anderen Registers.
Stackpointer und co sind wegrationalisiert. Entweder wird der Stack softwaremäßig emuliert oder der Rücksprung wird einfach durch "goto"-Konstrukte ersetzt. Das sollte dann der Compiler erledigen können. Das es später einmal einen hardwaremäßigen Stack gibt, schließe ich jetzt auch nicht hundertprozentig aus.

Der Bus sieht bei mir so aus:
Eine Anfrage besteht aus Befehl, Adresse und Daten\Feedback. (Daten beim Schreiben\Feedback beim Lesen)
Nun werden die Anfragen im Scheduler zwischengespeichert(Queue) und weitergegeben sobald das "Gerät", das in dem Adressbereich liegt, bereit ist.
Das "Gerät" speichert entweder die Daten an der Adresse oder es liest an der Adresse und schickt die gelesenen Daten wieder zurück mit dem angehängten Feedback. Was es tut, hängt vom Befehl ab.
Die Komponente die die Anfrage gestellt hat erkennt an dem Binärcode im Feedback, dass jetzt die Daten kommen, die es angefordert hat.

Da es in Logiksim aber scheinbar keine Durchlaufzeit gibt, kann man das wahrscheinlich deutlich einfacher gestallten.
Eine umfangreiche Komponente die die ganzen Anfragen "managt" kann man sich dann auch sparen.
Das alles passiert in meinem Fall seriell. In der Realität und auch Logiksim ist es parallel eher geschickter.
17
Lowlevel-Coding / Re: Exception bei Mutitasking
« am: 03. December 2012, 20:53 »
Ok, danke für den Tipp. Werde ich versuchen.
Ich habe derweil meinen vorherigen Post "überarbeitet".   :wink:

EDIT:
Das hat schonmal wirklich geholfen.  :-)
Ein Geheimtipp den ich mir unbedingt merken sollte.

Den Assemblerausschnitt bei der Adresse:
00102490 <Console_CurserMove>:
  102490: 55                    push   %ebp
  102491: 89 e5                mov    %esp,%ebp
  102493: 80 3d 65 68 10 00 00 cmpb   $0x0,0x106865
  10249a: 74 22                je     1024be <Console_CurserMove+0x2e>
  10249c: ba d4 03 00 00        mov    $0x3d4,%edx
  1024a1: b0 0e                mov    $0xe,%al
  1024a3: ee                    out    %al,(%dx)                             ;Hier kracht es...
  1024a4: 8b 0d 30 69 10 00    mov    0x106930,%ecx
  1024aa: 89 c8                mov    %ecx,%eax
  1024ac: c1 e8 08              shr    $0x8,%eax
  1024af: b2 d5                mov    $0xd5,%dl
  1024b1: ee                    out    %al,(%dx)
  1024b2: b2 d4                mov    $0xd4,%dl
  1024b4: b0 0f                mov    $0xf,%al
  1024b6: ee                    out    %al,(%dx)
  1024b7: b2 d5                mov    $0xd5,%dl
  1024b9: 88 c8                mov    %cl,%al
  1024bb: ee                    out    %al,(%dx)
  1024bc: eb 17                jmp    1024d5 <Console_CurserMove+0x45>
  1024be: ba d4 03 00 00        mov    $0x3d4,%edx
  1024c3: b0 0e                mov    $0xe,%al
  1024c5: ee                    out    %al,(%dx)
  1024c6: b2 d5                mov    $0xd5,%dl
  1024c8: b0 07                mov    $0x7,%al
  1024ca: ee                    out    %al,(%dx)
  1024cb: b2 d4                mov    $0xd4,%dl
  1024cd: b0 0f                mov    $0xf,%al
  1024cf: ee                    out    %al,(%dx)
  1024d0: b2 d5                mov    $0xd5,%dl
  1024d2: b0 d0                mov    $0xd0,%al
  1024d4: ee                    out    %al,(%dx)
  1024d5: 5d                    pop    %ebp
  1024d6: c3                    ret   

Es scheint es Probleme beim "out"-Befehl zu geben.
Aber nur im Multitasking. Im Kernel funktioniert es.
Liege ich mit meiner Vermutung richtig, dass ich zum Lösen des Problemes Syscalls einbauen müsste?
18
Lowlevel-Coding / Re: Exception bei Mutitasking
« am: 03. December 2012, 20:23 »
Wie kriege ich denn raus, welcher Code an 0x1024a3 liegt?
Debuggen algemein ist in der Betriebssystementwicklung ja generel eher schwer möglich.
Das einzige was ich sicher weiß ist noch, dass der Fehler nicht auftrit, wenn ich "Console_WriteChar" in den Multitaskthreads auskommentiere...

init.c
void Write0()
{
    while(true)
    {
        //halt();
        Console_WriteChar('0');
        for(int i = 0; i < 0x6fffff; i++) nop10();
    }
}
void WriteX()
{
    while(true)
    {
        //halt();
        Console_WriteChar('X');
        for(int i = 0; i < 0x6fffff; i++) nop10();
    }
}
void main(Multiboot_Info* MultibootInfo)
{
    Time_Read(&StartTime);
    Console_ClearScreen();
       
    Console_WriteHeader("Kernel gestartet!");
    Console_Write("Bootloader: ");
    Console_WriteLine(MultibootInfo->BootloaderName);
    Console_Write("Prozessorhersteller: ");
    int Processorvendor = CpuId_ReadVendor();
    Console_WriteVendor(Processorvendor);
    Console_NewLine();
    if (Processorvendor == CPUID_VENDOR_INTEL)
    {
        Console_Write("Prozessortype: ");
        Console_WriteIntelProcName();
        Console_NewLine();
    }
    Console_Write("Startzeit: ");
    Console_WriteTime(&StartTime);
    Console_NewLine(); Console_NewLine();
   
    Console_WriteHeader("Lade Kernel");
    Gdt_Init();
   
    ProcessCount = 2;
    Processes[0] = Process_New();
    Processes[0].Threads[0] = Thread_New(Proc0Thread0Stack, THREAD_STACKSIZE, Proc0Thread0UserStack, THREAD_USERSTACKSIZE, &WriteX);
    Processes[1] = Process_New();
    Processes[1].Threads[0] = Thread_New(Proc1Thread0Stack, THREAD_STACKSIZE, Proc1Thread0UserStack, THREAD_USERSTACKSIZE, &Write0);
   
    Intr_Init();
    stop();
}

console.c
#define CONSOLE_LINELENGTH (80)
#define CONSOLE_LINECOUNT (25)
#define CONSOLE_CHARCOUNT (CONSOLE_LINECOUNT * CONSOLE_LINELENGTH)
#define CONSOLE_VIDEO ((uint16_t*) 0xb8000)

__attribute__((unused)) uint32_t Console_Curser = 0;
__attribute__((unused)) uint32_t Console_UsingLines = 23;
__attribute__((unused)) uint8_t Console_Format = 0x07;
__attribute__((unused)) bool Console_ShowCurser = true;

[...] //Sehr viel jetzt nicht relevanter Code

void Console_ShiftUp()
{
    for(int i = 0; i < CONSOLE_CHARCOUNT; i++)
    {
        if (i < (CONSOLE_CHARCOUNT - CONSOLE_LINELENGTH))
        {
            //Untere Zeile nach oben kopieren
            CONSOLE_VIDEO[i] = CONSOLE_VIDEO[i + CONSOLE_LINELENGTH];
        }
        else
        {
            //Unterste Zeile leeren
            CONSOLE_VIDEO[i] = ((uint16_t)EMPTYCHAR) | (((uint16_t)Console_Format) << 8);
        }
    }
    //Curser eine Zeile nach oben verschieben
    Console_Curser -= CONSOLE_LINELENGTH;
    Console_CurserMove();
}

void Console_NewLine()
{
    //Zeiger platzieren
    Console_Curser -= Console_Curser % CONSOLE_LINELENGTH;
    Console_Curser += CONSOLE_LINELENGTH;
   
    //Zeilen hochschieben wenn nötig
    if (Console_UsingLines >= (Console_Curser * CONSOLE_LINELENGTH))
    {
        Console_ShiftUp();
    }   
}

void Console_WriteChar(const char Char)
{
    //Zeiger platzieren
    if (Char == NEWLINE)
    {
        Console_NewLine();
        return;
    }

    //Zeilen hochschieben wenn nötig
    if ((Console_Curser / CONSOLE_LINELENGTH) >= Console_UsingLines)
    {
        Console_ShiftUp();
    }     

    //Zeichen schreiben
    CONSOLE_VIDEO[Console_Curser++] = ((uint16_t)Char) | (((uint16_t)Console_Format) << 8);
}
19
Lowlevel-Coding / Exception bei Mutitasking
« am: 03. December 2012, 18:39 »
Also ich wollte mal nach langer Zeit mal wieder an meinem OS weiterarbeiten.
Das Problem ist, der Kernel löst nach dem 400 Timerinterupt beim Taskwechsel vom 1. Prozess zurück in den 0. eine Generall Protection Exception (13) aus.

Da das Multitasking aus mehreren größeren Dateien besteht, hab ich es angehängt.
Wäre um einen Tipp, wie ich dem Fehler zu Leibe rücken kann, sehr dankbar.  :-)
Was mich so irritiert ist, dass der Taskwechsel vorher einigemale klappt.

Die Textdatei im Anhang ist eine falsche 7-Zip-Datei, damit ich sie hochladen kann.
Warum sind hier keine Zipdateien erlaubt? Finde ich ziemlich umständlich.  :wink:
20
Lowlevel-Coding / Re: Port 0x60 leeren - Tastaturtreiber
« am: 09. May 2012, 11:41 »
Natürlich kann auch ein Interrupt ausgelöst werden.
Ist im Wiki auch genauestens beschrieben:
http://www.lowlevel.eu/wiki/KBC#IRQ-Handler
http://www.lowlevel.eu/wiki/IRQ#IRQ_Tabelle
Seiten: [1] 2 3

Einloggen