OSDev.org

iansjack wrote:

WindowsNT wrote:

iansjack wrote:I'm still interested to know how you are testing that you are in long mode.

The code later switches back to protected, and finally to real mode and exits.
In both bochs and vmware it does that. When I issue the interrupt, bochs works, vmware crashes.

If you consider that an answer to the question I think it's time I gave up asking.

Well, what is wrong with that. It sets flags from within long mode that are verified later from real mode.

I'm afraid that's just waffle that tells us absolutely nothing. You have given us very little information (e.g. details of your page table might help) and I find a lot of your code suspect. For example, you zero registers and then immediately load a value into them. What's the point of that?

Anyway, you are convinced that you are reaching long mode and, as you know far more about your code than you have told us, I'll believe you. I don't really think the purpose of this site is to review code for standard cases, so I'll leave you to it. What I would suggest is that you run the code under a debugger and inspect memory and registers whilst single-stepping through critical sections. Also, inspect your GDT, IDT, and page table carefully to ensure they contain the correct values. It should then be fairly easy to pinpoint your error.

I do not disagree, in fact I suspected the page table from the beginning. But, as I said, in bochs it works without trouble.

Do I have another choice to debug it?

VirtualBox has a built in debugger which is sufficient for your purposes: http://www.virtualbox.org/manual/ch12.html#ts_debugger

You can also use gdb with VirtualBox, although it is a little more involved to set it up. Sometimes you can't beat single-stepping through code when you are unsure what is happening. You may be surprised by the results. At the very least this will give you the ability to inspect the page table just before the point of interest. It is amazing how often you discover that (for instance) you have failed to mark a page as present or some similar trivial error. This sort of thing is immediately obvious when you actually inspect the table in RAM.

There is no real substitute for learning how to debug. There are a lot of techniques that you can use - simple printing of the values of variables, or even just a marker to say "I reached this point" can often be enough. But when you haven't got to the stage of being able to print you can't beat using a debugger. And the quicker you learn how to use it effectively the better; the effort will be repaid many times over.

I prefer Bochs for debugging, as it seems a bit easier to use than VirtualBox debugging. But once you get the VirtualBox debugger working, they are pretty similar.

In Bochs, you can enable something called a "Magic Breakpoint", where you simply add a MOV bx, bx to your code, and Bochs will break into the debugger whenever this instruction is encountered. Or, you can just add a JMP $ to do an infinite loop, and then stop the debugger whenever you feel like it, and set the RIP register to the next instruction address.

SpyderTL wrote:a "Magic Breakpoint", where you simply add a MOV bx, bx to your code

it's xchg bx, bx

I also prefer bochs for debugging. Besides, I created the GUI for it, remember?

My favourite environment for debugging startup assembler code is SimNow. But when the bug only appears in VmWare and VirtualBox it doesn't seem productive to suggest Bochs or SimNow as a debugger.

Is there a function to stop the app and show the debugger in VirtualBox?
Like xchg bx,bx in bochs or the bochs feature "break when mode change"

M.

You can always use the technique that SpyperTL mentioned:

Or, you can just add a JMP $ to do an infinite loop, and then stop the debugger whenever you feel like it, and set the RIP register to the next instruction address.

I just tried that but I find the debugger interface a bit flawed.... I stopped it at jmp $ and it does not seem to change the eip with rg eip =. I will try it more though.

Not only eip cannot be changed, but once I try the trace command the entire vm gets stuck.

Yes. It looks as if "rg" only displays the register. But you can stop the machine at a pertinent point and then inspect structures such as the page table. Else, you'll have to use gdb.

BTW, a common reason for a program to work in some emulators but not others is because it makes unwarranted assumptions about the state of the machine. One such assumption is that memory is zeroed.

I was able to isolate the problem to something not related to long mode: the apic. In virtualbox I do not seem to be able to parse the acpi tables correctly.

Once I disabled it and tried to enter long mode from the main cpu (i was trying to enter from the second cpu), both long mode and the interrupt work.

Therefore, it must be a state assumption you mentioned correctly that works in bochs but not in vmware.

Combuster wrote:

SpyderTL wrote:a "Magic Breakpoint", where you simply add a MOV bx, bx to your code

it's xchg bx, bx

That's what I said. xchg bx, bx.

iansjack wrote:My favourite environment for debugging startup assembler code is SimNow. But when the bug only appears in VmWare and VirtualBox it doesn't seem productive to suggest Bochs or SimNow as a debugger.

I really like SimNOW as well. I think it's probably the most "accurate" whole virtual machine, but i think bochs is easier/quicker for finding bugs.

WindowsNT wrote:Is there a function to stop the app and show the debugger in VirtualBox?
Like xchg bx,bx in bochs or the bochs feature "break when mode change"

M.

I don't think so, but I just got VirtualBox debugging working a few days ago.