[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <001e01d72c9f$09d1b700$1d752500$@yandex-team.ru>
Date: Thu, 8 Apr 2021 20:46:00 +0300
From: "Andrey Bugaevskiy" <bugaevskiy@...dex-team.ru>
To: "'Florian Weimer'" <fweimer@...hat.com>
Cc: <musl@...ts.openwall.com>
Subject: RE: errno and swapcontext in a multithreaded setup
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.
I believe the only reason optimizer is allowed to remove the call
to __errno_location is the "const" attribute.
--
Andrey Bugaevskiy
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
