RE: [PATCH] btrace: diagnose "record btrace pt" without libipt

["Metzger, Markus T" <markus.t.metzger@intel.com>]

> -----Original Message-----
> From: Pedro Alves [mailto:palves@redhat.com]
> Sent: Friday, November 20, 2015 2:12 PM
> To: Metzger, Markus T
> Cc: gdb-patches@sourceware.org
> Subject: Re: [PATCH] btrace: diagnose "record btrace pt" without libipt
> 
> On 11/20/2015 12:11 PM, Metzger, Markus T wrote:
> 
> > The record target is popped off the target stack on disconnect.  This
> disables
> > branch tracing.  The below log is for BTS but the logic is the same for PT.
> > 	Sending packet: $Qbtrace:off#37...Packet received: OK
> 
> >
> > After reconnecting, you need to enable btrace again.
> 
> I see.  But then it sounds like we'll have the problem if the connection
> drops unexpectedly -- gdb won't be able to tell the server to
> disable Qbtrace.  I guess the easiest way to emulate is kill gdb:
> 
>  #1 - enable btrace pt
>  #2 - connection is terminated unexpectedly / kill gdb
>  #3 - reconnect to gdbserver
> 
> a) Does the new gdb get out of sync and confused?

Yes.

GDB doesn't recognize that the remote agent is already tracing.
This also prevents enabling branch tracing after reconnect.

    (gdb) info rec
    No record target is currently active.
    (gdb) rec b
    [record-btrace] open
    [record-btrace] open
    [btrace] enable thread 1 (Thread 141484)
    Sending packet: $Qbtrace-conf:bts:size=0x10000#e3...Packet received: OK
    Sending packet: $Qbtrace:bts#45...Packet received: E.Btrace already enabled.
    Could not enable branch tracing for Thread 141484: Btrace already enabled.
    (gdb) info rec
    No record target is currently active.
    (gdb)


Thanks for pointing this out.  Let's try to fix it...

Handling the "E.Btrace already enabled" error in remote.c shouldn't be too hard.
This would at least allow another "record btrace" after reconnect - and it should
keep the trace logs.  This takes the same code path as a new enable so the check
in this patch should suffice.

A non-PT enabled GDB would try to fall back to BTS, though, so we could either
implicitly disable PT in the target to allow it or give an error, which again leaves
branch tracing unusable in this GDB session.  But it would keep the trace logs if
the user accidentally chose the wrong GDB for reconnecting.

It would be nice if GDB could detect that record btrace is already enabled and push
the record-btrace target automatically.  I guess this requires some indication about
the record status from gdbserver.  Is there some other target that does this automatic
push on (re-)connect that I could use as reference?

This still leaves the question how GDB should behave if it doesn't support the tracing
format that's already enabled in the GDBserver it just connected to.

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