From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3481 invoked by alias); 3 Dec 2001 12:14:16 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 3453 invoked from network); 3 Dec 2001 12:14:14 -0000 Received: from unknown (HELO nic.osagesoftware.com) (65.186.161.49) by sources.redhat.com with SMTP; 3 Dec 2001 12:14:14 -0000 Received: from maple.osagesoftware.com (maple.osagesoftware.com [192.168.1.20]) by nic.osagesoftware.com (8.10.1/8.10.1) with ESMTP id fB3CEDI31076 for ; Mon, 3 Dec 2001 07:14:13 -0500 Message-Id: <4.3.2.7.2.20011203070819.00c785c0@mail.osagesoftware.com> X-Sender: relson@mail.osagesoftware.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Dec 2001 04:14:00 -0000 To: gdb@sources.redhat.com From: David Relson Subject: Re: Problem with threaded program In-Reply-To: <3C0B0D62.3040708@cygnus.com> References: <3C0A7599.3040902@cygnus.com> <4.3.2.7.2.20011202114313.00c40ab0@mail.osagesoftware.com> <3C0A7599.3040902@cygnus.com> <4.3.2.7.2.20011202201853.00bfba30@mail.osagesoftware.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SW-Source: 2001-12/txt/msg00009.txt.bz2 At 12:28 AM 12/3/01, you wrote: >>Daniel, >>I don't know what the division of labor is between gdb and the kernel for >>situations like this, so I can't comment on that. I can report, however, >>that the problem doesn't occur with gdb-4.18. I had previously tested >>with an old copy of gdb-4.18. To remove one possible difference, I have >>tested for the problem using copies of both gdb-4.18 and gdb-5.1 built >>today under the 2.4.16 kernel. gdb-4.18 works properly and gdb-5.1 shows >>the problem. If the problem is in the kernel, then 4.18 and 5.1 must be >>using different capabilities ... > >Yes, very, very different: > >>>The apparent 4.18 -> 5.0 ``breakage'' would have occured because GDB >>>switched to using the thread-db/kernel interface. > >best way to describe this is, unfortunatly, is ``radical surgery''. While >the new implementation is significantly better and definitly worth the >effort. however, it is showing up a few teathing problems. I believe the phrase goes "you have to break an egg to make an omelet" or is it that progress requires "two steps forward and one step backwards"? > Just make certain that your kernel/glibc are recent. Current they are. kernel is 2.4.16 and glibc is 2.2.4-6mdk. I'd be willing to update to 2.4.17-pre2 and 2.2.4-7 if you thought it'd make a difference. Is this something that ought to be brought to the attention of the kernel maintainers? If so, would you notify them? Your deeper knowledge and understanding of the issues involved would be helpful. Cheers! David