OSDev.org

Hi all,

I'm working on setting up bochs on my Mac. From macports it works fine, but it doesn't have gdb stub or an internal debugger, and it's giving some problems compiling. I reckon I can fix it, but before I spend a lot of time working on that, what is the best option for debugging my OS:
- Bochs with gdb stub
- Bochs internal debugger
- Qemu

I've never used Qemu before, I've used both Bochs with gdb and internal debugger, but only briefly. What do you prefer and why?
I've read somewhere that Bochs GDB stub doesn't work with SMP. Is that true? Would that impact your decision?

Thanks in advance

I'm mainly using Bochs and its internal debugger for debugging my OS, so I can mainly comment on this one. Most important for me is that it shows lots of CPU internal information (descriptor tables, page tables, segment registers (including their shadowed parts), TLBs) and also information on several devices using the Bochs param tree. Displaying of this information together with other commands can be automated, so I can write automated tests and dump the results into a log file. (Most of the time I just do things like "set a breakpoint at x, run, dump register contents (and some other relevant information), quit".)

GDB is certainly a great debugger and it's usable with both QEMU and Bochs (with GDB stub). Unfortunately it has some problems with switching between 32 and 64 bit mode and crashes when I try to debug my 64 bit kernel, so for me it's rather usesless for kernel debugging... This problem used to persist for quite a long time, so it may or may not be fixed in the meantime.

Thanks for your reply!

Is there anybody else who can share their opinion? One opinion is very useful, but the more the better!

I also use bochs on mac, and I use it's internal debugger. The latest source compiles with apple's gcc toolchain out of the box, no problems. I've configured it with (Maybe not the best, but good for me. It worth mentioning that enabling iodebug will slow down simulation considerably)

As for it's debugger: first I was not satisfied with it at all, so I upgraded it a little bit to give more information on 64 bit structures (ist in 64 mode idt and such). I've already posted a diff somewhere on this forum, I'm sure you can find it. With this little patch and the "xchg bx,bx" hack it've became so powerful, that I never think of using anything else for debugging.

qemu come out of the box from apt-get or darwin port, and is pretty convenient.
However, qemu is simulator aimed at performance and it sometime will "work" even you do not do things properly - things that bite you later when you test on bochs or real hardware.

Bottom line, I keep both bochs and qemu as test platform - as it cost nothing, the more the better.

qemu come out of the box from apt-get

AFAIK, in Debian's repos, it's still <1.0. In Ubuntu <12.04's, it's still <1.0; in Mint <13's, it's still <1.0.

On most systems, or at least on those that aren't completely up-to-date (and, sadly, there are people staying away from updating their OSes), I would advise against getting it from distro's repos.

qemu has a pretty epic history of stability issues, of which the notorious incompatibility with GCC4. There have been quite a few breaks with backwards-compatibility, and while my gentoo already offers 1.1.1, 0.11 is still the "stable" default. Probably not in the least because quite a few distro maintainers are scared of the flamefests that typically follow substituting one bug with the other.

For most purposes, even the old versions of qemu work fine but just like the odd hardware vendors it needs a bit of special casing. Which in turn makes it an excellent second tier emulator

At any rate, that's just a few of the reasons for why I would recommend Bochs over qemu any day.

(and, sadly, there are people staying away from updating their OSes),

Mainly because every time I dist-upgrade ubuntu manages to break something fundamental. Last time it shat all over the kernel and refused to boot.

JamesM wrote:Mainly because every time I dist-upgrade ubuntu manages to break something fundamental. Last time it shat all over the kernel and refused to boot.

+1 here. On my way to 12.04 LTS it decided to go pass the wrong root= to the kernel.

JamesM wrote:

(and, sadly, there are people staying away from updating their OSes),

Mainly because every time I dist-upgrade ubuntu manages to break something fundamental. Last time it shat all over the kernel and refused to boot.

That's why I always do full re-install; with 20Mbps Internet connection redownloading everything is quite quick and painless, and compiling those few things (like kdevelop or bochs) doesn't take that long; sometimes, it is as easy as linking and installing everything, without recompilation, as I keep everything* on /home and don't have to really bother with it.

* as in: downloaded and compiled sources

Thanks guys! Bochs internal debugger it is .

Combuster wrote:qemu has a pretty epic history of stability issues, of which the notorious incompatibility with GCC4. There have been quite a few breaks with backwards-compatibility...

The dependency on gcc 3.x was fixed with 0.10, in early 2009. Are you sure that history really matters for a user today?

What kind of backwards compatibility do you mean?

...and while my gentoo already offers 1.1.1, 0.11 is still the "stable" default.

Ouch. I don't think this is a good idea of the Gentoo maintainers.

At any rate, that's just a few of the reasons for why I would recommend Bochs over qemu any day.

And I would do the opposite, because bochs is just too slow, and because I hate config files. Good that everyone has his own taste.

Thank you for this question - I also think, that you should prefer Bochs, even if you want to debug bootloader code. I've read many Internet Articles about Qemu+GDB bootloader debugging and it seems that Qemu have a problem in debugging bootloader-code from an raw image file. It seems that Qemu can only debug EFI-Files. Don't ask me if it is or not, i've not tested it. Please correct me, if there is an error.

So i have 2 questions about it :
- Is Qemu able to debug 16-Bit bootloader code ? I ask because i think that Qemu doesn't have an internal debugger like Bochs
- I start Bochs with debugger and always have to manually set a breakpoint to specific memory places, like 0x7C00. Is there an "automatically" way to say Bochs when it starts, that it has to set an breakpoint at 0x7C00? Maybe in some kind of script ?

Greetings,
bsc

That's really more a question about gdb than about qemu. As far as I know, debugging 16 bit code works fine per se, it's just that gdb gets confused with mode switches. So you need to make sure that you start debugging while you are already in the right processor mode if you want all gdb output to make sense. The qemu monitor itself doesn't have problems with mode switching, so you can always get correct register dumps, memory dumps and such.

So you need to make sure that you start debugging while you are already in the right processor mode if you want all gdb output to make sense

So GDB only have problems if you change your processor mode, for example switching 16-32Bit, switching Real-/Protected Mode, is this correct ?

The qemu monitor itself doesn't have problems with mode switching, so you can always get correct register dumps, memory dumps and such.

Only to make sure, that I understood you:
You need GDB for debugging in QEMU. Or is there another way for debugging/setting breakpoints in QEMU ?
(Sorry but I don't know much about QEMU )