Pretty printer for #trace_entry_t-format traces about dynamorio HOT 3 OPEN

Note that trace_entry_t was originally not meant to be a public interface at all. Even now with the record_filter_t tool operating on it, nearly all uses should be at the memref_t level. We want to discourage new tools like converters from our format to other formats from using trace_entry_t as they will end up duplicating caching of encodings + v2p + other non-repeated items or will make mistakes; that is one reason we never wanted it to be well-documented/publicized/supported externally.

from dynamorio.

Pasting from #6771 (comment)

trace_entry_t is not meant to be a public interface with guaranteed stability. The public interface is the memref_t record and reader library and the libraries on top of those like the analysis tools. trace_entry_t is supposed to be treated more like a black box by users. Its individual fields are not doxygen-commented.

Hence, providing a pretty printer seems to send the wrong message, encouraging users to peer inside the black box. We would prefer things like converters to other simulator formats to use memref_t + reader_t whose abstraction layer hides a number of messy details.

The record_filter tool can be used while keeping trace_entry_t a black box, as basically all of its filters operate above the memref_t abstraction level: remove marker types; trim to timestamp values; apply cache filters. So it is a little different.

from dynamorio.

Further observations:

• The on-disk record format is not very usable as the encodings (beyond the 1st) are missing, so you just see the PC w/o knowing what instruction it is.

• On-disk examination is generally a debugging step. Once something is fixed, the memref_t view tool should generally always be run as the final step to confirm the tool view is correct, and the invariant_checker used for regression checking.

• The last time I looked at the on-disk view was debugging record_filter zip chunking support. There I had to look just before and after the 10M-instr chunk boundaries. Running od on one particular zipfile subfile at a time made this very easy. This new tool abstracts away the file divisions and provides a single trace_entry_t stream: so unfortunately I don't think it would have removed the need to run od for this debugging (even if the chunk markers are found, there is no fast skipping implemented at the trace_entry_t layer, and the markers can't be assumed to be correct when debugging the chunk boundaries: have to run od anyway).

from dynamorio.