public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Roland McGrath <roland@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb@sources.redhat.com, libc-alpha@sources.redhat.com
Subject: Re: Amusing problem in current libthread_db
Date: Tue, 03 Jun 2003 22:30:00 -0000	[thread overview]
Message-ID: <200306032230.h53MUlA22339@magilla.sf.frob.com> (raw)
In-Reply-To: Daniel Jacobowitz's message of  Tuesday, 3 June 2003 18:09:12 -0400 <20030603220912.GA7922@nevyn.them.org>

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

  reply	other threads:[~2003-06-03 22:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-03 22:09 Daniel Jacobowitz
2003-06-03 22:30 ` Roland McGrath [this message]
2003-08-18 19:33   ` Daniel Jacobowitz
2003-08-19  6:45     ` Machine interface jacques
2003-08-19 13:30       ` Andrew Cagney
2003-08-19 14:00         ` Alain Magloire
2003-08-25  8:17     ` Amusing problem in current libthread_db Ulrich Drepper

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=200306032230.h53MUlA22339@magilla.sf.frob.com \
    --to=roland@redhat.com \
    --cc=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    --cc=libc-alpha@sources.redhat.com \
    /path/to/YOUR_REPLY

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

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