Re: gdb and dlopen

[Mark Kettenis <kettenis@wins.uva.nl>]

   Date: Wed, 17 Oct 2001 14:09:50 -0400
   From: Daniel Jacobowitz <drow@mvista.com>

   (Shouldn't there be a way for us to tell when a thread dies without
   receiving the TD_DEATH event anyway?  We -are- attached to all threads,
   and LinuxThreads threads are all separate processes...)

Ultimately waitpid() will report that the process has exited.
Unfortunately there seems to be a window where we cannot access that
process's memory with ptrace, while waitpid() hasn't reported that
exit yet.

   > If we declare glibc 2.1.3 broken, and force people to upgrade to glibc
   > 2.2.x, we could assume that a thread stays alive between TD_CREATE and
   > TD_DEATH, and speed up thread_db_thread_alive considerably.
   > 
   > Something similar can be done for lwp_from_threads since assigning a
   > thread to a particular LWP can be reported too (never happens on Linux
   > since LinuxThreads uses a 1:1 mapping).
   > 
   > Note that if we assume that all threads see the same VM, and that the
   > initial LWP stays alive during the execution of the program, we could
   > simply use the process ID of the initial LWP for all memory transfers,
   > which would remove the need for those checks completely.

   I'm not entirely comfortable with that assumption, especially since
   this is in thread-db rather than the LinuxThreads specific code.  But
   perhaps we could introduce a target method saying what PID to use for
   reads?  Then we could make Linux (I'm perfectly comfortable with not
   supporting thread debugging on 2.1.3...) simply return the PID without
   any expensive checks.

I think the assumption that all threads/LWPs share the same VM is a
fair assumption for thread-db.  GDB assumes this model in several
places, and you'd probably wouldn't call processes not sharing their
VM threads at all.

As an aside, it appears that Solaris doesn't even allow you to read
memory from a particular LWP at all.

Mark