Re: [musl] MUSL ignores__attribute__((constructor(priority))) ?

[Rich Felker <dalias@libc.org>]

On Thu, May 21, 2020 at 11:19:27PM +0200, Harald Welte wrote:
> Hi Rich,
> 
> thanks for your super-fast response.
> 
> On Thu, May 21, 2020 at 04:40:49PM -0400, Rich Felker wrote:
> > On Thu, May 21, 2020 at 10:22:53PM +0200, Harald Welte wrote:
> > > 1) if there are multiple libraries (in this example libosmocore and libtalloc,
> > >    where libosmocore depends on libtalloc), the __attribute__((constructor))
> > >    functions are not called in inverse dependency order, i.e. the talloc
> > >    ones are *not* called before those of libosmocore.
> > 
> > They should be, since commit 188759bbee057aa94db2bbb7cf7f5855f3b9ab53
> > (releases 1.1.22 and later). Are you using an older version?
> 
> According to the OpenWRT build I have been provided by a 3rd party, it's
> using musl-1-1.23.

Can you confirm this to make sure we're not debugging an issue that's
long since fixed? Run /lib/ld-musl-armhf.so.1 as a command and it will
print its version.

> I meanwhile also found that the ELF specifications
> back to 1997 already specify that this ordering is required of a linker.

FWIW the only standards that musl purports to actually adhere to are
C, POSIX, and IEEE 754 (as referenced by C Annex F). While ELF is the
binary format used and we aim to use it in compatible ways so as not
to be gratuitously breaking, there are a lot of details that do not
match historical SysV behavior (this is also true on glibc to a lesser
extent), e.g. historical RPATH vs RUNPATH difference, LD_* vars, etc.
Dependency order for ctors was adopted as an enhancement because it
was deemed very reasonable and interacts better with other things (see
the commit message for the commit cited above) but was not part of
original requirements for musl. I only bring this up because
"historical SysV documents say you have to do things this way" is not
*automatically* a compelling argument for what musl should do, just
one ingredient for consideration.

> There clearly is no circular dependency either:
> 
> # ldd ./libosmocore.so
>         ldd (0xb6f46000)
>         libtalloc.so.2 => /usr/lib/libtalloc.so.2 (0xb6efd000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6ee2000)
>         libc.so => ldd (0xb6f46000)
> 
> # ldd ./libtalloc.so
>         ldd (0xb6f5b000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6f29000)
>         libc.so => ldd (0xb6f5b000)
> 
> and the executable linking against both of them:
> 
> # ldd /usr/sbin/osmo-remsim-client-st2
>         /lib/ld-musl-armhf.so.1 (0xb6eeb000)
>         libosmogsm.so.13 => /usr/lib/libosmogsm.so.13 (0xb6e8d000)
>         libosmoabis.so.6 => /usr/lib/libosmoabis.so.6 (0xb6e67000)
>         libosmousb.so.0 => /usr/lib/libosmousb.so.0 (0xb6e53000)
>         libosmo-simtrace2.so.0 => /usr/lib/libosmo-simtrace2.so.0 (0xb6e40000)
>         libusb-1.0.so.0 => /usr/lib/libusb-1.0.so.0 (0xb6e23000)
>         libosmo-rspro.so.1 => /usr/lib/libosmo-rspro.so.1 (0xb6df3000)
>         libtalloc.so.2 => /usr/lib/libtalloc.so.2 (0xb6ddc000)
>         libosmocore.so.12 => /usr/lib/libosmocore.so.12 (0xb6daa000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb6d8f000)
>         libc.so => /lib/ld-musl-armhf.so.1 (0xb6eeb000)
>         libosmovty.so.4 => /usr/lib/libosmovty.so.4 (0xb6d63000)
>         libosmosim.so.0 => /usr/lib/libosmosim.so.0 (0xb6d43000)
> 
> (executed using the musl ldd on the target itself)

Indeed it looks to me like this should work fine and libtalloc's ctors
should ru nbefore libosmocore's.

> Still, I can show very clearly while stepping through [remote] gdb that
> the constructor of libosmocore is called before that of talloc.

If this is >=1.1.22 then there's probably a bug in either the
topological sort or the deps-list going into it.

> I can share the binaries if you'd like (armv7l) or provide you with any other
> diagnostic output.

If it's not just that you're using an old version of musl, could you
put the binaries (full set of libs from ldd) somewhere and share a
link?

Rich