This is the mail archive of the
mailing list for the glibc project.
Re: __libc_single_threaded design
* Siddhesh Poyarekar:
> On 07/10/19 2:23 pm, Florian Weimer wrote:
>>> My understanding of the __libc (or __cxa on the other end) namespace is
>>> that you'd want it if libstdc++ (and standard libraries, including glibc
>>> itself) are the *only* intended users. For a proper public symbol (i.e.
>>> something we declare as widely available) it seems better to me to have
>>> a name without the __libc prefix.
>> We can make pthread_single_threaded_np. That variable libstdc++ might
>> even want to use directly, without a __ prefix.
>> I do not feel *very* strongly about this. But adding a second variable
>> due to aesthetic considerations, possibly introducing bugs as a result,
>> is not something what I like.
>> We had this discussion several years ago about __secure_getenv. Oh
> I'm more inclined towards not having a __* name and having just one
> variable (with a libc.so-private alias to skip the indirection) if it's
> not necessary.
There would have to be a second, hidden copy of the variable. We cannot
make them the same variable because copy relocations break such aliases.
(Ideally, we would not want this variable to be subject to a copy
relocation so that we can control inside glibc what ends up on the same
cache line, but the toolchain currently does not support that.)
In effect, we'd have that if we added just pthread_single_threaded_np
(without removing anything) because there's already some information
that powers the architecture-specific SINGLE_THREAD_P macro.
> I found the patch thread as well, so I can help with the patch review
> for this.
I'll post a new revision (with the changed name) once I've got the new
ld.so/libc.so hand-off code, which will hopefully the initialization far