Re: lib/60215: ld.elf_so dlerror() state is not thread-local

[Jörg Sonnenberger <joerg%bec.de@localhost>]

On 4/29/26 1:20 AM, Izumi Tsutsui via gnats wrote:
> The following reply was made to PR lib/60215; it has been noted by GNATS.
>
> From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
> To: gnats-bugs%netbsd.org@localhost
> Cc: tsutsui%ceres.dti.ne.jp@localhost
> Subject: Re: lib/60215: ld.elf_so dlerror() state is not thread-local
> Date: Wed, 29 Apr 2026 08:18:16 +0900
>
>   > ld.elf_so doesn't itself have any notion of threads, which makes it
>   > quite hard to make error messages thread-safe.
>   
>   >From the application's point of view, this is not only about making
>   error messages thread-safe.  If dlerror() state is process-global,
>   the usual dlerror()/dlsym()/dlerror() sequence can report an
>   unrelated error from another LWP and make the application take
>   the wrong error path.

Yes, it is possible to return unrelated errors, but for any sane 
application it shouldn't result in a different error path. That would 
mean that the application is branching based on dlerror() and not the 
actual error status of the failing function.

>   For comparison, glibc does not use a single process-global dlerror
>   state.  Its current implementation stores dlfcn failure state in
>   thread-local storage:

Yes, glibc ties its dynamic linker much tighter to libpthread. We 
haven't so far. I'm not convinced that the price is worth is here.

Joerg