On Thu, Aug 09, 2018 at 04:28:13PM -0400, Theodore Y. Ts'o wrote:
> On Thu, Aug 09, 2018 at 12:18:32PM -0700, Darrick J. Wong wrote:
> >
> > Now there's a side effect I didn't notice before -- LTO means we switch
> > to static libraries, presumably if the linker can find static libs with
> > LTO bytecode inside.
>
> Hmm, I'm not seeing this with my compiler toolchain (binaries built
> using dpkg-buildpackage -us -uc -b on a recently updated Debian
> unstable system):
>
> <tytso@cwcc> {/tmp/debian/e2fsprogs/debian/e2fsprogs/sbin} (next)
> 1391% ldd debugfs
> linux-vdso.so.1 (0x00007ffc816f7000)
> libext2fs.so.2 => /lib/x86_64-linux-gnu/libext2fs.so.2 (0x00007f395fdcb000)
> libe2p.so.2 => /lib/x86_64-linux-gnu/libe2p.so.2 (0x00007f395fdc1000)
> libss.so.2 => /lib/x86_64-linux-gnu/libss.so.2 (0x00007f395fdb7000)
> libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f395fdb1000)
> libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f395fb62000)
> libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f395f95b000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f395f954000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f395f797000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f395f776000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f395fe7c000)
> <tytso@cwcc> {/tmp/debian/e2fsprogs/debian/e2fsprogs/sbin} (next)
> 1392% ldd e2fsck
> linux-vdso.so.1 (0x00007fffae2e7000)
> libext2fs.so.2 => /lib/x86_64-linux-gnu/libext2fs.so.2 (0x00007f35f07cf000)
> libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f35f07c9000)
> libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f35f057a000)
> libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f35f0373000)
> libe2p.so.2 => /lib/x86_64-linux-gnu/libe2p.so.2 (0x00007f35f0369000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f35f0364000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f35f01a5000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f35f0184000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f35f089c000)
> <tytso@cwcc> {/tmp/debian/e2fsprogs/debian/e2fsprogs/sbin} (next)
> 1393% grep -- -lto ../../rules
> COMMON_CONF_FLAGS = --enable-lto --disable-ubsan --disable-addrsan \
>
> And given the bloated size of libext2fs.a, I know that we actually
> were building with LTO:
>
> <tytso@cwcc> {/tmp/debian/e2fsprogs/debian/e2fsprogs/sbin} (next)
> 1394% ls ../../libext2fs-dev/usr/lib/x86_64-linux-gnu/libext2fs.a
> 3696 ../../libext2fs-dev/usr/lib/x86_64-linux-gnu/libext2fs.a
>
> And just in case the problem was shared object files with -fpic
> weren't built with LTO, I can confirm they were:
>
> <tytso@cwcc> {/tmp/debian/e2fsprogs/debian/e2fsprogs/sbin} (next)
> 1395% cd ../../BUILD-STD/lib/ext2fs/
> <tytso@cwcc> {/tmp/debian/e2fsprogs/debian/BUILD-STD/lib/ext2fs} (next)
> 1396% objdump -x elfshared/alloc.o | grep lto | head -10
> 3 .gnu.lto_.profile.dc6c1beb1dcdd1cc 00000014 0000000000000000 0000000000000000 00000e1a 2**0
> 4 .gnu.lto_.icf.dc6c1beb1dcdd1cc 00000082 0000000000000000 0000000000000000 00000e2e 2**0
> 5 .gnu.lto_.jmpfuncs.dc6c1beb1dcdd1cc 0000033c 0000000000000000 0000000000000000 00000eb0 2**0
> 6 .gnu.lto_.inline.dc6c1beb1dcdd1cc 000004c1 0000000000000000 0000000000000000 000011ec 2**0
> 7 .gnu.lto_.pureconst.dc6c1beb1dcdd1cc 00000035 0000000000000000 0000000000000000 000016ad 2**0
> 8 .gnu.lto_check_inode_uninit.dc6c1beb1dcdd1cc 000006e8 0000000000000000 0000000000000000 000016e2 2**0
> 9 .gnu.lto_ext2fs_clear_block_uninit.part.7.dc6c1beb1dcdd1cc 000002bf 0000000000000000 0000000000000000 00001dca 2**0
> 10 .gnu.lto_ext2fs_get_free_blocks2.part.8.dc6c1beb1dcdd1cc 00000703 0000000000000000 0000000000000000 00002089 2**0
> 11 .gnu.lto_ext2fs_alloc_range.part.9.dc6c1beb1dcdd1cc 000003ca 0000000000000000 0000000000000000 0000278c 2**0
> 12 .gnu.lto_ext2fs_clear_block_uninit.dc6c1beb1dcdd1cc 000003c6 0000000000000000 0000000000000000 00002b56 2**0
>
> And just double checking to be sure:
>
> <tytso@cwcc> {/tmp/debian/e2fsprogs/debian/BUILD-STD/e2fsck} (next)
> 1399% objdump -x e2fsck | grep lto | head -10
> 000000000000f6d3 l F .text 00000000000002c9 new_table_block.lto_priv.31
> 000000000000f610 l F .text 00000000000000c3 finish_processing_inode.part.27.lto_priv.28
> 0000000000016730 l F .text 00000000000000c7 mark_inode_bad.lto_priv.30
> 00000000000503a0 l O .bss 0000000000000038 ext2_max_sizes.lto_priv.15
> 00000000000503d8 l O .bss 0000000000000008 inodes_to_process.lto_priv.16
> 0000000000034900 l F .text 0000000000000197 e2fsck_handle_read_error.lto_priv.22
> 0000000000050740 l O .bss 0000000000000008 operation.lto_priv.8
> 0000000000012e60 l F .text 000000000000006a pass1_read_inode.lto_priv.19
> 000000000002bcc0 l F .text 00000000000001fb check_large_ea_inode.lto_priv.13
> 000000000000f99c l F .text 000000000000014a adjust_extattr_refcount.lto_priv.27
> <tytso@cwcc> {/tmp/debian/e2fsprogs/debian/BUILD-STD/e2fsck} (next)
> 1400% ldd e2fsck
> linux-vdso.so.1 (0x00007fff889a6000)
> libext2fs.so.2 => /lib/x86_64-linux-gnu/libext2fs.so.2 (0x00007f2512abe000)
> libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f2512ab8000)
> libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007f2512869000)
> libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f2512662000)
> libe2p.so.2 => /lib/x86_64-linux-gnu/libe2p.so.2 (0x00007f2512658000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2512653000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2512494000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2512473000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f2512b8b000)
>
> > That's an interesting implication -- libraries which are shared widely
> > among the "usual" set of running programs on a computer should not be
> > LTO'd because we're better off (in terms of memory consumption) to share
> > the library code; but libraries which are not widely shared should be
> > LTO if the reduction in code size outweighs the loss of amortization
> > possibilities. I guess?
>
> I think the bigger take home is that LTO is very much an emerging
> technology, and may be true for one version of the toolchain may not
> be true for another.
>
> So I'm wondering if we should default LTO to be off, rather than
> --enable-lto=probe for now. Mainly because I'm a bit more nervous how
> mature the LTO support is for all distributions.
Probably a reasonable default, at least for a year or two. :)
--D
>
> - Ted
>
>
>
> >
> > --D
> >
> > >
> > > - Ted
