Fix 'call8: call target out of range' xtensa ld relaxation bug

During link-time relaxation distance between cross-section call site and
its target may grow, producing 'call target out of range' error for
relaxed calls. Be more conservative when calculating whether or not a
callx can be converted to a straight call.

2014-09-23  Sterling Augustine  <augustine.sterling@gmail.com>

bfd/
    * elf32-xtensa.c (is_resolvable_asm_expansion): for cross-section
    call relaxation use furthermost addresses where call source and
    destination can be to check whether it's in the range of a direct
    call.
daily update
Honour SIGILL and SIGSEGV in cancel breakpoint and event lwp selection

I see the following fail on arm-none-linux-gnueabi testing,

(gdb) continue^M
Continuing.^M
^M
Program received signal SIGILL, Illegal instruction.^M
[Switching to Thread 1003]^M
handler (signo=10) at
/scratch/yqi/arm-none-linux-gnueabi/src/gdb-trunk/gdb/testsuite/gdb.threads/sigstep-threads.c:33^M
33        tgkill (getpid (), gettid (), SIGUSR1);       /* step-2 */^M
(gdb) FAIL: gdb.threads/sigstep-threads.exp: continue

the cause is that GDBserver doesn't cancel the breakpoint if the stop
signal is SIGILL.  The kernel used here is a little old, 2.6.x, and
doesn't translate SIGILL to SIGTRAP when program hits breakpoint
instruction (which is an illegal instruction actually).  GDB and
GDBserver can translate SIGILL to SIGTRAP under certain circumstance,
so it is not a problem here.  See gdbserver/linux-low.c:linux_wait_1

  /* If this event was not handled before, and is not a SIGTRAP, we
     report it.  SIGILL and SIGSEGV are also treated as traps in case
     a breakpoint is inserted at the current PC.  If this target does
     not support internal breakpoints at all, we also report the
     SIGTRAP without further processing; it's of no concern to us.  */
  maybe_internal_trap
    = (supports_breakpoints ()
       && (WSTOPSIG (w) == SIGTRAP
	   || ((WSTOPSIG (w) == SIGILL
		|| WSTOPSIG (w) == SIGSEGV)
	       && (*the_low_target.breakpoint_at) (event_child->stop_pc))));

However, SIGILL and SIGSEGV is not considered when cancelling
breakpoint, which causes the fail above.  That is, when GDB is doing
software single step on address ADDR, both thread A and thread B hits the
software single step breakpoint, and get SIGILL.  GDB selects the event
from thread A, removes the software single step breakpoint, and resume
the program.  The event (SIGILL) from thread B is reported to GDB, but
GDB doesn't regard this SIGILL as SIGTRAP, because the breakpoint on
address ADDR was removed, so GDB reports "Program received signal
SIGILL".

The patch is to allow calling cancel_breakpoint if the signal is
SIGILL and SIGSEGV.  This patch fixes the fail above.  Likewise, event
lwp selection should honour SIGILL and SIGSEGV too.

gdb/gdbserver:

2014-09-23  Yao Qi  <yao@codesourcery.com>

	* linux-low.c (lp_status_maybe_breakpoint): New function.
	(linux_low_filter_event): Call lp_status_maybe_breakpoint.
	(count_events_callback): Likewise.
	(select_event_lwp_callback): Likewise.
	(cancel_breakpoints_callback): Likewise.