RFC: nptl threading patch for linux

[J. Johnston]

Daniel Jacobowitz wrote:
> 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?
>>

Glad to hear this.

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

More good news.

> 
> 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 does not fail on my test system.  I end up on line 42 after the next
is issued.

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

Have you managed to trace which test in thread_db_alive is returning false?

-- Jeff J.