From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9928 invoked by alias); 13 Dec 2001 23:57:56 -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 9674 invoked from network); 13 Dec 2001 23:56:39 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 13 Dec 2001 23:56:39 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16EfiO-0003R5-00; Thu, 13 Dec 2001 18:56:36 -0500 Date: Thu, 13 Dec 2001 15:57:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Don't use thread_db on corefiles Message-ID: <20011213185635.A12902@nevyn.them.org> Mail-Followup-To: Michael Snyder , gdb-patches@sources.redhat.com 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> <3C193D13.AED0F79F@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C193D13.AED0F79F@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-12/txt/msg00371.txt.bz2 On Thu, Dec 13, 2001 at 03:43:15PM -0800, Michael Snyder wrote: > Good, dumping only the LWPs is the right thing to do, I think. > But if that's what you're doing, then the thread-db module should > still be useful to you: I know it is on Solaris, which this one > was modelled after. You'll need it if-and-when the thread-to-lwp > mapping ever becomes many-to-one (which may be soon). See my comments about cross core debugging in my message to Andrew. > > 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. > > You can't rely on that assumption in the future. We need to make > all these packages work together. It won't be a freebie, it will > require some work. But as I say, it works for Solaris gdb. We > just didn't bother making it work for Linux gdb and corefiles, > because up until now there were no threads in corefiles on Linux. It will require a large amount of work. For now, threaded core dumps work with cross debuggers (because thread_db and lin-lwp are not present at all) but cause internal errors with native debuggers for the reasons I explained. If there is really such vehement opposition to my workaround, I'll maintain it as a local patch instead, and leave anyone else wanting to do this out in the cold. Please don't take that as any kind of threat; the patch fixes something which is obviously broken, and I can not justify the time for the significant infrastructure work necessary for any other solution. Thread_db, as things stand, does not work on core files. Is preventing it from trying, and thus crashing GDB, really such a disruptive suggestion? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer