[SOLVED] Unexpected behaviour

[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.

[iansjack]

Real perfectionists write everything in pure assembler. None of this namby-pamby C with inline assembler.

[nop]

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

Code: Select all

"movq %%cr2,%0\n\t"

translated into

Code: Select all

movq %cr2, %r12

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

[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.

[nop]

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!!!

[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

[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.)

[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

[nop]

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

[nop]

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...

[Griwes]

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...

[Griwes]

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?

[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?

[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.

[nop]

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