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

[Pedro Alves <palves@redhat.com>]

On 11/20/2015 09:17 AM, Markus Metzger wrote:
> If GDB has been configured without libipt support, i.e. HAVE_LIBIPT is
> undefined, and is running on a system that supports Intel(R) Processor Trace,
> GDB will run into an internal error when trying to decode the trace.
> 
>     (gdb) record btrace
>     (gdb) s
>     usage (name=0x7fffffffe954 "fib-64")
>         at src/fib.c:12
>     12          fprintf(stderr, "usage: %s <num>\n", name);
>     (gdb) info record
>     Active record target: record-btrace
>     Recording format: Intel(R) Processor Trace.
>     Buffer size: 16kB.
>     gdb/btrace.c:971: internal-error: Unexpected branch trace format.
>     A problem internal to GDB has been detected,
>     further debugging may prove unreliable.
>     Quit this debugging session? (y or n)
> 
> This requires a system with Linux kernel 4.1 or later running on a 5th
> Generation Intel Core processor or later.
> 
> When trying to enable branch tracing, in addition to checking the target
> support for the requested branch tracing format, also check whether GDB
> supports. it.

BTW, this made me wonder what happens if you're remote debugging with
gdbserver, and then:

 #1 - enable btrace pt
 #2 - disconnect with "disconnect"
 #3 - restart gdb
 #4 - reconnect to gdbserver

- Does gdb sync the "btrace-enabled" state with the server?  Or does it get out
  of sync and confused?

- What if btrace pt was enabled on the inferior, and the gdb that reconnects
  in #4 above is compiled _without_ libipt?  Will "info record" still crash?

Thanks,
Pedro Alves