Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb-patches@sourceware.org, Jerome Guitton <guitton@adacore.com>
Subject: Re: [RFA] arm-pikeos: software single step
Date: Tue, 11 Sep 2018 20:57:00 -0000	[thread overview]
Message-ID: <20180911205742.GB12573@adacore.com> (raw)
In-Reply-To: <15fd4c1d-d265-073d-a4d8-14de3d607a44@redhat.com>

Hi again Pedro,

> > Unfortunately, the problem is that we do not control the stub (muxa),
> > it is a tool that the vendor provides.
>
> Did you check whether it is already reporting the RSP packets as I
> had suggested?  We wouldn't be adding new packets, but instead using
> some that are already defined.
> 
> If the stub really needs modification, I'm not opposed to your patch
> as stop gap.  Would there be any chance to forward the information to
> the sysgo folks, see if they're willing to tweak the stub?  It should
> be a trivial change.

So, here is what I could gather (full log at the end of this email [1]).
GDB sends the $qSupported packet, equiring about support...

    | Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack

... and the list returned is fairly small, as I suspected:

    | Packet received: qXfer:features:read+

After that, I don't see very much happening at the vCont level,
so fast-forward to the first "cont" command (after having inserted
a breakpoint), and we see some interesting stuff. In particular,
GDB asks the target what vCont support it provides, and here is
what we receive:

    | Sending packet: $vCont?#49...Ack
    | Packet received: vCont;c;s;C;S
    | Packet vCont (verbose-resume) is supported

Hah! So, on the one end, the stub says stepping is supported
('s' and 'S'), but on the other hand we were told that this
feature is not supported on ARM.

So, if I understand correctly the current situation, we do have
one small infrastructure adjustment to do in GDB, but then once
done, if the stub on advertised support for "vCont;c;C", then
GDB would automatically be switching to software single step.
Do I understand correctly?

If that's correct, I'll make sure AdaCore forwards the suggestion
to Sysgo.

Thanks!
-- 
Joel

[1] For the record, complete copy/paste of a short "target remote"
    + "break xxx" + "cont" + "next" session, just for the record.

    | (gdb) tar rem :1502
    | Remote debugging using :1502
    | Sending packet: $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack
    | Packet received: qXfer:features:read+
    | Packet qSupported (supported-packets) is supported
    | Sending packet: $vMustReplyEmpty#3a...Ack
    | Packet received:
    | Sending packet: $Hg0#df...Ack
    | Packet received: OK
    | Sending packet: $qXfer:features:read:target.xml:0,18a#15...Ack
    | Packet received: m<?xml version="1.0"?>\n<!-- Copyright (C) 2009-2015 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 target SYSTEM "gdb-target.dtd">\n<target version="1.0">\n\n<feature name="org.gnu.gdb.arm.core">\n  <reg name
    | Sending packet: $qXfer:features:read:target.xml:189,18a#87...Ack
    | Packet received: m="r0" bitsize="32" type="uint32"/>\n  <reg name="r1" bitsize="32" type="uint32"/>\n  <reg name="r2" bitsize="32" type="uint32"/>\n  <reg name="r3" bitsize="32" type="uint32"/>\n  <reg name="r4" bitsize="32" type="uint32"/>\n  <reg name="r5" bitsize="32" type="uint32"/>\n  <reg name="r6" bitsize="32" type="uint32"/>\n  <reg name="r7" bitsize="32" type="uint32"/>\n  <reg name="r8" bitsize="32" type="
    | Sending packet: $qXfer:features:read:target.xml:312,18a#7b...Ack
    | Packet received: muint32"/>\n  <reg name="r9" bitsize="32" type="uint32"/>\n  <reg name="r10" bitsize="32" type="uint32"/>\n  <reg name="r11" bitsize="32" type="uint32"/>\n  <reg name="r12" bitsize="32" type="uint32"/>\n  <reg name="sp" bitsize="32" type="data_ptr"/>\n  <reg name="lr" bitsize="32" type="code_ptr"/>\n  <reg name="pc" bitsize="32" type="code_ptr"/>\n\n  <!-- The CPSR is register 25, rather than registe
    | Sending packet: $qXfer:features:read:target.xml:49b,18a#b4...Ack
    | Packet received: mr 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\n<feature name="org.gnu.gdb.arm.vfp">\n  <reg name="d0" bitsize="64" type="ieee_double"/>\n  <reg name="d1" bitsize="64" type="ieee_double"/>\n  <reg name="d2" bitsize="64" type="ieee_double"/>\n  <reg name="d3" bitsi
    | Sending packet: $qXfer:features:read:target.xml:624,18a#81...Ack
    | Packet received: mze="64" type="ieee_double"/>\n  <reg name="d4" bitsize="64" type="ieee_double"/>\n  <reg name="d5" bitsize="64" type="ieee_double"/>\n  <reg name="d6" bitsize="64" type="ieee_double"/>\n  <reg name="d7" bitsize="64" type="ieee_double"/>\n  <reg name="d8" bitsize="64" type="ieee_double"/>\n  <reg name="d9" bitsize="64" type="ieee_double"/>\n  <reg name="d10" bitsize="64" type="ieee_double"/>\n  <reg
    | Sending packet: $qXfer:features:read:target.xml:7ad,18a#e1...Ack
    | Packet received: m name="d11" bitsize="64" type="ieee_double"/>\n  <reg name="d12" bitsize="64" type="ieee_double"/>\n  <reg name="d13" bitsize="64" type="ieee_double"/>\n  <reg name="d14" bitsize="64" type="ieee_double"/>\n  <reg name="d15" bitsize="64" type="ieee_double"/>\n  <reg name="d16" bitsize="64" type="ieee_double"/>\n  <reg name="d17" bitsize="64" type="ieee_double"/>\n  <reg name="d18" bitsize="64" type
    | Sending packet: $qXfer:features:read:target.xml:936,18a#87...Ack
    | Packet received: m="ieee_double"/>\n  <reg name="d19" bitsize="64" type="ieee_double"/>\n  <reg name="d20" bitsize="64" type="ieee_double"/>\n  <reg name="d21" bitsize="64" type="ieee_double"/>\n  <reg name="d22" bitsize="64" type="ieee_double"/>\n  <reg name="d23" bitsize="64" type="ieee_double"/>\n  <reg name="d24" bitsize="64" type="ieee_double"/>\n  <reg name="d25" bitsize="64" type="ieee_double"/>\n  <reg name=
    | Sending packet: $qXfer:features:read:target.xml:abf,18a#0e...Ack
    | Packet received: m"d26" bitsize="64" type="ieee_double"/>\n  <reg name="d27" bitsize="64" type="ieee_double"/>\n  <reg name="d28" bitsize="64" type="ieee_double"/>\n  <reg name="d29" bitsize="64" type="ieee_double"/>\n  <reg name="d30" bitsize="64" type="ieee_double"/>\n  <reg name="d31" bitsize="64" type="ieee_double"/>\n\n  <reg name="fpscr" bitsize="32" type="int" group="float"/>\n</feature>\n\n<feature name="org.g
    | Sending packet: $qXfer:features:read:target.xml:c48,18a#b4...Ack
    | Packet received: lnu.gdb.arm.neon"/>\n\n</target>\n
    | Sending packet: $qTStatus#49...Ack
    | Packet received:
    | Packet qTStatus (trace-status) is NOT supported
    | Sending packet: $?#3f...Ack
    | Packet received: S05
    | Sending packet: $qfThreadInfo#bb...Ack
    | Packet received: m1
    | Sending packet: $qsThreadInfo#c8...Ack
    | Packet received: l
    | Sending packet: $qAttached#8f...Ack
    | Packet received:
    | Packet qAttached (query-attached) is NOT supported
    | Sending packet: $Hc-1#09...Ack
    | Packet received: OK
    | Sending packet: $qC#b4...Ack
    | Packet received: QC1
    | Sending packet: $qOffsets#4b...Ack
    | Packet received:
    | Sending packet: $g#67...Ack
    | Packet received: 01000000e07b0f08c47b0f082014030800000000000000000000000000000000000000000000000000000000fc7f0f0800000000987f0f083c040108502a0108100000a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000[144 bytes omitted]
    | Sending packet: $m8018748,4#41...Ack
    | Packet received: 1eff2fe1
    | Sending packet: $qfThreadInfo#bb...Ack
    | Packet received: m1
    | Sending packet: $qsThreadInfo#c8...Ack
    | Packet received: l
    | Sending packet: $m8012a50,4#5e...Ack
    | Packet received: 700020e1
    | gdbarch_breakpoint () at arm-gdbstub.c:290
    | 290	arm-gdbstub.c: No such file or directory.
    | Sending packet: $qSymbol::#5b...Ack
    | Packet received:
    | Packet qSymbol (symbol-lookup) is NOT supported
    | (gdb) b test_simple
    | Sending packet: $m8010500,40#5b...Ack
    | Packet received: 00b08de200f020e300d08be204b09de41eff2fe104b02de500b08de200f020e300d08be204b09de41eff2fe100482de904b08de230d04de20030a0e308300be5
    | Sending packet: $m8010538,4#36...Ack
    | Packet received: 0030a0e3
    | Breakpoint 1 at 0x8010538: file simple.adb, line 16.
    | (gdb) cont
    | Continuing.
    | Sending packet: $Z0,8010538,4#7f...Ack
    | Packet received:
    | Packet Z0 (software-breakpoint) is NOT supported
    | Sending packet: $m8010538,4#36...Ack
    | Packet received: 0030a0e3
    | Sending packet: $X8010538,0:#57...Ack
    | Packet received:
    | binary downloading NOT supported by target
    | Sending packet: $M8010538,4:fedeffe7#4c...Ack
    | Packet received: OK
    | Sending packet: $vCont?#49...Ack
    | Packet received: vCont;c;s;C;S
    | Packet vCont (verbose-resume) is supported
    | Sending packet: $vCont;c#a8...Ack
    | Packet received: T050f:38050108;0d:407f0f08;thread:1;
    | Sending packet: $qfThreadInfo#bb...Ack
    | Packet received: m1
    | Sending packet: $qsThreadInfo#c8...Ack
    | Packet received: l
    | Sending packet: $M8010538,4:0030a0e3#3c...Ack
    | Packet received: OK
    | 
    | Breakpoint 1, Sending packet: $m8010538,4#36...Ack
    | Packet received: 0030a0e3
    | simple.test_simple () at simple.adb:16
    | 16	      A : Integer   := 0;
    | (gdb) n
    | Sending packet: $g#67...Ack
    | Packet received: 4851020860510208010000004450020800000000000000000000000000000000000000000000000000000000747f0f0825000000407f0f08b405010838050108100000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000[144 bytes omitted]
    | Sending packet: $m8018748,4#41...Ack
    | Packet received: 1eff2fe1
    | Sending packet: $M8018748,4:fedeffe7#57...Ack
    | Packet received: OK
    | Sending packet: $m8010538,4#36...Ack
    | Packet received: 0030a0e3
    | Sending packet: $m8010538,4#36...Ack
    | Packet received: 0030a0e3
    | Sending packet: $m801053c,4#61...Ack
    | Packet received: 08300be5
    | Sending packet: $m8010538,4#36...Ack
    | Packet received: 0030a0e3
    | Sending packet: $m8010538,4#36...Ack
    | Packet received: 0030a0e3
    | Sending packet: $m8010538,4#36...Ack
    | Packet received: 0030a0e3
    | Sending packet: $m801053c,4#61...Ack
    | Packet received: 08300be5
    | Sending packet: $M801053c,4:fedeffe7#77...Ack
    | Packet received: OK
    | Sending packet: $vCont;c:1#13...Ack
    | Packet received: T050f:3c050108;0d:407f0f08;thread:1;
    | Sending packet: $M801053c,4:08300be5#72...Ack
    | Packet received: OK
    | Sending packet: $m8010538,4#36...Ack
    | Packet received: 0030a0e3
    | Sending packet: $M8010538,4:fedeffe7#4c...Ack
    | Packet received: OK
    | Sending packet: $g#67...Ack
    | Packet received: 4851020860510208010000000000000000000000000000000000000000000000000000000000000000000000747f0f0825000000407f0f08b40501083c050108100000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000[144 bytes omitted]
    | Sending packet: $m801053c,4#61...Ack
    | Packet received: 08300be5
    | Sending packet: $m801053c,4#61...Ack
    | Packet received: 08300be5
    | Sending packet: $m8010540,4#2f...Ack
    | Packet received: 0030a0e3
    | Sending packet: $m801053c,4#61...Ack
    | Packet received: 08300be5
    | Sending packet: $m801053c,4#61...Ack
    | Packet received: 08300be5
    | Sending packet: $m801053c,4#61...Ack
    | Packet received: 08300be5
    | Sending packet: $m8010540,4#2f...Ack
    | Packet received: 0030a0e3
    | Sending packet: $M8010540,4:fedeffe7#45...Ack
    | Packet received: OK
    | Sending packet: $vCont;c#a8...Ack
    | Packet received: T050f:40050108;0d:407f0f08;thread:1;
    | Sending packet: $M8010540,4:0030a0e3#35...Ack
    | Packet received: OK
    | Sending packet: $m8010540,4#2f...Ack
    | Packet received: 0030a0e3
    | Sending packet: $g#67...Ack
    | Packet received: 4851020860510208010000000000000000000000000000000000000000000000000000000000000000000000747f0f0825000000407f0f08b405010840050108100000200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000[144 bytes omitted]
    | Sending packet: $M8018748,4:1eff2fe1#eb...Ack
    | Packet received: OK
    | Sending packet: $qfThreadInfo#bb...Ack
    | Packet received: m1
    | Sending packet: $qsThreadInfo#c8...Ack
    | Packet received: l
    | Sending packet: $M8010538,4:0030a0e3#3c...Ack
    | Packet received: OK
    | 17	      B : Float     := 0.0;


  reply	other threads:[~2018-09-11 20:57 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-10 15:13 Joel Brobecker
2018-09-10 17:28 ` Tom Tromey
2018-09-10 17:43   ` Joel Brobecker
2018-09-10 18:39     ` [RFA v2] " y
2018-09-10 20:01       ` Simon Marchi
2018-09-10 20:53         ` Tom Tromey
2018-09-11  8:56         ` Joel Brobecker
2018-09-11  9:58           ` Simon Marchi
2018-09-11 13:51             ` Joel Brobecker
2018-09-11 15:41           ` Tom Tromey
2018-09-11 21:17             ` Joel Brobecker
2018-09-14  0:47               ` Joel Brobecker
2018-09-14 10:57                 ` Simon Marchi
2018-11-01 21:44                 ` Joel Brobecker
2018-09-11  9:08 ` [RFA] " Pedro Alves
2018-09-11 11:04   ` Joel Brobecker
2018-09-11 11:27     ` Pedro Alves
2018-09-11 20:57       ` Joel Brobecker [this message]
2018-09-12 13:22         ` Pedro Alves
2018-09-14  0:38           ` Joel Brobecker

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=20180911205742.GB12573@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=guitton@adacore.com \
    --cc=palves@redhat.com \
    /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