From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11951 invoked by alias); 9 May 2003 21:58:57 -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 11938 invoked from network); 9 May 2003 21:58:56 -0000 Received: from unknown (HELO crack.them.org) (146.82.138.56) by sources.redhat.com with SMTP; 9 May 2003 21:58:56 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 19EFtd-0004ht-00; Fri, 09 May 2003 16:59:18 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 19EFtC-0007k1-00; Fri, 09 May 2003 17:58:50 -0400 Date: Fri, 09 May 2003 21:58:00 -0000 From: Daniel Jacobowitz To: Roland McGrath Cc: Mark Kettenis , gdb@sources.redhat.com Subject: Re: gdb/dwarf-frame.c Message-ID: <20030509215850.GA29659@nevyn.them.org> Mail-Followup-To: Roland McGrath , Mark Kettenis , gdb@sources.redhat.com References: <200305091942.h49Jgn64007660@elgar.kettenis.dyndns.org> <200305092119.h49LJVi27336@magilla.sf.frob.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305092119.h49LJVi27336@magilla.sf.frob.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-05/txt/msg00165.txt.bz2 On Fri, May 09, 2003 at 02:19:31PM -0700, Roland McGrath wrote: > [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. Coincidentally, I'm working on this this weekend. Or I was going to. The NPTL gdb patches do _not_ work on 2.5.69. The message about this is stuck in my outbox; I'm trying to get GDB to give me a backtrace but it's been chugging for an hour now with no luck (160K frames and counting!) > 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'd rather support it. I think we can, too. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer