tree 52484d0fb2037ce2b89c08e56cad890030b582ae
parent ce159d20e52add25e51f2aa8c504726221b204ba
author Jason Molenda <jmolenda@apple.com> 1751344073 -0700
committer GitHub <noreply@github.com> 1751344073 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJoY2PJCRC1aQ7uu5UhlAAADCcQAKLgS4xkDHu4LyIbon4HUYdV
 U2oQyzs2DU6x0D/x8D9r8bKHwjvNf57e5NbwgafuNYVe8ai1srIL91rpEcGqACMg
 UsqZ7RZNC1BLyYWimdzb+RWwc0cxyb0zRuGFdo1vGkB75CJLZnnStbHMnl6DbFNh
 q+fFK07OsNfZ44wmN5a0UNwK4atKf3ohXfgWKzU4rygQS4tpG02eyYY/Fr5NuOiP
 o+KlQQGdlYFWCJ/g6Wv0ddH24WKeD5FeNRE0TQY3AaJ9HgQjkkACgqXtdo/N7HDn
 BdDK0BZsZbNnUkrwWQ8lycJccUR/ZmKlBTBoK3SFs7u6QYGjVofcsW++n+EiNHv7
 9aX38EYu4+8gKXqVmw81z2vnKEz2PvqBjlGL+ygKv1tBHGSDc7lWiYdGW9e857nI
 yOLeyLea+qaETSysuZolEtdq+43yCrrAONZyLGpnAdmWwlqVSVeUHZWn+OYORP/9
 FX13mJYeIXttXUaq9GuJ9+7sDCAVYmM9xAl1qSB1p1p5iTgHvB0g4kJJb6GO7qGE
 0JzXWScojYQUpDD69e5X7HrTCCYvTc4WQQXPmM+wEma6MPtkViUk37Gp5TmlgFZy
 lQpmnTrJVsZTdQjQWiU44FZK1YKhQA6gILmoVliQxiNkpqSeXlpiOz1hXImqOfXj
 UQtfleRaQmYOLZzi9BXM
 =ng6/
 -----END PGP SIGNATURE-----
 

[lldb][Mach-O] Fix several bugs in x86_64 Mach-O corefile (#146460)

reading, and one bug in the new RegisterContextUnifiedCore class.

The PR I landed a few days ago to allow Mach-O corefiles to augment
their registers with additional per-thread registers in metadata exposed
a few bugs in the x86_64 corefile reader when running under different CI
environments. It also showed a bug in my RegisterContextUnifiedCore
class where I wasn't properly handling lookups of unknown registers
(e.g. the LLDB_GENERIC_RA when debugging an intel target).

The Mach-O x86_64 corefile support would say that it had fpu & exc
registers available in every corefile, regardless of whether they were
actually present. It would only read the bytes for the first register
flavor in the LC_THREAD, the GPRs, but it read them incorrectly, so
sometimes you got more register context than you'd expect. The LC_THREAD
register context specifies a flavor and the number of uint32_t words;
the ObjectFileMachO method would read that number of uint64_t's,
exceeding the GPR register space, but it was followed by FPU and then
EXC register space so it didn't crash. If you had a corefile with GPR
and EXC register bytes, it would be written into the GPR and then FPU
register areas, with zeroes filling out the rest of the context.