Re: RFC: nptl threading patch for linux

[Daniel Jacobowitz <drow@mvista.com>]

On Sat, May 10, 2003 at 05:18:55PM -0400, Daniel Jacobowitz wrote:
> On Fri, May 09, 2003 at 06:00:11PM -0400, Daniel Jacobowitz wrote:
> > On Thu, Apr 24, 2003 at 04:52:04PM -0400, J. Johnston wrote:
> > > The following is the last part of my revised nptl patch that has
> > > been broken up per Daniel J.'s suggestion.  There are no generated
> > > files included in the patch.
> > 
> > Well, this patch doesn't work for me :(  Using 2.5.69, since I don't
> > have any of the Red Hat kernels available here at the moment.  It looks
> > like GDB bellies up around the second thread creation.
> 
> Sorry, I found the problem.  Configure was not finding tkill.  Entirely
> a local problem; but how would you feel about something which set the
> default number for __NR_tkill if __i386__?  Or has someone already
> discouraged that approach?
> 
> So:
> 
> >   - stop_wait_callback should be fixed to not be so dumb when this
> >     happens.
> 
> This one is still true.  Patch for another day.
> 
> >   - we need to figure out how we got into this mess.
> >   - and why the SIGSTOP never showed up.
> 
> But these are resolved.
> 
> 
> I now get fairly good test results with your patch and NPTL; there are
> some failures because of the vsyscall issue being currently discussed. 
> Backtraces in linux-dp don't work because the threads are stopped in
> the kernel page.
> 
> I can also report that the kernel change I am testing to report thread
> exits does not appear to cause your patch any problems.  Yay!  More on
> that in a little while.

I could cause segfaults in both the inferior and GDB, and some missed
single-steps.  I don't know if my kernel patch is at fault or your
patch, but I figured I'd write them up anyway for posterity and later
review.

Start with gdb.threads/print-threads.  Put a breakpoint on
thread_function and one on the printf ("Done\n") main.  Run, disable
the first breakpoint when you hit it, and say next.  You'll hit the
breakpoint in main instead of staying within thread_function.

This is timing sensitive.  It didn't show up with set debug
lin-lwp/target both on.

In other interesting notes, it looks like there is a (related?) problem
with target_thread_alive.  The LWP I'm single-stepping in appears to be
marked as not alive about half the time.  No idea what's up with that. 
It appears to come from thread_db_thread_alive, not from
lin_lwp_thread_alive, which always succeeds.

I can't reproduce the SIGSEGV now for some reason.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer