[Linux] Force the inclusion of the backtracing code when static linking.

[al45tair]

When we're statically linking the standard library, we need to force the inclusion of the backtracing code in the runtime, otherwise we don't get on-crash backtraces.

Also, add a test to make sure that this works.

rdar://115774613

[al45tair]

@swift-ci Please test

[al45tair]

Explanation: When using --static-stdlib, the crash handler for the backtracing code doesn't get linked into the final binary because the backtracing code is entirely self-contained and it gets discarded by the linker. This fixes that issue by adding a reference to it to swiftrt.o, which causes the static linker to drag it in from the archive.
Risk: Low. Only affects Linux.
Original PR: #68669
Reviewed by: @mikeash
Resolves: rdar://115774613
Tests: This PR adds an explicit test to make sure that we get backtraces when a statically linked program crashes. It fails prior to the other changes in the PR, and succeeds after them.

[al45tair]

@swift-ci Please test

[0xTim]

Can we get this cherrypicked onto the next 5.9 monthly release?

Additionally is there a workaround for current applications?

[gwynne]

@al45tair This is not sufficient for backtracing to work in statically linked executables. There are two other major issues:

1. Either SWIFT_ROOT=/usr or SWIFT_BACKTRACE=swift_backtrace=/usr/libexec/swift/linux/swift-backtrace must be specified in the environment (in statically linked binaries, the dladdr() trick used to get a default root path won't find anything).
2. Typically, (part of) the point of a statically linked executable is to use it without needing the Swift runtime libs in the final host filesystem (such as a runner Docker image). Unfortunately, the required swift-backtrace binary is not itself statically linked, which means either having a Swift toolchain installed or copying the runtime libraries to the runner environment.

In short, it doesn't work (very well) with statically linked binaries anyway 😕.

As an aside, as a workaround for the linkage problem in 5.9.0 that this PR addresses, it is sufficient to add -Xlinker -u -Xlinker _swift_backtrace_isThunkFunction to the build command (or otherwise specify the linker flag).

[al45tair]

@al45tair This is not sufficient for backtracing to work in statically linked executables. There are two other major issues:

1. Either SWIFT_ROOT=/usr or SWIFT_BACKTRACE=swift_backtrace=/usr/libexec/swift/linux/swift-backtrace must be specified in the environment (in statically linked binaries, the dladdr() trick used to get a default root path won't find anything).

I'm aware of that (and, actually, on Glibc at least, I think you can also put a copy of swift-backtrace into the same path as your executable, since the search logic in Paths.cpp should find it relative to the executable path in that case; I haven't checked that yet, but the environment variables do work). I'm hoping to document all of this at some point in a public blog post.

I have a better solution in mind in the longer term.

2. Typically, (part of) the point of a statically linked executable is to use it without needing the Swift runtime libs in the final host filesystem (such as a runner Docker image). Unfortunately, the required swift-backtrace binary is not itself statically linked, which means either having a Swift toolchain installed or copying the runtime libraries to the runner environment.

I'm aware of the various reasons people might want a statically linked executable. I'm also working on a statically linked swift-backtrace (which will be in a separate PR) that users who want to do this could distribute.

Can we get this cherrypicked onto the next 5.9 monthly release?

There is already a 5.9 cherrypick.

Additionally is there a workaround for current applications?

As Gwynne says, you could do this:

As an aside, as a workaround for the linkage problem in 5.9.0 that this PR addresses, it is sufficient to add -Xlinker -u -Xlinker _swift_backtrace_isThunkFunction to the build command (or otherwise specify the linker flag).

[al45tair]

@swift-ci Please test