From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Revise etc/DEBUG documentation Date: Sat, 03 Sep 2016 14:31:02 +0300 Message-ID: <838tv9dxu1.fsf@gnu.org> References: <864m5xtgtf.fsf@realize.ch> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1472902360 19850 195.159.176.226 (3 Sep 2016 11:32:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Sep 2016 11:32:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: Alain Schneble Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 03 13:32:37 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bg9Bb-0004ZU-H8 for ged-emacs-devel@m.gmane.org; Sat, 03 Sep 2016 13:32:35 +0200 Original-Received: from localhost ([::1]:45761 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bg9BZ-0002yk-8R for ged-emacs-devel@m.gmane.org; Sat, 03 Sep 2016 07:32:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35323) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bg9A9-0002Mt-2A for emacs-devel@gnu.org; Sat, 03 Sep 2016 07:31:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bg9A5-0003qU-Sd for emacs-devel@gnu.org; Sat, 03 Sep 2016 07:31:05 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39343) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bg9A5-0003qP-QK; Sat, 03 Sep 2016 07:31:01 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3469 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bg9A4-0000IJ-HF; Sat, 03 Sep 2016 07:31:01 -0400 In-reply-to: <864m5xtgtf.fsf@realize.ch> (message from Alain Schneble on Sat, 3 Sep 2016 12:31:56 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207146 Archived-At: > From: Alain Schneble > Date: Sat, 3 Sep 2016 12:31:56 +0200 > > While studying how signals are handled in Emacs (both when run under a > POSIX system as well as MS-Windows) and also how GDB deals with them, I > thought it would be worth to revise the section 'Getting control to the > debugger' in etc/DEBUG to include some more information about how > signals can be used to interrupt Emacs debuggee and return control back > to GDB. > > Would you mind installing this patch? Any comments are welcome. Thanks. Frankly, I'm a bit confused after reading the changes. Some of them rephrase what was already in DEBUG, others rearrange existing text (and also rephrase it a bit), still others describe features that I either didn't understand or they will work only under specific circumstances. I guess I don't really understand the main idea behind the proposed changes. I also am not sure we should repeat here stuff that is basic GDB usage. Any such descriptions are bound to be incomplete and thus inaccurate. It is better to refer the readers to the GDB manual, if they are not already proficient. How about if we first add any missing information, and leave rephrasing for a separate patch? Or maybe just tell what you think is missing in the current version, and let's take it from there. Some specific comments and questions follow. > +When Emacs is running under a window system, reception of a SIGINT and > +SIGQUIT will cause it to terminate. It might therefore be useful to > +configure the 'handle' command for those signals to use 'nopass', to > +prevent Emacs from terminating on reception of such signals. I don't understand why is this useful. > +When using a window system, there is no reason for Emacs to handle C-g > +as a SIGINT, as keyboard input is processed by the window system's > +message pump. Hence, no signal is sent as a response to a C-g. This explains how Emacs works, but I'm not sure it belongs in DEBUG. > +When using X, type C-z at the window where Emacs is running under GDB, > +and it will stop Emacs just as it would stop any ordinary program. The "window where Emacs is running under GDB" part is IMO confusing: I couldn't figure out what window does this refer to. There might not be such a window at all, AFAIU. > +On MS-Windows, starting Emacs in its own separate terminal even when > +running as a GUI application will allow you to send a Ctrl-c or > +Ctrl-Break to the console. GDB treats them as a SIGINT, but Emacs > +won't terminate as it ignores these events. This also left me confused. First, what do you mean by "separate terminal" in this case? Up to here, when DEBUG says "terminal", it means "text terminal", but here you are talking about GUI sessions, so what is a "separate terminal" applicable to the GUI Emacs session on MS-Windows? Next, what do you mean by "send a Ctrl-c or +Ctrl-Break to the console"? What console is alluded to here? Finally, what does the "GDB treats them as a SIGINT, but Emacs won't terminate as it ignores these events" part want to tell? I couldn't figure that out. > +On MS-Windows, GDB will turn a C-c into a DebugBreakProcess call if > +Emacs is running in a separate terminal Here's the "separate terminal" thing once again. > or it will just ignore it > +otherwise, as the event will be received by Emacs anyway when running > +under the same terminal as GDB. This part is also confusing. And I wonder why the signal-process feature is not mentioned here. Thanks again for working on this.