Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Michael Snyder <msnyder@cygnus.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] Don't use thread_db on corefiles
Date: Thu, 13 Dec 2001 17:14:00 -0000	[thread overview]
Message-ID: <3C19516C.DB743DF2@cygnus.com> (raw)
In-Reply-To: <20011213184449.A12630@nevyn.them.org>

Daniel Jacobowitz wrote:
> 
> On Thu, Dec 13, 2001 at 03:37:04PM -0800, Andrew Cagney wrote:
> > >On Thu, Dec 13, 2001 at 03:04:07PM -0800, Michael Snyder wrote:
> > >
> > >>OK.  I'd like to see that patch when it's ready.
> > >>Do you use only lwp's, or do you use glibc/libpthread threads?
> > >>If you use library threads, are you saving their info in the
> > >>core file, or are you only saving the info for the lwp's?
> > >
> > >
> > >It's completely thread-package-agnostic.  I dump all LWPs sharing the
> > >same VM, as a fairly reliable marker (I'd use 2.4 threadgroups, but
> > >LinuxThreads doesn't use them...)
> >
> >
> > Ok.  So you're dumping out the raw data that libthread-db would use to
> > recreate the current thread state from the raw LWP state.
> >
> >
> > >So there is enough information there for lin-lwp to parse the threads,
> > >if we stubbed out its attempts to write, I expect.  But since the
> > >current Linux threads model has one thread per process, I can simply
> > >use the corefile.c thread support instead, which I'd rather do.
> >
> >
> > Er, careful.  I think lin-lwp should be fixed.  lin-lwp should be
> > interpreting the raw LWP data translating it into user level threads.
> > (Why it writes to the target just sounds like a bug.)
> 
> Strongly object.
> 
> Why?  Because thread_db is only usable natively!  lin-lwp is not fit
> for cross or remote debugging and never can be. 

Maybe so -- maybe not.  But at the moment we're talking about core
files.
Let's keep to one discussion at a time.

> I am testing with MIPS
> cores on an x86-linux host.  Right now it "works" because thread-db is
> not compiled in; if I had an --enable-targets=i386-linux,mipsel-linux
> it would be, though.

Assuming your MIPS remote target is multi-threaded, that would
definitely
confuse thread-db, yes.  But why would you want to do that?  

It seems like you are maybe trying to be more multi-arch than 
thread-db is designed for.  If the problem is that thread-db 
is not multi-arch enough, then let's address that problem.

> If you want to break lin-lwp up into pieces such that one of them can
> do this, you might as well abandon using thread_db at all.  The kernel
> has enough information to tell you about all the threads; it does so.

Hold on -- I think we're having too many conversations at once.
The kernel doesn't know anything about glibc threads, which are
the only threads that thread-db is concerned with.


  reply	other threads:[~2001-12-14  1:14 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-13  8:50 Daniel Jacobowitz
2001-12-13 10:57 ` Andrew Cagney
2001-12-13 11:37   ` Daniel Jacobowitz
2001-12-16 17:58   ` Daniel Jacobowitz
2001-12-16 21:32     ` Kevin Buettner
2001-12-17  8:34       ` Daniel Jacobowitz
2001-12-13 12:26 ` Michael Snyder
2001-12-13 12:31   ` Daniel Jacobowitz
2001-12-13 14:59     ` Michael Snyder
2001-12-13 15:04       ` Daniel Jacobowitz
2001-12-13 15:08         ` Michael Snyder
2001-12-13 15:11           ` Daniel Jacobowitz
2001-12-13 15:37             ` Andrew Cagney
2001-12-13 15:46               ` Daniel Jacobowitz
2001-12-13 17:14                 ` Michael Snyder [this message]
2001-12-13 20:29                   ` Daniel Jacobowitz
2001-12-14 18:12                     ` Andrew Cagney
2001-12-14 18:25                       ` Daniel Jacobowitz
2001-12-13 15:47             ` Michael Snyder
2001-12-13 15:57               ` Daniel Jacobowitz
2001-12-13 16:06                 ` Daniel Jacobowitz
2001-12-13 17:31                   ` Michael Snyder
2001-12-13 20:23                     ` Daniel Jacobowitz
2001-12-14 15:43                       ` Michael Snyder
2001-12-14 17:14                         ` Daniel Jacobowitz
2001-12-17 11:40                           ` Michael Snyder
2001-12-17 11:51                             ` Daniel Jacobowitz
2001-12-13 17:26                 ` Michael Snyder
2001-12-13 20:27                   ` Daniel Jacobowitz
2001-12-14 18:31                     ` Andrew Cagney
2001-12-14 18:36                       ` Andrew Cagney
2001-12-14 18:42                       ` Daniel Jacobowitz
2001-12-15  9:16                         ` Andrew Cagney
2001-12-16 12:26                           ` Daniel Jacobowitz
2001-12-16 13:29                             ` Andrew Cagney
2001-12-16 17:02                               ` Daniel Jacobowitz
2002-01-03 17:11 ` Michael Snyder
2002-01-04 10:25   ` Daniel Jacobowitz
2002-01-04 14:49     ` Michael Snyder
2002-01-04 17:28     ` Michael Snyder
2002-01-04 17:47       ` Daniel Jacobowitz

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=3C19516C.DB743DF2@cygnus.com \
    --to=msnyder@cygnus.com \
    --cc=ac131313@cygnus.com \
    --cc=drow@mvista.com \
    --cc=gdb-patches@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