* 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<!-- Copyright (C) 2008 Free Software Foundation, Inc.\n\n Copying and distribution of this file, with or without modification,\n are permitted in any medium without royalty provided the copyright\n notice and this notice are preserved. -->\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 <!-- The CPSR is register 25, rather than register 16, because\n the FPA registers historically were placed between the PC\n and the CPSR in the "g" packet. -->\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<!-- Copyright (C) 2008 Free Software Foundation, Inc.\n\n Copying and distribution of this file, with or without modification,\n are permitted in any medium without royalty provided the copyright\n notice and this notice are preserved. -->\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 <!-- The CPSR is register 25, rather than register 16, because\n the FPA registers historically were placed between the PC\n and the CPSR in the "g" packet. -->\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).