From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32236 invoked by alias); 14 Dec 2001 01:14:37 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 31654 invoked from network); 14 Dec 2001 01:13:17 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 14 Dec 2001 01:13:17 -0000 Received: from cygnus.com (reddwarf.cygnus.com [205.180.231.12]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id RAA18913; Thu, 13 Dec 2001 17:13:10 -0800 (PST) Message-ID: <3C19516C.DB743DF2@cygnus.com> Date: Thu, 13 Dec 2001 17:14:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Daniel Jacobowitz CC: Andrew Cagney , gdb-patches@sources.redhat.com Subject: Re: [RFA] Don't use thread_db on corefiles References: <20011213114847.A17989@nevyn.them.org> <3C190DDC.B32D6A7B@cygnus.com> <20011213152958.A30211@nevyn.them.org> <3C1931E3.E240B409@cygnus.com> <20011213180259.A11251@nevyn.them.org> <3C1933E7.E2B9DE87@cygnus.com> <20011213181006.A11536@nevyn.them.org> <3C193BA0.2030207@cygnus.com> <20011213184449.A12630@nevyn.them.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2001-12/txt/msg00374.txt.bz2 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.