Optional fall back to LLVM symbolizer markup

[mysterymath]

Now that Symbolizer Markup has landed in LLVM 15.0.2, it would be possible to add an option to emit this markup whenever symbol information is unavailable (fully-stripped binaries, etc.).

Producing symbolizer markup would allow llvm-symbolizer to produce human-readable backtraces from it after the fact, looking up the necessary artifacts using debuginfod. This complements https://github.com/ianlancetaylor/libbacktrace/issues/79; since it would be nice to have debuginfod lookups handled transparently, but that's not always possible (e.g., for embedded or sandboxed environments).

This should be relatively straightforward to implement, since the format is just a simple textual representation of the memory layout of the process and the return addresses of the backtrace.

[ianlancetaylor]

This seems like something to be done by the code that uses libbacktrace, not by libbacktrace itself. libbacktrace just returns file and funcition names, it doesn't print them. Well, except for backtrace_print, but changing the format of backtrace_print seems likely to break existing programs.

[mysterymath]

Unfortunately, getting this to work requires the detailed memory layout of the process to be emitted as markup. I don't think it's likely that you'd get N utility authors to dliterate_phdr, and to spit out the right markup from the results.

I was hoping from a systems integrator perspective that there'd be an environment variable that could be used to turn this on for disparate utilities that depend on libbacktrace library. Then, you could run over backtrace logs produced by stripped binaries and symbolize them after the fact. That's how things work for Fuchsia today, and it's great, but there's nothing Fuchsia-specific about it, and it'd be nice to be able to bring this to the embedded Linux space as well.

[ianlancetaylor]

But, again, libbacktrace doesn't print anything. I don't understand how you think that libbacktrace should change.

[mysterymath]

Sorry, I had meant to imply (and should have stated) that I'd like to see a change to backtrace_print for this. Is the format output by that function part of the backwards-compatibility guarantees of the library? Is it being parsed such that utilities might break if such an environment variable were flipped on?

I've also been operating under the assumption that the most common mode of use for the library is to backtrace_print in a signal handler, which I've not verified.

[ianlancetaylor]

Those are good questions about backtrace_print. I kind of assume that very few people use it. Searching GitHub at https://github.com/search?q=backtrace_print&ref=simplesearch doesn't find very many uses, but I don't know how meaningful that is.

[ianlancetaylor]

libbacktrace relies on _Unwind_Backtrace, and it should already be possible to use _Unwind_Backtrace to get the information needed to print LLVM symbolizer markup format. I don't see a useful role for libbacktrace here. Please comment if you disagree.