Linux：窥探信号而不会破坏后续核心转储的寄存器？

概述当我得到coredump-cause信号时,我想运行自己的处理程序将siginfo_t和ucontext_t结构复制到全局变量,以便可以在核心转储中访问它们.目前在我的处理程序结束时,我重新分配默认处理程序并调用raise(thesig).这样做的问题是核心转储“信息寄存器”显示了我的处理程序中寄存器的状态,而不是原始信号时的状态.我意识到,因为我已经保存了ucontext_t,我可以查看原始寄存 当我得到coredump-cause信号时,我想运行自己的处理程序将siginfo_t和ucontext_t结构复制到全局变量,以便可以在核心转储中访问它们.目前在我的处理程序结束时,我重新分配默认处理程序并调用raise(thesig).这样做的问题是核心转储“信息寄存器”显示了我的处理程序中寄存器的状态,而不是原始信号时的状态.我意识到,因为我已经保存了ucontext_t,我可以查看原始寄存器值,但是当核心转储在团队中传递时,这些知识可能会丢失/遗忘.

所以我的问题是：有没有办法重新加载信号,并确保核心转储文件保持原始信号的寄存器状态？我想也许我可以使用一些内联asm来手动恢复处理程序末尾的所有reg,然后返回到导致信号的指令而不是调用raise(),但我不确定我们是否可以保证重新 – 尝试该指令将导致与第一次尝试相同的信令行为.

解决方法

copy the siginfo_t and ucontext_t structures to global variables,so that they may be accessed in the core dump

如果您在处理程序中重新提升信号,则无需复制任何内容 – 值将在堆栈中并可在核心转储中访问.

“info registers” shows the state of the registers in my handler,and not at the time of the original signal.

只需要做5(或者你需要升级以达到崩溃点的多个级别)和再次信息reg.

is there a way to reraise a signal,and ensure the core dump file holds the register state of the original signal?

是：使用信号(signum,SIG_DFL)将信号处置设置为SIG_DFL;并从你的处理程序返回.导致SIGSEGV的指令将重新启动,现在将立即导致核心转储.

总结

以上是内存溢出为你收集整理的Linux：窥探信号而不会破坏后续核心转储的寄存器？全部内容，希望文章能够帮你解决Linux：窥探信号而不会破坏后续核心转储的寄存器？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。