This is the mail archive of the
mailing list for the GDB project.
Re: Debug ARM semihosting Thumb-2 binary
On 08 Feb 2012, at 18:32, Matthew Gretton-Dann wrote:
> 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?
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, so 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 cortex-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 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.
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 the mean time).