This PR fixes several things related to threads emulation:
1. Support `SameTebFlags.InitialThread`
This flag is needed to support emulation of .net executables (not yet
fully supported) that don't have an entry point set in `PE` header. This
applies to both `PE32` and `PE64` executables. If `InitialThread` is set
the loader substitutes an entry point of the .net executable with
`mscoree.dll!_CorExeMain`.
2. Fix static thread local storage for `WOW64`
This fix resolves `shell32.dll` initialization on `WOW64`. This fix also
uses correct structure and field names that are obtained from the
corresponding `.pdb` files.
3. Fix dynamic thread local storage for `WOW64`
4. Fix setting argument of a `WOW64` thread start proc
5. Fix creating suspended thread and parse create_flags
Currently creating suspended thread doesn't work because
`NtCreateThreadEx` handler uses invalid flag `CREATE_SUSPENDED`. This PR
fixes that, and moreover it carefully parses create_flags of the
`NtCreateThreadEx` call.
6. Fix `FS` and `GS` handling
This PR fixes several problems with `GS` and `FS` segments:
* Wrong GDT descriptor for selector 0x53
* Update GDT descriptor for selector 0x53 for a `WOW64` process every
context switch like Windows does
* Set `GS` base when `GS` segment register is updated in 64-bit code
(code selector is `0x33`). When `GS` segment register is loaded with
correct selector (`0x2b`) `GS` base is set to 0. So, when the code
accesses something like `gs:[0]`, a page fault occurs. `KiPageFault`
handles this situation and sets correct `GS` base.
Also, take into account that `teb64.ExceptionList` initially contains
`teb32` address for `WOW64` process. This is used to setup `FS` base
when `wrfsbase` instruction is available. We can enable this instruction
using `kusd.ProcessorFeatures.arr[PF_RDWRFSGSBASE_AVAILABLE] = 1;` and
this work perfectly with `unicorn` backend. Unfortunately `icicle`
backend does not support `wrfsbase`, so I don't enable this instruction
by default.
- wrapped std::function into utils::optional_function
-- cleaned the code accordingly in windows_emulator
- using the 'emulator'/'windows_emulator' dependency implies the emulator_common as well.
The idea is to allow as much internal information into inner components.
to not burden all builds, the reflection level can be controlled via the
MOMO_REFLECTION_LEVEL (where 0 means no reflection code is included).
more reflection variables will be introduced as needed.
For now, the memory manager's layout state version is used to track
whether the memory layout is changed or not (at the lowest level). the
win_emu API consumer can use this reflection to decide to whether to
refresh or not expensive computations
