Re: Real-Time signals & GDB

[Mark Kettenis <kettenis@wins.uva.nl>]

   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
>