OSDev.org

stlw wrote:

stlw wrote: That easy. Just few years of experience as x86 expert and CPU architect.

This is very impossible. It is really really hard to know all the behaviour of intel CPU. I guess, you have a in-circuit-emulator, during the development of bochs, when you are not sure how cpu behaviour, you just use your ICE to emulate it. Am I right? If you are american, you should able to get a high paid job in Intel.

No, I don't have in-circuit-emulator of Intel CPU, if I am not sure how things should behave usually I test it on real hardware.
And yes, I work for Intel already
There are not so many companies where I could do x86 or cpu architecture.

Too good

The gui just sending the debug command to bochs and capture the result. But very sadly it can't run in windows

But if you know to send commands - you probably could send Ctrl-C as well, no ?
SIGINT is the only way you could talk with running Bochs window ? I thought you could send keys into it as well.

In windows, when the bochs is running, whatever key i send to it, it don't pause

Yes, I will make it support x86-64. These feature i want to implement too
1) back trace (need to add some code to bochs's source)
2) c/c++ level single step trace (don't know how to make it)

What is back trace ?
Ability to "undo" every instruction or just ability to print X last instuctions occured ?
If second - probably I need to implement hardware CPU LBR feature (record last 16 branches occured in MSRs) and so you could read them in debugger and generate your backtrace offline.

Yes, the second. Record the register/GDT/whatever on every jmp/call/interrupt/task-switch is a great feature for operating system developer, especially for the os dev beginner.
Few years ago, my os will failure after running a whole night, I spent totally one month to trace this problem. This feature would save me.

And what is c/c++ level single step trace ? How do you know which ask instructions correspond to single c/c++ line ?
And what about software not written in C/C++ ?

Almost os developer write their os in c/c++, single step trace in assembly level may not too helpful. That's why we need this feature.

Some questions:
1) what debug command I get get DR0-DR7 ?

> dreg

2) In linux , when i type in "r" , it will show eax. But in windows, it will show rax. Also, the output format is different. In windows, one line show two registers, but in linux, one line per register.

This is not difference between linux and windows - this is difference between x86-64 enabled and disabled.
If x86-64 not compiled in Bochs looks slightly different as you could see ...

I see, thanks. What debugging command I can know x86-64 is compiled in bochs?

Just discovered tonight, the disassembly commands cannot disassemble from a physical address or virtual address

Stanislav

What is back trace ?
Ability to "undo" every instruction or just ability to print X last instuctions occured ?
If second - probably I need to implement hardware CPU LBR feature (record last 16 branches occured in MSRs) and so you could read them in debugger and generate your backtrace offline.

Yes, the second. Record the register/GDT/whatever on every jmp/call/interrupt/task-switch is a great feature for operating system developer, especially for the os dev beginner.
Few years ago, my os will failure after running a whole night, I spent totally one month to trace this problem. This feature would save me.

When you debug hardware you don't have more than LBR

What debugging command I can know x86-64 is compiled in bochs?

There is no such command. You could look into bochs log (x86-64 support: yes) or send smth like 'r' command and see format of the output.

Just discovered tonight, the disassembly commands cannot disassemble from a physical address or virtual address

Between virtual address and linear address there is no big difference. You could try disasm cs:eip and it will calculate linear address alone and call disasm linear function.
About disasm physical - it will require to supply "default" operand and address size in this case. Currently disasm takes current CPU operand and address size.
But in general - it is nice feature, you are welcome to add it.

About rest of the stuff you add - I added range watchpoints to CVS now so no need for your addm command anymore. Your gdt command is also redundant.
And I am waiting for your new patch!
But do not try to combine too many stuff into one patch. The bigger patch is - the less chance you have to merge it.

Stanislav

thanks
i am working on the "address lookup" function for the bochs gui. If you enter a virutal address, it will tell you the linear address , page dir no., pt no., the final physical address. It make the debug easier, please take a look the bottom of the image.

I want to implement a "reverse lookup" too, that mean if you enter a physical address, it will show you which virutal address of which task will point to that address. When I wrote OS, sometime I don't know why the bytes are changed by accident, this function will help people to find it out. But I need to lookup all the descriptor in all tasks pointed by register TR. It need sometime to work it out.



thanks
from Peter