Re: master: x86-64: Improve break instruction change a little more

Break arguments could be moved to the debug fun. But it will make
decoding internal errors in C harder.

On Tue, Nov 11, 2025 at 7:50 PM snuglas via Sbcl-commits
<[email protected]> wrote:
>
> The branch "master" has been updated in SBCL:
>        via  67ce03f689f1ca266ae0d60f4982acd0727f5202 (commit)
>       from  db7eb0d55fb79cbf304bfe62cac072a7f9fb08a0 (commit)
>
> - Log -----------------------------------------------------------------
> commit 67ce03f689f1ca266ae0d60f4982acd0727f5202
> Author: Douglas Katzman <[email protected]>
> Date:   Tue Nov 11 11:49:43 2025 -0500
>
>     x86-64: Improve break instruction change a little more
>
>     Always use unadorned UD2 for pseudo-atomic unless we can't.
>     The only reason to avoid it for receive-pending-interrupt is that UD2 might
>     be needed for _all_ traps, which in general are followed by opaque bytes.
>     And officially there is no single-byte illegal opcode, which we'd like
>     to have because reasons. (So claim revs 795e122b and 6e722b9c regarding
>     Haiku OS though the situation may have changed since.) But anyway, if UD2
>     isn't used for other purposes, then using an instruction that is not
>     followed by un-decodable bytes is preferable to one that is.
>
>     Back story: we got a complaint that our Lisp binaries contained a lot of
>     AVX instructions that were causing CPU throttling, which may affect tasks
>     other than your own, due to thermal management. So I promised we don't have
>     a ton of AVX instructions, and that any offline tool which statically analyses
>     Lisp assembly code is going to wrongly decode due to loss of sync after every
>     0xCC byte unless you're privy to the magic of the Lisp payload bytes.
> ---
>  src/compiler/x86-64/macros.lisp | 5 +++--
>  src/runtime/x86-64-arch.c       | 4 ++--
>  2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/src/compiler/x86-64/macros.lisp b/src/compiler/x86-64/macros.lisp
> index 36e3beaca..8a98d957d 100644
> --- a/src/compiler/x86-64/macros.lisp
> +++ b/src/compiler/x86-64/macros.lisp
> @@ -213,8 +213,9 @@
>        ;; using the process signal mask.
>        #+partial-sw-int-avoidance (inst call (ea (make-fixup 'synchronous-trap :assembly-routine)))
>        #-partial-sw-int-avoidance (progn
> -      #+int4-breakpoints (inst ud2)
> -      #-int4-breakpoints (inst break pending-interrupt-trap))
> +      ;; *NOT* ud2-breakpoints means *do* use UD2 for pseudo-atomic, as a special case.
> +      #-ud2-breakpoints (inst ud2)
> +      #+ud2-breakpoints (inst break pending-interrupt-trap))
>        OUT)))
>
>  (defmacro define-allocator (name &body body &aux (g (cdr (assoc :generator body))))
> diff --git a/src/runtime/x86-64-arch.c b/src/runtime/x86-64-arch.c
> index d3cbc6c9e..32c5934ee 100644
> --- a/src/runtime/x86-64-arch.c
> +++ b/src/runtime/x86-64-arch.c
> @@ -460,8 +460,8 @@ sigill_handler(int __attribute__((unused)) signal,
>  #ifdef LISP_FEATURE_UD2_BREAKPOINTS
>          return sigtrap_handler(signal, siginfo, context);
>  #else
> -        /* If and only if 0xCE is our error trap opcode, then UD2 ends pseudo-atomic sequences.
> -         * Apart from error breaks, the normal instruction stream is fully decodable by 'gdb'
> +        /* UD2 ends pseudo-atomic sequences and has no trailing bytes that encode the
> +         * reason for the trap. So the normal instruction stream is fully decodable by 'gdb'
>           * - which shows 0xCE as "(bad)" - or other tools, being devoid of arbitrary bytes
>           * that encode error metadata after the trapping instruction */
>          return interrupt_handle_pending(context);
>
> -----------------------------------------------------------------------
>
>
> hooks/post-receive
> --
> SBCL
>
>
> _______________________________________________
> Sbcl-commits mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sbcl-commits


_______________________________________________
Sbcl-commits mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-commits