From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Gdb in emacs 24 Date: Wed, 19 Oct 2011 10:35:30 -0400 Message-ID: References: <87k481gma9.fsf@ginnungagap.bsc.es> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1319034952 25344 80.91.229.12 (19 Oct 2011 14:35:52 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2011 14:35:52 +0000 (UTC) Cc: Tom Tromey , David Reitter , "emacs-devel@gnu.org devel" To: =?iso-8859-1?Q?Llu=EDs?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 19 16:35:44 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RGXFA-0008WJ-Ar for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2011 16:35:44 +0200 Original-Received: from localhost ([::1]:35432 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGXF9-0002Z5-Ju for ged-emacs-devel@m.gmane.org; Wed, 19 Oct 2011 10:35:43 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:39345) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGXF2-0002YJ-Po for emacs-devel@gnu.org; Wed, 19 Oct 2011 10:35:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RGXEy-0008Qg-G2 for emacs-devel@gnu.org; Wed, 19 Oct 2011 10:35:36 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:42431 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RGXEy-0008QX-84 for emacs-devel@gnu.org; Wed, 19 Oct 2011 10:35:32 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAH7fnk5MCqLO/2dsb2JhbABEqHOBBoFuAQEEAVYjBQsLNBIUGA0kiBO0TIgbBKEshEU X-IronPort-AV: E=Sophos;i="4.69,372,1315195200"; d="scan'208";a="143052998" Original-Received: from 76-10-162-206.dsl.teksavvy.com (HELO pastel.home) ([76.10.162.206]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 19 Oct 2011 10:35:30 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 6A30458CEC; Wed, 19 Oct 2011 10:35:30 -0400 (EDT) In-Reply-To: <87k481gma9.fsf@ginnungagap.bsc.es> (=?iso-8859-1?Q?=22Llu=ED?= =?iso-8859-1?Q?s=22's?= message of "Wed, 19 Oct 2011 15:10:06 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:145333 Archived-At: > There seems to be no obvious command in gdb to get the current > interpreter. The closest match is routine 'top_level_interpreter', but > there is no command to get that. How 'bout some way to just check whether `mi' is the current interpreter. It doesn't have to be a dedicated command, just a command which will reliably behave differently (e.g. return some recognizable value if `mi' is used, and return an error if not). That would at least let us provide a clear error message to the user. > create a new command (e.g., "set interpreter") to set the current > interpreter This is ambiguous if there's an `interpreter' variable in the currently debugged program. But, yes, such a command would be very welcome, especially if it fails reliably in GDB versions that don't support it. > Even if not optimal, the cost of setting the interpreter on > a per-command basis (as opposed to setting the current interpreter > for all future commands) should not have a noticeable impact > on performance. At least for commands typed interactively by the user, that's true. Don't know how many commands are sent by gdb-mi.el so I don't know if the impact could be noticeable there, but I expect it shouldn't be a problem. OTOH I wonder if macros defined for example in .gdbinit would go through `mi' or not. > * What to do if the user ever passed "-i=tui" in the gdb cmdline > (which seems to make MI unusable even through "interpreter-exec"). If we can test for `mi', we can signal a clear error message to the user. > This can be worked around by silently appending any other interface > option in the cmdline when starting gdb. No. The whole reason why "--i=mi" and "--annotate=3" is explicitly present in the minibuffer prompt is because adding those options silently makes it impossible to use GUD with setups where gdb is run indirectly (e.g. the command might be "make debug" rather than "gdb prog", so silently adding "--i=mi" is not an option). > * Should user-issued commands in the gdb buffer use the mi or console > interpreter? gdb-mi.el wants those commands to go through `mi' as well. Stefan