This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Crash of GDB with gdbserver btrace enabled [Re: [patch v9 00/23] branch tracing support for Atom]
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