This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]