drew
/
acadia-newlib
1
0
Fork 0
Code Issues Pull Requests Packages 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> </answer></qandaentry>
<qandaentry id="faq.programming.gdb-signals"> <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> <answer>
<para>Unfortunately, there is only minimal signal handling support in gdb <para>
currently. Signal handling only works with Windows-type signals. gdb maps known Windows exceptions to signals such as SIGSEGV, SIGFPE, SIGTRAP,
SIGINT may work, SIGFPE may work, SIGSEGV definitely does. You cannot SIGINT and SIGILL. Other Windows exceptions are passed on to the handler (if
'stop', 'print' or 'nopass' signals like SIGUSR1 or SIGHUP to the any), and reported as an unknown signal if an unhandled (second chance)
process being debugged. exception occurs.
</para> </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> </answer></qandaentry>
<qandaentry id="faq.programming.linker"> <qandaentry id="faq.programming.linker">