From patchwork Wed Jul 5 13:48:06 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adhemerval Zanella Netto X-Patchwork-Id: 784625 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3x2hzy0LdJz9s8V for ; Wed, 5 Jul 2017 23:49:01 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="NEpD/qgA"; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=F0aNI56kxK6uGRlM 4KnUvAHRVmM9uGbF91KlqBO8B4VG17QDQrFKmFjEwt8nvF4eSwRx3MSE7VTf9bgR 2enRXb+KTrTNv4oKU8NN/qRMPA1ujV+8Wp04ipdJqbfWgZBETI4zREyAI84o8XYR YIoqQR4w3Bkh1Q0b/xN001xiMRo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=OWGvytyQ6UV6NWoZwuOg7I bs79U=; b=NEpD/qgAlshLxVLutVfwZpGqSVudkOda6H5D4W4T2eBAxd4kXXA7Ss HjngImvR7A2QO+6ayV/wQ+0Rh0cqlS2tLh5qwUZDANlOAkn5/qCWV6szSY7iT1Dd 0cdxL4yGXAwmNQ5MoIL3eP9Szy2w/40dis+5DL5t/Hlx9PjcakQ14= Received: (qmail 33204 invoked by alias); 5 Jul 2017 13:48:45 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 26347 invoked by uid 89); 5 Jul 2017 13:48:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-16.4 required=5.0 tests=BAYES_00, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM, SPF_PASS autolearn=ham version=3.3.2 spammy=validated, Hx-languages-length:2344 X-HELO: mail-qk0-f182.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Klkx/GKEOlqe43Rk8jAC150bTDBdVtCwTgS/OC3ALEo=; b=ayPOi2YlpKwzv92gybIMTulngnsI4t5vn49+J1ALgdsEuTOVXypgopjgMNryJK6p8B TQXA61if+dm8ifa3BOmo71tbrPClN5qexIxJ3ZM56tsfzAbQyardET+fqScuTGCpAxrb N4tGCCcCyGgw75FSIMxkAs5NcQQcwgxNeMgS7N1TBlCOPTWhnDM+Y3ec7gPKJLsTR/En wlI8gLe9Q9F7nAuqRupnBsluqrefAlJWPn2FqAfm5qS/q8GCQBNrPYOaT1DEfq7DPZeq rM7xqRCZZf6fJZrCi2J9sVAArUFTJSWOontuSU0rEFJzuFKFv0L7IrYZVBoNCMJZkVuz cIuA== X-Gm-Message-State: AIVw112WRdrM43fRWKOMz7WEy77QcR7E1JS0lwnIDHa+G+nZ0cRtmL4o a8JroA43jQQ0okS6myjxPg== X-Received: by 10.55.209.139 with SMTP id o11mr5944946qkl.144.1499262489515; Wed, 05 Jul 2017 06:48:09 -0700 (PDT) Subject: Re: 2.26 release blockers? To: Joseph Myers , Siddhesh Poyarekar Cc: libc-alpha@sourceware.org References: <6ce02dfc-d8e8-bcd8-4ced-a09293cf1732@redhat.com> <8bcba445-524d-c0b2-cd11-03ef82f3f5a5@linaro.org> <1065eb07-b190-6edd-fc53-a717569a2273@gotplt.org> <7d896fb7-b83e-41e9-527d-01be5e299b89@gotplt.org> From: Adhemerval Zanella Message-ID: Date: Wed, 5 Jul 2017 10:48:06 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: On 05/07/2017 07:34, Joseph Myers wrote: > On Wed, 5 Jul 2017, Siddhesh Poyarekar wrote: > >>> there's also the possibility of interactions with the thread types >>> headers, if there's anything in the architecture-specific headers that >>> works for pthreads but not for C11 threads. >> >> From a quick look at the changes, I couldn't find any changes in the >> arch-specific sysdeps directories other than the abilist changes, i.e. >> there are no architecture-specific headers. Bugs in C11 should thus be > > The thread types headers refactoring, to make them usable for both C11 > threads and pthreads, went in some time ago. > > All that architecture-specific header content will get used in C11 threads > and it's far from obvious that any issues that appear with C11 threads > would also appear with pthreads. It was not clear to me if you still consider C11 threads patches a disruptive for arch-testing that can't not get validated in current cross-compiling testing. I think the only snippet that differs significantly from pthread is related to thread creation [1] where since different signatures between POSIX and C11 I had to add an explicit cast and recast: iff --git a/nptl/pthread_create.c b/nptl/pthread_create.c index 7a970ff..3efb76d 100644 Besides that, all other implementation uses pthread code directly and with a validation of pthread primitives it should not show any issues as you pointed out. [1] https://sourceware.org/ml/libc-alpha/2017-06/msg01418.html --- a/nptl/pthread_create.c +++ b/nptl/pthread_create.c @@ -461,7 +461,19 @@ START_THREAD_DEFN LIBC_PROBE (pthread_start, 3, (pthread_t) pd, pd->start_routine, pd->arg); /* Run the code the user provided. */ - THREAD_SETMEM (pd, result, pd->start_routine (pd->arg)); + void *ret; + if (pd->c11) + { + /* The function pointer of the c11 thread start is cast to an incorrect + type on __pthread_create_2_1 call, however it is casted back to correct + one so the call behavior is well-defined (it is assumed that pointers + to void are able to represent all values of int. */ + int (*start)(void*) = (int (*) (void*)) pd->start_routine; + ret = (void*) (intptr_t) start (pd->arg); + } + else + ret = pd->start_routine (pd->arg); + THREAD_SETMEM (pd, result, ret); } /* Call destructors for the thread_local TLS variables. */