This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pthread_t ids of threads not showed by "thread info"


> From: Pedro Alves <pedro@codesourcery.com>
> 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, "<main task>");
>    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().


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]