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.
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.
My purpose was to figure out how to handle single stepping when UNPREDICTBLE instruction is encountered.
I must treat it as UNDEFINED (refuse to step), or the code may run away.
Thanks for the more detailed explanation.
Hi turboscrew,
When most debuggers encounter an UNPREDICTABLE instruction during stepping.. they step into it. You wouldn't want to change the behaviour of the code any more than the debugger already does modify the state of the system.
It would be extremely useful to warn a user that the next instruction has potentially UNPREDICTABLE behaviours (or is deprecated for some reason) but there's not a lot you can do.
Ta,
Matt
But if the UNPREDICTABLE happens to be UNDEFINED, it'll cause an exception in the middle of single step.
Hmm...
I was wrestling with myself with this...
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..
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. ;-)
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.
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.