From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27209 invoked by alias); 8 Feb 2012 22:36:06 -0000 Received: (qmail 26925 invoked by uid 22791); 8 Feb 2012 22:36:03 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,TW_QE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp2.ugent.be (HELO smtp2.UGent.be) (157.193.49.126) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 08 Feb 2012 22:35:47 +0000 Received: from localhost (mcheck5.ugent.be [157.193.49.247]) by smtp2.UGent.be (Postfix) with ESMTP id 3E79D44A715; Wed, 8 Feb 2012 23:35:46 +0100 (CET) Received: from smtp2.UGent.be ([157.193.49.126]) by localhost (mcheck5.UGent.be [157.193.43.11]) (amavisd-new, port 10024) with ESMTP id 4i6BIcRSfBfQ; Wed, 8 Feb 2012 23:35:45 +0100 (CET) Received: from [192.168.1.2] (45.77-241-81.adsl-dyn.isp.belgacom.be [81.241.77.45]) (Authenticated sender: jmaebe) by smtp2.UGent.be (Postfix) with ESMTPSA id 7FFEC44A57D; Wed, 8 Feb 2012 23:35:45 +0100 (CET) Subject: Re: Debug ARM semihosting Thumb-2 binary Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonas Maebe In-Reply-To: <20120208173258.GA21639@e103070-lin.arm.com> Date: Wed, 08 Feb 2012 22:36:00 -0000 Cc: "gdb@sourceware.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2370539B-1B7C-4ADB-B44F-0F09553C5D62@elis.ugent.be> References: <047D674A-A77C-4E5A-B207-592A81D857DC@elis.ugent.be> <20120208173258.GA21639@e103070-lin.arm.com> To: Matthew Gretton-Dann X-j-chkmail-Enveloppe: 4F32F8C0.005/81.241.77.45/45.77-241-81.adsl-dyn.isp.belgacom.be/[192.168.1.2]/ X-j-chkmail-Score: MSGID : 4F32F8C0.005 on smtp2.UGent.be : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-02/txt/msg00016.txt.bz2 On 08 Feb 2012, at 18:32, Matthew Gretton-Dann wrote: > On Wed, Feb 08, 2012 at 10:34:18AM +0000, Jonas Maebe wrote: >>=20 >> I'm debugging ARM binaries compiled for the semihosting interface (http:= //infocenter.arm.com/help/index.jsp?topic=3D/com.arm.doc.dui0471c/CHDJHHDI.= html=20 >> ). The binaries run under qemu-system-arm and I'm using QEMU's gdb=20=20 >> remote target interface. >>=20 >> In general, this works fine, except when such binaries are Thumb-2 and= =20=20 >> perform system calls. The reason is that for Thumb-2, the system call=20= =20 >> interface of the semihosting platform uses "bkpt 0xab" (http://infocente= r.arm.com/help/index.jsp?topic=3D/com.arm.doc.dui0491c/CJAFABBB.html=20 >> ). GDB intercepts this bkpt, halts the execution with a SIGINT=20=20 >> message and does not pass it on to the debugged process. If the=20=20 >> process is then continued, it behaves as if the system call/bkpt in=20=20 >> question never was executed >>=20 >> Using "handle SIGINT pass" does not change this. >>=20 >> Is there another way to tell gdb to ignore those particular bkpt=20=20 >> instructions and execute them normally? I'm using gdb 7.4 (7.2 behaves= =20=20 >> the same). >=20 > What CPU are you compiling for? Cortex-M0. I'm executing them under QEMU as Cortex-M3 because 1) QEMU (1.0) does not know about Cortex-M0 2) the binaries are rewritten and contain a few non Cortex-M0 instructions = afterwards (Thumb-2 branches). The issue with the unrecognised bkpt's also = manifests itself when I use the original (not rewritten) binaries though, s= o it's not an artifact of the rewriting process. The full QEMU command line I use: ~/qemu/bin/qemu-system-arm -nographic -semihosting -M realview-eb -cpu cort= ex-m3 -kernel qsort_large -append "input_large.dat" -S -s Note that if I don't use -s/-S (used to tell QEMU to wait for gdb to attach= ), the binary runs and completes successfully/correctly. > The docs aren't clear but BKPT should only be used > for Cortex-M CPUs - otherwise 'svc 0xab' is appropriate in ARM state. Since Cortex-M0/M3 don't support ARM state, I guess bkpt should be ok here. > However, I know there have been issues with libgloss/newlib using the wro= ng > semi-hosting call sequence in some cases. >=20 > Try updating newlib (if that is what you are using) if you are compiling = for > non-Cortex-M systems. If you are compiling for a Cortex-M CPU then I > believe things should work. I'm using RVCT 4.1 (v713) along with the libraries it ships with (well, I h= ave used RVCT 4.1 to compile those binaries; our license has lapsed in the = mean time). Jonas