lang/rust: drop /proc usage for RUST_BACKTRACE

[jbeich]

Summary

/proc may not be mounted and its usage is discouraged on BSDs. libstd bundles a C library from GCC into each executable. However, lang/gcc* don't expose sanitizers or Go runtime, so upstreaming is complicated. Let's just patch /proc out for downstream users.

This backs out D9838.

Test Plan

• poudriere bulk -t is green on 10.3 i386/amd64, 11.0 i386/amd64, 12.0 amd64

fn main() {
    panic!();
}

before:

$ rustc test.rs
$ RUST_BACKTRACE=1 ./test
thread 'main' panicked at 'explicit panic', test.rs:2
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: <unknown>
  10: <unknown>

after:

$ rustc test.rs
$ RUST_BACKTRACE=1 ./test
thread 'main' panicked at 'explicit panic', test.rs:2
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: test::main
   7: __rust_maybe_catch_panic
             at /usr/ports/lang/rust/work/rustc-1.18.0-src/src/libpanic_unwind/lib.rs:98
   8: std::rt::lang_start
   9: main
  10: _start
             at /usr/src/lib/csu/amd64/crt1.c:72

[asomers]

What's the output of RUST_BACKTRACE=1 ./a without your patch when /proc is unmounted?

[jbeich]

lang/rust/files/patch-src_libbacktrace_fileline.c

17 ↗

(On Diff #30707)

getexecname() usage in libbacktrace is probably bogus. According to Solaris manpage it isn't guaranteed to return absolute path unlike /proc/self/path/a.out.

[jbeich]

In D11574#239569, @asomers wrote:

What's the output of RUST_BACKTRACE=1 ./a without your patch when /proc is unmounted?

I've adjusted TEST PLAN. Without recompiling the test program it won't have an effect as rustc statically links libstd.

[asomers]

Do you plan to upstream this change to rust-lang.org? If not, then rustup users will still need /proc in order to see backtraces.

[jbeich]

In D11574#239583, @asomers wrote:

Do you plan to upstream this change to rust-lang.org?

Did you read the summary? Upstream is GCC, not Rust. The change maybe lost on a regular update (example).

If not, then rustup users will still need /proc in order to see backtraces.

Why would rustup users have lang/rust installed?

[jbeich]

@gerald, does anything block enabling sanitizers in lang/gcc*? I'd like to convert some parts of the patch here (e.g. sys/sysctl.h ifdef) to autoconf and test build as part of GCC.

[dumbbell]

Hi!

Just wanted to let you know I saw this patch. I'm working on further fixes and improvement to the Rust 1.19.0 update. Once this is committed, I'll try your patch.

[jbeich]

Works fine on ref11-aarch64 and ref12-aarch64 which don't have /proc mounted. I still don't have time to check DragonFly or NetBSD. ;\

[gerald]

In D11574#239599, @jbeich wrote:

@gerald, does anything block enabling sanitizers in lang/gcc*? I'd like to convert some parts of the patch here (e.g. sys/sysctl.h ifdef) to autoconf and test build as part of GCC.

I believe nobody has given it a try so far, but definitely worth one, Jan.

[bdrewery]

Submitted upstream (GCC) here: https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00068.html

[jbeich]

If GCC is not upstream let's try the standalone project:
https://github.com/ianlancetaylor/libbacktrace/pull/22

[jbeich]

libbacktrace is part of GCC and GNU projects require copyright assignment. FSF wants "citizenship, birth year, and postal address" for a disclaimer, so I gave up as my privacy is not free unlike code. Hopefully, after rP489090 anyone can claim they're the copyright holder.