Debug ARM semihosting Thumb-2 binary

public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed

* Debug ARM semihosting Thumb-2 binary
@ 2012-02-08 10:34 Jonas Maebe
  2012-02-08 17:34 ` Matthew Gretton-Dann
  0 siblings, 1 reply; 10+ messages in thread
From: Jonas Maebe @ 2012-02-08 10:34 UTC (permalink / raw)
  To: gdb

Hi,

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

Thanks,

Jonas

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Debug ARM semihosting Thumb-2 binary
  2012-02-08 10:34 Debug ARM semihosting Thumb-2 binary Jonas Maebe
@ 2012-02-08 17:34 ` Matthew Gretton-Dann
  2012-02-08 22:36   ` Jonas Maebe
  0 siblings, 1 reply; 10+ messages in thread
From: Matthew Gretton-Dann @ 2012-02-08 17:34 UTC (permalink / raw)
  To: Jonas Maebe; +Cc: gdb

On Wed, Feb 08, 2012 at 10:34:18AM +0000, Jonas Maebe wrote:
> Hi,
> 
> 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.

Thanks,

Matt

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Debug ARM semihosting Thumb-2 binary
  2012-02-08 17:34 ` Matthew Gretton-Dann
@ 2012-02-08 22:36   ` Jonas Maebe
  2012-02-09  1:38     ` Matthew Gretton-Dann
  0 siblings, 1 reply; 10+ messages in thread
From: Jonas Maebe @ 2012-02-08 22:36 UTC (permalink / raw)
  To: Matthew Gretton-Dann; +Cc: gdb


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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Debug ARM semihosting Thumb-2 binary
  2012-02-08 22:36   ` Jonas Maebe
@ 2012-02-09  1:38     ` Matthew Gretton-Dann
  2012-02-09 13:08       ` Jonas Maebe
  0 siblings, 1 reply; 10+ messages in thread
From: Matthew Gretton-Dann @ 2012-02-09  1:38 UTC (permalink / raw)
  To: Jonas Maebe, peter.maydell; +Cc: gdb

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Debug ARM semihosting Thumb-2 binary
  2012-02-09  1:38     ` Matthew Gretton-Dann
@ 2012-02-09 13:08       ` Jonas Maebe
  2012-02-15 17:33         ` Peter Maydell
  0 siblings, 1 reply; 10+ messages in thread
From: Jonas Maebe @ 2012-02-09 13:08 UTC (permalink / raw)
  To: Matthew Gretton-Dann; +Cc: peter.maydell, gdb

[-- Attachment #1: Type: text/plain, Size: 2784 bytes --]

On 09 Feb 2012, at 02:38, Matthew Gretton-Dann wrote:

> On Wed, Feb 08, 2012 at 10:35:48PM +0000, Jonas Maebe wrote:
>>
>> 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).

I've now tried both -M lm3s811evb (Stellaris LM3S811EVB) and -M  
lm3s6965evb (Stellaris LM3S6965EVB) together with -cpu cortex-m3.  
Neither appears to work at all: there's no output (not even QEMU  
complaining that it can't open any sound devices, which it does  
instantaneously on startup if I choose the realview-eb platform).

If I start QEMU with a Stellaris platform selected and with -S -s  
(stop immediately on startup and wait for gdb) and attach gdb, the  
process is stopped at address 0 (instead of 0x8000). Removing the - 
semihosting switch does not change this (that would obviously fail as  
soon as a syscall were executed, but it doesn't get that far).

> We need to diagnose whether this is a QEmu or GDB issue.

Yes, I'm also starting to wonder whether I might be QEMU rather than  
gdb that's going wrong...

> What QEmu are you using?

The main site's 1.0 release, manually compiled directly from source  
(on Linux/x86-64).

> 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?

If I run it in QEMU (with -m realview-eb -cpu cortex-m3) without gdb  
attached, everything works correctly (although occasionally not all  
output is printed, but that's probably a QEMU issue). I currently  
can't rebuild it for Cortex-A or anything else because our license for  
RVCT has expired and we're still in the process of renewing it.

> Can you also provide a gdb trace of the remote protocol (use set debug
> remote on before attaching to QEmu).

I've attached the remote log for the qsort_large program I've  
compiled. The binary was started with the following QEMU command line:

~/qemu/bin/qemu-system-arm -nographic -semihosting -M realview-eb -cpu  
cortex-m3 -kernel qsort_large -append "input_large.dat" -s -S

I've also attached the qsort_large binary itself, since it's pretty  
small (and it's from mibench, so it's freely distributable). The  
input_large.dat file that's required for input can be gotten from http://www.eecs.umich.edu/mibench/automotive.tar.gz 
  (automotive/qsort/input_large.dat)

Thanks,

Jonas

[-- Attachment #2: gdb-qsort_large-remote-log.txt --]
[-- Type: text/plain, Size: 7967 bytes --]

$ ~/armgdb/bin/arm-unknown-linux-gnueabi-gdb
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-unknown-linux-gnueabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(reverse-i-search)`set': ^CQuitm force-mode thumb
(gdb) set debug remote 1
(gdb) target remote :1234
Remote debugging using :1234
Sending packet: $qSupported:qRelocInsn+#9a...Ack
Packet received: PacketSize=1000;qXfer:features:read+
Packet qSupported (supported-packets) is supported
Sending packet: $Hg0#df...Ack
Packet received: OK
Sending packet: $qXfer:features:read:target.xml:0,ffb#79...Ack
Packet received: l<?xml version="1.0"?><!DOCTYPE target SYSTEM "gdb-target.dtd"><target><xi:include href="arm-core.xml"/></target>
Sending packet: $qXfer:features:read:arm-core.xml:0,ffb#08...Ack
Packet received: l<?xml version="1.0"?>\n\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.arm.core">\n  <reg name="r0" bitsize="32"/>\n  <reg name="r1" bitsize="32"/>\n  <reg name="r2" bitsize="32"/>\n  <reg name="r3" bitsize="32"/>\n  <reg name="r4" bitsize="32"/>\n  <reg name="r5" bitsize="32"/>\n  <reg name="r6" bitsize="32"/>\n  <reg name="r7" bitsize="32"/>\n  <reg name="r8" bitsize="32"/>\n  <reg name="r9" bitsize="32"/>\n  <reg name="r10" bitsize="32"/>\n  <reg name="r11" bitsize="32"/>\n  <reg name="r12" bitsize="32"/>\n  <reg name="sp" bitsize="32" type="data_ptr"/>\n  <reg name="lr" bitsize="32"/>\n  <reg name="pc" bitsize="32" type="code_ptr"/>\n\n  \n  <reg name="cpsr" bitsize="32" regnum="25"/>\n</feature>\n
Sending packet: $?#3f...Ack
Packet received: T05thread:01;
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received: QC1
Sending packet: $qAttached#8f...Ack
Packet received: 
Packet qAttached (query-attached) is NOT supported
Sending packet: $g#67...Ack
Packet received: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000073010040
Sending packet: $qTStatus#49...Ack
Packet received: 
Sending packet: $qTStatus#49...Ack
Packet received: 
Sending packet: $qTStatus#49...Ack
Packet received: 
Sending packet: $qTStatus#49...Ack
Packet received: 
Sending packet: $m8000,4#95...Ack
Packet received: 00f002f8
Sending packet: $m7ffc,4#33...Ack
Packet received: 00000000
Sending packet: $m8000,4#95...Ack
Packet received: 00f002f8
Sending packet: $m7ffc,4#33...Ack
Packet received: 00000000
Sending packet: $m8000,4#95...Ack
Packet received: 00f002f8
Sending packet: $m7ffc,4#33...Ack
Packet received: 00000000
Sending packet: $m8000,4#95...Ack
Packet received: 00f002f8
Sending packet: $m7ffc,4#33...Ack
Packet received: 00000000
Sending packet: $m8000,4#95...Ack
Packet received: 00f002f8
Sending packet: $m8000,4#95...Ack
Packet received: 00f002f8
Sending packet: $m8000,4#95...Ack
Packet received: 00f002f8
0x00008000 in ?? ()
Sending packet: $qTStatus#49...Ack
Packet received: 
(gdb) x/i $pc
Sending packet: $m8000,2#93...Ack
Packet received: 00f0
Sending packet: $m8002,2#95...Ack
Packet received: 02f8
=> 0x8000:	bl	0x8008
(gdb) c
Continuing.
Sending packet: $qTStatus#49...Ack
Packet received: 
Sending packet: $vCont?#49...Ack
Packet received: vCont;c;C;s;S
Packet vCont (verbose-resume) is supported
Sending packet: $vCont;c#a8...Ack
Packet received: Fopen,04000024/10,00000000,1a4
Sending packet: $m4000024,10#54...Packet instead of Ack, ignoring it
Ack
Packet received: 696e7075745f6c617267652e64617400
Sending packet: $F-1,2#02...Ack
Packet received: Fisatty,00000001
Sending packet: $F1#77...Packet instead of Ack, ignoring it
Ack
Packet received: T02thread:01;
Sending packet: $g#67...Ack
Packet received: 010000002806ea070000000069ac000048ba00000a0000000a000000010000000000000000000000d8b80000d8b80000000000002806ea07c1a60000448c000073010020

Program received signal SIGINT, Interrupt.
Sending packet: $m8c44,4#d0...Ack
Packet received: 08bd1cb5
Sending packet: $m8c40,4#cc...Ack
Packet received: 0920abbe
Sending packet: $m8c44,4#d0...Ack
Packet received: 08bd1cb5
Sending packet: $m8c40,4#cc...Ack
Packet received: 0920abbe
Sending packet: $m8c44,4#d0...Ack
Packet received: 08bd1cb5
Sending packet: $m8c40,4#cc...Ack
Packet received: 0920abbe
Sending packet: $m8c44,4#d0...Ack
Packet received: 08bd1cb5
Sending packet: $m8c40,4#cc...Ack
Packet received: 0920abbe
Sending packet: $m8c44,4#d0...Ack
Packet received: 08bd1cb5
Sending packet: $m8c44,4#d0...Ack
Packet received: 08bd1cb5
Sending packet: $m8c44,4#d0...Ack
Packet received: 08bd1cb5
0x00008c44 in ?? ()
(gdb) x/5i $pc-8
Sending packet: $m8c3c,2#fc...Ack
Packet received: 6946
   0x8c3c:	mov	r1, sp
Sending packet: $m8c3e,2#fe...Ack
Packet received: 0090
   0x8c3e:	str	r0, [sp, #0]
Sending packet: $m8c40,2#ca...Ack
Packet received: 0920
   0x8c40:	movs	r0, #9
Sending packet: $m8c42,2#cc...Ack
Packet received: abbe
   0x8c42:	bkpt	0x00ab
Sending packet: $m8c44,2#ce...Ack
Packet received: 08bd
=> 0x8c44:	pop	{r3, pc}
(gdb) ni
Sending packet: $qTStatus#49...Ack
Packet received: 
Sending packet: $m8c44,2#ce...Ack
Packet received: 08bd
Sending packet: $m8c44,2#ce...Ack
Packet received: 08bd
Sending packet: $m7ea062c,4#c5...Ack
Packet received: c1a60000
Sending packet: $ma6c0,2#f5...Ack
Packet received: 2546
Sending packet: $Z0,a6c0,2#3e...Ack
Packet received: OK
Packet Z0 (software-breakpoint) is supported
Sending packet: $vCont;c#a8...Ack
Packet received: T05thread:01;
Sending packet: $g#67...Ack
Packet received: 010000002806ea07000000000100000048ba00000a0000000a000000010000000000000000000000d8b80000d8b80000000000003006ea07c1a60000c0a6000073010020
Sending packet: $z0,a6c0,2#5e...Ack
Packet received: OK
Sending packet: $ma6c0,4#f7...Ack
Packet received: 25462435
Sending packet: $ma6bc,4#29...Ack
Packet received: fef7bdfa
Sending packet: $ma6c0,4#f7...Ack
Packet received: 25462435
Sending packet: $ma6bc,4#29...Ack
Packet received: fef7bdfa
Sending packet: $ma6c0,4#f7...Ack
Packet received: 25462435
Sending packet: $ma6bc,4#29...Ack
Packet received: fef7bdfa
Sending packet: $ma6c0,4#f7...Ack
Packet received: 25462435
Sending packet: $ma6bc,4#29...Ack
Packet received: fef7bdfa
Sending packet: $ma6c0,4#f7...Ack
Packet received: 25462435
Sending packet: $ma6c0,4#f7...Ack
Packet received: 25462435
Sending packet: $ma6c0,4#f7...Ack
Packet received: 25462435
Sending packet: $ma6c0,4#f7...Ack
Packet received: 25462435
Sending packet: $ma6bc,4#29...Ack
Packet received: fef7bdfa
Sending packet: $ma6c0,4#f7...Ack
Packet received: 25462435
Sending packet: $ma6bc,4#29...Ack
Packet received: fef7bdfa
Sending packet: $ma6c0,4#f7...Ack
Packet received: 25462435
Sending packet: $ma6bc,4#29...Ack
Packet received: fef7bdfa
Sending packet: $ma6c0,4#f7...Ack
Packet received: 25462435
Sending packet: $ma6bc,4#29...Ack
Packet received: fef7bdfa
Sending packet: $ma6c0,4#f7...Ack
Packet received: 25462435
Sending packet: $ma6c0,4#f7...Ack
Packet received: 25462435
Sending packet: $ma6c0,4#f7...Ack
Packet received: 25462435
0x0000a6c0 in ?? ()

[-- Attachment #3: qsort_large.bz2 --]
[-- Type: application/x-bzip2, Size: 19443 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Debug ARM semihosting Thumb-2 binary
  2012-02-09 13:08       ` Jonas Maebe
@ 2012-02-15 17:33         ` Peter Maydell
  2012-02-20 16:21           ` Peter Maydell
  0 siblings, 1 reply; 10+ messages in thread
From: Peter Maydell @ 2012-02-15 17:33 UTC (permalink / raw)
  To: Jonas Maebe; +Cc: Matthew Gretton-Dann, gdb

On 9 February 2012 13:08, Jonas Maebe <jonas.maebe@elis.ugent.be> wrote:
> On 09 Feb 2012, at 02:38, Matthew Gretton-Dann wrote:
>> On Wed, Feb 08, 2012 at 10:35:48PM +0000, Jonas Maebe wrote:
>>> 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).
>
> I've now tried both -M lm3s811evb (Stellaris LM3S811EVB) and -M lm3s6965evb
> (Stellaris LM3S6965EVB) together with -cpu cortex-m3. Neither appears to
> work at all: there's no output (not even QEMU complaining that it can't open
> any sound devices, which it does instantaneously on startup if I choose the
> realview-eb platform).

You shouldn't expect complaints about sound devices because the
stellaris boards don't have any sound devices.

The reason this isn't working for you is that QEMU's M3 model doesn't
pay any attention to the entry point in an ELF file -- it expects that
you feed it an ELF image which starts at address zero and includes the
M profile vector table (from which it will pull the starting PC and SP).

Not supporting "load ELF file and use its entry point as the starting
PC" is arguably a missing feature (although you have to answer the question
of 'so what should the starting SP be' if you want to support this).
However since QEMU's M profile support is basically in the 'odd fixes'
state this isn't likely to be improved in the near future, so the
simplest thing is for you to just generate an ELF file of the right
shape.

Using the 'realview-eb' platform is definitely a bad idea as it only
'works' because we don't really nail down the set of supported CPUs;
at some point in the future it may actively tell you this set of
command line options are a user error :-)

>> We need to diagnose whether this is a QEmu or GDB issue.

> Yes, I'm also starting to wonder whether I might be QEMU rather than gdb
> that's going wrong...

Coincidentally, Meador Inge from CodeSourcery posted a patch to the
QEMU list today which fixes the SIGINT issue:
http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02008.html
(not yet code reviewed, but I did a quick test and it does seem to
at least avoid the SIGINT problems.)
However speed of fread over the gdb syscall interface is absolutely
dire, it seems (from 'set debug remote 1') to be doing about one
data packet a second...

-- PMM

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Debug ARM semihosting Thumb-2 binary
  2012-02-15 17:33         ` Peter Maydell
@ 2012-02-20 16:21           ` Peter Maydell
  2012-02-23 14:12             ` Jonas Maebe
  0 siblings, 1 reply; 10+ messages in thread
From: Peter Maydell @ 2012-02-20 16:21 UTC (permalink / raw)
  To: Jonas Maebe; +Cc: Matthew Gretton-Dann, gdb

On 15 February 2012 17:33, Peter Maydell <peter.maydell@linaro.org> wrote:
> Coincidentally, Meador Inge from CodeSourcery posted a patch to the
> QEMU list today which fixes the SIGINT issue:
> http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02008.html
> (not yet code reviewed, but I did a quick test and it does seem to
> at least avoid the SIGINT problems.)
> However speed of fread over the gdb syscall interface is absolutely
> dire, it seems (from 'set debug remote 1') to be doing about one
> data packet a second...

There's now a version 2 of the patch which attacks the problem
in a slightly different way and fixes both the SIGINT problems and
also the occasional stalls which were causing semihosting read/write
performance to be so poor:

http://patchwork.ozlabs.org/patch/141867/

-- PMM

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Debug ARM semihosting Thumb-2 binary
  2012-02-20 16:21           ` Peter Maydell
@ 2012-02-23 14:12             ` Jonas Maebe
  2012-02-23 14:48               ` Peter Maydell
  0 siblings, 1 reply; 10+ messages in thread
From: Jonas Maebe @ 2012-02-23 14:12 UTC (permalink / raw)
  To: Peter Maydell; +Cc: Matthew Gretton-Dann, gdb

[-- Attachment #1: Type: text/plain, Size: 2604 bytes --]

On 20 Feb 2012, at 17:21, Peter Maydell wrote:

> The reason this isn't working for you is that QEMU's M3 model doesn't
> pay any attention to the entry point in an ELF file -- it expects that
> you feed it an ELF image which starts at address zero and includes the
> M profile vector table (from which it will pull the starting PC and  
> SP).
>
> Not supporting "load ELF file and use its entry point as the starting
> PC" is arguably a missing feature (although you have to answer the  
> question
> of 'so what should the starting SP be' if you want to support this).
> However since QEMU's M profile support is basically in the 'odd fixes'
> state this isn't likely to be improved in the near future, so the
> simplest thing is for you to just generate an ELF file of the right
> shape.

I see, thanks. I'm currently waiting for a renewal of our compiler  
license though, so right now that's unfortunately not an option (I can  
use objcopy extract a binary dump from my binary, but then it misses  
the vector table). Since I'm not writing an OS but am running very  
simple minibenchmarks (mibench), I assume that in general things  
should work fine though. Except, of course, if the bkpt instructions  
require extra support not provided by the realview-eb platform...

> There's now a version 2 of the patch which attacks the problem
> in a slightly different way and fixes both the SIGINT problems and
> also the occasional stalls which were causing semihosting read/write
> performance to be so poor:
>
> http://patchwork.ozlabs.org/patch/141867/

Thanks. I tested it (with the realview-eb platform) on top of Qemu  
1.0, but unfortunately it doesn't completely solve the problem yet for  
me:
a) gdb no longer stops with SIGINT whenever a bkpt is executed, which  
is good
b) however, the syscalls still don't seem to get executed, or at least  
do not return the proper result

Without gdb attached, the qsort_large binary shows this output:

***
Sorting 50000 vectors based on distance from the origin.

25138398 28611231 9838998
[etc]
***

With gdb attached, this is the output:

***
Sorting 0 vectors based on distance from the origin.
***

So it seems the reading of the input file fails. FWIW, this is the  
same output I got before the patch, except that GDB then also stopped  
with a SIGINT every time a syscall/bkpt was executed. I've attached  
the new target remote debug output from gdb.

If this is due to me using the realview-eb platform, then I guess I'll  
just have to do without debugging past the first syscall until I can  
regenerate my binaries.

Thanks,

Jonas

[-- Attachment #2: target-remote-v2.txt --]
[-- Type: text/plain, Size: 4098 bytes --]

(gdb) set arm force-mode thumb
(gdb) set debug remote 1
(gdb) target remote :1234
Remote debugging using :1234
Sending packet: $qSupported:qRelocInsn+#9a...Ack
Packet received: PacketSize=1000;qXfer:features:read+
Packet qSupported (supported-packets) is supported
Sending packet: $Hg0#df...Ack
Packet received: OK
Sending packet: $qXfer:features:read:target.xml:0,ffb#79...Ack
Packet received: l<?xml version="1.0"?><!DOCTYPE target SYSTEM "gdb-target.dtd"><target><xi:include href="arm-core.xml"/></target>
Sending packet: $qXfer:features:read:arm-core.xml:0,ffb#08...Ack
Packet received: l<?xml version="1.0"?>\n\n\n<!DOCTYPE feature SYSTEM "gdb-target.dtd">\n<feature name="org.gnu.gdb.arm.core">\n  <reg name="r0" bitsize="32"/>\n  <reg name="r1" bitsize="32"/>\n  <reg name="r2" bitsize="32"/>\n  <reg name="r3" bitsize="32"/>\n  <reg name="r4" bitsize="32"/>\n  <reg name="r5" bitsize="32"/>\n  <reg name="r6" bitsize="32"/>\n  <reg name="r7" bitsize="32"/>\n  <reg name="r8" bitsize="32"/>\n  <reg name="r9" bitsize="32"/>\n  <reg name="r10" bitsize="32"/>\n  <reg name="r11" bitsize="32"/>\n  <reg name="r12" bitsize="32"/>\n  <reg name="sp" bitsize="32" type="data_ptr"/>\n  <reg name="lr" bitsize="32"/>\n  <reg name="pc" bitsize="32" type="code_ptr"/>\n\n  \n  <reg name="cpsr" bitsize="32" regnum="25"/>\n</feature>\n
Sending packet: $?#3f...Ack
Packet received: T05thread:01;
Sending packet: $Hc-1#09...Ack
Packet received: OK
Sending packet: $qC#b4...Ack
Packet received: QC1
Sending packet: $qAttached#8f...Ack
Packet received: 
Packet qAttached (query-attached) is NOT supported
Sending packet: $g#67...Ack
Packet received: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000080000073010040
Sending packet: $m8000,4#95...Ack
Packet received: 00f002f8
Sending packet: $m7ffc,4#33...Ack
Packet received: 00000000
Sending packet: $m8000,4#95...Ack
Packet received: 00f002f8
Sending packet: $m7ffc,4#33...Ack
Packet received: 00000000
Sending packet: $m8000,4#95...Ack
Packet received: 00f002f8
Sending packet: $m7ffc,4#33...Ack
Packet received: 00000000
Sending packet: $m8000,4#95...Ack
Packet received: 00f002f8
Sending packet: $m8000,4#95...Ack
Packet received: 00f002f8
Sending packet: $m8000,4#95...Ack
Packet received: 00f002f8
0x00008000 in ?? ()
Sending packet: $qTStatus#49...Ack
Packet received: 
(gdb) c
Continuing.
Sending packet: $vCont?#49...Ack
Packet received: vCont;c;C;s;S
Packet vCont (verbose-resume) is supported
Sending packet: $vCont;c#a8...Ack
Packet received: Fopen,04000024/10,00000000,1a4
Sending packet: $m4000024,10#54...Ack
Packet received: 696e7075745f6c617267652e64617400
Sending packet: $F-1,2#02...Ack
Packet received: Fisatty,00000001
Sending packet: $F1#77...Ack
Packet received: Fwrite,00000001,04000188,00000001
Sending packet: $m4000188,1#2f...Ack
Packet received: 0a

Sending packet: $F1#77...Ack
Packet received: Fwrite,00000001,04000188,00000035
Sending packet: $m4000188,35#66...Ack
Packet received: 536f7274696e67203020766563746f7273206261736564206f6e2064697374616e63652066726f6d20746865206f726967696e2e0a
Sorting 0 vectors based on distance from the origin.
Sending packet: $F35#ae...Ack
Packet received: Fwrite,00000001,04000188,00000001
Sending packet: $m4000188,1#2f...Ack
Packet received: 0a

Sending packet: $F1#77...Ack
Packet received: Fclose,00000000
Sending packet: $F0#76...Ack
Packet received: Fclose,00000001
Sending packet: $F0#76...Ack
Packet received: Fclose,00000001
Sending packet: $F-1,9#09...Ack
Packet received: W00

Program exited normally.

[-- Attachment #3: Type: text/plain, Size: 1 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Debug ARM semihosting Thumb-2 binary
  2012-02-23 14:12             ` Jonas Maebe
@ 2012-02-23 14:48               ` Peter Maydell
  2012-02-23 14:51                 ` Jonas Maebe
  0 siblings, 1 reply; 10+ messages in thread
From: Peter Maydell @ 2012-02-23 14:48 UTC (permalink / raw)
  To: Jonas Maebe; +Cc: Matthew Gretton-Dann, gdb

On 23 February 2012 14:12, Jonas Maebe <jonas.maebe@elis.ugent.be> wrote:
> Without gdb attached, the qsort_large binary shows this output:
>
> ***
> Sorting 50000 vectors based on distance from the origin.
>
> 25138398 28611231 9838998
> [etc]
> ***
>
> With gdb attached, this is the output:
>
> ***
> Sorting 0 vectors based on distance from the origin.
> ***
>
> So it seems the reading of the input file fails.

I look into my crystal ball and deduce that you're running gdb
in the wrong directory. When you do semihosting via gdb syscalls
the file opens are for paths relative to gdb's working directory,
not qemu's. This particular test seems to have no error handling
so if it can't open the file it will happily proceed to sort
no data...

-- PMM

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Debug ARM semihosting Thumb-2 binary
  2012-02-23 14:48               ` Peter Maydell
@ 2012-02-23 14:51                 ` Jonas Maebe
  0 siblings, 0 replies; 10+ messages in thread
From: Jonas Maebe @ 2012-02-23 14:51 UTC (permalink / raw)
  To: Peter Maydell; +Cc: Matthew Gretton-Dann, gdb


On 23 Feb 2012, at 15:47, Peter Maydell wrote:

> On 23 February 2012 14:12, Jonas Maebe <jonas.maebe@elis.ugent.be>  
> wrote:
>> So it seems the reading of the input file fails.
>
> I look into my crystal ball and deduce that you're running gdb
> in the wrong directory. When you do semihosting via gdb syscalls
> the file opens are for paths relative to gdb's working directory,
> not qemu's. This particular test seems to have no error handling
> so if it can't open the file it will happily proceed to sort
> no data...

That's an awesome crystal ball, I want one too! I can confirm now that  
the patch works as expected and everything is fine.

Thanks a lot!


Jonas

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2012-02-23 14:51 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-02-08 10:34 Debug ARM semihosting Thumb-2 binary Jonas Maebe
2012-02-08 17:34 ` Matthew Gretton-Dann
2012-02-08 22:36   ` Jonas Maebe
2012-02-09  1:38     ` Matthew Gretton-Dann
2012-02-09 13:08       ` Jonas Maebe
2012-02-15 17:33         ` Peter Maydell
2012-02-20 16:21           ` Peter Maydell
2012-02-23 14:12             ` Jonas Maebe
2012-02-23 14:48               ` Peter Maydell
2012-02-23 14:51                 ` Jonas Maebe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).