Qemu: confusing behavior?

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
Ethin
Member
Member
Posts: 625
Joined: Sun Jun 23, 2019 5:36 pm
Location: North Dakota, United States

Qemu: confusing behavior?

Post by 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.
Attachments
image.png
User avatar
iansjack
Member
Member
Posts: 4683
Joined: Sat Mar 31, 2012 3:07 am
Location: Chichester, UK

Re: Qemu: confusing behavior?

Post by 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
Member
Member
Posts: 625
Joined: Sun Jun 23, 2019 5:36 pm
Location: North Dakota, United States

Re: Qemu: confusing behavior?

Post by 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
Member
Member
Posts: 5487
Joined: Mon Mar 25, 2013 7:01 pm

Re: Qemu: confusing behavior?

Post by 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
Member
Member
Posts: 625
Joined: Sun Jun 23, 2019 5:36 pm
Location: North Dakota, United States

Re: Qemu: confusing behavior?

Post by Ethin »

Octocontrabass wrote: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
Member
Member
Posts: 5487
Joined: Mon Mar 25, 2013 7:01 pm

Re: Qemu: confusing behavior?

Post by Octocontrabass »

Ethin wrote: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
Member
Member
Posts: 625
Joined: Sun Jun 23, 2019 5:36 pm
Location: North Dakota, United States

Re: Qemu: confusing behavior?

Post by Ethin »

Octocontrabass wrote:
Ethin wrote: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
Member
Member
Posts: 5487
Joined: Mon Mar 25, 2013 7:01 pm

Re: Qemu: confusing behavior?

Post by 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
Member
Member
Posts: 625
Joined: Sun Jun 23, 2019 5:36 pm
Location: North Dakota, United States

Re: Qemu: confusing behavior?

Post by Ethin »

Octocontrabass wrote: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.
Post Reply