| commit | c48c1c2d03abb2e5ac119b7f4bebf85768ea5590 | |
| author | Douglas Katzman <dougk@google.com> | |
| Thu, 9 Feb 2017 03:35:07 +0000 (8 22:35 -0500) | ||
| committer | Douglas Katzman <dougk@google.com> | |
| Thu, 9 Feb 2017 03:38:38 +0000 (8 22:38 -0500) | ||
| tree | fa2956c04dd06b59507d4fbab1d1d2dd0503eb51 | treesnapshot (tar.gz zip) |
| parent | 7b42b3412f53700587f8854fe0099c19f62afec1 | commitdiff |
Fix yet another "how did this ever work?" thing in genesis.
* Fixups on x86-64 would read 8 bytes, 4 of which were total junk,
coming from the next machine instruction. Little-endianness,
and the fact that all (SETF BVREF-n) setters ignore bits,
made this work essentially by accident.
* The test for whether to record in %code-fixups a relative fixup
for 32-bit was wrong but got the right answer. It meant to compare
the absolute address in question against the code component address
range, but instead compared the computed displacement.
* Fixups on x86-64 would read 8 bytes, 4 of which were total junk,
coming from the next machine instruction. Little-endianness,
and the fact that all (SETF BVREF-n) setters ignore bits,
made this work essentially by accident.
* The test for whether to record in %code-fixups a relative fixup
for 32-bit was wrong but got the right answer. It meant to compare
the absolute address in question against the code component address
range, but instead compared the computed displacement.
| src/compiler/generic/genesis.lisp | diffblobblamehistory |