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

["Jörg Sonnenberger via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR lib/60215; it has been noted by GNATS.

From: =?UTF-8?Q?J=C3=B6rg_Sonnenberger?= <joerg%bec.de@localhost>
To: gnats-bugs%netbsd.org@localhost, lib-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
Cc: 
Subject: Re: lib/60215: ld.elf_so dlerror() state is not thread-local
Date: Wed, 29 Apr 2026 11:28:14 +0200

 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