From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11930 invoked by alias); 26 Jan 2002 02:09:44 -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 11821 invoked from network); 26 Jan 2002 02:09:40 -0000 Received: from unknown (HELO c2.ciena.com) (63.118.32.25) by sources.redhat.com with SMTP; 26 Jan 2002 02:09:40 -0000 Received: by c2.ciena.com (8.8.8+Sun/SMI-SVR4-8.0) id VAA08739; Fri, 25 Jan 2002 21:09:39 -0500 (EST) Received: from wntcsdexg01.csd.ciena.com(10.128.2.158) by c2.ciena.com via smap (V2.0) id xma008676; Fri, 25 Jan 02 21:09:30 -0500 Received: by wntcsdexg01.csd.ciena.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jan 2002 18:09:30 -0800 Message-ID: From: "Warner, William (Bill)" To: "'gdb@sources.redhat.com'" Subject: Linux threads incorrectly "detected" in non-threaded program Date: Fri, 25 Jan 2002 18:09:00 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SW-Source: 2002-01/txt/msg00305.txt.bz2 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? 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 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 (gdb) info threads 1 Thread 1024 (LWP 13719) Couldn't get registers: No such process. (gdb) c Continuing. Couldn't get registers: No such process. (gdb) Thanks, -- Bill Warner CIENA Core Switching Division 408 366-3385