Bochs w/ remote GDB - not functional

[vargadanis]

Hello everyone,

(first post)... So I've decided to save the world and write an OS. Ya all know how that is.
So I started by going through some manuals, read up on it and now I bumped into a problem.
Using bochs and my little tiny kernel with debugging symbols enabled I somehow cannot debug my application.

#bochsrc
megs: 64
romimage: file=/usr/share/bochs/BIOS-bochs-latest
floppya: 1_44=./bootfloppy/floppy.img, status=inserted
boot: floppy
log: bochsout.txt
gdbstub: enabled=1, port=1234, text_base=0, data_base=0, bss_base=0

The floppy has a grub on it, fat12 formatted and the kernel is loaded from there...

#switches for gcc
CC=gcc
CFLAGS=-Wall -nostdlib -nostartfiles -nodefaultlibs -I$(INCLUDES) -g3 -ggdb

Well I suppose only the -g and -ggdb are relevant now..

so: bochs -q -> start up bochs
stops execution waiting for gdb to connect to it.. So far so good

>gdb kernel/kernel.bin
Reading symbols from /kernel/kernel.bin...done.
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
warning: Remote failure reply: Eff
0x00000000 in ?? ()
(gdb) b kernel.c:12
Breakpoint 1 at 0x100026: file kernel.c, line 12.
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0005799b in ?? ()
(gdb) list

So with the above example debugging I have 2 problems:

• warning: Remote failure reply: Eff ---> What does that mean?
• when issuing list no matter where I am or where I have set a breakpoint it only lists the first 10 or so lines of kernel.c file on which the kmain() function is

Any help where I screw debugging up would be much appreciated...

edit: the first few lines of kernel.c http://pastebin.com/5hyiTkKC

[bewing]

Hi, I am creating my own emulator, and I just created the gdb stub code for it.
During that process, it was necessary for me to wade through the entire bochs gdb stub several times until I understood it quite well.

The first thing to say is that the version that I looked at was a couple years old. But it had quite a few bugs in it. At the least, though, I know the answer to your two questions.

When GDB connects to an emulator, it sends a sequence of about a dozen commands. It does not expect the emulator to understand them all -- in fact, that's why GDB does it ... it examines the replies to find out which commands are supported by the stub and which are not.

So: question #1 -- WTF does "Eff" mean? GDB has a protocol where commands have a specific set of replies. Either data in the form of hex, an empty packet (for commands that are not understood), "OK", or an 'error response' in the form of a capital E followed by a 2 digit hex error number. The error number was never standardized by GDB, so stubs are allowed to send any old 2 digit hex number they feel like. So 'Eff" is a generic error response from the bochs GDB stub to a partially supported command that it didn't like -- probably a 'q' command of some sort.

Question #2 -- why only a few lines? For some really stupid reason, bochs only has a 255 byte buffer for memory transfers in the GDB stub. When you ask gdb for a disassembly, it requests a block of memory from bochs. Now, GDB is also a bit stupid -- it tries to limit the size of its packets to about 150 to 300 bytes -- so it might not be all bochs' fault. But the point is that you can't really fit very much disassembly into a measly 255 bytes.