wasmtime / issue #5652 winch: Use aarch64 backend for cod... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #5652 winch: Use aarch64 backend for cod...

Wasmtime GitHub notifications bot (Jan 30 2023 at 16:01):

github-actions[bot] commented on issue #5652:

Subscribe to Label Action

cc @saulecabrera

<details>
This issue or pull request has been labeled: "winch"

Thus the following users have been cc'd because of the following labels:

saulecabrera: winch

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Feb 01 2023 at 17:12):

saulecabrera commented on issue #5652:

@cfallin regarding signal safety -- I did a verification with the program below, using bl_signal which as far as I can tell doesn't set up an alternative stack.

<details>
<summary>Signal handler</summary>

.global _start
.align 2

_start:
  stp x29, x30, [sp, #-16]!

  ;; Signal number, sigint in this case
  mov x0, #2

  ;; Load address of the handler
  adr x1, _signal_handler

  ;; Call bsd_signal to register the signal handler
  bl _bsd_signal

  ;; Unalign the sp;
  ;; simulate making space for word-wise pushes
  sub sp, sp, #8
  sub sp, sp, #8
  sub sp, sp, #8

;; Infinite loop;
;; simulate waiting
   loop: mov x0, #1  ;; Descriptor
   adr x1, _looping   ;; Message address
   mov x2, #5           ;; Length
   mov x16, #4         ;; Write
   svc #0                  ;; Call service
   b loop

;; Commented out since it will never make it here
;; ldp x29, x30, [sp], #16
;; ret

_signal_handler:
  stp x29, x30, [sp, #-16]!
  mov x0, #1             ;; Descriptor
  adr x1, _message  ;; Message address
  mov x2, #15           ;; Length
  mov x16, #4           ;; Write
  svc #0                    ;;  Call service

  ldp x29, x30, [sp], #16

  ;; Terminate the program (for demonstration purposes)
  ;; and to quit the infinite loop

  mov x0, #0      ;; Return code
  mov x16, #1     ;; Service code
  svc #0              ;; Call to terminate

_message: .ascii "Signal handled\n"
_looping: .ascii "Loop\n"

</details>

and the results confirm the theory that SP is aligned when entering the signal handler's frame. The program above runs successfully even though the stack pointer is not aligned to 16 before entering the loop. When the signal handler's code is changed to use an unaligned SP to address memory (e.g. stp x29, x30, [sp, #-24]!) we get a bus error crash as expected.

Wasmtime GitHub notifications bot (Feb 01 2023 at 17:14):

saulecabrera edited a comment on issue #5652:

@cfallin regarding signal safety -- I did a verification with the program below, using bl_signal which as far as I can tell doesn't set up an alternative stack.

<details>
<summary>Signal handler</summary>

.global _start
.align 2

_start:
  stp x29, x30, [sp, #-16]!

  ;; Signal number, sigint in this case
  mov x0, #2

  ;; Load address of the handler
  adr x1, _signal_handler

  ;; Call bsd_signal to register the signal handler
  bl _bsd_signal

  ;; Unalign the sp;
  ;; simulate making space for word-wise pushes
  sub sp, sp, #8
  sub sp, sp, #8
  sub sp, sp, #8

;; Infinite loop;
;; simulate waiting
   loop: mov x0, #1  ;; Descriptor
   adr x1, _looping   ;; Message address
   mov x2, #5           ;; Length
   mov x16, #4         ;; Write
   svc #0                  ;; Call service
   b loop

;; Commented out since it will never make it here
;; ldp x29, x30, [sp], #16
;; ret

_signal_handler:
  stp x29, x30, [sp, #-16]!
  mov x0, #1             ;; Descriptor
  adr x1, _message  ;; Message address
  mov x2, #15           ;; Length
  mov x16, #4           ;; Write
  svc #0                    ;;  Call service

  ldp x29, x30, [sp], #16

  ;; Terminate the program (for demonstration purposes)
  ;; and to quit the infinite loop

  mov x0, #0      ;; Return code
  mov x16, #1     ;; Service code
  svc #0              ;; Call to terminate

_message: .ascii "Signal handled\n"
_looping: .ascii "Loop\n"

</details>

and the results confirm the theory that SP is aligned when entering the signal handler's frame. The program above runs successfully even though the stack pointer is not aligned to 16 before entering the loop. If the signal handler's code is changed to use an unaligned SP to address memory (e.g. stp x29, x30, [sp, #-24]!) we get a bus error crash as expected.

Wasmtime GitHub notifications bot (Feb 02 2023 at 00:51):

saulecabrera edited a comment on issue #5652:

@cfallin regarding signal safety -- I did a verification with the program below, using bl_signal which as far as I can tell doesn't set up an alternative stack.

<details>
<summary>Signal handler</summary>

.global _start
.align 2

_start:
  stp x29, x30, [sp, #-16]!

  ;; Signal number, sigint in this case
  mov x0, #2

  ;; Load address of the handler
  adr x1, _signal_handler

  ;; Call bsd_signal to register the signal handler
  bl _bsd_signal

  ;; Unalign the sp;
  ;; simulate making space for word-wise pushes
  sub sp, sp, #8
  sub sp, sp, #8
  sub sp, sp, #8

;; Infinite loop;
;; simulate waiting
   loop: mov x0, #1  ;; Descriptor
   adr x1, _looping   ;; Message address
   mov x2, #5           ;; Length
   mov x16, #4         ;; Write
   svc #0                  ;; Call service
   b loop

;; Commented out since it will never make it here
;; ldp x29, x30, [sp], #16
;; ret

_signal_handler:
  stp x29, x30, [sp, #-16]!
  mov x0, #1             ;; Descriptor
  adr x1, _message  ;; Message address
  mov x2, #15           ;; Length
  mov x16, #4           ;; Write
  svc #0                    ;;  Call service

  ldp x29, x30, [sp], #16

  ;; Terminate the program (for demonstration purposes)
  ;; and to quit the infinite loop

  mov x0, #0      ;; Return code
  mov x16, #1     ;; Service code
  svc #0              ;; Call to terminate

_message: .ascii "Signal handled\n"
_looping: .ascii "Loop\n"

</details>

and the results confirm the theory that SP is _correctly_ aligned when entering the signal handler's frame. The program above runs successfully even though the stack pointer is not aligned to 16 before entering the loop. If the signal handler's code is changed to use an unaligned SP to address memory (e.g. stp x29, x30, [sp, #-24]!) we get a bus error crash as expected.

Wasmtime GitHub notifications bot (Feb 02 2023 at 16:22):

cfallin commented on issue #5652:

Ah, that's a really interesting outcome, thanks! Was this on macOS/aarch64 or Linux/aarch64? (I guess we'd want to make sure it's properly handled on both?)

Wasmtime GitHub notifications bot (Feb 02 2023 at 22:19):

saulecabrera commented on issue #5652:

Ah, that's a really interesting outcome, thanks! Was this on macOS/aarch64 or Linux/aarch64? (I guess we'd want to make sure it's properly handled on both?)

Yeah, tested in both.

MacOS Ventura 13.2: the linked example in my previous comment is the one I used in Mac.

For linux: I used Ubuntu 20.04.5. I tweaked the program above to use the right params for syscalls.

Last updated: Oct 23 2024 at 20:03 UTC