We don't support actually using ETW on windows/arm, but to make things
easier for downstream dependencies, we want to still allow the package
to compile and just no-op on this architecture. We do this by returning
a nil Provider, and implementing its methods to no-op when the receiver
is nil.
Previously this was implemented by putting NewProviderWithID in
provider_unsupported.go, but when we refactored the code so that the
actual work was done in NewProviderWithOptions instead, we didn't fix up
provider_unsupported. This change fixes this by putting only
NewProviderWithOptions in provider_unsupported.go, since the other
provider creation functions call into this one.
Signed-off-by: Kevin Parsons <kevpar@microsoft.com>
The ETW registration handle is defined to be 64-bits on all platforms. The Go
type previously used a uintptr which created problems on 32-bit systems. This
change adds a new wrapper file which receives a 64-bit handle for the functions
defined in it, and correctly passes it to the native ETW functions either as-is
(on 64-bit) or as two 32-bit values (on 32-bit).
This required a minor change in mksyscall_windows.go, to allow multiple syscalls
that map to the same underlying function without causing a duplicate definition
error in the generated file.
Proper support for ETW on ARM will require additional changes in Go to support
more than 16 bytes of arguments to a syscall callback. Until this work is done,
the ETW package is being changed to no-op on ARM.
There is a cleanup function deferred to remove the provider from the global
provider map. However, this function didn't bind the value of provider ahead of
time, so when the provider creation returned with nil for provider, we tried to
cleanup a nil provider, and panicked.
Kyle W