From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22944 invoked by alias); 23 Oct 2003 12:24:29 -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 22937 invoked from network); 23 Oct 2003 12:24:28 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 23 Oct 2003 12:24:28 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1ACeVt-0002bD-DN; Thu, 23 Oct 2003 08:24:25 -0400 Date: Thu, 23 Oct 2003 12:24:00 -0000 From: Daniel Jacobowitz To: Todd.Kneisel@Bull.com Cc: gdb@sources.redhat.com Subject: Re: gdb6.0 and statically linked threaded programs Message-ID: <20031023122424.GA9971@nevyn.them.org> Mail-Followup-To: Todd.Kneisel@Bull.com, gdb@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00258.txt.bz2 On Wed, Oct 22, 2003 at 03:59:53PM -0700, Todd.Kneisel@Bull.com wrote: > I have built gdb6.0 and am having trouble using it to debug a > threaded program that is statically linked with the linuxthreads > pthread library. Gdb does not detect the creation of threads, > it traps signal 32 that the pthread library uses to restart > threads, and gets a SIGINT instead of stopping at a breakpoint > in a thread. > > If I dynamically link my program, everything works fine. For > a number of reasons, I need to link my program statically. > > I've begun looking at the gdb code and found the following > text in a comment in the thread_db_mourn_inferior function: > > At present, > debugging a statically-linked threaded program is broken, but > the check is added below in the event that it is fixed in the > future. > > Is anyone working on fixing this? Or can anyone provide more > details about how or why it's broken? It's broken because the thread layer is never initialized. I'm waiting for some of the changes to the target stack to see if they make it easier to fix this - the last few things I've tried were simply gross beyond words. In the mean time I recommend using gdbserver instead of native gdb. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer