Re: Crash of GDB with gdbserver btrace enabled [Re: [patch v9 00/23] branch tracing support for Atom]

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Thu, 07 Mar 2013 16:21:58 +0100, Metzger, Markus T wrote:
> I assume you mean from a new target to_teardown_btrace method and not
> from btrace's to_close.  That's where it currently is and where we want it moved
> away from.
> 
> 
> To summarize:
> 1. add a new target method to_teardown_btrace
> 1.1. disable btrace for native targets
> 1.2. only clear the trace and free the btrace_target_info for remote targets
> 2. call target_teardown_btrace from clear_thread_inferior_resources
> 3. add new target method to_stop_recording
> 3.1. disable btrace in record-btrace target
> 3.2. undefined in other record targets - may later split record-full's to_close.

> 4. call target_stop_recording in "record stop" before unpushing the record target

Yes.


> 5. call target_stop_recording in record_mourn_inferior before unpushing the record target

I believe it is safer no, gdbserver will take care of it and it may be
dangerous during some teardown situations.


> 6. call target_stop_recording in record_detach before unpushing the record target

Yes.


> 7. call target_stop_recording in record_disconnect before unpushing the record target

Currently probably yes.

But one would not have to.  gdbserver then can continue btracing the inferior
and one can reconnect with new gdb later and fetch that information.  But that
would require detecing upon new connection whether btrace is running in remote
target and pushing gdb btrace target if so.


> 8. call target_stop_recording in record_kill before unpushing the record target

Also better no like in 5.


> 9. remove btrace disable from record_btrace_to_close
> 
> This will make record_btrace_to_close empty.  I must not touch the per-thread
> btrace configuration since this is needed later in 2.


Great summary, thanks.


Jan