errno/h_errno

Florian Weimer fweimer@redhat.com
Tue Jun 10 08:14:02 GMT 2025


* H. Peter Anvin:

> On 2025-06-09 20:51, H. Peter Anvin wrote:
>> Ok, I grok that back in 2016 the tools might not have been ready
>> yet, but in 2025?
>> 
>
> It is also perhaps worth noting that the errno TLS symbol is already
> globally exported and visible. This code works exactly as expected
> when linked against current glibc, either statically or dynamically:
>
> #define _GNU_SOURCE
> #include <stdio.h>
> #include <errno.h>
> #include <unistd.h>
> #include <string.h>
>
> #undef errno
> extern __thread int errno __attribute__((tls_model("initial-exec")));
>
> int main(void)
> {
>     errno = 0;
>     close(999);
>     /* errno should be EBADF now */
>     printf("errno = %d (%s), &errno = %p, __errno_location = %p\n",
> 	   errno, strerrorname_np(errno), &errno, __errno_location());
>     return 0;
> }

This puts a GLIBC_PRIVATE reference into applications, which interferes
with distribution dependency management.  This could be fixed by
exporting it as errno@@GLIBC_2.42.

However, I'm not sure if we want to promote an initial-exec TLS
reference, it makes it more difficult to move libc.so.6 off initial-exec
TLS as a whole, to allow more dlmopen namespaces.  Code overhead with
GNU2 TLS descriptors is rather low, only with the __tls_get_addr calls,
the function call approach is a clear win in terms of code size.  (I was
concerned about code size during the last discussion.)

Thanks,
Florian



More information about the Libc-alpha mailing list