From: "J. Johnston" <jjohnstn@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA: nptl threading support patches
Date: Tue, 22 Apr 2003 20:10:00 -0000 [thread overview]
Message-ID: <3EA5A1B3.6030001@redhat.com> (raw)
In-Reply-To: <20030422173055.GB17043@nevyn.them.org>
Daniel Jacobowitz wrote:
> I can't approve any of this, but I have some comments. First of all,
> this should be multiple patches, in at least a few trivial places.
> Roughly one per paragraph below.
>
> Please don't post changes to generated files. However, also please use
> the right versions of the tools to generate them! You can not use
> autoconf 2.57 to generate the GDB configure script; the right version
> of autoconf 2.13 is available on sources.redhat.com.
>
Ok, I will resubmit in smaller patches and remove generated files. I have to rethink
the scenario you mention whereby the main thread is the only unlocked thread
and exits under the Linuxthreads model.
> You did not mention testing. I assume you tested with NPTL. Did you
> test with LinuxThreads also?
>
Yes. No additional Linuxthreads failures in gdb.threads, although killed.exp fails a
little uglier than it did before. After looking at the exit problem, I will include the
testsuite results for gdb.threads for both nptl and linuxthreads in my resubmit.
> On Tue, Apr 22, 2003 at 11:10:08AM -0400, J. Johnston wrote:
>
>>The attached patch adds nptl threading support for gdb.
>>
>>There are a couple of key design changes to note with the nptl-enabled
>>kernel. First of all, kill semantics have changed. It is no longer
>>possible to send a signal to an lwp via kill. Only a process id can be
>>used, rather than a thread lwp. To keep the lin-lwp logic whereby SIGSTOP
>>is applied to a particular thread and some signals are pushed back, the
>>tkill syscall must be used. The tkill syscall allows us to send a signal
>>to a particular thread. A configuration check is made to see if we can
>>call syscall(__NR_tkill,..) and a runtime check is made to ensure that we
>>can call
>>it successfully without getting ENOSYS.
>
>
> This is a separate patch, for instance. It looks reasonable to me.
>
>
>>Another key behavior change regards thread exit. For linuxthreads, exiting
>>causes a WIFEXITED event to occur at which point we can delete the current
>>thread and determine if any threads still exist. In the new nptl model,
>>only the main thread generates this event and does so only once all the
>>threads have exited. There is no event for the individual threads exiting
>>so we must check at various times to see if a thread has gone away. For
>>example, when we stop all of the threads, this is a good time to see if
>>any have gone away. When we get the exit signal, we check if we have the
>>main thread or not. If it is the main thread, we have to stop all threads
>>(which will check whether they are alive or not), and then see how many
>>threads are left. This logic works for either model. If there are still
>>threads alive, we resume them and continue on without reporting the
>>exit.
>
>
> What was the verdict on whether this would break if I turned on exit
> events for every thread? Sorry for not getting back to that kernel
> patch sooner, I'm way behind. It looks like it would work.
>
Your patch won't affect this code as it was designed to handle either model, however,
a Red Hat Linux kernel has already shipped that has the behavior listed above.
> There are some subtleties. I think that in your patch, the main thread
> reporting a WIFEXITED status will cause other threads to be resumed -
> even if they weren't running before, due to schedule locking. I
> haven't tested that though.
>
As mentioned earlier, you raise a valid problem. I have to look at this.
>
>>A change was made in thread-db.c to handle a FIXME that has been
>>there for a while. When we get a create breakpoint in check_event, we
>>do not know what lwp has been created so we call td_ta_event_getmsg() to
>>get "a message" off the queue. This message might not actually be the
>>message corresponding to the breakpoint that stopped us. I have changed
>>the logic to perform a loop and read off all messages on the queue. This
>>enables death event reporting to work if desired. Without it, you can
>>get scenarios such as a death event preceding its create event, etc..
>
>
> This change looks reasonable to me.
>
>
>>The testsuite needed some changes because there is no longer a manager
>>thread with nptl so the testcase must account for either model when
>>doing info threads. The schedlock testcase was changed because
>>nptl scheduling differs from linuxthreads. One can't assume that
>>all threads will run equally in a small time slice, most notably when
>>stepping a particular thread.
>
>
> The changes to linux-dp.exp look reasonable to me. That can be a patch
> all by itself.
>
> The changes to schedlock.exp look reasonable, and may fix the false
> failures it produces on LinuxThreads already depending on your luck
> with the scheduler. It weakens the test - ideally it was supposed to
> make sure that GDB resumed every thread - but at this point I'll settle
> for resuming at least one other thread. So that's a separate good
> patch too.
>
>
>>It is a lot to digest. Let me know if/when it is ok to commit.
>>
>>-- Jeff J.
>>
>>2003-04-17 Jeff Johnston <jjohnstn@redhat.com>
>>
>> * acconfig.h: Add HAVE_TKILL_SYSCALL definition check.
>> * config.in: HAVE_TKILL_SYSCALL and HAVE_SYSCALL checks added.
>> * configure.in: Add test for syscall function and check for
>> __NR_tkill macro in <syscall.h> to set HAVE_TKILL_SYSCALL.
>> * configure: Regenerated.
>> * thread-db.c (check_event): For create/death event breakpoints,
>> loop through all messages to ensure that we read the message
>> corresponding to the breakpoint we are at.
>> * lin-lwp.c [HAVE_TKILL_SYSCALL]: Include <unistd.h> and
>> <sys/syscall.h>.
>> (kill_lwp): New function that uses tkill syscall or
>> uses kill, depending on whether threading model is nptl or not.
>> All callers of kill() changed to use kill_lwp().
>> (lin_lwp_wait): Make special check when WIFEXITED occurs to
>> see if all threads have already exited in the nptl model.
>> (stop_wait_callback): Check for threads already having exited and
>> delete such threads fromt the lwp list when discovered.
>> (stop_callback): Don't assert retcode of kill call.
>> * i386-linux-nat.c (ps_get_thread_area): New function needed by
>> nptl libthread_db.
>
>
prev parent reply other threads:[~2003-04-22 20:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-04-22 15:10 J. Johnston
2003-04-22 17:30 ` Daniel Jacobowitz
2003-04-22 20:10 ` J. Johnston [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3EA5A1B3.6030001@redhat.com \
--to=jjohnstn@redhat.com \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox