patch to ignore SIGPWR and SIGXCPU (used by pthreads)

patch to ignore SIGPWR and SIGXCPU (used by pthreads)

[Per Bothner]

[-- Attachment #1: Type: text/plain, Size: 322 bytes --]

Ok to check in?  Without it, people debugging Java have to issue handle
commands, as shown in http://gcc.gnu.org/java/gdb.html.

	* infrun.c (_initialize_infrun):  Don't stop or print SIGCPU and
	SIGPWR - they are used by the Java runtime's thread support.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

[-- Attachment #2: infrun.patch --]
[-- Type: text/plain, Size: 949 bytes --]

	* infrun.c (_initialize_infrun):  Don't stop or print SIGCPU and
	SIGPWR - they are used by the Java runtime's thread support.

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

Re: patch to ignore SIGPWR and SIGXCPU (used by pthreads)

[Andrew Cagney]

> 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

Re: patch to ignore SIGPWR and SIGXCPU (used by pthreads)

[Per Bothner]

Andrew Cagney wrote:
> 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 forwarded your message to the java mailing list.  But my assumption
is - what does it matter?  At least when using linux-threads, we do use
these signals.  As I understand it, linux-threads uses kernel support
and does not uses signals.  However, the garbage collector needs to be
able to stop and re-start all threads when doing a collection.  It does
this using signals, at least under linux-threads.  This has nothing to
do with the Solaris user-leel threads implementation, and is a
completely orthoginal issue.

> I don't know that it is right to always silence/ignore these signals 
> when not all systems are using pthreads/libgcj.

Why not?  What does it hurt to (by default) just pass them to the
inferior?  Having gdb stop inconveniences (and confuses) everybody who
uses gcj.  Having gdb silently pass the signals to the application
inconveniences/confuses - who?
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: patch to ignore SIGPWR and SIGXCPU (used by pthreads)

[Andrew Cagney]

> Why not?  What does it hurt to (by default) just pass them to the
> inferior?  Having gdb stop inconveniences (and confuses) everybody who
> uses gcj.  Having gdb silently pass the signals to the application
> inconveniences/confuses - who?


Consider SIGXCPU.

With your proposed change, a program that exceeds its CPU usage will 
quietly terminate.   The user will loose their entire debug session. 
This is very different to GDB's current behavour where the signal is 
intercepted, the program is stopped, and control is returned to the user.

Andrew

Re: patch to ignore SIGPWR and SIGXCPU (used by pthreads)

[Per Bothner]

Andrew Cagney wrote:
> Consider SIGXCPU.
> 
> With your proposed change, a program that exceeds its CPU usage will 
> quietly terminate.   The user will loose their entire debug session. 
> This is very different to GDB's current behavour where the signal is 
> intercepted, the program is stopped, and control is returned to the user.

How does a program exceed its CPU usage?  In any other situation except
by having a person running the program explicitly set the CPU usage?
Somebody who knows how to to do that can be expected to know how to
use the 'handle' command.  On the other hand, we should not expect
someone debugging a Java program to have to use 'handle'.  That is
not acceptable, so we need to figure some way to fix this problem.

Is there a way that gdb can check if the inferior has set a non-default
signal handler, and only stop if using the default handler (or of
course if 'handle' was explicitly set)?
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: patch to ignore SIGPWR and SIGXCPU (used by pthreads)

[Per Bothner]

To my forwarding of Andrew's (first) response to the Java list,
I got this response from Bryce McKinlay <bryce@waitaki.otago.ac.nz>:

Ideally the GC should just use "real-time" signals for the thread
suspend/resume on systems which support them. GDB won't stop on an RT
signal. Linux didn't support them until a few years ago but it should be
easy enough to do a configure test instead of the "#  if
defined(GC_HPUX_THREADS) || defined(GC_OSF1_THREADS)" that is currently
done in boehm-gc/linux_threads.c.

regards

Bryce.

Re: patch to ignore SIGPWR and SIGXCPU (used by pthreads)

[Andrew Cagney]

> Andrew Cagney wrote:
> Consider SIGXCPU.
> 
> With your proposed change, a program that exceeds its CPU usage will quietly terminate.   The user will loose their entire debug session. This is very different to GDB's current behavour where the signal is intercepted, the program is stopped, and control is returned to the user.
> 
> How does a program exceed its CPU usage?  In any other situation except
> by having a person running the program explicitly set the CPU usage?
> Somebody who knows how to to do that can be expected to know how to
> use the 'handle' command.  On the other hand, we should not expect
> someone debugging a Java program to have to use 'handle'.  That is
> not acceptable, so we need to figure some way to fix this problem.


I don't think it is reasonable to assume that it was the user that set 
the cpu-limit.  That is often a BOFH imposed restriction.

Remember, there is a compromise here.  Change GDB's behavour to give 
GCJ/Linux users a good experience (and in the process cover up a screwup 
- lets be honest :-) VS give GCJ/Linux users a bad experience but 
preserve correct behavour for all other users.

Andrew

Re: patch to ignore SIGPWR and SIGXCPU (used by pthreads)

[Michael Snyder]

Andrew Cagney wrote:
> 
> > Why not?  What does it hurt to (by default) just pass them to the
> > inferior?  Having gdb stop inconveniences (and confuses) everybody who
> > uses gcj.  Having gdb silently pass the signals to the application
> > inconveniences/confuses - who?
> 
> Consider SIGXCPU.
> 
> With your proposed change, a program that exceeds its CPU usage will
> quietly terminate.   The user will loose their entire debug session.
> This is very different to GDB's current behavour where the signal is
> intercepted, the program is stopped, and control is returned to the user.


Java's use of these signals is somewhat analogous to what
linux threads does.  In that case, we also "silence" the 
signals, but we do it only in the context where we know
they are used.  Only for linux, and only when a multi-thread
program is detected.

Could you do something like that?

Re: patch to ignore SIGPWR and SIGXCPU (used by pthreads)

[Daniel Jacobowitz]

On Mon, Jan 21, 2002 at 09:27:29AM -0800, Michael Snyder wrote:
> Andrew Cagney wrote:
> > 
> > > Why not?  What does it hurt to (by default) just pass them to the
> > > inferior?  Having gdb stop inconveniences (and confuses) everybody who
> > > uses gcj.  Having gdb silently pass the signals to the application
> > > inconveniences/confuses - who?
> > 
> > Consider SIGXCPU.
> > 
> > With your proposed change, a program that exceeds its CPU usage will
> > quietly terminate.   The user will loose their entire debug session.
> > This is very different to GDB's current behavour where the signal is
> > intercepted, the program is stopped, and control is returned to the user.
> 
> 
> Java's use of these signals is somewhat analogous to what
> linux threads does.  In that case, we also "silence" the 
> signals, but we do it only in the context where we know
> they are used.  Only for linux, and only when a multi-thread
> program is detected.
> 
> Could you do something like that?

Could we make Boehm GC export two variables containing the values of
the signals it intends to use, and recognise their presence?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer