Default and unspecified values for offline_file_type_t

[abhinav92003]

Today, offline_file_type_t has OFFLINE_FILE_TYPE_DEFAULT which perhaps at some point previously was intended for real trace files with no other "special" bit. But as of today, it seems that we would expect atleast one of the arch-related bits (OFFLINE_FILE_TYPE_ARCH_*).

dynamorio/clients/drcachesim/common/trace_entry.h

Line 992 in f007194

OFFLINE_FILE_TYPE_DEFAULT = 0x00,

Some existing code in opcode_mix does assume that no existing trace may use OFFLINE_FILE_TYPE_DEFAULT-only.

dynamorio/clients/drcachesim/tools/opcode_mix.cpp

Line 184 in f007194

* OFFLINE_FILE_TYPE_DEFAULT (== 0) should never be present alone and can be used as

Also, the scheduler initializes the get_filetype value to 0 (which is essentially OFFLINE_FILE_TYPE_DEFAULT):

dynamorio/clients/drcachesim/scheduler/scheduler.h

Line 1202 in f007194

uint64_t filetype_ = 0;

But then there are various unit tests that use 0 as a real value for the test trace:

dynamorio/clients/drcachesim/tests/view_test.cpp

Line 307 in f007194

gen_marker(t1, TRACE_MARKER_TYPE_FILETYPE, 0),

and also existing code that uses -1 to mean uninitialized:

dynamorio/clients/drcachesim/tools/view.cpp

Line 227 in f007194

if (filetype_ == -1) {

Goal: If it is indeed so that OFFLINE_FILE_TYPE_DEFAULT cannot be present on its own in real traces, perhaps we can use that as the uninitialized sentinel value, which is much cleaner. In that case, we should rename it (keeping the original enum value for backward compatibility) to OFFLINE_FILE_TYPE_UNINITIALIZED.

[abhinav92003]

Also some existing if-conditions are set up in a way that shows that we did assume previously that some traces may not have any arch-bit set.

dynamorio/clients/drcachesim/tools/view.cpp

Line 238 in f007194

if (TESTANY(OFFLINE_FILE_TYPE_ARCH_ALL & ~OFFLINE_FILE_TYPE_ARCH_REGDEPS,

[derekbruening]

An old-style trace only meant for address analysis such as through drcachesim that has no embedded encodings and so has no need to indicate an architecture would today have zero filetype bits set and still be perfectly valid for analysis tools that don't need to decode instructions. So I'm not sure it's worth completely disallowing such traces just because we want a sentinel value that uses an existing enum value. It seems cleaner to use the -1 or create a new sentinel value than to try to force a value of 0 to be invalid.