• Locked Locked
  • Replies 2 replies
  • Subscribers 119 subscribers
  • Views 2585 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Acknowledge exception handler in Linux

Michele Portolan
Parents
  • Arm Employee Badge
    Note: This was originally posted on 2nd April 2012 at http://forums.arm.com

    I'm afraid that I'm not a Linux expert, but I have a theory.

    The standard return sequence for an Undef exception puts the pc back to the instruction which triggered the Undef.  This would lead to the instruction being re-executed.

    This may sounds odd, but fits the use case for Undefs pretty well.  The common scenarios are:
    * Instruction that the task will never be able to execute (e.g. due to priviledge restrictions) - kill task
    * VFP/NEON instruction when VFP/NEON disabled - turn on VFP/NEON

    So you usually either want to re-execute the instruction or kill the task.
Reply
  • Arm Employee Badge
    Note: This was originally posted on 2nd April 2012 at http://forums.arm.com

    I'm afraid that I'm not a Linux expert, but I have a theory.

    The standard return sequence for an Undef exception puts the pc back to the instruction which triggered the Undef.  This would lead to the instruction being re-executed.

    This may sounds odd, but fits the use case for Undefs pretty well.  The common scenarios are:
    * Instruction that the task will never be able to execute (e.g. due to priviledge restrictions) - kill task
    * VFP/NEON instruction when VFP/NEON disabled - turn on VFP/NEON

    So you usually either want to re-execute the instruction or kill the task.
Children
No data