From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18140 invoked from network); 9 Apr 2021 12:12:29 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 9 Apr 2021 12:12:29 -0000 Received: (qmail 15723 invoked by uid 550); 9 Apr 2021 12:12:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 14211 invoked from network); 9 Apr 2021 12:11:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1617970275; bh=l7UJk/B0RXtE/emrI2VaOTpzgY+DQRkeHXeY6F6Xjwc=; h=Message-ID:References:Date:Subject:To:From:In-Reply-To:Cc; b=t8aVWHDKePUPmyy8G2OStspfzGOBciYYDMD78WymDIJOOuo4PTIL1WWzIMvLkBgLP vRoQ9supbd1Xpk5p6i0ZAbhMFDmuwAEK9uRIQqjhn7D8sOpou7ukMBcLm2vP2ta09K RxwLDYlkE4A+6Y369Y/Sb+RIMWrjhsdEoxMh8GP0= Authentication-Results: myt5-23f0be3aa648.qloud-c.yandex.net; dkim=pass header.i=@yandex-team.ru From: "Andrey Bugaevskiy" To: "'Rich Felker'" Cc: "'Florian Weimer'" , References: <00bc01d72c91$bdedb030$39c91090$@yandex-team.ru> <87wntc1zee.fsf@oldenburg.str.redhat.com> <001e01d72c9f$09d1b700$1d752500$@yandex-team.ru> <20210408185511.GC2546@brightrain.aerifal.cx> In-Reply-To: <20210408185511.GC2546@brightrain.aerifal.cx> Date: Fri, 9 Apr 2021 15:11:14 +0300 Message-ID: <00d101d72d39$70639840$512ac8c0$@yandex-team.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFhj4vmgm0to5vZEvd03mIy9uPHmQMDxG0XAiAQLcICwgjwcKtYJK5Q Content-Language: ru Subject: RE: [musl] errno and swapcontext in a multithreaded setup On Thu, 8 Apr 2021, Rich Felker wrote: > On Thu, Apr 08, 2021 at 08:46:00PM +0300, Andrey Bugaevskiy wrote: > > On Thu, 8 Apr 2021, Florian Weimer wrote: > > > * Andrey Bugaevskiy: > > > > > > > I'm using makecontext/swapcontext to migrate contexts between threads > > > > and this sometimes leads to getting incorrect errno values. > > > > > > > > Investigating further I've noticed that __errno_location > > > > is marked __attribute__((const)). > > > > This causes optimizers to assume that errno address never changes > > > > in the scope of the function which is not the case in my scenario. > > > > > > The optimizers make the same assumption for actual thread-local > > > variables, not just __errno_location. Migrating contexts between > > > threads results in undefined behavior. > > > > Can you please point me to some explanation why this optimization > > is valid for thread-local variables? > > > > As far as I can imagine optimizer should at least prove that it > > won't be changed from some other place or (if the variable is local > > to the function) that it is not changed by a recursive call. > > Perhaps you're confusing the value of errno with its address. No > function can change the address of errno, only its value. > Conceptually, __errno_location() is just &errno. Well, it's a function returning a value, but I see the point. I'm still a bit confused about why optimizer can assume that TLS location never changes though. Thanks to everyone for their replies. -- Andrey Bugaevskiy