This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Stopping reverse debugging behaves differently with btrace


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]