incorrect register '%rbx' used with 'l

2020-03-24 07:22发布

问题:

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 ?

回答1:

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



回答2:

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.



回答3:

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