From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26271 invoked by alias); 9 May 2003 21:19:34 -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 26198 invoked from network); 9 May 2003 21:19:34 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.163.213.212) by sources.redhat.com with SMTP; 9 May 2003 21:19:34 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 26BDA354C; Fri, 9 May 2003 14:19:33 -0700 (PDT) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h49LJVi27336; Fri, 9 May 2003 14:19:31 -0700 Date: Fri, 09 May 2003 21:19:00 -0000 Message-Id: <200305092119.h49LJVi27336@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Mark Kettenis Cc: gdb@sources.redhat.com Subject: Re: gdb/dwarf-frame.c In-Reply-To: Mark Kettenis's message of Friday, 9 May 2003 21:42:49 +0200 <200305091942.h49Jgn64007660@elgar.kettenis.dyndns.org> X-Windows: even not doing anything would have been better than nothing. X-SW-Source: 2003-05/txt/msg00159.txt.bz2 [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.) Thanks, Roland