For non-profiling kernels, there were two symbols assigned to the same
address. One was alltraps_with_regs_pushed, the other was calltrap. When the stack tracer walks up, it looks for magic symbol names to determine how to parse non-standard stack frames, such as a trapframe. It was looking for "calltrap". Which of the two symbols you got depended on things like Phase of moon, etc. If you were unlucky, you got a garbage stack trace for things like 'debug.trace_on_panic', which would completely hide the actual source of the problem.
This commit is contained in:
parent
4f39f90f5f
commit
c592ba5f3f
@ -165,8 +165,9 @@ alltraps_pushregs_no_rdi:
|
||||
movq %r13,TF_R13(%rsp)
|
||||
movq %r14,TF_R14(%rsp)
|
||||
movq %r15,TF_R15(%rsp)
|
||||
alltraps_with_regs_pushed:
|
||||
FAKE_MCOUNT(TF_RIP(%rsp))
|
||||
.globl calltrap
|
||||
.type calltrap,@function
|
||||
calltrap:
|
||||
call trap
|
||||
MEXITCOUNT
|
||||
@ -434,4 +435,5 @@ doreti_iret_fault:
|
||||
movq %r15,TF_R15(%rsp)
|
||||
movq $T_PROTFLT,TF_TRAPNO(%rsp)
|
||||
movq $0,TF_ERR(%rsp) /* XXX should be the error code */
|
||||
jmp alltraps_with_regs_pushed
|
||||
FAKE_MCOUNT(TF_RIP(%rsp))
|
||||
jmp calltrap
|
||||
|
Loading…
Reference in New Issue
Block a user