MIPS/LD/testsuite: Correct comm-data.exp test ABI/emul/endian arrangement

Update the ld-mips-elf/comm-data.exp test script to correctly select
emulations for targets using non-traditional MIPS emulation and also
correctly select ABIs for targets that do not support all of them, and
finally use the default endianness selection to benefit targets which
support only one, complementing commit 05a5feafdd38 ("Rewrite
check_shared_lib_support") and removing numerous test failures such as:

FAIL: MIPS o32/copyreloc common symbol override test (auxiliary shared object build)
FAIL: MIPS o32/copyreloc common symbol override test
FAIL: MIPS o32/nocopyreloc common symbol override test (auxiliary shared objectbuild)
FAIL: MIPS o32/nocopyreloc common symbol override test
FAIL: MIPS n32/copyreloc common symbol override test (auxiliary shared object build)
FAIL: MIPS n32/copyreloc common symbol override test
FAIL: MIPS n32/nocopyreloc common symbol override test (auxiliary shared objectbuild)
FAIL: MIPS n32/nocopyreloc common symbol override test

due to:

.../ld/ld-new: unrecognised emulation mode: elf32btsmip
Supported emulations: elf64btsmip elf64ltsmip

or:

.../ld/ld-new: unrecognised emulation mode: elf32btsmip
Supported emulations: elf32ebmip

or:

.../ld/ld-new: unrecognised emulation mode: elf32btsmip
Supported emulations: elf32l4300

etc., and:

ERROR: -n32 -march=mips3 -EB -call_shared .../ld/testsuite/ld-mips-elf/../ld-elf/comm-data1.s: assembly failed
UNRESOLVED: MIPS n32/copyreloc common symbol override test (auxiliary shared object build)
ERROR: -n32 -march=mips3 -EB -call_nonpic .../ld/testsuite/ld-mips-elf/../ld-elf/comm-data2.s: assembly failed
UNRESOLVED: MIPS n32/copyreloc common symbol override test
ERROR: -n32 -march=mips3 -EB -call_shared .../ld/testsuite/ld-mips-elf/../ld-elf/comm-data1.s: assembly failed
UNRESOLVED: MIPS n32/nocopyreloc common symbol override test (auxiliary shared object build)
ERROR: -n32 -march=mips3 -EB -call_nonpic .../ld/testsuite/ld-mips-elf/../ld-elf/comm-data2.s: assembly failed
UNRESOLVED: MIPS n32/nocopyreloc common symbol override test

due to:

Assembler messages:
Fatal error: selected target format 'elf32-nbigmips' unknown

and:

ERROR: -64 -march=mips3 -EB -call_shared .../ld/testsuite/ld-mips-elf/../ld-elf/comm-data1.s: assembly failed
UNRESOLVED: MIPS n64/copyreloc common symbol override test (auxiliary shared object build)
ERROR: -64 -march=mips3 -EB --defsym ELF64=1 -call_nonpic .../ld/testsuite/ld-mips-elf/../ld-elf/comm-data2.s:assembly failed
UNRESOLVED: MIPS n64/copyreloc common symbol override test
ERROR: -64 -march=mips3 -EB -call_shared .../ld/testsuite/ld-mips-elf/../ld-elf/comm-data1.s: assembly failed
UNRESOLVED: MIPS n64/nocopyreloc common symbol override test (auxiliary shared object build)
ERROR: -64 -march=mips3 -EB --defsym ELF64=1 -call_nonpic .../ld/testsuite/ld-mips-elf/../ld-elf/comm-data2.s:assembly failed
UNRESOLVED: MIPS n64/nocopyreloc common symbol override test

due to:

Assembler messages:
Fatal error: no compiled in support for 64 bit object file format

ld/
* testsuite/ld-mips-elf/comm-data.exp: Correct support for
targets using non-traditional MIPS emulation or having a limited
selection of ABIs available.  Don't force big endianness, use
defaults.

Don't call "detach_inferior" on "remote_follow_fork"

This patch fixes a regression that has been introduced by:

  commit bc09b0c14fb713a9aec25e09b78499f3bc2441b5
  Date:   Fri Jan 19 11:48:11 2018 -0500

      Make linux_nat_detach/thread_db_detach use the inferior parameter

It is possible to trigger this failure with gdb.base/foll-fork.exp (in
which case a bunch of ERROR's will be printed), but one can also use
the test below.

Consider the following example program:

  #include <unistd.h>

  int
  main (int argc, char *argv[])
  {
    fork ();

    return 0;
  }

When running it under gdbserver:

  # ./gdb/gdbserver/gdbserver --multi --once :2345

And debugging it under GDB, we see a segmentation fault:

  # ./gdb/gdb -q -batch -ex 'set remote exec-file ./a.out' -ex 'tar extended-remote :2345' -ex r ./a.out
  Starting program:
  ...
  [Detaching after fork from child process 16102.]
  Segmentation fault (core dumped)

The problem happens on inferior.c:detach_inferior:

  void
  detach_inferior (inferior *inf)
  {
    /* Save the pid, since exit_inferior_1 will reset it.  */
    int pid = inf->pid;
              ^^^^^^^^^

    exit_inferior_1 (inf, 0);

    if (print_inferior_events)
      printf_unfiltered (_("[Inferior %d detached]\n"), pid);
  }

When this code is called from remote.c:remote_follow_fork, the PID is
valid but there is no 'inferior' associated with it, which means that
'inf == NULL'.

The proper fix here is to not call "detach_inferior" when doing remote
follow-fork, because we don't have an inferior to detach on the host
side.

Before bc09b0c1, that call was already a nop (exit_inferior_1 bails
out early if you pass it a NULL inferior), except that it printed
"Inferior PID detached" when "set print inferior-events" is on.  Since
native debugging doesn't call detach_inferior in this case, removing
the call from remote aligns remote debugging output with native
debugging output further.

This has been regtested using BuildBot and no regressions were found.

gdb/ChangeLog:
2018-01-29  Sergio Durigan Junior  <sergiodj@redhat.com>

* remote.c (remote_follow_fork): Don't call "detach_inferior".

Update Russian translation for the gas sub-directory

Prevent patch remnants from being included in release tarballs.

* src-release.sh (do_proto_toplev): Strip patch remnant files from
the sources before creating the tarball.

ld: Skip unsupported static executable tests

Skip static executable tests if static executable is unsupported.
Tested on Linux/x86 without libc.a.

PR ld/22732
* testsuite/config/default.exp (STATIC_LDFLAGS): New.  Set to
"-static" if target compiler supports it.
* testsuite/ld-bootstrap/bootstrap.exp: Skip static executable
tests if target compiler doesn't support it.
* testsuite/ld-ifunc/ifunc.exp: Likewise.
* testsuite/lib/ld-lib.exp (run_ld_link_exec_tests): Likewise.
(run_cc_link_tests): Likewise.

PR22741, objcopy segfault on fuzzed COFF object

PR 22741
* coffgen.c (coff_pointerize_aux): Ensure auxent tagndx is in
range before converting to a symbol table pointer.

Automatic date update in version.in

Remove dwarf2_per_objfile_free and use after free of dwarf2_per_objfile

I got some crashes while doing some work with dwarf2_per_objfile.  It
turns out that dwarf2_per_objfile_free is using the dwarf2_per_objfile
objects after their destructor has ran.

The easiest way to reproduce this is to run the inferior twice (do
"start" twice).  Currently, it goes unnoticed, but when I tried to
change all_comp_units and all_type_units to std::vectors, things started
crashing.

The dwarf2_per_objfile objects get destroyed here:

 #0  dwarf2_per_objfile::~dwarf2_per_objfile (this=0x35afe70, __in_chrg=<optimized out>) at /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:2422
 #1  0x0000000000833282 in dwarf2_free_objfile (objfile=0x356cff0) at /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:25363
 #2  0x0000000000699255 in elf_symfile_finish (objfile=0x356cff0) at /home/emaisin/src/binutils-gdb/gdb/elfread.c:1309
 #3  0x0000000000911ed3 in objfile::~objfile (this=0x356cff0, __in_chrg=<optimized out>) at /home/emaisin/src/binutils-gdb/gdb/objfiles.c:674

and just after that the dwarf2read per-objfile registry cleanup function
gets called:

 #0  dwarf2_per_objfile_free (objfile=0x356cff0, d=0x35afe70) at /home/emaisin/src/binutils-gdb/gdb/dwarf2read.c:25667
 ... registry boilerplate ...
 #4  0x00000000009103ea in objfile_free_data (container=0x356cff0) at /home/emaisin/src/binutils-gdb/gdb/objfiles.c:61
 #5  0x0000000000911ee2 in objfile::~objfile (this=0x356cff0, __in_chrg=<optimized out>) at /home/emaisin/src/binutils-gdb/gdb/objfiles.c:678

In dwarf2_per_objfile_free, we access fields of the dwarf2_per_objfile
object, which is invalid since its destructor has been executed.

This patch moves the content of dwarf2_per_objfile_free to the
destructor of dwarf2_per_objfile.  The call to
register_objfile_data_with_cleanup in _initialize_dwarf2_read can be
changed to the simpler register_objfile_data.

gdb/ChangeLog:

* dwarf2read.c (free_dwo_files): Add forward-declaration.
(dwarf2_per_objfile::~dwarf2_per_objfile): Move content from
dwarf2_per_objfile_free here.
(dwarf2_per_objfile_free): Remove.
(_initialize_dwarf2_read): Don't register
dwarf2_per_objfile_free as a registry cleanup.

Update release notes with a reminder to check the gpg key being used.

* README-how-to-make-a-release: Add note about checking gpg key
and the results of gnupload.

Add a testcase for PR ld/22751

Since dummy.o must be placed before

-Wl,--whole-archive tmpdir/pr22751.a -Wl,--no-whole-archive

to trigger the bug, this patch adds an optional trailing ld options to
run_ld_link_exec_tests.

PR ld/22751
* testsuite/config/default.exp (INT128_CFLAGS): New.
* testsuite/ld-plugin/lto.exp (INT128_CFLAGS): New.
Run ld/22751 tests.
* testsuite/ld-plugin/pr22751.c: New file.
* testsuite/lib/ld-lib.exp (run_ld_link_exec_tests): Add
ld trailing options.

Automatic date update in version.in

PR22751, LTO broken for libgcc libcalls

So what was happening was that the file added from libgcc.a during the
rescan was not put on file_chain.  map_input_to_output_sections then
doesn't see the file and its sections are treated as discarded.

The file_chain list pointer bug was caused by that fact that an
archive element claimed by the plugin does not have my_archive set.
Or more correctly, the actual archive element does have my_archive
set, but this bfd is replaced with a dummy bfd that doesn't have
my_archive set.

PR 22751
* ldlang.c (find_rescan_insertion): Look past bfds with claim_archive
set.

Update documentation on making a release

Avoid compilation errors in MinGW native builds of GDB

The error is triggered by including python-internal.h, and the
error message is:

     In file included from d:\usr\lib\gcc\mingw32\6.3.0\include\c++\math.h:36:0,
      from build-gnulib/import/math.h:27,
      from d:/usr/Python26/include/pyport.h:235,
      from d:/usr/Python26/include/Python.h:58,
      from python/python-internal.h:94,
      from python/py-arch.c:24:
     d:\usr\lib\gcc\mingw32\6.3.0\include\c++\cmath:1157:11: error: '::hypot' has not been declared
        using ::hypot;
        ^~~~~

This happens because Python headers define 'hypot' to expand to
'_hypot' in the Windows builds.

gdb/ChangeLog:
2018-01-27  Eli Zaretskii  <eliz@gnu.org>

* python/python-internal.h (_hypot) [__MINGW32__]: Define back to
'hypoth'.  This avoids a compilation error.

Avoid compilation warning in libiberty/simple-object-xcoff.c

gdb/ChangeLog:
2018-01-27  Eli Zaretskii  <eliz@gnu.org>

* simple-object-xcoff.c (simple_object_xcoff_find_sections): Avoid
compilation warning in 32-bit builds not supported by
AC_SYS_LARGEFILE.

Updated Russian translation for the bfd sub-directory

Automatic date update in version.in

MIPS/LD: Correct `mips-*-windiss' target emulation configuration

Fix an issue with commit 73934d319dae ("Disable .gnu.hash on MIPS
targets"), <https://sourceware.org/ml/binutils/2006-07/msg00341.html>,
which in turn caused a regression with commit 861fb55ab50a ("Defer
allocation of R_MIPS_REL32 GOT slots"),
<https://sourceware.org/ml/binutils/2008-08/msg00096.html>, and use
`mipself.em' as the extra emulation file for `mips-*-windiss' targets,
removing a segmentation fault triggered as `_bfd_mips_elf_final_link'
calls `htab_traverse' to process LA25 stubs with `htab->la25_stubs'
being NULL.  This is in turn due to `_bfd_mips_elf_init_stubs' not
having been called, which is only done by `mipself.em'.  No LA25 stubs
are supposed to be produced for `mips-*-windiss' targets, however the
internal data structures have to be initialized.

ld/
* emulparams/elf32mipswindiss.sh (EXTRA_EM_FILE): Set to
`mipself'.

MIPS/GAS: Correct `mips-*-windiss' target emulation configuration

Fix a commit 0a44bf6950b3 ("mips-vxworks support"),
<https://sourceware.org/ml/binutils/2006-03/msg00179.html>, regression
and override the choice of the `vxworks' target environment introduced
with commit ea3eed15006f ("Add generic vxworks GAS target."),
<https://sourceware.org/ml/binutils/2005-01/msg00052.html>, for
`mips-*-windiss' targets as they have not been converted to the VxWorks
target format introduced with the former commit, removing a GAS target
format selection failure:

Assembler messages:
Fatal error: selected target format 'elf32-bigmips-vxworks' unknown

on any assembly attempt with `mips-windiss' and equivalent target
configurations.

gas/
* configure.tgt: Use generic emulation for `mips-*-windiss',
overriding the blanket choice made for `*-*-windiss'.

MIPS/GAS: Correct `mips-*-sysv4*' target emulation configuration

Use `mips-*-sysv4*' rather than `mips-*-sysv4*MP*' to match the system
type for System V Release 4 MIPS targets, removing a GAS target
selection failure:

Assembler messages:
Fatal error: selected target format 'elf32-bigmips' unknown

on any assembly attempt with `mips-sysv4' and equivalent target
configurations.  These would typically be called `mips-sni-sysv4'
(Sinix) vs `mips-dde-sysv4.2MP' (Supermax).

This corrects commit 8614eeee67f9 ("Traditional MIPS patches"),
<https://sourceware.org/ml/binutils/2000-07/msg00018.html>, making GAS
target selection match commit dd745cfae548 ("Traditional MIPS patches"),
<https://sourceware.org/ml/binutils/2000-07/msg00018.html>, and commit
3548145dcbf6 ("Traditional MIPS patches"),
<https://sourceware.org/ml/binutils/2000-07/msg00018.html>, which added
support for these targets to BFD and LD respectively.

gas/
* configure.tgt: Use `mips-*-sysv4*' rather than
`mips-*-sysv4*MP*'.

Add myself as a write-after-approval GDB maintainer.

gdb/
    * MAINTAINERS (Write After Approval): Add Alan Hayward.

Add myself as a write-after-approval GDB maintainer.

gdb/
    * MAINTAINERS (Write After Approval): Add Alan Hayward.

Update notes on making a release

PowerPC PLT stub matching

This patch fixes a number of bugs in ppc32 plt stub matching code.
1) The 4-insn stubs for shared libs and PIEs weren't matched.
2) The executable stub miscalculated PLT entry address (by oring a
   sign-extended quantity rather than adding).
3) Comments were not accurate.

In addition, the insn arrays are made const.

* ppc-linux-tdep.c (powerpc32_plt_stub): Make const.
(powerpc32_plt_stub_so_1): Rename from powerpc32_plt_stub_so.
Remove nop.  Make const.  Comment.
(powerpc32_plt_stub_so_2): New.
(POWERPC32_PLT_CHECK_LEN): Rename from POWERPC32_PLT_STUB_LEN.
Correct count.  Update uses.
(ppc_skip_trampoline_code): Match powerpc32_plt_stub_so_2 too.
Move common code reading PLT entry word.  Correct
powerpc32_plt_stub PLT address calculation.
* ppc64-tdep.c (ppc64_standard_linkage1): Make const.
(ppc64_standard_linkage2, ppc64_standard_linkage3): Likewise.
(ppc64_standard_linkage4, ppc64_standard_linkage5): Likewise.
(ppc64_standard_linkage6, ppc64_standard_linkage7): Likewise.
(ppc64_standard_linkage8): Likewise.
* rs6000-tdep.c (ppc_insns_match_pattern): Make pattern const.
Correct insns description.
* ppc-tdep.h (ppc_insns_match_pattern): Update prototype.

Reviewed-By: Yao Qi <qiyaoltc@gmail.com>

Define __start/__stop symbols when there is only a dynamic def

This patch fixes a case where a user had a C-representable named
section in both the executable and shared libraries, and of course
wanted the size of the local section in the executable, not the
dynamic section.  It does mean that __start and __stop symbols don't
behave exactly like PROVIDEd symbols, but I think that's a reasonable
difference particularly since this is the way they used to behave.

* elflink.c (bfd_elf_define_start_stop): Override symbols when
they are defined dynamically.

PowerPC64 .branch_lt size change leads to "stubs don't match calculated size"

https://bugzilla.redhat.com/show_bug.cgi?id=1523457

I haven't analyzed this myself, I'm relying on Nick's excellent
analysis.  What I believe is happening is that after some number of
stub sizing iterations, a long-branch stub needs to be converted to a
plt-branch, but either due to stub alignment or other stubs shrinking
in size, the stub group section size doesn't change.

That means we exit from ppc64_elf_size_stubs after sizing with an
incorrect layout, in fact the additional .branch_lt entry overlays
.got!  Since .TOC. is normally set to .got + 0x8000 the stub sizing
code decides that entry is within +/-32k of the TOC pointer and so a
three insn stub is sufficient.  When we come to build the stubs using
a correct non-overlaying layout, a four insn plt-branch stub is
generated and the stub group size doesn't match that calculated
earlier.

* elf64-ppc.c (ppc64_elf_size_stubs): Iterate sizing when
.branch_lt changes size.

Automatic date update in version.in

PR22746, crash when running 32-bit objdump on corrupted file

Avoid unsigned int overflow by performing bfd_size_type multiplication.

PR 22746
* elfcode.h (elf_object_p): Avoid integer overflow.

Fix PR ld/22727 (TLS breakage in PIC/PIE mode on SPARC).

There are actually 2 different bugs:
 1. TLS transition is broken in PIE mode.
 2. TLS is broken in PIC/PIE mode when the __tls_get_addr symbol
    is versioned  (as is the case on Linux and Solaris at least).

The 1st bug is fixed by reverting the problematic change for now
(note that the associated test doesn't pass on SPARC because of another
issue so there is  no formal regression in the testsuite). The 2nd bug
is fixed by changing the  call to _bfd_generic_link_add_one_symbol
on __tls_get_addr into a mere lookup in _bfd_sparc_elf_check_relocs.

bfd/
* elfxx-sparc.c (_bfd_sparc_elf_check_relocs) <R_SPARC_TLS_GD_CALL>:
Do a mere lookup of the __tls_get_addr symbol instead of adding it.

Revert
2017-10-19  H.J. Lu  <hongjiu.lu@intel.com>

PR ld/22263
* elfxx-sparc.c (sparc_elf_tls_transition): Replace
bfd_link_pic with !bfd_link_executable, !bfd_link_pic with
bfd_link_executable for TLS check.
(_bfd_sparc_elf_check_relocs): Likewise.
(allocate_dynrelocs): Likewise.
(_bfd_sparc_elf_relocate_section): Likewise.
ld/
* testsuite/ld-sparc/sparc.exp (32-bit: Helper shared library):
Link with a version script.
(32-bit: TLS -fpie): New test.
(64-bit: Helper shared library): Link with a version script.
(64-bit: TLS -fpie): New test.
(64-bit: GOTDATA relocations): Pass -Av9 to the assembler.
* testsuite/ld-sparc/tlslib.ver: New file.
* testsuite/ld-sparc/tlspie32.dd: Likewise.
* testsuite/ld-sparc/tlspie32.s: Likewise.
* testsuite/ld-sparc/tlspie64.dd: Likewise.
* testsuite/ld-sparc/tlspie64.s: Likewise.
* testsuite/ld-sparc/tlssunbin32.dd: Adjust for versioned symbol.
* testsuite/ld-sparc/tlssunbin32.rd: Likewise.
* testsuite/ld-sparc/tlssunbin32.sd: Likewise.
* testsuite/ld-sparc/tlssunbin64.dd: Likewise.
* testsuite/ld-sparc/tlssunbin64.rd: Likewise.
* testsuite/ld-sparc/tlssunbin64.sd: Likewise.

Automatic date update in version.in

Fix GCC PR83906 - [8 Regression] Random FAIL: libstdc++-prettyprinters/80276.cc whatis p4

GCC PR83906 [1] is about a GCC/libstdc++ GDB/Python type printer
testcase failing randomly, as shown by running (in libstdc++'s
testsuite):

 make check RUNTESTFLAGS=prettyprinters.exp=80276.cc

in a loop.  Sometimes you get this:

 FAIL: libstdc++-prettyprinters/80276.cc whatis p4

I.e., this:
 type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >>[]>>[99]>

instead of this:
 type = std::unique_ptr<std::vector<std::unique_ptr<std::list<std::string>[]>>[99]>

Jonathan Wakely tracked it on the printer side to this bit in
libstdc++'s type printer:

            if self.type_obj == type_obj:
                return strip_inline_namespaces(self.name)

This assumes the two types resolve to the same gdb.Type but some times
the comparison unexpectedly fails.

Running the testcase manually under Valgrind finds the problem in GDB:

 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 ==6118== Conditional jump or move depends on uninitialised value(s)
 ==6118==    at 0x4C35CB0: bcmp (vg_replace_strmem.c:1100)
 ==6118==    by 0x6F773A: check_types_equal(type*, type*, VEC_type_equality_entry_d**) (gdbtypes.c:3515)
 ==6118==    by 0x6F7B00: check_types_worklist(VEC_type_equality_entry_d**, bcache*) (gdbtypes.c:3618)
 ==6118==    by 0x6F7C03: types_deeply_equal(type*, type*) (gdbtypes.c:3655)
 ==6118==    by 0x4D5B06: typy_richcompare(_object*, _object*, int) (py-type.c:1007)
 ==6118==    by 0x63D7E6C: PyObject_RichCompare (object.c:961)
 ==6118==    by 0x646EAEC: PyEval_EvalFrameEx (ceval.c:4960)
 ==6118==    by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
 ==6118==    by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
 ==6118==    by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
 ==6118==    by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
 ==6118==    by 0x646DC08: PyEval_EvalFrameEx (ceval.c:4519)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

That "bcmp" call is really a memcmp call in check_types_equal.  The
problem is that gdb is memcmp'ing two objects that are equal in value:

 (top-gdb) p *TYPE_RANGE_DATA (type1)
 $1 = {low = {kind = PROP_CONST, data = {const_val = 0, baton = 0x0}}, high = {kind = PROP_CONST, data = {const_val = 15, baton = 0xf}}, flag_upper_bound_is_count = 0,
   flag_bound_evaluated = 0}
 (top-gdb) p *TYPE_RANGE_DATA (type2)
 $2 = {low = {kind = PROP_CONST, data = {const_val = 0, baton = 0x0}}, high = {kind = PROP_CONST, data = {const_val = 15, baton = 0xf}}, flag_upper_bound_is_count = 0,
   flag_bound_evaluated = 0}

but differ in padding.  Notice the 4-byte hole:

  (top-gdb) ptype /o range_bounds
  /* offset    |  size */  type = struct range_bounds {
  /*    0      |    16 */    struct dynamic_prop {
  /*    0      |     4 */        dynamic_prop_kind kind;
  /* XXX  4-byte hole  */
  /*    8      |     8 */        union dynamic_prop_data {
  /*                 8 */            LONGEST const_val;
  /*                 8 */            void *baton;

     /* total size (bytes):    8 */
 } data;

which is filled with garbage:

  (top-gdb) x /40bx TYPE_RANGE_DATA (type1)
  0x2fa7ea0:      0x01    0x00    0x00    0x00    0x43    0x01    0x00    0x00
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  0x2fa7ea8:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
  0x2fa7eb0:      0x01    0x00    0x00    0x00    0xfe    0x7f    0x00    0x00
  0x2fa7eb8:      0x0f    0x00    0x00    0x00    0x00    0x00    0x00    0x00
  0x2fa7ec0:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
  (top-gdb) x /40bx TYPE_RANGE_DATA (type2)
  0x20379b0:      0x01    0x00    0x00    0x00    0xfe    0x7f    0x00    0x00
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  0x20379b8:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00
  0x20379c0:      0x01    0x00    0x00    0x00    0xfe    0x7f    0x00    0x00
  0x20379c8:      0x0f    0x00    0x00    0x00    0x00    0x00    0x00    0x00
  0x20379d0:      0x00    0x00    0x00    0x00    0x00    0x00    0x00    0x00

  (top-gdb) p memcmp (TYPE_RANGE_DATA (type1), TYPE_RANGE_DATA (type2), sizeof (*TYPE_RANGE_DATA (type1)))
  $3 = -187

In some cases objects of type range_bounds are memset when allocated,
but then their dynamic_prop low/high fields are copied over from some
template dynamic_prop object that wasn't memset.  E.g.,
create_static_range_type's low/high locals are left with garbage in
the padding, and then that padding is copied over to the range_bounds
object's low/high fields.

At first, I considered making sure to always memset range_bounds
objects, thinking that maybe type objects are being put in some bcache
instance somewhere.  But then I hacked bcache/bcache_full to poison
non-pod types, and made dynamic_prop a non-pod, and GDB still
compiled.

So given that, it seems safest to not assume padding will always be
memset, and instead treat them as regular value types, implementing
(in)equality operators and using those instead of memcmp.

This fixes the random FAILs in GCC's testcase.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83906

gdb/ChangeLog:
2018-01-24  Pedro Alves  <palves@redhat.com>

GCC PR libstdc++/83906
* gdbtypes.c (operator==(const dynamic_prop &,
const dynamic_prop &)): New.
(operator==(const range_bounds &, const range_bounds &)): New.
(check_types_equal): Use them instead of memcmp.
* gdbtypes.h (operator==(const dynamic_prop &,
const dynamic_prop &)): Declare.
(operator!=(const dynamic_prop &, const dynamic_prop &)): Declare.
(operator==(const range_bounds &, const range_bounds &)): Declare.
(operator!=(const range_bounds &, const range_bounds &)): Declare.

[LD][AARCH64]Add group relocations to create PC-relative offset.

This is a patch to add linker support for group relocations to create a
16, 32, 48, or 64 bit PC-relative offset inline.

The following relocations are added along with the test cases:
BFD_RELOC_AARCH64_MOVW_PREL_G0, BFD_RELOC_AARCH64_MOVW_PREL_G0_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G1, BFD_RELOC_AARCH64_MOVW_PREL_G1_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G2, BFD_RELOC_AARCH64_MOVW_PREL_G2_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G3.

bfd/

2018-01-24  Renlin Li  <renlin.li@arm.com>

* elfnn-aarch64.c (elfNN_aarch64_final_link_relocate): Add support for
BFD_RELOC_AARCH64_MOVW_PREL_G0, BFD_RELOC_AARCH64_MOVW_PREL_G0_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G1, BFD_RELOC_AARCH64_MOVW_PREL_G1_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G2, BFD_RELOC_AARCH64_MOVW_PREL_G2_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G3.
* elfxx-aarch64.c (_bfd_aarch64_elf_put_addend): Likewise.
(_bfd_aarch64_elf_resolve_relocation): Likewise.

ld/

2018-01-24  Renlin Li  <renlin.li@arm.com>

* testsuite/ld-aarch64/aarch64-elf.exp: Run new testes.
* testsuite/ld-aarch64/emit-relocs-287.s: Fix test case.
* testsuite/ld-aarch64/emit-relocs-287.d: Fix expected output.
* testsuite/ld-aarch64/emit-relocs-287-overflow.s: New.
* testsuite/ld-aarch64/emit-relocs-287-overflow.d: New.
* testsuite/ld-aarch64/emit-relocs-288.d: New.
* testsuite/ld-aarch64/emit-relocs-288.s: New.
* testsuite/ld-aarch64/emit-relocs-289.d: New.
* testsuite/ld-aarch64/emit-relocs-289.s: New.
* testsuite/ld-aarch64/emit-relocs-289-overflow.s: New.
* testsuite/ld-aarch64/emit-relocs-289-overflow.d: New.
* testsuite/ld-aarch64/emit-relocs-290.d: New.
* testsuite/ld-aarch64/emit-relocs-290.s: New.
* testsuite/ld-aarch64/emit-relocs-291.d: New.
* testsuite/ld-aarch64/emit-relocs-291.s: New.
* testsuite/ld-aarch64/emit-relocs-291-overflow.s: New.
* testsuite/ld-aarch64/emit-relocs-291-overflow.d: New.
* testsuite/ld-aarch64/emit-relocs-292.d: New.
* testsuite/ld-aarch64/emit-relocs-292.s: New.
* testsuite/ld-aarch64/emit-relocs-293.d: New.
* testsuite/ld-aarch64/emit-relocs-293.s: New.

[GAS][AARCH64]Add group relocations to create PC-relative offset.

This is a patch to add the gas support for group relocations to create a
16, 32, 48, or 64 bit PC-relative offset inline.

The following relocations are added along with the test cases:
BFD_RELOC_AARCH64_MOVW_PREL_G0, BFD_RELOC_AARCH64_MOVW_PREL_G0_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G1, BFD_RELOC_AARCH64_MOVW_PREL_G1_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G2, BFD_RELOC_AARCH64_MOVW_PREL_G2_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G3.

bfd/

2018-01-24  Renlin Li  <renlin.li@arm.com>

* reloc.c: Add BFD_RELOC_AARCH64_MOVW_PREL_G0,
BFD_RELOC_AARCH64_MOVW_PREL_G0_NC, BFD_RELOC_AARCH64_MOVW_PREL_G1,
BFD_RELOC_AARCH64_MOVW_PREL_G1_NC, BFD_RELOC_AARCH64_MOVW_PREL_G2,
BFD_RELOC_AARCH64_MOVW_PREL_G2_NC, BFD_RELOC_AARCH64_MOVW_PREL_G3.
* bfd-in2.h: Regenerate.
* libbfd.h: Regenerate.
* elfnn-aarch64.c (elfNN_aarch64_howto_table): Add entries for
BFD_RELOC_AARCH64_MOVW_PREL_G0, BFD_RELOC_AARCH64_MOVW_PREL_G0_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G1, BFD_RELOC_AARCH64_MOVW_PREL_G1_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G2, BFD_RELOC_AARCH64_MOVW_PREL_G2_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G3.

gas/

2018-01-24  Renlin Li  <renlin.li@arm.com>

* config/tc-aarch64.c (reloc_table): add entries for
BFD_RELOC_AARCH64_MOVW_PREL_G0, BFD_RELOC_AARCH64_MOVW_PREL_G0_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G1, BFD_RELOC_AARCH64_MOVW_PREL_G1_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G2, BFD_RELOC_AARCH64_MOVW_PREL_G2_NC,
BFD_RELOC_AARCH64_MOVW_PREL_G3.
(process_movw_reloc_info): Supports newly added MOVW_PREL relocations.
(md_apply_fix): Likewise
* testsuite/gas/aarch64/prel_g0.s: New.
* testsuite/gas/aarch64/prel_g0.d: New.
* testsuite/gas/aarch64/prel_g0_nc.s: New.
* testsuite/gas/aarch64/prel_g0_nc.d: New.
* testsuite/gas/aarch64/prel_g1.s: New.
* testsuite/gas/aarch64/prel_g1.d: New.
* testsuite/gas/aarch64/prel_g1_nc.s: New.
* testsuite/gas/aarch64/prel_g1_nc.d: New.
* testsuite/gas/aarch64/prel_g2.s: New.
* testsuite/gas/aarch64/prel_g2.d: New.
* testsuite/gas/aarch64/prel_g2_nc.s: New.
* testsuite/gas/aarch64/prel_g2_nc.d: New.
* testsuite/gas/aarch64/prel_g3.s: New.
* testsuite/gas/aarch64/prel_g3.d: New.

Automatic date update in version.in

MIPS/GAS: Correct default ABI selection for `mips64*-ps2-elf*'

Correct an issue with the `mips64*-ps2-elf*' target introduced with
commit e407c74b5b60 ("Support for MIPS R5900 (Sony Playstation 2)"),
<https://sourceware.org/ml/binutils/2012-12/msg00240.html> and make
the n32 ABI the default for GAS, consistently with how BFD and LD
are configured for this target.

gas/
* configure.ac: Also set `mips_default_abi' to N32_ABI for
`mips64*-ps2-elf*'.
* configure: Regenerate.

MIPS/GAS: Remove a stale OPTION_COMPAT_ARCH_BASE option marker

Complement commit 23fce1e31156 ("MIPS16 intermix test failure"),
<https://sourceware.org/ml/binutils/2009-01/msg00335.html>, and
remove a stale option marker entry.

gas/
* config/tc-mips.c (options): Remove OPTION_COMPAT_ARCH_BASE
enum value.

MIPS/BFD: Update a stale `mips_elf32_section_processing' reference

Update a stale reference to `mips_elf32_section_processing', following a
merge of the function into `_bfd_mips_elf_section_processing' made with
commit 103186c62b99 ("PATCH for MIPS 64-bit ABI suport"),
<https://sourceware.org/ml/binutils/1999-q3/msg00072.html>.

bfd/
* elfxx-mips.c (_bfd_mips_elf_final_link): Update a stale
`mips_elf32_section_processing' comment reference.

Enable Intel PCONFIG instruction.

Intel has disclosed a set of new instructions for Icelake processor.
The spec is
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf

This patch enables Intel PCONFIG instruction.

gas/
* config/tc-i386.c (cpu_arch): Add .pconfig.
* doc/c-i386.texi: Document .pconfig.
* testsuite/gas/i386/i386.exp: Add PCONFIG tests.
* testsuite/gas/i386/pconfig-intel.d: New test.
* testsuite/gas/i386/pconfig.d: Likewise.
* testsuite/gas/i386/pconfig.s: Likewise.
* testsuite/gas/i386/x86-64-pconfig-intel.d: Likewise.
* testsuite/gas/i386/x86-64-pconfig.d: Likewise.
* testsuite/gas/i386/x86-64-pconfig.s: Likewise.
opcodes/
* i386-dis.c (enum): Add pconfig.
* i386-gen.c (cpu_flag_init): Add CPU_PCONFIG_FLAGS.
(cpu_flags): Add CpuPCONFIG.
* i386-opc.h (enum): Add CpuPCONFIG.
(i386_cpu_flags): Add cpupconfig.
* i386-opc.tbl: Add PCONFIG instruction.
* i386-init.h: Regenerate.
* i386-tbl.h: Likewise.

Enable Intel WBNOINVD instruction.

Intel has disclosed a set of new instructions for Icelake processor.
The spec is
https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf

This patch enables Intel WBNOINVD instruction.

gas/
* config/tc-i386.c (cpu_arch): Add .wbnoinvd.
* doc/c-i386.texi: Document .wbnoinvd.
* testsuite/gas/i386/i386.exp: Add WBNOINVD tests.
* testsuite/gas/i386/wbnoinvd-intel.d: New test.
* testsuite/gas/i386/wbnoinvd.d: Likewise.
* testsuite/gas/i386/wbnoinvd.s: Likewise.
* testsuite/gas/i386/x86-64-wbnoinvd-intel.d: Likewise.
* testsuite/gas/i386/x86-64-wbnoinvd.d: Likewise.
* testsuite/gas/i386/x86-64-wbnoinvd.s: Likewise.
opcodes/
* i386-dis.c (enum): Add PREFIX_0F09.
* i386-gen.c (cpu_flag_init): Add CPU_WBNOINVD_FLAGS.
(cpu_flags): Add CpuWBNOINVD.
* i386-opc.h (enum): Add CpuWBNOINVD.
(i386_cpu_flags): Add cpuwbnoinvd.
* i386-opc.tbl: Add WBNOINVD instruction.
* i386-init.h: Regenerate.
* i386-tbl.h: Likewise.

MIPS/GAS: Correct `as --help' always reporting `o32' as the default ABI

Remove an issue with `as --help' always reporting `o32' as the default
ABI regardless of what the default actually is, originally caused by
commit cac012d6d394 ("check mips abi x linker emulation compatibility"),
<https://sourceware.org/ml/binutils/2003-05/msg00187.html> missing an
update here.

gas/
* config/tc-mips.c (md_show_usage): Correctly indicate the
configuration-specific default ABI.

MIPS/GAS: Add missing `-mmips16e2'/`-mno-mips16e2' help text

Correct a commit 25499ac7ee92 ("MIPS16e2: Add MIPS16e2 ASE support") GAS
bug and add missing help text for the `-mmips16e2' and `-mno-mips16e2'
options added with said commit.

gas/
* config/tc-mips.c (md_show_usage): Report `-mmips16e2' and
`-mno-mips16e2' options.

s390: Clean up s390-linux-tdep.c

After moving big parts of the code to the new s390-tdep.c file
s390-linux-tdep.c now contains many includes it doesn't need anymore.
Furthermore, there are some functions lacking a description.

Fix both and order the remaining includes alphabetically.

gdb/ChangeLog
* s390-linux-tdep.c: Remove unneeded includes and order them
alphabetically.  Add comments to functions without description.

s390: Move record-replay to s390-tdep.c

Record-replay is independent of the OS.  So it can be moved to the common
s390 code without problem.

gdb/ChangeLog:

* s390-linux-tdep.c (s390_record_address_mask)
(s390_record_calc_disp_common, s390_record_calc_disp)
(s390_record_calc_disp_vsce, s390_record_calc_rl, s390_popcnt)
(s390_record_gpr_g, s390_record_gpr_h, s390_record_vr)
(s390_process_record): Move to s390-tdep.c.
(s390_linux_init_abi_any): Adjust.
* s390-tdep.c (s390_record_address_mask)
(s390_record_calc_disp_common, s390_record_calc_disp)
(s390_record_calc_disp_vsce, s390_record_calc_rl, s390_popcnt)
(s390_record_gpr_g, s390_record_gpr_h, s390_record_vr)
(s390_process_record): Moved from s390-linux-tdep.c
(s390_gdbarch_init): Adjust.

s390: Split up s390-linux-tdep.c into two files

Currently all target dependent code for s390 is in one file,
s390-linux-tdep.c.  This includes code general for the architecture as
well as code specific for uses in GNU/Linux (user space).  Up until now
this was OK as GNU/Linux was the only supported OS.  In preparation to
support the new Linux kernel 'OS' split up the existing s390 code into a
general s390-tdep and a GNU/Linux-specific s390-linux-tdep.

Note: The record-replay feature will be moved in a separate patch.  This
is simply due to the fact that the combined patch would be too large for
the mailing list.  This requires setting the process_record hook during
OSABI init to keep the code bisectable.  The patch moving record-replay
cleans up this hack.

gdb/ChangeLog:

* s390-linux-nat.c (s390-tdep.h): New include.
* Makefile.in (ALL_TARGET_OBS): Add s390-tdep.o.
(HFILES_NO_SRCDIR): Add s390-tdep.h.
(ALLDEPFILES): Add s390-tdep.c.
* configure.tgt (s390*-*-linux*): Add s390-tdep.o.
* s390-linux-tdep.h (HWCAP_S390_*, S390_*_REGNUM): Move to...
* s390-tdep.h: ...this.  New file.
* s390-linux-tdep.c (s390-tdep.h): New include.
(_initialize_s390_tdep): Rename to...
(_initialize_s390_linux_tdep): ...this and adjust.
(s390_abi_kind, s390_vector_abi_kind, gdbarch_tdep)
(enum named opcodes, S390_NUM_GPRS, S390_NUM_FPRS): Move to
s390-tdep.h.
(s390_break_insn, s390_breakpoint, s390_readinstruction, is_ri)
(is_ril, is_rr, is_rre, is_rs, is_rsy, is_rx, is_rxy)
(s390_is_partial_instruction, s390_software_single_step)
(is_non_branch_ril, s390_displaced_step_copy_insn)
(s390_displaced_step_fixup, s390_displaced_step_hw_singlestep)
(s390_prologue_data, s390_addr, s390_store, s390_load)
(s390_check_for_saved, s390_analyze_prologue, s390_skip_prologue)
(s390_register_call_saved, s390_guess_tracepoint_registers)
(s390_register_name, s390_dwarf_regmap, s390_dwarf_reg_to_regnum)
(regnum_is_gpr_full, regnum_is_vxr_full, s390_value_from_register)
(s390_pseudo_register_name, s390_pseudo_register_type)
(s390_pseudo_register_read, s390_pseudo_register_write)
(s390_pseudo_register_reggroup_p, s390_ax_pseudo_register_collect)
(s390_ax_pseudo_register_push_stack, s390_gen_return_address)
(s390_addr_bits_remove, s390_address_class_type_flags)
(s390_address_class_type_flags_to_name)
(s390_address_class_name_to_type_flags, s390_effective_inner_type)
(s390_function_arg_float, s390_function_arg_vector)
(is_power_of_two, s390_function_arg_integer, s390_arg_state)
(s390_handle_arg, s390_push_dummy_call, s390_dummy_id)
(s390_frame_align, s390_register_return_value, s390_return_value)
(s390_stack_frame_destroyed_p, s390_unwind_pc, s390_unwind_sp)
(s390_unwind_pseudo_register, s390_adjust_frame_regnum)
(s390_dwarf2_prev_register, s390_dwarf2_frame_init_reg)
(s390_trad_frame_prev_register, s390_unwind_cache)
(s390_prologue_frame_unwind_cache)
(s390_backchain_frame_unwind_cache, s390_frame_unwind_cache)
(s390_frame_this_id, s390_frame_prev_register, s390_frame_unwind)
(s390_stub_unwind_cache, s390_stub_frame_unwind_cache)
(s390_stub_frame_this_id, s390_stub_frame_prev_register)
(s390_stub_frame_sniffer, s390_stub_frame_unwind)
(s390_frame_base_address, s390_local_base_address)
(s390_frame_base, s390_gcc_target_options)
(s390_gnu_triplet_regexp, s390_stap_is_single_operand)
(s390_validate_reg_range, s390_tdesc_valid)
(s390_gdbarch_tdep_alloc, s390_gdbarch_init): Move to...
* s390-tdep.c: ...this.  New file.

s390: gdbarch_tdep add hook for syscall record

Most parts of s390_process_record are common for the architecture.  Only
the system call handling differs between the OSes.  In order to be able to
move s390_process_record to a common code file add a hook to record
syscalls to gdbarch_tdep.  So every OS can implement their own handling.

gdb/ChangeLog:

* s390-linux-tdep.c (gdbarch_tdep.s390_syscall_record): New hook.
(s390_process_record, s390_gdbarch_tdep_alloc)
(s390_linux_init_abi_any): Use/set new hook.

s390: Hook s390 into OSABI mechanism

Do what the title says and distinguish between 31- and 64-bit systems.
The goal is to init the OSABI as late as possible in gdbarch_init so the
OSABI has the chance to overwrite the defaults.

There are two pitfalls to be aware of:

First, the dwarf2 unwinder must be appended before the OSABI is
initialized.  Otherwise the OS could add a default unwinder which always
takes control before the dwarf unwinder even gets a chance.

Second, tdesc_use_registers has to be handled with extra care.  It sets
several gdbarch hooks, especially gdbarch_register_name, which has to be
overwritten again after the call.  Furthermore it deletes the tdesc_data
without checking.  Therefore there must not be a call to
tdesc_data_cleanup afterwards or GDB will crash with a double free.

gdb/ChangeLog:

* s390-linux-tdep.c (osabi.h): New include.
(s390_linux_init_abi_31, s390_linux_init_abi_64)
(s390_linux_init_abi_any): New functions.
(s390_gdbarch_init, _initialize_s390_tdep): Adjust.

s390: if -> gdb_assert for tdesc_has_registers check

Before doing the tdesc validation there is a check whether the tdesc has
registers or not.  This check is not only unnecessary but wrong.

First the check is done after a default tdesc is assigned if the original
tdesc has no registers.  These default tdescs always have registers so the
check alway returns true.

Second if the default tdesc would not have registers the check only skips
the tdesc validation instead of returning an error.  This would trigger a
gdb_assert later on in tdesc_use_registers.

gdb/ChangeLog:

* s390-linux-tdep.c (s390_gdbarch_init): Use gdb_assert for
tdesc_has_registers check

s390: Move tdesc validation to separate function

Simplify s390_gdbarch_init by moving the target description validation to
a separate function.

gdb/ChangeLog:

* s390-linux-tdep.c (s390_tdesc_valid): New function.
(s390_validate_reg_range): New macro.
(s390_gdbarch_init): Adjust.

s390: gdbarch_tdep add field tdesc

Add a field for the target description to gdbarch_tdep.  This will later be
needed to pass the 'correct' target description from osabi_init to
gdbarch_init.  Unfortunately this cannot be done using gdbarch_info as it
is only passed by copy, not reference.

gdb/ChangeLog:

* s390-linux-tdep.c (gdbarch_tdep) <tdesc>: New field.
(s390_gdbarch_tdep_alloc): Adjust.
(s390_gdbarch_init): Adjust.

s390: gdbarch_tdep.have_* int -> bool

Currently the gdbarch_tdep.have_* flags are a mix of int and bool.  Clean
this up by making them all bool.

gdb/ChangeLog:

* s390-linux-tdep.c (gdbarch_tdep) <have_linux_v1, have_linux_v2>
<have_tdb>: Change type to bool.
(s390_gdbarch_tdep_alloc): Adjust.
(s390_gdbarch_init): Adjust.

s390: Allocate gdbarch & tdep at start of gdbarch_init

Moving the allocation of gdbarch_tdep to the start of s390_gdbarch_init
allows us to use its fields for tracking the different features instead of
using separate variables.  To make the code a little nicer move the actual
allocation and initialization to a separate function.  Also move the
allocation of gdbarch to keep the two together.

gdb/ChangeLog:

* s390-linux-tdep (s390_abi_kind) <ABI_NONE>: New default field.
(gdbarch_tdep) <have_upper, have_vx>: New fields.
(s390_gdbarch_tdep_alloc): New function.
(s390_gdbarch_init): Allocate tdep at start and use its fields
instead of separate variables.

s390: Remove duplicate checks for cached gdbarch at init

When initializing the gdbarch there is a check whether an appropriate
gdbarch already exists in the gdbarch_list.  Failing of some of the checks
would lead to a different target description.  However
gdbarch_list_lookup_by_info already checks for

if (info->target_desc != arches->gdbarch->target_desc)
  continue;

Remove these duplicate checks.

gdb/ChangeLog:

* s390-linux-tdep.c (s390_gdbarch_init): Remove duplicate checks
when looking for cached gdbarch and add comment for remaining.

Automatic date update in version.in

GAS/doc: Correct `.set nomips16e2' directive description syntax

gas/
* doc/c-mips.texi (MIPS ASE Instruction Generation Overrides):
Correct syntax of the `.set nomips16e2' directive description.

binutils/doc: Fix a "using" typo in `objcopy --rename-section' description

binutils/
* doc/binutils.texi (objcopy): Fix a typo in `--rename-section'
option description.

Fix segfault with 'set print object on' + 'whatis <struct>' & co

Compiling GDB with a recent GCC exposes a problem:

  ../../gdb/typeprint.c: In function 'void whatis_exp(const char*, int)':
  ../../gdb/typeprint.c:515:12: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized]
    real_type = value_rtti_type (val, &full, &top, &using_enc);
    ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The warning is correct.  There are indeed code paths that use
uninitialized 'val', leading to crashes.  Inside the
value_rtti_indirect_type/value_rtti_type calls here in whatis_exp:

  if (opts.objectprint)
    {
      if (((TYPE_CODE (type) == TYPE_CODE_PTR) || TYPE_IS_REFERENCE (type))
  && (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_STRUCT))
        real_type = value_rtti_indirect_type (val, &full, &top, &using_enc);
      else if (TYPE_CODE (type) == TYPE_CODE_STRUCT)
real_type = value_rtti_type (val, &full, &top, &using_enc);
    }

We reach those calls above with "set print object on", and then with
any of:

  (gdb) whatis struct some_structure_type
  (gdb) whatis struct some_structure_type *
  (gdb) whatis struct some_structure_type &

because "whatis" with a type argument enters this branch:

      /* The behavior of "whatis" depends on whether the user
 expression names a type directly, or a language expression
 (including variable names).  If the former, then "whatis"
 strips one level of typedefs, only.  If an expression,
 "whatis" prints the type of the expression without stripping
 any typedef level.  "ptype" always strips all levels of
 typedefs.  */
      if (show == -1 && expr->elts[0].opcode == OP_TYPE)
{

which does not initialize VAL.  Trying the above triggers crashes like
this:

  (gdb) set print object on
  (gdb) whatis some_structure_type

  Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
  0x00000000005dda90 in check_typedef (type=0x6120736573756170) at src/gdb/gdbtypes.c:2388
  2388      int instance_flags = TYPE_INSTANCE_FLAGS (type);
  ...

This is a regression caused by a recent-ish refactoring of the code on
'whatis_exp', introduced by:

  commit c973d0aa4a2c737ab527ae44a617f1c357e07364
  Date:   Mon Aug 21 11:34:32 2017 +0100

      Fix type casts losing typedefs and reimplement "whatis" typedef stripping

Fix this by setting VAL to NULL in the "whatis TYPE" case, and
skipping fetching the dynamic type if there's no value to fetch it
from.

New tests included.

gdb/ChangeLog:
2018-01-22  Pedro Alves  <palves@redhat.com>
    Sergio Durigan Junior  <sergiodj@redhat.com>

* typeprint.c (whatis_exp): Initialize "val" in the "whatis type"
case.

gdb/testsuite/ChangeLog:
2018-01-22  Pedro Alves  <palves@redhat.com>
    Sergio Durigan Junior  <sergiodj@redhat.com>

* gdb.base/whatis.exp: Add tests for 'set print object on' +
'whatis <struct>' 'whatis <struct> *' and 'whatis <struct> &'.

MAINTAINERS: Update my company e-mail address

Following my recent transition from Imagination Technologies to the
reincarnated MIPS company update MAINTAINERS entries accordingly.

binutils/
* MAINTAINERS: Update my company e-mail address.

gdb/
* MAINTAINERS: Update my company e-mail address.

sim/
* MAINTAINERS: Update my company e-mail address.

Fix the RX assembler so that it can handle escaped double quote characters, ie: \"

PR 22737
* config/tc-rx.c (rx_start_line): Handle escaped double-quote character.
* testsuite/gas/rx/pr22737.s: New test.
* testsuite/gas/rx/pr22737.d: Likewise.
* testsuite/gas/rx/rx.exp: Run the new test.

Update Swedish translation for the binutils sub-directory

regcache::cooked_write test

Since my following patches will change how each gdbarch read and write
pseudo registers, it's better to write a unit test to
regcache::cooked_write, to make sure my following changes don't cause
any regressions.  See the comments on cooked_write_test.

gdb:

2018-01-22  Yao Qi  <yao.qi@linaro.org>

* regcache.c (cooked_write_test): New function.
(_initialize_regcache): Register the test.

regcache_cooked_read -> regcache->cooked_read

Similarly, this patch replaces regcache_cooked_read with
regcache->cooked_read.

gdb:

2018-01-22  Yao Qi  <yao.qi@linaro.org>

* ia64-tdep.c (ia64_pseudo_register_read): Call
regcache->cooked_read instead of regcache_cooked_read_unsigned.
* m32c-tdep.c (m32c_cat_read): Likewise.
(m32c_r3r2r1r0_read): Likewise.
* m68hc11-tdep.c (m68hc11_pseudo_register_read): Likewise.
* xtensa-tdep.c (xtensa_register_read_masked): Likewise.

Replace regcache_raw_read with regcache->raw_read

The patch later in this series will move regcache's raw_read and
cooked_read methods to a new class regcache_read, and regcache is
dervied from it.  Also pass regcache_read instead of regcache to gdbarch
methods pseudo_register_read and pseudo_register_read_value.  In order
to prepare for this change, this patch changes regcache_raw_read to
regcache->raw_read.  On the other hand, since we are in C++, I prefer
using class method (regcache->raw_read).

gdb:

2018-01-22  Yao Qi  <yao.qi@linaro.org>

* aarch64-tdep.c (aarch64_pseudo_read_value): Call regcache
method raw_read instead of regcache_raw_read.
* amd64-tdep.c (amd64_pseudo_register_read_value): Likewise.
* arm-tdep.c (arm_neon_quad_read): Likewise.
* avr-tdep.c (avr_pseudo_register_read): Likewise.
* bfin-tdep.c (bfin_pseudo_register_read): Likewise.
* frv-tdep.c (frv_pseudo_register_read): Likewise.
* h8300-tdep.c (h8300_pseudo_register_read): Likewise.
* i386-tdep.c (i386_mmx_regnum_to_fp_regnum): Likewise.
(i386_pseudo_register_read_into_value): Likewise.
* mep-tdep.c (mep_pseudo_cr32_read): Likewise.
* msp430-tdep.c (msp430_pseudo_register_read): Likewise.
* nds32-tdep.c (nds32_pseudo_register_read): Likewise.
* rl78-tdep.c (rl78_pseudo_register_read): Likewise.
* s390-linux-tdep.c (s390_pseudo_register_read): Likewise.
* sparc-tdep.c (sparc32_pseudo_register_read):  Likewise.
* sparc64-tdep.c (sparc64_pseudo_register_read): Likewise.
* spu-tdep.c (spu_pseudo_register_read_spu):  Likewise.
* xtensa-tdep.c (xtensa_pseudo_register_read): Likewise.

Remove mt port

This patch removes the MT port.  The removal was annoucned
https://sourceware.org/ml/gdb-announce/2017/msg00006.html
I'll remove MT from the top-level configure later.

gdb:

2018-01-22  Yao Qi  <yao.qi@linaro.org>

* Makefile.in (ALL_TARGET_OBS): Remove mt-tdep.o.
* configure.tgt: Remove target mt.
* mt-tdep.c: Remove.
* regcache.c (cooked_read_test): Remove the check for mt.

Don't call gdbarch_pseudo_register_read_value in jit.c

gdbarch_pseudo_register_read_value is not implemented in every gdbarch, so
the predicate gdbarch_pseudo_register_read_value_p is needed before
calling it.  However, there is no such guard in jit_frame_prev_register, I
am wondering how does jit work on the arch without having gdbarch method
pseudo_register_read_value.

The proper way to get register value is to call cooked_read, and then
create the value object from the buffer.

gdb:

2018-01-22  Yao Qi  <yao.qi@linaro.org>

* jit.c (jit_frame_prev_register): Call regcache::cooked_read
instead of gdbarch_pseudo_register_read_value.

Ada/DWARF: Assume the Ada compiler produces descriptive type attributes

GCC was enhanced in 2011 to generate this attribute, so I think we can
now assume that it is available when using that compiler. Doing so
allows us to speed up what we call "parallel type" lookups when
processing certain types encoded using the GNAT encoding.

This patch changes need_gnat_info to always expect those attributes
to be generated when the language is Ada. This is an assumption
that on the surfcace looks like it might be a bit on the edge; but
in practice, it should be OK because this is only useful in the
context of handling GNAT-specific encodings. Other Ada compilers
would presumably produce debugging information using pure DWARF
constructs, so would not be impacted by this.

gdb/ChangeLog:

        * dwarf2read.c (need_gnat_info): Return nonzero if the cu's
        language is Ada.

Tested on x86_64-linux.

wrong line number in breakpoint location

Consider the following situation, where we have one file containing...

    $ cat -n body.inc
         1  i = i + 1;

... we include that file from some code, like so:

    $ cat -n cat -n small.c
        [...]
        17  int
        18  next (int i)
        19  {
        20  #include "body.inc"
        21    return i;
        22  }

When trying to insert a breakpoint on line 18, for instance:

    (gdb) b small.c:18
    Breakpoint 1 at 0x40049f: file body.inc, line 18.
                                                  ^^
                                                  ||

Here, the issue is that GDB reports the breakpoint to be in file
body.inc, which is true, but with the line number that corresponding
to the user-requested location, which is not correct.

Although the simple reproducer may look slightly artificial,
the above is simply one way to reproduce the same issue observed
when trying to insert a breakpoint on a function provided in
a .h files and then subsequently inlined in a C file.

What happens is the following:

  1. We resolve the small.c:18 linespec into a symtab_and_line which
     has "small.c" and 18 as the symtab and line number.

  2. Next, we call skip_prologue_sal, which calculates the PC
     past the prologue, and updates the symtab_and_line: PC,
     but also symtab (now body.inc) and the new line (now 1).

  3. However, right after that, we do:

            /* Make sure the line matches the request, not what was
               found.  */
            intermediate_results.sals[i].line = val.line;

We should either restore both symtab and line, or leave the actual
line to match the actual symtab.  This patch chose the latter.
This introduces a few changes in a few tests, which required some
updates, but looking at those change, I believe them to be expected.

gdb/ChangeLog:

        * linespec.c (create_sals_line_offset): Remove code that preserved
        the symtab_and_line's line number.

gdb/testsuite/ChangeLog:

        * gdb.base/break-include.c, gdb.base/break-include.inc,
        gdb.base/break-include.exp: New files.
        * gdb.base/ending-run.exp: Minor adaptations due to the breakpoint's
        line number now being the actual line number where the breakpoint
        was inserted.
        * gdb.mi/mi-break.exp: Likewise.
        * gdb.mi/mi-reverse.exp: Likewise.
        * gdb.mi/mi-simplerun.exp: Ditto.

Tested on x86_64-linux.

Automatic date update in version.in

gdb: Don't store a thread-id for floating varobj

When creating a varobj with -var-create a user can create either fixed
varobj, or floating varobj.

A fixed varobj will always be evaluated within the thread/frame/block in
which the varobj was created, if that thread/frame/block is no longer
available then the varobj is considered out of scope.

A floating varobj will always be evaluated within the current
thread/frame/block.

Despite never using them GDB was storing the thread/frame/block into a
floating varobj, and the thread-id would then be displayed when GDB
reported on the state of the varobj, this could confuse a user into
thinking that the thread-id was relevant.

This commit prevents GDB storing the thread/frame/block onto floating
varobj, and updates the few tests where this impacts the results.

gdb/ChangeLog:

* varobj.c (varobj_create): Don't set valid_block when creating a
floating varobj.

gdb/testsuite/ChangeLog:

* gdb.python/py-mi.exp: Don't expect a thread-id for floating
varobj.
* gdb.mi/mi-var-create-rtti.exp: Likewise.

gdb: Remove out of date comment

Comment clean up.

gdb/ChangeLog:

* varobj.c (varobj_create): Remove out of date comment.

gdb: PR mi/20395: Fix -var-update for registers in frames 1 and up

This patch fixes a problem with using the MI -var-update command
to access the values of registers in frames other than the current
frame.  The patch includes a test that demonstrates the problem:

* run so there are several frames on the stack
* create a fixed varobj for $pc in each frame, #'s 1 and above
* step one instruction, to modify the value of $pc
* call -var-update for each of the previously created varobjs
  to verify that they are not reported as having changed.

Without the patch, the -var-update command reported that $pc for all
frames 1 and above had changed to the value of $pc in frame 0.

A varobj is created as either fixed, the expression is evaluated within
the context of a specific frame, or floating, the expression is
evaluated within the current frame, whatever that may be.

When a varobj is created by -var-create we set two fields of the varobj
to track the context in which the varobj was created, these two fields
are varobj->root->frame and var->root->valid_block.

If a varobj is of type fixed, then, when we subsequently try to
reevaluate the expression associated with the varobj we must determine
if the original frame (and block) is still available, if it is not then
the varobj can no longer be evaluated.

The problem is that for register expressions varobj->root->valid_block
is not set correctly.  This block tracking is done using the global
'innermost_block' which is set in the various parser files (for example
c-exp.y).  However, this is not set for register expressions.

The fix then seems like it should be to just update the innermost block
when parsing register expressions, however, that solution causes several
test regressions.

The problem is that in some cases we rely on the expression parsing
code not updating the innermost block for registers, one example is
when we parse the expression for a 'display' command.  The display
commands treats registers like floating varobjs, but symbols are
treated like fixed varobjs.  So 'display $reg_name' will always show
the value of '$reg_name' even as the user moves from frame to frame,
while 'display my_variable' will only show 'my_variable' while it is
in the current frame and/or block, when the user moves to a new frame
and/or block (even one with a different 'my_variable' in) then the
display of 'my_variable' stops.  For the case of 'display', without
the option to force fixed or floating expressions, the current
behaviour is probably the best choice.  For the varobj system though,
we can choose between floating and fixed, and we should try to make
this work for registers.

There's only one existing test case that needs to be updated, in that
test a fixed varobj is created using a register, the MI output now
include the thread-id in which the varobj should be evaluated, which I
believe is correct behaviour.  I also added a new floating test case
into the same test script, however, right now this also includes the
thread-id in the expected output, which I believe is an existing gdb
bug, which I plan to fix next.

Tested on x86_64 Linux native and native-gdbserver, no regressions.

gdb/ChangeLog:

PR mi/20395
* ada-exp.y (write_var_from_sym): Pass extra parameter when
updating innermost block.
* parse.c (innermost_block_tracker::update): Take extra type
parameter, and check types match before updating innermost block.
(write_dollar_variable): Update innermost block for registers.
* parser-defs.h (enum innermost_block_tracker_type): New enum.
(innermost_block_tracker::innermost_block_tracker): Initialise
m_types member.
(innermost_block_tracker::reset): Take type parameter.
(innermost_block_tracker::update): Take type parameter, and pass
type through as needed.
(innermost_block_tracker::m_types): New member.
* varobj.c (varobj_create): Pass type when reseting innermost
block.

gdb/testsuite/ChangeLog:

* gdb.mi/basics.c: Add new global.
* gdb.mi/mi-frame-regs.exp: New file.
* gdb.mi/mi-var-create-rtti.exp: Update expected results, add new
case.

gdb: New API for tracking innermost block

This commit is preparation for a later change, at this point there
should be no user visible change.

We currently maintain a global innermost_block which tracks the most
inner block encountered when parsing an expression.

This commit wraps the innermost_block into a new class, and switches all
direct accesses to the variable to use the class API.

gdb/ChangeLog:

* ada-exp.y (write_var_from_sym): Switch to innermost_block API.
* ada-lang.c (resolve_subexp): Likewise.
* breakpoint.c (set_breakpoint_condition) Likewise.
(watch_command_1) Likewise.
* c-exp.y (variable): Likewise.
* d-exp.y (PrimaryExpression): Likewise.
* f-exp.y (variable): Likewise.
* go-exp.y (variable): Likewise.
* m2-exp.y (variable): Likewise.
* objfiles.c (objfile::~objfile): Likewise.
* p-exp.y (variable): Likewise.
* parse.c (innermost_block): Change type.
* parser-defs.h (class innermost_block_tracker): New.
(innermost_block): Change to innermost_block_tracker.
* printcmd.c (display_command): Switch to innermost_block API.
(do_one_display): Likewise.
* rust-exp.y (do_one_display): Likewise.
* symfile.c (clear_symtab_users): Likewise.
* varobj.c (varobj_create): Switch to innermost_block API, replace
use of innermost_block with block stored on varobj object.

gdb: Remove duplicate declaration of global innermost_block

The global 'innermost_block' is declared in two header files.  Remove
one of the declarations, and add an include of the other header into
the one source file that could no longer see a declaration of
'innermost_block'.

gdb/ChangeLog:

* expression.h (innermost_block): Remove declaration.
* varobj.c: Add 'parser-defs.h' include.

gdb: Add test for some error cases of @entry usage

Adds a test that using @entry for a non-parameter, or for an unknown
symbol, both give the expected error.  This error message was
previously untested.

gdb/testsuite/ChangeLog:

* gdb.arch/amd64-entry-value.exp: Test using @entry on a
non-parameter, and on an unknown symbol.

Automatic date update in version.in

x86: Check the versioned __tls_get_addr symbol

We need to check the versioned __tls_get_addr symbol when looking up
"__tls_get_addr".

bfd/

PR ld/22721
* elfxx-x86.c (_bfd_x86_elf_link_check_relocs): Check the
versioned __tls_get_addr symbol.

ld/

PR ld/22721
* testsuite/ld-plugin/lto.exp: Run PR ld/22721 tests.
* testsuite/ld-plugin/pr22721.t: New file.
* testsuite/ld-plugin/pr22721a.s: Likewise.
* testsuite/ld-plugin/pr22721b.c: Likewise.

Automatic date update in version.in

Fix qualified name lookup for Rust

In https://github.com/rust-lang/rust/pull/46457, "m4b" pointed out
that the Rust support in gdb doesn't properly handle the lookup of
qualified names.

In particular, as shown in the test case in this patch, something like
"::NAME" should be found in the global scope, but is not.

This turns out to happen because rust_lookup_symbol_nonlocal does not
search the global scope unless the name in question is unqualified.
However, lookup_symbol_aux does not search the global scope, and
appears to search the static scope only as a fallback (I wonder if
this is needed?).

This patch fixes the problem by changing rust_lookup_symbol_nonlocal
to search the static and global blocks in more cases.

Regression tested against various versions of the rust compiler on
Fedora 26 x86-64.  (Note that there are unrelated failures with newer
versions of rustc; I will be addressing those separately.)

2018-01-19  Tom Tromey  <tom@tromey.com>

* rust-lang.c (rust_lookup_symbol_nonlocal): Look up qualified
symbols in the static and global blocks.

2018-01-19  Tom Tromey  <tom@tromey.com>

* gdb.rust/modules.rs (TWENTY_THREE): New global.
* gdb.rust/modules.exp: Add ::-qualified lookup test.

S390: Fix infcalls in s390-vregs test case

GDB used to assume that functions without debug info return int.  It
accepted an expression containing such a function call and silently
interpreted the function's return value as int.  But nowadays GDB yields
an error message instead, see

  https://sourceware.org/ml/gdb-patches/2017-07/msg00139.html

This affects the s390-vregs test case, because it contains calls to
setrlimit64 and chdir.  When no glibc debug info is installed, these lead
to unnecessary FAILs.  Fix this by adding appropriate casts to the
inferior function calls.

gdb/testsuite/ChangeLog:

* gdb.arch/s390-vregs.exp: Explicitly cast the return values of
setrlimit and chdir to int.

gdb: Add missing #ifdef USE_THREAD_DB to gdbserver

Otherwise, linking fails with:

  [...]/linux-low.c:664: undefined reference to `thread_db_notice_clone(thread_info*, ptid_t)'

gdb/gdbserver/ChangeLog:

* linux-low.c (handle_extended_wait): Surround call to
thread_db_notice_clone with #ifdef USE_THREAD_DB.

gdb: Fix ia64 defining TRAP_HWBKPT before including gdb_wait.h

On ia64, gdb_wait.h eventually includes siginfo-consts-arch.h, which
contains an enum with TRAP_HWBKPT, along with a #define. Thus we cannot
define TRAP_HWBKPT to 4 beforehand, and so gdb_wait.h must be included
earlier; include it from linux-ptrace.h so it can never come afterwards.

gdb/ChangeLog:

* nat/linux-ptrace.c: Remove unnecessary reinclusion of
gdb_ptrace.h, and move including gdb_wait.h ...
* nat/linux-ptrace.h: ... to here.

Make linux_nat_detach/thread_db_detach use the inferior parameter

This patch makes these two functions actually use the inferior parameter
added by the previous patch, instead of reading inferior_ptid.  I chose
these two, because they are the one actually used when I detach on my
GNU/Linux system, so they were easy to test.

I took the opportunity to pass the inferior being detached to
inf_ptrace_detach_success, so it could use it too.  From there, it made
sense to add an overload of detach_inferior that takes the inferior
directly rather than the pid, to avoid having to pass inf->pid only for
the callee to look up the inferior structure by pid.

gdb/ChangeLog:

* inf-ptrace.c (inf_ptrace_detach): Adjust call to
inf_ptrace_detach_success.
(inf_ptrace_detach_success): Add inferior parameter, use it
instead of inferior_ptid, pass it to detach_inferior.
* inf-ptrace.h (inf_ptrace_detach_success): Add inferior
parameter.
* inferior.c (detach_inferior): Add overload that takes an
inferior object.
* inferior.h (detach_inferior): Likewise.
* linux-nat.c (linux_nat_detach): Use the inf parameter, don't
use inferior_ptid, adjust call to inf_ptrace_detach_success.
* linux-thread-db.c (thread_db_detach): Use inf parameter.

Pass inferior down to target_detach and to_detach

The to_detach target_ops method implementations are currently expected
to work on current_inferior/inferior_ptid.  In order to make things more
explicit, and remove some "shadow" parameter passing through globals,
this patch adds an "inferior" parameter to to_detach.  Implementations
will be expected to use this instead of relying on the global.  However,
to keep things simple, this patch only does the minimum that is
necessary to add the parameter.  The following patch gives an example of
how one such implementation would be adapted.  If the approach is deemed
good, we can then look into adapting more implementations.  Until then,
they'll continue to work as they do currently.

gdb/ChangeLog:

* target.h (struct target_ops) <to_detach>: Add inferior
parameter.
(target_detach): Likewise.
* target.c (dispose_inferior): Pass inferior down.
(target_detach): Pass inferior down.  Assert that it is equal to
the current inferior.
* aix-thread.c (aix_thread_detach): Pass inferior down.
* corefile.c (core_file_command): Pass current_inferior() down.
* corelow.c (core_detach): Add inferior parameter.
* darwin-nat.c (darwin_detach): Likewise.
* gnu-nat.c (gnu_detach): Likewise.
* inf-ptrace.c (inf_ptrace_detach): Likewise.
* infcmd.c (detach_command): Pass current_inferior() down to
target_detach.
* infrun.c (follow_fork_inferior): Pass parent_inf to
target_detach.
(handle_vfork_child_exec_or_exit): Pass inf->vfork_parent to
target_detach.
* linux-nat.c (linux_nat_detach): Add inferior parameter.
* linux-thread-db.c (thread_db_detach): Likewise.
* nto-procfs.c (procfs_detach): Likewise.
* procfs.c (procfs_detach): Likewise.
* record.c (record_detach): Likewise.
* record.h (struct inferior): Forward-declare.
(record_detach): Add inferior parameter.
* remote-sim.c (gdbsim_detach): Likewise.
* remote.c (remote_detach_1): Likewise.
(remote_detach): Likewise.
(extended_remote_detach): Likewise.
* sol-thread.c (sol_thread_detach): Likewise.
* target-debug.h (target_debug_print_inferior_p): New macro.
* target-delegates.c: Re-generate.
* top.c (kill_or_detach): Pass inferior down to target_detach.
* windows-nat.c (windows_detach): Add inferior parameter.

Remove args from target detach

I was looking into adding a parameter to target_detach, and was
wondering what the args parameter was.  It seems like in the distant
past, it was possible to specify a signal number when detaching.  That
signal was injected in the process before it was detached.  There is an
example of code handling this in linux_nat_detach.  With today's GDB, I
can't get this to work.  Doing "detach 15" (15 == SIGTERM) doesn't work,
because detach is a prefix command and doesn't recognize the sub-command
15.  Doing "detach inferiors 15" doesn't work because it expects a list
of inferior id to detach.  Therefore, I don't think there's a way of
invoking detach_command with a non-NULL args.  I also didn't find any
documentation related to this feature.

I assume that this feature stopped working when detach was made a prefix
command, which is in f73adfeb8bae36885e6ea248d12223ab0d5eb9cb (sorry,
there's no commit title) from 2006.  Given that this feature was broken
for such a long time and we haven't heard anything (AFAIK, I did not
find any related bug), I think it's safe to remove it, as well as the
args parameter to target_detach.  If someone wants to re-introduce it, I
would suggest rethinking the user interface, and in particular would
suggest using signal name instead of numbers.

I tried to fix all the impacted code, but I might have forgotten some
spots.  It shouldn't be hard to fix if that's the case.  I also couldn't
build-test everything I changed, especially the nto and solaris stuff.

gdb/ChangeLog:

* target.h (struct target_ops) <to_detach>: Remove args
parameter.
(target_detach): Likewise.
* target.c (dispose_inferior): Adjust.
(target_detach): Remove args parameter, adjust.
* aix-thread.c (aix_thread_detach): Adjust.
* corefile.c (core_file_command): Adjust.
* corelow.c (core_detach): Adjust.
* darwin-nat.c (darwin_detach): Adjust.
* gnu-nat.c (gnu_detach): Adjust.
* inf-ptrace.c (inf_ptrace_detach): Adjust.
* infcmd.c (detach_command): Adjust
* infrun.c (follow_fork_inferior): Adjust.
(handle_vfork_child_exec_or_exit): Adjust.
* linux-fork.c (linux_fork_detach): Remove args parameter.
* linux-fork.h (linux_fork_detach): Likewise.
* linux-nat.c (linux_nat_detach): Likewise, and adjust.
* linux-thread-db.c (thread_db_detach): Likewise.
* nto-procfs.c (procfs_detach): Likewise.
* procfs.c (procfs_detach): Likewise.
(do_detach): Remove signo parameter.
* record.c (record_detach): Remove args parameter.
* record.h (record_detach): Likewise.
* remote-sim.c (gdbsim_detach): Likewise.
* remote.c (remote_detach_1): Likewise.
(remote_detach): Likewise.
(extended_remote_detach): Likewise.
* sol-thread.c (sol_thread_detach): Likewise.
* target-delegates.c: Re-generate.
* top.c (struct qt_args) <args>: Remove field.
(kill_or_detach): Don't pass args.
(quit_force): Don't set args.
* windows-nat.c (windows_detach): Remove args parameter.

[gas/ARM] Remove spurious comments

Remove spurious comments after the definition of ToC and ToU.

2018-01-19  Thomas Preud'homme  <thomas.preudhomme@arm.com>

gas/
* config/tc-arm.c (ToC macro): Remove spurious comment.
(ToU macro): Likewise.

S390: Improve comments for s390-tdbregs test case

This adds more explanation as to why the test case must be compiled with
the -msoft-float option.  It also documents the my_tbegin and my_tend
functions.

gdb/testsuite/ChangeLog:

* gdb.arch/s390-tdbregs.c (my_tbegin): Add comment documenting the
function.
(my_tend): Likewise.
* gdb.arch/s390-tdbregs.exp: Enhance comment; explain the
rationale of avoiding FP- and vector instructions.

Update French translation in bfd sub-directory

Don't pass -m32 to libcc1 on arm-linux

When I run gdb.compile/ tests on arm-linux, I get the following fails,

(gdb) compile code -- ;^M
arm-none-linux-gnueabihf-gcc: error: unrecognized command line option '-m32'; did you mean '-mbe32'?^M
Compilation failed.^M
(gdb) compile code (void) param^M
arm-none-linux-gnueabihf-gcc: error: unrecognized command line option '-m32'; did you mean '-mbe32'?^M
Compilation failed.^M
(gdb) FAIL: gdb.compile/compile-ops.exp: compile code (void) param

This patch fixes it by implementing gcc_target_options gdbarch method
for arm-linux to override option "-m32".

gdb:

2018-01-19  Yao Qi  <yao.qi@linaro.org>

* arm-linux-tdep.c (arm_linux_gcc_target_options): New function.
(arm_linux_init_abi): Install it.

Find arm-linux-gnueabi(hf)?-gcc in compile

GCC for arm-linux has different names on different distros.  It is
arm-linux-gnu-gcc on fedora.  Debian/Ubuntu has arm-linux-gnueabihf-gcc
and arm-linux-gnueabi-gcc.  So when I run gdb.compile/ tests on arm-linux,
I get,

(gdb) compile code -- ;
Could not find a compiler matching "^arm(-[^-]*)?-linux(-gnu)?-gcc$"

This patch extend the regexp to match both arm-linux-gnu-gcc and
arm-linux-gnueabihf-gcc.

gdb:

2018-01-19  Yao Qi  <yao.qi@linaro.org>

* osabi.c (gdb_osabi_names): Extend the regexp for
arm-linux-gnueabihf and arm-linux-gnueabi.

Make tests expect [ \t]+ pattern instead of \t for "info reg" command

This will allow to format output of "info reg" command as we wish,
without breaking the tests. In particular, it'll let us correctly align
raw and natural values of the registers using spaces instead of current
badly-working approach with tabs.

This change is forwards- and backwards-compatible, so that the amended
tests will work in the same way before and after reformatting patches
(unless the tests check formatting, of course, but I've not come across
any such tests).

Some tests already used this expected pattern, so they didn't
even have to be modified. Others are changed by this patch.

I've checked this on a i386 system, with no noticeable differences in
test results, so at least on i386 nothing seems to be broken by this.

gdb/testsuite/ChangeLog:

* gdb.arch/powerpc-d128-regs.exp: Replace expected "\[\t\]*" from
"info reg" with "\[ \t\]*".
* gdb.arch/altivec-regs.exp: Replace expected "\t" from "info reg" with
"\[ \t\]+".
* gdb.arch/s390-multiarch.exp: Ditto.
* gdb.base/pc-fp.exp: Ditto.
* gdb.reverse/i386-precsave.exp: Ditto.
* gdb.reverse/i386-reverse.exp: Ditto.
* gdb.reverse/i387-env-reverse.exp: Ditto.
* gdb.reverse/i387-stack-reverse.exp: Ditto.

Also xfail ld-elf/group1.d for Solaris

Also xfail ld-elf/group1.d for Solaris since _GLOBAL_OFFSET_TABLE_ is
always generated for Solaris as a global symbol after

.*: 0+1000 +0 +(NOTYPE|OBJECT) +WEAK +DEFAULT +. foo

instead of appending "#..." which will weaken the test.

* testsuite/ld-elf/group1.d: Also xfail Solaris.

x86: Update ld-elf/linkinfo1[ab].d for Solaris/x86

Update ld-elf/linkinfo1[ab].d to accommodate slightly different PLT/GOT
order/layout for Solaris/x86 targets.

* testsuite/ld-elf/linkinfo1a.d: Updated for slightly different
PLT/GOT order/layout for Solaris/x86 targets.
* testsuite/ld-elf/linkinfo1b.d: Likewise.

solaris2.em: Fold after_allocation into before_allocation

Since all ELF linkers call check_relocs after opening all inputs, we
can fold after_allocation into before_allocation so that local dynamic
symbols will be placed before global dynamic symbols in .dynsym section.
This fixed:

FAIL: Common symbol override test (auxiliary shared object build)
FAIL: ld-elf/pr19617a
FAIL: ld-elf/pr19698

for i386-solaris2.12 and x86_64-solaris2.12 targets.

PR ld/22728
* emultempl/solaris2.em (elf_solaris2_after_allocation): Fold
into ...
(elf_solaris2_before_allocation): This.
(LDEMUL_AFTER_ALLOCATION): Removed.

Automatic date update in version.in

GDB testsuite: Re-enable -fdiagnostics-color=never

In August 2017 the GDB test suite was changed to always add the compile
option "-fdiagnostics-color=never", see:

  https://sourceware.org/ml/gdb-patches/2017-08/msg00150.html

Since this option is not understood by rustc, a commit from 09/2017
dropped its use in that case:

  https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=5eb5f850
  ("Don't use -fdiagnostics-color=never for rustc")

But that change goes overboard and stops using the option for other
languages as well.  Thus compiler diagnostics written into gdb.log may
contain colored output again.  This is fixed.

gdb/testsuite/ChangeLog:

* lib/gdb.exp (gdb_compile): Re-enable use of
universal_compile_options for languages other than Rust.

S390: Use soft float in s390-tdbregs test case

The GDB test case s390-tdbregs.exp verifies GDB's handling of the
"transaction diagnostic block".  For simplicity, the test case uses the
"transaction begin" (TBEGIN) instruction with the "allow floating-point
operation" flag set to zero.  But some GCC versions may indeed emit
floating point or vector instructions for this test case.  If this happens
in the transaction, it aborts, and an endless loop results.

This change tells the compiler to produce a soft-float binary, so no
floating-point or vector registers are touched.

gdb/testsuite/ChangeLog:

* gdb.arch/s390-tdbregs.exp: Add the compile option -msoft-float.

Make abbrev_table::abbrevs private

abbrev_table::abbrevs is only access within abbrev_table's methods, so
it can be private.  Add "m_" prefix.

gdb:

2018-01-18  Yao Qi  <yao.qi@linaro.org>

* dwarf2read.c (abbrev_table) <abbrevs>: Rename it to
m_abbrevs.
(abbrev_table::add_abbrev): Update.
(abbrev_table::lookup_abbrev): Update.

Call cooked_read in ppu2spu_prev_register

The code in ppu2spu_prev_register is in fact regcache_cooked_read,
because spu doesn't have gdbarch method pseudo_register_read_value.

gdb:

2018-01-18  Yao Qi  <yao.qi@linaro.org>

* ppc-linux-tdep.c (ppu2spu_prev_register): Call cooked_read.

PowerPC PLT stub alignment fixes

Asking for ppc32 plt call stubs to be aligned at 32 byte boundaries
didn't quite work.  For ld.bfd they were spaced 32 bytes apart, but
only started on a 16 byte boundary.  ld.gold also didn't get it right.

Finding that bug made me check over the ppc64 plt stub alignment,
where I found that negative values for alignment (meaning align to
minimize boundary crossing) were not accepted.  Since no one has
complained about that, I guess I could have removed the feature from
ld.bfd documentation, but I've opted instead to correct the code.

I've also added an optional alignment paramenter for ppc32
--plt-align, for some consistency with gold and ppc64 ld.bfd.

bfd/
* elf32-ppc.c (ppc_elf_create_glink): Correct alignment of .glink.
* elf64-ppc.c (ppc64_elf_size_stubs): Handle negative plt_stub_align.
(ppc64_elf_build_stubs): Likewise.
gold/
* powerpc.cc (param_plt_align): New function supplying default
--plt-align values.  Use it..
(Stub_table::plt_call_align): ..here, and..
(Output_data_glink::global_entry_align): ..here.
(Stub_table::stub_align): Correct 32-bit minimum alignment.
ld/
* emultempl/ppc32elf.em: Support optional --plt-align arg.
* emultempl/ppc64elf.em: Support negative --plt-align arg.

Update Bulgarian translation of the binutils sub-directory

Automatic date update in version.in