From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84019 invoked by alias); 29 Mar 2017 20:30:48 -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 84006 invoked by uid 89); 29 Mar 2017 20:30:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=baldwin, HCc:D*ca, Baldwin, Apologies X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Mar 2017 20:30:45 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id C6A0310A82D; Wed, 29 Mar 2017 16:30:44 -0400 (EDT) From: John Baldwin To: gdb-patches@sourceware.org Cc: Pedro Alves , Simon Marchi , Simon Marchi Subject: Re: [PATCH] Fix usage of inferior_ptid in two thread_alive implementations Date: Wed, 29 Mar 2017 20:30:00 -0000 Message-ID: <2339561.2zYrb3lbLI@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <8688edde-759a-7f84-482d-9823a8f546b3@redhat.com> References: <20170207212450.2232-1-simon.marchi@ericsson.com> <8688edde-759a-7f84-482d-9823a8f546b3@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00513.txt.bz2 On Thursday, February 09, 2017 05:53:16 PM Pedro Alves wrote: > On 02/09/2017 04:46 PM, Simon Marchi wrote: > > On 2017-02-08 07:40, Pedro Alves wrote: > >> On 02/07/2017 09:24 PM, Simon Marchi wrote: > >>> While inspecting some target code, I noticed that in these two > >>> implementations of thread_alive, inferior_ptid is referenced directly > >>> instead of using the ptid passed as parameters. I guess that it is > >>> wrong, although I can't really test it in both cases. > >> > >> I can't test either, but it looks right to me. > > > > Soooo.. is this an approval :) ? > > OK by the end of the week to give a chance of area > maintainers or interested folks to comment. E.g., Eli > is the go32-nat.c maintainer and I don't mean to overstep, > though that bit does look obvious to me. Mark or someone > with BSD access could want to comment on the BSD bit. The > latter you could perhaps test on the compile farm, if you > have access. [ Apologies for the late reply ] I don't think any modern versions of either FreeBSD or OpenBSD use bsd-uthread.c. The uthread target is for a thread implementation that only provided threads in userland on top of a single process (like "green" threads in the JDK). FreeBSD last shipped a release with support for this thread model (FreeBSD 6.4) in 2008. I can't speak to when OpenBSD stopped using user-based threads, but the existence of kernel-based thread support in the obsd-nat target implies it isn't used anymore either. For FreeBSD at least I think it would be fine to remove bsd-uthread.c. (I should also send a patch in to remove FreeBSD/alpha as that platform was retired at around the same time. The last release to support alpha was 6.3 also released in 2008.) -- John Baldwin