Remove regbnd and vec_disp8

	* config/tc-i386.c (regbnd): Removed.
	(vec_disp8): Likewise.
[remote/gdbserver] Don't lose signals when reconnecting.

Currently, when GDB connects in all-stop mode, GDBserver always
responds to the status packet with a GDB_SIGNAL_TRAP, even if the
program is actually stopped for some other signal.

 (gdb) tar rem ...
 ...
 (gdb) c
 Program received signal SIGUSR1, User defined signal 1.
 (gdb) disconnect
 (gdb) tar rem ...
 (gdb) c

(Or a GDB crash instead of an explicit disconnect.)

This results in the program losing that signal on that last continue,
because gdb will tell the target to resume with no signal (to suppress
the GDB_SIGNAL_TRAP, due to 'handle SISGTRAP nopass'), and that will
actually suppress the real signal the program had stopped for
(SIGUSR1).  To fix that, I think we should make GDBserver report the
real signal the thread had stopped for in response to the status
packet:

 @item ?
 @cindex @samp{?} packet
 Indicate the reason the target halted.  The reply is the same as for
 step and continue.

But, that raises the question -- which thread are we reporting the
status for?  Due to how the RSP in all-stop works, we can only report
one status.  The status packet's response is a stop reply packet, so
it includes the thread identifier, so it's not a problem packet-wise.
However, GDBserver is currently always reporting the status for first
thread in the thread list, even though that may well not be the thread
that got the signal that caused the program to stop.  So the next
logical step would be to report the status for the
last_ptid/last_status thread (the last event reported to gdb), if it's
still around; and if not, fallback to some other thread.

There's an issue on the GDB side with that, though...

GDB currently always adds the thread reported in response to the
status query as the first thread in its list.  That means that if we
start with e.g.,

 (gdb) info threads
   3 Thread 1003 ...
 * 2 Thread 1002 ...
   1 Thread 1001 ...

And reconnect:

 (gdb) disconnect
 (gdb) tar rem ...

We end up with:

 (gdb) info threads
   3 Thread 1003 ...
   2 Thread 1001 ...
 * 1 Thread 1002 ...

Not a real big issue, but it's reasonably fixable, by having GDB
fetch/sync the thread list before fetching the status/'?', and then
using the status to select the right thread as current on the GDB
side.  Holes in the thread numbers are squashed before/after
reconnection (e.g., 2,3,5 becomes 1,2,3), but the order is preserved,
which I think is both good, and good enough.

However (yes, there's more...), the previous GDB that was connected
might have had gdbserver running in non-stop mode, or could have left
gdbserver doing disconnected tracing (which also forces non-stop), and
if the new gdb/connection is in all-stop mode, we can end up with more
than one thread with a signal to report back to gdb.  As we can only
report one thread/status (in the all-stop RSP variant; the non-stop
variant doesn't have this issue), we get to do what we do at every
other place we have this situation -- leave events we can't report
right now as pending, so that the next resume picks them up.

Note all this ammounts to a QoI change, within the existing framework.
There's really no RSP change here.

The only user visible change (other than that the signal is program is
stopped at isn't lost / is passed to the program), is in "info
program", that now can show the signal the program stopped for.  Of
course, the next resume will respect the pass/nopass setting for the
signal in question.  It'd be reasonable to have the initial connection
tell the user the program was stopped with a signal, similar to when
we load a core to debug, but I'm leaving that out for a future change.
I think we'll need to either change how handle_inferior_event & co
handle stop_soon, or maybe bypass them completely (like
fork-child.c:startup_inferior) for that.

Tested on x86_64 Fedora 17.

gdb/gdbserver/
2014-01-08  Pedro Alves  <palves@redhat.com>

	* gdbthread.h (struct thread_info) <status_pending_p>: New field.
	* server.c (visit_actioned_threads, handle_pending_status): New
	function.
	(handle_v_cont): Factor out parts to ...
	(resume): ... this new function.  If in all-stop, and a thread
	being resumed has a pending status, report it without actually
	resuming.
	(myresume): Adjust to use the new 'resume' function.
	(clear_pending_status_callback, set_pending_status_callback)
	(find_status_pending_thread_callback): New functions.
	(handle_status): Handle the case of multiple threads having
	interesting statuses to report.  Report threads' real last signal
	instead of always reporting GDB_SIGNAL_TRAP.  Look for a thread
	with an interesting thread to report the status for, instead of
	always reporting the status of the first thread.

gdb/
2014-01-08  Pedro Alves  <palves@redhat.com>

	* remote.c (remote_add_thread): Add threads silently if starting
	up.
	(remote_notice_new_inferior): If in all-stop, and starting up,
	don't call notice_new_inferior.
	(get_current_thread): New function, factored out from ...
	(add_current_inferior_and_thread): ... this.  Adjust.
	(remote_start_remote) <all-stop>: Fetch the thread list.  If we
	found any thread, then select the remote's current thread as GDB's
	current thread too.

gdb/testsuite/
2014-01-08  Pedro Alves  <palves@redhat.com>

	* gdb.threads/reconnect-signal.c: New file.
	* gdb.threads/reconnect-signal.exp: New file.
GDBserver: Discard previous queued events when GDB disconnects.

... not when a new GDB connection sends the status packet ('?').
Mainly just a cleanup/simplification, as GDB always sends '?' first.

Tested on x86_64 Fedora 17.

2014-01-08  Pedro Alves  <palves@redhat.com>

	* server.c (handle_status): Don't discard previous queued stop
	replies or thread's pending status here.
	(main) <disconnection>: Do it here instead.
daily update
Use table jump macros in coff-rs6000 targets.

bfd/
2014-01-09  Tristan Gingold  <gingold@adacore.com>

	* coff-rs6000.c (rs6000coff_vec, pmac_xcoff_vec): use jump
	table macros and add macros to initializa the structure.
Add and use check_lto_shared_available

2014-01-09  Vidya Praveen  <vidyapraveen@arm.com>

	* lib/ld-lib.exp (check_lto_shared_available): New check.
	* ld-plugin/lto.exp: Use check_lto_shared_available.
remove include/gdbm.h

include/gdbm.h is a relic.

2014-01-09  Tom Tromey  <tromey@redhat.com>

	* gdbm.h: Remove.
Check if GNU_RELRO segment is is generated

Fail if GNU_RELRO segment isn't generated, but should.

	* ld-elf/binutils.exp (binutils_test): Check if GNU_RELRO segment
	is generated.
Fix copyright year
Handle the case of a remote target supporting target side commands, but not on software breakpoints.

Although we can tell upfront whether a remote target supports target
side commands, we can only tell whether the target supports that in
combination with a given breakpoint kind (software, hardware,
watchpoints, etc.) when we go and try to insert such a breakpoint kind
the first time.  It's not desirable to make remote_insert_breakpoint
simply return -1 in this case, because if the breakpoint was set in a
shared library, insert_bp_location will assume that the breakpoint
insertion failed because the library wasn't mapped in.

insert_bp_location already handles errors/exceptions thrown from the
target_insert_xxx methods, exactly so the backend can tell the user
the detailed reason the insertion of hw breakpoints failed.  But, in
the case of software breakpoints, it discards the detailed error
message.

So the patch makes insert_bp_location use the error's message for SW
breakpoints too, and, introduces a NOT_SUPPORTED_ERROR error code so
that insert_bp_location doesn't confuse the error for failure due to a
shared library disappearing.

The result is:

(gdb) c
Warning:
Cannot insert breakpoint 2: Target doesn't support breakpoints that have target side commands.

2014-01-09  Pedro Alves  <palves@redhat.com>
	    Hui Zhu  <hui@codesourcery.com>

	PR gdb/16101
	* breakpoint.c (insert_bp_location): Rename hw_bp_err_string to
	bp_err_string.  Don't mark the location shlib_disabled if the
	error thrown wasn't a generic or memory error.  Catch errors
	thrown while inserting breakpoints in overlayed code.  Output
	error message of software breakpoints.
	* remote.c (remote_insert_breakpoint): If this breakpoint has
	target-side commands but this stub doesn't support Z0 packets,
	throw NOT_SUPPORTED_ERROR error.
	* exceptions.h (enum errors) <NOT_SUPPORTED_ERROR>: New error.
	* target.h (target_insert_breakpoint): Extend comment.
	(target_insert_hw_breakpoint): Add comment.
Fix buffer underrun in i386-dis.c.

opcodes/
	* i386-dis.c (print_insn): Do not touch all_prefixes[-1] when
	last_rex_prefix is -1.
gdb.mi/mi-info-os.exp: Fix cross-debugger testing

A live target is required for `-info-os' to work in non-native
configurations.

 (gdb)
 Expecting: ^(-info-os[
 ]+)?(.*\^done,OSDataTable=.*[
 ]+[(]gdb[)]
 [ ]*)
 -info-os
 ^error,msg="Don't know how to get OS data.  Try \"help target\"."
 (gdb)
 FAIL: gdb.mi/mi-info-os.exp: -info-os

If GDB does have a native configuration included, but we're testing
remote, it'll be worse, as if we're not connected yet, -info-os will
run against the default run target, and pass, falsely giving the
impression the remote bits were exercised.

gdb/testsuite/
2014-01-09  Maciej W. Rozycki  <macro@codesourcery.com>
	    Pedro Alves  <palves@redhat.com>

	* gdb.mi/mi-info-os.exp: Connect to the target with
        mi_gdb_target_load.
daily update
	* emulparams/crislinux.sh (COMMONPAGESIZE): Define.
Remove path from gdb.python/py-pp-integral.exp "source" test.

gdb/testsuite/ChangeLog:

	* gdb.python/py-pp-integral.exp: Remove path from "source" test.
Remove path from gdb.ada/pp-rec-component.exp "source" test

gdb/testsuite/ChangeLog:

	* gdb.ada/pp-rec-component.exp: Remove path from "source" test.
Don't adjust LOAD segment to match GNU_RELRO segment

Instead, fix Jakub's original code setting up the PR_GNU_RELRO header
from the PT_LOAD header.

	PR ld/14207
	PR ld/16322
	PR binutils/16323
bfd/
	* elf.c (assign_file_positions_for_load_sections): Revert last change.
	(assign_file_positions_for_non_load_sections): When setting up
	PT_GNU_RELRO header, don't require a corresponding PT_LOAD
	header that completely covers the relro region.
ld/
	* ldlang.c (lang_size_sections): Remove unneeded RELRO base
	adjust.  Tidy comments.
	* ld.texinfo (DATA_SEGMENT_RELRO_END): Correct description.
ld/testsuite/
	* ld-x86-64/pr14207.d: Adjust
Since upstream gcc has recently increased the function alignment on
S390, the dw2-dir-file-name test case fails in the first
gdb_continue_to_breakpoint.  Indeed, the breakpoint is now placed into
the alignment gap *before* the actual function.

This happens because the test case declares the respective "*_start"
symbol as a "loose" label before the function definition, and the
compiler inserts the alignment between that label and the function
itself.

The "*_start" symbols were only necessary because FUNC made the
function static.  The fix makes the functions extern instead, thus
making the "*_start" labels unnecessary.

testsuite/
2014-01-10  Andreas Arnez  <arnez@linux.vnet.ibm.com>
	    Pedro Alves <palves@redhat.com>

	* gdb.dwarf2/dw2-dir-file-name.c (FUNC): Remove "*_start" symbol.
	Make "name" extern.
	* gdb.dwarf2/dw2-dir-file-name.exp (out_cu, out_line): Replace
	references to ${name}_start by references to ${name}.
[doc] Mention that "set environment" affects the shell too.

gdb/doc/
2014-01-10  Pedro Alves  <palves@redhat.com>

	* gdb.texinfo (Your Program's Environment) <set environment>:
	Mention the shell, and point at 'set exec-wrapper'.
Merge remote-tracking branch 'origin/master' into hjl/linux/master