Re: Fwd: MIPSEL GLIBC sem_init() not shared

[Alessandro Carminati <alessandro.carminati@gmail.com>]

On Fri, Mar 12, 2021 at 5:04 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Alessandro Carminati via Libc-help:
>
> > Al the sources I have found seems to agree on the fact that if a
> > symbol is unversioned, like in my case, the symbol the dynamic linker
> > should use is the one that carries the "@@"
>
> I think they talk about the link editor (static linker) chosing the
> symbol version, and not about what happens at run time.

Thank you for your explanation. I want you to know my appreciation for your
contribution.
Back to the topic; about your last statement, I'm quite confused.
For example, if the target of the double @@ feature is the static linker,
why they talk about it in a post where the topic is DSO?
Why this double @@ is mainteined inside the DSOs?
Reflecting on my scenario I see that the dynamic linker finds quite unusual
situation where the symbol is required and there's no dependency on the DSO
containing it, and no indication (.gnu.version_r) about how to handle it.
My assumption was that the double @@ would handle these situation, but it
is reasonable that this situation to have another handling.
For this reason my current understanding is that the dynamic linker would
use default the double @@ indicated function, where the .gnu.version_r is
present but not populated, and use the older symbol where
the .gnu.version_r is missing. This way it would handle correctly the
situation where old executables do not have the section because it didn't
exist yet.
I will check the dynamic linker source code to confute or confirm this
hypothesis.

Thanks
Alessandro