Message ID | 4b19412f4ec22c719c7d0effe9e0e096@sourceware.mail.kapsi.fi |
---|---|
Headers |
Return-Path: <newlib-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6D3363857C66 for <patchwork@sourceware.org>; Wed, 30 Aug 2023 09:16:37 +0000 (GMT) X-Original-To: newlib@sourceware.org Delivered-To: newlib@sourceware.org Received: from mail.kapsi.fi (mail.kapsi.fi [IPv6:2001:67c:1be8::25]) by sourceware.org (Postfix) with ESMTPS id 6FCEC3858032 for <newlib@sourceware.org>; Wed, 30 Aug 2023 09:16:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6FCEC3858032 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sourceware.mail.kapsi.fi Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kapsi.fi DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kapsi.fi; s=20161220; h=Subject:Content-Transfer-Encoding:Content-Type:Message-ID:To: From:Date:MIME-Version:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=man8wpXNiX1j/29f9h6qw5pYQ6AfDcYXxRPng5MVAmI=; b=ZTGhxpkrsboXb0r/psXQocskrM qe22qdf08IQRlbi2HPXC+wMylyTfVQWMj0Bm+dXBoVtsv6xcCNiYPdAI9BgOm492JbwP36gEqy2Zk 7FKzk6HYeefPWGufUfxPBBZ5LLg2Dlybg0nZxf9iJJ2SMHuzAZaDtIFSVbd1v0O0dMl5omo53xLNO r/fe6+6OcmzUx/Ln9j3H7CdS4kUprHvVvSfzphRaTzaCK2PPfkv+0rFf10Dm+ZGkCbgNeDXL3baXB WkJ2ZfP3y+jyOf7LGNj3jDticT9eUkgmwQFSTdqfEbIEj/p6Qf+fk1joLtXbqHAujBcj6bIQjzJ9f NrclpmOg==; Received: from [2001:67c:1be8::200] (helo=roundcube.kapsi.fi) by mail.kapsi.fi with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <pexu@sourceware.mail.kapsi.fi>) id 1qbHJG-00D1B7-12 for newlib@sourceware.org; Wed, 30 Aug 2023 12:16:22 +0300 MIME-Version: 1.0 Date: Wed, 30 Aug 2023 12:16:21 +0300 From: =?utf-8?q?Pekka_Sepp=C3=A4nen?= <pexu@sourceware.mail.kapsi.fi> To: newlib@sourceware.org Message-ID: <4b19412f4ec22c719c7d0effe9e0e096@sourceware.mail.kapsi.fi> X-Sender: pexu@sourceware.mail.kapsi.fi Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 2001:67c:1be8::200 X-SA-Exim-Mail-From: pexu@sourceware.mail.kapsi.fi X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 Subject: [PATCH 0/3] Reentrancy X-SA-Exim-Version: 4.2.1 (built Wed, 06 Jul 2022 17:57:39 +0000) X-SA-Exim-Scanned: Yes (on mail.kapsi.fi) X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Newlib mailing list <newlib.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/newlib>, <mailto:newlib-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/newlib/> List-Post: <mailto:newlib@sourceware.org> List-Help: <mailto:newlib-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/newlib>, <mailto:newlib-request@sourceware.org?subject=subscribe> Errors-To: newlib-bounces+patchwork=sourceware.org@sourceware.org Sender: "Newlib" <newlib-bounces+patchwork=sourceware.org@sourceware.org> |
Series | Reentrancy | |
Message
Pekka Seppänen
Aug. 30, 2023, 9:16 a.m. UTC
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 <sys/reent.h> 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), <sys/reent.h> shall include <sys/cdefs.h> that will provide a correct mapping, should the compiler actually support thread-local storage. A prime example is libstdc++ configure, which uses #include <math.h> 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
Comments
Hi Pekka, your patches don't apply cleanly because your MUA added unwanted line breaks. Can you please tell your MUA not to do that and send the patches again? If that's not possible for some reason, add the patches as plaintext attachments to a single mail. 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 <sys/reent.h> 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), > <sys/reent.h> shall include <sys/cdefs.h> that will provide a correct > mapping, > should the compiler actually support thread-local storage. A prime example > is > libstdc++ configure, which uses #include <math.h> 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
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 <sys/reent.h> 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), > <sys/reent.h> shall include <sys/cdefs.h> that will provide a correct > mapping, > should the compiler actually support thread-local storage. A prime example > is > libstdc++ configure, which uses #include <math.h> 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
On 31.8.2023 12:23, Corinna Vinschen wrote: > Hi Pekka, > > your patches don't apply cleanly because your MUA added unwanted > line breaks. > > Can you please tell your MUA not to do that and send the patches again? > If that's not possible for some reason, add the patches as plaintext > attachments to a single mail. > My apologies, appears not to be possible until the next distro stable version rolls out. As that might take a while, here are the patches as plain text attachments. -- Pekka
Hello Pekka, thanks for the fixes. I reviewed the changes and checked them in.