From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15179 invoked by alias); 9 Feb 2012 01:38:44 -0000 Received: (qmail 15171 invoked by uid 22791); 9 Feb 2012 01:38:43 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,TW_QE X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 09 Feb 2012 01:38:28 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Thu, 09 Feb 2012 01:38:26 +0000 Received: from e103070-lin.arm.com ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Feb 2012 01:38:24 +0000 Date: Thu, 09 Feb 2012 01:38:00 -0000 From: Matthew Gretton-Dann To: Jonas Maebe , peter.maydell@linaro.org Cc: "gdb@sourceware.org" Subject: Re: Debug ARM semihosting Thumb-2 binary Message-ID: <20120209013821.GB7259@e103070-lin.arm.com> Mail-Followup-To: Jonas Maebe , peter.maydell@linaro.org, "gdb@sourceware.org" References: <047D674A-A77C-4E5A-B207-592A81D857DC@elis.ugent.be> <20120208173258.GA21639@e103070-lin.arm.com> <2370539B-1B7C-4ADB-B44F-0F09553C5D62@elis.ugent.be> MIME-Version: 1.0 In-Reply-To: <2370539B-1B7C-4ADB-B44F-0F09553C5D62@elis.ugent.be> User-Agent: Mutt/1.5.20 (2009-06-14) X-MC-Unique: 112020901382600201 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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/msg00018.txt.bz2 On Wed, Feb 08, 2012 at 10:35:48PM +0000, Jonas Maebe wrote: >=20 > On 08 Feb 2012, at 18:32, Matthew Gretton-Dann wrote: >=20 > > On Wed, Feb 08, 2012 at 10:34:18AM +0000, Jonas Maebe wrote: > >>=20 > >> I'm debugging ARM binaries compiled for the semihosting interface (htt= p://infocenter.arm.com/help/index.jsp?topic=3D/com.arm.doc.dui0471c/CHDJHHD= I.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://infocen= ter.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? >=20 > 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 instruction= s afterwards (Thumb-2 branches). The issue with the unrecognised bkpt's als= o manifests itself when I use the original (not rewritten) binaries though,= so it's not an artifact of the rewriting process. >=20 > The full QEMU command line I use: >=20 > ~/qemu/bin/qemu-system-arm -nographic -semihosting -M realview-eb -cpu co= rtex-m3 -kernel qsort_large -append "input_large.dat" -S -s I think -M realview-eb -cpu cortex-m3 is not the best way of invoking qemu as it generates a system with a Cortex-M3 but without the appropriate interrupt controller. Try one of the Stellaris boards instead (use -machine ? to get the actual command line). >=20 > Note that if I don't use -s/-S (used to tell QEMU to wait for gdb to atta= ch), the binary runs and completes successfully/correctly. >=20 > > The docs aren't clear but BKPT should only be used > > for Cortex-M CPUs - otherwise 'svc 0xab' is appropriate in ARM state. >=20 > Since Cortex-M0/M3 don't support ARM state, I guess bkpt should be ok her= e. >=20 > > However, I know there have been issues with libgloss/newlib using the w= rong > > semi-hosting call sequence in some cases. > >=20 > > Try updating newlib (if that is what you are using) if you are compilin= g for > > non-Cortex-M systems. If you are compiling for a Cortex-M CPU then I > > believe things should work. >=20 > I'm using RVCT 4.1 (v713) along with the libraries it ships with (well, I= have used RVCT 4.1 to compile those binaries; our license has lapsed in th= e mean time). Ah sorry - I was going down the wrong route - I misread your initial email. We need to diagnose whether this is a QEmu or GDB issue. What QEmu are you using? Can you clarify whether this is Cortex-M3 specific? Does it happen if you build for a Cortex-A profile CPU in ARM and Thumb state? What happens when you run the image in QEmu without GDB attached? Can you also provide a gdb trace of the remote protocol (use set debug remote on before attaching to QEmu). Thanks, Matt --=20 Matthew Gretton-Dann Principal Engineer, PD Software, ARM Ltd.