Page 1 of 1

Real undefined behavior - bochs

Posted: Fri Nov 11, 2022 2:52 pm
by Cyao
Hello everyone! I've been trying to get a 64 bit idt made, but somehow in the process I broke litteraly everything

Now the only thing my os does (in bochs) is switch to 32 bit mode and crash, I managed to track it down to here using the bochs's debugger

Code: Select all

Next at t=35427029
(0) [0x000000007cfa] 0008:0000000000007cfa (unk. ctxt): wrmsr                     ; 0f30
<bochs:26> 
Next at t=35427030
(0) [0x000000007cfc] 0008:0000000000007cfc (unk. ctxt): mov eax, cr0              ; 0f20c0
<bochs:27> 
Next at t=35427031
(0) [0x000000007cff] 0008:0000000000007cff (unk. ctxt): or eax, 0x0b8000bf        ; 0dbf00800b
<bochs:28> 
Next at t=35427032
(0) [0x000000007d04] 0008:0000000000007d04 (unk. ctxt): add byte ptr ds:[eax-72], cl ; 0048b8
<bochs:29> 
Next at t=35427033
(0) [0x000000007d07] 0008:0000000000007d07 (unk. ctxt): and byte ptr ds:[edi], cl ; 200f
<bochs:30> 
You can see that the instruction is now add byte ptr ds:[eax-72], cl ; 0048b8 (after this its just gets garbage instructions from nowhere and manage to cause a tripple fault) after the bitwise or , but my code is like this

Code: Select all

    mov eax, cr0                 ; Set the A-register to control register 0.
    or eax, 1 << 31              ; Set the PG-bit, which is the 32nd bit (bit 31).
    mov cr0, eax                 ; Set control register 0 to the A-register.

    jmp $
and I've also tried to run it on qemu and everything is fine. Does anyone know what is wrong with bochs? my bochsrc.txt is like this https://github.com/cheyao/AsmOS/blob/b1 ... /bochs.txt

Re: Real undefined behavior - bochs

Posted: Fri Nov 11, 2022 2:55 pm
by Cyao
Ahh Oh god it was me mispelling a number again, thought the bootsect's size was 0x100

And now I am back to fixing my idt, I have this error:

Code: Select all

LIDT64_Ms: loaded base64 address is not in canonical form!
00035427891e[CPU0  ] interrupt(long mode): IDT entry extended attributes DWORD4 TYPE != 0
00035427891e[CPU0  ] interrupt(long mode): IDT entry extended attributes DWORD4 TYPE != 0
00035427891i[CPU0  ] CPU is in long mode (active)
Anyone knows what does base64 address is not in canonical form mean?

thanks!

Re: Real undefined behavior - bochs

Posted: Fri Nov 11, 2022 5:59 pm
by kzinti
Look for "Canonical form addresses" here: https://en.wikipedia.org/wiki/X86-64
(...), the AMD specification requires that the most significant 16 bits of any virtual address, bits 48 through 63, must be copies of bit 47 (in a manner akin to sign extension). If this requirement is not met, the processor will raise an exception.[11]: 131  Addresses complying with this rule are referred to as "canonical form."[11]: 130  Canonical form addresses run from 0 through 00007FFF'FFFFFFFF, and from FFFF8000'00000000 through FFFFFFFF'FFFFFFFF, for a total of 256 TB of usable virtual address space.

Re: Real undefined behavior - bochs

Posted: Sat Nov 12, 2022 1:06 am
by Cyao
kzinti wrote:Look for "Canonical form addresses" here: https://en.wikipedia.org/wiki/X86-64
Hmm then how can I produce the coninical adress in c?

Re: Real undefined behavior - bochs

Posted: Sat Nov 12, 2022 1:32 am
by kzinti
You don't make a canonical address in C, you just use canonical addresses for virtual addresses when building your page tables.

You haven't show us the part where you use the LIDT instruction, so there is little to go with here.

But from what you posted it looks like:

1) Your IDT is not at a canonical address. Where did you put it (virtual address)?
2) Your IDT has invalid descriptor(s) (the 4 dword of each descriptor is reserved and should be zero, as per the error message).

Re: Real undefined behavior - bochs

Posted: Sat Nov 12, 2022 1:40 am
by Cyao
https://github.com/cheyao/AsmOS/blob/b1 ... /idt.c#L27

It's just here, the code is loaded into 0x7E00, should have nothing special with it, really wierd

Re: Real undefined behavior - bochs

Posted: Sat Nov 12, 2022 1:47 am
by kzinti
Line 26: Your IDT should have 256 entries, not 255.
Line 47: I see "u64int" instead of "uint64_t", how does that even compile?
Line 48: Your limit is wrong, it should be the size of the IDT minus 1, so 256 * 16 - 1, or sizeof(idt_entry_t) - 1

The rest looks good, but there might be other issues.

If your code and data is around 0x7E00, Bochs shouldn't complain about an invalid address. Are you able to print the address of your IDT (i.e. &idt_entry_t[0]) so we can see what it is?

Re: Real undefined behavior - bochs

Posted: Sat Nov 12, 2022 1:58 am
by Cyao
kzinti wrote:Line 26: Your IDT should have 256 entries, not 255.
The array dosen't start at 0? So idt[255] = 256 entries
kzinti wrote: Line 47: I see "u64int" instead of "uint64_t", how does that even compile?
This is just me being a bit lazy, I prefer u64int, but all wiki code is uint64_t, so I declared them both
kzinti wrote: Line 48: Your limit is wrong, it should be the size of the IDT minus 1, so 256 * 16 - 1, or sizeof(idt_entry_t) - 1 - which incidently is not a type, so lose the _t suffix?
I think this should not be the problem, less entries = less error possibility, so im just trying to make 2 gates
kzinti wrote: If your code and data is around 0x7E00, Bochs shouldn't complain about an invalid address. Are you able to print the address of your IDT (i.e. &idt_entry_t[0]) so we can see what it is?
Ye just wait a min ima implement a itoa

Re: Real undefined behavior - bochs

Posted: Sat Nov 12, 2022 2:03 am
by kzinti
cyao1234 wrote: The array dosen't start at 0? So idt[255] = 256 entries
idt[255] is 255 entries, with indices from 0 to 254.

Re: Real undefined behavior - bochs

Posted: Sat Nov 12, 2022 2:16 am
by kzinti
Since you are using Bochs, you can just set a breakpoint and see what value is loaded into the IDT. See "Magic Breakpoint" here: https://wiki.osdev.org/Bochs

Re: Real undefined behavior - bochs

Posted: Sat Nov 12, 2022 2:22 am
by Cyao
The idt_entry_t is in 0x7ffd7 (using bochs) looks a bit high to me, very wierd

And now bochs still shows the error
00035427891e[CPU0 ] LIDT64_Ms: loaded base64 address is not in canonical form!
00035427043e[CPU0 ] interrupt(long mode): IDT entry extended attributes DWORD4 TYPE != 0
00035427043e[CPU0 ] interrupt(long mode): IDT entry extended attributes DWORD4 TYPE != 0

Re: Real undefined behavior - bochs

Posted: Sat Nov 12, 2022 5:27 am
by kzinti
You flush_idt function is wrong: https://github.com/cheyao/AsmOS/blob/b1 ... tr.asm#L59

1) You are using %eax, which is a 32 bits register.
2) In 64 bits mode, the first parameter is in register %rdi (and not on the stack). This is assuming you are using the System V calling convention. If you use the Microsoft one, the parameter will be in %rax.

Re: Real undefined behavior - bochs

Posted: Sat Nov 12, 2022 5:56 am
by Cyao
kzinti wrote:You flush_idt function is wrong: https://github.com/cheyao/AsmOS/blob/b1 ... tr.asm#L59

1) You are using %eax, which is a 32 bits register.
2) In 64 bits mode, the first parameter is in register %rdi (and not on the stack). This is assuming you are using the System V calling convention. If you use the Microsoft one, the parameter will be in %rax.
Ahh thanks a lot! It fixed my problem!