From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) by sourceware.org (Postfix) with ESMTPS id 57E053858024 for ; Thu, 1 Apr 2021 04:58:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 57E053858024 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nicolachel.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cl26@nicolachel.net DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nicolachel.net; s=default; h=Content-Transfer-Encoding:Content-Type: Message-ID:Subject: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=JvYGaQ4ywHWxJ1BnMupJfCkYPpt9LqIohpJscvjdkdA=; b=TY9cft0LQvklTaZzRKaN1AqzZE n6ih7+1ESU61RW5Vv+CkwaGiiet+PT1kc89wPOCu4wb1ZRPqjL9QbyBJfFMKgqr6mCzhN0iAApQ52 iw9d7WnhgCNKit5BhwmSmnF2BFI+MgePa0xGQ4op1zQKoBkCjO2PSc//rIg0y05EMJrg0n68KjZh7 7elZsnKjM2f6H7gxm1fIh310PotpOxYyaFGl8CTaDzAzVvK+7gauzDSb1Ewg9lLk25OY1yTctL67P ruNCrarG4oIaZLCbTrynvsn+PM2auiqda7/gQFyhvyGTSlrSdplJ+wtxYKd3rYAq8sLWrCgRQusGA AAh3peSA==; Received: from [::1] (port=40472 helo=direct.host-care.com) by direct.host-care.com with esmtpa (Exim 4.93) (envelope-from ) id 1lRpPJ-0006vo-EQ for newlib@sourceware.org; Thu, 01 Apr 2021 00:58:13 -0400 MIME-Version: 1.0 Date: Thu, 01 Apr 2021 00:58:13 -0400 From: Nick To: newlib@sourceware.org Subject: Some questions on reentrancy, __DYNAMIC_REENT__ and _impure_ptr Message-ID: X-Sender: cl26@nicolachel.net User-Agent: Roundcube Webmail/1.3.15 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nicolachel.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: webmaster@nicolachel.net X-Authenticated-Sender: direct.host-care.com: webmaster@nicolachel.net X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2021 04:58:16 -0000 Hi, I've been trying to enable reentrancy of newlib on a home brew kernel for the x86 platform and have some questions on how various pieces all fits together. Implemented __getreent () to return a private copy of struct reent, and also hard coded __DYNAMIC_REENT__ and GETREENT_PROVIDED in sys/config.h to rule out any issue of passing in via build CFLAGS or the CFLAGS in configure.host. Things including errno seem to work but not totally making sense. As many library functions are still accessing the reent structure using _impure_ptr instead of calling my __getreent () function, for example, the CHECK_INIT (_REENT, fp) at the beginning of __swsetup_r (struct _reent *ptr, register FILE * fp). Questions: 1. Are the library functions expected to still use _impure_ptr instead of calling __getreent () when both __DYNAMIC_REENT__ and GETREENT_PROVIDED are hard coded in sys/config.h? If so, how do they provide reentrancy? Since _impure_ptr is a global pointer visible to all threads and threads can easily step on each other's toes trying to change fields in the reent structure pointed to by _impure_ptr concurrently. If not, what other MACROs or changes should I make so that all the library functions all use __getreent () instead of _impure_ptr? Is it okay to set _impure_ptr to a bad value such as NULL in this case, in order to catch any unintended access? 2. in the documentation on https://sourceware.org/newlib/, the following is mentioned as needed for syscalls stubs to return errno: #include #undef errno extern int errno; If I do include this part, all the syscalls stubs seem to do when they assign values to errno is setting the global int errno; inside reent.c. As user code built against the library don’t read out that integer but instead calls __(), errno set by syscall stubs can't be read out by user code. If on the other hand I don’t include this part before my syscall stubs, the errno set by them do seem to work as they also set the copy in reent structures. What might I have missed here? 3. There were some old discussions about manually changing _impure_ptr at each context switch. But I’m wondering about the validity of such a method since it seems like a really clumsy maneuver for kernel code at CPL0 to reach into user space belonging to different binaries to change a global pointer. What's more, if manually changing _impure_ptr at each context switch is needed, then what would be the purpose of __DYNAMIC_REENT__, GETREENT_PROVIDED and implementing a __getreent () to get a thread local version? 4. Is _global_impure_ptr thread safe? It is a bit concerning as it seems to be pointing to the same copy of impure_data that some libraries calls would access, and even if I try to change _impure_ptr at each context switch, some threads might still be accessing _global_impure_ptr concurrently? 5. There were also old discussions about having to provide mutex for malloc, is this still the case for newer versions of newlib like 4.10? Thanks! Nick