aarch64: implement signal delivery

[shrik3]

[updated!] There are some todos, see commit messages. Anyways for the scope of this PR I'll stop here.

we have the basic stuffs running without issues now. try container ubuntu bash

[shrik3]

if i may add, for the sake of simplicity, the fpstate is completely ignored in the signal context. This is left fot the readers as practice. (这都是作者的良苦 用心) also with the current task/context structs (and their compositions) it's hacky to plug in architectural extensions such as aarch64 SIMD (SME and SVE). they are ignored as well.

[chl337]

This is the result of the test directly on the machine:

Is this what to be expected?

---

On Quark:

[chl337]

The struct ucontext is different between x86_64 and arm64 in Linux? Could this cause cause confusion to glibc?

This experimental (copy-paste from linux) implementation breaks SignalReturn().

[shrik3]

This is the result of the test directly on the machine:

Is this what to be expected?

On Quark:

Is this what to be expected?

Yes. in the test I have no sanity check whether the vdso __kernel_rt_sigreturn is a null pointer. If you pass 0 to sigaction and set restorer to true then you will get funky things.

[shrik3]

The struct ucontext is different between x86_64 and arm64 in Linux? Could this cause cause confusion to glibc?

This experimental (copy-paste from linux) implementation breaks SignalReturn().

good point. let me see

[shrik3]

The struct ucontext is different between x86_64 and arm64 in Linux? Could this cause cause confusion to glibc?

This experimental (copy-paste from linux) implementation breaks SignalReturn().

can confirm, I think the problem is with stack unwinding.

[chl337]

known issue:

1. could panic if the user does not set a working trampoline for the sigreturn. Interestingly the libc `signal()` does not use vdso `__kernel_rt_sigreturn` actively. Perhaps we are missing some stuffs.

How can this behavior be reproduced?

[shrik3]

known issue:

1. could panic if the user does not set a working trampoline for the sigreturn. Interestingly the libc `signal()` does not use vdso `__kernel_rt_sigreturn` actively. Perhaps we are missing some stuffs.

How can this behavior be reproduced?

see my example, replace the sigaction stuffs with one signal(signo, handler). The return trampoline will not be correctly called.

[chl337]

known issue:

1. could panic if the user does not set a working trampoline for the sigreturn. Interestingly the libc `signal()` does not use vdso `__kernel_rt_sigreturn` actively. Perhaps we are missing some stuffs.

How can this behavior be reproduced?

see my example, replace the sigaction stuffs with one signal(signo, handler). The return trampoline will not be correctly called.

Thanks and sorry for the noise, I am a totally noob on the subject.

[shrik3]

The struct ucontext is different between x86_64 and arm64 in Linux? Could this cause cause confusion to glibc?
This experimental (copy-paste from linux) implementation breaks SignalReturn().

can confirm, I think the problem is with stack unwinding.

fixed. The problem is with UContext Default constructor. (it has infinite recursion)

I don't know exactly why but patterns like this should be avoided.

+impl Default for UContext {
+    fn default() -> Self {
+        Self {
+            __pad: [0; (1024/8) - core::mem::size_of::<u64>()],
+            ..Default::default()                   <= this causes recursion into Self::default
+        }
+    }
+}

[chl337]

The struct ucontext is different between x86_64 and arm64 in Linux? Could this cause cause confusion to glibc?
This experimental (copy-paste from linux) implementation breaks SignalReturn().

can confirm, I think the problem is with stack unwinding.

fixed. The problem is with UContext Default constructor. (it has infinite recursion)

I don't know exactly why but patterns like this should be avoided.

+impl Default for UContext {
+    fn default() -> Self {
+        Self {
+            __pad: [0; (1024/8) - core::mem::size_of::<u64>()],
+            ..Default::default()                   <= this causes recursion into Self::default
+        }
+    }
+}

Oh, yes I see.
rust-lang/rust-clippy#8609

[CharlyYu]

I still get an error when run ubuntu bash

and this is the log:

The code is in the branch of armdev_signals+pr+wip and I get qkernel_d.bin and quark_d by make debug.

[CharlyYu]

And It seems the signal is handled repeatedly.

[chl337]

And It seems the signal is handled repeatedly.

Can you show the last instructions before the first SIGSEGV (signal 11)?
Also the your git log please. I can't reproduce it.

[CharlyYu]

git log:

[CharlyYu]

Can you show the last instructions before the first SIGSEGV (signal 11)?

[CharlyYu]

It seems a page fault with an inappropriate address.

[chl337]

git log:

Can you also apply #1220 and test again? Also do a make clean first.

[CharlyYu]

Same error, is it because I didn't cherry-pick codes in #1212 or other prs? can you push a branch of your codes that can run the ubuntu bash?

[chl337]

Same error, is it because I didn't cherry-pick codes in #1212 or other prs?
My tree: #1212 + #1215 + #1217 + #1220

can you push a branch of your codes that can run the ubuntu bash?

I can do it first in ~1.5 hours, sorry.

[shrik3]

@CharlyYu sorry for the late reply.

https://github.com/shrik3/Quark/tree/armdev_dev_base -> for you only

please take a look at the commit log and throw away my local changes (prefixed with local) that you don't want.

#1220 is not necessary for ubuntu bash to run. Also note that the quark is broken on the newest ubuntu container image (both on main and us). Try using something older. Also you could try busybox sh

Note on my local commits: there are PAN related code that are only relevant to our testing machine. Compilation could fail in your env.

[chl337]

It seems a page fault with an inappropriate address.

@CharlyYu That seems to me as a context switch issue... If not already solved, try to print the state during switches (use #1203 for pretty print)

[chl337]

On trying Redis I get the following error:
bad g in signal handler
which for me is pretty cryptic. The only reference I found online is on Go runtime. AFAIK Redis is supported on main branch (cannot tested myself though).

Reproduce:
docker run --rm -it -p 6379:6379 --runtime=quark_dlocal --name redis_test redis

[shrik3]

On trying Redis I get the following error: bad g in signal handler which for me is pretty cryptic. The only reference I found online is on Go runtime. AFAIK Redis is supported on main branch (cannot tested myself though).

Reproduce: docker run --rm -it -p 6379:6379 --runtime=quark_dlocal --name redis_test redis

this: https://go.googlesource.com/go/+/go1.15.3/src/runtime/signal_unix.go#378

please grep sys_rt_sigaction in the log. What's sigaction (the restorer specifically)?

Also FWIW I don't want to look into go runtime perks in the scope of this PR. Could you take this to an issue to keep it tracked?

[chl337]

On Fri May 10, 2024 at 11:15 AM CEST, Tianhao Wang wrote: > On trying Redis I get the following error: `bad g in signal handler` which for me is pretty cryptic. The only reference I found online is on [Go runtime](https://go.googlesource.com/go/+/go1.15.3/src/runtime/signal_unix.go#919). AFAIK Redis is supported on main branch (cannot tested myself though). > > Reproduce: `docker run --rm -it -p 6379:6379 --runtime=quark_dlocal --name redis_test redis` this: https://go.googlesource.com/go/+/go1.15.3/src/runtime/signal_unix.go#378 please grep sys_rt_sigaction in the log. What's sigaction (the restorer specifically)?

Alright, I will open a new issue for this.