From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27518 invoked by alias); 26 Jul 2003 15:58:21 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 27510 invoked from network); 26 Jul 2003 15:58:21 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 26 Jul 2003 15:58:21 -0000 Received: from drow by nevyn.them.org with local (Exim 4.20 #1 (Debian)) id 19gRR6-0000IF-OA for ; Sat, 26 Jul 2003 11:58:20 -0400 Date: Sat, 26 Jul 2003 15:58:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: RFC: A mode in which gdb avoids libthread_db Message-ID: <20030726155820.GA1063@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-SW-Source: 2003-07/txt/msg00311.txt.bz2 Recent Linux kernels (2.5.30 and later; theoretically the latest Red Hat 2.4.20 kernels also include it, but I observed some badness in testing...) support some ptrace extensions I designed which make it possible to debug multi-threaded applications without using libthread_db at all. The only things we'll lose are: - Potential high-level information, like mutex status - right now we don't have this at all on GNU/Linux. - TLS access - this could be easily fixed by handling each platform's TLS ABI directly from GDB, and there's a comment to that effect in GDB's source already. - TIDs - we'd only have the application's LWP IDs, not the thread IDs that LinuxThreads/NPTL use. Things we'll gain: - A lot of libthread_db-related bugs would go away. For instance, the kfail in print-threads.exp, which hits a breakpoint after LinuxThreads decides the thread has already exited. - ABI simplicity - this would solve the x86-64/i386 issue, and similar problems on MIPS. - Support for debugging clone-based 1-1 threading which doesn't use libpthread.so. Once the pending fork-debugging patch is accepted, most of the machinery we'd need to do it will be in place, too. Thoughts? Worthwhile? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer