[RFC] Should we declare errno with __thread on x86?

[Szabolcs Nagy]

On 13/04/16 13:37, Torvald Riegel wrote:
> On Wed, 2016-04-13 at 11:17 +0200, Florian Weimer wrote:
>> On 04/12/2016 08:30 PM, Torvald Riegel wrote:
>>> On Fri, 2016-03-18 at 16:14 -0700, Roland McGrath wrote:
>>>> If real-world performance measurement does in fact justify it, we'll still
>>>> need to be very circumspect about potential pitfalls (applications built
>>>> with older compilers, etc).  We'll need to put a lot of thought into it
>>>> collectively to achieve confidence that it's a safe and sensible change for
>>>> all our users.
>>>
>>> I agree that this would need a thorough investigation and assessment of
>>> risks of doing that.  One risk I see is that it would likely make it
>>> harder for us to support errno on threads of execution that are not OS
>>> threads (eg, coroutines, or under work-stealing implementations).
>>
>> It will not be worse than what we currently have because 
>> __errno_location is declared const.  Already today, resuming a call 
>> stack on a thread other the one on which it was suspended results in 
>> undefined behavior.  This also applies to most forms of TLS access (if 
>> not all of them), again due to compiler caching of TLS variable addresses.
> 
> That is a an interesting point, good catch.  But I disagree with your
> conclusion.
> 
> The const attribute is specified as asserting that the function does not
> examine any data except the arguments.  __errno_location has no
> arguments, so it would have to return the same values *every time*.
> This works in a single-threaded program, but not in a multi-threaded
> one.  Thus, I think that strictly speaking, it should not be const.
> 

that was my conclusion too, reading the second point in
https://gcc.gnu.org/ml/gcc/2015-09/msg00354.html
but there was no further discussion then..

> We could argue that this magically is meant to always be in the context
> of a specific thread.  Ignoring that GCC doesn't define threads itself
> (especially in something like NPTL which is about creating a notion of
> threads), we could still assume that this works because in practice, the
> compiler and its passes can't leak knowledge across a function used in
> one thread and other one used in another thread.  But then this would
> still hold for coroutines, I guess, if we can manage to have
> __errno_location return a coroutine-specific location if this is
> executed in a coroutine.  It would limit the amount of inlining we can
> do though.
> 
>> (Your job is to make sure that we can implement C++ coroutines with 
>> something substantially more lightweight than threads, while still 
>> keeping all our existing binaries, particularly libraries. :)
> 
> :)
> 
> TLS, signals, and all these things make this challenging.  Maybe some
> execution agents will only work with C++ code; it could happen that we
> just can't preserve some of the old semantics...
> 
>