Golang 1.22.1协程抢占机制核心实现相关技术疑问

1. 为何信号处理函数sighandler需要被汇编函数sigtramp包裹？ #

• 内核信号处理有严格调用约定限制：内核会直接用当前线程的栈执行信号处理逻辑，但Go的goroutine使用用户态私有栈，直接让内核调用Go实现的sighandler会破坏goroutine栈结构，甚至引发栈溢出。
• sigtramp作为汇编层跳板，承担三个核心职责：一是完整保存当前线程的寄存器上下文（包括被抢占goroutine的rip、rsp等），为后续恢复提供可靠状态；二是切换到Go runtime预先设置的专用信号栈执行sighandler，避免与原goroutine栈产生冲突；三是完成内核调用约定与Go runtime调用约定的转换，把内核传递的信号参数转换成Go代码可处理的格式。
• 汇编实现的sigtramp能保证底层操作的原子性与正确性——涉及寄存器操作、栈切换这类底层逻辑，Go高级语言代码无法直接实现精准控制。

2. 代码行ctxt.pushCall(abi.FuncPCABI0(asyncPreempt), newpc)的具体作用是什么？直接调用asyncPreempt无法达到相同效果吗？ #

这行代码的核心是在被抢占goroutine的栈上构造调用帧，将抢占逻辑注入到该goroutine的执行流中，和直接调用asyncPreempt有本质区别：

• 直接调用asyncPreempt是在信号处理函数的上下文（当前处理信号的M线程）中执行，不属于被抢占的G。这种情况下，asyncPreempt的调度逻辑无法作用于目标G，根本触发不了goroutine的抢占切换。
• ctxt.pushCall的具体操作：修改被抢占G的栈帧，将asyncPreempt的入口地址压入栈顶，同时把原执行地址newpc作为返回地址保存。当该G后续被调度恢复时，会从栈顶取出asyncPreempt的地址作为下一条执行指令，自动进入抢占逻辑——包括保存G的完整状态、调用gopreempt_m触发调度，最终跳回newpc继续执行。
• 简单来说，这是让被抢占的G“主动”执行抢占流程，而非在信号上下文里强行操作，符合Go runtime的调度模型。

3. 被中断的goroutine的rip、栈及寄存器具体存储在何处？如何保证这些寄存器未被修改且属于原goroutine？rip最初是如何被放到栈上的？ #

存储位置 #

• 寄存器上下文（含rip）：信号触发时，内核会先将当前线程的寄存器状态保存到信号栈的ucontext_t结构体中；随后sigtramp会把这些寄存器值复制到被抢占G的g.sched字段（Go runtime专为G调度状态设计的结构体）中，其中rip对应g.sched.pc，rsp对应g.sched.sp。
• 栈信息：被抢占G的栈起始、结束地址通过g.stack字段记录，栈的当前状态则由g.sched.sp指向的栈指针维护。

寄存器状态的可靠性保证 #

• sigtramp是汇编实现的，执行过程中仅做必要的寄存器保存/恢复操作，不会修改原G的寄存器值；
• 信号处理期间，当前M线程会与被抢占的G绑定，直到信号处理完成，这段时间内不会有其他G使用该M的寄存器；
• g.sched是每个G独有的私有字段，仅由操作该G的M线程访问，不存在并发修改风险。

rip入栈的过程 #

• 内核发送抢占信号时，会将当前线程正在执行的指令地址（即被抢占G的rip）保存到ucontext_t的uc_mcontext.gregs[REG_RIP]中；
• sigtramp读取该rip值作为newpc，通过ctxt.pushCall将其设置为asyncPreempt调用后的返回地址，压入被抢占G的栈帧；
• 当G恢复执行时，asyncPreempt完成调度逻辑后，会自动跳回newpc，继续执行被中断前的代码。

内容的提问来源于stack exchange，提问作者toozyfuzzy