From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3154 invoked by alias); 24 Oct 2003 21:01:10 -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 3132 invoked from network); 24 Oct 2003 21:01:10 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 24 Oct 2003 21:01:10 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id B78A92B89; Fri, 24 Oct 2003 17:01:10 -0400 (EDT) Message-ID: <3F999316.6050805@gnu.org> Date: Fri, 24 Oct 2003 21:01:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Todd.Kneisel@Bull.com, gdb@sources.redhat.com Subject: Re: gdb6.0 and statically linked threaded programs References: <20031023203554.GA12733@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00281.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. Daniel, suggest looking at: interface VS target (or something else wrong with the target vector) http://sources.redhat.com/ml/gdb/2003-10/msg00218.html The implication is that immediatly after attaching to a process (or corefile) there'd be some sort of broadcast message telling any interested parties (thread stratum, overlay stratum, shlibs, ...) that there's a fresh new process/core to push onto. But as you note, it will require some pushing and shoving to get there. Andrew