Linux threads incorrectly "detected" in non-threaded program

["Warner, William (Bill)" <wwarner at ciena dot com>]

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