From: "Metzger, Markus T" <markus.t.metzger@intel.com>
To: Marc Khouzam <marc.khouzam@ericsson.com>,
"Pedro Alves (palves@redhat.com)" <palves@redhat.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: RE: Stopping reverse debugging behaves differently with btrace
Date: Mon, 13 Jun 2016 15:21:00 -0000 [thread overview]
Message-ID: <A78C989F6D9628469189715575E55B23332ED1C5@IRSMSX104.ger.corp.intel.com> (raw)
In-Reply-To: <A78C989F6D9628469189715575E55B23332EC30D@IRSMSX104.ger.corp.intel.com>
Hi Marc, Pedro,
> > > I find it strange though that when turning off record, every indication
> > > to the user is that we are still at line 150, when in reality, GDB is
> > > effectively back at line 200. This is particularly noticeable in a
> > > frontends when execution jumps (unexpectedly) when the first step
> > > is requested.
> > >
> > > Variables also remain unavailable until the next step (or strangely,
> > > until I send some register command).
> > >
> > > I was wondering if GDB should reset its execution to the proper
> > > place upon a 'record stop' for btrace? And notify the frontend of
> > > that change.
> >
> > I agree. I'll look into it. Thanks for pointing it out.
>
> I have a fix for the missing STOP_PC update which may result in all
> kinds of strange effects. The front-end notification sounds more
> tricky, though.
Looks like the trick is to clear the proceed state of the moving thread
before calling the normal-stop observer. I'm omitting the about-to-
proceed notification and I'm not calling proceed or normal_stop.
I hope I'm not breaking something.
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="/lib64/libc.so.6"},thread-id="1",stopped-threads="all",core="1"
^done
We can also invent a new stop-reason if necessary. 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",value="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",value="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
Marc, is this what you were expecting?
The CLI output for "record stop" needs more polishing. It currently prints the
updated source location for every replaying thread without indicating the thread
the output belongs to. Not sure how much output we really want on the CLI for
"record stop".
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
next prev parent reply other threads:[~2016-06-13 15:21 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 [this message]
2016-06-13 17:43 ` Marc Khouzam
2016-06-14 7:40 ` Metzger, Markus T
2016-06-17 11:48 ` Metzger, Markus T
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=A78C989F6D9628469189715575E55B23332ED1C5@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