OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Jun 13, 2024 4:42 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: Qemu: confusing behavior?
PostPosted: Tue May 21, 2024 8:48 am 
Offline
Member
Member

Joined: Sun Jun 23, 2019 5:36 pm
Posts: 624
Location: North Dakota, United States
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
image.png [ 78.74 KiB | Viewed 1297 times ]
Top
 Profile  
 
 Post subject: Re: Qemu: confusing behavior?
PostPosted: Tue May 21, 2024 10:19 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4602
Location: Chichester, UK
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?


Top
 Profile  
 
 Post subject: Re: Qemu: confusing behavior?
PostPosted: Tue May 21, 2024 11:03 am 
Offline
Member
Member

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


Top
 Profile  
 
 Post subject: Re: Qemu: confusing behavior?
PostPosted: Tue May 21, 2024 11:35 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5215
Even if it did redirect the VGA buffer, that would only work for VGA text modes, not the bitmap framebuffer you're using.


Top
 Profile  
 
 Post subject: Re: Qemu: confusing behavior?
PostPosted: Tue May 21, 2024 12:35 pm 
Offline
Member
Member

Joined: Sun Jun 23, 2019 5:36 pm
Posts: 624
Location: North Dakota, United States
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.)


Top
 Profile  
 
 Post subject: Re: Qemu: confusing behavior?
PostPosted: Tue May 21, 2024 2:11 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5215
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.


Top
 Profile  
 
 Post subject: Re: Qemu: confusing behavior?
PostPosted: Tue May 21, 2024 7:19 pm 
Offline
Member
Member

Joined: Sun Jun 23, 2019 5:36 pm
Posts: 624
Location: North Dakota, United States
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. :)


Top
 Profile  
 
 Post subject: Re: Qemu: confusing behavior?
PostPosted: Tue May 21, 2024 9:52 pm 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5215
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:
uint32_t *canvas_line = ctx->canvas ? ctx->canvas + x + (y + gy) * ctx->width : NULL;


Top
 Profile  
 
 Post subject: Re: Qemu: confusing behavior?
PostPosted: Wed May 22, 2024 6:07 pm 
Offline
Member
Member

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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 41 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group