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