Support use libunwind for backtracking

[RinCat]

When execinfo.h not available.

Can be used in musl Liunx system as well as *BSD.

Signed-off-by: Rin Cat (鈴猫) dev@rincat.ch

[tytso]

This patch doesn't look complete; don't you need to link with libunwind?

I've tried playing with it, and the build explodes because the link for e2fsck is missing -lunwind.

[RinCat]

I think it depends on how user configured the toolchains. In my LLVM/clang toolchains it is supposed to be LDFLAGS=... -unwindlib=libunwind ... for all files. So there is no -lunwind.
I'm not sure how others configured it, given that this configuration is uncommon.

[tytso]

I was testing on Debian, and I found there that its libunwind package `installed the libunwind.h header file in a directory that is picked up by gcc and clang, but it doesn't automatically install the library; you have to explicitly request it using the linker option -lunwind, just like you have to use -lcurses, -lm, etc. The libunwind..h header is also in a place where musl-gcc does not pick it up.

So the concern that I have is that depending on the how the distro installs the compilers and the libunwind directory, this patch might end up causing the compile failure. And that's a problem, especially if there is some mysterious toolchain where it automatically links against the unwind liubrary --- that just seems weird! Why not do that with the curses library, or math library, or for that matter, all of the GNOME libraries automagically?!?

[RinCat]

For what I know, multiple different unwind libraries are interchangeable.
Like in the clang docs

-unwindlib=, --unwindlib=
Unwind library to use. must be ‘libgcc’, ‘unwindlib’ or ‘platform’.

So it probably doesn't want the program being compiled to decide for itself.

I did some quick searching, but I couldn't find any explanation of this design.

I'll try to find a solution.

[tytso]

This web page [1] documents that you should use -lunwind. The clang web page you mentioned seems to have a clang-specific command-line option, "-unwindlib=". But that's only going to work on clang! What if you are on FreeBSD, and decide to use pcc? What if you have purchased Intel's icc compiler?

[1] https://www.nongnu.org/libunwind/man/libunwind(3).html

I can see a couple of paths forward. One option is to not use the clang --unwindlib option as being non-portable, and see if you can successfully build using -lunwind, since that appears to be what is documented and what presumably will work for all linkers --- unless clang does something weird and installs libunwind in some non-standard place that isn't searched by the linker.

Another is an autoconf hack that only tries to use libunwind if you are using the clang compiler, and it automagically passes the clang-specific --unwindlib to the clang compiler. So then we're not asking the user to use LDFLAGS="", but instead, "configure --enable-clang-libunwind" and the right thing happens --- if and only if (a) libunwind.h is found, and (b) clang is in use, and we can successfully link libunwind using the clang --libunwind=yes option. If that doesn't work, then if the user explicitly specified --enable-clang-libunwind, the configure script will abort with an error. (Or silently ignore the --enable-clang-libunwind, although I'm less happy with that option.)

But in general, what I do not want to happen is that the configure script finds libunwind.h, and doesn't find execinfo.h, and decides automatically to use the libunwind functions, only to have the resul;ting build fail with a confusing error message.

[RinCat]

I do remember see some programs use something like --enable-libunwind. So I will try add something in autoconf.