Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jonas Maebe <jonas.maebe@elis.ugent.be>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Matthew Gretton-Dann <matthew.gretton-dann@arm.com>,
	"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: Debug ARM semihosting Thumb-2 binary
Date: Thu, 23 Feb 2012 14:12:00 -0000	[thread overview]
Message-ID: <0BFF88B8-4648-444A-B4ED-2BEEAD2F35E8@elis.ugent.be> (raw)
In-Reply-To: <CAFEAcA858F27c-5UJQjDO6cKKV17=neAJMaSjqN3tVE0LwtQtw@mail.gmail.com>

[-- 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 --]



  reply	other threads:[~2012-02-23 14:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-08 10:34 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 [this message]
2012-02-23 14:48               ` Peter Maydell
2012-02-23 14:51                 ` Jonas Maebe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0BFF88B8-4648-444A-B4ED-2BEEAD2F35E8@elis.ugent.be \
    --to=jonas.maebe@elis.ugent.be \
    --cc=gdb@sourceware.org \
    --cc=matthew.gretton-dann@arm.com \
    --cc=peter.maydell@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox