Sysprogs forums › Forums › VisualGDB › VisualGDB + Bochs
- This topic has 1 reply, 2 voices, and was last updated 10 years ago by support.
-
AuthorPosts
-
November 24, 2014 at 00:03 #932b9brej5nParticipant
I am developing an OS as a hobby. Part of the development is running the OS in emulators/simulators, e.g. VMware and Bochs. Since Bochs has a gdb stub, I am trying to pair it with VisualGDB since I am using Visual Studio as the development environment. I managed to get it to connect by specifying a custom GDB stub in the Project properties:
GDBServer/stub: x:xxxxxxxxxxxBochs-2.6.7bochs_msvc_gdb.exe -q
GDBServer port: 1234and specifying an additional command for GDB after it connects to the target:
break *0x21160When I select Debug with GDB from the Debug menu, Bochs launches just fine, accepts the connection from GDB and stops at the breakpoint. VisualGDB complains about a ‘signal 0’, but the problem is that it can’t decode the i386 registers reported by Bochs:
eax = 0x000000a0 ecx = 0x00000000 edx = 0x00000000 ebx = 0x00000000
esp = 0x000003d5 ebp = 0x00000000 esi = 0x000003d5 edi = 0x00000000
eip = 0x00020318cs = 0x00000000 ss = 0x00000000 ds = 0x00007ff4 es = 0x00000000
fs = 0x00007fe8 gs = 0x00000000Now I can see from the log file of Bochs that it correctly inserted the breakpoint at 0x21160 (which is an address in the OS image I know will be executed at initialization and I can confirm this by using the built-in debugger of Bochs), but the registers seem to be completely mixed up. You can’t have segment registers with values like 0x7ff4 or 0x0, on the other hand the 0xA0 in eax is likely to be the value of cs. The 0x7ff4 and 0x7fe8 are addresses pointing inside the stack… You get the idea.
I have looked through this forum but I haven’t found anyone either trying to use VisualGDB with Bochs. Is this scenario supported? I don’t know which end (VisualGDB or Bochs) interprets/sends the registers incorrectly but clearly they can’t talk to each other. Is there some specification about what format VisualGDB expects?
I have Bochs version 2.6.7 fresh off Sourceforge, compiled with
./configure –target=pentium-windows –enable-sb16 –enable-ne2000 –enable-all-optimizations –enable-cpu-level=6 –enable-x86-64 –enable-vmx=2
–enable-pci –enable-clgd54xx –enable-voodoo –enable-usb –enable-usb-ohci –enable-usb-xhci –enable-es1370
–enable-e1000 –enable-show-ips –disable-readline –without-x –enable-gdb-stub –with-win32 –with-rfb –with-nogui
(precompiled binaries don’t have the GDB stub)I have VisualGDB 4.2
November 26, 2014 at 01:27 #3452supportKeymasterHi,
It’s hard to say where exactly the problem is, but it’s somewhere between your GDB and the GDB stub. The GDBServer protocol uses hardcoded register positions, so if the stub and GDB make different assumptions about them, things will be mixed up.
We would advise using VMWare GDB stub instead (e.g. http://sysprogs.com/VisualKernel/tutorials/vmware/). You can also try explicitly compiling your GDB with XML support so that it will understand XML register descriptions reported by the stub (if Bochs supports them). If that does not help, the solution would be to dump the packets received from the GDB stub, compare the reply from Bochs with the reply from normal GDBServer and adjust the Bochs sources to make them compatible with GDB. -
AuthorPosts
- You must be logged in to reply to this topic.