[AArch64][SVE 15/32] Add {insert,extract}_all_fields helpers

Several of the SVE operands use the aarch64_operand fields array
to store the fields that make up the operand, rather than hard-coding
the names in the C code.  This patch adds helpers for inserting and
extracting those fields.

opcodes/
* aarch64-asm.c: Include libiberty.h.
(insert_fields): New function.
(aarch64_ins_imm): Use it.
* aarch64-dis.c (extract_fields): New function.
(aarch64_ext_imm): Use it.

[AArch64][SVE 14/32] Make aarch64_logical_immediate_p take an element size

SVE supports logical immediate operations on 8-bit, 16-bit and 32-bit
elements, treating them as aliases of operations on 64-bit elements in
which the immediate is replicated.  This patch therefore replaces the
"32-bit/64-bit" input to aarch64_logical_immediate_p with a more
general "number of bytes" input.

opcodes/
* aarch64-opc.c (aarch64_logical_immediate_p): Replace is32
with an esize parameter.
(operand_general_constraint_met_p): Update accordingly.
Fix misindented code.
* aarch64-asm.c (aarch64_ins_limm): Update call to
aarch64_logical_immediate_p.

[AArch64][SVE 13/32] Add an F_STRICT flag

SVE predicate operands can appear in three forms:

1. unsuffixed: "Pn"
2. with a predication type: "Pn/[ZM]"
3. with a size suffix: "Pn.[BHSD]"

No variation is allowed: unsuffixed operands cannot have a (redundant)
suffix, and the suffixes can never be dropped.  Unsuffixed Pn are used
in LDR and STR, but they are also used for Pg operands in cases where
the result is scalar and where there is therefore no choice to be made
between "merging" and "zeroing".  This means that some Pg operands have
suffixes and others don't.

It would be possible to use context-sensitive parsing to handle
this difference.  The tc-aarch64.c code would then raise an error
if the wrong kind of suffix is used for a particular instruction.

However, we get much more user-friendly error messages if we parse
all three forms for all SVE instructions and record the suffix as a
qualifier.  The normal qualifier matching code can then report cases
where the wrong kind of suffix is used.  This is a slight extension
of existing usage, which really only checks for the wrong choice of
suffix within a particular kind of suffix.

The only catch is a that a "NIL" entry in the qualifier list
specifically means "no suffix should be present" (case 1 above).
NIL isn't a wildcard here.  It also means that an instruction that
requires all-NIL qualifiers can fail to match (because a suffix was
supplied when it shouldn't have been); this requires a slight change
to find_best_match.

This patch adds an F_STRICT flag to select this behaviour.
The flag will be set for all SVE instructions.  The behaviour
for other instructions doesn't change.

include/
* opcode/aarch64.h (F_STRICT): New flag.

opcodes/
* aarch64-opc.c (match_operands_qualifier): Handle F_STRICT.

gas/
* config/tc-aarch64.c (find_best_match): Simplify, allowing an
instruction with all-NIL qualifiers to fail to match.

[AArch64][SVE 12/32] Remove boolean parameters from parse_address_main

In the review of the original version of this series, Richard didn't
like the use of boolean parameters to parse_address_main.  I think we
can just get rid of them and leave the callers to check the addressing
modes.  As it happens, the handling of ADDR_SIMM9{,_2} already did this
for relocation operators (i.e. it used parse_address_reloc and then
rejected relocations).

The callers are already set up to reject invalid register post-indexed
addressing, so we can simply remove the accept_reg_post_index parameter
without adding any more checks.  This again creates a corner case where:

.equ x2, 1
ldr w0, [x1], x2

was previously an acceptable way of writing "ldr w0, [x1], #1" but
is now rejected.

Removing the "reloc" parameter means that two cases need to check
explicitly for relocation operators.

ADDR_SIMM9_2 appers to be unused.  I'll send a separate patch
to remove it.

This patch makes parse_address temporarily equivalent to
parse_address_main, but later patches in the series will need
to keep the distinction.

gas/
* config/tc-aarch64.c (parse_address_main): Remove reloc and
accept_reg_post_index parameters.  Parse relocations and register
post indexes unconditionally.
(parse_address): Remove accept_reg_post_index parameter.
Update call to parse_address_main.
(parse_address_reloc): Delete.
(parse_operands): Call parse_address instead of parse_address_main.
Update existing callers of parse_address and make them check
inst.reloc.type where appropriate.
* testsuite/gas/aarch64/diagnostic.s: Add tests for relocations
in ADDR_SIMPLE, SIMD_ADDR_SIMPLE, ADDR_SIMM7 and ADDR_SIMM9 addresses.
Also test for invalid uses of post-index register addressing.
* testsuite/gas/aarch64/diagnostic.l: Update accordingly.

[AArch64][SVE 11/32] Tweak aarch64_reg_parse_32_64 interface

aarch64_reg_parse_32_64 is currently used to parse address registers,
among other things.  It returns two bits of information about the
register: whether it's W rather than X, and whether it's a zero register.

SVE adds addressing modes in which the base or offset can be a vector
register instead of a scalar, so a choice between W and X is no longer
enough.  It's more convenient to pass the type of register around as
a qualifier instead.

As it happens, two callers of aarch64_reg_parse_32_64 already wanted
the information in the form of a qualifier, so the change feels pretty
natural even without SVE.

Also, the function took two parameters to control whether {W}SP
and (W|X)ZR should be accepted.  We tend to get slightly better
error messages by accepting them regardless and getting the caller
to do the check, rather than potentially treating "xzr", "sp" etc.
as constants.  This is easier to do if the function returns the
reg_entry rather than just the register number.

This does create a corner case where:

.equ sp, 1
ldr w0, [x0, sp]

was previously an acceptable way of writing "ldr w0, [x0, #1]",
but I don't think it's important to continue supporting that.
We already rejected things like:

.equ sp, 1
add x0, x1, sp

To ensure these new error messages "win" when matching against
several candidate instruction entries, we need to use the same
address-parsing code for all addresses, including ADDR_SIMPLE
and SIMD_ADDR_SIMPLE.  The next patch also relies on this.

Finally, aarcch64_check_reg_type was written in a pretty
conservative way.  It should always be equivalent to a single
bit test.

gas/
* config/tc-aarch64.c (REG_TYPE_R_Z, REG_TYPE_R_SP): New register
types.
(get_reg_expected_msg): Handle them and REG_TYPE_R64_SP.
(aarch64_check_reg_type): Simplify.
(aarch64_reg_parse_32_64): Return the reg_entry instead of the
register number.  Return the type as a qualifier rather than an
"isreg32" boolean.  Remove reject_sp, reject_rz and isregzero
parameters.
(parse_shifter_operand): Update call to aarch64_parse_32_64_reg.
Use get_reg_expected_msg.
(parse_address_main): Likewise.  Use aarch64_check_reg_type.
(po_int_reg_or_fail): Replace reject_sp and reject_rz parameters
with a reg_type parameter.  Update call to aarch64_parse_32_64_reg.
Use aarch64_check_reg_type to test the result.
(parse_operands): Update after the above changes.  Parse ADDR_SIMPLE
addresses normally before enforcing the syntax restrictions.
* testsuite/gas/aarch64/diagnostic.s: Add tests for a post-index
zero register and for a stack pointer index.
* testsuite/gas/aarch64/diagnostic.l: Update accordingly.
Also update existing diagnostic messages after the above changes.
* testsuite/gas/aarch64/illegal-lse.l: Update the error message
for 32-bit register bases.

[AArch64][SVE 10/32] Move range check out of parse_aarch64_imm_float

Since some SVE constants are no longer explicitly tied to the 8-bit
FP immediate format, it seems better to move the range checks out of
parse_aarch64_imm_float and into the callers.

gas/
* config/tc-aarch64.c (parse_aarch64_imm_float): Remove range check.
(parse_operands): Check the range of 8-bit FP immediates here instead.

[AArch64][SVE 09/32] Improve error messages for invalid floats

Previously:

        fmov d0, #2

would give an error:

        Operand 2 should be an integer register

whereas the user probably just forgot to add the ".0" to make:

        fmov d0, #2.0

This patch reports an invalid floating point constant unless the
operand is obviously a register.

The FPIMM8 handling is only relevant for SVE.  Without it:

        fmov z0, z1

would try to parse z1 as an integer immediate zero (the res2 path),
whereas it's more likely that the user forgot the predicate.  This is
tested by the final patch.

gas/
* config/tc-aarch64.c (parse_aarch64_imm_float): Report a specific
low-severity error for registers.
(parse_operands): Report an invalid floating point constant for
if parsing an FPIMM8 fails, and if no better error has been
recorded.
* testsuite/gas/aarch64/diagnostic.s,
testsuite/gas/aarch64/diagnostic.l: Add tests for integer operands
to FMOV.

[AArch64][SVE 08/32] Generalise aarch64_double_precision_fmovable

SVE has single-bit floating-point constants that don't really
have any relation to the AArch64 8-bit floating-point encoding.
(E.g. one of the constants selects between 0 and 1.)  The easiest
way of representing them in the aarch64_opnd_info seemed to be
to use the IEEE float representation directly, rather than invent
some new scheme.

This patch paves the way for that by making the code that converts IEEE
doubles to IEEE floats accept any value in the range of an IEEE float,
not just zero and 8-bit floats.  It leaves the range checking to the
caller (which already handles it).

gas/
* config/tc-aarch64.c (aarch64_double_precision_fmovable): Rename
to...
(can_convert_double_to_float): ...this.  Accept any double-precision
value that converts to single precision without loss of precision.
(parse_aarch64_imm_float): Update accordingly.

[AArch64][SVE 07/32] Replace hard-coded uses of REG_TYPE_R_Z_BHSDQ_V

To remove parsing ambiguities and to avoid register names being
accidentally added to the symbol table, the immediate parsing
routines reject things like:

.equ x0, 0
add v0.4s, v0.4s, x0

An explicit '#' must be used instead:

.equ x0, 0
add v0.4s, v0.4s, #x0

Of course, it wasn't possible to predict what other register
names might be added in future, so this behaviour was restricted
to the register names that were defined at the time.  For backwards
compatibility, we should continue to allow things like:

.equ p0, 0
add v0.4s, v0.4s, p0

even though p0 is now an SVE register.

However, it seems reasonable to extend the x0 behaviour above to
SVE registers when parsing SVE instructions, especially since none
of the SVE immediate formats are relocatable.  Doing so removes the
same parsing ambiguity for SVE instructions as the x0 behaviour removes
for base AArch64 instructions.

As a prerequisite, we then need to be able to tell the parsing routines
which registers to reject.  This patch changes the interface to make
that possible, although the set of rejected registers doesn't change
at this stage.

gas/
* config/tc-aarch64.c (parse_immediate_expression): Add a
reg_type parameter.
(parse_constant_immediate): Likewise, and update calls.
(parse_aarch64_imm_float): Likewise.
(parse_big_immediate): Likewise.
(po_imm_nc_or_fail): Update accordingly, passing down a new
imm_reg_type variable.
(po_imm_of_fail): Likewise.
(parse_operands): Likewise.

[AArch64][SVE 06/32] Generalise parse_neon_reg_list

Rename parse_neon_reg_list to parse_vector_reg_list and take
in the required register type as an argument.  Later patches
will reuse the function for SVE registers.

gas/
* config/tc-aarch64.c (parse_neon_reg_list): Rename to...
(parse_vector_reg_list): ...this and take a register type
as input.
(parse_operands): Update accordingly.

[AArch64][SVE 05/32] Rename parse_neon_type_for_operand

Generalise the name of parse_neon_type_for_operand to
parse_vector_type_for_operand.  Later patches will add SVEisms to it.

gas/
* config/tc-aarch64.c (parse_neon_type_for_operand): Rename to...
(parse_vector_type_for_operand): ...this.
(parse_typed_reg): Update accordingly.

[AArch64][SVE 04/32] Rename neon_type_el to vector_type_el

Similar to the previous patch, but this time for the neon_type_el
structure.

gas/
* config/tc-aarch64.c (neon_type_el): Rename to...
(vector_type_el): ...this.
(parse_neon_type_for_operand): Update accordingly.
(parse_typed_reg): Likewise.
(aarch64_reg_parse): Likewise.
(vectype_to_qualifier): Likewise.
(parse_operands): Likewise.
(eq_neon_type_el): Likewise.  Rename to...
(eq_vector_type_el): ...this.
(parse_neon_reg_list): Update accordingly.

[AArch64][SVE 03/32] Rename neon_el_type to vector_el_type

Later patches will add SVEisms to neon_el_type, so this patch renames
it to something more generic.

gas/
* config/tc-aarch64.c (neon_el_type: Rename to...
(vector_el_type): ...this.
(neon_type_el): Update accordingly.
(parse_neon_type_for_operand): Likewise.
(vectype_to_qualifier): Likewise.

[AArch64][SVE 02/32] Avoid hard-coded limit in indented_print

The maximum indentation needed by aarch64-gen.c grows as more
instructions are added to aarch64-tbl.h.  Rather than having to
increase the indentation limit to a higher value, it seemed better
to replace it with "%*s".

opcodes/
* aarch64-gen.c (indented_print): Avoid hard-coded indentation limit.

[AArch64][SVE 01/32] Remove parse_neon_operand_type

A false return from parse_neon_operand_type had an overloaded
meaning: either the parsing failed, or there was nothing to parse
(which isn't necessarily an error).  The only caller, parse_typed_reg,
would therefore not consume the suffix if it was invalid but instead
(successfully) parse the register without a suffix.  It would still
leave inst.parsing_error with an error about the invalid suffix.

It seems wrong for a successful parse to leave an error message,
so this patch makes parse_typed_reg return PARSE_FAIL instead.

The patch doesn't seem to make much difference in practice.
Most possible follow-on errors use set_first_error and so the
error about the suffix tended to win despite the successful parse.

gas/
* config/tc-aarch64.c (parse_neon_operand_type): Delete.
(parse_typed_reg): Call parse_neon_type_for_operand directly.

MIPS/testsuite: mips16-thunks: Use `standard_output_file'

Correct a commit 2151ccc56c74 ("Always organize test artifacts in a
directory hierarchy") regression causing:

Running .../gdb/testsuite/gdb.arch/mips16-thunks.exp ...
gdb compile failed, Assembler messages:
Fatal error: can't create .../gdb/testsuite/gdb.arch/mips16-thunks-inmain.o: No such file or directory
gdb compile failed, Assembler messages:
Fatal error: can't create .../gdb/testsuite/gdb.arch/mips16-thunks-main.o: No such file or directory
gdb compile failed, mips-mti-linux-gnu-gcc: error: .../gdb/testsuite/gdb.arch/mips16-thunks-inmain.o: No such file or directory
mips-mti-linux-gnu-gcc: error: .../gdb/testsuite/gdb.arch/mips16-thunks-main.o: No such file or directory
UNSUPPORTED: gdb.arch/mips16-thunks.exp: No MIPS16 support in the toolchain.

by using `standard_output_file' to construct output file names
throughout.

gdb/testsuite/
* gdb.arch/mips16-thunks.exp: Use `standard_output_file'
throughout.

Keep reserved bits in CPSR on write

In patch https://sourceware.org/ml/gdb-patches/2016-04/msg00529.html
I cleared reserved bits when reading CPSR.  It makes a problem that
these bits (zero) are written back to kernel through ptrace, and it
changes the state of the processor on some recent kernel, which is
unexpected.

In this patch, I keep these reserved bits when write CPSR back to
hardware.

gdb:

2016-09-21  Yao Qi  <yao.qi@linaro.org>

* aarch32-linux-nat.c (aarch32_gp_regcache_collect): Keep
bits 20 to 23.

gdb/gdbserver:

2016-09-21  Yao Qi  <yao.qi@linaro.org>

* linux-aarch32-low.c (arm_fill_gregset): Keep bits 20 to
23.

Automatic date update in version.in

Avoid -Wduplicated-cond warnings in gdb/python

I tried building gdb with -Wduplicated-cond.  This patch fixes the
simpler issue that was found.

In Python 3, "int" and "long" are synonyms, so code like:

      else if (PyLong_Check (obj))
...
      else if (PyInt_Check (obj))

.... will trigger this warning.  The fix is to conditionalize the
PyInt_Check branches on Python 2.

Tested by rebuilding, with both version of Python, on x86-64 Fedora 24.

2016-09-20  Tom Tromey  <tom@tromey.com>

* python/py-value.c (convert_value_from_python): Make PyInt_Check
conditional on Python 2.
* python/py-arch.c (archpy_disassemble): Make PyInt_Check
conditional on Python 2.

ppc: Fix record support of Store String Word instructions

gdb/ChangeLog
2016-09-20  Edjunior Barbosa Machado  <emachado@linux.vnet.ibm.com>

* rs6000-tdep.c (ppc_process_record_op31): Fix record of Store String
Word instructions.

ld: Fix mistake in ChangeLog

The previous commit contained a small mistake in the ChangeLog, fixed in
this commit.

ld: Extend documentation for EXCLUDE_FILE

There was a gap in the documentation of EXCLUDE_FILE that could cause
confusion to a user.  When writing an input section specifier like this:

    *(EXCLUDE_FILE (somefile.o) .text .text.*)

this could mean one of the following:

   1. All '.text' and '.text.*' from all files except for 'somefile.o',
   or
   2. All '.text' from all files except 'somefile.o', and all '.text.*'
   sections from all files.

It turns out that the second interpretation is correct, but the manual
does not make this clear (to me at least).  Hopefully this patch makes
things clearer.

ld/ChangeLog:

* ld/ld.texinfo (Input Section Basics): Expand the description of
EXCLUDE_FILE.

Use 'event_ptid' instead of 'resume_ptid' on startup_inferior (fix for regression on my last commit)

Pedro pointed out a regression happening on gdb.mi/mi-exec-run.exp,
and as it turned out, this was a thinko when dealing with some events
on startup_inferior.  Basically, one needs to pass 'event_ptid' to
target_mourn_inferior, but I mistakenly passed 'resume_ptid'.

This commit fixes it.

Built and regtested on BuildBot, now with fixed e-mail notifications!

gdb/ChangeLog:
2016-09-20  Sergio Durigan Junior  <sergiodj@redhat.com>

* fork-inferior.c (startup_inferior): Pass 'event_ptid' instead of
'resume_ptid' to 'target_mourn_inferior'.  Fix regression
introduced by my last commit.

Automatic date update in version.in

gdb: Fix build breakage with GCC 4.1 and --disable-nls

Ref: https://sourceware.org/ml/gdb-patches/2016-09/msg00203.html

The std::{min,max} patch caused build failures when configuring GDB
with with --disable-nls and using GCC 4.1.

The reason is this bit in common/gdb_locale.h:

 #ifdef ENABLE_NLS
 ...
 #else
 # define gettext(Msgid) (Msgid)
 ...
 #endif

This causes problems if the <libintl.h> header is first included at
any point after "gdb_locale.h".

Specifically, the gettext&co declarations in libintl.h:

 extern char *gettext (__const char *__msgid)
      __THROW __attribute_format_arg__ (1);

end up broken after preprocessing:

 extern char *(__const char *__msgid)
      throw () __attribute__ ((__format_arg__ (1)));

After the std::min/std::max change to include <algorithm>, this now
happens with at least the GCC 4.1 copy of <algorithm>, which includes
<libintl.h> via <bits/stl_algobase.h>, <iosfwd>, and
<bits/c++locale.h>.

The fix is to simply remove the troublesome *gettext and *textdomain
macros, leaving only the _ and N_ ones.

gdb/ChangeLog:
2016-09-19  Pedro Alves  <palves@redhat.com>

* common/gdb_locale.h [!ENABLE_NLS] (gettext, dgettext, dcgettext,
textdomain, bindtextdomain): Delete macros.
* main.c (captured_main) [!ENABLE_NLS]: Skip bintextdomain and
textdomain calls.

bfd: allow negative offsets to _GLOBAL_OFFSET_TABLE_ in elf64 SPARC

The code compiled with the -fpic model in SPARC uses 13-bit signed
immediate PC-relative loads to fetch entries from the GOT table.  In
theory this would allow using a GOT table (.got section) containing up
to 1024 entries in elf32 or 512 entries in elf64.

However, in elf64 sparc GNU targets _GLOBAL_OFFSET_TABLE_ is always
placed at the beginning of the .got section, making it impossible to use
negative offsets.  This limits the usage of -fpic to GOT tables
containing a maximum of 257 entries in elf64.

This patch activates an optimization that is already used in sparc-elf32
also in sparc-elf64, that sets _GLOBAL_OFFSET_TABLE_ to point 0x1000
into the .got section if the section size is bigger than 0x1000.

2016-09-19  Jose E. Marchesi  <jose.marchesi@oracle.com>

* elfxx-sparc.c (_bfd_sparc_elf_size_dynamic_sections): Allow
negative offsets to _GLOBAL_OFFSET_TABLE_ if the .got section is
bigger than 0x1000 bytes.

nm handling of synthetic symbols

Symbol sorting means we can't assume that the last n symbols are
synthetic.

* nm.c (print_symbol): Remove is_synthetic param.  Test sym->flags
instead.
(print_size_symbols, print_symbols): Adjust to suit, deleting
now unused synth_count param and fromsynth var.
(display_rel_file): Adjust, localizing synth_count.

Consolidate target_mourn_inferior between GDB and gdbserver

This patch consolidates the API of target_mourn_inferior between GDB
and gdbserver, in my continuing efforts to make sharing the
fork_inferior function possible between both.

GDB's version of the function did not care about the inferior's ptid
being mourned, but gdbserver's needed to know this information.  Since
it actually makes sense to pass the ptid as an argument, instead of
depending on a global value directly (which GDB's version did), I
decided to make the generic API to accept it.  I then went on and
extended all calls being made on GDB to include a ptid argument (which
ended up being inferior_ptid most of the times, anyway), and now we
have a more sane interface.

On GDB's side, after talking to Pedro a bit about it, we decided that
just an assertion to make sure that the ptid being passed is equal to
inferior_ptid would be enough for now, on the GDB side.  We can remove
the assertion and perform more operations later if we ever pass
anything different than inferior_ptid.

Regression tested on our BuildBot, everything OK.

I'd appreciate a special look at gdb/windows-nat.c's modification
because I wasn't really sure what to do there.  It seemed to me that
maybe I should build a ptid out of the process information there, but
then I am almost sure the assertion on GDB's side would trigger.

gdb/ChangeLog:
2016-09-19  Sergio Durigan Junior  <sergiodj@redhat.com>

* darwin-nat.c (darwin_kill_inferior): Adjusting call to
target_mourn_inferior to include ptid_t argument.
* fork-child.c (startup_inferior): Likewise.
* gnu-nat.c (gnu_kill_inferior): Likewise.
* inf-ptrace.c (inf_ptrace_kill): Likewise.
* infrun.c (handle_inferior_event_1): Likewise.
* linux-nat.c (linux_nat_attach): Likewise.
(linux_nat_kill): Likewise.
* nto-procfs.c (interrupt_query): Likewise.
(procfs_interrupt): Likewise.
(procfs_kill_inferior): Likewise.
* procfs.c (procfs_kill_inferior): Likewise.
* record.c (record_mourn_inferior): Likewise.
* remote-sim.c (gdbsim_kill): Likewise.
* remote.c (remote_detach_1): Likewise.
(remote_kill): Likewise.
* target.c (target_mourn_inferior): Change declaration to accept
new ptid_t argument; use gdb_assert on it.
* target.h (target_mourn_inferior): Move function prototype from
here...
* target/target.h (target_mourn_inferior): ... to here.  Adjust it
to accept new ptid_t argument.
* windows-nat.c (get_windows_debug_event): Adjusting call to
target_mourn_inferior to include ptid_t argument.

gdb/gdbserver/ChangeLog:
2016-09-19  Sergio Durigan Junior  <sergiodj@redhat.com>

* server.c (start_inferior): Call target_mourn_inferior instead of
mourn_inferior; pass ptid_t argument to it.
(resume): Likewise.
(handle_target_event): Likewise.
* target.c (target_mourn_inferior): New function.
* target.h (mourn_inferior): Delete macro.

Automatic date update in version.in

gdb/s390: Fix build breakage due to std::min/std::max usage without header

  [...]
  .../gdb/s390-linux-nat.c: In function 'void s390_prepare_to_resume(lwp_info*)':
  .../gdb/s390-linux-nat.c:703:20: error: 'min' is not a member of 'std'
      watch_lo_addr = std::min (watch_lo_addr, area->lo_addr);
  [...]

gdb/ChangeLog:
2016-09-18  Pedro Alves  <palves@redhat.com>

* s390-linux-nat.c: Include <algorithm>.

gdb: Fix std::{min, max}-related build breakage on 32-bit hosts

Building on a 32-bit host fails currently with errors like:

  .../src/gdb/exec.c: In function ‘target_xfer_status section_table_read_available_memory(gdb_byte*, ULONGEST, ULONGEST, ULONGEST*)’:
  .../src/gdb/exec.c:801:54: error: no matching function for call to ‘min(ULONGEST, long unsigned int)’
      end = std::min (offset + len, r->start + r->length);
^
  In file included from /usr/include/c++/5.3.1/algorithm:61:0,
   from .../src/gdb/exec.c:46:
  /usr/include/c++/5.3.1/bits/stl_algobase.h:195:5: note: candidate: template<class _Tp> const _Tp& std::min(const _Tp&, const _Tp&)
       min(const _Tp& __a, const _Tp& __b)
       ^
  /usr/include/c++/5.3.1/bits/stl_algobase.h:195:5: note:   template argument deduction/substitution failed:
  .../src/gdb/exec.c:801:54: note:   deduced conflicting types for parameter ‘const _Tp’ (‘long long unsigned int’ and ‘long unsigned int’)
      end = std::min (offset + len, r->start + r->length);
^
  In file included from /usr/include/c++/5.3.1/algorithm:61:0,
   from .../src/gdb/exec.c:46:
  /usr/include/c++/5.3.1/bits/stl_algobase.h:243:5: note: candidate: template<class _Tp, class _Compare> const _Tp& std::min(const _Tp&, const _Tp&, _Compare)
       min(const _Tp& __a, const _Tp& __b, _Compare __comp)
       ^

The problem is that the std::min/std::max function templates use the
same type for both parameters.  When the argument types are different,
the compiler can't automatically deduce which template specialization
to pick from the arguments' types.

Fix that by specifying the specialization we want explicitly.

gdb/ChangeLog:
2016-09-18  Pedro Alves  <palves@redhat.com>

* breakpoint.c (hardware_watchpoint_inserted_in_range): Explicitly
specify the std:min/std::max specialization.
* exec.c (section_table_read_available_memory): Likewise.
* remote.c (remote_read_qxfer): Likewise.
* target.c (simple_verify_memory): Likewise.

Automatic date update in version.in

Improve MinGW support in Readline

These changes were already accepted upstream in Readline,
but GDB did not yet import a newer Readline version.

readline/Changelog.gdb:

* util.c: Include rlshell.h.
(_rl_tropen) [_WIN32 && !__CYGWIN__]: Open the trace file in the
user's temporary directory.
* tcap.h [HAVE_NCURSES_TERMCAP_H]: Include ncurses/termcap.h.
* input.c (w32_isatty) [_WIN32 && !__CYGWIN__]: New function, to
replace isatty that is not reliable enough on MS-Windows.
(isatty) [_WIN32 && !__CYGWIN__]: Redirect to w32_isatty.
(rl_getc): Call _getch, not getch, which could be an ncurses
function when linked with ncurses, in which case getch will return
EOF for any keystroke, because there's no curses window.
* tilde.c (tilde_expand_word) [_WIN32]:
* histfile.c (history_filename) [_WIN32]: Windows-specific
environment variable to replace HOME if that is undefined.
* funmap.c (default_funmap): Compile rl_paste_from_clipboard on
all Windows platforms, not just Cygwin.
* readline.h (rl_paste_from_clipboard): Include declaration for
all Windows platforms.
* display.c (insert_some_chars, delete_chars): Don't use the
MinGW-specific code if linked with ncurses.
* configure.in:
* config.h.in: Support ncurses/termcap.h.  The configure script
was updated accordingly.
* complete.c [_WIN32 && !__CYGWIN__]: Initialize
_rl_completion_case_fold to 1.
(printable_part, rl_filename_completion_function)
[_WIN32 && !__CYGWIN__]: Handle the drive letter.

Automatic date update in version.in

Introduce cleanup to restore current_uiout

Make a globally available cleanup from a pre-existing one in infrun.c.
This is used in a following patch.

gdb/ChangeLog:

* infrun.c (restore_current_uiout_cleanup): Move to ui-out.c.
(print_stop_event): Use make_cleanup_restore_current_uiout.
* python/python.c (execute_gdb_command): Likewise.
* ui-out.c (restore_current_uiout_cleanup): Move from infrun.c.
(make_cleanup_restore_current_uiout): New function definition.
* ui-out.h (make_cleanup_restore_current_uiout): New function
declaration.
* utils.c (do_restore_ui_out): Remove.
(make_cleanup_restore_ui_out): Remove.
* utils.h (make_cleanup_restore_ui_out): Remove.

gdb: Use std::min and std::max throughout

Otherwise including <string> or some other C++ header is broken.
E.g.:

  In file included from /opt/gcc/include/c++/7.0.0/bits/char_traits.h:39:0,
   from /opt/gcc/include/c++/7.0.0/string:40,
   from /home/pedro/gdb/mygit/cxx-convertion/src/gdb/infrun.c:68:
  /opt/gcc/include/c++/7.0.0/bits/stl_algobase.h:243:56: error: macro "min" passed 3 arguments, but takes just 2
       min(const _Tp& __a, const _Tp& __b, _Compare __comp)
  ^
  /opt/gcc/include/c++/7.0.0/bits/stl_algobase.h:265:56: error: macro "max" passed 3 arguments, but takes just 2
       max(const _Tp& __a, const _Tp& __b, _Compare __comp)
  ^
  In file included from .../src/gdb/infrun.c:21:0:

To the best of my grepping abilities, I believe I adjusted all min/max
calls.

gdb/ChangeLog:
2016-09-16  Pedro Alves  <palves@redhat.com>

* defs.h (min, max): Delete.
* aarch64-tdep.c: Include <algorithm> and use std::min and
std::max throughout.
* aarch64-tdep.c: Likewise.
* alpha-tdep.c: Likewise.
* amd64-tdep.c: Likewise.
* amd64-windows-tdep.c: Likewise.
* arm-tdep.c: Likewise.
* avr-tdep.c: Likewise.
* breakpoint.c: Likewise.
* btrace.c: Likewise.
* ctf.c: Likewise.
* disasm.c: Likewise.
* doublest.c: Likewise.
* dwarf2loc.c: Likewise.
* dwarf2read.c: Likewise.
* environ.c: Likewise.
* exec.c: Likewise.
* f-exp.y: Likewise.
* findcmd.c: Likewise.
* ft32-tdep.c: Likewise.
* gcore.c: Likewise.
* hppa-tdep.c: Likewise.
* i386-darwin-tdep.c: Likewise.
* i386-tdep.c: Likewise.
* linux-thread-db.c: Likewise.
* lm32-tdep.c: Likewise.
* m32r-tdep.c: Likewise.
* m88k-tdep.c: Likewise.
* memrange.c: Likewise.
* minidebug.c: Likewise.
* mips-tdep.c: Likewise.
* moxie-tdep.c: Likewise.
* nds32-tdep.c: Likewise.
* nios2-tdep.c: Likewise.
* nto-procfs.c: Likewise.
* parse.c: Likewise.
* ppc-sysv-tdep.c: Likewise.
* probe.c: Likewise.
* record-btrace.c: Likewise.
* remote.c: Likewise.
* rs6000-tdep.c: Likewise.
* rx-tdep.c: Likewise.
* s390-linux-nat.c: Likewise.
* s390-linux-tdep.c: Likewise.
* ser-tcp.c: Likewise.
* sh-tdep.c: Likewise.
* sh64-tdep.c: Likewise.
* source.c: Likewise.
* sparc-tdep.c: Likewise.
* symfile.c: Likewise.
* target-memory.c: Likewise.
* target.c: Likewise.
* tic6x-tdep.c: Likewise.
* tilegx-tdep.c: Likewise.
* tracefile-tfile.c: Likewise.
* tracepoint.c: Likewise.
* valprint.c: Likewise.
* value.c: Likewise.
* xtensa-tdep.c: Likewise.
* cli/cli-cmds.c: Likewise.
* compile/compile-object-load.c: Likewise.

S390: Hardware breakpoint support

Add hardware breakpoint support for S390 targets.

gdb/ChangeLog:

* s390-linux-nat.c (PER_BIT, PER_EVENT_BRANCH, PER_EVENT_IFETCH)
(PER_EVENT_STORE, PER_EVENT_NULLIFICATION)
(PER_CONTROL_BRANCH_ADDRESS, PER_CONTROL_SUSPENSION)
(PER_CONTROL_ALTERATION): New macros.
(struct s390_debug_reg_state) <break_areas>: New member.
(s390_forget_process): Free break_areas as well.
(s390_linux_new_fork): Copy break_areas as well.
(s390_prepare_to_resume): Install hardware breakpoints.
(s390_can_use_hw_breakpoint): Indicate support for hardware
breakpoints.
(s390_insert_hw_breakpoint, s390_remove_hw_breakpoint): New
linux_nat target methods.
(_initialize_s390_nat): Register them.

gdb/testsuite/ChangeLog:

* lib/gdb.exp: No longer skip hardware breakpoint tests on s390.

linux-nat: Add function lwp_is_stepping

Add the function lwp_is_stepping which indicates whether the given LWP
is currently single-stepping.  This is a common interface, usable from
native GDB as well as from gdbserver.

gdb/gdbserver/ChangeLog:

* linux-low.c (lwp_is_stepping): New function.

gdb/ChangeLog:

* nat/linux-nat.h (lwp_is_stepping): New declaration.
* linux-nat.c (lwp_is_stepping): New function.

S390: Enable "maint set show-debug-regs"

Implement a new function for dumping the S390 "debug
registers" (actually, the PER info) and invoke it at appropriate places.
Respect the variable show_debug_regs and make it settable by the user.

gdb/ChangeLog:

* s390-linux-nat.c (gdbcmd.h): New include.
(s390_show_debug_regs): New function.
(s390_stopped_by_watchpoint): Call it, if show_debug_regs is set.
(s390_prepare_to_resume): Likewise.
(_initialize_s390_nat): Register the command "maint set
show-debug-regs".

S390: Multi-inferior watchpoint support

Support different sets of watchpoints in multiple inferiors.

gdb/ChangeLog:

* s390-linux-nat.c (watch_areas): Remove variable.  Replace by a
member of...
(struct s390_debug_reg_state): ...this.  New struct.
(struct s390_process_info): New struct.
(s390_process_list): New variable.
(s390_find_process_pid, s390_add_process, s390_process_info_get)
(s390_get_debug_reg_state): New functions.
(s390_stopped_by_watchpoint): Now access the watch_areas VEC via
s390_get_debug_reg_state.
(s390_prepare_to_resume): Likewise.
(s390_insert_watchpoint): Likewise.
(s390_remove_watchpoint): Likewise.
(s390_forget_process, s390_linux_new_fork): New linux_nat target
methods.
(_initialize_s390_nat): Register them.

S390: Migrate watch areas from list to VEC type

For S390, the list of active watchpoints is maintained in a list based
at "watch_base".  This refactors the list to a vector "watch_areas".

gdb/ChangeLog:

* s390-linux-nat.c (s390_watch_area): New typedef.  Define a VEC.
(watch_base): Remove variable.
(watch_areas): New variable.
(s390_stopped_by_watchpoint): Transform operations on the
watch_base list to equivalent operations on the watch_areas VEC.
(s390_prepare_to_resume): Likewise.
(s390_insert_watchpoint): Likewise.
(s390_remove_watchpoint): Likewise.

S390: Avoid direct access to lwp_info structure

When using the lwp_info structure, avoid accessing its members directly,
and use the advertised function interfaces instead.  This is according
to the instructions in linux-nat.h and prepares for making some of the
code common between gdb and gdbserver.

gdb/ChangeLog:

* s390-linux-nat.c (s390_prepare_to_resume): Use advertised lwp
functions instead of accessing lwp_info structure members.
(s390_mark_per_info_changed): New function.
(s390_new_thread): Use it.
(s390_refresh_per_info_cb): New function.
(s390_refresh_per_info): Remove parameter.  Refresh all lwps of
the current process.
(s390_insert_watchpoint): Adjust call to s390_refresh_per_info.
(s390_remove_watchpoint): Likewise.

testsuite: Fix false FAIL in gdb.cp/casts.exp

gcc-6.2.1-1.fc26.x86_64

gdb compile failed, /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/casts.cc:40:10: error: expected primary-expression before 'int'
 decltype(int x)
          ^~~
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/casts.cc:40:10: error: expected ')' before 'int'
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/casts.cc:40:1: error: expected unqualified-id before 'decltype'
 decltype(int x)
 ^~~~~~~~
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/casts.cc: In function 'int main(int, char**)':
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/casts.cc:59:14: error: expected primary-expression before 'decltype'
   double y = decltype(2);
              ^~~~~~~~

'decltype' is a registered keyword since C++11 which is now a default for GCC.

On Thu, 15 Sep 2016 14:06:56 +0200, Pedro Alves wrote:

Seems to be exercising the FLAG_SHADOW bits:

...
    {"__typeof__", TYPEOF, OP_TYPEOF, 0 },
    {"__typeof", TYPEOF, OP_TYPEOF, 0 },
    {"typeof", TYPEOF, OP_TYPEOF, FLAG_SHADOW },
    {"__decltype", DECLTYPE, OP_DECLTYPE, FLAG_CXX },
    {"decltype", DECLTYPE, OP_DECLTYPE, FLAG_CXX | FLAG_SHADOW },
...

/* This is used to associate some attributes with a token.  */

enum token_flag
{
...
  /* If this bit is set, the token is conditional: if there is a
     symbol of the same name, then the token is a symbol; otherwise,
     the token is a keyword.  */

  FLAG_SHADOW = 2
};

So perhaps a better fix is to move that particular test to a
separate testcase that force-compiles with -std=c++03.

gdb/testsuite/ChangeLog
2016-09-16  Jan Kratochvil  <jan.kratochvil@redhat.com>

* gdb.cp/casts.cc (decltype): Move it ...
(main): ... with its call to ...
* gdb.cp/casts03.cc: ... a new file.
* gdb.cp/casts.exp: Add new file casts03.cc, move decltype test to it.

[ARC] Disassemble correctly extension instructions.

For each MAJOR-MINOR opcode tuple, we can have either a 3-operand, or
2-operand, or a single operand instruction format, depending on the
values present in i-field, and a-field.

The disassembler is reading the section containing the extension
instruction format and stores them in a table.  Each table element
represents a linked list with encodings for a particular MAJOR-MINOR
tuple.

The current implementation checks only against the first element of
the list, hence, the issue.

This patch is walking the linked list until empty or finds an opcode
match.  It also adds a test outlining the found problem.

opcodes/
2016-09-15  Claudiu Zissulescu  <claziss@synopsys.com>

* arc-dis.c (find_format): Walk the linked list pointed by einsn.

gas/
2016-09-15  Claudiu Zissulescu  <claziss@synopsys.com>

* testsuite/gas/arc/textinsnxop.d: New file.
* testsuite/gas/arc/textinsnxop.s: Likewise.

Automatic date update in version.in

testsuite: Fix C++11 compilation failure for gdb.cp/m-static.exp

gcc-6.2.1-1.fc26.x86_64

g++ -std=c++03:
no warnings

g++:
In file included from /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.cc:79:0:
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.h:9:34: error: ‘constexpr’ needed for in-class initialization of static
data member ‘const float gnu_obj_4::somewhere’ of non-integral type [-fpermissive]
   static const float somewhere = 3.14159;
                                  ^~~~~~~

clang++:
In file included from /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.cc:79:
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.h:9:22: warning: in-class initializer for static data member of type 'const
float' is a GNU extension [-Wgnu-static-float-init]
  static const float somewhere = 3.14159;
                     ^           ~~~~~~~
1 warning generated.

clang++ -std=c++11:
In file included from /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.cc:79:
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.h:9:22: error: in-class initializer for static data member of type 'const
float' requires 'constexpr' specifier [-Wstatic-float-init]
  static const float somewhere = 3.14159;
                     ^           ~~~~~~~
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.h:9:3: note: add 'constexpr'
  static const float somewhere = 3.14159;
  ^
  constexpr
1 error generated.

OK for check-in?

After the fix out of the 4 combinations above only this one remains non-empty:

clang++:
In file included from /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.cc:79:
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.h:9:22: warning: in-class initializer for static data member of type 'const
float' is a GNU extension [-Wgnu-static-float-init]
  static const float somewhere = 3.14159;
                     ^           ~~~~~~~
1 warning generated.

On Thu, 15 Sep 2016 15:10:50 +0200, Pedro Alves wrote:

Hmm, OK, now that I read the test, I think you were right in trying to
keep it safe, actually.  The .exp file has:

if { $non_dwarf } { setup_xfail *-*-* }
gdb_test "print test4.everywhere" "\\$\[0-9\].* = 317" "static const int initialized in class definition"
if { $non_dwarf } { setup_xfail *-*-* }
gdb_test "print test4.somewhere" "\\$\[0-9\].* = 3.14\[0-9\]*" "static const float initialized in class definition"
                                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Added by this:

 https://sourceware.org/bugzilla/show_bug.cgi?id=11702
 https://sourceware.org/ml/gdb-patches/2010-06/msg00677.html
 https://sourceware.org/ml/gdb-patches/2010-06/txt00011.txt

So the new patch would make that highlighted tested above not
test what its test message says it is testing.

So I now think your original patch is better.  Please push
that one instead.

gdb/testsuite/ChangeLog
2016-09-15  Jan Kratochvil  <jan.kratochvil@redhat.com>

* gdb.cp/m-static.h (gnu_obj_4::somewhere): Use constexpr for C++11.

Update ISA 3.0 / POWER9 gdb tests to match GAS test cases.

* gdb.arch/powerpc-power.s: Update Power9 instruction tests
and sync up the test with tests in gas/testsuite/gas/ppc.
* gdb.arch/powerpc-power.exp: Likewise.

testsuite: Disable ccache

There were always various problems with compatibility with ccache:
https://bugzilla.redhat.com/show_bug.cgi?id=488863
https://bugzilla.redhat.com/show_bug.cgi?id=759592
https://sourceware.org/ml/gdb-patches/2009-02/msg00397.html

IMO in a summary ccache finds more a benefit of faster compilation despite the
debug info is no longer exactly the same (as without ccache).

Although for example in this case ccache helped to find a real GDB bug:
https://sourceware.org/ml/gdb-patches/2015-01/msg00497.html

For the GDB testcases ccache has (IMO) no real performance advantage and it
just brings heisenbugs - false FAILs - from time to time:

Breakpoint 1, main () at gdb/testsuite/gdb.base/vdso-warning.c:21^M
21        return 0;^M
(gdb) PASS: gdb.base/vdso-warning.exp: run: startup
->
Breakpoint 1, main () at gdb/testsuite/gdb.base/hbreak-unmapped.c:21^M
21        return 0;^M
(gdb) FAIL: gdb.base/vdso-warning.exp: run: startup

So I find most safe and easy to just disable ccache for all testsuites.

gdb/testsuite/ChangeLog
2016-09-15  Jan Kratochvil  <jan.kratochvil@redhat.com>

* lib/future.exp: Set CCACHE_DISABLE, clear CCACHE_NODISABLE.

gas: run the sparc test dcti-couples-v9 only in ELF targets.

gas/ChangeLog:

2016-09-15  Jose E. Marchesi  <jose.marchesi@oracle.com>

* testsuite/gas/sparc/sparc.exp (gas_64_check): Run
dcti-couples-v9 only in ELF targets to avoid spurious failures in
sparc-aout and sparc-coff targets.

Fix typo in readelf error message.

* readelf.c (process_mips_specific): Fix typo in error message.

Modify POWER9 support to match final ISA 3.0 documentation.

opcodes/
* ppc-opc.c (powerpc_opcodes) <slbiag>: New mnemonic.
<addex., brd, brh, brw, lwzmx, nandxor, rldixor, setbool,
xor3>: Delete mnemonics.
<cp_abort>: Rename mnemonic from ...
<cpabort>: ...to this.
<setb>: Change to a X form instruction.
<sync>: Change to 1 operand form.
<copy>: Delete mnemonic.
<copy_first>: Rename mnemonic from ...
<copy>: ...to this.
<paste, paste.>: Delete mnemonics.
<paste_last>: Rename mnemonic from ...
<paste.>: ...to this.

gas/
* testsuite/gas/ppc/power9.d <slbiag, cpabort> New tests.
<addex., brd, brh, brw, lwzmx, nandxor, rldixor, setbool,
xor3, cp_abort, copy_first, paste, paste_last, sync>: Remove tests.
<copy, paste.>: Update tests.
* testsuite/gas/ppc/power9.s: Likewise.

Automatic date update in version.in

Fix ld --gc-section segfault with ARMv8-M entry function in absolute section

bfd/
2016-09-14  Thomas Preud'homme  <thomas.preudhomme@arm.com>

* elf32-arm.c (elf32_arm_gc_mark_extra_sections): Only mark section
not already marked.

ld/
2016-09-14  Thomas Preud'homme  <thomas.preudhomme@arm.com>

* testsuite/ld-arm/cmse-veneers.s: Add a test for ARMv8-M Security
Extensions entry functions in absolute section.
* testsuite/ld-arm/cmse-veneers.rd: Adapt expected output accordingly.

Fix seg-fault in objdump when run on a fuzzed PE binary.

PR binutils/20605
* peicode.h (pe_bfd_read_buildid): Check that the Data Directory
contains a valid size for the Debug directory.

gas: improve architecture mismatch diagnostics in sparc

Merely dumping the mnemonic name in "architecture mismatch" errors may
not provide enough information to determine what went wrong, as the same
mnemonic can be used for different variants of an instruction pertaining
to different architecture levels.

This little patch makes the assembler to include the instruction
arguments in the error message.

gas/ChangeLog:

2016-09-14  Jose E. Marchesi  <jose.marchesi@oracle.com>

* config/tc-sparc.c (sparc_ip): Print the instruction arguments
in "architecture mismatch" error messages.

gas: detect DCTI couples in sparc

Before SPARC V9 the effect of having a delayed branch instruction in the
delay slot of a conditional delayed branch was undefined.

In SPARC V9 DCTI couples are well defined.

However, starting with the UltraSPARC Architecture 2005, DCTI
couples (of all kind) are deprecated and should not be used, as they may
be slow or behave differently to what the programmer expects.

This patch adds a new command line option --dcti-couples-detect to `as',
disabled by default, that makes the assembler to warn the user if an
unpredictable DCTI couple is found.  Tests and documentation are
included.

gas/ChangeLog:

2016-09-14  Jose E. Marchesi  <jose.marchesi@oracle.com>

* config/tc-sparc.c (md_assemble): Detect and warning on
unpredictable DCTI couples in certain arches.
(dcti_couples_detect): New global.
(md_longopts): Add command line option -dcti-couples-detect.
(md_show_usage): Document -dcti-couples-detect.
(md_parse_option): Handle OPTION_DCTI_COUPLES_DETECT.
* testsuite/gas/sparc/sparc.exp (gas_64_check): Run
dcti-couples-v8, dcti-couples-v9 and dcti-couples-v9c tests.
* testsuite/gas/sparc/dcti-couples.s: New file.
* testsuite/gas/sparc/dcti-couples-v9c.d: Likewise.
* testsuite/gas/sparc/dcti-couples-v8.d: Likewise.
* testsuite/gas/sparc/dcti-couples-v9.d: Likewise.
* testsuite/gas/sparc/dcti-couples-v9c.l: Likewise.
* testsuite/gas/sparc/dcti-couples-v8.l: Likewise.
* doc/as.texinfo (Overview): Document --dcti-couples-detect.
* doc/c-sparc.texi (Sparc-Opts): Likewise.

Prevent segfault in GDB when searching for architecture matches.

* format.c (struct bfd_preserve): New "build_id" field.
(bfd_preserve_save): Save "build_id".
(bfd_preserve_restore): Restore "build_id".

[ARC] Fix parsing dtpoff relocation expression.

The assembler accepts dtpoff complex relocation expression like
identifier@dtpoff + const. However, it doesn't accept an expression such
as identifier@dtpoff@base + const. This patch solves this issue, and adds
a number of tests.

ld/
2016-09-14  Claudiu Zissulescu  <claziss@synopsys.com>

* testsuite/ld-arc/tls-dtpoff.dd: New file.
* testsuite/ld-arc/tls-dtpoff.rd: Likewise.
* testsuite/ld-arc/tls-dtpoff.s: Likewise.
* testsuite/ld-arc/tls-relocs.ld: Likewise.
* testsuite/ld-arc/arc.exp: Add new tdpoff test.

gas/
2016-09-14  Claudiu Zissulescu  <claziss@synopsys.com>

* testsuite/gas/arc/tls-relocs2.d: New file.
* testsuite/gas/arc/tls-relocs2.s: Likewise.
* config/tc-arc.c (tokenize_arguments): Accept offsets when base
is used.

Stop the ARC disassembler from seg-faulting if initialised without a BFD present.

* arc-dis.c (arc_get_disassembler): Accept a null bfd gracefully.

Add support for disabling automatic generation of .eh_frame_hdr sections in ELF based linkers.

PR ld/20537
* emultempl/elf32.em: More OPTION_xxx values into an enum.  Add
OPTION_NO_EH_FRAME_HDR.
(_add_options): Add support for --no-eh-frame-hdr.
* ld.texinfo: Document new option.
* lexsup.c (elf_shlib_list_options): List new option.
* NEWS: Mention the new option.

Automatic date update in version.in

Fix for gdb.server/non-existing-program.exp test case

The last commit was supposed to have the reference to ptrace () removed.
The patch didn't get updated correctly before the commit.  This commit
fixes the comment as requested

gdbserver/ChangeLog

2016-09-06  Carl Love  <cel@us.ibm.com>

* server.c (start_inferior):  Fixed comment, requested comment change
didn't get updated correctly.  Removed reference to ptrace () call as
  it is only true on Linux systems.

Fix for gdb.server/non-existing-program.exp test case

The test checks to make sure GDB exits cleanly if there is
no valid target binary.  Currently, ppc and S390 fail on this
test.  The function target_post_create_inferior () calls
linux_post_create_inferior () which calls the architecture
specific functions s390_arch_setup () and ppc_arch_setup ()
which make ptrace calls to access the architecture specific
registers.  These ptrace calls fail because the process does
not exist causing GDB to exit on error.

This patch checks to see if the initial ptrace (PTRACE_TRACEME, ...)
call returned a status of TARGET_WAITKIND_EXITED indicating the
target has already exited.  If the target has exited, then the
target_post_create_inferior () is not called since there is no
inferior to be setup.  The test to see if the initial ptrace
call succeeded is done after the ptrace (PTRACE_TRACEME, ...)
call and the wait for the inferior process to stop, assuming
it exists, has occurred.

The patch has been tested on X86 64-bit, ppc64 and s390.  If
fixes the test failures on ppc64 and s390.  The test does not
fail on X86 64-bit.  The patch does not introduce any additional
regression failures on any of these three platforms.

gdbserver/ChangeLog

2016-09-06  Carl Love  <cel@us.ibm.com>

* server.c (start_inferior):  Do not call
function target_post_create_inferior () if the
inferior process has already exited.

Automatic date update in version.in

S/390: Add alternate processor names.

This patch adds alternate CPU names which adhere to the number of the
architecture document.  So instead of having z196, zEC12, and z13 you
can use arch9, arch10, and arch11.  The old cpu names stay valid and
should primarily be used.

The alternate names are supposed to improve compatibility with the IBM
XL compiler toolchain which uses the arch numbering.

opcodes/ChangeLog:

2016-09-12  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>

* s390-mkopc.c (main): Support alternate arch strings.

gas/ChangeLog:

2016-09-12  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>

* config/tc-s390.c (s390_parse_cpu): Support alternate arch
strings.
* doc/as.texinfo: Document new arch strings.
* doc/c-s390.texi: Likewise.

S/390: Fix facility bit default.

gas/ChangeLog:

2016-09-12  Andreas Krebbel  <krebbel@linux.vnet.ibm.com>

* config/tc-s390.c: Set all facitily bits by default

S/390: Fix kmctr instruction type.

opcodes/ChangeLog:

2016-09-12  Patrick Steuer  <steuer@linux.vnet.ibm.com>

* s390-opc.txt: Fix kmctr instruction type.

gas/ChangeLog:

2016-09-12  Patrick Steuer  <steuer@linux.vnet.ibm.com>

* testsuite/gas/s390/zarch-z196.d: Adjust testcase.

Fix false FAIL on gdb.base/stap-probe.exp, due to ICF optimization

GCC 6's ICF optimization pass is making the declaration of 'm1' and
'm2', on gdb.base/stap-probe.c, to be unified.  However, this leads to
only one instance of the probe 'two' being created, which causes a
failure on the testsuite (which expects a multi-location breakpoint to
be inserted on the probe).

This patch fixes this failure by declaring a dummy variable on 'm1',
and using it as an argument to m1's version of probe 'two'.  Since we
do not care about the contents of the functions nor about the
arguments of each probe 'two', this is OK.

gdb/testsuite/ChangeLog:
2016-09-11  Sergio Durigan Junior  <sergiodj@redhat.com>
    Jan Kratochvil  <jan.kratochvil@redhat.com>

* gdb.base/stap-probe.c (m1): New variable 'dummy', necessary to
make m1's definition to be different from m2's.  Use 'dummy' as an
argument for probe 'two'.

Automatic date update in version.in

Automatic date update in version.in

Use target_sim_options for sim target.

2016-09-10  Jon Beniston  <jon@beniston.com>

* lib/mi-support.exp (mi_gdb_target_load): Use target_sim_options
for sim target.

Automatic date update in version.in

Pass HWCAP to ifunc resolver

On various GNU Elf architectures, including AArch64, ARM, s390/s390x,
ppc32/64, and sparc32/64, the dynamic loader passes HWCAP as a parameter
to each ifunc resolver.  Currently there is an open glibc Bugzilla that
requests this to be generalized to all architectures:

  https://sourceware.org/bugzilla/show_bug.cgi?id=19766

And various ifunc resolvers already rely on receiving HWCAP.  Currently
GDB always calls an ifunc resolver without any arguments; thus the
resolver may receive garbage, and based on that, the resolver may decide
to return a function that is not suited for the given platform.

This patch always passes HWCAP to ifunc resolvers, even on systems where
the dynamic loader currently behaves otherwise.  The rationale is
that (1) the dynamic loader may get adjusted on those systems as well in
the future; (2) passing an unused argument should not cause a problem
with existing resolvers; and (3) the logic is much simpler without such
a distinction.

gdb/ChangeLog:

* elfread.c (auxv.h): New include.
(elf_gnu_ifunc_resolve_addr): Pass HWCAP to ifunc resolver.

gdb/testsuite/ChangeLog:

* gdb.base/gnu-ifunc-lib.c (resolver_hwcap): New external
variable declaration.
(gnu_ifunc): Add parameter hwcap.  Store it in resolver_hwcap.
* gdb.base/gnu-ifunc.c (resolver_hwcap): New global variable.
* gdb.base/gnu-ifunc.exp: Add test to verify that the resolver
received HWCAP as its argument.

Automatic date update in version.in

Remove some unneeded casts from remote.c

I happened to notice a few unneeded casts in remote.c.  In some cases
these are no-ops, and in others these cast away const, but in a context
where this is not needed.

I'm checking this in under the obvious rule.
Tested by rebuilding on x86-64 Fedora 24.

2016-09-08  Tom Tromey  <tom@tromey.com>

* remote.c (remote_notif_stop_ack, remote_wait_as)
(show_remote_cmd): Remove unneeded casts.

Allow PROCESSOR_IAMCU for Intel MCU

* config/tc-i386.c (i386_target_format): Allow PROCESSOR_IAMCU
for Intel MCU.

Automatic date update in version.in

X86: Allow additional ISAs for IAMCU in assembler

Originally only Pentium integer instructions are allowed for IAMCU.
This patch removes such a restriction.  For example, 387 and SSE2
instructions can be enabled by passing "-march=iamcu+sse2+387" to
assembler.

gas/

* config/tc-i386.c (valid_iamcu_cpu_flags): Removed.
(set_cpu_arch): Updated.
(md_parse_option): Likewise.
* testsuite/gas/i386/i386.exp: Run iamcu-4 and iamcu-5.  Remove
iamcu-inval-2 and iamcu-inval-3.
* testsuite/gas/i386/iamcu-4.d: New file.
* testsuite/gas/i386/iamcu-4.s: Likewise.
* testsuite/gas/i386/iamcu-5.d: Likewise.
* testsuite/gas/i386/iamcu-5.s: Likewise.
* testsuite/gas/i386/iamcu-inval-2.l: Removed.
* testsuite/gas/i386/iamcu-inval-2.s: Likewise.
* testsuite/gas/i386/iamcu-inval-3.l: Likewise.
* testsuite/gas/i386/iamcu-inval-3.s: Likewise.

opcodes/

* i386-gen.c (cpu_flag_init): Remove CPU_IAMCU_COMPAT_FLAGS.
* i386-init.h: Regenerated.

[arm] Automatically enable CRC instructions on supported ARMv8-A CPUs.

2016-09-07  Richard Earnshaw  <rearnsha@arm.com>

* opcode/arm.h (ARM_ARCH_V8A_CRC): New architecture.

2016-09-07  Richard Earnshaw  <rearnsha@arm.com>

* config/tc-arm.c ((arm_cpus): Use ARM_ARCH_V8A_CRC for all
ARMv8-A CPUs except xgene1.

Automatic date update in version.in

new-ui command: gdb internal errors if input is already pending

I noticed that if input is already pending on the new-ui TTY, gdb
internal-errors.

E.g., create /dev/pts/2, and type anything there (even just <return>
is sufficient).

Now start GDB creating a new UI on that TTY, while at the same time,
running a synchronous execution command.  Something like:

$ gdb program -ex "new-ui console /dev/pts/2" -ex "start"

Back on /dev/pts/2, we get:

  (gdb) .../src/gdb/event-top.c:360: internal-error: double prompt
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.

While the main UI was waiting for "start" to finish, gdb kepts pumping
events, including the input fd of the extra console.  The problem is
that stdin_event_handler doesn't restore the current UI back to what
it was, assuming that it's only ever called from the top level event
loop.  However, in this case, it's being called from the nested event
loop from within maybe_wait_sync_command_done.

When finally the "start" command is done, we reach the code that
prints the prompt in the main UI, just before starting the main event
loop.  Since now the current UI is pointing at the extra console (by
mistake), we find ourselves printing a double prompt on the extra
console.  This is caught by the assertion that fails, as shown above.

Since other event handlers also don't restore the UI (e.g., signal
event handlers), I think it's better if whatever is pumping events to
take care to restore the UI, if it cares.  That's what this patch
does.  New test included.

gdb/ChangeLog:
2016-09-06  Pedro Alves  <palves@redhat.com>

* top.c (wait_sync_command_done): Don't assume current_ui doesn't
change across events.  Restore the current UI before returning.
(gdb_readline_wrapper): Restore the current UI before returning.

gdb/testsuite/ChangeLog:
2016-09-06  Pedro Alves  <palves@redhat.com>

* gdb.base/new-ui-pending-input.c: New file.
* gdb.base/new-ui-pending-input.exp: New file.
* gdb.exp (clear_gdb_spawn_id): New procedure.
(with_spawn_id): Check whether gdb_spawn_id exists before
referencing it.  If gdb_spawn_id didn't exist on entry, clear it
on exit.

Introduce make_cleanup_restore_current_ui

Just a tidy, no functional changes.

gdb/ChangeLog:
2016-09-06  Pedro Alves  <palves@redhat.com>

* event-top.c (restore_ui_cleanup): Now static.
(make_cleanup_restore_current_ui): New function.
(switch_thru_all_uis_init): Use it.
* infcall.c (call_thread_fsm_should_stop): Use it.
* infrun.c (fetch_inferior_event): Use it.
* top.c (new_ui_command): Use it.
* top.h (restore_ui_cleanup): Delete declaration.
(make_cleanup_restore_current_ui): New declaration.

Resolve size relocation with copy relocation

We can resolve size relocation against symbol which needs copy relocation
when building executable.

bfd/

PR ld/20550
* elf64-x86-64.c (elf_x86_64_relocate_section): Resolve size
relocation with copy relocation when building executable.

ld/

PR ld/20550
* testsuite/ld-x86-64/pr20550a.s: New file.
* testsuite/ld-x86-64/pr20550b.s: Likewise.
* testsuite/ld-x86-64/x86-64.exp (x86_64tests): Add tests for
PR ld/20550.

Do not pass host compiler sanitization flags on to linker testsuite.

* Makefile.am (CFLAGS_FOR_TARGET): Define as a copy of CFLAGS but
without any sanitization options.
(CXXFLAGS_FOR_TARGET): Define as a copy of CXXFLAGS but without
any sanitization options.
(check-DEJAGNU): Pass CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET
as CFLAGS and CXXFLAGS respectively.

Support 128-bit IEEE floating-point types on Intel and Power

Now that all the prerequisites are in place, this commit finally adds support
for handling the __float128 type on Intel and Power, by providing appropriate
platform-specific versions of the floatformat_for_type callback.

Since at this point we do not yet have any indication in the debug info to
distinguish different floating-point formats of the same length, we simply
use the type name as hint.  Types named "__float128" get the IEEE format.
In addition to handling "__float128" itself, we also recognize "_Float128"
and (on Power) "_Float64x", as well as the complex versions of those.
(As pointed out by Joseph Myers, starting with GCC 7, __float128 is just
a typedef for _Float128 -- but it's good to handle this anyway.)

A new test case does some simple verification that the format is decoded
correctly, using both __float128 and "long double" to make sure using both
in the same file still works.  Another new test verifies handling of the
_FloatN and _FloatNx types supported by GCC 7, as well as the complex
versions of those types.

Note that this still only supports basic format decoding and encoding.
We do not yet support the GNU extension 'g' suffix for __float128 constants.
In addition, since all *arithmetic* on floating-point values is still
performed in native host "long double" arithmetic, if that format is not
able to encode all target __float128 values, we may get incorrect results.
(To fix this would require implementing fully synthetic target floating-
point arithmetic along the lines of GCC's real.c, presumably using MPFR.)

gdb/ChangeLog:

* i386-tdep.c (i386_floatformat_for_type): New function.
(i386_gdbarch_init): Install it.
* ppc-linux-tdep.c (ppc_floatformat_for_type): New function.
(ppc_linux_init_abi): Install it.

gdb/testsuite/ChangeLog:

* gdb.base/float128.c: New file.
* gdb.base/float128.exp: Likewise.
* gdb.base/floatn.c: Likewise.
* gdb.base/floatn.exp: Likewise.

Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>

Add gdbarch callback to provide formats for debug info float types

At this point, all TYPE_CODE_FLT types carry their floating-point format,
except for those creating from reading DWARF or stabs debug info.  Those
will be addressed by this commit.

The main issue here is that we actually have to determine which floating-
point format to use.  Currently, we only have the type length as input
to this decision.  In the future, we may hopefully get --at least in
DWARF-- additional information to help disambiguate multiple different
formats of the same length.  For now, we can still look at the type name
as a hint.

This decision logic is encapsulated in a gdbarch callback to allow
platform-specific overrides.  The default implementation use the same
logic (compare type length against the various gdbarch_..._bit sizes)
that is currently implemented in floatformat_from_length.

With this commit, all platforms still use the default logic, so there
should be no actual change in behavior.  A follow-on commit will add
support for __float128 on Intel and Power.

Once dwarf2read.c and stabsread.c make use of the new callback to
determine floating-point formats, we're now sure every TYPE_CODE_FLT
type will always carry its format.  The commit therefore adds asserts
to verify_floatformat to ensure new code will continue to always
provide formats, and removes the code in floatformat_from_type that
used to handle types with a NULL TYPE_FLOATFORMAT.

gdb/ChangeLog:

* gdbarch.sh (floatformat_for_type): New gdbarch callback.
* gdbarch.h, gdbarch.c: Re-generate.
* arch-utils.h (default_floatformat_for_type): New prototype.
* arch-utils.c (default_floatformat_for_type): New function.

* doublest.c (floatformat_from_length): Remove.
(floatformat_from_type): Assume TYPE_FLOATFORMAT is non-NULL.
* gdbtypes.c (verify_floatformat): Require non-NULL format.

* dwarf2read.c (dwarf2_init_float_type): New function.
(read_base_type): Use it.
* stabsread.c (dbx_init_float_type): New function.
(read_sun_floating_type): Use it.
(read_range_type): Likewise.

Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>

Add missing format for built-in floating-point types

Many callers of init_float_type and arch_float_type still pass a NULL
floatformat.  This commit changes those callers where the floatformat
that is supposed to be use is obvious.  There are two categories where
this is the case:

- A number of built-in types are intended to match the platform ABI
  floating-point types (i.e. types that use gdbarch_float_bit etc.).
  Those places should use the platform ABI floating-point formats
  defined via gdbarch_float_format etc.

- A number of language built-in types should simply use IEEE floating-
  point formats, since the language actually defines that this is the
  format that must be used to implement floating-point types for this
  language.  (This affects Java, Go, and Rust.)  The same applies for
  to the predefined "RS/6000" stabs floating-point built-in types.

gdb/ChangeLog:

* ada-lang.c (ada_language_arch_info): Use gdbarch-provided
platform ABI floating-point formats for built-in types.
* d-lang.c (build_d_types): Likewise.
* f-lang.c (build_fortran_types): Likewise.
* m2-lang.c (build_m2_types): Likewise.
* mdebugread.c (basic_type): Likewise.

* go-lang.c (build_go_types): Use IEEE floating-point formats
for language built-in types as mandanted by the language.
* jv-lang.c (build_java_types): Likewise.
* rust-lang.c (rust_language_arch_info): Likewise.
* stabsread.c (rs6000_builtin_type): Likewise.

Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>

Remove TYPE_NOSIGN "char" hack

init_type (and arch_integer_type) currently use a special hack to set the
TYPE_NOSIGN flag if the type name is exactly "char".  This commit moves the
hack up to the callers of those routines.

The special case currently can hit only for types created from dwarf2read,
but read_base_type actually implements the "char" check itself, so it is
redundant to do it in init_type as well.  (Note that stabsread.c and the
other type readers always pass NULL as name to init_type, so the special
case can never hit for those.)

A few other cases create pre-definded types with a hard-coded name of "char";
the commit simply moves setting the TYPE_NOSIGN flag to those places.

No functional change intended.

gdb/ChangeLog:

* gdbtypes.c (init_type): Remove "char" special case.
(arch_integer_type): Likewise.
(gdbtypes_post_init): Set TYPE_NOSIGN for "char" type.
(objfile_type): Likewise.
* mdebugread.c (basic_type): Likewise.
* stabsread.c (rs6000_builtin_type): Likewise.

Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>

Remove obsolete TYPE_FLAG_... values

Now that init_type no longer takes a FLAGS argument, there is no user of
the TYPE_FLAGS_... enum values left.  This commit removes them (and all
references to them in comments as well).

This is mostly a no-op, except for a change to the Python type printer,
which attempted to use them before.  (As best as I can tell, this wasn't
really needed anyway, since it was only used to pretty-print type
*instance* flags, which only use the instance flags.)

gdb/ChangeLog:

* gdbtypes.h (enum type_flag_value): Remove.
Remove references to TYPE_FLAG_... in comments throughout.
* gdbtypes.c (recursive_dump_type): Do not print TYPE_FLAG_...
flags, print the corresponding TYPE_... access macro names.
Remove references to TYPE_FLAG_... in comments throughout.
* infcall.c: Remove references to TYPE_FLAG_... in comments.
* valprint.c: Likewise.
* gdb-gdb.py (class TypeFlag): No longer consider TYPE_FLAG_...
values, only TYPE_INSTANCE_FLAG_... values.
(class TypeFlagsPrinter): Likewise.

gdb/testsuite/ChangeLog:

* gdb.cp/hang.exp: Remove reference to TYPE_FLAG_STUB in comment.

Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>

Unify init_type and arch_type interface and helpers

This adds a number of helper routines for creating objfile-owned types;
these correspond 1:1 to the already existing helper routines for creating
gdbarch-owned types, and are intended to be used instead of init_type.
A shared fragment of init_float_type and arch_float_type is extracted into
a separate subroutine verify_subroutine.

The commit also brings the interface of init_type in line with the one for
arch_type.  In particular, this means removing the FLAGS argument; callers
now set the required flags directly.  (Since most callers use the new
helper routines, very few callers actually need to set any additional
flags directly any more.)

Note that this means all the TYPE_FLAGS_... defined are no longer needed
anywhere; they will be removed by a follow-on commit.

All users of init_type are changed to use on of the new helpers where
possible.  No functional change intended.

gdb/ChangeLog:

* gdbtypes.h (init_type): Remove FLAGS argument.  Move OBJFILE
argument to first position.
(init_integer_type): New prototype.
(init_character_type): Likewise.
(init_boolean_type): Likewise.
(init_float_type): Likewise.
(init_decfloat_type): Likewise.
(init_complex_type): Likewise.
(init_pointer_type): Likewise.
* gdbtypes.c (verify_floatflormat): New function.
(init_type): Remove FLAGS argument and processing.  Move OBJFILE
argument to first position.
(init_integer_type): New function.
(init_character_type): Likewise.
(init_boolean_type): Likewise.
(init_float_type): Likewise.
(init_decfloat_type): Likewise.
(init_complex_type): Likewise.
(init_pointer_type): Likewise.
(arch_float_type): Use verify_floatflormat.
(objfile_type): Use init_..._type helpers instead of calling
init_type directly.
* dwarf2read.c (fixup_go_packaging): Update to changed init_type
prototype.
(read_namespace_type): Likewise.
(read_module_type): Likewise.
(read_typedef): Likewise.
(read_unspecified_type): Likewise.
(build_error_marker_type): Likewise.
(read_base_type): Use init_..._type helpers.
* mdebugread.c (basic_type): Use init_..._type helpers.
(parse_type): Update to changed init_type prototype.
(cross_ref): Likewise.
* stabsread.c (rs6000_builtin_type): Use init_..._type helpers.
(read_sun_builtin_type): Likewise.
(read_sun_floating_type): Likewise.
(read_range_type): Likewise.  Also update to changed init_type
prototype.

Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>

Add some missing arch_..._type helpers

gdbtypes provides a number of helper routines that can be called instead of
using arch_type directly to create a type of a particular kind.  This patch
adds two additional such routines that have been missing so far, to allow
creation of TYPE_CODE_DECFLOAT and TYPE_CODE_POINTER types.

The patch also changes a number of places to use the new helper routines
instead of calling arch_type directly.  No functional change intended.

gdb/ChangeLog:

* gdbtypes.h (arch_decfloat_type): New prototype.
(arch_pointer_type): Likewise.
* gdbtypes.c (arch_decfloat_type): New function.
(arch_pointer_type): Likewise.
(gdbtypes_post_init): Use arch_decfloat_type.
* avr-tdep.c (avr_gdbarch_init): Use arch_pointer_type.
* ft32-tdep.c (ft32_gdbarch_init): Likewise.
* m32c-tdep.c (make_types): Likewise.
* rl78-tdep.c (rl78_gdbarch_init): Likewise.

Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>

Fix TYPE_SPECIFIC_FIELD for types created via arch_type

A type's TYPE_SPECIFIC_FIELD is supposed to be initialized as appropriate
for the type code.  This does happen if the type is created via init_type,
but not if it created via arch_type.

Fixed by extracting the initialization logic into a new set_type_code
routine, which is then called from both places.

gdb/ChangeLog:

* gdbtypes.c (set_type_code): New function.
(init_type, arch_type): Use it.

Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>

Fix typo in ada_language_arch_info

This fixes a bug introduced by a wrong replacement here:
https://sourceware.org/ml/gdb-patches/2007-06/msg00196.html

The Ada "long_long_float" type is supposed to correspond to the
platform ABI long double type, not double.

gdb/ChangeLog:

* ada-lang.c (ada_language_arch_info): Use gdbarch_long_double_bit
instead of gdbarch_double_bit for "long_long_float".

Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>

Fix a problem in readelf where memcpy could be called with a NULL second argument.

* readelf.c (request_dump_bynumber): Only call memcpy if
dump_sects is not NULL.

Fix PR ld/20545 - relaxation bugs in avr backend

Prior to the patch, addends for relocs were being adjusted even if
they went beyond an alignment boundary. This is wrong - to
preserve alignment constraints, the relaxation logic adds as many padding
bytes at the alignment boundary as was deleted, so addends beyond the
boundary should not be adjusted. avr-prop-7.s reproduces this
scenario.

Also, prior to this patch, the relaxation logic assumed that the addr
parameter pointed to the middle of the instruction to be deleted, and
that addr - count would therefore be the shrinked instruction's
address. This is true when actually shrinking instructions.

The alignment constraints handling logic also invokes the same logic
though, with addr as the starting offset of padding bytes and
with count as the number of bytes to be deleted. Calculating the
shrinked insn's address as addr - count is obviously wrong in this
case - that offset would point to count bytes before the last
non-padded byte. avr-prop-8.s reproduces this scenario.

To fix scenario 1, the patch adds an additional check to ensure reloc addends
aren't adjusted if they cross a shrink boundary. The shrink boundary
is either the section size or an alignment boundary. Addends pointing
at an alignment boundary don't need to be adjusted, as padding would
occur and keep the boundary the same. Addends pointing at section size
need to be adjusted though, as no padding occurs and the section size
itself would get decremented. The patch records whether padding
occured (did_pad) and uses that to detect and handle this condition.

To fix scenario 2, the patch adds an additional parameter
(delete_shrinks_insn) to elf32_avr_relax_delete_bytes to distinguish
instruction bytes deletion from padding bytes deletion. It then uses that to
correctly set shrinked_insn_address.

bfd/ChangeLog:

2016-09-02  Senthil Kumar Selvaraj  <senthil_kumar.selvaraj@atmel.com>

PR ld/20545
* elf32-avr.c (elf32_avr_relax_delete_bytes): Add parameter
delete_shrinks_insn. Modify computation of shrinked_insn_address.
Compute shrink_boundary and adjust addend only if
addend_within_shrink_boundary.
(elf32_avr_relax_section): Modify calls to
elf32_avr_relax_delete_bytes to pass extra parameter.

ld/ChangeLog:

2016-09-02  Senthil Kumar Selvaraj  <senthil_kumar.selvaraj@atmel.com>

PR ld/20545
* testsuite/ld-avr/avr-prop-7.d: New test.
* testsuite/ld-avr/avr-prop-7.s: New test.
* testsuite/ld-avr/avr-prop-8.d: New test.
* testsuite/ld-avr/avr-prop-8.s: New test.

Automatic date update in version.in

gdb/: Require a C++ compiler

This removes all support for building gdb & gdbserver with a C
compiler from gdb & gdbserver's build machinery.

gdb/ChangeLog:
2016-09-05  Pedro Alves  <palves@redhat.com>

* NEWS: Mention that a C++ compiler is now required.
* Makefile.in (COMPILER, COMPILER_CFLAGS): Remove.
(COMPILE.pre, CC_LD): Use CXX directly.
(INTERNAL_CFLAGS_BASE): Use CXXFLAGS directly.
* acinclude.m4: Don't include build-with-cxx.m4.
* build-with-cxx.m4: Delete file.
* configure.ac: Remove GDB_AC_BUILD_WITH_CXX call.
* warning.m4: Assume $enable_build_with_cxx is yes.
* configure: Regenerate.

gdb/gdbserver/ChangeLog:
2016-09-05  Pedro Alves  <palves@redhat.com>

* Makefile.in (COMPILER, COMPILER_CFLAGS): Remove.
(COMPILE.pre, CC_LD): Use CXX directly.
(INTERNAL_CFLAGS_BASE): Use CXXFLAGS directly.
* acinclude.m4: Don't include build-with-cxx.m4.
* configure.ac: Remove GDB_AC_BUILD_WITH_CXX call.
* configure: Regenerate.

Fix PR19927: Avoid unwinder recursion if sniffer uses calls parse_and_eval

This fixes the problem exercised by Kevin's test at:

 https://sourceware.org/ml/gdb-patches/2016-08/msg00216.html

This was originally exposed by the OpenJDK Python-based unwinder.

If an unwinder attempts to call parse_and_eval from within its
sniffing method, GDB's unwinding machinery enters infinite recursion.
However, parse_and_eval is a pretty reasonable thing to call, because
Python/Scheme-based unwinders will often need to read globals out of
inferior memory.  The recursion happens because:

- get_current_frame() is called soon after the target stops.

- current_frame is NULL, and so we unwind it from the sentinel frame
  (which is special and has level == -1).

- We reach get_prev_frame_if_no_cycle, which does cycle detection
  based on frame id, and thus tries to compute the frame id of the new
  frame.

- Frame id computation requires an unwinder, so we go through all
  unwinder sniffers trying to see if one accepts the new frame (the
  current frame).

- the unwinder's sniffer calls parse_and_eval().

- parse_and_eval depends on the selected frame/block, and if not set
  yet, the selected frame is set to the current frame.

- get_current_frame () is called again.  current_frame is still NULL,
  so ...

- recurse forever.

In Kevin's test at:

 https://sourceware.org/ml/gdb-patches/2016-08/msg00216.html

gdb doesn't recurse forever simply because the Python unwinder
contains code to detect and stop the recursion itself.  However, GDB
goes downhill from here, e.g., by showing the sentinel frame as
current frame (note the -1):

    Breakpoint 1, ccc (arg=<unavailable>) at py-recurse-unwind.c:23
    23      }
    (gdb) bt
    #-1 ccc (arg=<unavailable>) at py-recurse-unwind.c:23
    Backtrace stopped: previous frame identical to this frame (corrupt stack?)

That "-1" frame level comes from this:

      if (catch_exceptions (current_uiout, unwind_to_current_frame,
    sentinel_frame, RETURN_MASK_ERROR) != 0)
{
  /* Oops! Fake a current frame?  Is this useful?  It has a PC
             of zero, for instance.  */
  current_frame = sentinel_frame;
}

which is bogus.  It's never correct to set the current frame to the
sentinel frame.  The only reason this has survived so long is that
getting here normally indicates something wrong has already happened
before and we fix that.  And this case is no exception -- it doesn't
really matter how precisely we managed to get to that bogus code (it
has to do with the the stash), because anything after recursion
happens is going to be invalid.

So the fix is to avoid the recursion in the first place.

Observations:

 #1 - The recursion happens because we try to do cycle detection from
      within get_prev_frame_if_no_cycle.  That requires computing the
      frame id of the frame being unwound, and that itself requires
      calling into the unwinders.

 #2 - But, the first time we're unwinding from the sentinel frame,
      when we reach get_prev_frame_if_no_cycle, there's no frame chain
      at all yet:

      - current_frame is NULL.
      - the frame stash is empty.

Thus, there's really no need to do cycle detection the first time we
reach get_prev_frame_if_no_cycle, when building the current frame.

So we can break the recursion by making get_current_frame call a
simplified version of get_prev_frame_if_no_cycle that results in
setting the current_frame global _before_ computing the current
frame's id.

But, we can go a little bit further.  As there's really no reason
anymore to compute the current frame's frame id immediately, we can
defer computing it to when some caller of get_current_frame might need
it.  This was actually how the frame id was computed for all frames
before the stash-based cycle detection was added.  So in a way, this
patch reintroduces the lazy frame id computation, but unlike before,
only for the case of the current frame, which turns out to be special.

This lazyness, however, requires adjusting
gdb.python/py-unwind-maint.exp, because that assumes unwinders are
immediately called as side effect of some commands.  I didn't see a
need to preserve the behavior expected by that test (all it would take
is call get_frame_id inside get_current_frame), so I adjusted the
test.

gdb/ChangeLog:
2016-09-05  Pedro Alves  <palves@redhat.com>

PR backtrace/19927
* frame.c (get_frame_id): Compute the frame id if not computed
yet.
(unwind_to_current_frame): Delete.
(get_current_frame): Use get_prev_frame_always_1 to get the
current frame and assert that that always succeeds.
(get_prev_frame_if_no_cycle): Skip cycle detection if returning
the current frame.

gdb/testsuite/ChangeLog:
2016-09-05  Pedro Alves  <palves@redhat.com>

PR backtrace/19927
* gdb.python/py-unwind-maint.exp: Adjust tests to not expect that
unwinders are immediately called as side effect of "source" or
"disable unwinder" commands.
* gdb.python/py-recurse-unwind.exp: Remove setup_kfail calls.

Automatic date update in version.in

Automatic date update in version.in