Optionally print symbolizer markup backtraces.

[mysterymath]

Summary

When the environment LLVM_ENABLE_SYMBOLIZER_MARKUP is set, if
llvm-symbolizer fails or is disabled, this change will print a backtrace
in llvm-symbolizer markup instead of falling back to in-process
symbolization mechanisms.

This allows llvm-symbolizer to be run on the output later to produce a
high quality backtrace, even for fully-stripped LLVM utilities.

[mysterymath]

Add negative test.

[mcgrathr]

I thought we agreed that the desirable semantics to keep things simple is that if markup is requested then markup is always printed, period. It shouldn't have anything to do with whether llvm-symbolizer works.

[phosek]

In D139750#3985896, @mcgrathr wrote:

I thought we agreed that the desirable semantics to keep things simple is that if markup is requested then markup is always printed, period. It shouldn't have anything to do with whether llvm-symbolizer works.

I agree, I think it's fine if we keep markup as a fallback in the case when llvm-symbolizer fails or is disabled, but there should also be a way to force the use markup without trying anything else.

[mysterymath]

In D139750#3986437, @phosek wrote:

In D139750#3985896, @mcgrathr wrote:

I thought we agreed that the desirable semantics to keep things simple is that if markup is requested then markup is always printed, period. It shouldn't have anything to do with whether llvm-symbolizer works.

I agree, I think it's fine if we keep markup as a fallback in the case when llvm-symbolizer fails or is disabled, but there should also be a way to force the use markup without trying anything else.

The idea was to keep LLVM_DISABLE_SYMBOLIZATION and LLVM_ENABLE_SYMBOLIZER_MARKUP orthogonal; it seems prima facie that setting LLVM_ENABLE_SYMBOLIZER_MARKUP shouldn't also have the effect of setting LLVM_DISABLE_SYMBOLIZATION.

But the available options form a priority ordering; at most one method should be used, and some are superior to others. We could reasonable consider the markup workflow to have superior characteristics the others in the scenarios where it applies, so I think it's reasonable for enabling it to implicitly disable the others. Accordingly, I've moved the markup option to the top of the list.

[mysterymath]

Give markup priority over other symbolization options.

[mysterymath]

Add Windows version of printMarkupContext.

[mysterymath]

Apply git clang-format.

[phosek]

llvm/lib/Support/Unix/Signals.inc

538

Can you use reinterpret_cast instead of C-style cast?

561

Can you use C++-style instead of C-style cast here and below?

571

What does Amt refer to? Might be better to use something more self-descriptive.

[mysterymath]

Address review comments.

llvm/lib/Support/Unix/Signals.inc

538

This is just an array to pointer decay, so static_cast works. format just doesn't like being handed an array type.

561

Done, throughout.

571

Renamed these as the bytes remaining until the next item.

[jhenderson]

No idea where would the most appropriate place be for this, but should this be added to the docs somewhere?

[mysterymath]

Add blurb about LLVM_ENABLE_SYMBOLIZER_MARKUP to markup doc.

[mysterymath]

I'd like to ping this; having symbolizer markup would be boon for debugging crashes in CI environments where the toolchain is stripped. Fuchsia does this to minimize the install image for the toolchain, but it currently means that we must reproduce all crashes locally with a debug build to get a usable stack trace.