Page 2 of 2
Re: Unexpected behaviour
Posted: Thu Jun 21, 2012 6:46 am
by qw
Combuster, Already covered in my first reply.
Iansjack, My remark was meant for perfectionists who like to squeeze every millibyte out of his computer. I am one of those every now and then.
Re: Unexpected behaviour
Posted: Thu Jun 21, 2012 7:08 am
by iansjack
Real perfectionists write everything in pure assembler. None of this namby-pamby C with inline assembler.
Re: Unexpected behaviour
Posted: Thu Jun 21, 2012 7:09 am
by nop
Hobbes wrote:nop wrote:This is exactly my first implementation (if I'm not wrong it's also in the asm inline example of the wiki), the code I posted in the opening of the thread was a (wrong) variant - I was exploring the problem looking for a solution: the "=A" was because I wanted to make sure to use a 64 bits register.
"=A" does not mean RAX but RDX:RAX (or EDX:EAX in 32-bits code). If you want to force the use of RAX, use "=a" instead of "=r". However, for optimization, you'd better leave the decision what register is used to the compiler.
oops you're right, my bad. Silly mistake.
I confirm I'm using "in production" the first variant I coded, as I told in my previous message, which leaves to the compiler the choice of the register to use (R12) as suggested also by Combuster
What I'm saying here is that, looking at the code with the Bochs internal debugger, this single line
translated into
fills the high half of R12 with a nice sequence of "1"
I'm definitely missing something.
At this point I'll make a function on its own as suggested by iansjack
Re: Unexpected behaviour
Posted: Thu Jun 21, 2012 7:55 am
by Combuster
looking at the code with the Bochs internal debugger
Bochs doesn't do ATT syntax, so I can't trust you to tell us what you actually see.
Re: Unexpected behaviour
Posted: Thu Jun 21, 2012 5:11 pm
by nop
Combuster wrote:looking at the code with the Bochs internal debugger
Bochs doesn't do ATT syntax, so I can't trust you to tell us what you actually see.
You are perfectly right, this the code generated
Code: Select all
#APP
# 151 "../../inc/asm/asm.h" 1
xchg %bx, %bx
# 0 "" 2
# 193 "../../inc/asm/asm.h" 1
nop
movq %cr2,%rbx
nop
# 0 "" 2
#NO_APP
movq %rbx, %r12
movq %rbx, %rsi
xorl %eax, %eax
shrq $39, %r12
movabsq $printk, %rbp
movq %rcx, 16(%rsp)
andl $511, %r12d
movl %r9d, 8(%rsp)
movabsq $.LC19, %rdi
call *%rbp
by
Code: Select all
static inline u64_t get_cr2()
{
u64_t val = 0;
bochs_bp(); // Bochs magic breakpoint
__asm__ __volatile__(
"nop\n\t"
"movq %%cr2,%0\n\t"
"nop\n\t"
:"=r"(val));
return val;
}
The asm snippet is big enough to show also the code which evaluates the PML4 offset of the linear address (a macro not shown here) .
CR2 is 0xc00100ed
- cr2 value on breakpoint
, RBX receives the value 0xffffffffc00100ed
- rbx after the assigment
and the offset is 511 instead of 0
As I've already said, I think I'm missing something big
Thanks for all the support!!!
Re: Unexpected behaviour
Posted: Thu Jun 21, 2012 9:44 pm
by jbemmel
You say that CR2 is 0xc00100ed, but the Bochs debugger GUI only shows 32 bits. Since you get 0xfffff..., it would seem that CR2 upper 32 bits are not 0.
Did you try the debug console? using "creg" it will show you the full 64-bit CR2
Re: Unexpected behaviour
Posted: Fri Jun 22, 2012 12:23 am
by iansjack
I'd have to agree with that. The debugger that you are using is not very useful as it is not showing 64-bit registers. Try running under gdb in qemu or, my favourite, SimNow. Either of those will show the full 64 bits. If a simple move from %cr2 is showing that result then that indeed is what is in the register. (Either that or Bochs is broken. I don't use Bochs so I can't comment on that.)
Re: Unexpected behaviour
Posted: Fri Jun 22, 2012 4:04 am
by iansjack
Just one more small remark. How are you sure what the faulting address is? From what you have said to me it looks more and more likely that you are getting the correct value for %cr2 but are making a false assumption about what it should be. Have you tried single-stepping the code immediately prior to the fault?
when you have eliminated the impossible, whatever remains, however improbable, must be the truth
Re: Unexpected behaviour
Posted: Fri Jun 22, 2012 5:30 am
by nop
jbemmel wrote:Did you try the debug console? using "creg" it will show you the full 64-bit CR2
We have a winner!!!
Sadly enough, Bochs hid the high half of the cr2 address
I would have never imagined such behaviour (where's the point of having the system in long mode and showing CRs 32 bits????)
I think my Bochs days are over (I'll try SimNow, thanks iansjack)
I didn't spot this before because the page fault happens after a RET (I have a stack corruption) and the code I have single-stepped of my previous posts runs happily at the standard address in the 0xc001xxxx range; or, at least, it
seems to be at that address.
Now I have to find what causes the stack corruption, but this might be the topic of another post :p
Thanks again
Re: Unexpected behaviour
Posted: Fri Jun 22, 2012 6:08 am
by nop
berkus wrote:Your screenshots show you weren't using bochs.
Can you be more specific, please? I cannot check now how I compiled bochs, but I'm pretty sure to have enabled the debugger GUI with --enable-debugger-gui (as suggested in the wiki) and it's built on top of the internal debugger.
I also use Qemu but I don't have the gdb stub enabled - I always use Bochs to single step code...
Re: Unexpected behaviour
Posted: Fri Jun 22, 2012 7:29 am
by Griwes
berkus wrote:nop wrote:Sadly enough, Bochs hid the high half of the cr2 address
I would have never imagined such behaviour (where's the point of having the system in long mode and showing CRs 32 bits????)
Your screenshots show you weren't using bochs.
His only two screenshots actually prove that he is using bochs...
Re: Unexpected behaviour
Posted: Sat Jun 23, 2012 5:33 am
by Griwes
berkus wrote:Griwes wrote:His only two screenshots actually prove that he is using bochs...
He is using bochs
GUI which is not bochs as far as I'm concerned.
It's just GUI front-end for bochs debugger - how would he use it without using bochs?
Re: Unexpected behaviour
Posted: Sat Jun 23, 2012 7:08 am
by Combuster
I've looked at the register dump, and noticed that there are several other registers set to the value around 0x(FFFFFFFF)C00xxxxx, and that is before storing CR2 somewhere. So I suspect you are hunting a ghost and the pagefault in question actually took place at the address you see.
Are you sure you're not truncating addresses to an 32-bit int, either in the sourcecode or by virtue of the memory model?
Re: Unexpected behaviour
Posted: Sat Jun 23, 2012 11:43 am
by iansjack
It certainly looks like more than coincidence that %rsi is set to the exact value that the page fault is reporting. Unfortunately, we haven't seen the code that caused the fault.
Re: Unexpected behaviour
Posted: Sat Jun 23, 2012 11:54 am
by nop
Combuster wrote:I've looked at the register dump, and noticed that there are several other registers set to the value around 0x(FFFFFFFF)C00xxxxx, and that is before storing CR2 somewhere. So I suspect you are hunting a ghost and the pagefault in question actually took place at the address you see.
Are you sure you're not truncating addresses to an 32-bit int, either in the sourcecode or by virtue of the memory model?
Yes, the fault took place at the address reported, and the Bochs internal debugger GUI hid the full 64 bit address as I wrote a few posts ago; I also added that was caused by a stack corruption, which luckily I got fixed today
Again, thanks again for all the precious advice!
EDIT: I apologize for not having marked the post "solved" sooner