From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22666 invoked by alias); 25 Mar 2013 19:12:38 -0000 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 Received: (qmail 22627 invoked by uid 89); 25 Mar 2013 19:12:31 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 25 Mar 2013 19:12:31 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r2PJCPs4004775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Mar 2013 15:12:25 -0400 Received: from host2.jankratochvil.net (ovpn-116-100.ams2.redhat.com [10.36.116.100]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r2PJCKxV012161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 25 Mar 2013 15:12:23 -0400 Date: Tue, 26 Mar 2013 00:15:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: "Metzger, Markus T" , "gdb-patches@sourceware.org" , "markus.t.metzger@gmail.com" , "Himpel, Christian" Subject: Re: [patch] Code cleanup: Remove parameter quitting [Re: Crash of GDB with gdbserver btrace enabled] Message-ID: <20130325191219.GA30661@host2.jankratochvil.net> References: <20130307101350.GA14969@host2.jankratochvil.net> <20130307120644.GA21253@host2.jankratochvil.net> <5138AE4C.3060801@redhat.com> <20130318170643.GA15625@host2.jankratochvil.net> <514758DA.2060905@redhat.com> <20130318192604.GA2786@host2.jankratochvil.net> <51477828.30000@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51477828.30000@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-03/txt/msg00950.txt.bz2 Hi Pedro, I do not plan to do any changes mentioned below, it is just an affirmation future development has an agreed upon design. On Mon, 18 Mar 2013 21:25:12 +0100, Pedro Alves wrote: > Other Debug APIs may > require a "debug_api_foo_close ()" call that actually results in traffic, > to properly release the reference to the debug api library. remote-mips.c > seems to be doing something like that, and it's the sort of code that > could hang/block for a while, so it seems to me like the original intent > of QUITTING would be to handle _that_ kind of blocking. If "QUITTING", > GDB is quitting, so don't bother being nice to your debug API library, > if that takes long and hang a fast "quit" experience, as the whole GDB > process is going away anyway. Otherwise, if not QUITTING, take care to > clean up properly, because the user may want to spawn a new debug session, > in the same GDB process. Do you think that the mips_close packet communication should have been done only if !QUITTING? This would mean the GDB "quit" command would leave the MIPS target in some inconsistent state, possibly not ready for a new connection later (assuming the MIPS target cannot accept new connection without previous mips_exit_debug packets). quit_command already does disconnect_tracing and then (target_detach or target_kill) before target_close. I miss target_disconnect in quit_command. This could do the packet communication part of mips_close. mips_close then would not communicate anything so that mips_close is always safe in some broken communication cases. And even the quit_command call of disconnect_tracing could be then removed and disconnect_tracing called only from remote_disconnect. That target_detach or target_kill could be kept only for compatibility with old targets (if there are any), normal targets should do target_detach/target_kill automatically from to_disconnect. > Yes, it certainly should _not_ send "D", as that's not RSP's "close > connection packet", it has more meaning than that -- it makes gdbserver itself > detach from the inferior, for example. I see I have mistaken "D". So remote_close does not need to do any packet communication thanks to the gdbserver protocol design. > Releasing > resources in the backend debug API side (the remote stub, in the RSP case) > related to the inferior IMO (breakpoints, etc.) should not be done in > to_close. If necessary, these resources should be released through some > other mechanism or target hook. E.g., removing breakpoints in always inserted > mode could be done even as late as in to_detach, but not in to_close. OK, thanks for clarification of the design. Jan