http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56621



             Bug #: 56621

           Summary: Misaligned stack with inline assembly

    Classification: Unclassified

           Product: gcc

           Version: 4.7.2

            Status: UNCONFIRMED

          Severity: normal

          Priority: P3

         Component: inline-asm

        AssignedTo: unassig...@gcc.gnu.org

        ReportedBy: au...@yahoo.com





The following minimal program (compiled merely by "gcc test.c -o test") is

intended to write "test" to standard output using the write system call, and

then exit:



int main() {

    int tmp;

    char message[8] = "test\n";

    int message_size = 5;



    // Comment out this loop and it suddenly works correctly.

    for (tmp = 0; tmp < 1; ++tmp) { }



    __asm__ __volatile__

    (

        "movq $1, %%rax;"       // System call 1 (write)

        "movq $1, %%rdi;"       // File descriptor 1 (stdout)

        "movq %0, %%rsi;"       // %0 is message

        "movq %1, %%rdx;"       // %1 is message_size

        "syscall"

        :

        : "q"(message), "g"(message_size)

        : "%rax", "%rdi", "%rsi", "%rdx", "%rcx", "%r11"

    );



    return(0);

}



This version produces no output, and exits immediately.  If the marked "for"

loop is commented out, the program *does* produce the expected output. 

(Obviously, the original version where I discovered this problem had a loop

that did actual work).



Examining the binary via objdump (or the intermediate test.s file when

preserving temporary files), I find that it uses an instruction of "movq

-8(%rbp), %rdx" in the non-working version, as compared to "movq -4(%rbp,

%rdx)" in the working version.  Similarly, the initial assignment is done by an

offset of -8 or -4 in the stack, respectively.  If I directly edit the binary

file to change the instruction to the correct offset, the non-working version

then starts working as expected.



This problem is present in the default Debian "wheezy" gcc version 4.7.2

(output of gcc -v below); it is also present in the latest development version

as of the time of this bug report, which I downloaded and compiled in order to

test the problem.  The bug is *not* present in the Debian "squeeze" version

4.4.5 of gcc, so I can only conclude that this became an issue somewhere in an

intervening version.



$ gcc -v

Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper

Target: x86_64-linux-gnu

Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'

--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs

--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr

--program-suffix=-4.7 --enable-shared --enable-linker-build-id

--with-system-zlib --libexecdir=/usr/lib --without-included-gettext

--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7

--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu

--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object

--enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic

--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu

--target=x86_64-linux-gnu

Thread model: posix

gcc version 4.7.2 (Debian 4.7.2-5)

Reply via email to