Arc: Fix changing of PC while in delay slot

In ARC PC register is a normal register so in most cases setting PC value is a
straightforward process: debugger just writes PC value. However it gets
trickier in case when current instruction is an instruction in delay slot. In
this case CPU will execute instruction at current PC value, then will set PC to
the current value of BTA register; also current instruction cannot be
branch/jump and some of the other instruction types. Thus if debugger would try
to just change PC value in this case, this instruction will get executed, but
then core will "jump" to the original branch target.

ARC provides following means to resolve this problem: - BTA register contains
address where core should jump after executing instruction in delay slot - Bit
DE in STATUS32 register indicates if current instruction is a delay slot
instruction. This bit is writable by debug host, which allows debug host to
prevent core from jumping after the delay slot instruction. At also works in
another directions: setting this bit will make core to treat any current
instructions as a delay slot instruction and to set PC to the current value of
BTA register.

To workaround issues with changing PC register while in delay slot instruction,
debugger should check for the STATUS32.DE bit and reset it if it is set. No
other change is required in this function. Most common case where this function
might be required is calling inferior functions from debugger.  Generic GDB
logic handles this pretty well: current values of registers are stored, value
of PC is changed (that is the job of this function), after inferior function is
executed, GDB restores all registers, which also means that core is returned to
its original state of being halted on delay slot instructions.

This method is useless for ARC 600, because it doesn't have externally exposed
BTA register. In the case of ARC 600 it is impossible to restore core to it's
state in all occasions thus core should never be halted (from the perspective
of debugger host) in the delay slot.

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
Arc: Add helper functions to check for target architecture

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
Arc: Write SW breakpoints of the same length as replaced instruction

In case of baremetal targets it is possible to set software breakpoint to
the delay slot instructions in the form of BRK_S instructions, which doesn't
commit unlike TRAP_S used in user-space debugger.  So CPU is halted in the
state before delay slot execution: STATUS32.DE is 1, BTA is set, BLINK is
set. Then to resume execution generic GDB logic makes a single instruction
step to execute instruction which really should be in the delay slot, then
writes BRK_S back into memory and resumes execution. However there is a case
when this doesn't work that out well. The problem is that we always use
2-byte long BRK_S instruction as a breakpoint to replace both 2-byte and
4-byte instructions in code. In most cases that doesn't have any issues,
because PC is not advanced by BRK_S, so it doesn't matter which one is used,
therefore we use the shortest one as it always works and keep GDB simple.
However the problem happens with link branches with delay slot. BL.D/JL.D
instructions set value of BLINK register to the address of instruction after
the delay slot, but they do this before BRK_S is executed, so if there is
BRK_S in delay slot, then BLINK is set to +2 byte offset, however if
original instruction in delay slot was 4-byte one, than BLINK should be set
with +4 offset. BLINK will be pointed to the wrong address as the result.
To resolve this GDB should be made more intelligent: before setting software
breakpoint it should disassemble current instruction, and set breakpoint of
the same length as the instruction being replaced. Thus BLINK value will be
consistent in all cases.

ARC 600 doesn't implement BRK instruction thus this patch doesn't apply to
it.

Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>