From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15646 invoked by alias); 13 Dec 2001 19:37:26 -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 14540 invoked from network); 13 Dec 2001 19:36:09 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 13 Dec 2001 19:36:09 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16EbdV-00074j-00; Thu, 13 Dec 2001 14:35:17 -0500 Date: Thu, 13 Dec 2001 11:37:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Don't use thread_db on corefiles Message-ID: <20011213143517.A26663@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20011213114847.A17989@nevyn.them.org> <3C18FA17.6030603@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C18FA17.6030603@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-12/txt/msg00355.txt.bz2 On Thu, Dec 13, 2001 at 10:57:27AM -0800, Andrew Cagney wrote: > >This patch fixes a really frustrating internal error when you open the > >coredump of a multithreaded application. Depending on your kernel, either > >the core has threads (corefile.c supports this just fine) or it doesn't. > >Neither way will opening libthread_db work right. > > > Daniel, can you explain the problem? Thread-db should work on core > files (or realize it is silly and not open its self). I suppose it might, theoretically, work on core files - but why bother? All we need is the list of threads and their registers, and corefile.c provides that and adds the threads appropriately. What the patch does is make thread-db realize it is silly and not open itself. It has no code to do that; basically, it will always try to dlopen(), even if debugging core files or remote code; and if the dlopen succeeds it will try to use thread-db. The first thing to go wrong is that we try to enable event reporting. That calls ps_pdwrite, which of course doesn't work. We get a warning(). Then, every time we attach to a thread we try to enable event reporting there too, and that's an error(). If we connect to a remote target, as I said, the same thing will happen; and in that case we'll have host libthread_db and target libpthread. That's bad, but I'll not touch it until someone makes progress on remote thread debugging. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer