Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: pedro@codesourcery.com
Cc: gdb@sourceware.org, stefano.sabatini-lala@poste.it
Subject: Re: pthread_t ids of threads not showed by "thread info"
Date: Fri, 23 Apr 2010 12:31:00 -0000	[thread overview]
Message-ID: <201004231229.o3NCTqBk031213@glazunov.sibelius.xs4all.nl> (raw)
In-Reply-To: <201004231250.34075.pedro@codesourcery.com> (message from Pedro 	Alves on Fri, 23 Apr 2010 12:50:34 +0100)

> 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().


  reply	other threads:[~2010-04-23 12:31 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-22 15:19 Stefano Sabatini
2010-04-22 15:44 ` Stefano Sabatini
2010-04-22 16:59   ` Jan Kratochvil
2010-04-23  7:51     ` Stefano Sabatini
2010-04-23 10:25       ` Jan Kratochvil
2010-04-23 14:21         ` Stefano Sabatini
2010-04-23 14:25           ` Jan Kratochvil
2010-04-23 15:36             ` Stefano Sabatini
2010-04-23 15:46               ` Jan Kratochvil
2010-04-26  8:38                 ` Stefano Sabatini
2010-04-26  9:04                   ` Jan Kratochvil
2010-04-26 11:07                     ` Stefano Sabatini
2010-04-26 11:25                       ` Jan Kratochvil
2010-04-23 14:29           ` Stefano Sabatini
2010-04-23 11:50   ` Pedro Alves
2010-04-23 12:31     ` Mark Kettenis [this message]
2010-04-23 12:47       ` Pedro Alves
2010-04-23 15:37         ` Mark Kettenis
2010-04-23 15:51           ` Pedro Alves
2010-08-04 14:36             ` Pedro Alves
2010-08-04 14:57               ` Mark Kettenis
2010-08-04 15:29                 ` Pedro Alves
2010-08-04 16:53               ` Ulrich Weigand
2010-08-04 17:14                 ` Pedro Alves
2010-08-04 17:40                   ` Pedro Alves
2010-08-04 17:44                     ` Ulrich Weigand
2010-08-04 18:20                       ` Pedro Alves
2010-08-04 18:34                         ` Ulrich Weigand
2010-08-04 20:41                           ` Pedro Alves
2010-08-04 17:45                     ` Ulrich Weigand
2010-04-22 20:52 ` Petr Hluzín
2010-04-22 20:56   ` Daniel Jacobowitz
2010-08-18 14:17 ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201004231229.o3NCTqBk031213@glazunov.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=gdb@sourceware.org \
    --cc=pedro@codesourcery.com \
    --cc=stefano.sabatini-lala@poste.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox