Re: Debug ARM semihosting Thumb-2 binary

[Matthew Gretton-Dann <matthew.gretton-dann@arm.com>]

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).

Thanks,

Matt

-- 
Matthew Gretton-Dann
Principal Engineer, PD Software, ARM Ltd.