ODP: Implementation of IO with Panama

[Florian Weimer]

* Radosław Smogura:

> But I did objdump and on my Linux the errno is symbol in .tbss
> section (thread local one),
>
> [ /usr/include ]
> radek at radek-ubuntu # objdump -T /usr/lib/x86_64-linux-gnu/libc-2.32.so |grep errno
> 0000000000000010 g    D  .tbss  0000000000000004  GLIBC_PRIVATE errno
> 0000000000029030 g    DF .text  0000000000000015  GLIBC_2.2.5 __errno_location
> 00000000001498d0 g    DF .text  000000000000005f (GLIBC_2.2.5) clnt_sperrno
> 0000000000149930 g    DF .text  0000000000000084 (GLIBC_2.2.5) clnt_perrno
> 000000000000006c g    D  .tbss  0000000000000004  GLIBC_PRIVATE __h_errno
> 0000000000129b60 g    DF .text  0000000000000015  GLIBC_2.2.5 __h_errno_location

errno is a GLIBC_PRIVATE symbol, so it's expected to be used
internally by glibc only.

Applications are expected to call __errno_location instead and use the
returned pointer to access the errno thread-local variable.  <errno.h>
defines a macro to achieve this redirection.

I can propose to make errno part of the public glibc ABI in a future
glibc version.  However, on several platforms, using __errno_location
tends to result in tighter code, so we will likely keep it.  If
initial-exec TLS could be used to access errno, it will be faster, but
due to the way most POSIX APIs work, such access happens only on error
paths, so tighter code seems the better choice here.

I hope this answers your implied questions.