ianlancetaylor / libbacktrace

A C library that may be linked into a C/C++ program to produce symbolic backtraces
Other
944 stars 220 forks source link

Packaging libbacktrace #85

Closed wookey closed 2 years ago

wookey commented 2 years ago

I tried email to Ian Lance Taylor iant@golang.org but got no response, so trying here instead.

I looked at packaging your libbacktrace (from
https://github.com/ianlancetaylor/libbacktrace) because a trivial fork
of it (https://github.com/tlc-pack/libbacktrace) is used by Apache
TVM, which I am packaging for Debian/Ubuntu.

Firstly, I see that it only builds a static library. Is that a
technical limitation to do with the backtracing or the way it is
intended to be used, (or something to do with there being no
ABI-stability guarantees like libiberty) or just a 'no-one asked for a
dynamic version yet' thing?

Obviously in distro-world we'd normally build a dynamic version (and a
static version) and use them as required. So I'm just wondering if
there is a reason why I shouldn't do that?

Re the fork. The only change is this:(and 3 lines of whitespace)
https://github.com/tlc-pack/libbacktrace/commit/08f7c7e69f8ea61a0c4151359bc8023be8e9217b
which I think is irrelevant on linux as we are not normally looking at macho-0 binaries).

If it's useful then maybe that one-line change could go upstream and
there might be one fewer pointless fork in the world :-)
If I'm understanding right it may be related to : https://github.com/ianlancetaylor/libbacktrace/issues/78

Cheers for any pointers you can give,

Wookey

ianlancetaylor commented 2 years ago

The libbacktrace library explicitly supports being invoked from a signal handler, but that most likely won't work if it is linked in as a dynamic library. So in normal use, without additional information, it should be linked statically.

ianlancetaylor commented 2 years ago

I committed the one line patch that you mentioned.

ianlancetaylor commented 2 years ago

Nothing else to do here. Thanks.

carlosgalvezp commented 1 year ago

The libbacktrace library explicitly supports being invoked from a signal handler, but that most likely won't work if it is linked in as a dynamic library

Hi @ianlancetaylor ! I'm interested in building the dynamic library version and using it in a signal handler (via Boost.Stacktrace). Could you elaborate on why static linking is the only option in this case?

ianlancetaylor commented 1 year ago

My concern is that lazy PLT calls may not work reliably if invoked via a signal handler. I don't know whether this concern is completely valid. It can be obviated by using -Wl,-z,now when linking.