From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13055 invoked from network); 21 May 2020 21:50:03 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 21 May 2020 21:50:03 -0000 Received: (qmail 26106 invoked by uid 550); 21 May 2020 21:50:01 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26087 invoked from network); 21 May 2020 21:50:00 -0000 Date: Thu, 21 May 2020 17:49:48 -0400 From: Rich Felker To: Harald Welte Cc: musl@lists.openwall.com Message-ID: <20200521214948.GL1079@brightrain.aerifal.cx> References: <20200521202253.GC601762@nataraja> <20200521204048.GJ1079@brightrain.aerifal.cx> <20200521211927.GE601762@nataraja> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200521211927.GE601762@nataraja> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] MUSL ignores__attribute__((constructor(priority))) ? 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