Android: Don't build LDC with NDK's implicit -fstack-protector-strong

[kinke]

Another test wrt. #4383, incl. new LLVM Android builds without -fstack-protector-strong.

[kinke]

@robertkirkman: It'd be awesome if you could test the Android aarch64 CI artifact here: https://github.com/ldc-developers/ldc/actions/runs/22321787659/artifacts/5623463625

[robertkirkman]

Thanks! I'll test it ASAP

[robertkirkman]

Ok, I've tested this one, it's giving a different result, so something did change. This one has Segmentation fault:

~/ldc2-22cc0437-android-aarch64/bin $ ls
ddemangle  dustmite          ldc-build-runtime  ldc-profgen      ldc2   rdmd    timetrace2txt
dub        ldc-build-plugin  ldc-profdata       ldc-prune-cache  ldmd2  reggae
~/ldc2-22cc0437-android-aarch64/bin $ ./ldc2
Segmentation fault         ./ldc2
~/ldc2-22cc0437-android-aarch64/bin $ ./ldc2 --version
Segmentation fault         ./ldc2 --version
~/ldc2-22cc0437-android-aarch64/bin $ ./ldc2 --help
Segmentation fault         ./ldc2 --help
~/ldc2-22cc0437-android-aarch64/bin $ gdb ./ldc2 
GNU gdb (GDB) 16.3
Copyright (C) 2024 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-linux-android".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./ldc2...
(gdb) run
...
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 

[kinke]

Damn, looks genuine indeed then. :( - Thx for testing!

[kinke]

I'll now try without alternate signal stack on Android: ldc-developers/llvm-project@e7130c4

[kinke]

Damn, that's not it either, no change.

[kinke]

Switching LLVM+LDC builds to latest NDK r29 doesn't change anything either.

Last try: compiling LLVM for API level 30 (not 29), like LDC.

[kinke]

That doesn't change anything either, giving up.

[kinke]

Not just yet; trying a no-op LLVM RegisterHandlers() on Android: ldc-developers/llvm-project@2846eba

FWIW, I've also glanced at a few files in https://github.com/termux/termux-packages/tree/master/packages/libllvm, and I couldn't spot any interesting patch or CMake build option for Termux' LLVM.

[kinke]

The dummy RegisterHandlers() leads to the same behavior as in #5070 (comment) - compiling with -o- works fine, but still hitting the stack corruption when emitting an object file, and with --version.

[kinke]

Oh well, the object file is generated successfully at least AFAICT, I don't think that was the case earlier. But it doesn't continue to the linking stage, the stack corruption seems to happen quickly after the object-file emission.

[kinke]

The crash for ldc2 --version might be the most interesting/simple one. This:

ldc/driver/main.cpp

Lines 138 to 156 in 2e33c9c

	OS << " Default target: " << llvm::sys::getDefaultTargetTriple() << "\n";
	std::string CPU(llvm::sys::getHostCPUName());
	if (CPU == "generic" || env::has("SOURCE_DATE_EPOCH")) {
	// Env variable SOURCE_DATE_EPOCH indicates that a reproducible build is
	// wanted. Don't print the actual host CPU in such an environment to aid
	// in man page generation etc.
	CPU = "(unknown)";
	}
	OS << " Host CPU: " << CPU << "\n";
	OS << " https://dlang.org - https://wiki.dlang.org/LDC\n";
	OS << "\n";
	// Without explicitly flushing here, only the target list is visible when
	// redirecting stdout to a file.
	OS.flush();
	llvm::TargetRegistry::printRegisteredTargetsForVersion(OS);
	exit(EXIT_SUCCESS);

only manages to print the default target triple; then the stack corruption gets reported with -fstack-protector-strong, or a segfault/sigbus happens without that switch.

[kinke]

I think I'm really out of ideas now. Still getting sigbus for ldc2 --version and when compiling a hello-world - but the emitted object file (emitted successfully before the crash) is absolutely fine; I can link it manually with Termux's cc (clang 21.1.8 targeting API level 30) using bundled druntime and Phobos, and that hello-world then runs fine too.

Edit: Oh, linking via LDC also works fine without LDC crashing. So ldc2 -c hello.d emits a working object file but then crashes, then a ldc2 hello.o for linking works fine, and ./hello runs fine.