Autor Thema: In Eclipse OS in Qemu mit GDB debuggen  (Gelesen 10018 mal)

OS_3000

  • Beiträge: 53
    • Profil anzeigen
Gespeichert
« 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...

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 03. September 2013, 22:06 »
1. Wenn ich die Debuginformationen einschalte(egal ob g1, g2 oder g3), kann GRUB den Kernel nicht mehr starten.
Und mit -g? Ansonsten müsstest du mal die Ausgabe von objdump -x herzeigen.

Verwendest du ein Tutorial/eine Anleitung wie man Qemu mit Eclipse nutzen kann? Also beim googeln ist z.b. das hier rausgekommen, das komplett anders eingerichtet ist. Ich hab meine Zweifel, dass du Qemu so verwenden kannst, wie du es tust, weil ich glaube, dass in deinem Fall Eclipse versucht Qemu oder die .bat-Datei zu debuggen und nicht dein OS.
Dieser Text wird unter jedem Beitrag angezeigt.

OS_3000

  • Beiträge: 53
    • Profil anzeigen
Gespeichert
« Antwort #2 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?  :?
« Letzte Änderung: 03. September 2013, 22:47 von OS_3000 »

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 03. September 2013, 22:59 »
Die Ausgabe habe ich angehängt.
In dem Dump wird der Multibootheader an der virtuellen Adresse 00111a30 angegeben. Das ist zu weit hinten. Ich glaube das Problem ist, dass du in die .text-Sektion alle Sektionen aus init.o und initasm.o ziehst. Ich weiß nicht was die beiden Dateien bei dir machen, aber du solltest dafür sorgen, dass der Multiboot-Header am Anfang landet und dahinter die .text-Sektionen der anderen Dateien.

Zum Beispiel zieht dieser Ausschnitt die Text-Sektionen aus den beiden Dateien. Die anderen Sektionen (.data, ...) werden ganz normal von den anderen Statements verarbeitet.
  .text :
  {
    init.o(.text)
    initasm.o(.text)
    *(.text)
  }

Das kann gut sein. Aber soll ich dann wählen? Remote Application? Attach to Application?  :?
Remote Application klingt nicht schlecht. Aber ich hab von Eclipse zu wenig Ahnung um dazu mehr sagen zu können.
Dieser Text wird unter jedem Beitrag angezeigt.

OS_3000

  • Beiträge: 53
    • Profil anzeigen
Gespeichert
« Antwort #4 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.
« Letzte Änderung: 03. September 2013, 23:26 von OS_3000 »

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 03. September 2013, 23:37 »
Ich habe das Gefühl das damit das Remote Debuggen einer Anwendung auf einen anderen System gemeint ist. Nicht das System selber.
Es funktioniert auch auf dem lokalen System. In deiner gdbinit hast du ja auch target remote 127.0.0.1 geschrieben. Es ist vermutlich dasselbe Konzept von Remote System gemeint.

Meine Vermutung ist, dass diese Connection-Geschichte (auf dem Main-Tab) dazu dienen soll, Eclipse beizubringen, wie man im Falle eines tatsächlichen Remote Systems die kompilierte Executable dahin kopiert bekommt. Ich nehme an, dass Local die korrekte Einstellung ist, und keine neue Connection benötigt wird. Vielleicht musst du bei "Remote Absolute File Path for C/C++ Application" den Pfad zur kernel.bin angeben. Das Tab Debugger sieht auch ganz interessant aus. Da kannst du ihm eventuell beibringen, dass du gdb nutzen willst, und wo die gdbinit zu finden ist. Möglicherweise musst du da allerdings das Connection-Tab ausfüllen.

edit: Wow, wie oft ich "vermutlich", "möglicherweise", usw. geschrieben habe ...
« Letzte Änderung: 03. September 2013, 23:40 von Jidder »
Dieser Text wird unter jedem Beitrag angezeigt.

OS_3000

  • Beiträge: 53
    • Profil anzeigen
Gespeichert
« Antwort #6 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:
« Letzte Änderung: 04. September 2013, 11:20 von OS_3000 »

 

Einloggen