From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6321 invoked by alias); 26 Jan 2002 07:08:41 -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 6266 invoked from network); 26 Jan 2002 07:08:31 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 26 Jan 2002 07:08:31 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16UMwy-0004iA-00; Sat, 26 Jan 2002 02:08:32 -0500 Date: Fri, 25 Jan 2002 23:08:00 -0000 From: Daniel Jacobowitz To: "Warner, William (Bill)" Cc: "'gdb@sources.redhat.com'" Subject: Re: Linux threads incorrectly "detected" in non-threaded program Message-ID: <20020126020832.A18087@nevyn.them.org> Mail-Followup-To: "Warner, William (Bill)" , "'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.3.23i X-SW-Source: 2002-01/txt/msg00308.txt.bz2 On Fri, Jan 25, 2002 at 06:09:28PM -0800, Warner, William (Bill) wrote: > Hi - > I'm using GDB 5.1.1 on Linux 2.4.7 kernel (RedHat 7.2). > The program I'm trying to debug links against libpthread.so (indirectly), > but does not create any additional pthreads (only the "initial" thread > exists.) > However, the program does do its own user-level context switching > (save/restore > registers and change stack pointers.) > My problem is that after the program starts up, GDB apparently > "detects" a new thread or lwp, but of course fails when it tries to use it > (since it doesn't really exist.) > Two questions: > 1. Why does gdb think there's a new thread? Does it, or libthread_db, still > rely on > the stack pointer to identify threads? What state is being relied on? When does it detect a new thread? When you create one, or at startup? If the latter, then it should still work just fine. Performance will be impacted - which is avoidable, but not currently avoided - but it should still work. > 2. Can GDB be configured (at run-time or compile-time) to disable thread > awareness and > not call the lin-lwp or thread_db stuff? That is, be forced to treat the > program > as non-threaded? I don't believe there is an option for this. There probably should be. > > I should note that the program, when compiled for Solaris, can be > debugged fine > with GDB 5.0. The Solaris implementation therefore seems more robust. > > Here's a transcript: > > % gdb simv > GNU gdb 5.1.1 > ... > (gdb) attach 12418 > Attaching to program: > /home/wwarner/p4/hw/txn/asics/sim/tb_scm/src/i686/simv, process 13228 > Reading symbols from /lib/librt.so.1...done. > Loaded symbols for /lib/librt.so.1 > ... > Reading symbols from /lib/i686/libpthread.so.0...done. > [New Thread 1024 (LWP 13228)] > Loaded symbols for /lib/i686/libpthread.so.0 > ... > 0x4019ca31 in __libc_nanosleep () from /lib/i686/libc.so.6 > (gdb) continue > Continuing. > // process resumes, and starts creating user-level threads and context > switching. > // Then I hit Control-C. > [New Cannot find thread 2049: invalid thread handle This line above is quite peculiar. Is the source to your application available, or can you create a reduced testcase, perhaps? I'd quite like to see what's going wrong. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer