• State Accepted Answer
  • Locked Locked
  • Replies 8 replies
  • Subscribers 349 subscribers
  • Views 7554 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

UPREDICTABLE instructions

Juha Aaltonen

Any idea about instructions marked as UNPREDICTABLE: can it then be UNDEFINED?

In other words: UNDEFINED REQUIRES the instruction to cause UND-exception, but

MAY UNPREDICTABLE do that, or does it have to execute normally except that the result may be whatever?

(I'm not yelling even if I used caps.)

I did as that same thing there Re: ARM/THUMB instructions that change execution path?

but I don't seem to get any answers. And this is probably more appropriate space anyway.

Parents
  • 0 Arm Employee Badge in reply to Juha Aaltonen
    You can't guarantee it'll be UNDEFINED - all you can do is present something to state that stepping into that instruction may have an UNPREDICTABLE effect.

    If you are writing a debug monitor then you have control over the Undef handler, surely? If it's external debug then you can use Vector Catch, if not then it's the debug monitor's responsibility (by design) to handle any exceptions caused by debug events. You should already have good reason to be hooked in to that handler otherwise you couldn't handle a breakpoint instruction..


Reply
  • 0 Arm Employee Badge in reply to Juha Aaltonen
    You can't guarantee it'll be UNDEFINED - all you can do is present something to state that stepping into that instruction may have an UNPREDICTABLE effect.

    If you are writing a debug monitor then you have control over the Undef handler, surely? If it's external debug then you can use Vector Catch, if not then it's the debug monitor's responsibility (by design) to handle any exceptions caused by debug events. You should already have good reason to be hooked in to that handler otherwise you couldn't handle a breakpoint instruction..


Children
  • 0 in reply to Matt Sealey

    I think, for now I'll settle with this:

    #ifdef INSTR_ALLOW_UNPREDS

    #define INSTR_ADDR_IMPL_DEP(x) (x )

    #else

    #define INSTR_ADDR_IMPL_DEP(x) INSTR_ADDR_UNPRED

    #endif

    Later I could change the new address into a flag-address pair.

    Then the main program gets the address, but also knows to inform the user about unpredictable step.

    I'm using BKPT and supervisor mode, so the debug exception should be PABT.

    As my first ARM-project, the debug mode (not to mention the debug co-processor) seems too complicated especially now that I don't have any hardware for debugging the target (bare metal, no jtag/j-link/st-link,...).

    That's why the previous weird questions. ;-)

  • 0 Arm Employee Badge in reply to Juha Aaltonen

    Aha :)


    BKPT only exists ARMv5 and above so debuggers that attempt to support older architectures instead use a known unallocated encoding to trap instructions as Undef. If you're only concerned about newer cores then maybe you can get away with it - that said if you're arguing that you can handle an abort exception then handling Undef shouldn't be too big a pain.

  • 0 in reply to Matt Sealey

    There's a vector and banked regs set up already. The idea is to catch most exceptions.

    I'm writing it specifically to my Raspberry Pi 2B (but I hope it'll work on the other RPi-versions too).

    This is my private "blinky"-project, except that it doesn't blink a LED.

    (Isn't that usually the first ever program on new HW?)

    The SW I'm trying to put together is some kind of standalone gdb-stub (with included serial I/O).

    It should be able to load a program via the serial line and debug it.

    At the moment only single core is supported.