This is the mail archive of the
mailing list for the GDB project.
Re: Debug ARM semihosting Thumb-2 binary
- From: Matthew Gretton-Dann <matthew dot gretton-dann at arm dot com>
- To: Jonas Maebe <jonas dot maebe at elis dot ugent dot be>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Wed, 8 Feb 2012 17:32:58 +0000
- Subject: Re: Debug ARM semihosting Thumb-2 binary
- References: <047D674A-A77C-4E5A-B207-592A81D857DC@elis.ugent.be>
On Wed, Feb 08, 2012 at 10:34:18AM +0000, Jonas Maebe wrote:
> I'm debugging ARM binaries compiled for the semihosting interface (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/CHDJHHDI.html
> ). The binaries run under qemu-system-arm and I'm using QEMU's gdb
> remote target interface.
> In general, this works fine, except when such binaries are Thumb-2 and
> perform system calls. The reason is that for Thumb-2, the system call
> interface of the semihosting platform uses "bkpt 0xab" (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491c/CJAFABBB.html
> ). GDB intercepts this bkpt, halts the execution with a SIGINT
> message and does not pass it on to the debugged process. If the
> process is then continued, it behaves as if the system call/bkpt in
> question never was executed
> Using "handle SIGINT pass" does not change this.
> Is there another way to tell gdb to ignore those particular bkpt
> instructions and execute them normally? I'm using gdb 7.4 (7.2 behaves
> the same).
What CPU are you compiling for? The docs aren't clear but BKPT should only be used
for Cortex-M CPUs - otherwise 'svc 0xab' is appropriate in ARM state.
However, I know there have been issues with libgloss/newlib using the wrong
semi-hosting call sequence in some cases.
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.
Principal Engineer, PD Software, ARM Ltd.