From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: GSoC gdb-mi.el changes Date: Tue, 11 Aug 2009 07:17:59 -0700 (PDT) Message-ID: <200908111417.n7BEHxxu007130@godzilla.ics.uci.edu> References: <877hxdj0ai.fsf@sphinx.net.ru> <200908110453.n7B4reIS002762@godzilla.ics.uci.edu> <874ose7fgn.fsf@sphinx.net.ru> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1250000422 27179 80.91.229.12 (11 Aug 2009 14:20:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Aug 2009 14:20:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Dzhus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 11 16:20:15 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MasCy-00084i-OI for ged-emacs-devel@m.gmane.org; Tue, 11 Aug 2009 16:20:13 +0200 Original-Received: from localhost ([127.0.0.1]:37956 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MasCx-0004XY-1K for ged-emacs-devel@m.gmane.org; Tue, 11 Aug 2009 10:20:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MasCV-0004MT-Rb for emacs-devel@gnu.org; Tue, 11 Aug 2009 10:19:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MasCR-0004Js-0Y for emacs-devel@gnu.org; Tue, 11 Aug 2009 10:19:43 -0400 Original-Received: from [199.232.76.173] (port=34488 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MasCQ-0004Jn-Pf for emacs-devel@gnu.org; Tue, 11 Aug 2009 10:19:38 -0400 Original-Received: from barrelv2.ics.uci.edu ([128.195.1.114]:42305) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1MasCQ-0000Lo-B7 for emacs-devel@gnu.org; Tue, 11 Aug 2009 10:19:38 -0400 Original-Received: from godzilla.ics.uci.edu (godzilla.ics.uci.edu [128.195.10.101]) by barrelv2.ics.uci.edu (8.13.8+Sun/8.13.8) with ESMTP id n7BEI0HD010418; Tue, 11 Aug 2009 07:18:00 -0700 (PDT) Original-Received: (from dann@localhost) by godzilla.ics.uci.edu (8.13.8+Sun/8.13.6/Submit) id n7BEHxxu007130; Tue, 11 Aug 2009 07:17:59 -0700 (PDT) In-Reply-To: <874ose7fgn.fsf@sphinx.net.ru> (Dmitry Dzhus's message of "Tue, 11 Aug 2009 15:33:12 +0400") Original-Lines: 73 X-ICS-MailScanner-Information: Please contact the ISP for more information X-ICS-MailScanner-ID: n7BEI0HD010418 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-ICS-MailScanner-From: dann@godzilla.ics.uci.edu X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:114051 Archived-At: Dmitry Dzhus writes: > Dan Nicolaescu wrote: > > > Suggestion: don't show the -i=mi flag, users don't care about it (same > > way rgrep/lgrep don't show the -n flag they pass to grep) > > I'll do this. > > > Issues: > > echo 'int main () { printf ("Hello, World!\n");}' > t.c > > gcc t.c > > emacs -Q > > M-x gdb RET ./a.out RET > > > > error in process filter: Symbol's function definition is void: mapcar* > > > > M-x load-library RET cl RET > > M-x gdb RET ./a.out RET > > Uh-oh, that's very bad. Somehow I thought that mapcar* is a macro. I'll > rewrite some of my functions without mapcar* then. To see more compilation warnings, you can cd to the lisp directory and do: make recompile there. As of today you'll get some extra warnings about using `goto-line' too. > > > > Show the disassembly window > > > > b main > > > > A warning pops up: > > &"warning: GDB: Failed to set controlling terminal: Operation not permitted\n" How about this warning? > > > > si > > si > > si > > > > The cursor in the disassembly does not move correctly when single > > stepping and it does not update the stack frames all the time. > > (At the time of your writing, stepping was just broken; I installed some > fixes in CVS.) Still some problems, given the example above if in the middle of the execution I do: r yes (to restart execution) I get: Debugger aborted the disassembly frame disappears and the debug window does not work anymore. > Does it occur when you compile your target with -g, too? It works for the code, but not when going through library functions that don't have debug info (this worked fine in 22.1). > Unlike GDB's CLI `disassemble` command, to show disassembly code for you > program, MI needs to know either file:line information for the function > you're interested in, or its memory range. For the former your target > needs to be compiled with debugging information, and for the latter we > need to query GDB for function memory range, but this command is not > implemented in GDB/MI yet :( Given that you know the details here, can you please file a gdb bug? What do other GDB/MI front-ends do in this situation?