libs/newlib-cygwin
libs
/
newlib-cygwin
mirror of git://sourceware.org/git/newlib-cygwin.git
4
0
Fork 0
Code Issues Projects Releases Wiki Activity

faq: Update FAQ question and answer about gdb and signals 

* faq-programming.xml: Update question and answer about gdb and signals.

Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
This commit is contained in:
Jon Turney 2016-01-14 17:44:18 +00:00
parent d2216272f5
commit 9c8a6e5646
1 changed files with 13 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
winsup/doc/faq-programming.xml
View File

@ -859,15 +859,22 @@ on using <literal>strace</literal>, see the Cygwin User's Guide.
</answer></qandaentry>
<qandaentry id="faq.programming.gdb-signals">
<question><para>Why doesn't gdb handle signals?</para></question>
<question><para>How does gdb handle signals?</para></question>
<answer>
<para>Unfortunately, there is only minimal signal handling support in gdb
currently. Signal handling only works with Windows-type signals.
SIGINT may work, SIGFPE may work, SIGSEGV definitely does. You cannot
'stop', 'print' or 'nopass' signals like SIGUSR1 or SIGHUP to the
process being debugged.
<para>
gdb maps known Windows exceptions to signals such as SIGSEGV, SIGFPE, SIGTRAP,
SIGINT and SIGILL. Other Windows exceptions are passed on to the handler (if
any), and reported as an unknown signal if an unhandled (second chance)
exception occurs.
</para>
<para>
There is also an experimental feature to notify gdb of purely Cygwin signals
like SIGABRT, SIGHUP or SIGUSR1. This currently has some known problems, for
example, single-stepping from these signals may not work as expected.
</para>
</answer></qandaentry>
<qandaentry id="faq.programming.linker">