Mail Archives: cygwin/2006/11/14/22:19:53
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/
- Raw text -