X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-1.4 required=5.0	tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Message-ID: <4F9E8B0E.9000603@cs.utoronto.ca>
Date: Mon, 30 Apr 2012 08:52:30 -0400
From: Ryan Johnson <ryan DOT johnson AT cs DOT utoronto DOT ca>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: gdb hanging in emacs
References: <4F9C4BD1 DOT 1040401 AT cs DOT utoronto DOT ca> <4F9D39C4 DOT 4010904 AT cornell DOT edu> <20120429221905 DOT GB27448 AT ednor DOT casa DOT cgf DOT cx>
In-Reply-To: <20120429221905.GB27448@ednor.casa.cgf.cx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

On 29/04/2012 6:19 PM, Christopher Faylor wrote:
> On Sun, Apr 29, 2012 at 08:53:24AM -0400, Ken Brown wrote:
>> On 4/28/2012 3:58 PM, Ryan Johnson wrote:
>>> Hi all,
>>>
>>> I'm trying to use a home-built cross-gdb to do some remote debugging
>>> over tcp, but running gdb inside emacs doesn't work. M-x gud-gdb works
>>> fine, it's something wrong with the emacs integration. Unlike past times
>>> this has come up, the issue doesn't seem to be related to seg faults;
>>> the closest match I can find is from the emacs mailing list a while back
>>> [1], and involves a so-called "phase error." Basically, a large fraction
>>> of commands cause gud to hang in "[initializing...]" state for minutes
>>> or longer, apparently because it doesn't see what it expects and gets
>>> confused.
>>>
>>> The workaround to use 'file $BINARY' instead of specifying it at the
>>> command line avoids one problem, but simple things like 'set remotebaud
>>> 115200' also hang (unless added to a .gdbinit), and actually attempting
>>> to attach to the remote process similarly hangs forever in the
>>> initializing state. There is no CPU or disk utilization, and the command
>>> can't be interrupted with C-c C-c (though that does make it report a
>>> phase error before going back to hung). In some cases the "hang"
>>> resolves itself after about two minutes -- usually for simple commands
>>> like `set remotebaud' -- but more often than not, it's permanent. The
>>> behavior is also somewhat erratic, in the sense that the specific set of
>>> commands that hangs changes slowly over time and/or between invocations.
>>>
>>> So, two questions:
>>>
>>> 1. Has anyone else seen this, and if so, do they have any advice or
>>> workarounds?
>>>
>>> 2. Cygwin's official gdb doesn't seem to have any of these problems,
>>> though I can't test most of the commands, since it can't attach to the
>>> remote process. Is there some set of cygwin-specific patches I could
>>> borrow that make all the difference, or is my observation just coincidence?
>> Can't you just download the source for Cygwin's gdb and use that as the
>> starting point for your home-built cross-gdb?
> There is nothing magical in the Cygwin gdb source.  Any recent gdb source
> should be perfectly usable.
OK, I was just hoping there was some easy fix.

Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple