arc: Fix invalid decr_pc_after_break value

This patch fixes a rare-case bug, where PC value gets decremented by two
bytes, when breakpoint has been set at the instruction which is a target of
branching.

Value of gdbarch_decr_pc_after_break has been 2 for a long time to mark the fact
that on ARC instructions of software breakpoint commit, thus PC value must
be decremented by 2 bytes (size of software breakpoint instruction) to get a
real location of breakpoint.

This assumption however is false.
1. In case of baremetal applications BRK_S instruction is used, which do not
commit. Thus decrementing PC is not required.
2. Since recent times baremetal GDB started to use 4-byte breakpoints to
overwrite 4-byte instructions. Thus making this decr_pc_after_break value
invalid as well.
3. In case of Linux applications debugging, whiel it is true that
instruction TRAP_S commits, thus PC must be reduced, that shouldn't be done
in GDB.  Kernel already handles this, so STOP_PC pseudo register already
contains decremented PC. Also kernel doesn't decrease PC arithmetically,
instead it uses EFA value.

It is curios why we haven't noted this problem before, because it seems that
if GDB always decreases PC by two bytes when it's not needed, than it would
cause a lot of obvious error. As it happens GDB doesn't simply decrease PC
value. Instead of it computes decreased value and checks whether it inserted
breakpoint at this address, if it is not then it was silently (!!!)
ignoring this and moved on. So for this trigger there should have been two
software breakpoints at adjacent locations. Another condition for this issue
to trigger is that GDB must not be stepping application. This means that
after GDB hits first breakpoint, when it resumes it must step once, so it
will execute original instruction at this address, then it will resume as
is. Which means that in case of two adjacent breakpoints, second is never
hit in a "free-running" mode. The only case where this error might be
observed is if second breakpoint is the target of branch instruction and the
first one has size of 2 bytes. In this case GDB will hit second breakpoint,
then it will really decrease PC value by two bytes. For example:

.global __start
.align 4
__start:
    bl.d @.L2
    xor_s r0, r0, r0
.L1:
    mov_s r1, r0
.L2:
    mov_s r2, r0

In this case if breakpoint is set at both @.L1 and @.L2, then bl.d will jump
to @.L2, execution will jalt at breakpoint, GDB will decrease PC by 2 bytes,
then it will find a valid breakpoint @.L1 and will set PC value to (PC-2).
Meaning that instruction at @.L1 will be executed, while it shouldn't.

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

Add implementation of function ps_get_thread_area. This function is
required to debug multithreaded applications with NPTL.

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