X-Spam-Check-By: sourceware.org Date: Tue, 14 Nov 2006 19:19:21 -0800 From: Gordon Prieur Subject: Cygwin gdb and signals To: GDB Users , Cygwin Cc: Gordon Prieur 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@cygwin.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.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/