Re: gdb/dwarf-frame.c

[Roland McGrath <roland@redhat.com>]

[I trimmed the CC because I think everyone else is on the mailing list.]

> Yes indeed.  I mostly use FreeBSD instead of Linux nowadays, so I
> haven't tracked what's been happening on the Linux thread front too
> closely.  I get the feeling though that trying to support both the old
> and the new threading model in the same code isn't a good idea :-(.

Can you be specific in your criticism?  The rigamarole to get sibling
threads stopped and started is a bit unsightly, but not too horrible I
didn't think.  I think trying to have separate backend implementations for
linuxthreads and nptl and switching among them (whether two target modules
or one with internal state flags) would be worse than any moderate amount
of kludgery in the one backend.  

The situation in lin-lwp.c can be much cleaner if Dan and I ever implement
the enhancements to ptrace in Linux 2.5 that we have discussed in detail
privately in the past.  That would let thread tracing at the kernel level
work in a sane fashion with either kind of threads on a new kernel, and
make it easy to detect an old kernel lacking the new ptrace features and
fall back to the existing code that only supports linuxthreads.  We can
probably be spurred to do this, though it has heretofore fallen off the end
of our queues of wonderful things that ought to be done real soon now.

That doesn't help debugging NPTL on extant 2.5 kernels or on modified 2.4
kernels that support NPTL like those in RHL9.  But personally I am ok with
such support not going into mainline gdb if cleaner support for newer
kernels is there.  (However I don't speak for my RH colleagues who will
have to maintain private patches as necessary.)


Thanks,
Roland