Re: gdb/dwarf-frame.c

[Daniel Jacobowitz <drow at mvista dot com>]

On Fri, May 09, 2003 at 02:19:31PM -0700, Roland McGrath wrote:
> [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.

Coincidentally, I'm working on this this weekend.  Or I was going to. 
The NPTL gdb patches do _not_ work on 2.5.69.  The message about this
is stuck in my outbox; I'm trying to get GDB to give me a backtrace but
it's been chugging for an hour now with no luck (160K frames and
counting!)

> 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.)

I'd rather support it.  I think we can, too.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer