From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14197 invoked by alias); 7 Mar 2013 15:46:18 -0000 Received: (qmail 14187 invoked by uid 22791); 7 Mar 2013 15:46:17 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 Mar 2013 15:46:08 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r27Fk6H3032520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 7 Mar 2013 10:46:06 -0500 Received: from host2.jankratochvil.net (ovpn-116-50.ams2.redhat.com [10.36.116.50]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r27Fk1ih001990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 7 Mar 2013 10:46:04 -0500 Date: Thu, 07 Mar 2013 15:46:00 -0000 From: Jan Kratochvil To: "Metzger, Markus T" Cc: "gdb-patches@sourceware.org" , "markus.t.metzger@gmail.com" , "Himpel, Christian" , Pedro Alves Subject: Re: Crash of GDB with gdbserver btrace enabled [Re: [patch v9 00/23] branch tracing support for Atom] Message-ID: <20130307154601.GA15088@host2.jankratochvil.net> References: <20130307090632.GA11095@host2.jankratochvil.net> <20130307101350.GA14969@host2.jankratochvil.net> <20130307120644.GA21253@host2.jankratochvil.net> <20130307144440.GA477@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-03/txt/msg00299.txt.bz2 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