On Monday, 27 September 2021 at 06:59:32 UTC, Vladimir Panteleev wrote:

The llvm-lto2 tool provides LTO as an isolated step without linking. If you have it as a cross-compiler.

On Monday, 27 September 2021 at 02:27:32 UTC, kinke wrote:

Rented an AWS EC2 ARM box today and tried it out there. The std.process segfaults indeed appear to be specific to the QEMU/binfmt interaction, however, exceptions still did not work. I narrowed it down to -static, confirming your guess. Seems to be an issue with unwinding?

  * frame #0: 0x0000000000518180 btdu-static-aarch64`gsignal + 224
    frame #1: 0x0000000000400434 btdu-static-aarch64`abort + 244
    frame #2: 0x000000000050e1f4 btdu-static-aarch64`uw_init_context_1 + 580
    frame #3: 0x000000000050eb44 btdu-static-aarch64`_Unwind_Backtrace + 84
    frame #4: 0x000000000054d214 btdu-static-aarch64`backtrace + 68
    frame #5: 0x00000000004fb524 btdu-static-aarch64`_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo + 116
    frame #6: 0x00000000004fcf08 btdu-static-aarch64`_d_createTrace + 76
    frame #7: 0x00000000004e1a6c btdu-static-aarch64`_d_throw_exception + 176
    frame #8: 0x00000000004399cc btdu-static-aarch64`_D3std9exception__T7bailOutHTC9ExceptionZQwFNaNfAyamMAxaZNn(file=(length = 39, ptr = u8"/home/ubuntu/btdu/source/btdu/subproc.d"), line=109, msg=(length = 33, ptr = u8"Unexpected subprocess termination")) at exception.d:517:9

To reproduce:

$ echo 'import std.stdio, std.process; void main() { writeln(spawnProcess(["/bin/true"]).wait()); }' > test.d
$ ldc2-1.27.1-linux-aarch64/bin/ldc2 -static test.d
$ ./test
Aborted (core dumped)

Worth upgrading this to an issue?

Also, any ideas for workarounds? (Non-static builds lose most benefits of distributing pre-built binaries in the first place.)

Thanks!

On Friday, 1 October 2021 at 11:18:52 UTC, Vladimir Panteleev wrote:

Sorry, wrong code, should be:

$ echo 'import std.stdio; void main() { try throw new Exception("Caught"); catch (Exception e) writeln(e); }' > test.d

On Friday, 1 October 2021 at 11:18:52 UTC, Vladimir Panteleev wrote:

  * frame #0: 0x0000000000518180 btdu-static-aarch64`gsignal + 224
    frame #1: 0x0000000000400434 btdu-static-aarch64`abort + 244
    frame #2: 0x000000000050e1f4 btdu-static-aarch64`uw_init_context_1 + 580
    frame #3: 0x000000000050eb44 btdu-static-aarch64`_Unwind_Backtrace + 84
    frame #4: 0x000000000054d214 btdu-static-aarch64`backtrace + 68
    frame #5: 0x00000000004fb524 btdu-static-aarch64`_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo + 116
    frame #6: 0x00000000004fcf08 btdu-static-aarch64`_d_createTrace + 76
    frame #7: 0x00000000004e1a6c btdu-static-aarch64`_d_throw_exception + 176
    frame #8: 0x00000000004399cc btdu-static-aarch64`_D3std9exception__T7bailOutHTC9ExceptionZQwFNaNfAyamMAxaZNn(file=(length = 39, ptr = u8"/home/ubuntu/btdu/source/btdu/subproc.d"), line=109, msg=(length = 33, ptr = u8"Unexpected subprocess termination")) at exception.d:517:9

Hmm, apparently coming from libbacktrace. IIRC, EH and backtrace code in druntime for Linux AArch64 doesn't really diverge from x64.

I guess you could try compiling druntime manually, defining version (DRuntime_Use_Libunwind) to use libunwind instead of libbacktrace. See https://wiki.dlang.org/Building_LDC_runtime_libraries for how to do that quite painlessly.

On Friday, 1 October 2021 at 11:41:06 UTC, kinke wrote:

Wow, that looks cool.

version=DRuntime_Use_Libunwind seems to have bitrotten a bit though I think:

core/internal/backtrace/handler.d(89): Error: undefined identifier `Dl_info`
core/internal/backtrace/handler.d(90): Error: undefined identifier `dladdr`

On Friday, 1 October 2021 at 11:46:37 UTC, Vladimir Panteleev wrote:

Argh, yeah, it's currently only enabled by default for musl, and that isn't CI-tested, going the usual way... ;) - Probably needs to be fixed in upstream druntime.

On Friday, 1 October 2021 at 11:49:20 UTC, kinke wrote:

I think there's more. I added the import and the runtime built, however, the application now fails to link because it can't find unw_getcontext etc. However, looking in /usr/include, I see:

#define unw_getcontext(uc)              unw_tdep_getcontext(uc)

This include file is in /usr/include/aarch64-linux-gnu, which I guess might mean that the libunwind ABI interface differs across architectures :(

On Friday, 1 October 2021 at 11:57:53 UTC, Vladimir Panteleev wrote:

#define unw_getcontext(uc)              unw_tdep_getcontext(uc)

Argh... and that might be yet another macro, and possibly even buggy if not from a pretty recent libunwind version: https://github.com/libunwind/libunwind/pull/221/files

[For 32-bit ARM, we have this to account for libunwind macro trouble: https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/arm_unwind.c]

On Friday, 1 October 2021 at 11:18:52 UTC, Vladimir Panteleev wrote:

I guess going down the rabbit hole all the way isn't really what you're looking for. ;) - I'd probably settle for dynamically linking against an old glibc, and only linking the other libs statically. Won't work on your phone, but I guess btrfs isn't really a thing on phones. :]