From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28247 invoked by alias); 23 Apr 2010 15:51:48 -0000 Received: (qmail 27986 invoked by uid 22791); 23 Apr 2010 15:51:46 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Apr 2010 15:51:35 +0000 Received: (qmail 7755 invoked from network); 23 Apr 2010 15:51:33 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 Apr 2010 15:51:33 -0000 From: Pedro Alves To: Mark Kettenis Subject: Re: pthread_t ids of threads not showed by "thread info" Date: Fri, 23 Apr 2010 15:51:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-20-generic; KDE/4.3.2; x86_64; ; ) Cc: gdb@sourceware.org, stefano.sabatini-lala@poste.it References: <20100422151855.GA3128@geppetto> <201004231347.31809.pedro@codesourcery.com> <201004231536.o3NFa1Kn029584@glazunov.sibelius.xs4all.nl> In-Reply-To: <201004231536.o3NFa1Kn029584@glazunov.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201004231651.31431.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00109.txt.bz2 On Friday 23 April 2010 16:36:01, Mark Kettenis wrote: > > From: Pedro Alves > > > The interpretation of the > > > pid read from the core file really is OS-specific. The default > > > core_pid_to_str should really be the lowest common denominator, i.e, > > > normal_pid_to_str(). That's really the only thing that makes sense > > > for non-threaded code on a UNIX-like system. > > > > Yeah, probably. What are the targets we support you're thinking > > where "process" would make more sense and be less confusing > > than "LWP"? Pedantic-ness issues aside, seeing multiple > > "processes" in the list when all the processes share a single > > address space looks a bit strange to me. > > I was thinking of *any* target running a UNIX-like OS. For for the > (typical) user debugging a non-threaded program on a UNIX-like OS, > seeing "Thread ..." or "LWP ..." is confusing. Especially the term > "LWP" will be pretty cryptic to many people not familliar with > implementation details of the Solaris/SVR4.2 MP/NetBSD threads > implementations. > > One can even argue that it's the wrong thing to use on Linux. I don't > think the Linux kernel has the concept of an LWP. A more appropriate > term on Linux would be TID, at least that is what the gettid() man > page uses and what's used in the comments in the kernel sources. Maybe. That's a fair point. I've no sensibility whether TID would be more or less confusing for linux users. > > > The threads stratum then > > > can override this for threaded code. > > > > > > If like on Linux, the threading stuff is messed up for core files, and > > > not easily fixable, it is probably more helpful to print LWP's like > > > you suggest. > > > > It's not about that, that's a different issue. In linux, assume > > we're talking about the core of a program that didn't use any > > pthreads facilities (used raw `clone'), and you still have > > multiple processes listed in the core. > > Right. It would be nice if that produced meaningful output as well. > > > > But in my opinion that really should be done by > > > overriding the default using set_gdbarch_core_pid_to_str(). > > > > That works, of course. I'm just thinking of the practical > > aspect. If we have many targets that want "LWP", and one > > that wants "process", is it worth the hassle? > > I think decoupling things will help us here in the long run. Completely decoupling would mean no default at all ;-) I'll eventually come up with a patch, though not this week, probably. -- Pedro Alves