From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11954 invoked by alias); 9 May 2003 21:48:32 -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 11947 invoked from network); 9 May 2003 21:48:32 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 9 May 2003 21:48:32 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h49LmWH21578 for ; Fri, 9 May 2003 17:48:32 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h49LmVI20151 for ; Fri, 9 May 2003 17:48:31 -0400 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h49LmU814124; Fri, 9 May 2003 17:48:31 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id BDC532C439; Fri, 9 May 2003 17:53:37 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16060.9057.586713.837253@localhost.redhat.com> Date: Fri, 09 May 2003 21:48:00 -0000 To: Roland McGrath Cc: Mark Kettenis , gdb@sources.redhat.com Subject: Re: gdb/dwarf-frame.c In-Reply-To: <200305092119.h49LJVi27336@magilla.sf.frob.com> References: <200305091942.h49Jgn64007660@elgar.kettenis.dyndns.org> <200305092119.h49LJVi27336@magilla.sf.frob.com> X-SW-Source: 2003-05/txt/msg00162.txt.bz2 Roland McGrath writes: > [I trimmed the CC because I think everyone else is on the mailing list.] > > > Yes indeed. I mostly use FreeBSD instead of Linux nowadays, so I > > haven't tracked what's been happening on the Linux thread front too > > closely. I get the feeling though that trying to support both the old > > and the new threading model in the same code isn't a good idea :-(. > > Can you be specific in your criticism? The rigamarole to get sibling > threads stopped and started is a bit unsightly, but not too horrible I > didn't think. I think trying to have separate backend implementations for > linuxthreads and nptl and switching among them (whether two target modules > or one with internal state flags) would be worse than any moderate amount > of kludgery in the one backend. > > The situation in lin-lwp.c can be much cleaner if Dan and I ever implement > the enhancements to ptrace in Linux 2.5 that we have discussed in detail > privately in the past. That would let thread tracing at the kernel level > work in a sane fashion with either kind of threads on a new kernel, and > make it easy to detect an old kernel lacking the new ptrace features and > fall back to the existing code that only supports linuxthreads. We can > probably be spurred to do this, though it has heretofore fallen off the end > of our queues of wonderful things that ought to be done real soon now. > > That doesn't help debugging NPTL on extant 2.5 kernels or on modified 2.4 > kernels that support NPTL like those in RHL9. But personally I am ok with > such support not going into mainline gdb if cleaner support for newer > kernels is there. (However I don't speak for my RH colleagues who will > have to maintain private patches as necessary.) > I don't think it is a good idea for gdb6 to be broken on the most recent linux kernels. elena > > Thanks, > Roland