Re: gdb/dwarf-frame.c

[Elena Zannoni <ezannoni at redhat dot com>]

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