CODEWITHSUNDEEP
gccassemblyattosdev
Per Lundberg
Per Lundberg

Reputation: 4221

gcc compilation error with inline assembly: operand type mismatch for ljmp

For whatever reason, the following inline assembly (AT&T/gcc style) does not work on a newly installed Debian GNU/Linux 64-bit machine; it compiles and works correctly on other machines:

static void INIT_CODE kernel_entry (void) NORETURN;

void _start(void)
{
    // ...other code here...

    asm ("ljmp   %0, %1"
         :
         : "n" (SELECTOR_KERNEL_CODE),
         "p" (&kernel_entry));
}

static void INIT_CODE kernel_entry(void)
{
    // ...
}

The compile error I get is this, with both gcc 7 and 8:

$ gcc-7 -o init.o -Wall -Wextra -Wshadow -Wpointer-arith -Waggregate-return \
    -Wredundant-decls -Winline -Werror -Wcast-align -Wsign-compare -Wmissing-declarations \
    -Wmissing-noreturn -pipe -O0 -fno-builtin -fno-asynchronous-unwind-tables \
    -funsigned-char   -g -fomit-frame-pointer -ffreestanding   -DPACKAGE_NAME=\"storm\" \
    -DPACKAGE_VERSION=\"0.5.1+\" \
    -DREVISION=\"`git rev-list HEAD --max-count 1 --abbrev-commit`\" \
    -DCREATOR=\"`whoami`@`hostname -s`\" --std=gnu99 -Wbad-function-cast \
    -Wmissing-prototypes -Wnested-externs   -Wstrict-prototypes -m32 -I../include \
    -I.. -I. -c init.c 
init.c: Assembler messages:
init.c:151: Error: operand type mismatch for `ljmp'

I also tried looking at the assembly code (compile with -S) and it makes total sense why it doesn't compile:

#NO_APP
        leal    kernel_entry@GOTOFF(%eax), %eax
#APP
# 151 "init.c" 1
        ljmp   $8, %eax
# 0 "" 2

This will not work; the ljmp instruction only accepts two constant operands (i.e. not %eax as the second operand).

So, how can I make gcc understand this? Do I need to change the p argument constraint? I tried with changing it to n already but then I get this error instead:

init.c: In function ‘_start’:
init.c:151:5: warning: asm operand 1 probably doesn’t match constraints
     asm ("ljmp   %0, %1"
     ^~~
init.c:151:5: error: impossible constraint in ‘asm’

Many thanks in advance.

Upvotes: 2

Views: 1552

Answers (1)

Per Lundberg
Per Lundberg

Reputation: 4221

As suggested in a comment, it turned out that the problem is that my gcc is using PIC by default:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-5' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-5)

The --enable-default-pie flag is the problem here; it enables PIC/PIE mode by default.

Apparently, many Linux distributions (including Debian) have moved over to position-independent code by default for security reasons: https://wiki.debian.org/Hardening/PIEByDefaultTransition

The workaround for code like this (which really doesn't work in position-independent mode) is to add -fno-pic to the list of compiler arguments - this gives us the following asm output instead which works much better:

# 0 "" 2
        .loc 1 151 0
# 151 "init.c" 1
        ljmp   $8, $kernel_entry
# 0 "" 2

When assembling this, $kernel_entry can be resolved as a compile-time constant => valid machine code for this instruction can be generated.

Upvotes: 2

Related Questions