Autor Thema: bochs debug-problem  (Gelesen 8375 mal)

middle_endian

  • Beiträge: 25
    • Profil anzeigen
Gespeichert
« am: 12. July 2007, 23:26 »
hi,
wenn ich unter linux versuche meinen bootloader+kernel mittels bochs zu laden und mich dann per gdb zu bochs connecte, hab ich weder die möglichkeit den code per single-step durchzugehn, noch break points zu setzen. das einzige, das funktioniert, ist das programm einfach komplett durchlaufen zu lassen.
hab versucht mittels nasm mittels -g zu sagen, dass er debuginformationen miterstellen soll. bringt aber auch nichts.
wenn ich mittels "s" in gdb versuche einen singlestep durchzuführen, bekomme ich die meldung "Cannot find bounds of current function". wenn ich versuche mittels "b 0x0000:0x7c00" einen breakpoint zu setzen, bekomm ich "No symbol table is loaded. use the "file" command".
woran kann das liegen?

danke
« Letzte Änderung: 12. July 2007, 23:30 von middle_endian »

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 13. July 2007, 08:43 »
Öhm, ich würde mal stark bezweifeln, daß gdb mit 16-Bit-Code umgehen kann (deine Adresse sieht jedenfalls sehr danach aus, daß du das versuchst). Setz einen Breakpoint in deinen Kernel und laß dann erstmal weiterlaufen.

Ohne Debugsymbole kannst du übrigens nur si benutzen, das dann einen Assemblerbefehl abarbeitet. s soll ja eine Quellcodezeile abarbeiten, aber welche Befehle die umfaßt, ist ohne Debuginformationen nicht bekannt.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

middle_endian

  • Beiträge: 25
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 13. July 2007, 14:13 »
Setz einen Breakpoint in deinen Kernel und laß dann erstmal weiterlaufen.
und wie stell ich das an? hab versucht vor dem ersten befehl im kernel int 3 bzw 0xcc aufzurufen, aber das versetzt mich auch nicht in den debugger.
unter windows läuft das debugging mit bochs wunderbar. lieber wärs mir, wenns umgekehrt wär :)

middle_endian

  • Beiträge: 25
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 16. July 2007, 08:44 »
hi,
ich hab mir dieses wochenende noch ein ganzes weilchen den kopf darüber zerbrochen, wie ich meinen code unter linux debuggen kann, aber da ich mit qemu/gdb bzw bochs/gdb einfach nicht weiterkomm(offenbar kann gdb mit dem 16bit code ohne debuginfos genau gar nichts anfangen) frag ich mich, wie ihr euren code unter linux debugged?
weiß außerdem vielleicht jemand was bochs unter windows intern für nen debugger verwendet? hab eigentlich angenehmen, dass gdb verwendet wird, aber da das debuggen unter windows funktioniert - es aber wenn ich den gdb unter windows mit bochs quasi standalone verwendet nicht funktioniert - hab ich diesen gedanken wieder verworfen.

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 16. July 2007, 11:23 »
aber da ich mit qemu/gdb bzw bochs/gdb einfach nicht weiterkomm(offenbar kann gdb mit dem 16bit code ohne debuginfos genau gar nichts anfangen) frag ich mich, wie ihr euren code unter linux debugged?
Daß gdb ohne Debuginfos mit dem 16-Bit-Code nichts anfangen kann, dürfte richtig sein. Genauso richtig dürfte es aber sein, daß gdb auch mit Debuginfos nichts mit 16-Bit-Code anfangen kann. ;)

Meine Lösung: Ich habe einfach keinen 16-Bit-Code. Es lebe GRUB.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

middle_endian

  • Beiträge: 25
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 16. July 2007, 15:21 »
sprich, wenn ich mich in den protected-mode einlese und diesen verwende, funktioniert das debuggen mittels gdb?

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #6 am: 16. July 2007, 15:36 »
Jo, den realmode verwendet eh keiner mehr. Ist auch der letzte Schrott.
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #7 am: 16. July 2007, 15:50 »
Jo, den realmode verwendet eh keiner mehr. Ist auch der letzte Schrott.
Stimmt so nicht. Ich habe mir ein Microcode-Update lieber als DOS Startdiskette geladen als als Windows Anwendung. Denn DOS traue ich bezüglich stabilität mehr zu als Windows. Und somit verwende ich, zwar selten aber immernoch manchmal den RealMode (bzw. DOS).

bitmaster
In the Future everyone will need OS-64!!!

nooooooooos

  • Beiträge: 734
    • Profil anzeigen
Gespeichert
« Antwort #8 am: 16. July 2007, 16:23 »
bitmaster das hat aber eher was damit zu tun, das DOS von Microsoft nur gekauft und nicht entwickelt wurde...

Nooooooooooos

bitmaster

  • Troll
  • Beiträge: 1 138
    • Profil anzeigen
    • OS-64 = 64 Bit Operating System
Gespeichert
« Antwort #9 am: 16. July 2007, 16:39 »
bitmaster das hat aber eher was damit zu tun, das DOS von Microsoft nur gekauft und nicht entwickelt wurde...

Nooooooooooos
Nur dumm das DOS in der Version 6.X tausende von Quellcodezeilen hat und DOS 1 nur 4.000. Außerdem konnte die erste DOS Version nicht einmal mit Verzeichnissen/Festplatten usw. umgehen. Ich schätze das 90% Anteil von dem DOS-Quellcode von Microsoft stammen. Außerdem war das gar nicht das Thema.

bitmaster
In the Future everyone will need OS-64!!!

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #10 am: 16. July 2007, 17:34 »
Mein PC bootet übrigens auch im Realmode :-o  :mrgreen:  :roll:
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #11 am: 16. July 2007, 17:36 »
Du solltest auf eine andere Architektur umsteigen. ;)
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

middle_endian

  • Beiträge: 25
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 18. July 2007, 14:28 »
ok, hab jetzt einen mini 32bit assembler kernel, der von meinem bootloader geladen wird. debuggen geht aber immer noch nicht...
da ich in dieser hinsicht scheinbar dauernd mit dem kopf gegen die wand renne, würd mich einfach (etwas allgemeiner gesehn) interessiern, wie ihr euren kernel unter linux debugged(kein c, nur assembler code)?!

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #13 am: 18. July 2007, 17:57 »
Ich nutze meistens den bochs debuger, bochs logs, disassemblies, stacktraces, "cli-hlt", printf/cout.
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

middle_endian

  • Beiträge: 25
    • Profil anzeigen
Gespeichert
« Antwort #14 am: 18. July 2007, 21:03 »
Ich nutze meistens den bochs debuger, bochs logs, disassemblies, stacktraces, "cli-hlt", printf/cout.
wie startest du unter linux diesen bochs-internen debugger?

edit: halleluja, nachdem ich bochs ein zweites mal mit den korrekten parametern kompiliert hab, funktioniert das debuggen jetzt endlich!
« Letzte Änderung: 18. July 2007, 21:42 von middle_endian »

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #15 am: 18. July 2007, 22:56 »
[...] funktioniert das debuggen jetzt endlich!
Der eingebaute debugger oder mit gdb?
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

middle_endian

  • Beiträge: 25
    • Profil anzeigen
Gespeichert
« Antwort #16 am: 18. July 2007, 22:59 »
der eingebaute. den ich fälschlicherweise als nicht vorhanden abgestempelt hab, und gdb dafür die schuld gegeben hab.

 

Einloggen