X-Spam-Check-By: sourceware.org
Date: Tue, 14 Nov 2006 19:19:21 -0800
From: Gordon Prieur <Gordon DOT Prieur AT Sun DOT COM>
Subject: Cygwin gdb and signals
To: GDB Users <gdb AT sourceware DOT org>, Cygwin <cygwin AT cygwin DOT com>
Cc: Gordon Prieur <Gordon DOT Prieur AT Sun DOT COM>
Message-id: <455A8739.50108@Sun.COM>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
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

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:-).

Thanks,
Gordon


--
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/