Autor Thema: Kerneldebugging unter Windows mit QEmu & GDB  (Gelesen 8891 mal)

OS_3000

  • Beiträge: 53
    • Profil anzeigen
Gespeichert
« am: 27. April 2013, 22:37 »
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:
« Letzte Änderung: 27. April 2013, 23:04 von OS_3000 »

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 27. April 2013, 23:11 »
Der Parameter -S sorgt dafür, dass Qemu die virtuelle Maschine nicht direkt startet. Das musst du selbst von der Qemu-Console aus tun. In die Konsole kommst du mit der Tastenkombination Strg-Alt-2. Der Befehl zum Starten ist einfach c (oder cont). Zurück zum Bildschirm kommst du mit Strg-Alt-1. Das sollte der Grund dafür sein, dass der Bildschirm schwarz ist.

Auf die Packetfehler kann ich mir keinen Reim machen. Der MinGW-GDB sollte aber auch ELF-Dateien können.

Edit: Du solltest außerdem GDB die Binary auch irgendwie mitteilen. Entweder als Parameter beim Aufruf oder in der GDB-Console.
« Letzte Änderung: 28. April 2013, 00:11 von Jidder »
Dieser Text wird unter jedem Beitrag angezeigt.

OS_3000

  • Beiträge: 53
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 27. April 2013, 23:49 »
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 ""

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 28. April 2013, 00:10 »
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.  :|
Sorry, falsche Tastenkombination. Ich meine Strg-Alt-2 bzw. Strg-Alt-1 (Zahlen jeweils die über den Buchstaben).

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...
Hm, stimmt das sollte auch gehen.

Welche Qemu-Version nutzt du?
« Letzte Änderung: 28. April 2013, 00:13 von Jidder »
Dieser Text wird unter jedem Beitrag angezeigt.

OS_3000

  • Beiträge: 53
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 28. April 2013, 16:33 »
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'"
« Letzte Änderung: 28. April 2013, 16:52 von OS_3000 »

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 28. April 2013, 18:16 »
Du könntest mal versuchen QEMU von http://qemu.weilnetz.de/ runterzuladen. Ich hab nie das QEMU von da benutzt, aber bei anderen scheint es zu funktionieren. Ich glaube w32/qemu-20121125-w32.exe bzw. w64/qemu-20121204-w64.exe (je nach Windows-Version) ist die richtige Datei.
Dieser Text wird unter jedem Beitrag angezeigt.

OS_3000

  • Beiträge: 53
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 28. April 2013, 20:10 »
Mit der Version scheint das Debuggen zu funktionieren.

Vielen dank für deine Hilfe.  :wink:

OS_3000

  • Beiträge: 53
    • Profil anzeigen
Gespeichert
« Antwort #7 am: 29. April 2013, 21:19 »
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.  :-)
« Letzte Änderung: 29. April 2013, 21:23 von OS_3000 »

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #8 am: 29. April 2013, 21:37 »
Da darfst du den Kernel wohl nicht strippen. Nur weil du die Symbole aus der Datei mit den Debuginfos lädst, heißt das nicht, dass er auch den Quellcode daraus lädt. Du solltest GDB einfach die ungestrippte Binary beim Start als Parameter übergeben. Kannst ja vorm Strippen eine Kopie anlegen.
Dieser Text wird unter jedem Beitrag angezeigt.

OS_3000

  • Beiträge: 53
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 29. April 2013, 22:00 »
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.

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #10 am: 29. April 2013, 22:13 »
Wie rufst du GDB auf?
Dieser Text wird unter jedem Beitrag angezeigt.

OS_3000

  • Beiträge: 53
    • Profil anzeigen
Gespeichert
« Antwort #11 am: 29. April 2013, 22:18 »
GDB ruft für mich die "Affinic Debugger GUI" auf.
Wieso, gibt es da etwas bestimmtes zu beachten?

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 29. April 2013, 22:19 »
Du solltest die ungestrippte Kernel Binary als Kommandozeilenparemeter übergeben. Meine Vermutung ist, dass nur dann auch der Quellcode zur Verfügung steht. Der Befehl symbol-file klingt zumindest nicht so, als ob er das könnte.
Dieser Text wird unter jedem Beitrag angezeigt.

OS_3000

  • Beiträge: 53
    • Profil anzeigen
Gespeichert
« Antwort #13 am: 29. April 2013, 22:41 »
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.

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #14 am: 29. April 2013, 22:43 »
Hm, dann hab ich auch keine Idee mehr.
Dieser Text wird unter jedem Beitrag angezeigt.

 

Einloggen