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 X-Patchwork-Id: 21433 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. */