Process ID munging

[Mark Kettenis <kettenis at wins dot uva dot nl>]

Some good news and some bad...

Starting with the good news, I've managed to get the
threads-debugging-library-assisted code to gracefully handle threads
that exit.

However, when trying to determine if the code suffered from the
zombie-problem reported some time ago (see
http://sourceware.cygnus.com/ml/bug-gdb/2000-02/msg00008.html), I
noticed that GDB bails out after thread #31 is created, with an error
message indicating that td_ta_map_id2thr failed:

   [New Thread 31770 (runnable)]
   spawned 30, return code 0, join returned 0
   tid 32794: I'm #31
   thread_db: map_id2thr failed: invalid thread handle

Looking at the thread id, this is no surprise.  There's no way 32794
is going to fit into the 15 bits that are reserved for the thread id
in GDB's munged process ids.

I can think of some hacks that could make things work for a few more
threads (an extra lookup table or making use of some intimate
knowledge about the LinuxThreads implementation), but ultimately we
will have to think of something better.  There is just no way we can
stuff a 32-bit process id and a 32-bit (or 64-bit) thread id into an
int.

Mark