This is the mail archive of the
mailing list for the GDB project.
Re: Debug ARM semihosting Thumb-2 binary
On Wed, Feb 08, 2012 at 10:35:48PM +0000, Jonas Maebe wrote:
> 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
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).
> 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).
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).
Principal Engineer, PD Software, ARM Ltd.