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.