From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: nickrob@snap.net.nz (Nick Roberts) Newsgroups: gmane.emacs.devel Subject: Re: GDB on Mac is (NOT) Broken Date: Mon, 22 Mar 2010 15:32:34 +1300 Message-ID: <19366.54978.906314.549908@totara.tehura.co.nz> References: <19357.53872.672127.600861@totara.tehura.co.nz> <19359.5799.721358.312552@totara.tehura.co.nz> <19365.49601.379093.424303@totara.tehura.co.nz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1269287434 6902 80.91.229.12 (22 Mar 2010 19:50:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 22 Mar 2010 19:50:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: YAMAMOTO Mitsuharu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 22 20:50:29 2010 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.69) (envelope-from ) id 1Ntnds-0006Lr-Rb for ged-emacs-devel@m.gmane.org; Mon, 22 Mar 2010 20:50:29 +0100 Original-Received: from localhost ([127.0.0.1]:38137 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ntnds-0005oQ-77 for ged-emacs-devel@m.gmane.org; Mon, 22 Mar 2010 15:50:28 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ntndk-0005lb-JF for emacs-devel@gnu.org; Mon, 22 Mar 2010 15:50:20 -0400 Original-Received: from [140.186.70.92] (port=55877 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ntndf-0005c5-E7 for emacs-devel@gnu.org; Mon, 22 Mar 2010 15:50:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ntndd-0000v0-Tr for emacs-devel@gnu.org; Mon, 22 Mar 2010 15:50:15 -0400 Original-Received: from mx.southnet.co.nz ([202.37.101.20]:54015 helo=viper.snap.net.nz) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ntndd-0000uN-KP for emacs-devel@gnu.org; Mon, 22 Mar 2010 15:50:13 -0400 Original-Received: from totara (143.60.255.123.dynamic.snap.net.nz [123.255.60.143]) by viper.snap.net.nz (Postfix) with ESMTP id C38453DAB56; Mon, 22 Mar 2010 15:32:36 +1300 (NZDT) Original-Received: by totara (Postfix, from userid 1000) id E61A1C172; Mon, 22 Mar 2010 15:32:34 +1300 (NZDT) In-Reply-To: X-Mailer: VM 7.19 under Emacs 22.2.1 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 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:122507 Archived-At: > I tried your code with removing the line (setq gdb-version "pre-6.4") > in gdb-apple-test, because set-process-coding-system should go to the > then-clause. Yes, it shouldn't be there. Sorry, it was just a cut and paste error from gdb-get-version. > (I'm not familiar with this at all, but should Apple versions be > regarded as pre-6.4? On Mac OS X 10.6, the first line looks like `GNU > gdb 6.3.50-20050815 (Apple version gdb-1346) (Fri Sep 18 20:40:51 UTC > 2009)', and `server interpreter mi -stack-info-frame' results in > `^error,msg="No registers."'.) Apple generally merge in FSF GDB changes so they are broadly similar. The pre-6.4 tag is just a crude way of finding what MI features GDB will have and does this by testing if -stack-info-frame is present. Your actual version is actually < 6.4 but I think we can leave this as it will be correct to a first approximation. > It avoided the hang in completion, but in the > " *partial-output-yourprog*" buffer, ^M was already added because > "server show version\n" was executed after "server interpreter mi > -stack-info-frame\n" which triggered the addition of ^M. How about > checking the result of "server show version\n" before "server > interpreter mi -stack-info-frame\n"? Sure. I don't think it matters to other platforms where it goes. I think it should go in both the branch and the trunk but I defer to Stefan or Cyd on the former. -- Nick http://users.snap.net.nz/~nickrob