fix typos

Fix below buildbot failure.

```
/var/lib/buildbot/fuchsia-x86_64-linux/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:172:42: error: use of undeclared identifier 'uint'
  172 |           Printf("Flag: %s %u\n", Name, (uint)Val);
```

Replace uint with uint32_t cast.

This reverts commit 8062b166762b51f1c3a9168e7031babde3e330a8.

This reverts commit b44e6e01f7f778bbb569e07821f5ddfdb90c4d4d.

This pull request addresses fixes against violations happening under
subcategory 'cpp/wrong-type-format-argument' related to
dfsan,fuzzer,hwasan.

The declaration was static when it shouldn't be since it can be defined
in FuzzerUtilFuchsia.cpp

…(#155042)

This reverts commit 781a4db6b50bb660cb293d3e7e29957aeb4b02ac.

Relanded with the fix declaring StartRssThread.

Reverts llvm/llvm-project#154854 because it broke Clang toolchain
builders for Fuchsia:

https://luci-milo.appspot.com/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8705803649235662417/overview

Every once in a couple hundred runs of a downstream fuzzer test, we see
a fuzzing test freeze while waiting for a thread to be suspended. The
main thread is frozen because it's waiting to suspend either the alarm
or rss thread which is stuck waiting for an exception they sent out to
be handled. Specifically, both threads send out a synthetic
`ZX_EXCP_THREAD_STARTING` exception to be handled by the crash handling
thread which sets up an exception channel on the whole process with
`ZX_EXCEPTION_CHANNEL_DEBUGGER`. This is the only channel type that
listens to thread stop/start exceptions. Normally, the exception would
be ignored and the alarm or rss thread would continue normally once the
crash handling thread closes the read exception. However, the memory
snapshot machinery can suspend this thread while its in the process of
waiting for or handling a `ZX_EXCP_THREAD_STARTING` sent by either the
rss or alarm thread. If this is suspended first, then we attempt to
suspend either the alarm or rss thread while they're still waiting for
the crash handling thread to handle its exception, we will freeze
waiting for those threads to give the suspend signal, which they won't
because they're blocked on waiting for the exception handler. This is
the deadlock.

Until there's a way for the memory snapshot machinery to suspend the
thread while it's stuck on an exception, then we can work around this in
the meantime by just ensuring the alarm and rss threads start normally
via signals on the initial startup path. I can assert locally the
freezing doesn't occur after 6000 runs where prior we would see it every
couple hundred runs. Note this type of issue can arise again if the
fuzzing test launches any dangling threads that happen to not start yet.
One of the recommendations for writing a fuzz test is that the test may
launch threads, but they should be joined by the end of the test
(https://llvm.org/docs/LibFuzzer.html#fuzz-target), so hopefully we
won't see this type of bug rise frequently from fuzz tests. More
broadly, this can also arise if any process launches its own debugger
via `ZX_EXCEPTION_CHANNEL_DEBUGGER`, but I would think in practice this
isn't very likely to happen.

More context in https://fxbug.dev/436923423.

---------

Co-authored-by: Petr Hosek <phosek@google.com>

Swift's FatalError raises a SIGTRAP, which currently causes the fuzzer
to exit without writing out the crashing input.

rdar://142975522

This is to fix modules build errors in chromium like
*
https://ci.chromium.org/ui/p/chromium/builders/try/linux-libfuzzer-asan-rel/2292144/overview
*
https://ci.chromium.org/ui/p/chromium/builders/try/linux-libfuzzer-asan-rel/2292444/overview

---------

Co-authored-by: Petr Hosek <phosek@google.com>