This is an ephemeral object that implements the core::fmt::Write trait.
It’s used as write!(&zx_libc::sanitizer::Log::new(), "...", ...) to send
a single logging line. The object holds a fixed buffer that is used to
collect the multiple fragments from formatters; it’s written using
zx_libc::sanitizer::log() when the buffer fills or the object is dropped.
This does a fast, best-effort attempt to collect a backtrace. It writes PC
values (return addresses) into the pc_buffer, and returns the subslice of
frames collected. The first frame (pc_buffer[0]) will be fast_backtrace()
itself (and that’s the only frame guaranteed to be collected), the second
will be that frame’s caller, and so on. This is safe even if register and
memory state is bogus. It’s best-effort; results will be imprecise in the
face of code that doesn’t use either shadow-call-stack or frame pointers.
Write logging information from the sanitizer runtime. The string is
expected to be printable text with ‘\n’ ending each line. Timestamps and
globally unique identifiers of the calling process and thread (zx::Koid)
are attached to all messages, so there is no need to include those details
in the text. The log of messages written with this call automatically
includes address and ELF build ID details of the program and all shared
libraries sufficient to translate raw address values into program symbols
or source locations via a post-processor that has access to the original
ELF files and their debugging information. The text can contain markup
around address values that should be resolved symbolically.
Runtimes that have binary data to publish (e.g. coverage) use this
interface. The name describes the data sink that will receive this blob of
data; the string is not used after this call returns. The caller creates a
VMO and passes it in. Each particular data sink has its own conventions
about both the format of the data in the VMO and the protocol for when data
must be written there. For some sinks, the VMO’s data is used immediately.
For other sinks, the caller is expected to have the VMO mapped in and be
writing more data there throughout the life of the process, to be analyzed
only after the process terminates. Yet others might use an asynchronous
shared memory protocol between producer and consumer. The return value is
either the null handle or a Zircon handle whose lifetime is used to signal
the readiness of the data in the VMO. This handle can be dropped to
indicate the data is ready to be consumed. Or the handle can safely be
leaked; the data will be ready when the process exits. Note there is no
indication of success or failure returned here (though it may be logged).
A null handle return value merely indicates there is no way to communicate
data readiness before process exit.