From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id C5AC83858D37 for ; Thu, 31 Aug 2023 09:24:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C5AC83858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1693473899; h=from:from:reply-to: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=nWfD1m/v2zm3mgeU9GmI6bV4DYEx2qrDQSAEqa2xXnk=; b=C7NegaCetuUft/9As+IcT7g/c3fRnZUhaaaQ6OBs3yLRTTy7Idb05SrFHhVcP99H2ljHwN 6zOzHK7sbYHFA4Nx+Av8XPehdVQ4/q885SpNdEFeVqPzG0IvwZwLCEK5j+dyDhVHKF/a90 cS3F2j7tnl+f97AkEcufEg46jDKS4Uc= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-655-WDCdx6hhMuqjwii7tp26iw-1; Thu, 31 Aug 2023 05:24:56 -0400 X-MC-Unique: WDCdx6hhMuqjwii7tp26iw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id ED1783814961; Thu, 31 Aug 2023 09:24:55 +0000 (UTC) Received: from calimero.vinschen.de (unknown [10.39.192.15]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CBB42140E96E; Thu, 31 Aug 2023 09:24:55 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id B9095A807AC; Thu, 31 Aug 2023 11:24:54 +0200 (CEST) Date: Thu, 31 Aug 2023 11:24:54 +0200 From: Corinna Vinschen To: Sebastian Huber Cc: newlib@sourceware.org Subject: Re: [PATCH 0/3] Reentrancy Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: Sebastian Huber , newlib@sourceware.org References: <4b19412f4ec22c719c7d0effe9e0e096@sourceware.mail.kapsi.fi> MIME-Version: 1.0 In-Reply-To: <4b19412f4ec22c719c7d0effe9e0e096@sourceware.mail.kapsi.fi> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Sebastian, given you're the one pushing the thread_local change in the first place, would you mind to review this, too? Looks good to me, but I'd like to have your input on this. If you think the patches are ok, feel free to push them. Thanks, Corinna On Aug 30 12:16, Pekka Seppänen wrote: > Hi, > > The following patch series provides small (one line) fixes for newlib/libc > reentrancy when using --enable-newlib-reent-thread-local and uses the > existing > infrastructure to do that: > > - There were a few locations on which _errno member was directly accessed. > As struct _reent is not available if _REENT_THREAD_LOCAL is defined, any > accesses to errno shall be done using the corresponding _REENT_ERRNO() > macro. > Should be self-explanatory. > > - __getreent() did not check that struct _reent and _impure_ptr were > available. Both and impure.c, that declare and define > _impure_ptr, use similar #ifdef/ifndef gate. If thread-local storage is > used > the allocated objects are not related to each other. Therefore __getreent() > does not exist even at a concept level, hence should not be provided at all. > > - As _Thread_local might not be available (as in that particular keyword), > shall include that will provide a correct > mapping, > should the compiler actually support thread-local storage. A prime example > is > libstdc++ configure, which uses #include in some of the generated > checks. Essentially any C++ target is affected and possibly C targets in > near future as C23 uses thread_local, not _Thread_local. > > It should be noted that libgloss is affected by similar reentrancy issues, > but > I decided not to touch those. > > -- Pekka