1

I have an exception handler for an arm32 bit system running Linux. When the exception occurs, I'd like to do some analysis, and optionally change the PC and some other registers when the exception returns. I thought it would be easy to find information on how to properly do this online, but I've not found anything as of yet.

I can get the registers at the time of the exception from the ucontext_t * parameter, and I thought I would be able to simply modify this to effect the return state, however, I found this, which suggests that I cannot do that. I'm wondering if there is a proper way to do this?

Just to clarify -- I want the signal handler to adjust the PC and registers of the thread that was running when the exception occured, such that when the thread resumes, it resumes with a slightly different state.

HardcoreHenry
  • 5,909
  • 2
  • 19
  • 44
  • Do you mean an *exception* handler (directly handles hardware exceptions, invoked by hardware, would be privileged code in the kernel), or a *signal* handler (part of a userspace program, installed by `signal` or `sigaction`, delivered by the kernel in response to hardware exception or `kill()`)? – Nate Eldredge Jun 02 '21 at 14:41
  • The linked question seems to be doing something different - their `setcontext` would actually jump out of the signal handler. That's not the same as modifying registers and returning. – Nate Eldredge Jun 02 '21 at 14:47
  • Use assembly or intrinsic APIs to change the registers that you want. You can't change the PC though (it'll cause a jump), but you can't change LR (the return address), if needed. – hesham_EE Jun 02 '21 at 15:39
  • Sorry, yes it would be a signal handler. Depending on the instructions at the thread's PC, I may want to either return to that instruction, or do some work, and advance to the next instruction, and perform a simulated version of the previous instruction (which would include updating several registers). – HardcoreHenry Jun 02 '21 at 18:02
  • which core/architecture are you talking about arm32 doesnt mean a whole lot. as far as the arm goes that is all documented. but as far as the operating system goes it is operating system specific, so you will need to work it from that angle as well. and of course which linux kernel, etc, etc...which is of course open source. with already implemented handlers to examine. – old_timer Jun 02 '21 at 22:32
  • there is more than one proper way to do it in general, but specific to your needs there may be only one. – old_timer Jun 02 '21 at 22:33
  • So this would be running an armv7a instruction set (optionally, the thread being interrupted might be running in thumb mode). I'd like this to work on varying linux kernels ( >= 2.34 ) – HardcoreHenry Jun 03 '21 at 12:48

0 Answers0