tree d7de1aece736e97065646db4a9564290ed2799d2
parent 61907ebd764afe75aa7134627f41827e6893d6d0
author Michael Buch <michaelbuch12@gmail.com> 1743675016 +0100
committer GitHub <noreply@github.com> 1743675016 +0100
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJn7l6ICRC1aQ7uu5UhlAAAgvgQAB57eO8a8upB4mMO0xs8opdw
 ZmJHjRQFREg6+x5FogCLIQja0v61ODwTzwy5Tl371UtKCmQ98weIhxaTFXKLSS63
 Me2BJ/e+imtR4XF2gXvRjwSqzUgz+6p+DjMDzGF/ggoG7VCdSz1XfsUCyiqpl2Da
 Y1U8i4WJ/vytoq7rT/4MzdB+GOU/D36JJ8MHecYMI/WGVKbaOSHRkIT/Kp02z+tl
 fYMQSRIkaZEIDgJ7+rNffgn0+falGICCLAZ2erSxcE/k6n6fnmBvXOimKLYrZ1Tf
 beFOyJGielcfDxpXPLQSK49W1P7vJcSN/1NghqIy1t/IHhGoSA9aCOwiN/UdMn+4
 MTc2bIlN6Bz4mDlABSMVxMc0kJaygVMbe5S+o2dCKlSE/an1FrkTqCwfvGUCVkUQ
 2PqBm5RqsQMgTqOm8a+qzFn7sSM15OubMasWwqYNHbMyaXrBuZZJP/Wwyn2HTlOl
 TlIok2tmDpajvzeFeVPn9nXcnPyXr9rm7I0gaKWRWuxl8g5E9K5gZlqZkCB7Ukf0
 31CgpIwbstdhGxSGhlbwULKcAdX05pNVr+xA1FZnUYJAbNMz2Vhlm1XdxHgTZ6Qr
 UgfeX//Pd/9FmTcb1sRKffTSDSiePNdF27mZpey+CRcCXXhl4vRNRned+zzwFyhP
 JHWWUlWqD/o9SDe9HlJS
 =hLjT
 -----END PGP SIGNATURE-----
 

[lldb][Target] RunThreadPlan to save/restore the ExecutionContext's frame if one exists (#134097)

When using `SBFrame::EvaluateExpression` on a frame that's not the
currently selected frame, we would sometimes run into errors such as:
```
error: error: The context has changed before we could JIT the expression!
error: errored out in DoExecute, couldn't PrepareToExecuteJITExpression
```

During expression parsing, we call `RunStaticInitializers`. On our
internal fork this happens quite frequently because any usage of, e.g.,
function pointers, will inject ptrauth fixup code into the expression.
The static initializers are run using `RunThreadPlan`. The
`ExecutionContext::m_frame_sp` going into the `RunThreadPlan` is the
`SBFrame` that we called `EvaluateExpression` on. LLDB then tries to
save this frame to restore it after the thread-plan ran (the restore
occurs by unconditionally overwriting whatever is in
`ExecutionContext::m_frame_sp`). However, if the `selected_frame_sp` is
not the same as the `SBFrame`, then `RunThreadPlan` would set the
`ExecutionContext`'s frame to a different frame than what we started
with. When we `PrepareToExecuteJITExpression`, LLDB checks whether the
`ExecutionContext` frame changed from when we initially
`EvaluateExpression`, and if did, bails out with the error above.

One such test-case is attached. This currently passes regardless of the
fix because our ptrauth static initializers code isn't upstream yet. But
the plan is to upstream it soon.

This patch addresses the issue by saving/restoring the frame of the
incoming `ExecutionContext`, if such frame exists. Otherwise, fall back
to using the selected frame.

rdar://147456589