Closed kzdixon closed 2 years ago
Thank you for your report. If it fails with an illegal instruction error, it is very likely that mold corrupted the binary. However, unfortunately, I couldn't reproduce the issue by checking out dolphin-emu from https://github.com/dolphin-emu/dolphin and built on my machine. If you check it out from the git repository and build it yourself, does it still fail?
Here is what I did:
git clone git@github.com:dolphin-emu/dolphin.git
cd dolphin
git submodule update --init
mkdir build
cd build
cmake -GNinja ..
mold -run ninja
./Binaries/dolphin-emu --version
Building with your instructions seems to work fine.
Adding in all of my flags as env vars for another build on the repo seems to give me the Illegal instruction (core dumped)
so one of those isn't playing nicely when mold is in use. Will try to narrow it down.
I exported all your variables as below, but it still succeeded.
export CARCH="x86_64"
export CHOST="x86_64-pc-linux-gnu"
#-- Compiler and Linker Flags
export CPPFLAGS="$CFLAGS"
export CFLAGS="-march=native -B/usr/lib/mold -Ofast -pipe -fno-plt \
-fstack-protector-strong --param=ssp-buffer-size=4 -fopenmp -pthread -Wno-error -w"
export CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS"
export LDFLAGS="-Wl,-O4,--sort-common,--as-needed,-z,relro,-z,now,-lpthread"
export RUSTFLAGS="-C opt-level=2 -C target-cpu=native -C link-arg=-fuse-ld=/usr/lib/mold"
#-- Make Flags: change this for DistCC/SMP systems
export MAKEFLAGS="-j$(nproc) --quiet"
#-- Debugging flags
export DEBUG_CFLAGS="-g -fvar-tracking-assignments"
export DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"
#DEBUG_RUSTFLAGS="-C debuginfo=2"
export DEBUG_MAKEFLAGS="-j1 --debug=bvij"
export CC_LD=mold
export CXX_LD=mold
export CMAKE_C_COMPILER="command gcc $CFLAGS"
export CMAKE_CXX_COMPILER="command g++ $CXXFLAGS"
export CMAKE_LINKER="command ld $LDFLAGS"
cmake -GNinja ..
ninja
./Binaries/dolphin-emu --version
What am I missing?
Honestly not sure... Using the default arch makepkg flags also results in the same issue when mold
is used to wrap around ninja
apparently.
For Reference these are the defaults for makepkg.conf
:
#########################################################################
# ARCHITECTURE, COMPILE FLAGS
#########################################################################
#
CARCH="x86_64"
CHOST="x86_64-pc-linux-gnu"
#-- Compiler and Linker Flags
#CPPFLAGS=""
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
-Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security \
-fstack-clash-protection -fcf-protection"
CXXFLAGS="$CFLAGS -Wp,-D_GLIBCXX_ASSERTIONS"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"
#RUSTFLAGS="-C opt-level=2"
#-- Make Flags: change this for DistCC/SMP systems
MAKEFLAGS="-j8"
#-- Debugging flags
DEBUG_CFLAGS="-g -fvar-tracking-assignments"
DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"
#DEBUG_RUSTFLAGS="-C debuginfo=2"
Could be CPU-family specific unless you're also on Ryzen.
Appears to be isolated to CFLAGS
/CXXFLAGS
of course. The below flags are what I trimmed down to from the default arch CFLAGS
/CXXFLAGS
to get it to successfully build with mold
.
$ echo $CFLAGS
-fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection
$ echo $CXXFLAGS
-fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS
Which means that getting rid of -fno-plt
was the culprit for my system apparently. Rerunning with all the arch makepkg.conf
defaults sans -fno-plt
also works just fine.
$ gcc --help=optimizers | grep fno-plt
-fplt Use PLT for PIC calls (-fno-plt: load the address from GOT at call site).
Rerunning the AUR installation of dolphin-emu-git
with -fno-plt
removed from my actual makepkg.conf
also seems to work just fine; Thus it appears there is a weird interaction on Ryzen (assuming our CPUs are not the same) when mold
is used alongside -fno-plt
for dolphin-emu
!
Haven't seen other builds with similar behavior quite yet but I only just recently swapped over to mold
and these FLAGS.
And just to sanity check, here's the readelf
output:
$ readelf -p .comment /usr/bin/dolphin-emu
String dump of section '.comment':
[ 0] GCC: (GNU) 11.2.0
[ 12] mold 1.1 (89612b709638b90c8a044e2f96f47d28054ba789; compatible with GNU ld)
Thanks! I added -no-plt
and indeed it causes a segmentation fault. It looks like we are handling R_X86_64_GOTPCRELX
in an incorrect way. Let me prepare a fix.
To verify the fix, please rebuild mold after git pull
and try to build dolphin-emu again.
$ paru -Ss mold-git
aur/mold-git v1.0.1_11_g4ccbd24c-1 [+4 ~0.37] [Installed: v1.1_14_g9f348308-1]
A Modern Linker
Clean install of dolphin-emu-git
:
$ dolphin-emu --version
Dolphin 5.0-16081
$ readelf -p .comment /usr/bin/dolphin-emu
String dump of section '.comment':
[ 0] GCC: (GNU) 11.2.0
[ 12] mold 1.1 (9f3483088206dd6f939d7b2c090570cf1f83d728; compatible with GNU ld)
All is well!
As stated in the title, building dolphin-emu appears to spit out a corrupted binary when using
mold
.(Clean/purged build from
dolphin-emu-git
AUR package.)Does not work. Instant core dump.
Removed
-B/usr/lib/mold
fromCFLAGS
(Clean/purged build from
dolphin-emu-git
AUR package.)Works and runs successfully.
Disabling LTO via
-fno-lto
doesn't seem to help either as the result is the same.