Re: Debug ARM semihosting Thumb-2 binary

[Jonas Maebe <jonas.maebe@elis.ugent.be>]

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


Jonas