split the Query/Set syscalls out into secondary tables

_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on May 16, 2014 01:30:21_

Xref issue #1540 Xref issue #1547 This is a separate issue on splitting the Query/Set syscalls out into secondary tables, for two purposes:

1) We need to provide the name of the struct for each enum code, for issue #1540 2) Some enum codes have separate return success semantics: issue #1547 **\* TODO secondary tables for each Query/Set enum code set?

For secondary tables, we'd have at least 18 of them:
> grep -o '([A-Z]*_INFORMATION_CLASS),' drsyscall/drsyscall_windows.c | sort | uniq -c
1 (ATOM_INFORMATION_CLASS),
2 (ENLISTMENT_INFORMATION_CLASS),
1 (EVENT_INFORMATION_CLASS),
4 (FILE_INFORMATION_CLASS),
2 (FS_INFORMATION_CLASS),
2 (KEY_INFORMATION_CLASS),
1 (MEMORY_INFORMATION_CLASS),
1 (MUTANT_INFORMATION_CLASS),
2 (OBJECT_INFORMATION_CLASS),
1 (PORT_INFORMATION_CLASS),
2 (RESOURCEMANAGER_INFORMATION_CLASS),
1 (SECTION_INFORMATION_CLASS),
1 (SEMAPHORE_INFORMATION_CLASS),
4 (SYSTEM_INFORMATION_CLASS),
1 (TIMER_INFORMATION_CLASS),
2 (TOKEN_INFORMATION_CLASS),
2 (TRANSACTION_INFORMATION_CLASS),
2 (TRANSACTIONMANAGER_INFORMATION_CLASS),

We'd need a better soln than the global var "sysnum_secondary_zero" used
for the wingdi secondary tables.

Would it be weird to promote these info classes to first-class secondary
syscalls, and not promote a bunch of other candidates like
NtDeviceIoControlFile codes, or 32-bit Linux IPC syscalls (SYS_socketcall,
SYS_semctl, SYS_msgctl, SYS_shmctl)?

Would this save drstrace from having to encode numerous enum-to-string
tables, since the enum string would be right there in the syscall name?
E.g., "NtQueryVirtualMemory.MemoryWorkingSetList".
Xref issue #1540.

For the separate type name per Query/Set struct: prob best to encode in
table, via a new type_name field in sysinfo_arg_t.

***\* TODO avoid duplicated entries

Some of the enums have as many as 40 values. I'm ok w/ duplicated data:
we're only talking about a few KB. But for maintainability we do not want
duplicated sources. Multi-line macros are a pain. How about at startup
we copy fields? Costs us runtime overhead I guess.

syscall_info_t syscall_QueryVirtualMemory_info[] = {
{{0,0},"NtQueryVirtualMemory.MemoryBasicInformation", OK, RNTST, 6,
{
{0, sizeof(HANDLE), SYSARG_INLINED, DRSYS_TYPE_HANDLE},
{1, sizeof(PVOID), SYSARG_INLINED, DRSYS_TYPE_POINTER},
{2, sizeof(MEMORY_INFORMATION_CLASS), SYSARG_INLINED, DRSYS_TYPE_SIGNED_INT},
{3, -4, W|NAMED, 0, "MEMORY_BASIC_INFORMATION"},
{3, -5, WI},
{4, sizeof(ULONG), SYSARG_INLINED, DRSYS_TYPE_UNSIGNED_INT},
{5, sizeof(ULONG), W|HT, DRSYS_TYPE_UNSIGNED_INT},
}
},
{{0,0},"NtQueryVirtualMemory.MemoryWorkingSetList", OK, RNTST, 6,
{ {3, -4, W|NAMED, 0, "MEMORY_WORKING_SET_LIST"}, }
},
{{0,0},"NtQueryVirtualMemory.MemorySectionName", OK, RNTST, 6,
{ {3, -4, W|NAMED, 0, "MEMORY_SECTION_NAME"}, }
},
};

Macro:
#define ENTRY_QueryVirtualMemory(typename) \
{ \
{0, sizeof(HANDLE), SYSARG_INLINED, DRSYS_TYPE_HANDLE}, \
{1, sizeof(PVOID), SYSARG_INLINED, DRSYS_TYPE_POINTER}, \
{2, sizeof(MEMORY_INFORMATION_CLASS), SYSARG_INLINED, DRSYS_TYPE_SIGNED_INT}, \
{3, -4, W|NAMED, 0, typename}, \
{3, -5, WI}, \
{4, sizeof(ULONG), SYSARG_INLINED, DRSYS_TYPE_UNSIGNED_INT}, \
{5, sizeof(ULONG), W|HT, DRSYS_TYPE_UNSIGNED_INT}, \
}

syscall_info_t syscall_QueryVirtualMemory_info[] = {
{{0,0},"NtQueryVirtualMemory.MemoryBasicInformation", OK, RNTST, 6,
ENTRY_QueryVirtualMemory("MEMORY_BASIC_INFORMATION")
},
{{0,0},"NtQueryVirtualMemory.MemoryWorkingSetList", OK, RNTST, 6,
ENTRY_QueryVirtualMemory("MEMORY_WORKING_SET_LIST")
},
{{0,0},"NtQueryVirtualMemory.MemorySectionName", OK, RNTST, 6,
ENTRY_QueryVirtualMemory("MEMORY_SECTION_NAME")
},
};

***\* TODO need default for new codes added

How do we do that when we're using a hashtable lookup? We need a max code
stored in the primary table entry, and an "unknown type" entry to use
(perhaps at the max code entry in the secondary table).

_Original issue: http://code.google.com/p/drmemory/issues/detail?id=1549_