[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 9 Apr 2021 08:15:51 -0400
From: 'Rich Felker' <dalias@...c.org>
To: Andrey Bugaevskiy <bugaevskiy@...dex-team.ru>
Cc: 'Florian Weimer' <fweimer@...hat.com>, musl@...ts.openwall.com
Subject: Re: errno and swapcontext in a multithreaded setup
On Fri, Apr 09, 2021 at 03:11:14PM +0300, Andrey Bugaevskiy wrote:
> 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.
Because that's a guarantee of the C language. All objects have
addresses that are constant for their lifetime. For example, if *you*
took &errno or &some_tls_var and saved it, the address you saved is
valid until the lifetime of the object ends. It will compare equal to
what you get if you take the address again. (The fact tht it doesn't
necessarily in your ucontext example is a consequence of you having
invoked UB by attempting to "move" an executing block from one thread
to another.)
Rich
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.
