OSDev.org

Korona wrote:GDB usually misbehaves if you are using x86_64-system-qemu in 32-bit mode. In 64-bit mode it works fine again.

That's a well-known problem: https://bugs.launchpad.net/qemu/+bug/1686170
Unfortunately, the QEMU guys don't wanna fix it. Therefore, for 32-bit code we have to use i386-system-qemu and for 64-bit code we must use x86_64-system-qemu, if we want to debug our code using QEMU's gdb server.

vvaltchev wrote: That's a well-known problem: https://bugs.launchpad.net/qemu/+bug/1686170
Unfortunately, the QEMU guys don't wanna fix it. Therefore, for 32-bit code we have to use i386-system-qemu and for 64-bit code we must use x86_64-system-qemu, if we want to debug our code using QEMU's gdb server.

Unfortunately, that's what I did. I use Gentoo and I specifically compiled the i386 qemu version since I've been playing around with the x86 kernel. I wonder if the problem is with GDB, since my Gentoo is not multilib (perhaps GDB expects x86_64 when QEMU is giving i386). However, I don't want to hijack the posters original post. The main thing is that for a beginner, getting exception handlers to work and also using print statements can go a pretty long way.

I'm currently testing my new disc buffering algorithm (read-mode only).

I'm not running the test on emulators (for obvious reasons), rather use XHCI hardware and a USB stick. I test it on an 8-core AMD machine but I can disable multicore to make sure it runs on single-core machines too. I also have a USB analyzer so I can see that reasonable request sizes are used against the USB stick.

To verify that I read out the correct data I prepared the USB stick by writing unique data to every sector I access in the test. The data is composed of a biased sector value at offset 16 and a fixed 0x55 pattern between position 20 and 511. I calculate an MD5 sum for positions 16 to 511 and put that between positions 0 and 15. When I read out a particular sector I will first calculate MD5 for offsets 16 to 511 and check against the stored MD5 between offset 0 and 15. If this matches, I check the sector I read out with the biased sector value to make sure it's the correct sector. I log every mismatch during the tests.

The partition server process will create 10 threads. Each thread will calculate a random start sector (between 400 000 and 1 000 000) and a random number of sectors (1 to 128). After the sectors have been read each of them is verified for correctness, and then the thread will do a random delay between 0 and 30 ms before it repeats the process.

When this test is run the buffers will be randomly filled until all sectors are cached, at which point no more disc requests are done.

To increase complexity of the test I add a maximum size of the cache. I can set it to any value, but in the test I set the limit to about 45% of sectors I read out. The thread that frees cached sectors will use the second-chance algorithm. When a sector is referenced, it will set a bit. When the free process checks a cached sector, it will first check so it is not locked, and then it will check the reference bit, and if it is set it will clear it, otherwise it will free the entry. With this in place, the test will continue to heavily load the USB stick and try to cache new sectors.

I will run this test over the weekend and hope everything still runs on Monday.

The test ran successfully. It also run half-a-day with EHCI & an USB hub.

The next test stage is to do a similar test on a couple of files in the filesystem once I get to this point.

My goal is to modify BOCHS and QEMU so that they take a few extra command line options - after a certain amount of time, dump the registers and section of memory.

Then have code that runs outside the VM to verify specific register and memory states.

But fursti, working on the much more interesting problem of making a relocatable kernel ... almost there!

Using something like the expect tool to automate GDB commands and inspect IO values, memory and registers seems an interesting idea. Here's a skeleton ChatGPT suggested when I queried how to unit test the outb command:
Does anyone know of a kernel where this approach has been taken, comprehensively, and ideally within some kind of automated CI setup?

I'd be interested to hear any views on this, pro or cons.