It turns out that the endianness-detection header delivered with the
softfloat library is extremely brittle and gives wrong results when
targeting FreeBSD (long story short, _BIG_ENDIAN is always defined there
and that breaks the #if defined() chain).
Use our own endianness detection header to work around any potential
problem.
- original PR #7949 (incorrectly) patched a generated-file and changes
have subsequently been lost/overwritten
- fix#7947 in a different way: drop `ppc32` because `ppc` already exists
std/crypto: use finer-grained error sets in function signatures
Returning the `crypto.Error` error set for all crypto operations
was very convenient to ensure that errors were used consistently,
and to avoid having multiple error names for the same thing.
The flipside is that callers were forced to always handle all
possible errors, even those that could never be returned by a
function.
This PR makes all functions return union sets of the actual errors
they can return.
The error sets themselves are all limited to a single error.
Larger sets are useful for platform-specific APIs, but we don't have
any of these in `std/crypto`, and I couldn't find any meaningful way
to build larger sets.
These are currently incorrect according to the gitattributes(5) and
gitignore(5) man pages. However, it seems github ended up treating them
as we intended due to a bug until recently when that bug was fixed.
This was also an experiment to see if it were easier to implement a new
feature when using the instruction encoder.
Verdict: It's not that much easier, but I think it's certainly much more
readable, because the description of the Instruction annotates what each
field means. Right now, precise knowledge of x86_64 instructions is
still required because things like when to set the 64-bit flag, how to
read x86_64 instruction references, etc. are still not automatically
done for you.
In the future, this interface might make it sligtly easier to write an
assembler for x86_64, by abstracting the bit-fiddling aspects of
instruction encoding.
From my very cursory reading, it seems that the register manager doesn't
distinguish between registers that are physically the same but have
different sizes.
In that case, this means that during codegen, we can't rely on
`reg.size()` when determining the width of the operations we have to
perform. Instead, we must use some form of `ty.abiSize(self.target.*)`
to determine the size of the type we're operating with. If this size is
64 bits, then we should enable 64-bit operation.
This fixed a bug in the codegen for spilling instructions, which was
overwriting the previous stack entry with zeroes. See the modified test
case in this commit.
There are parts of it that I didn't modify because the byte
representation was important (e.g. we need to know what the exact
byte position where we store the address into the offset table is)
