runtime: add hexdumper

Currently, we have a simple hexdumpWords facility for debugging. It's
useful but pretty limited.

This CL adds a much more configurable and capable "hexdumper". It can
be configured for any word size (including bytes), handles unaligned
data, includes an ASCII dump, and accepts data in multiple slices. It
also has a much nicer "mark" facility for annotating the hexdump that
isn't limited to a single character per word.

We use this to improve our existing hexdumps, particularly the new
mark facility. The next CL will integrate hexdumps into debuglog,
which will make use of several other new capabilities.

Also this adds an actual test.

The output looks like:

                       7 6 5 4  3 2 1 0   f e d c  b a 9 8  0123456789abcdef
    000000c00006ef70:                    03000000 00000000          ........
    000000c00006ef80: 00000000 0053da80  000000c0 000bc380  ..S.............
                      ^ <testing.tRunner.func2+0x0>
    000000c00006ef90: 00000000 0053dac0  000000c0 000bc380  ..S.............
                      ^ <testing.tRunner.func1+0x0>
    000000c00006efa0: 000000c0 0006ef90  000000c0 0006ef80  ................
    000000c00006efb0: 000000c0 0006efd0  00000000 0053eb65  ........e.S.....
                                         ^ <testing.(*T).Run.gowrap1+0x25>
    000000c00006efc0: 000000c0 000bc380  00000000 009aaae8  ................
    000000c00006efd0: 00000000 00000000  00000000 00496b01  .........kI.....
                                         ^ <runtime.goexit+0x1>
    000000c00006efe0: 00000000 00000000  00000000 00000000  ................
    000000c00006eff0: 00000000 00000000                     ........

The header gives column labels, indicating the order of bytes within
the following words. The addresses on the left are always 16-byte
aligned so it's easy to combine that address with the column header to
determine the full address of a byte. Annotations are no longer
interleaved with the data, so the data stays in nicely aligned
columns. The annotations are also now much more flexible, including
support for multiple annotations on the same word (not shown).

Change-Id: I27e83800a1f6a7bdd3cc2c59614661a810a57d4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/681375
Reviewed-by: Michael Pratt <mpratt@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Austin Clements <austin@google.com>

0 files changed, 0 insertions, 0 deletions