--- Begin Message ---
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sun, 20 Jan 2002 19:48:32 -0500
- Subject: Re: patch to ignore SIGPWR and SIGXCPU (used by pthreads)
- References: <3C49D806.4050500@bothner.com>
> Index: infrun.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/infrun.c,v
> retrieving revision 1.50
> diff -u -p -r1.50 infrun.c
> --- infrun.c 2002/01/17 22:15:17 1.50
> +++ infrun.c 2002/01/19 20:17:19
> @@ -4298,6 +4298,12 @@ of the program stops.", &cmdlist);
> signal_stop[TARGET_SIGNAL_WINCH] = 0;
> signal_print[TARGET_SIGNAL_WINCH] = 0;
>
> + /* These are used for pthread context switching, used by libgcj. */
> + signal_stop[TARGET_SIGNAL_PWR] = 0;
> + signal_print[TARGET_SIGNAL_PWR] = 0;
> + signal_stop[TARGET_SIGNAL_XCPU] = 0;
> + signal_print[TARGET_SIGNAL_XCPU] = 0;
> +
> /* These signals are used internally by user-level thread
> implementations. (See signal(5) on Solaris.) Like the above
> signals, a healthy program receives and handles them as part of
>
Per, can you please expand a little on the history of this choice of
signals?
SIGXCPU terminate process CPU time limit exceeded (see
SIGPWR discard signal power failure/restart
I don't know that it is right to always silence/ignore these signals
when not all systems are using pthreads/libgcj. This is even more
interesting given that just below we have:
/* These signals are used internally by user-level thread
implementations. (See signal(5) on Solaris.) Like the above
signals, a healthy program receives and handles them as part of
its normal operation. */
signal_stop[TARGET_SIGNAL_LWP] = 0;
signal_print[TARGET_SIGNAL_LWP] = 0;
signal_stop[TARGET_SIGNAL_WAITING] = 0;
signal_print[TARGET_SIGNAL_WAITING] = 0;
signal_stop[TARGET_SIGNAL_CANCEL] = 0;
signal_print[TARGET_SIGNAL_CANCEL] = 0;
puzzled,
Andrew
--- End Message ---