Date: Wed, 15 Nov 2006 00:01:09 -0500
From: Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Cygwin gdb and signals
Message-ID: <20061115050109.GA25952@trixie.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <455A8739 DOT 50108 AT Sun DOT COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <455A8739.50108@Sun.COM>
User-Agent: Mutt/1.5.11
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

On Tue, Nov 14, 2006 at 07:19:21PM -0800, Gordon Prieur wrote:
>Hi,
>
>I've got several questions relating to gdb (as distribited by
>Cygwin.com) for Windows.  I'm the team lead for the NetBeans C/C++
>Developer pack (C/C++ support on NetBeans).  We're doing a gdb-based
>debug module and I've got some questions pertaining to signal handling
>and the exception stack we get when we interrupt the debuggee.
>
>First off, when my signal is received, gdb stops and the stack looks
>like its some kind of exception stack (no user calls).  Is there anyway
>to see the user stack while stopped in this exception/signal stack?  My
>concern is that most of my users won't understand why they see a stack
>trace without any of their calls in it.  A combined stack (with some
>kind of separator) would be more beneficial to novice users.  If the
>regular stack is available, I can tack them together and deliver this
>to my users.
>
>The other question is about input being reentrant.  On Unix, if I
>interrupt a system call (specificaly a read), when I resume its after
>the syscall.  What I'm getting (its mostly an issue for interrupted
>input) is the read is resumed and the program continues to be blocked.
>Since the user can't (at least with my current understanding of gdb and
>cygwin) see their data, it basically means the interrupt is useless
>(they can't see their stack, see their data, or modify their
>environment in any useful way).  And after continuing (step or
>continue) they're still blocked waiting for input.  At least to me (a
>long-time Unix developer), this is very counter intuitive.
>
>Any help on either stack manipulation or making syscalls non-reentrant
>would be appreciated.  My current plan is to show the user this
>exception stack (which they'll think is a bug) and resume execution
>with the blocked input (which they'll also think is a bug:-).

Cygwin's gdb doesn't really understand Cygwin signals that well.  I added
some prelimary code a while ago but it is not anywhere close to being as
functional as linux.

If you receive a Windows signal, you are likely to be in another thread
since Windows starts a separate thread to deal with signals like CTRL-C
and, so, the stack frame will reflect that.  If the main thread is
blocked in a Windows system call then you won't get much information
from the backtrace because Windows doesn't store stack frames.  If the
main thread is blocking in a Cygwin function (which is unlikely since
the only way Cygwin can really block is in a Windows function) then the
stack frames will not be correct in most cases since Cygwin messes with
the stack to handle its own signals.

So, sorry to say that the situation with gdb/cygwin/signals is really not
very useful.

cgf

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