From: "Metzger, Markus T" <markus.t.metzger@intel.com>
To: Marc Khouzam <marc.khouzam@ericsson.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>,
"Pedro Alves (palves@redhat.com)" <palves@redhat.com>
Subject: RE: Stopping reverse debugging behaves differently with btrace
Date: Fri, 17 Jun 2016 11:48:00 -0000 [thread overview]
Message-ID: <A78C989F6D9628469189715575E55B23332EE56F@IRSMSX104.ger.corp.intel.com> (raw)
In-Reply-To: <A78C989F6D9628469189715575E55B23332ED499@IRSMSX104.ger.corp.intel.com>
Hi Marc,
> > > GDB is now sending a normal-stop without stop reason on every record
> > > goto command:
> > >
> > > (gdb)
> > > rec go 12
> > > &"rec go 12\n"
> > > ~"0x00007ffff762c671 in _dl_addr () from /lib64/libc.so.6\n"
> > >
> >
> *stopped,frame={addr="0x00007ffff762c671",func="_dl_addr",args=[],from="/li
> > b64/libc.so.6"},thread-id="1",stopped-threads="all",core="1"
> > > ^done
> >
> > I'd have to try it to be sure, but this looks right. If a record command
> > changes the line at which GDB is stopped, the frontend needs a *stopped
> > event like that. Sending multiple *stopped events for the same thread without
> > a *running event in between may be a new case; I don't know if that is
> > something
> > frontends are supposed to be ready for. I'm almost certain Eclipse can handle
> > it though.
Eclipse Mars.2 seems to be OK with it.
> > > The record-btrace
> > > target also sends such a normal-stop notification on "record stop" for
> > > each replaying thread:
> > >
> > > (gdb)
> > > rec stop
> > > &"rec stop\n"
> > > ~"test (arg=0x0) at gdb.btrace/multi-thread-step.c:34\n"
> > > ~"34\t global = 42; /* bp.2 */\n"
> > >
> >
> *stopped,frame={addr="0x000000000040078a",func="test",args=[{name="arg",v
> > alue="0x0"}],file="gdb.btrace/multi-thread-
> step.c",fullname="gdb.btrace/multi-
> > thread-step.c",line="34"},thread-id="1",stopped-threads="all",core="1"
> > > ~"test (arg=0x0) at gdb.btrace/multi-thread-step.c:34\n"
> > > ~"34\t global = 42; /* bp.2 */\n"
> > >
> >
> *stopped,frame={addr="0x000000000040078a",func="test",args=[{name="arg",v
> > alue="0x0"}],file="gdb.btrace/multi-thread-
> step.c",fullname="gdb.btrace/multi-
> > thread-step.c",line="34"},thread-id="2",stopped-threads="all",core="1"
> > > ~"Process record is stopped and all execution logs are deleted.\n"
> > > =record-stopped,thread-group="i1"
> > > ^done
> >
> > That also seems right.
> > Eclipse does not yet support reverse debugging with non-stop, but we are
> > working on it.
>
> That's the output for stop-all. On "record stop" GDB is iterating over all threads to
> stop recording and I'm sending a notification for every thread that moved due to
> this.
Eclipse seems to be able to handle it but it may cause a thread switch. Plus this
causes lots of output on the CLI. I don't think we want that.
For stop-all mode, I changed this to send a single *stopped for the selected thread -
provided it is replaying. This works fine as long as the selected thread actually is
replaying. All threads are updated and we're not switching away from the selected
thread.
If the selected thread isn't replaying, however, GDB won't send a *stopped. This is
OK for the selected thread as its state didn't change, but it won't cause other threads
that had been replaying to be updated.
I added another *stopped event without thread information for that case. Eclipse
seems to be OK with it. We're not switching threads but other threads seem to be
updated correctly.
I pushed the series into users/mmetzger/record-goto-mi. Let me know what you think
and if this is working for you. I will send the patches out for review in a week or two.
Regards,
Markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
prev parent reply other threads:[~2016-06-17 11:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-07 20:13 Marc Khouzam
2016-06-08 6:41 ` Metzger, Markus T
2016-06-09 14:11 ` Metzger, Markus T
2016-06-13 15:21 ` Metzger, Markus T
2016-06-13 17:43 ` Marc Khouzam
2016-06-14 7:40 ` Metzger, Markus T
2016-06-17 11:48 ` Metzger, Markus T [this message]
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=A78C989F6D9628469189715575E55B23332EE56F@IRSMSX104.ger.corp.intel.com \
--to=markus.t.metzger@intel.com \
--cc=gdb@sourceware.org \
--cc=marc.khouzam@ericsson.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