From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28244 invoked by alias); 23 Apr 2010 12:31:24 -0000 Received: (qmail 28231 invoked by uid 22791); 23 Apr 2010 12:31:23 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_00,TW_XS,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 12:31:17 +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 o3NCTsrG024693; Fri, 23 Apr 2010 14:29:54 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id o3NCTqBk031213; Fri, 23 Apr 2010 14:29:52 +0200 (CEST) Date: Fri, 23 Apr 2010 12:31:00 -0000 Message-Id: <201004231229.o3NCTqBk031213@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: pedro@codesourcery.com CC: gdb@sourceware.org, stefano.sabatini-lala@poste.it In-reply-to: <201004231250.34075.pedro@codesourcery.com> (message from Pedro Alves on Fri, 23 Apr 2010 12:50:34 +0100) Subject: Re: pthread_t ids of threads not showed by "thread info" References: <20100422151855.GA3128@geppetto> <20100422154404.GB3128@geppetto> <201004231250.34075.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/msg00096.txt.bz2 > From: Pedro Alves > Date: Fri, 23 Apr 2010 12:50:34 +0100 > > On Thursday 22 April 2010 16:44:04, Stefano Sabatini wrote: > > > (gdb) info threads > > > * 9 Thread 25919 0x0040cc7d in PSafeObject::LockReadOnly (this=0xb6d3d1d8) > > > at ../common/safecoll.cxx:144 > > > 8 Thread 25920 0x00885402 in __kernel_vsyscall () > > For core files, older GDBs printed: > > 8 process 25920 0x00885402 in __kernel_vsyscall () > > instead. I'm thinking that the change so s/process/Thread/ in > corelow.c:core_pid_to_str to default to print "Thread" wasn't > that great. The idea was that "process" isn't good either, > since now GDB supports multi-process, and so it's also confusing. > > What would people say to a change like this (pseudo-patch): > > static char * > core_pid_to_str (struct target_ops *ops, ptid_t ptid) > { > static char buf[64]; > > if (core_gdbarch > && gdbarch_core_pid_to_str_p (core_gdbarch)) > { > char *ret = gdbarch_core_pid_to_str (core_gdbarch, ptid); > if (ret != NULL) > return ret; > } > > if (ptid_get_lwp (ptid) == 0) > xsnprintf (buf, sizeof buf, "
"); > else > - xsnprintf (buf, sizeof buf, "Thread %ld", ptid_get_lwp (ptid)); > + xsnprintf (buf, sizeof buf, "LWP %ld", ptid_get_lwp (ptid)); > > return buf; > } > > That is, default to print "LWP" instead. > > For core files, older GDBs printed: > > 8 LWP 25920 0x00885402 in __kernel_vsyscall () > > I think that'll make more sense for the majority of > hosts/targets that support core files. At least more > than "Thread ". > > The gdbarch callback was added specifically for Solaris, > so that we'd print "LWP " there: > > char * > sol2_core_pid_to_str (struct gdbarch *gdbarch, ptid_t ptid) > { > static char buf[80]; > > xsnprintf (buf, sizeof buf, "LWP %ld", ptid_get_lwp (ptid)); > return buf; > } > > we could get rid of it, and instead register callbacks to > whatever targets/archs want "Thread " instead. Note that there > are a few targets that do layer a thread_stratum layer > on top of corelow.c (at least OpenBSD, and Solaris' > sol-thread.c), and those are already overriding > core_pid_to_str to print whatever else they want instead, > using the regular target_ops inheritance mechanisms. I'm > thinking that Cygwin core files would be a case where you > don't have a thread_stratum, but still want "Thread". These > kinds of targets sounds like the minority, so flipping the > default seems to make sense, and be less confusing to > users. > > Opinions? If you ask me, whoever made the change from process to thread (cvs annotate says it's you ;), made a mistake. 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. 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. But in my opinion that really should be done by overriding the default using set_gdbarch_core_pid_to_str().