On Thu, Aug 29, 2019 at 2:50 PM Waldek Kozaczuk
wrote:
> Musl treats DT_VERSYM as an array of int16_t (signed) instead of what we
> do and should do - Elf64_Versym aka uint16_t. And then the simply check
> if that version number is negative:
>
> int16_t *versym;
>
> ...
>
> (!dso->versym || dso->
Musl treats DT_VERSYM as an array of int16_t (signed) instead of what we do
and should do - Elf64_Versym aka uint16_t. And then the simply check if
that version number is negative:
int16_t *versym;
...
(!dso->versym || dso->versym[i] >= 0)
We instead check if the bit is set which is more corre
On Thu, Aug 29, 2019 at 1:28 AM Waldek Kozaczuk
wrote:
> Here is this bit from https://www.akkadia.org/drepper/symbol-versioning:
>
> "If the highest bit (no. 15) of the version symbol value is set, the
>
> object is hidden and must not be used. In this case the linker must
> treat the symbol as
Here is this bit from https://www.akkadia.org/drepper/symbol-versioning:
"If the highest bit (no. 15) of the version symbol value is set, the
object is hidden and must not be used. In this case the linker must
treat the symbol as not present in the object."
This seems to explain what musl is d
>From https://wiki.musl-libc.org/functional-differences-from-glibc.html
"Symbol versioning
glibc allows the usage of versioned symbols through version tables in
gnu-specific elf sections. the musl dynlinker only supports the subset of
symbol versioning that allows to pick the default symbol ve
