pthread_t ids of threads not showed by "thread info"

pthread_t ids of threads not showed by "thread info"

[Stefano Sabatini]

Hi all,

$ gdb --version
GNU gdb (GDB) 7.1

(gdb) info threads
* 9 Thread 25919  0x0040cc7d in PSafeObject::LockReadOnly (this=0xb6d3d1d8)
    at ../common/safecoll.cxx:144
  8 Thread 25920  0x00885402 in __kernel_vsyscall ()
  7 Thread 25921  0x00885402 in __kernel_vsyscall ()
  6 Thread 25922  0x00885402 in __kernel_vsyscall ()
  5 Thread 25927  0x00885402 in __kernel_vsyscall ()
  4 Thread 25928  0x00885402 in __kernel_vsyscall ()
  3 Thread 16215  0x00885402 in __kernel_vsyscall ()
  2 Thread 16216  0x00885402 in __kernel_vsyscall ()
  1 Thread 25917  0x00885402 in __kernel_vsyscall ()
(gdb) help info thread
IDs of currently known threads.

This shows the gdb thread number, the process ID and I don't know
what's contained in the fourth column, but that's for sure cannot be
the same as the pthread_t id as it is the same for all the threads.

On another machine I get this output:
  3 Thread 0xb7642b70 (LWP 3334)  (running)
  2 Thread 0xb7e43b70 (LWP 3333)  (running)
* 1 Thread 0xb7e446c0 (LWP 3327)  0xb7fe1424 in __kernel_vsyscall ()

Can you explain the differences, and why are there in the first place?

Also in the first scenario I cannot get the pthread_t information, which
is shown in the third column of the second scenario.

To me this sounds like a real puzzle, I'll be grateful to whom will
help me to figure it out, also a pointer to the location in the gdb
sources where the "info thread" command is executed would be welcome.

TIA, regards.

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

[Stefano Sabatini]

On date Thursday 2010-04-22 17:18:55 +0200, Stefano Sabatini wrote:
> Hi all,
> 
> $ gdb --version
> GNU gdb (GDB) 7.1
> 
> (gdb) info threads
> * 9 Thread 25919  0x0040cc7d in PSafeObject::LockReadOnly (this=0xb6d3d1d8)
>     at ../common/safecoll.cxx:144
>   8 Thread 25920  0x00885402 in __kernel_vsyscall ()
>   7 Thread 25921  0x00885402 in __kernel_vsyscall ()
>   6 Thread 25922  0x00885402 in __kernel_vsyscall ()
>   5 Thread 25927  0x00885402 in __kernel_vsyscall ()
>   4 Thread 25928  0x00885402 in __kernel_vsyscall ()
>   3 Thread 16215  0x00885402 in __kernel_vsyscall ()
>   2 Thread 16216  0x00885402 in __kernel_vsyscall ()
>   1 Thread 25917  0x00885402 in __kernel_vsyscall ()
> (gdb) help info thread
> IDs of currently known threads.
> 
> This shows the gdb thread number, the process ID and I don't know
> what's contained in the fourth column, but that's for sure cannot be
> the same as the pthread_t id as it is the same for all the threads.
> 
> On another machine I get this output:
>   3 Thread 0xb7642b70 (LWP 3334)  (running)
>   2 Thread 0xb7e43b70 (LWP 3333)  (running)
> * 1 Thread 0xb7e446c0 (LWP 3327)  0xb7fe1424 in __kernel_vsyscall ()
> 
> Can you explain the differences, and why are there in the first place?
> 
> Also in the first scenario I cannot get the pthread_t information, which
> is shown in the third column of the second scenario.

The difference between the first and the second scenario is that the
first output was issued debugging a core, the second one by running a
process through gdb run.

May be possible that it is not possible to extract the pthread_t
info from a core file? Can you explain why?

[...]

Regards.

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

[Jan Kratochvil]

On Thu, 22 Apr 2010 17:44:04 +0200, Stefano Sabatini wrote:
> The difference between the first and the second scenario is that the
> first output was issued debugging a core, the second one by running a
> process through gdb run.

Yes, IIRC GDB does not use linux-thread-db.c (libthread_db) for core files.
`info threads' displays LWPs (and not real threads) in such case.


> May be possible that it is not possible to extract the pthread_t
> info from a core file?

LWPs do not have associated pthread_t.


> Can you explain why?

IIRC I tried once to add linux-thread-db.c for core files but for some reason
it was not completely trivial and I rather debugged the specific case by hand
iterating some pthread_t structures for that crash.


Regards,
Jan

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

[Petr Hluzín]

Hi Stefano

On 22 April 2010 17:18, Stefano Sabatini <stefano.sabatini-lala@poste.it> 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 ()
>  7 Thread 25921  0x00885402 in __kernel_vsyscall ()
>  6 Thread 25922  0x00885402 in __kernel_vsyscall ()
>  5 Thread 25927  0x00885402 in __kernel_vsyscall ()
>  4 Thread 25928  0x00885402 in __kernel_vsyscall ()
>  3 Thread 16215  0x00885402 in __kernel_vsyscall ()
>  2 Thread 16216  0x00885402 in __kernel_vsyscall ()
>  1 Thread 25917  0x00885402 in __kernel_vsyscall ()
> (gdb) help info thread
> IDs of currently known threads.

I tried this on process on x86 to make myself sure:
(gdb) info threads
* 1 process 1248  0xb7fdf410 in __kernel_vsyscall ()
(gdb) info symbol 0xb7fdf410
__kernel_vsyscall + 16 in section .text of system-supplied DSO at 0xb7fdf000

The 0xb7fdf410 is a return address within code of __kernel_vsyscall().
The address is mostly useless when you have symbols. I guess it is
mostly for debugging gdb itself.

-- 
Petr Hluzin

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

[Daniel Jacobowitz]

On Thu, Apr 22, 2010 at 10:51:55PM +0200, Petr Hluzín wrote:
> The 0xb7fdf410 is a return address within code of __kernel_vsyscall().
> The address is mostly useless when you have symbols. I guess it is
> mostly for debugging gdb itself.

The address is shown whenever you aren't at the start of a known
source line; there's no source level debug info for the vDSO.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Stefano Sabatini]

On Thursday 2010-04-22 18:59:24 +0200, Jan Kratochvil wrote:
> On Thu, 22 Apr 2010 17:44:04 +0200, Stefano Sabatini wrote:
> > The difference between the first and the second scenario is that the
> > first output was issued debugging a core, the second one by running a
> > process through gdb run.
> 
> Yes, IIRC GDB does not use linux-thread-db.c (libthread_db) for core files.
> `info threads' displays LWPs (and not real threads) in such case.
> 
> 
> > May be possible that it is not possible to extract the pthread_t
> > info from a core file?
> 
> LWPs do not have associated pthread_t.
> 
> > Can you explain why?
> 
> IIRC I tried once to add linux-thread-db.c for core files but for some reason
> it was not completely trivial and I rather debugged the specific case by hand
> iterating some pthread_t structures for that crash.

Could you elaborate on that? I mean are you saying that it is possible
but currently unimplemented?

I'm in a situation where I need that feature (having a core with a
deadlock, I know which are the pthread_t of the involved threads but I
cannot associate them with the corresponding gdb threads), so I'll file
a feature-request or maybe will try myself to implement the feature.

> Regards,

Thanks, regards.

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

[Jan Kratochvil]

On Fri, 23 Apr 2010 09:51:35 +0200, Stefano Sabatini wrote:
> Could you elaborate on that? I mean are you saying that it is possible
> but currently unimplemented?

Yes, try this on a core file:

define threads
	set $ofs = (long) &((struct pthread *) 0)->list
	set $list = (void *) &$arg0
	set $link = (void *) $arg0.next
	while $link != $list
		set $this = (struct pthread *)($link - $ofs)
		p $this
		#p (struct pthread *) $this->header.self
		p $this->pid
		p $this->tid
		#p *$this
		set $link = (void *) $this->list.next
	end
end
threads __stack_user
threads stack_used


> or maybe will try myself to implement the feature.

That would be great.


Thanks,
Jan

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

[Pedro Alves]

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?

-- 
Pedro Alves

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

[Mark Kettenis]

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

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

[Pedro Alves]

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.

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

> 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?

-- 
Pedro Alves

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

[Stefano Sabatini]

On Friday 2010-04-23 12:25:06 +0200, Jan Kratochvil wrote:
> On Fri, 23 Apr 2010 09:51:35 +0200, Stefano Sabatini wrote:
> > Could you elaborate on that? I mean are you saying that it is possible
> > but currently unimplemented?
> 
> Yes, try this on a core file:
> 
> define threads
> 	set $ofs = (long) &((struct pthread *) 0)->list
> 	set $list = (void *) &$arg0
> 	set $link = (void *) $arg0.next
> 	while $link != $list
> 		set $this = (struct pthread *)($link - $ofs)
> 		p $this
> 		#p (struct pthread *) $this->header.self
> 		p $this->pid
> 		p $this->tid
> 		#p *$this
> 		set $link = (void *) $this->list.next
> 	end
> end
> threads __stack_user

(gdb) define threads ...

(gdb) threads __stack_user
No symbol "pthread" in current context.

[...]

Regards.

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

[Jan Kratochvil]

On Fri, 23 Apr 2010 16:21:15 +0200, Stefano Sabatini wrote:
> No symbol "pthread" in current context.

You must have debug symbols from glibc.  On Fedora `debuginfo-install glibc',
some similar command on other distros.


Regards,
Jan

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

[Stefano Sabatini]

On date Friday 2010-04-23 16:21:15 +0200, Stefano Sabatini wrote:
> On Friday 2010-04-23 12:25:06 +0200, Jan Kratochvil wrote:
> > On Fri, 23 Apr 2010 09:51:35 +0200, Stefano Sabatini wrote:
> > > Could you elaborate on that? I mean are you saying that it is possible
> > > but currently unimplemented?
> > 
> > Yes, try this on a core file:
> > 
> > define threads
> > 	set $ofs = (long) &((struct pthread *) 0)->list
> > 	set $list = (void *) &$arg0
> > 	set $link = (void *) $arg0.next
> > 	while $link != $list
> > 		set $this = (struct pthread *)($link - $ofs)
> > 		p $this
> > 		#p (struct pthread *) $this->header.self
> > 		p $this->pid
> > 		p $this->tid
> > 		#p *$this
> > 		set $link = (void *) $this->list.next
> > 	end
> > end
> > threads __stack_user
> 
> (gdb) define threads ...
> 
> (gdb) threads __stack_user
> No symbol "pthread" in current context.

Sorry that was after some modifications from mine, what I got with your
code is:

(gdb) threads __stack_user
No struct type named pthread.

Regards

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

[Stefano Sabatini]

On date Friday 2010-04-23 16:25:11 +0200, Jan Kratochvil wrote:
> On Fri, 23 Apr 2010 16:21:15 +0200, Stefano Sabatini wrote:
> > No symbol "pthread" in current context.
> 
> You must have debug symbols from glibc.  On Fedora `debuginfo-install glibc',
> some similar command on other distros.

OK now I have this problem:

(gdb) threads __stack_user
Attempt to extract a component of a value that is not a structure.
(gdb) threads stack_used
(gdb) p __stack_user
$1 = -1221236944
(gdb) p &__stack_user
$4 = (<data variable, no debug info> *) 0xb7970160
(gdb) p (void *)&__stack_user
$5 = (void *) 0xb7970160
(gdb) p (void *)&__stack_user.next
Attempt to extract a component of a value that is not a structure.

I have debug symbols installed (installed libc6-dbg on Debian).

Regards.

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

[Mark Kettenis]

> From: Pedro Alves <pedro@codesourcery.com>
> 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.

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

[Jan Kratochvil]

On Fri, 23 Apr 2010 17:35:54 +0200, Stefano Sabatini wrote:
> On date Friday 2010-04-23 16:25:11 +0200, Jan Kratochvil wrote:
> > You must have debug symbols from glibc.  On Fedora `debuginfo-install glibc',
> > some similar command on other distros.
> 
> OK now I have this problem:
> 
> (gdb) threads __stack_user
> Attempt to extract a component of a value that is not a structure.
> (gdb) threads stack_used

> (gdb) p __stack_user
> $1 = -1221236944
$1 = {next = 0x7ffff7fd19c0, prev = 0x7ffff7fd19c0}

> (gdb) p &__stack_user
> $4 = (<data variable, no debug info> *) 0xb7970160
$4 = (list_t *) 0x379501b280

> (gdb) p (void *)&__stack_user
> $5 = (void *) 0xb7970160
$5 = (void *) 0x379501b280

> (gdb) p (void *)&__stack_user.next
> Attempt to extract a component of a value that is not a structure.
$6 = (void *) 0x379501b280


> I have debug symbols installed (installed libc6-dbg on Debian).

You should bugreport it to libc6-dbg, __stack_user must have its type.


One could hack it more using just offsets without any struct definitions but
it was just a proof-of-concept hack the info is in the core file.  One should
just apply libthread_db even on the core files.


Regards,
Jan

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

[Pedro Alves]

On Friday 23 April 2010 16:36:01, Mark Kettenis wrote:
> > From: Pedro Alves <pedro@codesourcery.com>

> > > 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

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

[Stefano Sabatini]

On Friday 2010-04-23 17:46:29 +0200, Jan Kratochvil wrote:
> On Fri, 23 Apr 2010 17:35:54 +0200, Stefano Sabatini wrote:
> > On date Friday 2010-04-23 16:25:11 +0200, Jan Kratochvil wrote:
> > > You must have debug symbols from glibc.  On Fedora `debuginfo-install glibc',
> > > some similar command on other distros.
> > 
> > OK now I have this problem:
> > 
> > (gdb) threads __stack_user
> > Attempt to extract a component of a value that is not a structure.
> > (gdb) threads stack_used
> 
> > (gdb) p __stack_user
> > $1 = -1221236944
> $1 = {next = 0x7ffff7fd19c0, prev = 0x7ffff7fd19c0}
> 
> > (gdb) p &__stack_user
> > $4 = (<data variable, no debug info> *) 0xb7970160
> $4 = (list_t *) 0x379501b280
> 
> > (gdb) p (void *)&__stack_user
> > $5 = (void *) 0xb7970160
> $5 = (void *) 0x379501b280
> 
> > (gdb) p (void *)&__stack_user.next
> > Attempt to extract a component of a value that is not a structure.
> $6 = (void *) 0x379501b280
> 
> 
> > I have debug symbols installed (installed libc6-dbg on Debian).
> 
> You should bugreport it to libc6-dbg, __stack_user must have its type.

$ cat thrids.c 
#include <pthread.h>
#include <unistd.h>

void *fn(void *p)
{
  sleep(180);
  return 0;
}

int main(void)
{
    char *str = 0;

    pthread_t pth1, pth2;

    pthread_create(&pth1, 0, fn, 0);
    pthread_create(&pth2, 0, fn, 0);
    *str = 0;
    pthread_join(pth1, 0);

    return 0;
}

$ make thrids 
gcc -I/home/stefano/include -g -O0 -pg -D_ISOC9X_SOURCE -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -fno-math-errno -lm -I/home/stefano/include -L/home/stefano/lib -pthread  thrids.c   -o thrids
$ ldd thrids
	linux-gate.so.1 =>  (0xb78c6000)
	libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb788b000)
	libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7872000)
	libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb772a000)
	/lib/ld-linux.so.2 (0xb78c7000)

$ gdb thrids
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/stefano/src/Sandbox/C/thrids...done.
(gdb) b main
Breakpoint 1 at 0x8048630: file thrids.c, line 12.
(gdb) r
[Thread debugging using libthread_db enabled]
 
Breakpoint 1, main () at thrids.c:12
12        char *str = 0;
(gdb) p stack_user
No symbol "stack_user" in current context.
(gdb) p __stack_user
$1 = -1209776352
(gdb) p &__stack_user
$2 = (<data variable, no debug info> *) 0xb7fa5160 
(gdb) quit

$ cd /usr/lib/debug/lib
$ cd
$ nm -S libpthread-2.10.2.so | grep __stack_user
00017160 00000008 b __GI___stack_user
00017160 00000008 b __stack_user
$ nm -S libpthread-2.10.2.so | grep stack_used
0001511c 00000008 d stack_used

I'm currently stucked with this, I really cannot say if it is a
problem with what I'm doing or with some debian specific issue.

I'll be grateful for any advice.
 
> One could hack it more using just offsets without any struct definitions but
> it was just a proof-of-concept hack the info is in the core file.  One should
> just apply libthread_db even on the core files.

Best regards.

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

[Jan Kratochvil]

On Mon, 26 Apr 2010 10:38:09 +0200, Stefano Sabatini wrote:
> $ cd /usr/lib/debug/lib
> $ cd
> $ nm -S libpthread-2.10.2.so | grep __stack_user
> 00017160 00000008 b __GI___stack_user
> 00017160 00000008 b __stack_user
> $ nm -S libpthread-2.10.2.so | grep stack_used
> 0001511c 00000008 d stack_used

You should have DWARFs symbols.  The ELF symbols are not enough for structures
derefencing.

readelf -wi /usr/lib/debug/lib64/libpthread.so.0.debug
[ formatted a bit ]
 <1><9304>: Abbrev Number: 111 (DW_TAG_variable)
    <9305>   DW_AT_name        : (indirect string, offset: 0x300b): __stack_user
    <930f>   DW_AT_type        : <0x461b>
    <9313>   DW_AT_external    : 1
    <9314>   DW_AT_location    : 9 byte block: 3 80 b2 21 0 0 0 0 0     (DW_OP_addr: 21b280)
 <1><461b>: Abbrev Number: 3 (DW_TAG_typedef)
    <461c>   DW_AT_name        : (indirect string, offset: 0x7f8): list_t
    <4622>   DW_AT_type        : <0x45f0>
 <1><45f0>: Abbrev Number: 14 (DW_TAG_structure_type)
    <45f1>   DW_AT_name        : (indirect string, offset: 0x2469): list_head
    <45f5>   DW_AT_byte_size   : 16
 <2><45fc>: Abbrev Number: 11 (DW_TAG_member)
    <45fd>   DW_AT_name        : (indirect string, offset: 0x169d): next
    <4603>   DW_AT_type        : <0x4615>
    <4607>   DW_AT_data_member_location: 0
 <2><4608>: Abbrev Number: 11 (DW_TAG_member)
    <4609>   DW_AT_name        : (indirect string, offset: 0x1303): prev
    <460f>   DW_AT_type        : <0x4615>
    <4613>   DW_AT_data_member_location: 8

Anyway these symbols are not required for the right way of traversing this
list.  For that purpose (as being used for native non-core `info threads') GDB
just calls functions provided by /lib64/libthread_db.so.1 . You can check glibc
sources for nptl_db/td_ta_thr_iter.c . nptl_db uses simple ELF symbols not
requiring the debuginfo files, like this one:
$ gdb -q -ex 'p *(int *)_thread_db_pthread_list' -ex q /lib64/libpthread.so.0
$1 = 128


> I'm currently stucked with this, I really cannot say if it is a
> problem with what I'm doing or with some debian specific issue.

If Debian GDB cannot find the symbols guessing Debian probably has more light
(smaller) debug info packages.


Regards,
Jan

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

[Stefano Sabatini]

On Monday 2010-04-26 11:03:57 +0200, Jan Kratochvil wrote:
> On Mon, 26 Apr 2010 10:38:09 +0200, Stefano Sabatini wrote:
> > $ cd /usr/lib/debug/lib
> > $ cd
> > $ nm -S libpthread-2.10.2.so | grep __stack_user
> > 00017160 00000008 b __GI___stack_user
> > 00017160 00000008 b __stack_user
> > $ nm -S libpthread-2.10.2.so | grep stack_used
> > 0001511c 00000008 d stack_used
> 
> You should have DWARFs symbols.  The ELF symbols are not enough for structures
> derefencing.
> 
> readelf -wi /usr/lib/debug/lib64/libpthread.so.0.debug
> [ formatted a bit ]
>  <1><9304>: Abbrev Number: 111 (DW_TAG_variable)
>     <9305>   DW_AT_name        : (indirect string, offset: 0x300b): __stack_user
>     <930f>   DW_AT_type        : <0x461b>
>     <9313>   DW_AT_external    : 1
>     <9314>   DW_AT_location    : 9 byte block: 3 80 b2 21 0 0 0 0 0     (DW_OP_addr: 21b280)
>  <1><461b>: Abbrev Number: 3 (DW_TAG_typedef)
>     <461c>   DW_AT_name        : (indirect string, offset: 0x7f8): list_t
>     <4622>   DW_AT_type        : <0x45f0>
>  <1><45f0>: Abbrev Number: 14 (DW_TAG_structure_type)
>     <45f1>   DW_AT_name        : (indirect string, offset: 0x2469): list_head
>     <45f5>   DW_AT_byte_size   : 16
>  <2><45fc>: Abbrev Number: 11 (DW_TAG_member)
>     <45fd>   DW_AT_name        : (indirect string, offset: 0x169d): next
>     <4603>   DW_AT_type        : <0x4615>
>     <4607>   DW_AT_data_member_location: 0
>  <2><4608>: Abbrev Number: 11 (DW_TAG_member)
>     <4609>   DW_AT_name        : (indirect string, offset: 0x1303): prev
>     <460f>   DW_AT_type        : <0x4615>
>     <4613>   DW_AT_data_member_location: 8
> 
> Anyway these symbols are not required for the right way of traversing this
> list.  For that purpose (as being used for native non-core `info threads') GDB
> just calls functions provided by /lib64/libthread_db.so.1 . You can check glibc
> sources for nptl_db/td_ta_thr_iter.c . nptl_db uses simple ELF symbols not
> requiring the debuginfo files, like this one:
> $ gdb -q -ex 'p *(int *)_thread_db_pthread_list' -ex q /lib64/libpthread.so.0
> $1 = 128
> 
> 
> > I'm currently stucked with this, I really cannot say if it is a
> > problem with what I'm doing or with some debian specific issue.
> 
> If Debian GDB cannot find the symbols guessing Debian probably has more light
> (smaller) debug info packages.

Can you suggest a command I can use to check this?

Thanks, regards.

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

[Jan Kratochvil]

On Mon, 26 Apr 2010 13:07:18 +0200, Stefano Sabatini wrote:
> On Monday 2010-04-26 11:03:57 +0200, Jan Kratochvil wrote:
> > On Mon, 26 Apr 2010 10:38:09 +0200, Stefano Sabatini wrote:
> > readelf -wi /usr/lib/debug/lib64/libpthread.so.0.debug
> > [ formatted a bit ]
> >  <1><9304>: Abbrev Number: 111 (DW_TAG_variable)
> >     <9305>   DW_AT_name        : (indirect string, offset: 0x300b): __stack_user
> >     <930f>   DW_AT_type        : <0x461b>
> >     <9313>   DW_AT_external    : 1
> >     <9314>   DW_AT_location    : 9 byte block: 3 80 b2 21 0 0 0 0 0     (DW_OP_addr: 21b280)
> >  <1><461b>: Abbrev Number: 3 (DW_TAG_typedef)
> >     <461c>   DW_AT_name        : (indirect string, offset: 0x7f8): list_t
...
> > If Debian GDB cannot find the symbols guessing Debian probably has more light
> > (smaller) debug info packages.
> 
> Can you suggest a command I can use to check this?

It was that "readelf -wi" command above, with some appropriate path to your
libpthread separate debug info file.  Search in its output for appropriate
definitions (which should be obvious without reading the DWARF documentation).


Regards,
Jan

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

[Pedro Alves]

[Mark, patch below]

On Friday 23 April 2010 16:51:31, Pedro Alves wrote:
> On Friday 23 April 2010 16:36:01, Mark Kettenis wrote:
> > > From: Pedro Alves <pedro@codesourcery.com>
> 
> > > > 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.

Here's a patch.  Keeping "LWP" for linux, as that's
what linux-nat.c prints (probably since ever), so that
we're consistent.  I've added linux_init_abi, for common
GNU/Linux osabi stuff, and, added a cygwin callback
so that it keeps printing "Thread".

WDYT?

-- 
Pedro Alves

2010-08-04  Pedro Alves  <pedro@codesourcery.com>

	* corelow.c (core_pid_to_str): Default to using normal_pid_to_str
	instead of printing "Thread" here.
	* linux-tdep.c: Include inferior.h.
	(linux_core_pid_to_str): New.
	(linux_init_abi): New.
	* linux-tdep.h (linux_init_abi): Declare.
	* alpha-linux-tdep.c: Include linux-tdep.h.
	(alpha_linux_init_abi): Call linux_init_abi.
	* amd64-linux-tdep.c (amd64_linux_init_abi): Call linux_init_abi.
	* arm-linux-tdep.c (arm_linux_init_abi): Call linux_init_abi.
	* frv-linux-tdep.c: Include linux-tdep.h
	(frv_linux_init_abi): Call linux_init_abi.
	* hppa-linux-tdep.c: Include linux-tdep.h
	(hppa_linux_init_abi): Call linux_init_abi.
	* i386-linux-tdep.c (i386_linux_init_abi): Call linux_init_abi.
	* ia64-linux-tdep.c: Include linux-tdep.h.
	(ia64_linux_init_abi): Call linux_init_abi.
	* m32r-linux-tdep.c: Include linux-tdep.h.
	(m32r_linux_init_abi): Call linux_init_abi.
	* m68klinux-tdep.c: Include linux-tdep.h.
	(m68k_linux_init_abi): Call linux_init_abi.
	* microblaze-linux-tdep.c: Include linux-tdep.h.
	(microblaze_linux_init_abi): Call linux_init_abi.
	* mips-linux-tdep.c: Include linux-tdep.h.
	(mips_linux_init_abi): Call linux_init_abi.
	* mn10300-linux-tdep.c: Include linux-tdep.h.
	(am33_linux_init_osabi): Call linux_init_abi.  Rename the
	'gdbinfo' parameter to 'info'.
	* ppc-linux-tdep.c: Include linux-tdep.h.
	(ppc_linux_init_abi): Call linux_init_abi.
	* sh-linux-tdep.c: Include linux-tdep.h.
	(sh_linux_init_abi): Call linux_init_abi.
	* sparc-linux-tdep.c: Include linux-tdep.h.
	(sparc32_linux_init_abi): Call linux_init_abi.
	* sparc64-linux-tdep.c: Include linux-tdep.h.
	(sparc64_linux_init_abi): Call linux_init_abi.
	* xtensa-linux-tdep.c: Include linux-tdep.h.
	(xtensa_linux_init_abi): Call linux_init_abi.
	* i386-cygwin-tdep.c (i386_windows_core_pid_to_str): New.
	(i386_cygwin_init_abi): Install it as gdbarch_core_pid_to_str
	callback.

---
 gdb/alpha-linux-tdep.c      |    4 +++-
 gdb/amd64-linux-tdep.c      |    2 ++
 gdb/arm-linux-tdep.c        |    2 ++
 gdb/corelow.c               |   28 ++++++++++++++++++----------
 gdb/frv-linux-tdep.c        |    4 ++++
 gdb/hppa-linux-tdep.c       |    4 +++-
 gdb/i386-cygwin-tdep.c      |   18 ++++++++++++++++++
 gdb/i386-linux-tdep.c       |    2 ++
 gdb/ia64-linux-tdep.c       |    3 +++
 gdb/linux-tdep.c            |   26 ++++++++++++++++++++++++++
 gdb/linux-tdep.h            |    2 ++
 gdb/m32r-linux-tdep.c       |    4 ++++
 gdb/m68klinux-tdep.c        |    3 +++
 gdb/microblaze-linux-tdep.c |    4 +++-
 gdb/mips-linux-tdep.c       |    3 +++
 gdb/mn10300-linux-tdep.c    |    5 ++++-
 gdb/ppc-linux-tdep.c        |    3 +++
 gdb/sh-linux-tdep.c         |    3 +++
 gdb/sparc-linux-tdep.c      |    3 +++
 gdb/sparc64-linux-tdep.c    |    3 +++
 gdb/xtensa-linux-tdep.c     |    4 +++-
 21 files changed, 115 insertions(+), 15 deletions(-)

Index: src/gdb/corelow.c
===================================================================
--- src.orig/gdb/corelow.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/corelow.c	2010-08-04 15:18:11.000000000 +0100
@@ -853,21 +853,29 @@ static char *
 core_pid_to_str (struct target_ops *ops, ptid_t ptid)
 {
   static char buf[64];
+  int pid;
 
+  /* The preferred way is to have a gdbarch/OS specific
+     implementation.  */
   if (core_gdbarch
       && gdbarch_core_pid_to_str_p (core_gdbarch))
-    {
-      char *ret = gdbarch_core_pid_to_str (core_gdbarch, ptid);
+    return 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));
+  /* Otherwise, if we don't have one, we'll just fallback to
+     "process", with normal_pid_to_str.  */
 
+  /* Try the LWPID field first.  */
+  pid = ptid_get_lwp (ptid);
+  if (pid != 0)
+    return normal_pid_to_str (pid_to_ptid (pid));
+
+  /* Otherwise, this isn't a "threaded" core -- use the PID field, but
+     only if it isn't a fake PID.  */
+  if (!core_has_fake_pid)
+    return normal_pid_to_str (ptid);
+
+  /* No luck.  We simply don't have a valid PID to print.  */
+  xsnprintf (buf, sizeof buf, "<main task>");
   return buf;
 }
 
Index: src/gdb/linux-tdep.c
===================================================================
--- src.orig/gdb/linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/linux-tdep.c	2010-08-04 15:27:56.000000000 +0100
@@ -23,6 +23,7 @@
 #include "auxv.h"
 #include "target.h"
 #include "elf/common.h"
+#include "inferior.h"
 
 /* This function is suitable for architectures that don't
    extend/override the standard siginfo structure.  */
@@ -152,3 +153,28 @@ linux_has_shared_address_space (void)
 
   return target_is_uclinux;
 }
+
+/* This is how we want PTIDs from core files to be printed.  */
+
+static char *
+linux_core_pid_to_str (struct gdbarch *gdbarch, ptid_t ptid)
+{
+  static char buf[80];
+
+  if (ptid_get_lwp (ptid) != 0)
+    {
+      snprintf (buf, sizeof (buf), "LWP %ld", ptid_get_lwp (ptid));
+      return buf;
+    }
+
+  return normal_pid_to_str (ptid);
+}
+
+/* To be called from the various GDB_OSABI_LINUX handlers for the
+   various GNU/Linux architectures and machine types.  */
+
+void
+linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
+{
+  set_gdbarch_core_pid_to_str (gdbarch, linux_core_pid_to_str);
+}
Index: src/gdb/linux-tdep.h
===================================================================
--- src.orig/gdb/linux-tdep.h	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/linux-tdep.h	2010-08-03 18:42:20.000000000 +0100
@@ -22,4 +22,6 @@
 
 struct type *linux_get_siginfo_type (struct gdbarch *);
 
+extern void linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch);
+
 #endif /* linux-tdep.h */
Index: src/gdb/alpha-linux-tdep.c
===================================================================
--- src.orig/gdb/alpha-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/alpha-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
@@ -26,7 +26,7 @@
 #include "symtab.h"
 #include "regset.h"
 #include "regcache.h"
-
+#include "linux-tdep.h"
 #include "alpha-tdep.h"
 
 /* Under GNU/Linux, signal handler invocations can be identified by
@@ -212,6 +212,8 @@ alpha_linux_init_abi (struct gdbarch_inf
 {
   struct gdbarch_tdep *tdep;
 
+  linux_init_abi (info, gdbarch);
+
   /* Hook into the DWARF CFI frame unwinder.  */
   alpha_dwarf2_init_abi (info, gdbarch);
 
Index: src/gdb/amd64-linux-tdep.c
===================================================================
--- src.orig/gdb/amd64-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/amd64-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
@@ -1291,6 +1291,8 @@ amd64_linux_init_abi (struct gdbarch_inf
 
   gdb_assert (tdesc_data);
 
+  linux_init_abi (info, gdbarch);
+
   tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
   tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
   tdep->sizeof_gregset = 27 * 8;
Index: src/gdb/arm-linux-tdep.c
===================================================================
--- src.orig/gdb/arm-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/arm-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
@@ -862,6 +862,8 @@ arm_linux_init_abi (struct gdbarch_info 
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
 
+  linux_init_abi (info, gdbarch);
+
   tdep->lowest_pc = 0x8000;
   if (info.byte_order == BFD_ENDIAN_BIG)
     {
Index: src/gdb/frv-linux-tdep.c
===================================================================
--- src.orig/gdb/frv-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/frv-linux-tdep.c	2010-08-03 18:44:42.000000000 +0100
@@ -32,6 +32,7 @@
 #include "frame-unwind.h"
 #include "regset.h"
 #include "gdb_string.h"
+#include "linux-tdep.h"
 
 /* Define the size (in bytes) of an FR-V instruction.  */
 static const int frv_instr_size = 4;
@@ -490,8 +491,11 @@ frv_linux_regset_from_core_section (stru
 static void
 frv_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
 {
+  linux_init_abi (info, gdbarch);
+
   /* Set the sigtramp frame sniffer.  */
   frame_unwind_append_unwinder (gdbarch, &frv_linux_sigtramp_frame_unwind); 
+
   set_gdbarch_regset_from_core_section (gdbarch,
                                         frv_linux_regset_from_core_section);
 }
Index: src/gdb/hppa-linux-tdep.c
===================================================================
--- src.orig/gdb/hppa-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/hppa-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
@@ -32,7 +32,7 @@
 #include "regset.h"
 #include "regcache.h"
 #include "hppa-tdep.h"
-
+#include "linux-tdep.h"
 #include "elf/common.h"
 
 /* Map DWARF DBX register numbers to GDB register numbers.  */
@@ -523,6 +523,8 @@ hppa_linux_init_abi (struct gdbarch_info
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
 
+  linux_init_abi (info, gdbarch);
+
   /* GNU/Linux is always ELF.  */
   tdep->is_elf = 1;
 
Index: src/gdb/i386-linux-tdep.c
===================================================================
--- src.orig/gdb/i386-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/i386-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
@@ -654,6 +654,8 @@ i386_linux_init_abi (struct gdbarch_info
 
   gdb_assert (tdesc_data);
 
+  linux_init_abi (info, gdbarch);
+
   /* GNU/Linux uses ELF.  */
   i386_elf_init_abi (info, gdbarch);
 
Index: src/gdb/ia64-linux-tdep.c
===================================================================
--- src.orig/gdb/ia64-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/ia64-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
@@ -26,6 +26,7 @@
 #include "osabi.h"
 #include "solib-svr4.h"
 #include "symtab.h"
+#include "linux-tdep.h"
 
 /* The sigtramp code is in a non-readable (executable-only) region
    of memory called the ``gate page''.  The addresses in question
@@ -122,6 +123,8 @@ ia64_linux_init_abi (struct gdbarch_info
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
 
+  linux_init_abi (info, gdbarch);
+
   /* Set the method of obtaining the sigcontext addresses at which
      registers are saved.  */
   tdep->sigcontext_register_address = ia64_linux_sigcontext_register_address;
Index: src/gdb/m32r-linux-tdep.c
===================================================================
--- src.orig/gdb/m32r-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/m32r-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
@@ -37,6 +37,8 @@
 #include "frame-unwind.h"
 
 #include "m32r-tdep.h"
+#include "linux-tdep.h"
+
 \f
 
 /* Recognizing signal handler frames.  */
@@ -404,6 +406,8 @@ m32r_linux_init_abi (struct gdbarch_info
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
 
+  linux_init_abi (info, gdbarch);
+
   /* Since EVB register is not available for native debug, we reduce
      the number of registers.  */
   set_gdbarch_num_regs (gdbarch, M32R_NUM_REGS - 1);
Index: src/gdb/m68klinux-tdep.c
===================================================================
--- src.orig/gdb/m68klinux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/m68klinux-tdep.c	2010-08-03 18:42:20.000000000 +0100
@@ -38,6 +38,7 @@
 #include "auxv.h"
 #include "observer.h"
 #include "elf/common.h"
+#include "linux-tdep.h"
 \f
 /* Offsets (in target ints) into jmp_buf.  */
 
@@ -338,6 +339,8 @@ m68k_linux_init_abi (struct gdbarch_info
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
 
+  linux_init_abi (info, gdbarch);
+
   tdep->jb_pc = M68K_LINUX_JB_PC;
   tdep->jb_elt_size = M68K_LINUX_JB_ELEMENT_SIZE;
 
Index: src/gdb/microblaze-linux-tdep.c
===================================================================
--- src.orig/gdb/microblaze-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/microblaze-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
@@ -35,7 +35,7 @@
 #include "trad-frame.h"
 #include "frame-unwind.h"
 #include "tramp-frame.h"
-
+#include "linux-tdep.h"
 
 static int
 microblaze_linux_memory_remove_breakpoint (struct gdbarch *gdbarch, 
@@ -123,6 +123,8 @@ microblaze_linux_init_abi (struct gdbarc
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
 
+  linux_init_abi (info, gdbarch);
+
   set_gdbarch_memory_remove_breakpoint (gdbarch,
 					microblaze_linux_memory_remove_breakpoint);
 
Index: src/gdb/mips-linux-tdep.c
===================================================================
--- src.orig/gdb/mips-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/mips-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
@@ -38,6 +38,7 @@
 #include "target-descriptions.h"
 #include "mips-linux-tdep.h"
 #include "glibc-tdep.h"
+#include "linux-tdep.h"
 
 static struct target_so_ops mips_svr4_so_ops;
 
@@ -1140,6 +1141,8 @@ mips_linux_init_abi (struct gdbarch_info
   enum mips_abi abi = mips_abi (gdbarch);
   struct tdesc_arch_data *tdesc_data = (void *) info.tdep_info;
 
+  linux_init_abi (info, gdbarch);
+
   switch (abi)
     {
       case MIPS_ABI_O32:
Index: src/gdb/mn10300-linux-tdep.c
===================================================================
--- src.orig/gdb/mn10300-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/mn10300-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
@@ -32,6 +32,7 @@
 #include "frame.h"
 #include "trad-frame.h"
 #include "tramp-frame.h"
+#include "linux-tdep.h"
 
 #include <stdlib.h>
 
@@ -709,8 +710,10 @@ am33_linux_sigframe_cache_init (const st
    Now's our chance to register our corefile handling.  */
 
 static void
-am33_linux_init_osabi (struct gdbarch_info gdbinfo, struct gdbarch *gdbarch)
+am33_linux_init_osabi (struct gdbarch_info info, struct gdbarch *gdbarch)
 {
+  linux_init_abi (info, gdbarch);
+
   set_gdbarch_regset_from_core_section (gdbarch, 
 					am33_regset_from_core_section);
   set_solib_svr4_fetch_link_map_offsets
Index: src/gdb/ppc-linux-tdep.c
===================================================================
--- src.orig/gdb/ppc-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/ppc-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
@@ -48,6 +48,7 @@
 #include "arch-utils.h"
 #include "spu-tdep.h"
 #include "xml-syscall.h"
+#include "linux-tdep.h"
 
 #include "features/rs6000/powerpc-32l.c"
 #include "features/rs6000/powerpc-altivec32l.c"
@@ -1486,6 +1487,8 @@ ppc_linux_init_abi (struct gdbarch_info 
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
   struct tdesc_arch_data *tdesc_data = (void *) info.tdep_info;
 
+  linux_init_abi (info, gdbarch);
+
   /* PPC GNU/Linux uses either 64-bit or 128-bit long doubles; where
      128-bit, they are IBM long double, not IEEE quad long double as
      in the System V ABI PowerPC Processor Supplement.  We can safely
Index: src/gdb/sh-linux-tdep.c
===================================================================
--- src.orig/gdb/sh-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/sh-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
@@ -25,6 +25,7 @@
 
 #include "glibc-tdep.h"
 #include "sh-tdep.h"
+#include "linux-tdep.h"
 
 #define REGSx16(base) \
   {(base),      0}, \
@@ -72,6 +73,8 @@ static const struct sh_corefile_regmap f
 static void
 sh_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
 {
+  linux_init_abi (info, gdbarch);
+
   /* GNU/Linux uses SVR4-style shared libraries.  */
   set_gdbarch_skip_trampoline_code (gdbarch, find_solib_trampoline_target);
   set_solib_svr4_fetch_link_map_offsets
Index: src/gdb/sparc-linux-tdep.c
===================================================================
--- src.orig/gdb/sparc-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/sparc-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
@@ -33,6 +33,7 @@
 #include "trad-frame.h"
 #include "tramp-frame.h"
 #include "xml-syscall.h"
+#include "linux-tdep.h"
 
 /* The syscall's XML filename for sparc 32-bit.  */
 #define XML_SYSCALL_FILENAME_SPARC32 "syscalls/sparc-linux.xml"
@@ -273,6 +274,8 @@ sparc32_linux_init_abi (struct gdbarch_i
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
 
+  linux_init_abi (info, gdbarch);
+
   tdep->gregset = regset_alloc (gdbarch, sparc32_linux_supply_core_gregset,
 				sparc32_linux_collect_core_gregset);
   tdep->sizeof_gregset = 152;
Index: src/gdb/sparc64-linux-tdep.c
===================================================================
--- src.orig/gdb/sparc64-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/sparc64-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
@@ -32,6 +32,7 @@
 #include "trad-frame.h"
 #include "tramp-frame.h"
 #include "xml-syscall.h"
+#include "linux-tdep.h"
 
 /* The syscall's XML filename for sparc 64-bit.  */
 #define XML_SYSCALL_FILENAME_SPARC64 "syscalls/sparc64-linux.xml"
@@ -237,6 +238,8 @@ sparc64_linux_init_abi (struct gdbarch_i
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
 
+  linux_init_abi (info, gdbarch);
+
   tdep->gregset = regset_alloc (gdbarch, sparc64_linux_supply_core_gregset,
 				sparc64_linux_collect_core_gregset);
   tdep->sizeof_gregset = 288;
Index: src/gdb/xtensa-linux-tdep.c
===================================================================
--- src.orig/gdb/xtensa-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
+++ src/gdb/xtensa-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
@@ -19,7 +19,7 @@
 
 #include "defs.h"
 #include "osabi.h"
-
+#include "linux-tdep.h"
 #include "solib-svr4.h"
 #include "symtab.h"
 
@@ -28,6 +28,8 @@
 static void
 xtensa_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
 {
+  linux_init_abi (info, gdbarch);
+
   set_solib_svr4_fetch_link_map_offsets
     (gdbarch, svr4_ilp32_fetch_link_map_offsets);
 }
Index: src/gdb/i386-cygwin-tdep.c
===================================================================
--- src.orig/gdb/i386-cygwin-tdep.c	2010-06-16 10:55:17.000000000 +0100
+++ src/gdb/i386-cygwin-tdep.c	2010-08-04 13:43:27.000000000 +0100
@@ -28,6 +28,7 @@
 #include "gdbcore.h"
 #include "solib.h"
 #include "solib-target.h"
+#include "inferior.h"
 
 /* Core file support.  */
 
@@ -199,6 +200,22 @@ windows_core_xfer_shared_libraries (stru
   return len;
 }
 
+/* This is how we want PTIDs from core files to be printed.  */
+
+static char *
+i386_windows_core_pid_to_str (struct gdbarch *gdbarch, ptid_t ptid)
+{
+  static char buf[80];
+
+  if (ptid_get_lwp (ptid) != 0)
+    {
+      snprintf (buf, sizeof (buf), "Thread 0x%lx", ptid_get_lwp (ptid));
+      return buf;
+    }
+
+  return normal_pid_to_str (ptid);
+}
+
 static CORE_ADDR
 i386_cygwin_skip_trampoline_code (struct frame_info *frame, CORE_ADDR pc)
 {
@@ -233,6 +250,7 @@ i386_cygwin_init_abi (struct gdbarch_inf
     (gdbarch, i386_windows_regset_from_core_section);
   set_gdbarch_core_xfer_shared_libraries
     (gdbarch, windows_core_xfer_shared_libraries);
+  set_gdbarch_core_pid_to_str (gdbarch, i386_windows_core_pid_to_str);
 
   set_gdbarch_auto_wide_charset (gdbarch, i386_cygwin_auto_wide_charset);
 

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

[Mark Kettenis]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Wed, 4 Aug 2010 15:35:43 +0100

> [Mark, patch below]
> 
> On Friday 23 April 2010 16:51:31, Pedro Alves wrote:
> > On Friday 23 April 2010 16:36:01, Mark Kettenis wrote:
> > > > From: Pedro Alves <pedro@codesourcery.com>
> > 
> > > > > 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.
> 
> Here's a patch.  Keeping "LWP" for linux, as that's
> what linux-nat.c prints (probably since ever), so that
> we're consistent.  I've added linux_init_abi, for common
> GNU/Linux osabi stuff, and, added a cygwin callback
> so that it keeps printing "Thread".
> 
> WDYT?

Looks good to me.  I like linux_init_abi(); there's plenty more stuff
that could be moved there!


> 2010-08-04  Pedro Alves  <pedro@codesourcery.com>
> 
> 	* corelow.c (core_pid_to_str): Default to using normal_pid_to_str
> 	instead of printing "Thread" here.
> 	* linux-tdep.c: Include inferior.h.
> 	(linux_core_pid_to_str): New.
> 	(linux_init_abi): New.
> 	* linux-tdep.h (linux_init_abi): Declare.
> 	* alpha-linux-tdep.c: Include linux-tdep.h.
> 	(alpha_linux_init_abi): Call linux_init_abi.
> 	* amd64-linux-tdep.c (amd64_linux_init_abi): Call linux_init_abi.
> 	* arm-linux-tdep.c (arm_linux_init_abi): Call linux_init_abi.
> 	* frv-linux-tdep.c: Include linux-tdep.h
> 	(frv_linux_init_abi): Call linux_init_abi.
> 	* hppa-linux-tdep.c: Include linux-tdep.h
> 	(hppa_linux_init_abi): Call linux_init_abi.
> 	* i386-linux-tdep.c (i386_linux_init_abi): Call linux_init_abi.
> 	* ia64-linux-tdep.c: Include linux-tdep.h.
> 	(ia64_linux_init_abi): Call linux_init_abi.
> 	* m32r-linux-tdep.c: Include linux-tdep.h.
> 	(m32r_linux_init_abi): Call linux_init_abi.
> 	* m68klinux-tdep.c: Include linux-tdep.h.
> 	(m68k_linux_init_abi): Call linux_init_abi.
> 	* microblaze-linux-tdep.c: Include linux-tdep.h.
> 	(microblaze_linux_init_abi): Call linux_init_abi.
> 	* mips-linux-tdep.c: Include linux-tdep.h.
> 	(mips_linux_init_abi): Call linux_init_abi.
> 	* mn10300-linux-tdep.c: Include linux-tdep.h.
> 	(am33_linux_init_osabi): Call linux_init_abi.  Rename the
> 	'gdbinfo' parameter to 'info'.
> 	* ppc-linux-tdep.c: Include linux-tdep.h.
> 	(ppc_linux_init_abi): Call linux_init_abi.
> 	* sh-linux-tdep.c: Include linux-tdep.h.
> 	(sh_linux_init_abi): Call linux_init_abi.
> 	* sparc-linux-tdep.c: Include linux-tdep.h.
> 	(sparc32_linux_init_abi): Call linux_init_abi.
> 	* sparc64-linux-tdep.c: Include linux-tdep.h.
> 	(sparc64_linux_init_abi): Call linux_init_abi.
> 	* xtensa-linux-tdep.c: Include linux-tdep.h.
> 	(xtensa_linux_init_abi): Call linux_init_abi.
> 	* i386-cygwin-tdep.c (i386_windows_core_pid_to_str): New.
> 	(i386_cygwin_init_abi): Install it as gdbarch_core_pid_to_str
> 	callback.
> 
> ---
>  gdb/alpha-linux-tdep.c      |    4 +++-
>  gdb/amd64-linux-tdep.c      |    2 ++
>  gdb/arm-linux-tdep.c        |    2 ++
>  gdb/corelow.c               |   28 ++++++++++++++++++----------
>  gdb/frv-linux-tdep.c        |    4 ++++
>  gdb/hppa-linux-tdep.c       |    4 +++-
>  gdb/i386-cygwin-tdep.c      |   18 ++++++++++++++++++
>  gdb/i386-linux-tdep.c       |    2 ++
>  gdb/ia64-linux-tdep.c       |    3 +++
>  gdb/linux-tdep.c            |   26 ++++++++++++++++++++++++++
>  gdb/linux-tdep.h            |    2 ++
>  gdb/m32r-linux-tdep.c       |    4 ++++
>  gdb/m68klinux-tdep.c        |    3 +++
>  gdb/microblaze-linux-tdep.c |    4 +++-
>  gdb/mips-linux-tdep.c       |    3 +++
>  gdb/mn10300-linux-tdep.c    |    5 ++++-
>  gdb/ppc-linux-tdep.c        |    3 +++
>  gdb/sh-linux-tdep.c         |    3 +++
>  gdb/sparc-linux-tdep.c      |    3 +++
>  gdb/sparc64-linux-tdep.c    |    3 +++
>  gdb/xtensa-linux-tdep.c     |    4 +++-
>  21 files changed, 115 insertions(+), 15 deletions(-)
> 
> Index: src/gdb/corelow.c
> ===================================================================
> --- src.orig/gdb/corelow.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/corelow.c	2010-08-04 15:18:11.000000000 +0100
> @@ -853,21 +853,29 @@ static char *
>  core_pid_to_str (struct target_ops *ops, ptid_t ptid)
>  {
>    static char buf[64];
> +  int pid;
>  
> +  /* The preferred way is to have a gdbarch/OS specific
> +     implementation.  */
>    if (core_gdbarch
>        && gdbarch_core_pid_to_str_p (core_gdbarch))
> -    {
> -      char *ret = gdbarch_core_pid_to_str (core_gdbarch, ptid);
> +    return 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));
> +  /* Otherwise, if we don't have one, we'll just fallback to
> +     "process", with normal_pid_to_str.  */
>  
> +  /* Try the LWPID field first.  */
> +  pid = ptid_get_lwp (ptid);
> +  if (pid != 0)
> +    return normal_pid_to_str (pid_to_ptid (pid));
> +
> +  /* Otherwise, this isn't a "threaded" core -- use the PID field, but
> +     only if it isn't a fake PID.  */
> +  if (!core_has_fake_pid)
> +    return normal_pid_to_str (ptid);
> +
> +  /* No luck.  We simply don't have a valid PID to print.  */
> +  xsnprintf (buf, sizeof buf, "<main task>");
>    return buf;
>  }
>  
> Index: src/gdb/linux-tdep.c
> ===================================================================
> --- src.orig/gdb/linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/linux-tdep.c	2010-08-04 15:27:56.000000000 +0100
> @@ -23,6 +23,7 @@
>  #include "auxv.h"
>  #include "target.h"
>  #include "elf/common.h"
> +#include "inferior.h"
>  
>  /* This function is suitable for architectures that don't
>     extend/override the standard siginfo structure.  */
> @@ -152,3 +153,28 @@ linux_has_shared_address_space (void)
>  
>    return target_is_uclinux;
>  }
> +
> +/* This is how we want PTIDs from core files to be printed.  */
> +
> +static char *
> +linux_core_pid_to_str (struct gdbarch *gdbarch, ptid_t ptid)
> +{
> +  static char buf[80];
> +
> +  if (ptid_get_lwp (ptid) != 0)
> +    {
> +      snprintf (buf, sizeof (buf), "LWP %ld", ptid_get_lwp (ptid));
> +      return buf;
> +    }
> +
> +  return normal_pid_to_str (ptid);
> +}
> +
> +/* To be called from the various GDB_OSABI_LINUX handlers for the
> +   various GNU/Linux architectures and machine types.  */
> +
> +void
> +linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
> +{
> +  set_gdbarch_core_pid_to_str (gdbarch, linux_core_pid_to_str);
> +}
> Index: src/gdb/linux-tdep.h
> ===================================================================
> --- src.orig/gdb/linux-tdep.h	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/linux-tdep.h	2010-08-03 18:42:20.000000000 +0100
> @@ -22,4 +22,6 @@
>  
>  struct type *linux_get_siginfo_type (struct gdbarch *);
>  
> +extern void linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch);
> +
>  #endif /* linux-tdep.h */
> Index: src/gdb/alpha-linux-tdep.c
> ===================================================================
> --- src.orig/gdb/alpha-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/alpha-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
> @@ -26,7 +26,7 @@
>  #include "symtab.h"
>  #include "regset.h"
>  #include "regcache.h"
> -
> +#include "linux-tdep.h"
>  #include "alpha-tdep.h"
>  
>  /* Under GNU/Linux, signal handler invocations can be identified by
> @@ -212,6 +212,8 @@ alpha_linux_init_abi (struct gdbarch_inf
>  {
>    struct gdbarch_tdep *tdep;
>  
> +  linux_init_abi (info, gdbarch);
> +
>    /* Hook into the DWARF CFI frame unwinder.  */
>    alpha_dwarf2_init_abi (info, gdbarch);
>  
> Index: src/gdb/amd64-linux-tdep.c
> ===================================================================
> --- src.orig/gdb/amd64-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/amd64-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
> @@ -1291,6 +1291,8 @@ amd64_linux_init_abi (struct gdbarch_inf
>  
>    gdb_assert (tdesc_data);
>  
> +  linux_init_abi (info, gdbarch);
> +
>    tdep->gregset_reg_offset = amd64_linux_gregset_reg_offset;
>    tdep->gregset_num_regs = ARRAY_SIZE (amd64_linux_gregset_reg_offset);
>    tdep->sizeof_gregset = 27 * 8;
> Index: src/gdb/arm-linux-tdep.c
> ===================================================================
> --- src.orig/gdb/arm-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/arm-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
> @@ -862,6 +862,8 @@ arm_linux_init_abi (struct gdbarch_info 
>  {
>    struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>  
> +  linux_init_abi (info, gdbarch);
> +
>    tdep->lowest_pc = 0x8000;
>    if (info.byte_order == BFD_ENDIAN_BIG)
>      {
> Index: src/gdb/frv-linux-tdep.c
> ===================================================================
> --- src.orig/gdb/frv-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/frv-linux-tdep.c	2010-08-03 18:44:42.000000000 +0100
> @@ -32,6 +32,7 @@
>  #include "frame-unwind.h"
>  #include "regset.h"
>  #include "gdb_string.h"
> +#include "linux-tdep.h"
>  
>  /* Define the size (in bytes) of an FR-V instruction.  */
>  static const int frv_instr_size = 4;
> @@ -490,8 +491,11 @@ frv_linux_regset_from_core_section (stru
>  static void
>  frv_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
>  {
> +  linux_init_abi (info, gdbarch);
> +
>    /* Set the sigtramp frame sniffer.  */
>    frame_unwind_append_unwinder (gdbarch, &frv_linux_sigtramp_frame_unwind); 
> +
>    set_gdbarch_regset_from_core_section (gdbarch,
>                                          frv_linux_regset_from_core_section);
>  }
> Index: src/gdb/hppa-linux-tdep.c
> ===================================================================
> --- src.orig/gdb/hppa-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/hppa-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
> @@ -32,7 +32,7 @@
>  #include "regset.h"
>  #include "regcache.h"
>  #include "hppa-tdep.h"
> -
> +#include "linux-tdep.h"
>  #include "elf/common.h"
>  
>  /* Map DWARF DBX register numbers to GDB register numbers.  */
> @@ -523,6 +523,8 @@ hppa_linux_init_abi (struct gdbarch_info
>  {
>    struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>  
> +  linux_init_abi (info, gdbarch);
> +
>    /* GNU/Linux is always ELF.  */
>    tdep->is_elf = 1;
>  
> Index: src/gdb/i386-linux-tdep.c
> ===================================================================
> --- src.orig/gdb/i386-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/i386-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
> @@ -654,6 +654,8 @@ i386_linux_init_abi (struct gdbarch_info
>  
>    gdb_assert (tdesc_data);
>  
> +  linux_init_abi (info, gdbarch);
> +
>    /* GNU/Linux uses ELF.  */
>    i386_elf_init_abi (info, gdbarch);
>  
> Index: src/gdb/ia64-linux-tdep.c
> ===================================================================
> --- src.orig/gdb/ia64-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/ia64-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
> @@ -26,6 +26,7 @@
>  #include "osabi.h"
>  #include "solib-svr4.h"
>  #include "symtab.h"
> +#include "linux-tdep.h"
>  
>  /* The sigtramp code is in a non-readable (executable-only) region
>     of memory called the ``gate page''.  The addresses in question
> @@ -122,6 +123,8 @@ ia64_linux_init_abi (struct gdbarch_info
>  {
>    struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>  
> +  linux_init_abi (info, gdbarch);
> +
>    /* Set the method of obtaining the sigcontext addresses at which
>       registers are saved.  */
>    tdep->sigcontext_register_address = ia64_linux_sigcontext_register_address;
> Index: src/gdb/m32r-linux-tdep.c
> ===================================================================
> --- src.orig/gdb/m32r-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/m32r-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
> @@ -37,6 +37,8 @@
>  #include "frame-unwind.h"
>  
>  #include "m32r-tdep.h"
> +#include "linux-tdep.h"
> +
>  \f
>  
>  /* Recognizing signal handler frames.  */
> @@ -404,6 +406,8 @@ m32r_linux_init_abi (struct gdbarch_info
>  {
>    struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>  
> +  linux_init_abi (info, gdbarch);
> +
>    /* Since EVB register is not available for native debug, we reduce
>       the number of registers.  */
>    set_gdbarch_num_regs (gdbarch, M32R_NUM_REGS - 1);
> Index: src/gdb/m68klinux-tdep.c
> ===================================================================
> --- src.orig/gdb/m68klinux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/m68klinux-tdep.c	2010-08-03 18:42:20.000000000 +0100
> @@ -38,6 +38,7 @@
>  #include "auxv.h"
>  #include "observer.h"
>  #include "elf/common.h"
> +#include "linux-tdep.h"
>  \f
>  /* Offsets (in target ints) into jmp_buf.  */
>  
> @@ -338,6 +339,8 @@ m68k_linux_init_abi (struct gdbarch_info
>  {
>    struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>  
> +  linux_init_abi (info, gdbarch);
> +
>    tdep->jb_pc = M68K_LINUX_JB_PC;
>    tdep->jb_elt_size = M68K_LINUX_JB_ELEMENT_SIZE;
>  
> Index: src/gdb/microblaze-linux-tdep.c
> ===================================================================
> --- src.orig/gdb/microblaze-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/microblaze-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
> @@ -35,7 +35,7 @@
>  #include "trad-frame.h"
>  #include "frame-unwind.h"
>  #include "tramp-frame.h"
> -
> +#include "linux-tdep.h"
>  
>  static int
>  microblaze_linux_memory_remove_breakpoint (struct gdbarch *gdbarch, 
> @@ -123,6 +123,8 @@ microblaze_linux_init_abi (struct gdbarc
>  {
>    struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>  
> +  linux_init_abi (info, gdbarch);
> +
>    set_gdbarch_memory_remove_breakpoint (gdbarch,
>  					microblaze_linux_memory_remove_breakpoint);
>  
> Index: src/gdb/mips-linux-tdep.c
> ===================================================================
> --- src.orig/gdb/mips-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/mips-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
> @@ -38,6 +38,7 @@
>  #include "target-descriptions.h"
>  #include "mips-linux-tdep.h"
>  #include "glibc-tdep.h"
> +#include "linux-tdep.h"
>  
>  static struct target_so_ops mips_svr4_so_ops;
>  
> @@ -1140,6 +1141,8 @@ mips_linux_init_abi (struct gdbarch_info
>    enum mips_abi abi = mips_abi (gdbarch);
>    struct tdesc_arch_data *tdesc_data = (void *) info.tdep_info;
>  
> +  linux_init_abi (info, gdbarch);
> +
>    switch (abi)
>      {
>        case MIPS_ABI_O32:
> Index: src/gdb/mn10300-linux-tdep.c
> ===================================================================
> --- src.orig/gdb/mn10300-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/mn10300-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
> @@ -32,6 +32,7 @@
>  #include "frame.h"
>  #include "trad-frame.h"
>  #include "tramp-frame.h"
> +#include "linux-tdep.h"
>  
>  #include <stdlib.h>
>  
> @@ -709,8 +710,10 @@ am33_linux_sigframe_cache_init (const st
>     Now's our chance to register our corefile handling.  */
>  
>  static void
> -am33_linux_init_osabi (struct gdbarch_info gdbinfo, struct gdbarch *gdbarch)
> +am33_linux_init_osabi (struct gdbarch_info info, struct gdbarch *gdbarch)
>  {
> +  linux_init_abi (info, gdbarch);
> +
>    set_gdbarch_regset_from_core_section (gdbarch, 
>  					am33_regset_from_core_section);
>    set_solib_svr4_fetch_link_map_offsets
> Index: src/gdb/ppc-linux-tdep.c
> ===================================================================
> --- src.orig/gdb/ppc-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/ppc-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
> @@ -48,6 +48,7 @@
>  #include "arch-utils.h"
>  #include "spu-tdep.h"
>  #include "xml-syscall.h"
> +#include "linux-tdep.h"
>  
>  #include "features/rs6000/powerpc-32l.c"
>  #include "features/rs6000/powerpc-altivec32l.c"
> @@ -1486,6 +1487,8 @@ ppc_linux_init_abi (struct gdbarch_info 
>    struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>    struct tdesc_arch_data *tdesc_data = (void *) info.tdep_info;
>  
> +  linux_init_abi (info, gdbarch);
> +
>    /* PPC GNU/Linux uses either 64-bit or 128-bit long doubles; where
>       128-bit, they are IBM long double, not IEEE quad long double as
>       in the System V ABI PowerPC Processor Supplement.  We can safely
> Index: src/gdb/sh-linux-tdep.c
> ===================================================================
> --- src.orig/gdb/sh-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/sh-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
> @@ -25,6 +25,7 @@
>  
>  #include "glibc-tdep.h"
>  #include "sh-tdep.h"
> +#include "linux-tdep.h"
>  
>  #define REGSx16(base) \
>    {(base),      0}, \
> @@ -72,6 +73,8 @@ static const struct sh_corefile_regmap f
>  static void
>  sh_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
>  {
> +  linux_init_abi (info, gdbarch);
> +
>    /* GNU/Linux uses SVR4-style shared libraries.  */
>    set_gdbarch_skip_trampoline_code (gdbarch, find_solib_trampoline_target);
>    set_solib_svr4_fetch_link_map_offsets
> Index: src/gdb/sparc-linux-tdep.c
> ===================================================================
> --- src.orig/gdb/sparc-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/sparc-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
> @@ -33,6 +33,7 @@
>  #include "trad-frame.h"
>  #include "tramp-frame.h"
>  #include "xml-syscall.h"
> +#include "linux-tdep.h"
>  
>  /* The syscall's XML filename for sparc 32-bit.  */
>  #define XML_SYSCALL_FILENAME_SPARC32 "syscalls/sparc-linux.xml"
> @@ -273,6 +274,8 @@ sparc32_linux_init_abi (struct gdbarch_i
>  {
>    struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>  
> +  linux_init_abi (info, gdbarch);
> +
>    tdep->gregset = regset_alloc (gdbarch, sparc32_linux_supply_core_gregset,
>  				sparc32_linux_collect_core_gregset);
>    tdep->sizeof_gregset = 152;
> Index: src/gdb/sparc64-linux-tdep.c
> ===================================================================
> --- src.orig/gdb/sparc64-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/sparc64-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
> @@ -32,6 +32,7 @@
>  #include "trad-frame.h"
>  #include "tramp-frame.h"
>  #include "xml-syscall.h"
> +#include "linux-tdep.h"
>  
>  /* The syscall's XML filename for sparc 64-bit.  */
>  #define XML_SYSCALL_FILENAME_SPARC64 "syscalls/sparc64-linux.xml"
> @@ -237,6 +238,8 @@ sparc64_linux_init_abi (struct gdbarch_i
>  {
>    struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
>  
> +  linux_init_abi (info, gdbarch);
> +
>    tdep->gregset = regset_alloc (gdbarch, sparc64_linux_supply_core_gregset,
>  				sparc64_linux_collect_core_gregset);
>    tdep->sizeof_gregset = 288;
> Index: src/gdb/xtensa-linux-tdep.c
> ===================================================================
> --- src.orig/gdb/xtensa-linux-tdep.c	2010-07-28 19:50:13.000000000 +0100
> +++ src/gdb/xtensa-linux-tdep.c	2010-08-03 18:42:20.000000000 +0100
> @@ -19,7 +19,7 @@
>  
>  #include "defs.h"
>  #include "osabi.h"
> -
> +#include "linux-tdep.h"
>  #include "solib-svr4.h"
>  #include "symtab.h"
>  
> @@ -28,6 +28,8 @@
>  static void
>  xtensa_linux_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch)
>  {
> +  linux_init_abi (info, gdbarch);
> +
>    set_solib_svr4_fetch_link_map_offsets
>      (gdbarch, svr4_ilp32_fetch_link_map_offsets);
>  }
> Index: src/gdb/i386-cygwin-tdep.c
> ===================================================================
> --- src.orig/gdb/i386-cygwin-tdep.c	2010-06-16 10:55:17.000000000 +0100
> +++ src/gdb/i386-cygwin-tdep.c	2010-08-04 13:43:27.000000000 +0100
> @@ -28,6 +28,7 @@
>  #include "gdbcore.h"
>  #include "solib.h"
>  #include "solib-target.h"
> +#include "inferior.h"
>  
>  /* Core file support.  */
>  
> @@ -199,6 +200,22 @@ windows_core_xfer_shared_libraries (stru
>    return len;
>  }
>  
> +/* This is how we want PTIDs from core files to be printed.  */
> +
> +static char *
> +i386_windows_core_pid_to_str (struct gdbarch *gdbarch, ptid_t ptid)
> +{
> +  static char buf[80];
> +
> +  if (ptid_get_lwp (ptid) != 0)
> +    {
> +      snprintf (buf, sizeof (buf), "Thread 0x%lx", ptid_get_lwp (ptid));
> +      return buf;
> +    }
> +
> +  return normal_pid_to_str (ptid);
> +}
> +
>  static CORE_ADDR
>  i386_cygwin_skip_trampoline_code (struct frame_info *frame, CORE_ADDR pc)
>  {
> @@ -233,6 +250,7 @@ i386_cygwin_init_abi (struct gdbarch_inf
>      (gdbarch, i386_windows_regset_from_core_section);
>    set_gdbarch_core_xfer_shared_libraries
>      (gdbarch, windows_core_xfer_shared_libraries);
> +  set_gdbarch_core_pid_to_str (gdbarch, i386_windows_core_pid_to_str);
>  
>    set_gdbarch_auto_wide_charset (gdbarch, i386_cygwin_auto_wide_charset);
>  
> 

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

[Pedro Alves]

On Wednesday 04 August 2010 15:55:15, Mark Kettenis wrote:
> > Here's a patch.  Keeping "LWP" for linux, as that's
> > what linux-nat.c prints (probably since ever), so that
> > we're consistent.  I've added linux_init_abi, for common
> > GNU/Linux osabi stuff, and, added a cygwin callback
> > so that it keeps printing "Thread".
> > 
> > WDYT?
> 
> Looks good to me.  I like linux_init_abi(); there's plenty more stuff
> that could be moved there!

Thanks.  I've applied it.

-- 
Pedro Alves

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

[Ulrich Weigand]

Pedro Alves wrote:

> 	* linux-tdep.h (linux_init_abi): Declare.
> 	* alpha-linux-tdep.c: Include linux-tdep.h.
> 	(alpha_linux_init_abi): Call linux_init_abi.
> 	* amd64-linux-tdep.c (amd64_linux_init_abi): Call linux_init_abi.
> 	* arm-linux-tdep.c (arm_linux_init_abi): Call linux_init_abi.
> 	* frv-linux-tdep.c: Include linux-tdep.h
> 	(frv_linux_init_abi): Call linux_init_abi.
> 	* hppa-linux-tdep.c: Include linux-tdep.h
> 	(hppa_linux_init_abi): Call linux_init_abi.
> 	* i386-linux-tdep.c (i386_linux_init_abi): Call linux_init_abi.
> 	* ia64-linux-tdep.c: Include linux-tdep.h.
> 	(ia64_linux_init_abi): Call linux_init_abi.
> 	* m32r-linux-tdep.c: Include linux-tdep.h.
> 	(m32r_linux_init_abi): Call linux_init_abi.
> 	* m68klinux-tdep.c: Include linux-tdep.h.
> 	(m68k_linux_init_abi): Call linux_init_abi.
> 	* microblaze-linux-tdep.c: Include linux-tdep.h.
> 	(microblaze_linux_init_abi): Call linux_init_abi.
> 	* mips-linux-tdep.c: Include linux-tdep.h.
> 	(mips_linux_init_abi): Call linux_init_abi.
> 	* mn10300-linux-tdep.c: Include linux-tdep.h.
> 	(am33_linux_init_osabi): Call linux_init_abi.  Rename the
> 	'gdbinfo' parameter to 'info'.
> 	* ppc-linux-tdep.c: Include linux-tdep.h.
> 	(ppc_linux_init_abi): Call linux_init_abi.
> 	* sh-linux-tdep.c: Include linux-tdep.h.
> 	(sh_linux_init_abi): Call linux_init_abi.
> 	* sparc-linux-tdep.c: Include linux-tdep.h.
> 	(sparc32_linux_init_abi): Call linux_init_abi.
> 	* sparc64-linux-tdep.c: Include linux-tdep.h.
> 	(sparc64_linux_init_abi): Call linux_init_abi.
> 	* xtensa-linux-tdep.c: Include linux-tdep.h.
> 	(xtensa_linux_init_abi): Call linux_init_abi.

You seem to have missed s390-tdep.c here (note that Linux is the
only supported OS on that platform, therefore there is no init_abi.)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

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

[Pedro Alves]

On Wednesday 04 August 2010 17:53:45, Ulrich Weigand wrote:

> You seem to have missed s390-tdep.c here (note that Linux is the
> only supported OS on that platform, therefore there is no init_abi.)

Thanks.  We can then just call linux_init_abi at the top of
s390_gdbarch_init, right?

-- 
Pedro Alves

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

[Pedro Alves]

On Wednesday 04 August 2010 18:14:44, Pedro Alves wrote:
> On Wednesday 04 August 2010 17:53:45, Ulrich Weigand wrote:
> 
> > You seem to have missed s390-tdep.c here (note that Linux is the
> > only supported OS on that platform, therefore there is no init_abi.)
> 
> Thanks.  We can then just call linux_init_abi at the top of
> s390_gdbarch_init, right?

Or rather, a bit further down, where the gdbarch is actually
created, like so?

(tested by building an --enable-targets=all gdb, on x86_64-linux)

-- 
Pedro Alves

2010-08-04  Pedro Alves  <pedro@codesourcery.com>

	* s390-tdep.c: Include linux-tdep.h.
	(s390_gdbarch_init): Call linux_init_abi.

---
 gdb/s390-tdep.c |    2 ++
 1 file changed, 2 insertions(+)

Index: src/gdb/s390-tdep.c
===================================================================
--- src.orig/gdb/s390-tdep.c	2010-08-04 18:16:31.000000000 +0100
+++ src/gdb/s390-tdep.c	2010-08-04 18:16:24.000000000 +0100
@@ -2829,6 +2829,8 @@ s390_gdbarch_init (struct gdbarch_info i
   tdep->abi = tdep_abi;
   gdbarch = gdbarch_alloc (&info, tdep);
 
+  linux_init_abi (info, gdbarch);
+
   set_gdbarch_believe_pcc_promotion (gdbarch, 0);
   set_gdbarch_char_signed (gdbarch, 0);
 

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

[Ulrich Weigand]

Pedro Alves wrote:

> > Thanks.  We can then just call linux_init_abi at the top of
> > s390_gdbarch_init, right?
> 
> Or rather, a bit further down, where the gdbarch is actually
> created, like so?

Actually, I think it should be rather at the end, where other
architectures which support multiple OSABIs call gdbarch_init_osabi.

That way, at least basic setup of the architecture is already done
when the osabi routine is called ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

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

[Ulrich Weigand]

Pedro Alves wrote:

Oh, something else:

> 	* s390-tdep.c: Include linux-tdep.h.

The patch you posted doesn't :-)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

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

[Pedro Alves]

On Wednesday 04 August 2010 18:44:31, Ulrich Weigand wrote:
> Pedro Alves wrote:
> 
> > > Thanks.  We can then just call linux_init_abi at the top of
> > > s390_gdbarch_init, right?
> > 
> > Or rather, a bit further down, where the gdbarch is actually
> > created, like so?
> 
> Actually, I think it should be rather at the end, where other
> architectures which support multiple OSABIs call gdbarch_init_osabi.
> 
> That way, at least basic setup of the architecture is already done
> when the osabi routine is called ...

Ah, agreed.  I've now placed it just above some core file and other
OS specific-ish bits, although there are a few non-OS things
mingled a bit below too.
(OOC, I wonder whether there's anything technically preventing
installing an GDB_OSABI_LINUX osabi callback and move
these linux related bits there, to keep things neat.)

> Oh, something else:
> 
> > 	* s390-tdep.c: Include linux-tdep.h.
> 
> The patch you posted doesn't :-)

Bah, sorry, forgot to "quilt refresh" before copy&paste.  :-)

Let try once more...

-- 
Pedro Alves

2010-08-04  Pedro Alves  <pedro@codesourcery.com>

	* s390-tdep.c: Include linux-tdep.h.
	(s390_gdbarch_init): Call linux_init_abi.

---
 gdb/s390-tdep.c |    6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

Index: src/gdb/s390-tdep.c
===================================================================
--- src.orig/gdb/s390-tdep.c	2010-08-04 18:48:44.000000000 +0100
+++ src/gdb/s390-tdep.c	2010-08-04 19:06:27.000000000 +0100
@@ -43,7 +43,7 @@
 #include "dis-asm.h"
 #include "solib-svr4.h"
 #include "prologue-value.h"
-
+#include "linux-tdep.h"
 #include "s390-tdep.h"
 
 #include "features/s390-linux32.c"
@@ -2909,6 +2909,10 @@ s390_gdbarch_init (struct gdbarch_info i
                                        displaced_step_at_entry_point);
   set_gdbarch_max_insn_length (gdbarch, S390_MAX_INSTR_SIZE);
 
+  /* Note that GNU/Linux is the only OS supported on this
+     platform.  */
+  linux_init_abi (info, gdbarch);
+
   switch (tdep->abi)
     {
     case ABI_LINUX_S390:

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

[Ulrich Weigand]

Pedro Alves wrote:

> (OOC, I wonder whether there's anything technically preventing
> installing an GDB_OSABI_LINUX osabi callback and move
> these linux related bits there, to keep things neat.)

Yes, I've thought about this.  But in the absence of any specific
other OS it is not fully clear which pieces are Linux specific
and which aren't.  For example, the calling convention is in theory
OS specific, but any other OS on s390 that I'm aware of that might
conceivably have an interest in GDB (e.g. OpenSolaris) is using the
same conventions as Linux for compatibility reasons ...

> 2010-08-04  Pedro Alves  <pedro@codesourcery.com>
> 
> 	* s390-tdep.c: Include linux-tdep.h.
> 	(s390_gdbarch_init): Call linux_init_abi.

This looks good to me now.

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

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

[Pedro Alves]

On Wednesday 04 August 2010 19:34:44, Ulrich Weigand wrote:

> Yes, I've thought about this.  But in the absence of any specific
> other OS it is not fully clear which pieces are Linux specific
> and which aren't.  For example, the calling convention is in theory
> OS specific, but any other OS on s390 that I'm aware of that might
> conceivably have an interest in GDB (e.g. OpenSolaris) is using the
> same conventions as Linux for compatibility reasons ...

Thanks.

> > 2010-08-04  Pedro Alves  <pedro@codesourcery.com>
> > 
> > 	* s390-tdep.c: Include linux-tdep.h.
> > 	(s390_gdbarch_init): Call linux_init_abi.
> 
> This looks good to me now.

Thanks, now applied.

-- 
Pedro Alves

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

[Pedro Alves]

Hi,

On Thursday 22 April 2010 16:18:55, Stefano Sabatini wrote:
> Hi all,
> 
> $ gdb --version
> GNU gdb (GDB) 7.1
> 
> (gdb) info threads
> * 9 Thread 25919  0x0040cc7d in PSafeObject::LockReadOnly (this=0xb6d3d1d8)
>     at ../common/safecoll.cxx:144
>   8 Thread 25920  0x00885402 in __kernel_vsyscall ()
>   7 Thread 25921  0x00885402 in __kernel_vsyscall ()
>   6 Thread 25922  0x00885402 in __kernel_vsyscall ()
>   5 Thread 25927  0x00885402 in __kernel_vsyscall ()
>   4 Thread 25928  0x00885402 in __kernel_vsyscall ()
>   3 Thread 16215  0x00885402 in __kernel_vsyscall ()
>   2 Thread 16216  0x00885402 in __kernel_vsyscall ()
>   1 Thread 25917  0x00885402 in __kernel_vsyscall ()
> (gdb) help info thread
> IDs of currently known threads.
> 
> This shows the gdb thread number, the process ID and I don't know
> what's contained in the fourth column, but that's for sure cannot be
> the same as the pthread_t id as it is the same for all the threads.
> 
> On another machine I get this output:
>   3 Thread 0xb7642b70 (LWP 3334)  (running)
>   2 Thread 0xb7e43b70 (LWP 3333)  (running)
> * 1 Thread 0xb7e446c0 (LWP 3327)  0xb7fe1424 in __kernel_vsyscall ()
> 
> Can you explain the differences, and why are there in the first place?
> 
> Also in the first scenario I cannot get the pthread_t information, which
> is shown in the third column of the second scenario.
> 
> To me this sounds like a real puzzle, I'll be grateful to whom will
> help me to figure it out, also a pointer to the location in the gdb
> sources where the "info thread" command is executed would be welcome.

Just to put closure on this thread: this is now fixed on
CVS mainline (future 7.3).  "info threads" when debugging a core file now
has  the same output as when debugging the process when it was live,
and, you can now inspect TLS variables when debugging a core file.
This should Just Work when debugging core files generated on the
same machine you are debugging.  When moving cores between machines, you
may need to point gdb at the correct libthread_db.so with
"(gdb) set libthread-db-search-path".  See the manual for more details on
that command.

-- 
Pedro Alves