[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 21 May 2020 23:19:27 +0200
From: Harald Welte <laforge@...monks.org>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: MUSL ignores__attribute__((constructor(priority))) ?
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. I meanwhile also found that the ELF specifications
back to 1997 already specify that this ordering is required of a linker.
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)
Still, I can show very clearly while stepping through [remote] gdb that
the constructor of libosmocore is called before that of talloc.
Also, here the 'readelf -d' output of the related objects:
$ readelf -d ./build_dir/target-arm_cortex-a8+vfpv3_musl_eabi/talloc-2.1.14/bin/shared/libtalloc.so.2
Dynamic section at offset 0x5dd4 contains 31 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so]
0x0000000e (SONAME) Library soname: [libtalloc.so.2]
0x0000000c (INIT) 0x1d4c
0x0000000d (FINI) 0x4cf0
0x00000019 (INIT_ARRAY) 0x15dc8
0x0000001b (INIT_ARRAYSZ) 8 (bytes)
0x0000001a (FINI_ARRAY) 0x15dd0
0x0000001c (FINI_ARRAYSZ) 4 (bytes)
0x00000004 (HASH) 0xd4
0x6ffffef5 (GNU_HASH) 0x460
0x00000005 (STRTAB) 0xf18
0x00000006 (SYMTAB) 0x718
0x0000000a (STRSZ) 1981 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000003 (PLTGOT) 0x15eec
0x00000002 (PLTRELSZ) 488 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x1b64
0x00000011 (REL) 0x1b1c
0x00000012 (RELSZ) 72 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x6ffffffc (VERDEF) 0x17d8
0x6ffffffd (VERDEFNUM) 23
0x00000018 (BIND_NOW)
0x6ffffffb (FLAGS_1) Flags: NOW
0x6ffffffe (VERNEED) 0x1afc
0x6fffffff (VERNEEDNUM) 1
0x6ffffff0 (VERSYM) 0x16d6
0x6ffffffa (RELCOUNT) 4
0x00000000 (NULL) 0x0
$ readelf -d ./build_dir/target-arm_cortex-a8+vfpv3_musl_eabi/libosmocore-1.3.1/src/.libs/libosmocore.so
Dynamic section at offset 0x1e938 contains 30 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libtalloc.so.2]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so]
0x0000000e (SONAME) Library soname: [libosmocore.so.12]
0x0000000c (INIT) 0x844c
0x0000000d (FINI) 0x1b7f8
0x00000019 (INIT_ARRAY) 0x2e598
0x0000001b (INIT_ARRAYSZ) 12 (bytes)
0x0000001a (FINI_ARRAY) 0x2e5a4
0x0000001c (FINI_ARRAYSZ) 4 (bytes)
0x00000004 (HASH) 0xf4
0x6ffffef5 (GNU_HASH) 0x126c
0x00000005 (STRTAB) 0x44f8
0x00000006 (SYMTAB) 0x1fc8
0x0000000a (STRSZ) 10876 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000003 (PLTGOT) 0x2ea48
0x00000002 (PLTRELSZ) 2544 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x7a5c
0x00000011 (REL) 0x745c
0x00000012 (RELSZ) 1536 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x00000018 (BIND_NOW)
0x6ffffffb (FLAGS_1) Flags: NOW
0x6ffffffe (VERNEED) 0x741c
0x6fffffff (VERNEEDNUM) 2
0x6ffffff0 (VERSYM) 0x6f74
0x6ffffffa (RELCOUNT) 153
0x00000000 (NULL) 0x0
$ readelf -d ./build_dir/target-arm_cortex-a8+vfpv3_musl_eabi/osmo-remsim-client-0.2.99/src/client/.libs/osmo-remsim-client-st2
Dynamic section at offset 0x5d30 contains 36 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libosmogsm.so.13]
0x00000001 (NEEDED) Shared library: [libosmoabis.so.6]
0x00000001 (NEEDED) Shared library: [libosmousb.so.0]
0x00000001 (NEEDED) Shared library: [libosmo-simtrace2.so.0]
0x00000001 (NEEDED) Shared library: [libusb-1.0.so.0]
0x00000001 (NEEDED) Shared library: [libosmo-rspro.so.1]
0x00000001 (NEEDED) Shared library: [libtalloc.so.2]
0x00000001 (NEEDED) Shared library: [libosmocore.so.12]
0x00000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x00000001 (NEEDED) Shared library: [libc.so]
0x0000000c (INIT) 0x11b0c
0x0000000d (FINI) 0x14ba8
0x00000019 (INIT_ARRAY) 0x25d1c
0x0000001b (INIT_ARRAYSZ) 12 (bytes)
0x0000001a (FINI_ARRAY) 0x25d28
0x0000001c (FINI_ARRAYSZ) 4 (bytes)
0x00000004 (HASH) 0x1014c
0x6ffffef5 (GNU_HASH) 0x10478
0x00000005 (STRTAB) 0x10ea0
0x00000006 (SYMTAB) 0x10820
0x0000000a (STRSZ) 2105 (bytes)
0x0000000b (SYMENT) 16 (bytes)
0x00000015 (DEBUG) 0x0
0x00000003 (PLTGOT) 0x25e78
0x00000002 (PLTRELSZ) 760 (bytes)
0x00000014 (PLTREL) REL
0x00000017 (JMPREL) 0x11814
0x00000011 (REL) 0x117ec
0x00000012 (RELSZ) 40 (bytes)
0x00000013 (RELENT) 8 (bytes)
0x00000018 (BIND_NOW)
0x6ffffffb (FLAGS_1) Flags: NOW
0x6ffffffe (VERNEED) 0x117ac
0x6fffffff (VERNEEDNUM) 2
0x6ffffff0 (VERSYM) 0x116da
0x00000000 (NULL) 0x0
> The scope of ctor priorities is within a single DSO. Priorities are
> used by the linker to order them within the ctor array of the library. [...]
Thanks for sharing your knowledge on the topic. So I stand corrected regarding
claiming the priority is a bug. However, the ordering constraints of the ELF
specification don't seem to be reflected.
I can share the binaries if you'd like (armv7l) or provide you with any other
diagnostic output.
Regards,
Harald
--
- Harald Welte <laforge@...monks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
