From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88453 invoked by alias); 31 Jan 2020 14:23:07 -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 88445 invoked by uid 89); 31 Jan 2020 14:23:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=High, debugged, Alexandre, alexandre X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 31 Jan 2020 14:23:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1580480585; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kzDoi8dcpTf8KfWMNfdyksZbwgGhiLq+8jin9uY5tNA=; b=KmQgbHIcBnMNkUV51nrIE3n1cTStxZdfope0hAMWwcNxmF5ZJhw3yUJ30qIoB4E6eL6XZ/ pFfUKTLjdlULxBvkpBxIuOGQuq9sw8TzMVFExHc5xP5/47btO+vnwFg1thkmwXjcDNSv8N CBrqFJI7jYBFtHJB7XYN6A+wQhKqrQE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-252-AebA0cA-Ow6EhpoDy9Nh4Q-1; Fri, 31 Jan 2020 09:23:02 -0500 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5C5C18017CC; Fri, 31 Jan 2020 14:23:01 +0000 (UTC) Received: from f31-4.lan (ovpn-116-54.phx2.redhat.com [10.3.116.54]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2F7EA60BE1; Fri, 31 Jan 2020 14:23:00 +0000 (UTC) Date: Fri, 31 Jan 2020 14:43:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Cc: Tom Tromey Subject: Re: [PATCH] Fix build on macOS Message-ID: <20200131072300.5062774a@f31-4.lan> In-Reply-To: <20191210214717.25680-1-tromey@adacore.com> References: <20191210214717.25680-1-tromey@adacore.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg01001.txt.bz2 On Tue, 10 Dec 2019 14:47:17 -0700 Tom Tromey wrote: > PR build/25268 points out that the build fails on macOS, because on > macOS the "pthread_setname_np" function takes a single argument. > > This patch fixes the problem, by introducing a new template adapter > function that handles both styles of pthread_setname_np. This is a > technique I learned from Alexandre Oliva, and avoids the need for a > complicated autoconf check. > > This change also meant moving the pthread_setname_np call to the > thread function, because macOS only permits setting the name of the > current thread. This means that there can be a brief window when gdb > will see the wrong name; but I think this is a minor concern. > > Tested by rebuilding on x86-64 Fedora 30, and on macOS High Sierra. > On Linux I also debugged gdb to ensure that the thread names are still > set correctly. > > gdb/ChangeLog > 2019-12-10 Tom Tromey > > PR build/25268: > * gdbsupport/thread-pool.c (set_thread_name): New template > function. > (thread_pool::set_thread_count): Don't call pthread_setname_np. > (thread_pool::thread_function): Call set_thread_name. Did this ever go in? If not, I think it looks reasonable. Kevin