From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57168 invoked by alias); 4 Jul 2018 16:39:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 57147 invoked by uid 89); 4 Jul 2018 16:39:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=confident, rabbit, Actually, directed X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Jul 2018 16:39:10 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w64Gd3O4007877 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 4 Jul 2018 12:39:08 -0400 Received: by simark.ca (Postfix, from userid 112) id 47A231EF29; Wed, 4 Jul 2018 12:39:03 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 3EC6C1E08D; Wed, 4 Jul 2018 12:39:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 04 Jul 2018 16:39:00 -0000 From: Simon Marchi To: Pedro Alves Cc: gdb-patches@sourceware.org, tom@tromey.com Subject: Re: [PATCH 1/2] darwin: Silence syscall deprecated declaration warning In-Reply-To: <52b499e2-748f-6f64-4368-13942e45a79c@redhat.com> References: <20180704043033.29212-1-simon.marchi@polymtl.ca> <52b499e2-748f-6f64-4368-13942e45a79c@redhat.com> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.6 X-IsSubscribed: yes X-SW-Source: 2018-07/txt/msg00106.txt.bz2 On 2018-07-04 06:30, Pedro Alves wrote: > Plain kill probably would not, as that it not directed to a specific > thread -- any thread could dequeue it. > > My immediate question when reading this was "why not use the > pthread_kill C function instead of calling the syscall directly?" > > I then followed the rabbit down the hole, starting here: > > > https://stackoverflow.com/questions/44990839/pthread-kill-to-a-gcd-managed-thread > > which lead to pthread_kill's sources, here: > > > https://github.com/apple/darwin-libpthread/blob/768e71947f16da454ea05c4a98f77a0f14358f21/src/pthread.c#L1412 > > So it's very likely we use the syscall directly instead of pthread_kill > because > we want to be able to send a signal to all kinds of threads, including > worker threads underlying GCD. I wish there was a comment to the > effect here. Indeed, I saw that too. I can only assume that this was Tristan's intention when writing the code. I can add the comment if we're confident enough that it's the case. > I also peeked at debugserver's sources in lldb, and it seems to me that > lldb doesn't send a signal to the thread unless it was stopped on a > mach > exception? > > Actually, I wonder if that syscall in gdb is really ever reached... We > shouldn't be calling darwin_resume_thread on non-resumed threads, > AFAICT, > so why do we handle that? See comment underlined below -- when isn't > the process stopped when we get there? > > static void > darwin_resume_thread (struct inferior *inf, darwin_thread_t *thread, > int step, int nsignal) > { > .. > switch (thread->msg_state) > { > case DARWIN_MESSAGE: > if (thread->event.ex_type == EXC_SOFTWARE > && thread->event.ex_data[0] == EXC_SOFT_SIGNAL) > { > ... > } > else if (nsignal) > { > /* Note: ptrace is allowed only if the process is stopped. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Directly send the signal to the thread. */ > res = syscall (SYS___pthread_kill, thread->gdb_port, nsignal); > ... > } Just guessing here. It looks like when the thread generates mach exception (breakpoint, unix signal, bad instruction, etc), it "sends" a message (in Darwin jargon) and is stuck waiting for a reply. GDB needs to reply to it to unblock the thread (the call to darwin_send_reply). In this case, the thread might be stopped from the point of view of the user and GDB, but not from the point of view of the OS. So that's why, if we want to inject a signal, we have to use __pthread_kill. I don't know why the (ex_type == EXC_SOFTWARE && ex_data[0] == EXC_SOFT_SIGNAL) is treated differently though. In any case, changing this would require a deeper analysis and knowledge of the Darwin kernel and some time, and I don't have either :). Would you still be fine with silencing the warning for now to get it out of the way? Simon