My (AT&T) assembly (x86-x64) code should increment but doesn't

Question

I\'m trying to make a small program in assembly (for AT&T). I\'m trying to get an input from the user in the form of an integer, increment it after that and then output

Answer 1

re: updated code:

It runs and increments now, however, when the incremented value is outputed, there show up some weird signs after the value.

Arg-passing registers are call-clobbered. You call printf without putting the format-string into %rdi, which you have to assume holds garbage after scanf returns.

Single-step your code with a debugger. Use ni to step over calls in gdb. (See the bottom of the x86 tag wiki for GDB tips).

Answer 2

This is an assembly-level version of the classic confusion about how to call scanf correctly.

 14 inout:
 15     pushq %rbp              #Pushing bp
 16     movq %rsp, %rbp         #Moving sp to bp
 17     subq $8, %rsp           #Space on stack for variable
 18     leaq -8(%rbp), %rsi
 19     movq $formatstr, %rdi   #1st argument scanf
 20     movq $0, %rax           #no vector for scanf registers
 21     call scanf              #scanf

(Editor's note: prefer either mov $formatstr, %edi in a Linux non-PIE executable, or more portably position-independent lea formatstr(%rip), %rdi to put the address of a string in static storage into a register).

Up to this point your code is correct (except that you haven't aligned the stack correctly, but don't worry about that right now, scanf will probably let you get away with it). Update: modern builds of glibc do have a scanf that faults on a misaligned RSP, since Ubuntu 18.04 for example, maybe earlier.

 22     incq %rsi

Here's where you go wrong. Before the call you set RSI (the second argument register for scanf) to be a pointer to a storage location. scanf read a number from stdin and wrote it to that storage location, not to RSI.

From the discussion in the comments, your intention is to add one to the value read by scanf and immediately print it back out. As several other people pointed out, after scanf returns, you cannot assume that the values you loaded into RSI, RDI, or RAX are intact. (The x86-64 psABI specifies which registers are to be preserved over a function call: of the integer registers, only RBX, RBP, and R12 through R15 are preserved. You should read this document cover to cover if you intend to do much assembly programming on x86-64. (Caution: Windows uses a different ABI whose calling convention is documented on MSDN, see links in the x86 tag wiki.))

So you must set up the args to printf from scratch because scanf destroyed those registers:

       movq -8(%rbp), %rsi   # load variable as arg 2 of printf
       incq %rsi             # and add one
       movq $formatstr, %rdi # first argument to printf
       xorl %rax, %rax       # no vector args to printf
       call printf

Pay close attention to the difference between scanf and printf here: you can use the same format string for both, but when you call scanf you pass the address of a storage location (leaq -8(%rbp), %rsi), whereas when you call printf you pass the value to be printed (movq -8(%rbp), %rsi; incq %rsi).

(In fact you ought to use a slightly different format string when you call printf, because you need to print a newline after the number, so "%ld\n" would be better.)

Your current code does almost this, in a different way. I do it this way because it's bad practice to mess with the stack pointer (popq %rax) in the middle of a function. (Remember what I said about not aligning the stack correctly? It's much easier to keep the stack aligned if you set up a complete "call frame" on entry and then leave the stack pointer alone until exit. Technically you are only required to have the stack pointer aligned at the point of each call instruction, though.)

You also don't end the function correctly:

 27     addq $8, %rs  

I think you didn't copy and paste your entire program - this looks like it's been cut off in the middle of the line. Regardless, if you're going to bother having a frame pointer in the first place (frame pointers are not required on x86-64) you should use it again to exit:

        movq %rbp, %rsp
        popq %rbp
        ret

Incidentally, "AT&T" assembly syntax is used for many different CPU architectures. When talking about assembly language we always need to know the CPU architecture first; the syntax variant (if any) is secondary. You should have titled the question "My assembly program (x86-64, AT&T syntax) ..."

---

As a final piece of advice, I would suggest you compile this C program

#include <stdio.h>

static void inout(void)
{
    long x;
    scanf("%ld", &x);
    printf("%ld\n", x+1);
}

int main(void)
{
    printf("hi\n");
    inout();
    return 0;
}

with your choice of C compiler, using options equivalent to -S -O2 -fno-inline (that is: generate textual assembly language, optimized, but don't do any inlining) and then read through the assembly output line by line. Whenever the C compiler does something different than you did, that probably means it knows something you don't know and you should learn about that something.

Or more simply, look at it on the Godbolt compiler explorer