It looks like this change is a likely root cause for a size regression on Fuchsia. In particular, Fuchsia maintains a hermetic -fno-exceptions multilib of libc++.a that is statically linked into other binaries/libraries. Previously, the no-exceptions version of this code didn't depend on the error code or category libraries, but this change seems to bring them into the link unnecessarily. Would it be possible to revert this or to fix it forward to keep the no-exception case separate from these routines?

There should also be tests for this behavior in llvm/test/CodeGen/X86. I wouldn't think it necessary to fully test the calling convention; that should already be well covered; just something in those key test files (e.g., sse-regcall.ll) to verify that the uefi OS actually switches the calling convention at these key points.

Remove semicolon

More review comments

Another round of comments

Remove canned binary

Address review feedback

8d3ff601a3 should fix the Darwin build issue and make the Linux unit tests sufficiently lenient. The %#x behavior was intentional; the spec is written with it in mind.

In D139750#4596368, @arphaman wrote:

This breaks the build on Darwin: https://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/37054/:

Undefined symbols for architecture x86_64:
  "printMarkupContext(llvm::raw_ostream&, char const*)", referenced from:
      printMarkupStackTrace(llvm::StringRef, void**, int, llvm::raw_ostream&) in libLLVMSupport.a(Signals.cpp.o)

@mysterymath could you take a look please?

clang-format

Address review comments.

In D155648#4513561, @dvyukov wrote:

Reading the other thread:

It dereferences some value that it picks out of the GOT, but that isn't mapped in the binary.

In D155317#4505039, @dvyukov wrote:

Unexpectedly Passed Tests (1):
UBSan-ThreadSanitizer-aarch64 :: TestCases/Misc/Linux/sigaction.cpp

Do we just disable it instead of XFAIL?

Could we include a similarly descriptive error message in llvm-debuginfod as in llvm-mt as part of this? As is, this will produce a binary with undefined behavior, as it will hit a llvm_unreachable when attempting to use HTTPServer. Seems like HTTPServer is the right place for this; it should probably report_fatal_error instead of llvm_unreachable, and mention the specific library dep.

I've spent a surprising amount of time staring at this libcall list (originally in the context of https://discourse.llvm.org/t/lto-deplibs-and-libcalls-oh-my/64510). It's struck me as a bit of a hack; targets are free to change the names of libcalls in TLI or to include additional target-specific ones, and neither would end up in this list. LTO also depends on the accuracy of this list for correctness, since the symbol table of the link must be finalized before LTO codegen begins.

Update test cases.

Fix test on Windows.

IIRC it's more typical to re-open D151273 and address the issue there, that way the diffs of the fixes are easier to review, and the context of the review is maintained.

Apply black formatting to resolve merge conflict.

Fixed commit message typo.

Restrict description to Shell tests.

In D151269#4366484, @JDevlieghere wrote:

The change itself looks fine, but isn't this an issue for the API tests too? If so, how is the sys root passed to dotest.py and can the shell tests do the same?

It looks like this change or its followup is causing test failures on the Fuchsia toolchain builders:

Hey, looks like this is causing test failures on the Fuchsia Windows builders:
https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-windows-x64/b8782647969396934929/overview

Rebase.

Rebase.

Rebase.

Rename MarkupContext to ProcessContext.

Rename "[markup] context" to "process context".

Make --filter-markup a doc reference.

Add to description comment to relate MarkupContext back to the Symbolizer library.

Defined markup contexts briefly in the flag help message and more thoroughly in
the rst documentation.

Comment changes.

Address comments.