This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb/dwarf-frame.c
Roland McGrath writes:
> [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.)
>
<FSF hat>
I don't think it is a good idea for gdb6 to be broken on the most
recent linux kernels.
elena
>
> Thanks,
> Roland