mold built with makepkg always fails assertion about mold

[rui314]

Thank you very much @nehaljwani for finding the flag to reproduce the issue. I submitted fc4aafa so that at least on my machine, mold is now clean with these extra assertions

[Logarithmus]

On July 3, 2021 3:58:36 AM GMT+03:00, Wesley Moore ***@***.***> wrote: I'm trying to create an [AUR](https://aur.archlinux.org/) package for `mold`. You can see what I've come up with here: https://github.com/wezm/aur/tree/master/mold I'm using a modified `Makefile` which includes some of the changes @Logarithmus made for their Void package. With this `Makefile` and my `PKGBUILD` `mold` builds fine but the resulting binary always fails an assertion. If I build `mold` without using [makepkg](https://man.archlinux.org/man/makepkg.8), just using the `Makefile` supplied in the tarball the resulting binary works fine. The same issue happens if I don't link against the system `mimalloc` and let `mold` build its vendored copy. As this is a packaging issue I'll understand if you don't have time to took into this issue. Nonetheless I figured the error might mean more to you. If I try to build this small C program: ```c #include <stdio.h> #include <stdlib.h> int main(int argc, char **argv) { printf("Linked with mold\n"); return EXIT_SUCCESS; } ``` as follows: `mold -run clang -o mold-test test.c` I get this error: ``` /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/span:276: std::span::reference std::span<ElfSym<X86_64>, 18446744073709551615>::operator[](std::span::size_type) const [_Type = ElfSym<X86_64>, _Extent = 18446744073709551615]: Assertion '__idx < size()' failed. clang-12: error: unable to execute command: Aborted (core dumped) clang-12: error: linker command failed due to signal (use -v to see invocation) ``` The compiler used to build `mold` (and the test binary above) is: ``` clang version 12.0.0 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin ``` My system is an AMD Ryzen 9 3900X running Arch Linux. If you have any ideas I'd love to hear them.

I'm not sure, but to me it looks like mold isn't being linked properly. You probably just have an empty ELF. Please run strip for mold executable and tell what's the resulting size? If it's very small, then likely I'm right. I've encountered a similar problem some time ago when I was tinkering with cross compiling Rust code and invoked ld.lld directly. It turns out one should invoke a linker through compiler driver (cc or clang), and then pass which linker to use as a compiler driver option. Driver in this context means "a program which calls and manages other smaller programs (e. g. linker, )", not a hardware driver. Explaining this because I remember being confused about this usage of term "driver" at first.

[wezm]

I'm not sure, but to me it looks like mold isn't being linked properly. You probably just have an empty ELF. Please run strip for mold executable and tell what's the resulting size? If it's very small, then likely I'm right.

makepkg automatically strips binaries as part of the build process:

==> Entering fakeroot environment...
==> Starting package()...
install -Dm 755 mold /home/wmoore/Projects/aur.me/mold/pkg/mold/usr/bin/mold
install -m 755 -d /home/wmoore/Projects/aur.me/mold/pkg/mold/usr/lib/mold
install -m 644 mold-wrapper.so /home/wmoore/Projects/aur.me/mold/pkg/mold/usr/lib/mold
install -Dm 644 docs/mold.1 /home/wmoore/Projects/aur.me/mold/pkg/mold/usr/share/man/man1/mold.1
==> Tidying install...
  -> Removing libtool files...
  -> Purging unwanted files...
  -> Removing static library files...
  -> Stripping unneeded symbols from binaries and libraries...
  -> Compressing man and info pages...
==> Checking for packaging issues...
==> Creating package "mold"...
  -> Generating .PKGINFO file...
  -> Generating .BUILDINFO file...
  -> Generating .MTREE file...
  -> Compressing package...
==> Leaving fakeroot environment.
==> Finished making: mold 0.9.1-1 (Sat 03 Jul 2021 10:30:17)

Confirming binary is non-empty and stripping does not alter the binary (as it's already stripped):

$ strip /usr/bin/mold -o /tmp/mold-stripped
$ ls -l /usr/bin/mold /tmp/mold-stripped
.rwxr-xr-x 1.8M root    3 Jul 10:30 /usr/bin/mold
.rwxr-xr-x 1.8M wmoore  3 Jul 11:28 /tmp/mold-stripped
$ sha256sum /usr/bin/mold /tmp/mold-stripped
a57f51bfe05952d0f8953b1714b3cdf47a650944ea372ce395d3a83b1a25fccc  /usr/bin/mold
a57f51bfe05952d0f8953b1714b3cdf47a650944ea372ce395d3a83b1a25fccc  /tmp/mold-stripped

ldd output in case it's useful:

$ ldd /usr/bin/mold
	linux-vdso.so.1 (0x00007ffe75ff1000)
	libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x00007fd8adb7d000)
	libtbb.so.2 => /usr/lib/libtbb.so.2 (0x00007fd8adb37000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007fd8adb1d000)
	libmimalloc.so.2.0 => /usr/lib/libmimalloc.so.2.0 (0x00007fd8ada99000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fd8ad883000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fd8ad868000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fd8ad845000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007fd8ad679000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fd8ae048000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fd8ad672000)
	librt.so.1 => /usr/lib/librt.so.1 (0x00007fd8ad667000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007fd8ad523000)

[rui314]

Let me run makepkg in a Docker environment to see if I can reproduce the issue locally. I don't know what that command is exactly doing, but I guess I'd have to investigate the issue by bisecting -- find out differences of plain make and makepkg and identify which step causes a break.

[rui314]

It looks like it's working for me. Here is the config files I made to build mold with makepkg. https://github.com/rui314/aur/tree/master/mold

[nehaljwani]

One can replicate this problem with: make EXTRA_CPPFLAGS="-Wp,-D_GLIBCXX_ASSERTIONS"

Many modern distributions like Fedora and Arch use this as one of the default flags while building packages.

I found two places where problems were caught. Fix for one is available at #78

The second one is:

/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/span:276: std::span::reference std::span<ElfSym<X86_64>, 18446744073709551615>::operator[](std::span::size_type) const [_Type = ElfSym<X86_64>, _Extent = 18446744073709551615]: Assertion '__idx < size()' failed.

Thread 2.1 "mold" received signal SIGABRT, Aborted.
[Switching to LWP 3204173]
0x00007ffff78aa2a2 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff78aa2a2 in raise () from /lib64/libc.so.6
#1  0x00007ffff78938a4 in abort () from /lib64/libc.so.6
#2  0x000000000041b13d in std::__replacement_assert (__file=<optimized out>, __line=<optimized out>, __line@entry=276, __function=<optimized out>, __condition=<optimized out>)
    at /usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/x86_64-redhat-linux/bits/c++config.h:2654
#3  0x000000000044e94e in std::span<ElfSym<X86_64>, 18446744073709551615ul>::operator[] (this=<optimized out>, __idx=0) at /usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/span:276
#4  Symbol<X86_64>::esym (this=this@entry=0x53cf84f0140) at ./mold.h:1960
#5  0x000000000044dd7c in get_rank<X86_64> (sym=...) at object_file.cc:778

For some reason, at:

mold/mold.h

Lines 1957 to 1961 in 426a689

	const ElfSym<E> &esym() const {
	if (file->is_dso)
	return *((SharedFile<E> *)file)->elf_syms[sym_idx];
	return ((ObjectFile<E> *)file)->elf_syms[sym_idx];
	}

sym_idx is uninitialized for elf-init.oS which comes from libc_nonshared.a

[wezm]

Fantastic detective work @nehaljwani and thanks for fixing one of the issues.

[rui314]

Feel free to reopen if it still persists.