This makes it a little more straightforward to see what these return
values mean without needing to look at the implementation.
These tuples were also getting a little bit large.
Same behavior, but allows clang to elide pushing all of these values on
and off the stack, particularly given these are called quite frequently
throughout the opcode dispatcher.
Don't print how many instructions are installed in the tables.
This isn't useful anymore
Not installing signal 32 and 33 are something we don't support right now. Stop complaining in that case.
Stop printing when a thread is starting up and shutting down. If you want to see this then gdb shows it well.
Don't print clone flags unless we are hitting a case where we are printing another log message.
si_addr will still be incorrect. What matters more here is that SIGCHLD gets correct information.
The guest needs SIGCHLD ifnromation to be filled out correctly, otherwise TTY handoff hangs
with the child process stopped.
I saw a red herring that I thought the high cpu usage in steamwebhelper could come from signal handlers.
This turned out to not be the case, but now I've got this implemented.
Installs the few signal handlers that we need upfront but for everything that isn't a mandatory signal
we instead now wait until the guest also installs that signal handler.
This fixes#1107
Places them in RO where they can't be modified.
While we're in the area, we can use an alias to prevent duplicated array
types, and also add a static assert to ensure the arrays are always the
same size.
This allows us to avoid needing to bounds check several accesses in a
row that we know will always be successful.
When running the cpuid application (http://www.etallen.com/cpuid.html) I noticed
that we were returning some garbage data here.
After initially implementing support for leaf functions, it still didn't resolve the issue.
So I had to fix those in the x86-64 JIT.
I then went through and solved more issues with the function results.
- We now return a more sane CPU family that is near the feature set we support
- APICID now understands how to fill out the data correctly depending on emulated core counts
- Disabled some CPU features that we don't actually support
- Found two more cache functions that we weren't populating
- Filled with generic data cache size data
- Only thing that matters is that we ensure that cacheline size is reported as 64bytes
- L1D: 32KB, L1I: 32KB, L2: 512KB, L3: 8MB claimed for caches
- Implemented Leafs for functions
- 7h - Only has leaf 0
- Dh - Extended CPU features support
- Another register that lets you claim support for x87, SSE, and AVX
- Leaf 1 & 2 has some additional data
- 4h & 8000'0001Dh - Extended cache properties
- Almost the same as each other. One reports slightly less data though
After FEX has forked, there aren't any other threads in the process but their stacks remain.
We need to have some book keeping in place to have the stack ranges available to clean up
after fork.
We now keep both live stacks and dead stacks in a dequeue and on fork we will walk both to
clean up all stack objects that aren't our current thread.
rsi is a SSA argument, so we need to make sure to move the leaf argument first.
the leaf argument was getting corrupted when moving to the ABI.
Will be necessary once CPUID supports leafs
When floats and doubles were converting to integers we weren't doing the correct transformation.
AArch64 provides direct ops for all four of the op types. So lets use them
- f32 -> int64
- f32 -> int32
- f64 -> int64
- f64 -> int32
Doesn't fully fix the case of overflow for AArch64 since overflow behaviour is different.
x86 returns 0x8000'0000 or 0x8000'0000'0000'0000 while AArch64 saturates to the maximum signed
integers. Can't work around that without checking overflow flags.
This does solve the typical case though.
Fixes audio problems in all FMod games.
If the source GPR had data that was larger than the element it would overwrite other elements
Mask it correctly. This then matches behaviour with the other CPU backends
Theres a fair number of these so I won't describe them all.
A couple highlights are MPSADBW and PHMINPOSUW.
These don't really match with AArch64 very well so their IR is a bit ugly.
We need to save the vector registers otherwise we will corrupt them.
Also in the case of printing a vector register, fall down the specialized path
Only useful when debugging
Lioncash