Qemu: confusing behavior?

[Ethin]

I'm a bit confused by this. For some (very strange) reason, the framebuffer code I'm using causes the text to appear when I use the qemu graphical display, but if I use `-nographic` nothing shows up other than the firmware boot messages and such. It also shows up weirdly -- I've attached a screenshot. I don't clear the FB so maybe I should do that. For reference the implementation I'm using is flanterm. Is this just Qemu being weird, or is Qemu changing the console to use the serial port and not the framebuffer when I pass -nographic?

Edit: for reference, I'm using Qemu 7.2.9 (Debian 1:7.2+dfsg-7+deb12u5) from WSL. But the same behavior occurs on Qemu 9.0.0 (which is the latest version) as well.

[iansjack]

I think you may be confused as to what the -no graphic switch does. It switches off the guest display, redirecting the emulated serial port to the console.

Have you read the qemu manual?

[Ethin]

I thought I knew what it does -- I've used it to run Linux and the BSDs -- but since they just worked and I didn't need to actually use `-serial stdio` I believed it redirected the VGA buffer. But apparently it works more like `-serial stdio` than I thought.

[Octocontrabass]

Even if it did redirect the VGA buffer, that would only work for VGA text modes, not the bitmap framebuffer you're using.

[Ethin]

Even if it did redirect the VGA buffer, that would only work for VGA text modes, not the bitmap framebuffer you're using.

Good to know. Guess I do need to write that serial port implementation after all. At least I can know that the text I send to the port also goes to the display... Thank you guys. (Are the visual artifacts ChatGPT tells me are there caused because I don't zero the FB, or are they due to something else? I thought Flanterm cleared the display but I don't mind memsetting the buffer to zeros in case.)

[Octocontrabass]

Are the visual artifacts ChatGPT tells me are there caused because I don't zero the FB, or are they due to something else? I thought Flanterm cleared the display but I don't mind memsetting the buffer to zeros in case.

It looks like flanterm filled the screen with the default symbol it uses for displaying unsupported characters, then displayed your "info: hello" text near the middle of the screen. If it's not the result of something you're intentionally trying to display, I'd guess it's some kind of memory corruption bug.

[Ethin]

Are the visual artifacts ChatGPT tells me are there caused because I don't zero the FB, or are they due to something else? I thought Flanterm cleared the display but I don't mind memsetting the buffer to zeros in case.

It looks like flanterm filled the screen with the default symbol it uses for displaying unsupported characters, then displayed your "info: hello" text near the middle of the screen. If it's not the result of something you're intentionally trying to display, I'd guess it's some kind of memory corruption bug.

Huh, will have to investigate.... It does look like it does have UB (it triggered the UB sanitizer so I had to turn that off for now for the Flanterm sources in question). Not really sure how to fix that... Thank you anyway for the help, glad to know that this is actually working, glad to be back in OSDev land again.

[Octocontrabass]

Since you've already identified that it's undefined behavior from pointer arithmetic on a null pointer, the easiest fix would be to wrap it in a ternary operator to ensure the pointer is not null before performing any arithmetic. Maybe like this:

Code: Select all

uint32_t *canvas_line = ctx->canvas ? ctx->canvas + x + (y + gy) * ctx->width : NULL;

[Ethin]

Since you've already identified that it's undefined behavior from pointer arithmetic on a null pointer, the easiest fix would be to wrap it in a ternary operator to ensure the pointer is not null before performing any arithmetic. Maybe like this:

Code: Select all

uint32_t *canvas_line = ctx->canvas ? ctx->canvas + x + (y + gy) * ctx->width : NULL;

Yeah, I might do that, though if I did add that I'd then need to add yet another NULL check against canvas_line (I think, don't have the code open right now, restoring from backup right now, and god is it slow!). I'd like to not maintain my own fork of the code if possible but if it doesn't get fixed I'll just have to.