From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) by sourceware.org (Postfix) with ESMTPS id 219863891C0F for ; Mon, 10 Jan 2022 09:29:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 219863891C0F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embedded-brains.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embedded-brains.de Received: from sslproxy06.your-server.de ([78.46.172.3]) by dedi548.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1n6qzL-0002j6-Fs for newlib@sourceware.org; Mon, 10 Jan 2022 10:29:15 +0100 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy06.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n6qzL-000Ob8-DE for newlib@sourceware.org; Mon, 10 Jan 2022 10:29:15 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 1214E480049 for ; Mon, 10 Jan 2022 10:29:15 +0100 (CET) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id tSVWM4EK58uK for ; Mon, 10 Jan 2022 10:29:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id BFBBC4800BA for ; Mon, 10 Jan 2022 10:29:14 +0100 (CET) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id w97IF374fD4x for ; Mon, 10 Jan 2022 10:29:14 +0100 (CET) Received: from [10.10.171.10] (unknown [10.10.171.10]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 35E77480049 for ; Mon, 10 Jan 2022 10:29:08 +0100 (CET) Message-ID: <32452837-4a35-d458-c971-c5c1e4f92290@embedded-brains.de> Date: Mon, 10 Jan 2022 10:28:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Newlib From: Sebastian Huber Subject: Optionally use thread-local objects for struct _reent members Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.3/26417/Sun Jan 9 10:22:56 2022) X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Mon, 10 Jan 2022 09:29:23 -0000 Hello, Newlib currently uses a huge object of type struct _reent to store=20 thread-specific data. This object is returned by __getreent() if the=20 __DYNAMIC_REENT__ Newlib configuration option is defined. The reentrancy structure contains errno and also the standard input,=20 output, and error file streams. This means that if an application only=20 uses errno it has a dependency on the file stream support even if it=20 does not use it. This is an issue for lower end targets and applications=20 which need to qualify the software according to safety standards (for=20 example ECSS-E-ST-40C, ECSS-Q-ST-80C, IEC 61508, ISO 26262, DO-178, DO-330, DO-333). One approach to disentangle the dependencies introduced by struct _reent=20 is to get rid of this structure and replace the individual members of=20 the structure with thread-local objects. For example, instead of struct _reent { int _errno; __FILE *_stdin; __FILE *_stdout; __FILE *_stderr; }; use _Thread_local int _errno; _Thread_local __FILE *_stdin; _Thread_local __FILE *_stdout; _Thread_local __FILE *_stderr; if a new configuration option is defined (for example _REENT_THREAD_LOCAL= ). Newlib already has access macros for some struct _reent members, for=20 example: #define _REENT_SIGNGAM(ptr) ((ptr)->_new._reent._gamma_signgam) #define _REENT_RAND_NEXT(ptr) ((ptr)->_new._reent._rand_next) #define _REENT_RAND48_SEED(ptr) ((ptr)->_new._reent._r48._seed) #define _REENT_RAND48_MULT(ptr) ((ptr)->_new._reent._r48._mult) #define _REENT_RAND48_ADD(ptr) ((ptr)->_new._reent._r48._add) The member access macros are incomplete. We would have to add macros for=20 all the struct _reent members. Would this be an approach acceptable for=20 Newlib integration? --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/