From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11457 invoked by alias); 23 Apr 2010 15:37:33 -0000 Received: (qmail 11445 invoked by uid 22791); 23 Apr 2010 15:37:31 -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 sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 23 Apr 2010 15:37:25 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id o3NFa2Ca013601; Fri, 23 Apr 2010 17:36:02 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id o3NFa1Kn029584; Fri, 23 Apr 2010 17:36:01 +0200 (CEST) Date: Fri, 23 Apr 2010 15:37:00 -0000 Message-Id: <201004231536.o3NFa1Kn029584@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: pedro@codesourcery.com CC: gdb@sourceware.org, stefano.sabatini-lala@poste.it In-reply-to: <201004231347.31809.pedro@codesourcery.com> (message from Pedro Alves on Fri, 23 Apr 2010 13:47:31 +0100) Subject: Re: pthread_t ids of threads not showed by "thread info" References: <20100422151855.GA3128@geppetto> <201004231250.34075.pedro@codesourcery.com> <201004231229.o3NCTqBk031213@glazunov.sibelius.xs4all.nl> <201004231347.31809.pedro@codesourcery.com> 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/msg00107.txt.bz2 > From: Pedro Alves > Date: Fri, 23 Apr 2010 13:47:31 +0100 > > On Friday 23 April 2010 13:29:52, Mark Kettenis wrote: > > If you ask me, whoever made the change from process to thread (cvs > > annotate says it's you ;), made a mistake. > > Yep. No need to ask, I already said so. ;-) > > > 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. > > 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.