I'm trying to compile this code under linux with gcc compiler :
static inline unsigned long get_current(void)
{
unsigned long current;
asm volatile (
" movl %%esp, %%eax;"
" andl %1, %%eax;"
" movl (%%eax), %0;"
: "=r" (current)
: "i" (0xfffff000)
);
return current;
}
But i'm getting this error :
program.c: Assembler messages: program.c:455: Error: incorrect
register `%rbx' used with `l' suffix
what is wrong here ?
Obviously, you're compiling for 64 bits. Try using gcc -m32 if it's not what you want, or use 64-bit registers (%esp makes no sense at all on x64).
Whilst the above is sort of correct, I expect it's actually NOT the right solution. If you have 64-bit OS, you should use 64-bit operations for "get current".
asm volatile (
" movq %1, %%rax
" andq %%rsp, %%rax;" // We only care about lower bits.
" movq (%%rax), %0;"
: "=r" (current)
: "i" (0xfffffffffffff000)
: "rax" // Remember to mark any temporary registers modified in "clobber"
);
I rearranged the instructions, as you can't use 64-bit immediates with most instructions.
I would code this like:
static inline unsigned long get_current(void)
{
unsigned register long current asm("sp");
asm volatile ("" : "=r"(current));
return (current & ~ (unsigned long)0xfff);
}
This compiles both on 64bit and 32bit; creates the following code:
Disassembly of section .text:
0000000000000000 <get_current>:
0: 48 89 e0 mov %rsp,%rax
3: 48 25 00 f0 ff ff and $0xfffffffffffff000,%rax
9: c3 retq
respectively, for 32bit:
Disassembly of section .text:
00000000 <get_current>:
0: 89 e0 mov %esp,%eax
2: 25 00 f0 ff ff and $0xfffff000,%eax
7: c3 ret
One of the nifty things of gcc's inline assembler is the ability to bind variables to registers, and yes, as shown, it recognizes sp
on x86.
Edit: oops ... just noticed gcc 3.4.5 creates funny code for the above - even at high optimization levels, where it normally eliminates the frame pointer on its own, the above source will make create a framepointer (for a non-static instantiation of the function). Explicit compile with -fomit-frame-pointer
on gcc 3.4.5 or the use of gcc 4.x creates the correct code now shown (see posting history for what gcc 3.4.5 does).