Re: Process ID munging

[Andrew Cagney <ac131313 at cygnus dot com>]

Mark Kettenis wrote:
> 
> 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.

The short term bandaid most likely involves changing that PID to a
LONGEST (or a typedef LONGEST ...).  Longer term, it is going to need a
more radical treatment.

Instead of the current integer, a thread object that has bound to it
things like its architecture, its symbol information, its address map,
its target interface and even its cached register/memory information. 
Implementing it involves some careful thought and a serious amount of
strategizing (.... :-).

	Andrew