OSDev.org

The Place to Start for Operating System Developers
It is currently Sat Jan 19, 2019 4:42 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 7 posts ] 
Author Message
 Post subject: Two problems
PostPosted: Thu Jan 03, 2019 4:02 pm 
Offline

Joined: Tue Jan 01, 2019 4:10 pm
Posts: 5
Location: Normandy, France
Hello,

I'm currently facing 2 problems:

- When calling global constructors.
Calling the _init function makes QEMU go back to the GRUB selection screen.

- When writing to 0xB8000
When I try to write text on the screen using the VGA text mode buffer, it seems like it doesn't work (I tried debugging with GDB. Before and after calling my function vga_clear, the value of the whole buffer is 0xFF for each byte instead of 0x00)

Here is my code: https://gitlab.com/Crumble14/crumbleos/tree/0985ab533507a06e1dbaf8c6620eadb5e37912d1

_________________
Student at School 42 Paris (US: https://www.42.us.org/; FR: https://42.fr/)


Top
 Profile  
 
 Post subject: Re: Two problems
PostPosted: Fri Jan 04, 2019 5:09 am 
Offline
Member
Member

Joined: Sun Oct 21, 2018 1:37 pm
Posts: 38
I would suggest trying BOCHS to debug while writing on VGA memory. What I usually do is:

I inline one magic breakpoint before the piece of code I want to debug in the c Kernel:

Code:
   asm(
      "xchg bx, bx;");


I make sure you include "magic_break: enabled=1" in your .bxrc file

I execute BOCHS and F5 to execute until the magic breakpoint.

From this point, I use CTRL + F7 (Physical dump) to show 0xB8000 (VGA map) and F2 for the Stack content, while I F11 for step-by-step debugging.

On the other side, I compile my kernel using -g parameter, to include debug information and I have the output of an objdump "-D -M Intel --source" on one side of the screen.

This way I have full information to follow what exactly the kernel is doing and it helps me figure out quickly what is wrong.

This is an example:
PS: Ignore the code and the comments on my screenshots, it is just garbage. It is just to show how I debug :-)

ORIGINAL CODE:

Image

OBJDUMP OF MACHINE CODE WITH INTERLEAVED C CODE:

Image

BOCHS STOPPED AT BREAKPOINT WITH VGA CONTENT:

Image

Hope it helps !


Top
 Profile  
 
 Post subject: Re: Two problems
PostPosted: Fri Jan 04, 2019 5:38 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 156
Crumble14 wrote:
Calling the _init function makes QEMU go back to the GRUB selection screen.

This sounds like a triple-fault. That means, you have a fault, but the exception handler cannot be accessed either, therefore a new fault raised, which in turn cannot be handled either. The default behaviour of x86 is to reset the CPU when 3 faults accour in a row (hence you end up in GRUB again). Try to run qemu with "-d int" to see what exception or fault occurs first.

Crumble14 wrote:
I tried debugging with GDB. Before and after calling my function vga_clear, the value of the whole buffer is 0xFF for each byte instead of 0x00)

That's definitely not the video RAM buffer. Reading 0xFF suggests you are reading from the wrong memory offset. You should read altering bytes, just like on mihe's screenshot, because text mode contains ASCII codes and attributes one after another. On the screenshot you can see 0x20 and 0x07 which means space character with white on black background. 0xFF as an attribute would mean blinking bright white on white, very very unlikely.

Cheers,
bzt


Top
 Profile  
 
 Post subject: Re: Two problems
PostPosted: Fri Jan 04, 2019 12:38 pm 
Offline

Joined: Tue Jan 01, 2019 4:10 pm
Posts: 5
Location: Normandy, France
bzt wrote:
This sounds like a triple-fault. That means, you have a fault, but the exception handler cannot be accessed either, therefore a new fault raised, which in turn cannot be handled either. The default behaviour of x86 is to reset the CPU when 3 faults accour in a row (hence you end up in GRUB again). Try to run qemu with "-d int" to see what exception or fault occurs first.


I tried running qemu with "-d int". It printed many things out, including:

Code:
check_exception old: 0xffffffff new 0xd
     0: v=0d e=6288 i=0 cpl=0 IP=0010:00100110 pc=00100110 SP=0018:00107048 env->regs[R_EAX]=36d76289


and

Code:
check_exception old: 0xd new 0xd
     1: v=08 e=0000 i=0 cpl=0 IP=0010:00100110 pc=00100110 SP=0018:00107048 env->regs[R_EAX]=36d76289


So I guess you are right. However I don't know how to read this x)

_________________
Student at School 42 Paris (US: https://www.42.us.org/; FR: https://42.fr/)


Top
 Profile  
 
 Post subject: Re: Two problems
PostPosted: Sat Jan 05, 2019 4:54 am 
Offline
Member
Member
User avatar

Joined: Thu Oct 13, 2016 4:55 pm
Posts: 156
Hi,

It seems you got an exception 0xd. Open up the intel manual and check which exception belongs to number 13. The next thing is, figure out which code was loaded at IP (0x100110), and find that in your source. There're several ways, one would be to disassemble instrutions (a few before and after the faulting address) and look for those mnemonics in your source. The point is, figure out which source line corresponds to address 0x100110. Once you know the instruction that's causing the fault, look it up in the intel manual, and read on which conditions it throws a general protection fault. That will give you a clue what your code is missing. Now that you know where the misbehaving instruction is located in you source, and why it's misbehaving, you can start to fix it.

If your code runs perfectly in bochs, then you can also compare the environment, look for register values that are different. This might give you the idea what you haven't set up properly (and initialized differently by bochs and qemu).

Cheers,
bzt


Top
 Profile  
 
 Post subject: Re: Two problems
PostPosted: Sat Jan 05, 2019 1:41 pm 
Online
Member
Member

Joined: Fri Aug 26, 2016 1:41 pm
Posts: 250
Remove the multiboot2 address_tag and see if your call to _init works. As for displaying characters.If you have requested a framebuffer GRUB is probably going to toss you into a graphics mode. You won't be able to write to 0xb8000 text video memory and have that updated on the display. In graphics mode you will have to render the characters yourself.


Top
 Profile  
 
 Post subject: Re: Two problems
PostPosted: Mon Jan 07, 2019 6:31 am 
Offline

Joined: Tue Jan 01, 2019 4:10 pm
Posts: 5
Location: Normandy, France
MichaelPetch wrote:
Remove the multiboot2 address_tag and see if your call to _init works. As for displaying characters.If you have requested a framebuffer GRUB is probably going to toss you into a graphics mode. You won't be able to write to 0xb8000 text video memory and have that updated on the display. In graphics mode you will have to render the characters yourself.


Okay, you just solved both my problems at once. Thanks everyone for helping me! :)

Just one last question: Why does removing the address_tag make the call to _init work ?

_________________
Student at School 42 Paris (US: https://www.42.us.org/; FR: https://42.fr/)


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

All times are UTC - 6 hours


Who is online

Users browsing this forum: BaconWraith, Bing [Bot], MichaelPetch and 5 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