Re: /proc visibility patch breaks GDB, etc.

[Daniel Jacobowitz <dan@debian.org>]

On Wed, Feb 25, 2004 at 10:44:10PM -0800, Andrew Morton wrote:
> 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.
> 
> What does `ls /proc/757' say?  Presumably no such file or directory?
> It's fairly bizare behaviour to be able to open files which don't exist
> according to readdir, which is why we made that change.
> 
> The node to tid 757 should appear under its thread group leader's
> directory: /proc/NNN/757.  That node should be visible to readdir, and that
> is the node which gdb and perfmon should be looking for.
> 
> Of course, we may have burnt our boats with the initial silliness.  It's a
> shame that gdb and perfmon went and used it.

GDB has used it since long before any of this happened.  LinuxThreads
didn't use thread groups, remember?

There is no way from GDB to figure out which thread is the thread group
leader, either, so I don't know how you propose it find the proc
directory now.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer