Real-Time signals & GDB

Real-Time signals & GDB

[Jeff Jenkins]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

Anyone here know how 
to get GDB to properly handle RT signals?  When I queue a RT signal, GDB 
complains that it received an unknown signal and fails to deliever it to the 
process. Is there something specific I need to do such that GDB will handle 
RT signals?
 
Thanks!
 
-- 
jrj

Re: Real-Time signals & GDB

[Mark Kettenis]

   From: Jeff Jenkins <jjenkins@jetstream.com>
   Date: Fri, 1 Sep 2000 11:17:51 -0700 

   Anyone here know how to get GDB to properly handle RT signals?  When I queue
   a RT signal, GDB complains that it received an unknown signal and fails to
   deliever it to the process. Is there something specific I need to do such
   that GDB will handle RT signals?

Which GDB version?  Which platform?  GDB handles RT signals just fine
Linux/x86.

Mark
From kettenis@wins.uva.nl Sun Sep 03 12:34:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: gdb@sourceware.cygnus.com, rok.papez@kiss.uni-lj.si, blizzard@redhat.com, kevinb@cygnus.com, grg22@ai.mit.edu, greg@mcgary.org, randy@dontknow.org, jgarza@metrowerks.com, pnolan@dircon.co.uk, markusk@pvv.org, mikepery@fscked.org, eric@atdesk.com, asheik4@cs.mcgill.ca
Subject: Linux threads support in GDB
Date: Sun, 03 Sep 2000 12:34:00 -0000
Message-id: <200009031934.e83JYDs02423@delius.kettenis.local>
X-SW-Source: 2000-09/msg00003.html
Content-length: 1136

To all who have reported problems with GDB's threads support on Linux,

Today, I've checked in a rewrite of GDB's threads support for Linux
into the GDB CVS tree.  This should really make debugging
multi-threaded code more robust.  However, to be sure that it really
is more robust, it needs to be tested.  Multi-threaded code is
timing-critical and me not noticing any problems doesn't mean they are
not there.  I welcome everybody to check out the new code and report
any problems.  Please provide a (small) test program and enough
information to reproduce the problem if you do.

To avoid disappointments:

 * You'll need glibc 2.1.3.  Older versions are no longer supported.

 * The new threads stuff is only enabled for Linux/x86.

 * The "zombie problem" isn't fixed yet ...

 * ... which doesn't really matter since the limit of ~30 threads
   isn't fixed either.

 * You'll see quite a bit of debugging output, that tells you (or me)
   what's going on, but interferes with the program output.

See < http://sources.redhat.com/gdb > for information on how the check out
the code.

I'll be looking forward to your reports,

Mark
From pustota@ngi.de Sun Sep 03 12:55:00 2000
From: "Ariel V. Burbaickij" <pustota@ngi.de>
To: gdb@sources.redhat.com
Subject: gdb reports : Could not set file in non-blocking mode.Resource is temporarily unavailable.
Date: Sun, 03 Sep 2000 12:55:00 -0000
Message-id: <39B2AC83.F2F15AF4@ngi.de>
X-SW-Source: 2000-09/msg00004.html
Content-length: 252

I use :

OS: FreeBSD 4.1-STABLE
gdb: 4.18


trying to debug something I get warning put in subject.

Questions:
1)What resource/resources is/are meant ?
2)How do I cope with th problem ?



Regards

Please also CC to me to adress given in From: field.
From hjl@lucon.org Mon Sep 04 08:49:00 2000
From: "H . J . Lu" <hjl@lucon.org>
To: Joern Rennecke <amylaar@cygnus.co.uk>
Cc: GDB <gdb@sourceware.cygnus.com>
Subject: gdb doesn't work very well with dynamic linked binaries
Date: Mon, 04 Sep 2000 08:49:00 -0000
Message-id: <20000904084934.A11100@lucon.org>
References: <20000901192328.A28312@valinux.com> <200009041047.LAA10659@phal.cygnus.co.uk>
X-SW-Source: 2000-09/msg00005.html
Content-length: 560

On Mon, Sep 04, 2000 at 11:47:13AM +0100, Joern Rennecke wrote:
> > It is too bad that not many gcc developers using --enable-shared to
> > configure gcc under ia32. See
> 
> Well, on Linux, gdb fails to restart a cc1 / cc1plus executable that is
> statically linked, which makes debugging very tedious.
> So I always patch my Makefile to use static linking.

That is a very annoying bug in gdb 5.0. When I set a breakpoint in
the shared library, I have to disable them before restart. Also it is
very hard to debug ld-linux.so.2:

# gdb ld-linux.so.2



H.J.
From kettenis@wins.uva.nl Mon Sep 04 10:52:00 2000
From: Mark Kettenis <kettenis@wins.uva.nl>
To: hjl@lucon.org, drepper@redhat.com
Cc: amylaar@cygnus.co.uk, gdb@sourceware.cygnus.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Mon, 04 Sep 2000 10:52:00 -0000
Message-id: <200009041751.e84HprD11517@debye.wins.uva.nl>
References: <20000901192328.A28312@valinux.com> <200009041047.LAA10659@phal.cygnus.co.uk> <20000904084934.A11100@lucon.org>
X-SW-Source: 2000-09/msg00006.html
Content-length: 1019

   Date: Mon, 4 Sep 2000 08:49:34 -0700
   From: "H . J . Lu" <hjl@lucon.org>

   On Mon, Sep 04, 2000 at 11:47:13AM +0100, Joern Rennecke wrote:
   > > It is too bad that not many gcc developers using --enable-shared to
   > > configure gcc under ia32. See
   > 
   > Well, on Linux, gdb fails to restart a cc1 / cc1plus executable that is
   > statically linked, which makes debugging very tedious.
   > So I always patch my Makefile to use static linking.

   That is a very annoying bug in gdb 5.0. When I set a breakpoint in
   the shared library, I have to disable them before restart.

Getting this bug fixed is one of the release criteria for GDB 5.1.
All I have now is a hack that works around the problems, see the GDB
TODO file for more info.

   Also it is very hard to debug ld-linux.so.2:

   # gdb ld-linux.so.2

AFAIK this never worked.  Patches to make it work are certainly
welcome.  Uli mentioned he submitted some patches, but I cannot find
any trace of them.  Perhaps you re-submit them Uli?

Mark
From dan@cgsoftware.com Mon Sep 04 11:11:00 2000
From: Daniel Berlin <dan@cgsoftware.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
Cc: hjl@lucon.org, drepper@redhat.com, amylaar@cygnus.co.uk, gdb@sourceware.cygnus.com
Subject: Re: gdb doesn't work very well with dynamic linked binaries
Date: Mon, 04 Sep 2000 11:11:00 -0000
Message-id: <Pine.LNX.4.21.0009041104140.3814-100000@propylaea.anduin.com>
References: <200009041751.e84HprD11517@debye.wins.uva.nl>
X-SW-Source: 2000-09/msg00007.html
Content-length: 367

> 
> AFAIK this never worked.  Patches to make it work are certainly
> welcome.  Uli mentioned he submitted some patches, but I cannot find
> any trace of them.  Perhaps you re-submit them Uli?

If they were the same ones he sent me, i forwarded them along to various
gdb people, but the consensus was that it didn't actually fix the real
problem.
--Dan
> > Mark
> 

Re: Real-Time signals & GDB

[Peter.Schauer]

Please try the following (lightly tested) patch and let me know if there
are any more problems with realtime signals.

*** gdb-5.0/gdb/target.c.orig	Fri Apr 28 19:09:03 2000
--- gdb-5.0/gdb/target.c	Sun Sep 10 17:15:30 2000
***************
*** 1852,1857 ****
--- 1852,1869 ----
  	error ("GDB bug: target.c (target_signal_from_host): unrecognized real-time signal");
      }
  #endif
+ 
+ #if defined (SIGRTMIN)
+   if (hostsig >= SIGRTMIN && hostsig <= SIGRTMAX)
+     {
+       /* This block of TARGET_SIGNAL_REALTIME value is in order.  */
+       if (33 <= hostsig && hostsig <= 63)
+ 	return (enum target_signal)
+ 	  (hostsig - 33 + (int) TARGET_SIGNAL_REALTIME_33);
+       else
+ 	error ("GDB bug: target.c (target_signal_from_host): unrecognized real-time signal");
+     }
+ #endif
    return TARGET_SIGNAL_UNKNOWN;
  }
  
***************
*** 2107,2112 ****
--- 2119,2136 ----
  	}
  #endif
  #endif
+ #if defined (SIGRTMIN)
+       if (oursig >= TARGET_SIGNAL_REALTIME_33
+ 	  && oursig <= TARGET_SIGNAL_REALTIME_63)
+ 	{
+ 	  /* This block of signals is continuous, and
+              TARGET_SIGNAL_REALTIME_33 is 33 by definition.  */
+ 	  int retsig =
+ 	    (int) oursig - (int) TARGET_SIGNAL_REALTIME_33 + 33;
+ 	  if (retsig >= SIGRTMIN && retsig <= SIGRTMAX)
+ 	    return retsig;
+ 	}
+ #endif
        *oursig_ok = 0;
        return 0;
      }

>    From: Jeff Jenkins <jjenkins@jetstream.com>
>    Date: Wed, 6 Sep 2000 08:14:16 -0700 
> 
>    I downloaded gdb 5.0, and successfully compiled it for Solaris 7/SPARC.
>    However, the same problem persists as was present under 4.18.
> 
>    When I send a real-time signal from one thread to another thread, gdb halts
>    with the following message:
> 
>    "Program received signal ?, Unknown signal.
>    [Switching to LWP 7]
>    0xfef93224 in _libc_sigtimedwait () from /usr/lib/libc.so.1"
> 
> Looks like real-time signals aren't supported for Solaris.  Patches to
> make it work are probably welcome :-).
> 
> Mark

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From nickc@redhat.com Sun Sep 10 12:20:00 2000
From: Nick Clifton <nickc@redhat.com>
To: pb@tazenda.demon.co.uk
Cc: binutils@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: update config.sub
Date: Sun, 10 Sep 2000 12:20:00 -0000
Message-id: <200009101920.MAA01443@elmo.cygnus.com>
X-SW-Source: 2000-09/msg00097.html
Content-length: 121

Hi Phil,

: I'd like to update config.sub to the latest from subversions.  Any
: objection? 

Not from me.

Cheers
	Nick
From Franz.Sirl-kernel@lauterbach.com Sun Sep 10 12:29:00 2000
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: Nick Clifton <nickc@redhat.com>
Cc: pb@tazenda.demon.co.uk, binutils@sourceware.cygnus.com, gdb@sourceware.cygnus.com
Subject: Re: update config.sub
Date: Sun, 10 Sep 2000 12:29:00 -0000
Message-id: <5.0.0.19.2.20000910212651.01e89eb0@mail.lauterbach.com>
References: <200009101920.MAA01443@elmo.cygnus.com>
X-SW-Source: 2000-09/msg00098.html
Content-length: 224

At 21:20 10.09.00, Nick Clifton wrote:
>Hi Phil,
>
>: I'd like to update config.sub to the latest from subversions.  Any
>: objection?
>
>Not from me.

Shouldn't config.guess/config.sub always be updated as a pair?

Franz.