Re: /proc visibility patch breaks GDB, etc.

[David Mosberger <davidm@napali.hpl.hp.com>]

>>>>> On Wed, 25 Feb 2004 22:44:10 -0800, Andrew Morton <akpm@osdl.org> said:

  Andrew> Peter Chubb <peter@chubb.wattle.id.au> wrote:
  >> 
  >> 
  >> In fs/proc/base.c:proc_pid_lookup(), the patch
  >> 
  >> read_unlock(&tasklist_lock); if (!task) goto out; + if
  >> (!thread_group_leader(task)) + goto out_drop_task;
  >> 
  >> inode = proc_pid_make_inode(dir->i_sb, task, PROC_TGID_INO);
  >> 
  >> means that threads other than the thread group leader don't
  >> appear in the /proc top-level directory.  Programs that are
  >> informed via pid of events can no longer find the appropriate
  >> process -- for example, using gdb on a multi-threaded process, or
  >> profiling using perfmon.
  >> 
  >> The immediate symptom is GDB saying: Could not open
  >> /proc/757/status when 757 is a TID not a PID.

  Andrew> What does `ls /proc/757' say?  Presumably no such file or
  Andrew> directory?  It's fairly bizare behaviour to be able to open
  Andrew> files which don't exist according to readdir, which is why
  Andrew> we made that change.

Excuse, but this seems seriously FOOBAR.  I understand that it's
interesting to see the thread-leader/thread relationship, but surely
that's no reason to break backwards compatibility and the ability to
look up _any_ task's info via /proc/PID/.  A program that only wants
to show "processes" (thread-group leaders) can simply read
/proc/PID/status and ignore the entries for which Tgid != PPid.

Perhaps you could put relative symlinks in task/?  Something like
this:

 $ ls -l /proc/self/task
 dr-xr-xr-x    3 davidm   users           0 Feb 26 11:37 13494 -> ..
 dr-xr-xr-x    3 davidm   users           0 Feb 26 11:37 13495 -> ../../13495

perhaps?

	--david