From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2403 invoked by alias); 5 Jul 2018 16:12:26 -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 2388 invoked by uid 89); 5 Jul 2018 16:12:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Would X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Jul 2018 16:12:24 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C6E5340122D2; Thu, 5 Jul 2018 16:12:22 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 16622111E418; Thu, 5 Jul 2018 16:12:21 +0000 (UTC) Subject: Re: [PATCH 1/2] darwin: Silence syscall deprecated declaration warning To: Simon Marchi References: <20180704043033.29212-1-simon.marchi@polymtl.ca> <52b499e2-748f-6f64-4368-13942e45a79c@redhat.com> Cc: gdb-patches@sourceware.org, tom@tromey.com From: Pedro Alves Message-ID: <5ee07965-3182-14d0-80ae-de3004fe2ee4@redhat.com> Date: Thu, 05 Jul 2018 16:12:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-07/txt/msg00122.txt.bz2 On 07/04/2018 05:39 PM, Simon Marchi wrote: > 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'm reasonably confident. > >> 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. If a thread was suspended by GDB, with task_suspend, I'd assume that the thread's msg_state would not be DARWIN_MESSAGE, so we wouldn't reach here. But just guessing too. > > 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? Yes, of course. I'd suggest wrapping this in a function though (darwin_pthread_kill or some such), so that the silencing would be contained there out of view. We can also mention why we need the function in its intro comment too. Thanks, Pedro Alves