Found this through introspection, only a real problem with -O0.
We were moving a fextl::vector in to a shared pointer so it can be long
living, this causes a change in ownership which was causing the
`BlobData` pointer to be stale. This was then passed to the work queue
to be consumed. In -O1 and above a std::move of a fextl::vector is a
proper move, but -O0 it turns in to a copy.
Easy fix is to just create the shared_ptr early and reference that, so
the pointer is long lived and no references become stale.
NtDllRedirectionLUT has NtDllRedirectionLUTSize entries, so valid
offsets are 0 to NtDllRedirectionLUTSize - 1. The bounds check used
b.hi, which let an offset equal to the size through and read one entry
past the end of the allocation.
NtDllRedirectionLUTSize is a uint32_t, but CheckCall loaded it with a
64-bit ldr. The upper half of the bound then comes from whatever follows
the variable in memory, and the :lo12: offset of a 64-bit ldr needs an
8-byte aligned symbol, so the link fails with "misaligned ldr/str offset"
when the variable ends up on a 4-byte boundary.
Load it with a 32-bit ldr, which zero-extends into x17 for the compare.
This peephole removes unnecessary masking operations when the mask is
provably all 1s. This improves performance in GB7 'Asset Compression' by
about 2% with SVE and about 4% without SVE.
This doesn't fully fix#5912 but gets a step closer. Instead of just
hashing the filename, hash in the build-id as well when it exists.
This isn't all encompassing because the build-id may not exist in all
cases. Crypt Of the Necrodancer for example doesn't ship with the
build-id on their 64-bit build. Although their legacy 32-bit build had
it.
The build-id is always a hash, depending on tool it is either 64-bit or
160-bit in all the executables I found. Although it can be anything so
make sure to be flexible enough to support everything.
Just to ensure if someone is injecting a built FEX in to the Steam
depot, it doesn't happen to pick up on their system installed packages.
When built under SteamRT4 this isn't an issue as they don't exist, but
locally I'm usually not spinning up the docker instance each time and I
tend to get libxxhash-dev installed since Mesa needs it.
Ryan Houdek