Amusing problem in current libthread_db

Amusing problem in current libthread_db

[Daniel Jacobowitz]

In recent versions of libthread_db, there's this interesting code:

td_err_e
td_thr_getgregs (const td_thrhandle_t *th, prgregset_t gregs)
{
  struct _pthread_descr_struct pds;

  LOG ("td_thr_getgregs");

  if (th->th_unique == NULL)
    {
      /* No data yet.  */
      memset (gregs, '\0', sizeof (prgregset_t));
      return TD_OK;
    }



So, if we don't have a th_unique, claim to have no registers.  So for the
first thread, until the thread manager is initialized [for LinuxThreads at
least - is it initialized earlier in NPTL?], we claim that all
registers are zero.  GDB loads the registers during this interval.

So it thinks the PC is zero.  Anyone know the reason for this change, which
appears to have come in with:
date: 2002/07/16 03:35:49;  author: drepper;  state: Exp;  lines: +7 -0
Some more changes to handle TLS-enabled libpthread.


It doesn't seem to cause any problems, which baffles me just a little bit. 
I'm still trying to figure that part out.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Amusing problem in current libthread_db

[Roland McGrath]

The reason that code is needed for linuxthreads is that the thread
descriptor might be uninitialized.  The main thread and the manager thread
are always reported by td_ta_thr_iter.  However, early on their descriptors
are all zeros and so td_thr_get_info et al need to be able to cope with
that.  It might make more sense not to report any threads at all before
they are initialized enough to report useful information.  But I think that
was deemed a more risky change (vs possible presumptions of old gdbs, etc)
than faking the all-zeros responses in the early stages.  

The reason this wasn't an issue before and got changed was that the array
of thread descriptors used to be in initialized data, where the first two
elements were initialized nonzero to set up the the main and manager threads.
Now the whole array is in uninitialized so it can go in bss and not take up
space on disk; thus the main and manager threads' elements start out zero too.

td_thr_get_info does a somewhat more convincing job of faking info when
dealing with an uninitialized descriptor in the inferior, i.e. always just
use the main thread in that case.  td_thr_getgregs et al could be made to
do that.


Thanks,
Roland

Re: Amusing problem in current libthread_db

[Daniel Jacobowitz]

On Tue, Jun 03, 2003 at 03:30:47PM -0700, Roland McGrath wrote:
> The reason that code is needed for linuxthreads is that the thread
> descriptor might be uninitialized.  The main thread and the manager thread
> are always reported by td_ta_thr_iter.  However, early on their descriptors
> are all zeros and so td_thr_get_info et al need to be able to cope with
> that.  It might make more sense not to report any threads at all before
> they are initialized enough to report useful information.  But I think that
> was deemed a more risky change (vs possible presumptions of old gdbs, etc)
> than faking the all-zeros responses in the early stages.  
> 
> The reason this wasn't an issue before and got changed was that the array
> of thread descriptors used to be in initialized data, where the first two
> elements were initialized nonzero to set up the the main and manager threads.
> Now the whole array is in uninitialized so it can go in bss and not take up
> space on disk; thus the main and manager threads' elements start out zero too.
> 
> td_thr_get_info does a somewhat more convincing job of faking info when
> dealing with an uninitialized descriptor in the inferior, i.e. always just
> use the main thread in that case.  td_thr_getgregs et al could be made to
> do that.

Will the manager thread be reported as created only after its thread
descriptor is initialized?  I'm guessing "yes".  In that case, using
the main thread is sufficient.

Here's a patch to fix the problem, since it turned out to be more than
theoretical on ARM targets.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2003-08-18  Daniel Jacobowitz  <drow@mvista.com>

	* td_thr_getfpregs.c (td_thr_getfpregs): Use the main thread if
	the descriptor is uninitialized.
	* td_thr_getgregs.c (td_thr_getgregs): Likewise.

diff -urp -x '*~' glibc-2.3.2/linuxthreads_db.orig/td_thr_getfpregs.c glibc-2.3.2/linuxthreads_db/td_thr_getfpregs.c
--- glibc-2.3.2/linuxthreads_db.orig/td_thr_getfpregs.c	2002-07-15 23:25:16.000000000 -0400
+++ glibc-2.3.2/linuxthreads_db/td_thr_getfpregs.c	2003-08-18 14:44:11.000000000 -0400
@@ -1,5 +1,5 @@
 /* Get a thread's floating-point register set.
-   Copyright (C) 1999, 2001 Free Software Foundation, Inc.
+   Copyright (C) 1999, 2001, 2003 Free Software Foundation, Inc.
    This file is part of the GNU C Library.
    Contributed by Ulrich Drepper <drepper@cygnus.com>, 1999.
 
@@ -30,7 +30,10 @@ td_thr_getfpregs (const td_thrhandle_t *
 
   if (th->th_unique == NULL)
     {
-      memset (regset, '\0', sizeof (*regset));
+      /* No data yet.  Use the main thread.  */
+      pid_t pid = ps_getpid (th->th_ta_p->ph);
+      if (ps_lgetfpregs (th->th_ta_p->ph, pid, regset) != PS_OK)
+	return TD_ERR;
       return TD_OK;
     }
 
diff -urp -x '*~' glibc-2.3.2/linuxthreads_db.orig/td_thr_getgregs.c glibc-2.3.2/linuxthreads_db/td_thr_getgregs.c
--- glibc-2.3.2/linuxthreads_db.orig/td_thr_getgregs.c	2002-07-15 23:24:27.000000000 -0400
+++ glibc-2.3.2/linuxthreads_db/td_thr_getgregs.c	2003-08-18 14:43:08.000000000 -0400
@@ -1,5 +1,5 @@
 /* Get a thread's general register set.
-   Copyright (C) 1999, 2000, 2001 Free Software Foundation, Inc.
+   Copyright (C) 1999, 2000, 2001, 2003 Free Software Foundation, Inc.
    This file is part of the GNU C Library.
    Contributed by Ulrich Drepper <drepper@cygnus.com>, 1999.
 
@@ -30,8 +30,10 @@ td_thr_getgregs (const td_thrhandle_t *t
 
   if (th->th_unique == NULL)
     {
-      /* No data yet.  */
-      memset (gregs, '\0', sizeof (prgregset_t));
+      /* No data yet.  Use the main thread.  */
+      pid_t pid = ps_getpid (th->th_ta_p->ph);
+      if (ps_lgetregs (th->th_ta_p->ph, pid, gregs) != PS_OK)
+	return TD_ERR;
       return TD_OK;
     }
 

Machine interface

[jacques]

Hello, I've been doing some MI interface testing, and am in need of some 
grammar clarifications. After running until a breakpoint, I do the 
following:

(gdb)
-data-evaluate-expression b
^done,value="{<_Vector_base<int,std::allocator<int> >> = 
{<_Vector_alloc_base<int,std::allocator<int>,true>> = {_M_start = 
0x804aa50, _M_finish = 0x804aa58, _M_end_of_storage = 0x804aa58}, <No 
data fields>}, <No data fields>}"

Which is of the format:
output => result-record => "^" result-class ( "," result )
result-class => "done"
result => variable "=" value
value => tuple
tuple => "{" result "}"
...

Now all is well and fine, however the meat of the output, being the 
variable and value nonterminal symbols are unparseable! Indeed, they are 
composed of:
variable => string
value => const => c-string (since I can't fanthom not running into a 
const value after a while)

In this case, <_Vector_base<....>> is unparseable, and I wouldn't be 
able to know how to handle all cases. Furthermore, I don't see the 
distinction between c-string and string. I see how the production would 
depend on the programming language being being debugged, but it seems 
quite important to me.
--Jacques

Re: Machine interface

[Andrew Cagney]

Have a look at the -var-* commands.  The testsuite is currently the best 
source of examples.

Andrew

Re: Machine interface

[Alain Magloire]

> 
> Have a look at the -var-* commands.  The testsuite is currently the best 
> source of examples.
> 

In other words try:

(gdb)
-var-create - * b
...
-var-evaluate-expression var1


Using the varobj, as shown to be more reliable.
and we use -data-evaluate-expression only for hovering or quick evaluation.

Re: Amusing problem in current libthread_db

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Jacobowitz wrote:

> Here's a patch to fix the problem, since it turned out to be more than
> theoretical on ARM targets.

I supposed this isn't worse than what we had before.  I've applied it.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE/ScYM2ijCOnn/RHQRAn0mAJ9BkL1WvRWWZ7vl0iyuorUhnZWvOQCgynbO
T2b5NBhnYj/p1a+9Gbz/FK0=
=VEMF
-----END PGP SIGNATURE-----