From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21414 invoked by alias); 21 Dec 2013 23:20:32 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 21404 invoked by uid 89); 21 Dec 2013 23:20:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: bart.luffy.cx Received: from bart.luffy.cx (HELO bart.luffy.cx) (78.47.78.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sat, 21 Dec 2013 23:20:31 +0000 Received: from bart.luffy.cx (localhost [127.0.0.1]) by bart.luffy.cx (Postfix) with ESMTP id CD960141FE for ; Sun, 22 Dec 2013 00:20:27 +0100 (CET) Received: from neo.luffy.cx (unknown [IPv6:2a01:e34:ec6d:710:218:f3ff:fe03:4e06]) by bart.luffy.cx (Postfix) with ESMTPS id 96E62141B0 for ; Sun, 22 Dec 2013 00:20:27 +0100 (CET) Received: by neo.luffy.cx (Postfix, from userid 500) id B9E272B7; Sun, 22 Dec 2013 00:20:26 +0100 (CET) From: Vincent Bernat To: libffi-discuss@sourceware.org Subject: Corrupted stack on Sparc with Python CFFI Date: Sat, 21 Dec 2013 23:20:00 -0000 Message-ID: User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2013/txt/msg00239.txt.bz2 Hi! I have run into the following problem with Python CFFI when running on Sparc V8. The platform is the following: - Linux smetana 2.6.32-5-sparc64-smp #1 SMP Mon Feb 25 02:19:08 UTC 2013 sparc64 GNU/Linux - libffi 3.0.13 - python-cffi 0.8.1 (also tried with Mercurial repository) - 32bit userspace, latest Debian unstable Here is a simple Python program to trigger the bug: #+begin_src python #!/usr/bin/python from cffi import FFI import cffi.verifier cffi.verifier._FORCE_GENERIC_ENGINE = True ffi = FFI() ffi.cdef(""" typedef struct { ...; } myhandle_t; myhandle_t foo(void); """) lib = ffi.verify(""" typedef short myhandle_t; myhandle_t foo(void) { return 42; } """, extra_compile_args=["-g", "-O0"]) print lib.foo() #+end_src If you are not familiar with python cffi, testing for the bug is quite easy, download cffi from here: https://pypi.python.org/pypi/cffi Run "python setup.py build_ext -i", copy the above file in the current directory and execute it with python. You get an illegal instruction error. The generated code contains the following bits: #+begin_src c typedef short myhandle_t; myhandle_t foo(void) { return 42; } myhandle_t _cffi_f_foo(void) { return foo(); } #+end_src When the illegal instruction occurs, I have this in gdb: #+begin_example (gdb) bt #0 _cffi_f_foo () at __pycache__/_cffi__gc12d9a91xdd04fb9c.c:48 #1 0xf7ff401c in ?? () #2 0xf7ff4020 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) disassemble 0xf7ff4008,+30 Dump of assembler code from 0xf7ff4008 to 0xf7ff4026: 0xf7ff4008: mov %i7, %l7 0xf7ff400c: mov %o7, %i7 0xf7ff4010: sethi %hi(0xf78d0400), %g1 0xf7ff4014: call %g1 + 0x228 ! 0xf78d0628 <_cffi_f_foo> 0xf7ff4018: nop 0xf7ff401c: illtrap 0x2 0xf7ff4020: ret 0xf7ff4024: mov %l7, %i7 #+end_example So, the code seems the one generated in `ffi.c`. I don't know if it is expected that the return pointer is set on the illtrap instruction and the next one on ret. When executing step by step the code before the stacks become corrupt after calling _cffi_f_foo: #+begin_example (gdb) bt 2 #0 0xf7ff400c in ?? () #1 0xf7af5b38 in ffi_call_v8 () at ../src/sparc/v8.S:89 (More stack frames follow...) (gdb) si 0xf7ff4010 in ?? () (gdb) bt 2 #0 0xf7ff4010 in ?? () #1 0xf7af5b38 in ffi_call_v8 () at ../src/sparc/v8.S:89 (More stack frames follow...) (gdb) si 0xf7ff4014 in ?? () (gdb) bt 2 #0 0xf7ff4014 in ?? () #1 0xf7af5b38 in ffi_call_v8 () at ../src/sparc/v8.S:89 (More stack frames follow...) (gdb) si 0xf7ff4018 in ?? () (gdb) bt 2 #0 0xf7ff4018 in ?? () #1 0xf7ff4020 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) si _cffi_f_foo () at __pycache__/_cffi__gc12d9a91xdd04fb9c.c:47 47 { (gdb) bt 4 #0 _cffi_f_foo () at __pycache__/_cffi__gc12d9a91xdd04fb9c.c:47 #1 0xf7ff401c in ?? () #2 0xf7ff4020 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) #+end_example I absolutely don't know how the Sparc ABI should work (and I have a hard time even understanding what the illtrap/unimp instruction is used for). Is there something that could explain this behaviour? _cffi_f_foo is like this: #+begin_src asm Dump of assembler code for function _cffi_f_foo: 0xf78d0628 <+0>: save %sp, -96, %sp 0xf78d062c <+4>: call 0xf78d05c0 0xf78d0630 <+8>: nop 0xf78d0634 <+12>: mov %o0, %g1 => 0xf78d0638 <+16>: sll %g1, 0x10, %g1 0xf78d063c <+20>: sra %g1, 0x10, %g1 0xf78d0640 <+24>: mov %g1, %i0 0xf78d0644 <+28>: rett %i7 + 8 0xf78d0648 <+32>: nop #+end_src After returning, I got to the illtrap instruction and get a SIGILL. -- printk(KERN_WARNING "%s: Short circuit detected on the lobe\n", dev->name); 2.4.0-test2 /usr/src/linux/drivers/net/tokenring/lanstreamer.c