Fix the generation of relocs for missing build notes.

* write.c (create_note_reloc): Add desc2_size parameter.  Zero out
the addend field of REL relocations.  Store the full addend into
the note for REL relocations.

PR26239, memory leak in _bfd_dwarf2_slurp_debug_info

PR 26239
* coffgen.c (_bfd_coff_close_and_cleanup): Free dwarf2 info.

Fix an illegal memory access in the BFD library which can be triggered by attempting to parse a corrupt PE format file.

PR26240
* coffgen.c (coff_get_normalized_symtab): Fix off-by-one error in
check for aux entries that overflow the buufer.

[gdb/testsuite] Handle callq -> call disassembly change

We're currently running into:
...
FAIL: gdb.trace/entry-values.exp: disassemble bar
...

Since commit 36938cabf0 "x86: avoid attaching suffixes to unambiguous insns",
"callq" is disassembled as "call", and the test-case expects "callq".

Fix this by expecting "call" instead.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-15  Tom de Vries  <tdevries@suse.de>

* gdb.trace/entry-values.exp: Expect "call" instead of "callq" if
is_amd64_regs_target.

gdb/fortran: Handle dynamic string types when printing types

After commit:

  commit 8c2e4e0689ea244d0ed979171a3d09c9176b8175
  Date:   Sun Jul 12 22:58:51 2020 -0400

      gdb: add accessors to struct dynamic_prop

An existing bug was exposed in the Fortran type printing code.  When
GDB is asked to print the type of a function that takes a dynamic
string argument GDB will try to read the upper bound of the string.

The read of the upper bound is written as:

    if (type->bounds ()->high.kind () == PROP_UNDEFINED)
      // Treat the upper bound as unknown.
    else
      // Treat the upper bound as known and constant.

However, this is not good enough.  When printing a function type the
dynamic argument types will not have been resolved.  As a result the
dynamic property is not PROP_UNDEFINED, but nor is it constant.

By rewriting this code to specifically check for the PROP_CONST case,
and treating all other cases as the upper bound being unknown we avoid
incorrectly treating the dynamic property as being constant.

gdb/ChangeLog:

* f-typeprint.c (f_type_print_base): Allow for dynamic types not
being resolved.

gdb/testsuite/ChangeLog:

* gdb.fortran/ptype-on-functions.exp: Add more tests.
* gdb.fortran/ptype-on-functions.f90: Likewise.

x86: move putop() case labels to restore alphabetic sorting

... as far as non-fall-through behavior permits.

x86: make PUSH/POP disassembly uniform

Irrespective of their encoding the resulting output should look the
same. Therefore wire the handling of PUSH/POP with GPR operands
encoded in the main opcode byte to the same logic used for other
operands. This frees up yet another macro character.

x86-64: adjust stack insn test case

The value chosen for the 16-/32-bit immediate cases didn't work well
with the subsequent insn's REX prefix - we ought to pick a value the
upper two bytes of which evaluate to a 2-byte insn. Bump the values
accordingly, allowing the subsequent insn to actually have the intended
REX.W.

x86: avoid attaching suffixes to unambiguous insns

"Unambiguous" is is in particular taking as reference the assembler,
which also accepts certain insns - despite them allowing for varying
operand size, and hence in principle being ambiguous - without any
suffix. For example, from the very beginning of the life of x86-64 I had
trouble understanding why a plain and simple RET had to be printed as
RETQ. In case someone really used the 16-bit form, RETW disambiguates
the two quite fine.

mmix bfd: fix bfd_assert for R_MMIX_PUSHJ_STUBBABLE against undef'd symbol

Spotted when inspecting gcc testsuite logs, but this already is
covered by the ld-mmix testsuite, it's just that the assert is ignored
since the regexp match is for a substring and not anchored.

With the anchors added but not the bugfix, the ld.log shows that the
asserts cause a non-match as intended:

Executing on host: sh -c {./ld-new   -LX/src/ld/testsuite/ld-mmix  -m elf64mmix -o tmpdir/dump tmpdir/undef-2.o tmpdir/start.o  2>&1}  /dev/null dump.tmp (timeout = 300)
./ld-new: BFD (GNU Binutils) 2.34.50.20200629 assertion fail X/src/bfd/elf64-mmix.c:2845
./ld-new: BFD (GNU Binutils) 2.34.50.20200629 assertion fail X/src/bfd/elf64-mmix.c:2845
./ld-new: BFD (GNU Binutils) 2.34.50.20200629 assertion fail X/src/bfd/elf64-mmix.c:2845
./ld-new: tmpdir/undef-2.o:(.text+0x0): undefined reference to `undefd'
failed with: <./ld-new: BFD (GNU Binutils) 2.34.50.20200629 assertion fail X/src/bfd/elf64-mmix.c:2845
./ld-new: BFD (GNU Binutils) 2.34.50.20200629 assertion fail X/src/bfd/elf64-mmix.c:2845
./ld-new: BFD (GNU Binutils) 2.34.50.20200629 assertion fail X/src/bfd/elf64-mmix.c:2845
./ld-new: tmpdir/undef-2.o:(.text+0x0): undefined reference to `undefd'>, expected: <\A[^\n\r]*undefined reference to `undefd'\Z>
FAIL: ld-mmix/undef-2

Gone with the fix of course, leaving just the intended "undefined
reference" like.

I'm not going to add anchors manually for all the "error:" strings in
the test-suite, not even in the mmix parts.  Sorry, but I'll just do
it for *these* specific undefined-reference tests.

Just a thought: maybe the run_dump_test "error:" string should
*automatically* get anchor marks prepended and appended for a single
line match as in the patch, "\A[^\n\r]*" prepended and \Z appended
unless either anchor mark or \r or \n is present in the regexp?

Committed.

bfd:
* elf64-mmix.c (mmix_elf_relax_section): Improve accounting for
R_MMIX_PUSHJ_STUBBABLE relocs against undefined symbols.

ld/testsuite:
* testsuite/ld-mmix/undef-1.d, testsuite/ld-mmix/undef-1m.d,
testsuite/ld-mmix/undef-2.d, testsuite/ld-mmix/undef-2m.d: Add
start- and end-anchors to error-string to match just a
single-line error-message.

gdb/testsuite/lib/dwarf.exp: fix addr_size parameter comments

The comments modified in this patch claim that the addr_size parameters
can take the value 32 or 64 (suggesting the value is in bits).  In fact,
the expected value is in bytes, either 4 or 8.

The actual value in the DWARF info is in bytes.  And we can see that the
default values used (if addr_size == "default") are:

if {$_cu_addr_size == "default"} {
    if {[is_64_target]} {
set _cu_addr_size 8
    } else {
set _cu_addr_size 4
    }
}

gdb/testsuite/ChangeLog:

* lib/dwarf.exp (Dwarf::cu, Dwarf::tu, Dwarf::lines): Change valid
values in documentation for addr_size to 4 and 8.

Change-Id: I4a02dca2bb7992198864e545ef099f020f54ff2f

Automatic date update in version.in

PR26198 MinGW failure to link regular object file and LTO object file

PR 26198
* coffgen.c (_bfd_coff_section_already_linked): Allow for plugin
objects both before and after normal object files.
* elflink.c (_bfd_elf_section_already_linked): Likewise.

x86-64: Zero-extend lower 32 bits displacement to 64 bits

Since the addr32 (0x67) prefix zero-extends the lower 32 bits address to
64 bits, change disassembler to zero-extend the lower 32 bits displacement
to 64 bits when there is no base nor index registers.

gas/

PR gas/26237
* testsuite/gas/i386/addr32.s: Add tests for 32-bit wrapped around
address.
* testsuite/gas/i386/x86-64-addr32.s: Likewise.
* testsuite/gas/i386/addr32.d: Updated.
* testsuite/gas/i386/x86-64-addr32-intel.d: Likewise.
* testsuite/gas/i386/x86-64-addr32.d: Likewise.
* testsuite/gas/i386/ilp32/x86-64-addr32-intel.d: Likewise.
* testsuite/gas/i386/ilp32/x86-64-addr32.d: Likewise.

opcodes/

PR gas/26237
* i386-dis.c (OP_E_memory): Without base nor index registers,
32-bit displacement to 64 bits.

gdb: Improve formatting of 'show endian' messages

This commit changes the output of 'show endian'.  Here is a
session before this commit:

    (gdb) show endian
    The target endianness is set automatically (currently little endian)
    (gdb) set endian big
    The target is assumed to be big endian
    (gdb) show endian
    The target is assumed to be big endian
    (gdb)

After this commit the session now looks like this:

    (gdb) show endian
    The target endianness is set automatically (currently little endian).
    (gdb) set endian big
    The target is set to big endian.
    (gdb) show endian
    The target is set to big endian.
    (gdb)

The changes are:

  1. Each line ends with '.', and
  2. After setting the endianness GDB is now a little more assertive;
  'target is set to' not 'target is assumed to be', the user did just
  tell us after all!

gdb: Improve formatting of 'show architecture' messages

This commit changes the output of 'show architecture'.  Here is a
session before this commit:

  (gdb) show architecture
  The target architecture is set automatically (currently i386)
  (gdb) set architecture mips
  The target architecture is assumed to be mips
  (gdb) show architecture
  The target architecture is assumed to be mips
  (gdb)

After this commit the session now looks like this:

  (gdb) show architecture
  The target architecture is set to "auto" (currently "i386").
  (gdb) set architecture mips
  The target architecture is set to "mips".
  (gdb) show architecture
  The target architecture is set to "mips".
  (gdb)

The changes are:

  1. The value is now enclosed in quotes,
  2. Each line ends with '.', and
  3. After setting the architecture GDB is now a little more
  assertive; 'architecture is set to' not 'is assumed to be', the user
  did just tell us after all!

gdb/ChangeLog:

* arch-utils.c (show_architecture): Update formatting of messages.

gdb/testsuite/ChangeLog:

* gdb.arch/amd64-osabi.exp: Update.
* gdb.arch/arm-disassembler-options.exp: Update.
* gdb.arch/powerpc-disassembler-options.exp: Update.
* gdb.arch/ppc64-symtab-cordic.exp: Update.
* gdb.arch/s390-disassembler-options.exp: Update.
* gdb.base/all-architectures.exp.tcl: Update.
* gdb.base/attach-pie-noexec.exp: Update.
* gdb.base/catch-syscall.exp: Update.
* gdb.xml/tdesc-arch.exp: Update.

arc: Detect usage of illegal double register pairs

ARC can use odd-even double register pairs in some selected
instructions. Although the GNU assembler doesn't allow even-odd
registers to be used, there may be cases when the disassembler is
presented with such situation.  This patch add a test and detects such
cases.

opcodes/
2020-07-14  Claudiu Zissulescu  <claziss@gmail.com>

* arc-dis.c (print_insn_arc): Detect and emit a warning when a
faulty double register pair is detected.

binutils/
2020-07-14  Claudiu Zissulescu  <claziss@gmail.com>

* testsuite/binutils-all/arc/double_regs.s: New test.
* testsuite/binutils-all/arc/objdump.exp: Add the above test.

Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>

x86/Intel: debug registers are named DRn

%db<n> is an AT&T invention; the Intel documentation and MASM have only
ever specified DRn (in line with CRn and TRn). (In principle gas also
shouldn't accept the names in Intel mode, but at least for now I've kept
things as they are. Perhaps as a first step this should just be warned
about.)

x86: drop Rm and the 'L' macro

Rm (and hence OP_R()) can be dropped by making 'Z' force modrm.mod to 3
(for OP_E()) instead of ignoring it. While at it move 'Z' handling to
its designated place (after 'Y'; 'W' handling will be moved by a later
change).

Moves to/from TRn are illegal in 64-bit mode and thus get converted to
honor this at the same time (also getting them in line with moves
to/from CRn/DRn ModRM.mod handling wise). This then also frees up the L
macro.

x86: drop Rdq, Rd, and MaskR

Rdq, Rd, and MaskR can be replaced by Edq, Ed / Rm, and MaskE
respectively, as OP_R() doesn't enforce ModRM.mod == 3, and hence where
MOD matters but hasn't been decoded yet it needs to be anyway. (The case
of converting to Rm is temporary until a subsequent change.)

x86: simplify decode of opcodes valid only without any (embedded) prefix

In this case there's no need to go through prefix_table[] at all - the
.prefix_requirement == PREFIX_OPCODE machinery takes care of this case
already.

A couple of further adjustments are needed though:
- Gv / Ev and alike then can't be used (needs to be Gdq / Edq instead),
- dq_mode and friends shouldn't lead to PREFIX_DATA getting set in
  used_prefixes.

x86: also use %BW / %DQ for kshift*

[gdb/testsuite] Fix clone-new-thread-event.c with glibc 2.30

Starting glibc 2.30, unistd.h declares gettid (for _GNU_SOURCE).

This clashes with a static gettid in test source
clone-new-thread-event.c:
...
gdb compile failed, gdb.threads/clone-new-thread-event.c:46:1: error: \
  static declaration of 'gettid' follows non-static declaration
   46 | gettid (void)
      | ^~~~~~
In file included from /usr/include/unistd.h:1170,
                 from gdb.threads/clone-new-thread-event.c:27:
/usr/include/bits/unistd_ext.h:34:16: note: previous declaration of 'gettid' \
  was here
   34 | extern __pid_t gettid (void) __THROW;
      |                ^~~~~~
...

Fix this by renaming the static gettid to local_gettid.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-14  Tom de Vries  <tdevries@suse.de>

* gdb.threads/clone-new-thread-event.c (gettid): Rename to ...
(local_gettid): ... this.
(fn): Update.

x86: simplify decode of opcodes valid with (embedded) 66 prefix only

The only valid (embedded or explicit) prefix being the data size one
(which is a fairly common pattern), avoid going through prefix_table[].
Instead extend the "required prefix" logic to also handle PREFIX_DATA
alone in a table entry, now used to identify this case. This requires
moving the (adjusted) ->prefix_requirement logic ahead of the printing
of stray prefixes, as the latter needs to observe the new setting of
PREFIX_DATA in used_prefixes.

Also add PREFIX_OPCODE on related entries when previously there was
mistakenly no decode step through prefix_table[].

x86: drop further EVEX table entries that can be served by VEX ones

A few cases were missed by 6df22cf64c93 ("x86: drop EVEX table entries
that can be served by VEX ones").

x86: drop need_vex_reg

It was quite odd for the prior operand handling to have to clear this
flag for the actual operand handling to print nothing. Have the actual
operand handling determine whether the operand is actually present.
With this {d,q}_scalar_swap_mode become unused and hence also get dropped.

x86: drop Vex128 and Vex256

These are only used when VEX.L or EVEX.L'L have already been decoded,
and hence the "normal" length dependent name determination is quite
fine. Adjust a few enumerators to make clear that vex_len_table[] has
been consulted; be consistent and do so for all *f128 and *i128 insns
in one go.

x86: replace %LW by %DQ

This makes more visible what the two alternatives will be that result
from this macro.

x86: merge/move logic determining the EVEX disp8 shift

Fold redundant case blocks and move the extra adjustments logic into
the single case block that actually needs it - there's no need to go
through the extra logic for all the other cases. Also utilize there that
vex.b cannot be set at this point, due to earlier logic. Reduce the
comment there, which was partly stale anyway.

x86: extend %BW use to VP{COMPRESS,EXPAND}{B,W}

Unlike the earlier ones these also need their operands adjusted. Replace
the (mis-described: there's nothing "scalar" here) {b,w}_scalar_mode by
a single new mode, with the actual unit width controlled by EVEX.W.

x86-64: fix {,V}PCMPESTR{I,M} disassembly in Intel mode

The operands don't allow disambiguating the insn in 64-bit mode, and
hence suffixes need to be emitted not just in AT&T mode. Achieve this
by re-using %LQ while dropping PCMPESTR_Fixup().

x86: fold VCMP_Fixup() into CMP_Fixup()

There's no reason to have two functions and two tables, when the AVX
functionality here is a proper superset of the SSE one.

x86: don't disassemble MOVBE with two suffixes

MOVBE_Fixup() is entirely redundant with the S macro already used on the
mnemonics, leading to double suffixes in suffix-always mode. Drop the
function.

x86: avoid attaching suffix to register-only CRC32

Just like other insns with GPR operands, CRC32 with only register
operands should not get a suffix added unless in suffix-always mode.
Do away with CRC32_Fixup() altogether, using other more generic logic
instead.

x86-64: don't hide an empty but meaningless REX prefix

Unlike for non-zero values passed to USED_REX(), where rex_used gets
updated only when the respective bit was actually set in the encoding,
zero getting passed in is not further guarded, yet such a (potentially
"empty") REX prefix takes effect only when there are registers numbered
4 and up.

x86: drop dead code from OP_IMREG()

There's only a very limited set of modes that this function gets invoked
with - avoid it being more generic than it needs to be. This may, down
the road, allow actually doing away with the function altogether.

This eliminates a first improperly used "USED_REX (0)".

x86-64: fold ILP32 test expectations

Various of the test expectations get adjusted later in this and a
subsequent series, so in order to avoid having to adjust more instances
than necessary fold respective test ILP32 expectations with their main
64-bit counterparts where they're identical anyway.

gdbserver: fix memory leak when handling qsupported packet

When building gdbserver with AddressSanitizer, I get this annoying
little leak when gdbserver exits:

==307817==ERROR: LeakSanitizer: detected memory leaks

    Direct leak of 14 byte(s) in 1 object(s) allocated from:
        #0 0x7f7fd4256459 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:145
        #1 0x563bef981b80 in xmalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:60
        #2 0x563befb53301 in xstrdup /home/simark/src/binutils-gdb/libiberty/xstrdup.c:34
        #3 0x563bef9d742b in handle_query /home/simark/src/binutils-gdb/gdbserver/server.cc:2286
        #4 0x563bef9ed0b7 in process_serial_event /home/simark/src/binutils-gdb/gdbserver/server.cc:4061
        #5 0x563bef9f1d9e in handle_serial_event(int, void*) /home/simark/src/binutils-gdb/gdbserver/server.cc:4402
        #6 0x563befb0ec65 in handle_file_event /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:548
        #7 0x563befb0f49f in gdb_wait_for_event /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:673
        #8 0x563befb0d4a1 in gdb_do_one_event() /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:215
        #9 0x563bef9e721a in start_event_loop /home/simark/src/binutils-gdb/gdbserver/server.cc:3484
        #10 0x563bef9eb90a in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3875
        #11 0x563bef9ec2c7 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:3961
        #12 0x7f7fd3330001 in __libc_start_main (/usr/lib/libc.so.6+0x27001)

    SUMMARY: AddressSanitizer: 14 byte(s) leaked in 1 allocation(s).

This is due to the handling of unknown qsupported features in
handle_query.  The `qsupported` vector is built, containing all the
feature names received from GDB.  As we iterate on them, when we
encounter unknown ones, we move them at the beginning of the vector, in
preparation of passing this vector of unknown features down to the
target (which may know about them).

When moving these unknown features to other slots in the vector, we
overwrite other pointers without freeing them, which therefore leak.

An easy fix would be to add a `free` when doing the move.  However, I
think this is a good opportunity to sprinkle a bit of automatic memory
management in this code.

So, use a vector of std::string which owns all the entries.  And use a
separate vector (that doesn't own the entries) for the unknown ones,
which is then passed to target_process_qsupported.

Given that the `c_str` method of std::string returns a `const char *`,
it follows that process_stratum_target::process_qsupported must accept a
`const char **` instead of a `char **`.  And while at it, change the
pointer + size paramters to use an array_view instead.

gdbserver/ChangeLog:

* server.cc (handle_query): Use std::vector of
std::string for `qsupported` vector.  Use separate
vector for unknowns.
* target.h (class process_stratum_target) <process_qsupported>:
Change parameters to array_view of const char *.
(target_process_qsupported): Remove `count` parameter.
* target.cc (process_stratum_target::process_qsupported): Change
parameters to array_view of const char *.
* linux-x86-low.cc (class x86_target) <process_qsupported>:
Likewise.

Change-Id: I97f133825faa6d7abbf83a58504eb0ba77462812

Automatic date update in version.in

Fix frame-apply.html collision in GDB manual.

The addition of an anchor for the "frame apply" command was causing
the HTML documentation to include files named both "frame-apply.html"
and "Frame-Apply.html", which collide on case-insensitive file
systems.  This patch removes the redundant anchor and adjusts the two
xrefs to it.

2020-07-13 Paul Carroll <pcarroll@codesourcery.com>

PR gdb/25716

gdb/doc/
* gdb.texinfo (Frame Apply): Remove anchor for 'frame
apply' and adjust xrefs to it.

Skip directory tests in gdb.base/info_sources.exp on remote host

When testing on a remote host, source files from build are copied to
an arbitrary location on host.  Tests that try to pattern-match host
pathnames against directory prefixes on build don't generally work.

2020-07-13  Sandra Loosemore  <sandra@codesourcery.com>

gdb/testsuite/
* gdb.base/info_sources.exp: Skip directory match tests on
remote hosts.

x86: Remove 32-bit sign extension in offset_in_range

When encoding a 32-bit offset, there is no need to sign-extend it to 64
bits since only the lower 32 bits are used.

* config/tc-i386.c (offset_in_range): Remove 32-bit sign
extension.

Fix gdb.base/savedregs.exp with clang

gdb.base/savedregs.exp fails to run with clang, because of:

 gdb compile failed, /gdbtest/src/gdb/testsuite/gdb.base/savedregs.c:36:37:
       warning: operator '<<' has lower precedence than '+'; '+' will be
       evaluated first [-Wshift-op-parentheses]
   return callee (a1 << a2 * a3 / a4 + a6 & a6 % a7 - a8) + done;
                     ~~ ~~~~~~~~~~~~~^~~~
 /gdbtest/build/gdb/testsuite/gdb.base/savedregs.c:36:37: note: place
       parentheses around the '+' expression to silence this warning
   return callee (a1 << a2 * a3 / a4 + a6 & a6 % a7 - a8) + done;
                                     ^
                        (                )
 1 warning generated.

This commit fixes it by adding the suggested parentheses.

gdb/testsuite/ChangeLog:

* gdb.base/savedregs.exp (caller): Use parentheses to
make expected expression evaluation ordering explicit.

Fix gdb.arch/i386-sse.exp with clang

gdb.arch/i386-sse.exp fails to run with clang, because of:

 gdb compile failed, /gdbtest/src/gdb/testsuite/gdb.arch/i386-sse.c:56:40: warning:
       passing 'int *' to parameter of type 'unsigned int *' converts between
       pointers to integer types with different sign [-Wpointer-sign]
   if (!x86_cpuid (1, NULL, NULL, NULL, &edx))
                                        ^~~~
 /gdbtest/src/gdb/testsuite/../nat/x86-cpuid.h:35:41: note: passing
       argument to parameter '__edx' here
             unsigned int *__ecx, unsigned int *__edx)
                                               ^
 1 warning generated.

Fix it by declaring edx unsigned.

gdb/testsuite/ChangeLog:

* gdb.arch/i386-sse.c (have_sse) <edx>: Make unsigned.

Updated French translation for the gas/ and binutils/ sub-directories

Use volatile pointers when attempting to trigger SIGSEGVs

Clang fails to compile a number of files with the following warning:
indirection of non-volatile null pointer will be deleted, not trap
[-Wnull-dereference].  This commit qualifies the relevant pointers
with 'volatile'.

gdb/testsuite/ChangeLog:

* gdb.base/bigcore.c (main): Use a volatile pointer when
attempting to trigger a SIGSEGV.
* gdb.base/gcore-relro-pie.c (break_here): Likewise.
* gdb.base/gcore-tls-pie.c (break_here): Likewise.
* gdb.base/savedregs.c (thrower): Likewise.
* gdb.mi/mi-syn-frame.c (bar): Likewise.

Skip VLA structure field tests when compiling with clang

Clang fails to compile gdb.base/vla-datatypes.c with the following
error: fields must have a constant size: 'variable length array in
structure' extension will never be supported.  This commit factors
the affected tests out into a new testcase, vla-struct-fields.{exp,c},
which is skipped when the testcase is compiled using clang,

gdb/testsuite/ChangeLog:

* gdb.base/vla-datatypes.c (vla_factory): Factor out sections
defining and using VLA structure fields into...
* gdb.base/vla-struct-fields.c: New file.
* gdb.base/vla-datatypes.exp: Factor out VLA structure field
tests into...
* gdb.base/vla-struct-fields.exp: New file.

x86_64-cygwin tests

Tests just having "xfail: x86_64-*-cygwin" aren't good, since
presumably if a test fails on x86_64-cygwin then it also fails on
x86_64-*-pe* and x86_64-*-mingw*.

binutils/
* testsuite/lib/binutils-common.exp (is_pecoff_format): Accept
optional machine-os arg.
ld/
* testsuite/ld-scripts/default-script1.d: Don't skip, xfail
using is_pecoff_format.
* testsuite/ld-scripts/default-script2.d: Likewise.
* testsuite/ld-scripts/default-script3.d: Likewise.
* testsuite/ld-scripts/default-script4.d: Likewise.
* testsuite/ld-scripts/pr20302.d: Remove x86_64-*-cygwin from notarget.
* testsuite/ld-scripts/provide-6.d: Remove x86_64-*-cygwin from xfail.
* testsuite/ld-scripts/provide-8.d: Likewise.

gas DWARF2 test XPASSes

git commit af2b318648 introduced a number of XPASSes.  This removes
them.  (It also introduces a FAIL on ft32-elf but the comment in the
.d file didn't adequately explain why the failure should be expected.)

* testsuite/gas/elf/dwarf2-7.d: Remove most xfails.
* testsuite/gas/elf/dwarf2-12.d: Likewise.
* testsuite/gas/elf/dwarf2-13.d: Likewise.
* testsuite/gas/elf/dwarf2-14.d: Likewise.

[gdb/testsuite] Handle missing gold linker in gdb.base/morestack.exp

When running test-case gdb.base/morestack.exp without the gold linker
installed, we run into:
...
Running src/gdb/testsuite/gdb.base/morestack.exp ...
gdb compile failed, collect2: fatal error: cannot find 'ld'
compilation terminated.
FAIL: gdb.base/morestack.exp: continue

                === gdb Summary ===

nr of expected passes            1
nr of unexpected failures        1
nr of untested testcases         1
...

The test-case needs the gold linker to run correctly (as explained in commit
b8d38ee425 "testsuite: Fix false FAIL for gdb.base/morestack.exp"), but
only prefers it, and doesn't require it.

Fix this by requiring the gold linker in the test-case.  Furthermore, silence
the compilation error by introducing a caching proc have_fuse_ld_gold and
using it in this and other test-cases that use -fuse-ld=gold.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-07-13  Tom de Vries  <tdevries@suse.de>

* lib/gdb.exp (have_fuse_ld_gold): New caching proc.
* gdb.base/gcore-tls-pie.exp: Use have_fuse_ld_gold.
* gdb.base/gold-gdb-index.exp: Same.
* gdb.base/morestack.exp: Same.

gdb: make type::bounds work for array and string types

Getting the bounds of an array (or string) type is a common operation,
and is currently done through its index type:

    my_array_type->index_type ()->bounds ()

I think it would make sense to let the `type::bounds` methods work for
arrays and strings, as a shorthand for this.  It's natural that when
asking for the bounds of an array, we get the bounds of the range type
used as its index type.  In a way, it's equivalent as the now-removed
TYPE_ARRAY_{LOWER,UPPER}_BOUND_IS_UNDEFINED and
TYPE_ARRAY_{LOWER,UPPER}_BOUND_VALUE, except it returns the
`range_bounds` object.  The caller is then responsible for getting the
property it needs in it.

I updated all the spots I could find that could take advantage of this.

Note that this also makes `type::bit_stride` work on array types, since
`type::bit_stride` uses `type::bounds`.  `my_array_type->bit_stride ()`
now returns the bit stride of the array's index type.  So some spots
are also changed to take advantage of this.

gdb/ChangeLog:

* gdbtypes.h (struct type) <bounds>: Handle array and string
types.
* ada-lang.c (assign_aggregate): Use type::bounds on
array/string type.
* c-typeprint.c (c_type_print_varspec_suffix): Likewise.
* c-varobj.c (c_number_of_children): Likewise.
(c_describe_child): Likewise.
* eval.c (evaluate_subexp_for_sizeof): Likewise.
* f-typeprint.c (f_type_print_varspec_suffix): Likewise.
(f_type_print_base): Likewise.
* f-valprint.c (f77_array_offset_tbl): Likewise.
(f77_get_upperbound): Likewise.
(f77_print_array_1): Likewise.
* guile/scm-type.c (gdbscm_type_range): Likewise.
* m2-typeprint.c (m2_array): Likewise.
(m2_is_long_set_of_type): Likewise.
* m2-valprint.c (get_long_set_bounds): Likewise.
* p-typeprint.c (pascal_type_print_varspec_prefix): Likewise.
* python/py-type.c (typy_range): Likewise.
* rust-lang.c (rust_internal_print_type): Likewise.
* type-stack.c (type_stack::follow_types): Likewise.
* valarith.c (value_subscripted_rvalue): Likewise.
* valops.c (value_cast): Likewise.

Change-Id: I5c0c08930bffe42fd69cb4bfcece28944dd88d1f

gdb: remove TYPE_ARRAY_BIT_STRIDE

Remove it and update all callers to use the equivalent accessor methods.
A subsequent patch will make type::bit_stride work for array types
(effectively replacing this macro), but I wanted to keep this patch a
simple mechanical change.

gdb/ChangeLog:

* gdbtypes.c (TYPE_ARRAY_BIT_STRIDE): Remove.  Update all
callers to use the equivalent accessor methods.

Change-Id: I09e14bd45075f98567adce8a0b93edea7722f812

gdb: remove TYPE_BIT_STRIDE

Remove the macro and add a `bit_stride` method to `struct range_bounds`,
which does the byte -> bit conversion if needed.

Add a convenience `bit_stride` method to `struct type` as well.  I don't
really understand why the bit/byte stride is stored in the data
structure for bounds.  Maybe it was just put there because
`range_bounds` was already a data structure specific to TYPE_CODE_RANGE
types?  If the stride is indeed not related to the bounds, then I find
it more logical to do `my_range_type->bit_stride ()` than
`my_range_type->bounds ()->bit_stride ()`, hence the convenience
function on `struct type`.

gdb/ChangeLog:

* gdbtypes.h (struct range_bounds) <bit_stride>: New method.
(struct type) <bit_stride>: New method.
(TYPE_BIT_STRIDE): Remove.
* gdbtypes.c (update_static_array_size): Use type::bit_stride.

Change-Id: I6ecc1cfefdc20711fa8f188a94a05c1e116c9922

gdb: remove TYPE_ARRAY_{LOWER,UPPER}_BOUND_VALUE

Remove the macros, use the various equivalent getters instead.

gdb/ChangeLog:

* gdbtypes.h (TYPE_ARRAY_LOWER_BOUND_VALUE,
TYPE_ARRAY_UPPER_BOUND_VALUE): Remove.  Update all
callers to use the equivalent accessor methods instead.

Change-Id: I7f96d988f872170e7a2f58095832710e62b85cfd

gdb: remove TYPE_ARRAY_{UPPER,LOWER}_BOUND_IS_UNDEFINED

Remove the macros, use the various equivalent getters instead.

gdb/ChangeLog:

* gdbtypes.h (TYPE_ARRAY_UPPER_BOUND_IS_UNDEFINED,
TYPE_ARRAY_LOWER_BOUND_IS_UNDEFINED): Remove.  Update all
callers to use the equivalent accessor methods instead.

Change-Id: Ifb4c36f440b82533bde5d15a5cbb2fc91f467292

gdb: remove TYPE_LOW_BOUND_KIND and TYPE_HIGH_BOUND_KIND

Remove the macros, use the getters of `struct dynamic_prop` instead.

gdb/ChangeLog:

* gdbtypes.h (TYPE_LOW_BOUND_KIND,
TYPE_HIGH_BOUND_KIND): Remove.  Update all callers
to use dynamic_prop::kind.

Change-Id: Icb1fc761f675bfac934209f8102392504d905c44

gdb: remove TYPE_LOW_BOUND_UNDEFINED and TYPE_HIGH_BOUND_UNDEFINED

Remove the macros, use the getters of `struct dynamic_prop` instead.

gdb/ChangeLog:

* gdbtypes.h (TYPE_LOW_BOUND_UNDEFINED,
TYPE_HIGH_BOUND_UNDEFINED): Remove.  Update all callers
to get the bound property's kind and check against
PROP_UNDEFINED.

Change-Id: I6a7641ac1aa3fa7fca0c21f00556f185f2e2d68c

gdb: remove TYPE_HIGH_BOUND and TYPE_LOW_BOUND

Remove the macros, use the getters of `struct dynamic_prop` instead.

gdb/ChangeLog:

* gdbtypes.h (TYPE_LOW_BOUND, TYPE_HIGH_BOUND): Remove.  Update
all callers to use type::range_bounds followed by
dynamic_prop::{low,high}.

Change-Id: I31beeed65d94d81ac4f999244a8b859e2ee961d1

gdb: add accessors to struct dynamic_prop

Add setters, to ensure that the kind and value of the property are
always kept in sync (a caller can't forget one or the other).  Add
getters, such that we can assert that when a caller accesses a data bit
of the property, the property is indeed of the corresponding kind.

Note that because of the way `struct dynamic_prop` is allocated
currently, we can't make the `m_kind` and `m_data` fields private.  That
would make the type non-default-constructible, and we would have to call
the constructor when allocating them.  However, I still prefixed them
with `m_` to indicate that they should not be accessed from outside the
class (and also to be able to use the name `kind` for the method).

gdb/ChangeLog:

* gdbtypes.h (struct dynamic_prop) <kind, set_undefined,
const_val, set_const_val, baton, set_locexpr, set_loclist,
set_addr_offset, variant_parts, set_variant_parts,
original_type, set_original_type>: New methods.
<kind>: Rename to...
<m_kind>: ... this.  Update all users to use the new methods
instead.
<data>: Rename to...
<m_data>: ... this.  Update all users to use the new methods
instead.

Change-Id: Ib72a8eb440dfeb1a5421d0933334230d7f2478f9

gdb: make get_discrete_bounds check for non-constant range bounds

The next patch adds getters to the `dynamic_prop` structure.  These
getters validate that the accessed data matches the property kind (for
example, to access the `const_val` field, the property must be of kind
`PROP_CONST`).  It found one instance where we are accessing the
`const_val` data of a property that has the undefined kind.

This happens in function `get_discrete_bounds`, and is exposed by test
gdb.base/ptype.exp, amongst others.  Without this patch, we would get:

    $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.base/ptype/ptype -ex "ptype t_char_array"
    Reading symbols from testsuite/outputs/gdb.base/ptype/ptype...
    type = char [
    /home/smarchi/src/binutils-gdb/gdb/gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    Quit this debugging session? (y or n)

The `get_discrete_bounds` function returns the bounds of a type (not
only range types).  For range types, it naturally uses the bound
properties that are intrinsic to the range type.  It accesses these
properties using TYPE_LOW_BOUND and TYPE_HIGH_BOUND, which assume the
properties are defined and have constant values.  This is sometimes not
the case, and the passed range type (as in the example above) has an
undefined high/upper bound.

Given its current interface (returning two LONGEST values for low and
high), `get_discrete_bounds` can't really work if the range type's
bounds are not both defined and both constant values.

This patch changes the function to return -1 (failure to get the bounds)
if any of the range type's bounds is not a constant value.  It is
sufficient to fix the issue and it seems to keep the callers happy, at
least according to the testsuite.

A bit in `get_array_bounds` could be removed, since
`get_discrete_bounds` no longer returns 1 if a bound is undefined.

gdb/ChangeLog:

* gdbtypes.c (get_discrete_bounds): Return failure if
the range type's bounds are not both defined and constant
values.
(get_array_bounds): Update comment.  Remove undefined bound check.

Change-Id: I047a3beee2c1e275f888cfc4778228339922bde9

gdb: remove TYPE_RANGE_DATA macro

Remove it in favor of using type::bounds directly.

gdb/ChangeLog:

* gdbtypes.h (TYPE_RANGE_DATA): Remove.  Update callers to use
the type::bounds method directly.

Change-Id: Id4fab22af0a94cbf505f78b01b3ee5b3d682fba2

gdb: add type::bounds / type::set_bounds

Add the `bounds` and `set_bounds` methods on `struct type`, in order to
remove the `TYPE_RANGE_DATA` macro.  In this patch, the
`TYPE_RANGE_DATA` macro is changed to use `type::bounds`, so all the
call sites that are used to set a range type's bounds are changed to use
`type::set_bounds`.  The next patch will remove `TYPE_RANGE_DATA`
completely.

gdb/ChangeLog:

* gdbtypes.h (struct type) <bounds, set_bounds>: New methods.
(TYPE_RANGE_DATA): Use type::bounds.  Change all uses that
are used to set the range type's bounds to use set_bounds.

Change-Id: I62e15506239b98404e62bbea8120db184ed87847

Automatic date update in version.in

Automatic date update in version.in

rust: Fix rust modules test

I noticed that the modules test was failing. Some choice use of `nm`
revealed `TWENTY_THREE` was not in the final binary. Fix by taking a
pointer to the global, forcing the linker to keep the symbol in.

gdb/testsuite/ChangeLog
2020-07-11  Daniel Xu  <dxu@dxuuu.xyz>

PR rust/26121
* gdb.rust/modules.rs: Prevent linker from discarding test
symbol.

Signed-off-by: Daniel Xu <dxu@dxuuu.xyz>

Fine tune exec-file-mismatch help and documentation.

It was deemed better to explicitly mention in help and doc that build IDs
are used for comparison, and that symbols are loaded when asking to
load the exec-file.

This is V2, fixing 2 typos and replacing 'If the user asks to load'
by 'If the user confirms loading', as suggested by Pedro.

gdb/ChangeLog
2020-07-11  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* exec.c (_initialize_exec): Update exec-file-mismatch help.

gdb/doc/ChangeLog
2020-07-11  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* gdb.texinfo (Attach): Update exec-file-mismatch doc.

x86: Support GNU_PROPERTY_X86_FEATURE_2_TMM

Support GNU_PROPERTY_X86_FEATURE_2_TMM in

https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/1

 #define GNU_PROPERTY_X86_FEATURE_2_TMM      (1U << 10)

binutils/

* readelf.c (decode_x86_feature_2): Handle
GNU_PROPERTY_X86_FEATURE_2_TMM.

gas/

* config/tc-i386.c (output_insn): Check i.xstate to set
GNU_PROPERTY_X86_FEATURE_2_TMM.
* testsuite/gas/i386/i386.exp: Run x86-64-property-7,
x86-64-property-8 and x86-64-property-9.
* testsuite/gas/i386/x86-64-property-7.d: New file.
* testsuite/gas/i386/x86-64-property-7.s: Likewise.
* testsuite/gas/i386/x86-64-property-8.d: Likewise.
* testsuite/gas/i386/x86-64-property-8.s: Likewise.
* testsuite/gas/i386/x86-64-property-9.d: Likewise.
* testsuite/gas/i386/x86-64-property-9.s: Likewise.

include/

* elf/common.h (GNU_PROPERTY_X86_FEATURE_2_TMM): New.

Automatic date update in version.in

Fix crash if connection drops in scoped_restore_current_thread's ctor, part 2

Running the testsuite against an Asan-enabled build of GDB makes
gdb.base/multi-target.exp expose this bug.

scoped_restore_current_thread's ctor calls get_frame_id to record the
selected frame's ID to restore later.  If the frame ID hasn't been
computed yet, it will be computed on the spot, and that will usually
require accessing the target's memory and registers.  If the remote
connection closes, while we're computing the frame ID, the remote
target exits its inferiors, unpushes itself, and throws a
TARGET_CLOSE_ERROR error.  Exiting the inferiors deletes the
inferior's threads.

scoped_restore_current_thread increments the current thread's refcount
to prevent the thread from being deleted from under its feet.
However, the code that does that isn't considering the case of the
thread being deleted from within get_frame_id.  It only increments the
refcount _after_ get_frame_id returns.  So if the current thread is
indeed deleted, the

     tp->incref ();

statement references a stale TP pointer.

Incrementing the refcounts earlier fixes it.

We should probably also let the TARGET_CLOSE_ERROR error propagate in
this case.  That alone would fix it, though it seems better to tweak
the refcount handling too.  And to avoid having to manually decref
before throwing, convert to use gdb::ref_ptr.

Unfortunately, we can't define inferior_ref in inferior.h and then use
it in scoped_restore_current_thread, because
scoped_restore_current_thread is defined before inferior is
(inferior.h includes gdbthread.h).  To break that dependency, we would
have to move scoped_restore_current_thread to its own header.  I'm not
doing that here.

gdb/ChangeLog:

* gdbthread.h (inferior_ref): Define.
(scoped_restore_current_thread) <m_thread>: Now a thread_info_ref.
(scoped_restore_current_thread) <m_inf>: Now an inferior_ref.
* thread.c
(scoped_restore_current_thread::restore):
Adjust to gdb::ref_ptr.
(scoped_restore_current_thread::~scoped_restore_current_thread):
Remove manual decref handling.
(scoped_restore_current_thread::scoped_restore_current_thread):
Adjust to use
inferior_ref::new_reference/thread_info_ref::new_reference.
Incref the thread before calling get_frame_id instead of after.
Let TARGET_CLOSE_ERROR propagate.

Fix crash if connection drops in scoped_restore_current_thread's ctor, part 1

Running the testsuite against an Asan-enabled build of GDB makes
gdb.base/multi-target.exp expose this bug.

scoped_restore_current_thread's ctor calls get_frame_id to record the
selected frame's ID to restore later.  If the frame ID hasn't been
computed yet, it will be computed on the spot, and that will usually
require accessing the target's memory and registers, which requires
remote accesses.  If the remote connection closes while we're
computing the frame ID, the remote target exits its inferiors,
unpushes itself, and throws a TARGET_CLOSE_ERROR error.

If that happens, GDB can currently crash, here:

> ==18555==ERROR: AddressSanitizer: heap-use-after-free on address 0x621004670aa8 at pc 0x0000007ab125 bp 0x7ffdecaecd20 sp 0x7ffdecaecd10
> READ of size 4 at 0x621004670aa8 thread T0
>     #0 0x7ab124 in dwarf2_frame_this_id src/binutils-gdb/gdb/dwarf2/frame.c:1228
>     #1 0x983ec5 in compute_frame_id src/binutils-gdb/gdb/frame.c:550
>     #2 0x9841ee in get_frame_id(frame_info*) src/binutils-gdb/gdb/frame.c:582
>     #3 0x1093faa in scoped_restore_current_thread::scoped_restore_current_thread() src/binutils-gdb/gdb/thread.c:1462
>     #4 0xaee5ba in fetch_inferior_event(void*) src/binutils-gdb/gdb/infrun.c:3968
>     #5 0xaa990b in inferior_event_handler(inferior_event_type, void*) src/binutils-gdb/gdb/inf-loop.c:43
>     #6 0xea61b6 in remote_async_serial_handler src/binutils-gdb/gdb/remote.c:14161
>     #7 0xefca8a in run_async_handler_and_reschedule src/binutils-gdb/gdb/ser-base.c:137
>     #8 0xefcd23 in fd_event src/binutils-gdb/gdb/ser-base.c:188
>     #9 0x15a7416 in handle_file_event src/binutils-gdb/gdbsupport/event-loop.cc:548
>     #10 0x15a7c36 in gdb_wait_for_event src/binutils-gdb/gdbsupport/event-loop.cc:673
>     #11 0x15a5dbb in gdb_do_one_event() src/binutils-gdb/gdbsupport/event-loop.cc:215
>     #12 0xbfe62d in start_event_loop src/binutils-gdb/gdb/main.c:356
>     #13 0xbfe935 in captured_command_loop src/binutils-gdb/gdb/main.c:416
>     #14 0xc01d39 in captured_main src/binutils-gdb/gdb/main.c:1253
>     #15 0xc01dc9 in gdb_main(captured_main_args*) src/binutils-gdb/gdb/main.c:1268
>     #16 0x414ddd in main src/binutils-gdb/gdb/gdb.c:32
>     #17 0x7f590110b82f in __libc_start_main ../csu/libc-start.c:291
>     #18 0x414bd8 in _start (build/binutils-gdb/gdb/gdb+0x414bd8)

What happens is that above, we're in dwarf2_frame_this_id, just after
the dwarf2_frame_cache call.  The "cache" variable that the
dwarf2_frame_cache function returned is already stale.  It's been
released here, from within the dwarf2_frame_cache:

(top-gdb) bt
#0  reinit_frame_cache () at src/gdb/frame.c:1855
#1  0x00000000014ff7b0 in switch_to_no_thread () at src/gdb/thread.c:1301
#2  0x0000000000f66d3e in switch_to_inferior_no_thread (inf=0x615000338180) at src/gdb/inferior.c:626
#3  0x00000000012f3826 in remote_unpush_target (target=0x6170000c5900) at src/gdb/remote.c:5521
#4  0x00000000013097e0 in remote_target::readchar (this=0x6170000c5900, timeout=2) at src/gdb/remote.c:9137
#5  0x000000000130be4d in remote_target::getpkt_or_notif_sane_1 (this=0x6170000c5900, buf=0x6170000c5918, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9683
#6  0x000000000130c8ab in remote_target::getpkt_sane (this=0x6170000c5900, buf=0x6170000c5918, forever=0) at src/gdb/remote.c:9790
#7  0x000000000130bc0d in remote_target::getpkt (this=0x6170000c5900, buf=0x6170000c5918, forever=0) at src/gdb/remote.c:9623
#8  0x000000000130838e in remote_target::remote_read_bytes_1 (this=0x6170000c5900, memaddr=0x7fffffffcdc0, myaddr=0x6080000ad3bc "", len_units=64, unit_size=1, xfered_len_units=0x7fff6a29b9a0) at src/gdb/remote.c:8860
#9  0x0000000001308bd2 in remote_target::remote_read_bytes (this=0x6170000c5900, memaddr=0x7fffffffcdc0, myaddr=0x6080000ad3bc "", len=64, unit_size=1, xfered_len=0x7fff6a29b9a0) at src/gdb/remote.c:8987
#10 0x0000000001311ed1 in remote_target::xfer_partial (this=0x6170000c5900, object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0x6080000ad3bc "", writebuf=0x0, offset=140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/remote.c:10988
#11 0x00000000014ba969 in raw_memory_xfer_partial (ops=0x6170000c5900, readbuf=0x6080000ad3bc "", writebuf=0x0, memaddr=140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/target.c:918
#12 0x00000000014bb720 in target_xfer_partial (ops=0x6170000c5900, object=TARGET_OBJECT_RAW_MEMORY, annex=0x0, readbuf=0x6080000ad3bc "", writebuf=0x0, offset=140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/target.c:1148
#13 0x00000000014bc3b5 in target_read_partial (ops=0x6170000c5900, object=TARGET_OBJECT_RAW_MEMORY, annex=0x0, buf=0x6080000ad3bc "", offset=140737488342464, len=64, xfered_len=0x7fff6a29b9a0) at src/gdb/target.c:1380
#14 0x00000000014bc593 in target_read (ops=0x6170000c5900, object=TARGET_OBJECT_RAW_MEMORY, annex=0x0, buf=0x6080000ad3bc "", offset=140737488342464, len=64) at src/gdb/target.c:1419
#15 0x00000000014bbd4d in target_read_raw_memory (memaddr=0x7fffffffcdc0, myaddr=0x6080000ad3bc "", len=64) at src/gdb/target.c:1252
#16 0x0000000000bf27df in dcache_read_line (dcache=0x6060001eddc0, db=0x6080000ad3a0) at src/gdb/dcache.c:336
#17 0x0000000000bf2b72 in dcache_peek_byte (dcache=0x6060001eddc0, addr=0x7fffffffcdd8, ptr=0x6020001231b0 "") at src/gdb/dcache.c:403
#18 0x0000000000bf3103 in dcache_read_memory_partial (ops=0x6170000c5900, dcache=0x6060001eddc0, memaddr=0x7fffffffcdd8, myaddr=0x6020001231b0 "", len=8, xfered_len=0x7fff6a29bf20) at src/gdb/dcache.c:484
#19 0x00000000014bafe9 in memory_xfer_partial_1 (ops=0x6170000c5900, object=TARGET_OBJECT_STACK_MEMORY, readbuf=0x6020001231b0 "", writebuf=0x0, memaddr=140737488342488, len=8, xfered_len=0x7fff6a29bf20) at src/gdb/target.c:1034
#20 0x00000000014bb212 in memory_xfer_partial (ops=0x6170000c5900, object=TARGET_OBJECT_STACK_MEMORY, readbuf=0x6020001231b0 "", writebuf=0x0, memaddr=140737488342488, len=8, xfered_len=0x7fff6a29bf20) at src/gdb/target.c:1076
#21 0x00000000014bb6b3 in target_xfer_partial (ops=0x6170000c5900, object=TARGET_OBJECT_STACK_MEMORY, annex=0x0, readbuf=0x6020001231b0 "", writebuf=0x0, offset=140737488342488, len=8, xfered_len=0x7fff6a29bf20) at src/gdb/target.c:1133
#22 0x000000000164564d in read_value_memory (val=0x60f000029440, bit_offset=0, stack=1, memaddr=0x7fffffffcdd8, buffer=0x6020001231b0 "", length=8) at src/gdb/valops.c:956
#23 0x0000000001680fff in value_fetch_lazy_memory (val=0x60f000029440) at src/gdb/value.c:3764
#24 0x0000000001681efd in value_fetch_lazy (val=0x60f000029440) at src/gdb/value.c:3910
#25 0x0000000001676143 in value_optimized_out (value=0x60f000029440) at src/gdb/value.c:1411
#26 0x0000000000e0fcb8 in frame_register_unwind (next_frame=0x6210066bfde0, regnum=16, optimizedp=0x7fff6a29c200, unavailablep=0x7fff6a29c240, lvalp=0x7fff6a29c2c0, addrp=0x7fff6a29c300, realnump=0x7fff6a29c280, bufferp=0x7fff6a29c3a0 "@\304)j\377\177") at src/gdb/frame.c:1144
#27 0x0000000000e10418 in frame_unwind_register (next_frame=0x6210066bfde0, regnum=16, buf=0x7fff6a29c3a0 "@\304)j\377\177") at src/gdb/frame.c:1196
#28 0x0000000000f00431 in i386_unwind_pc (gdbarch=0x6210043d0110, next_frame=0x6210066bfde0) at src/gdb/i386-tdep.c:1969
#29 0x0000000000e39724 in gdbarch_unwind_pc (gdbarch=0x6210043d0110, next_frame=0x6210066bfde0) at src/gdb/gdbarch.c:3056
#30 0x0000000000c2ea90 in dwarf2_tailcall_sniffer_first (this_frame=0x6210066bfde0, tailcall_cachep=0x6210066bfee0, entry_cfa_sp_offsetp=0x0) at src/gdb/dwarf2/frame-tailcall.c:423
#31 0x0000000000c36bdb in dwarf2_frame_cache (this_frame=0x6210066bfde0, this_cache=0x6210066bfdf8) at src/gdb/dwarf2/frame.c:1198
#32 0x0000000000c36eb3 in dwarf2_frame_this_id (this_frame=0x6210066bfde0, this_cache=0x6210066bfdf8, this_id=0x6210066bfe40) at src/gdb/dwarf2/frame.c:1226

Note that remote_target::readchar in frame #4 throws
TARGET_CLOSE_ERROR after the remote_unpush_target in frame #3 returns.

The problem is that the TARGET_CLOSE_ERROR is swallowed by
value_optimized_out in frame #25.

If we fix that one, then we run into dwarf2_tailcall_sniffer_first
swallowing the exception in frame #30 too.

The attached patch fixes it by making those spots swallow fewer kinds
of errors.

gdb/ChangeLog:

* frame-tailcall.c (dwarf2_tailcall_sniffer_first): Only swallow
NO_ENTRY_VALUE_ERROR / MEMORY_ERROR / OPTIMIZED_OUT_ERROR /
NOT_AVAILABLE_ERROR.
* value.c (value_optimized_out): Only swallow MEMORY_ERROR /
OPTIMIZED_OUT_ERROR / NOT_AVAILABLE_ERROR.

Fix GDB busy loop when interrupting non-stop program (PR 26199)

When interrupting a program in non-stop, the program gets interrupted
correctly, but GDB busy loops (the event loop is always woken up).

Here is how to reproduce it:

 1. Start GDB: ./gdb -nx --data-directory=data-directory -ex "set non-stop 1" --args  /bin/sleep 60
 2. Run the program with "run"
 3. Interrupt with ^C.
 4. Look into htop, see GDB taking 100% CPU

Debugging `handle_file_event`, we see that the event source that wakes
up the event loop is the linux-nat one:

 (top-gdb) p file_ptr.proc
 $5 = (handler_func *) 0xb9cccd <handle_target_event(int, gdb_client_data)>
 ^^^^^^^^^^^^^^^^^^^
 |
 \-- the linux-nat callback

Debugging fetch_inferior_event and do_target_wait, we see that we
don't actually call `wait` on the linux-nat target, because
inferior_matches returns false:

 auto inferior_matches = [&wait_ptid] (inferior *inf)
   {
     return (inf->process_target () != NULL
     && (threads_are_executing (inf->process_target ())
 || threads_are_resumed_pending_p (inf))
     && ptid_t (inf->pid).matches (wait_ptid));
   };

because `threads_are_executing` is false.

What happens is:

 1. User types ctrl-c, that writes in the linux-nat pipe, waking up
    the event source.

 2. linux-nat's wait gets called, the SIGINT event is returned, but
    before returning, it marks the pipe again, in order for wait to
    get called again:

    /* If we requested any event, and something came out, assume there
       may be more.  If we requested a specific lwp or process, also
       assume there may be more.  */
    if (target_is_async_p ()
&& ((ourstatus->kind != TARGET_WAITKIND_IGNORE
     && ourstatus->kind != TARGET_WAITKIND_NO_RESUMED)
    || ptid != minus_one_ptid))
      async_file_mark ();

 3. The SIGINT event is handled, the program is stopped, the stop
    notification is printed.

 4. The event loop is woken up again because of the `async_file_mark`
    of step 2.

 5. Because `inferior_matches` returns false, we never call
    linux-nat's wait, so the pipe stays readable.

 6. Goto 4.

Pedro says:

This commit fixes it by letting do_target_wait call target_wait even
if threads_are_executing is false.  This will normally result in the
target returning TARGET_WAITKIND_NO_RESUMED, and _not_ marking its
event source again.  This results in infrun only calling into the
target only once (i.e., breaking the busy loop).

Note that the busy loop bug didn't trigger in all-stop mode because
all-stop handles this by unregistering the target from the event loop
as soon as it was all stopped -- see
inf-loop.c:inferior_event_handler's INF_EXEC_COMPLETE handling.  If we
remove that non-stop check from inferior_event_handler, and replace
the target_has_execution check for threads_are_executing instead, it
also fixes the issue for non-stop.  I considered that as the final
solution, but decided that the solution proposed here instead is just
simpler and more future-proof design.  With the
TARGET_WAITKIND_NO_RESUMED handling fixes done in the previous
patches, I think it should be possible to always keep the target
registered in the event loop, meaning we could eliminate the
target_async(0) call from inferior_event_handler as well as most of
the target_async(1) calls in the target backends.  That would allow in
the future e.g., the remote target reporting asynchronous
notifications even if all threads are stopped.  I haven't attempted
that, though.

gdb/ChangeLog:
yyyy-mm-dd  Simon Marchi  <simon.marchi@polymtl.ca>
    Pedro Alves  <pedro@palves.net>

PR gdb/26199
* infrun.c (threads_are_resumed_pending_p): Delete.
(do_target_wait): Remove threads_are_executing and
threads_are_resumed_pending_p checks from the inferior_matches
lambda.  Update comments.

Testcase for previous handle_no_resumed fixes

This adds a testcase that covers the scenarios described in the
previous two commits.

gdb/testsuite/ChangeLog:

PR gdb/26199
* gdb.multi/multi-target.c (exit_thread): New.
(thread_start): Break loop if EXIT_THREAD.
* gdb.multi/multi-target.exp (test_no_unwaited_for): New proc.
(top level) Call test_no_resumed.

Make handle_no_resumed transfer terminal

Let's consider the same use case as in the previous commit:

Say you have two inferiors 1 and 2, each connected to a different
target, A and B.

Now say you set inferior 2 running, with "continue &".

Now you select a thread of inferior 1, say thread 1.2, and continue in
the foreground.  All other threads of inferior 1 are left stopped.
Thread 1.2 exits, and thus target A has no other resumed thread, so it
reports TARGET_WAITKIND_NO_RESUMED.

At this point, because the threads of inferior 2 are still executing
the TARGET_WAITKIND_NO_RESUMED event is ignored.

Now, the user types Ctrl-C.  Because GDB had previously put inferior 1
in the foreground, the kernel sends the SIGINT to that inferior.
However, no thread in that inferior is executing right now, so ptrace
never intercepts the SIGINT -- it is never dequeued by any thread.
The result is that GDB's CLI is stuck.  There's no way to get back the
prompt (unless inferior 2 happens to report some event).

The fix in this commit is to make handle_no_resumed give the terminal
to some other inferior that still has threads executing so that a
subsequent Ctrl-C reaches that target first (and then GDB intercepts
the SIGINT).  This is a bit hacky, but seems like the best we can do
with the current design.

I think that putting all native inferiors in their own session would
help fixing this in a clean way, since with that a Ctrl-C on GDB's
terminal will _always_ reach GDB first, and then GDB can decide how to
pause the inferior.  But that's a much larger change.

The testcase added by the following patch needs this fix.

gdb/ChangeLog:

PR gdb/26199
* infrun.c (handle_no_resumed): Transfer terminal to inferior with
executing threads.

Fix handle_no_resumed w/ multiple targets

handle_no_resumed is currently not considering multiple targets.

Say you have two inferiors 1 and 2, each connected to a different
target, A and B.

Now say you set inferior 2 running, with "continue &".

Now you select a thread of inferior 1, say thread 1.2, and continue in
the foreground.  All other threads of inferior 1 are left stopped.
Thread 1.2 exits, and thus target A has no other resumed thread, so it
reports TARGET_WAITKIND_NO_RESUMED.

At this point, if both inferiors were running in the same target,
handle_no_resumed would realize that threads of inferior 2 are still
executing, so the TARGET_WAITKIND_NO_RESUMED event should be ignored.
But because handle_no_resumed only walks the threads of the current
target, it misses noticing that threads of inferior 2 are still
executing.  The fix is just to walk over all threads of all targets.

A testcase covering the use case above will be added in a following
patch.  It can't be added yet because it depends on yet another fix to
handle_no_resumed not included here.

gdb/ChangeLog:

PR gdb/26199
* infrun.c (handle_no_resumed): Handle multiple targets.

Avoid constant stream of TARGET_WAITKIND_NO_RESUMED

If we hit the synchronous execution command case described by
handle_no_resumed, and handle_no_resumed determines that the event
should be ignored, because it found a thread that is executing, we end
up in prepare_to_wait.

There, if the current target is not registered in the event loop right
now, we call mark_infrun_async_event_handler.  With that event handler
marked, the event loop calls again into fetch_inferior_event, which
calls target_wait, which returns TARGET_WAITKIND_NO_RESUMED, and we
end up in handle_no_resumed, again ignoring the event and marking
infrun_async_event_handler.  The result is that GDB is now always
keeping the CPU 100% busy in this loop, even though it continues to be
able to react to input and to real target events, because we still go
through the event-loop.

The problem is that marking of the infrun_async_event_handler in
prepare_to_wait.  That is there to handle targets that don't support
asynchronous execution.  So the correct predicate is whether async
execution is supported, not whether the target is async right now.

gdb/ChangeLog:

PR gdb/26199
* infrun.c (prepare_to_wait): Check target_can_async_p instead of
target_is_async_p.

Fix latent bug in target_pass_ctrlc

We were checking the thr->executing of an exited thread.

gdb/ChangeLog:

PR gdb/26199
* target.c (target_pass_ctrlc): Look at the inferior's non-exited
threads, not all threads.

Fix spurious unhandled remote %Stop notifications

In non-stop mode, remote targets mark an async event source whose
callback is supposed to result in calling remote_target::wait_ns to
either process the event queue, or acknowledge an incoming %Stop
notification.

The callback in question is remote_async_inferior_event_handler, where
we call inferior_event_handler, to end up in fetch_inferior_event ->
target_wait -> remote_target::wait -> remote_target::wait_ns.

A problem here however is that when debugging multiple targets,
fetch_inferior_event can pull events out of any target picked at
random, for event fairness.  This means that when
remote_async_inferior_event_handler returns, remote_target::wait may
have not been called at all, and thus pending notifications may have
not been acked.  Because async event sources auto-clear, when
remote_async_inferior_event_handler returns the async event handler is
no longer marked, so the event loop won't automatically call
remote_async_inferior_event_handler again to try to process the
pending remote notifications/queue.  The result is that stop events
may end up not processed, e.g., "interrupt -a" seemingly not managing
to stop all threads.

Fix this by making remote_async_inferior_event_handler mark the event
handler again before returning, if necessary.

Maybe a better fix would be to make async event handlers not
auto-clear themselves, make that the responsibility of the callback,
so that the event loop would keep calling the callback automatically.
Or, we could try making so that fetch_inferior_event would optionally
handle events only for the target that it got passed down via
parameter.  However, I don't think now just before branching is the
time to try to do any such change.

gdb/ChangeLog:

PR gdb/26199
* remote.c (remote_target::open_1): Pass remote target pointer as
data to create_async_event_handler.
(remote_async_inferior_event_handler): Mark async event handler
before returning if the remote target still has either pending
events or unacknowledged notifications.

Enable multi-process mode in the FreeBSD native target.

gdb/ChangeLog:

* fbsd-nat.h (fbsd_nat_target::supports_multi_process): New
declaration.
* fbsd-nat.c (fbsd_nat_target::supports_multi_process): New
function.

x86: Extract extended states from instruction template

Extract extended states from operand types in instruction template.  Set
xstate_zmm for master register move.

* config/tc-i386.c (_i386_insn): Remove has_regmmx, has_regxmm,
has_regymm, has_regzmm and has_regtmm.  Add xstate.
(md_assemble): Set i.xstate from operand types in instruction
template.
(build_modrm_byte): Updated.
(output_insn): Check i.xstate.
* testsuite/gas/i386/i386.exp: Run property-6 and
x86-64-property-6.
* testsuite/gas/i386/property-6.d: New file.
* testsuite/gas/i386/property-6.s: Updated.
* testsuite/gas/i386/x86-64-property-6.d: Likewise.

gas/i386/property-5.d: Correct test name

* testsuite/gas/i386/property-5.d: Correct test name.

x86: Add support for Intel AMX instructions

gas/

* doc/c-i386.texi: Document amx_int8, amx_bf16 and amx_tile.
* config/tc-i386.c (i386_error): Add invalid_sib_address.
(cpu_arch): Add .amx_int8, .amx_bf16 and .amx_tile.
(cpu_noarch): Add noamx_int8, noamx_bf16 and noamx_tile.
(match_simd_size): Add tmmword check.
(operand_type_match): Add tmmword.
(type_names): Add rTMM.
(i386_error): Add invalid_tmm_register_set.
(check_VecOperands): Handle invalid_sib_address and
invalid_tmm_register_set.
(match_template): Handle invalid_sib_address.
(build_modrm_byte): Handle non-vector SIB and zmmword.
(i386_index_check): Disallow RegIP for non-vector SIB.
(check_register): Handle zmmword.
* testsuite/gas/i386/i386.exp: Add AMX new tests.
* testsuite/gas/i386/intel-regs.d: Add tmm.
* testsuite/gas/i386/intel-regs.s: Add tmm.
* testsuite/gas/i386/x86-64-amx-intel.d: New.
* testsuite/gas/i386/x86-64-amx-inval.l: New.
* testsuite/gas/i386/x86-64-amx-inval.s: New.
* testsuite/gas/i386/x86-64-amx.d: New.
* testsuite/gas/i386/x86-64-amx.s: New.
* testsuite/gas/i386/x86-64-amx-bad.d: New.
* testsuite/gas/i386/x86-64-amx-bad.s: New.

opcodes/

* i386-dis.c (TMM): New.
(EXtmm): Likewise.
(VexTmm): Likewise.
(MVexSIBMEM): Likewise.
(tmm_mode): Likewise.
(vex_sibmem_mode): Likewise.
(REG_VEX_0F3849_X86_64_P_0_W_0_M_1): Likewise.
(MOD_VEX_0F3849_X86_64_P_0_W_0): Likewise.
(MOD_VEX_0F3849_X86_64_P_2_W_0): Likewise.
(MOD_VEX_0F3849_X86_64_P_3_W_0): Likewise.
(MOD_VEX_0F384B_X86_64_P_1_W_0): Likewise.
(MOD_VEX_0F384B_X86_64_P_2_W_0): Likewise.
(MOD_VEX_0F384B_X86_64_P_3_W_0): Likewise.
(MOD_VEX_0F385C_X86_64_P_1_W_0): Likewise.
(MOD_VEX_0F385E_X86_64_P_0_W_0): Likewise.
(MOD_VEX_0F385E_X86_64_P_1_W_0): Likewise.
(MOD_VEX_0F385E_X86_64_P_2_W_0): Likewise.
(MOD_VEX_0F385E_X86_64_P_3_W_0): Likewise.
(RM_VEX_0F3849_X86_64_P_0_W_0_M_1_R_0): Likewise.
(PREFIX_VEX_0F3849_X86_64): Likewise.
(PREFIX_VEX_0F384B_X86_64): Likewise.
(PREFIX_VEX_0F385C_X86_64): Likewise.
(PREFIX_VEX_0F385E_X86_64): Likewise.
(X86_64_VEX_0F3849): Likewise.
(X86_64_VEX_0F384B): Likewise.
(X86_64_VEX_0F385C): Likewise.
(X86_64_VEX_0F385E): Likewise.
(VEX_LEN_0F3849_X86_64_P_0_W_0_M_0): Likewise.
(VEX_LEN_0F3849_X86_64_P_0_W_0_M_1_REG_0_RM_0): Likewise.
(VEX_LEN_0F3849_X86_64_P_2_W_0_M_0): Likewise.
(VEX_LEN_0F3849_X86_64_P_3_W_0_M_0): Likewise.
(VEX_LEN_0F384B_X86_64_P_1_W_0_M_0): Likewise.
(VEX_LEN_0F384B_X86_64_P_2_W_0_M_0): Likewise.
(VEX_LEN_0F384B_X86_64_P_3_W_0_M_0): Likewise.
(VEX_LEN_0F385C_X86_64_P_1_W_0_M_0): Likewise.
(VEX_LEN_0F385E_X86_64_P_0_W_0_M_0): Likewise.
(VEX_LEN_0F385E_X86_64_P_1_W_0_M_0): Likewise.
(VEX_LEN_0F385E_X86_64_P_2_W_0_M_0): Likewise.
(VEX_LEN_0F385E_X86_64_P_3_W_0_M_0): Likewise.
(VEX_W_0F3849_X86_64_P_0): Likewise.
(VEX_W_0F3849_X86_64_P_2): Likewise.
(VEX_W_0F3849_X86_64_P_3): Likewise.
(VEX_W_0F384B_X86_64_P_1): Likewise.
(VEX_W_0F384B_X86_64_P_2): Likewise.
(VEX_W_0F384B_X86_64_P_3): Likewise.
(VEX_W_0F385C_X86_64_P_1): Likewise.
(VEX_W_0F385E_X86_64_P_0): Likewise.
(VEX_W_0F385E_X86_64_P_1): Likewise.
(VEX_W_0F385E_X86_64_P_2): Likewise.
(VEX_W_0F385E_X86_64_P_3): Likewise.
(names_tmm): Likewise.
(att_names_tmm): Likewise.
(intel_operand_size): Handle void_mode.
(OP_XMM): Handle tmm_mode.
(OP_EX): Likewise.
(OP_VEX): Likewise.
* i386-gen.c (cpu_flag_init): Add entries for CpuAMX_INT8,
CpuAMX_BF16 and CpuAMX_TILE.
(operand_type_shorthands): Add RegTMM.
(operand_type_init): Likewise.
(operand_types): Add Tmmword.
(cpu_flag_init): Add CPU_AMX_INT8, CpuAMX_BF16 and CpuAMX_TILE.
(cpu_flags): Add CpuAMX_INT8, CpuAMX_BF16 and CpuAMX_TILE.
* i386-opc.h (CpuAMX_INT8): New.
(CpuAMX_BF16): Likewise.
(CpuAMX_TILE): Likewise.
(SIBMEM): Likewise.
(Tmmword): Likewise.
(i386_cpu_flags): Add cpuamx_int8, cpuamx_bf16 and cpuamx_tile.
(i386_opcode_modifier): Extend width of fields vexvvvv and sib.
(i386_operand_type): Add tmmword.
* i386-opc.tbl: Add AMX instructions.
* i386-reg.tbl: Add AMX registers.
* i386-init.h: Regenerated.
* i386-tbl.h: Likewise.

[readelf] Fix end_seq entry in -wL.  Specifically stop the display of a line number and is_statement/has-view fields for the End of Sequence operator, as these have no meaning.

binutils* dwarf.c (display_debug_lines_decoded): Don't emit meaningless
information in the end_sequence row.
* testsuite/binutils-all/dw5.W: Update.
* testsuite/binutils-all/objdump.WL: Update.

gas * testsuite/gas/elf/dwarf2-11.d: Update expected output from
readelf's line table decoding.
* testsuite/gas/elf/dwarf2-12.d: Likewise.
* testsuite/gas/elf/dwarf2-13.d: Likewise.
* testsuite/gas/elf/dwarf2-14.d: Likewise.
* testsuite/gas/elf/dwarf2-15.d: Likewise.
* testsuite/gas/elf/dwarf2-16.d: Likewise.
* testsuite/gas/elf/dwarf2-17.d: Likewise.
* testsuite/gas/elf/dwarf2-18.d: Likewise.
* testsuite/gas/elf/dwarf2-19.d: Likewise.
* testsuite/gas/elf/dwarf2-5.d: Likewise.
* testsuite/gas/elf/dwarf2-6.d: Likewise.
* testsuite/gas/elf/dwarf2-7.d: Likewise.

Document powerpc64 ld options

* ld.texi (PowerPC64 ELF64): Document --no-inline-optimize,
--power10-stubs and --no-power10-stubs.

PowerPC64 ld --no-power10-stubs

Needed for libraries that use ifuncs or other means to support
cpu-optimized versions of functions, some power10, some not, and those
functions make calls using linkage stubs.

bfd/
* elf64-ppc.h (struct ppc64_elf_params): Add power10_stubs.
* elf64-ppc.c (struct ppc_link_hash_table): Delete
power10_stubs.
(ppc64_elf_check_relocs): Adjust setting of power10_stubs.
(plt_stub_size, ppc_build_one_stub, ppc_size_one_stub): Adjust
uses of power10_stubs.
ld/
* emultempl/ppc64elf.em (params): Init new field.
(enum ppc64_opt): Add OPTION_POWER10_STUBS and OPTION_NO_POWER10_STUBS.
(PARSE_AND_LIST_LONGOPTS): Support --power10-stubs and
--no-power10-stubs.
(PARSE_AND_LIST_OPTIONS, PARSE_AND_LIST_ARGS_CASES): Likewise.
* testsuite/ld-powerpc/callstub-3.d: New test.
* testsuite/ld-powerpc/powerpc.exp: Run it.

Automatic date update in version.in

Don't compare the pid returned from 'wait' against inferior_ptid.

'inf_ptrace::wait' needs to discard termination events reported by
detached child processes.  Previously it compared the returned pid
against the pid in inferior_ptid to determine if a termination event
should be discarded or reported.  The multi-target changes cleared
inferior_ptid to null_ptid in 'wait' target methods, so this was
always failing and never reporting exit events.  Instead, report
termination events whose pid matches any inferior belonging to the
current target.

Several tests started failing on FreeBSD after the multi-target
changes and pass again after this change.

gdb/ChangeLog:

* inf-ptrace.c (inf_ptrace_target::wait): Don't compare against
inferior_ptid.

x86: Properly set YMM/ZMM features

Since VEX/EVEX vector instructions will always update the full YMM/ZMM
registers, set YMM/ZMM features for VEX/EVEX vector instructions.

* config/tc-i386.c (output_insn): Set YMM/ZMM features for
VEX/EVEX vector instructions.
* testsuite/gas/i386/property-4.d: New file.
* testsuite/gas/i386/property-4.s: Likewise.
* testsuite/gas/i386/property-5.d: Likewise.
* testsuite/gas/i386/property-5.s: Likewise.
* testsuite/gas/i386/x86-64-property-4.d: Likewise.
* testsuite/gas/i386/x86-64-property-5.d: Likewise.

Support several new ELF auxiliary vector types on FreeBSD.

FreeBSD's kernel recently added several ELF auxiliary vector entries
to describe the arguments passed to new executable images during
exec().  The AT_FREEBSD_ARGC and AT_FREEBSD_ARGV entries give the
length and address of the process argument array.  AT_FREEBSD_ENVC and
AT_FREEBSD_ENVV entries give the length and address of the initial
process environment.  AT_FREEBSD_PS_STRINGS gives the address of the
'struct ps_strings' object.

include/ChangeLog:

* elf/common.h (AT_FREEBSD_ARGC, AT_FREEBSD_ARGV, AT_FREEBSD_ENVC)
(AT_FREEBSD_ENVV, AT_FREEBSD_PS_STRINGS): Define.

gdb/ChangeLog:

* fbsd-tdep.c (fbsd_print_auxv_entry): Handle AT_FREEBSD_ARGC,
AT_FREEBSD_ARGV, AT_FREEBSD_ENVC, AT_FREEBSD_ENVV,
AT_FREEBSD_PS_STRINGS.

Linux/x86: Configure gas with --enable-x86-used-note by default

* configure.ac: Configure with --enable-x86-used-note by default
for Linux/x86.
* configure: Regenerated.

Remove powerpc PE support

Plus some leftover powerpc lynxos support.

bfd/
* coff-ppc.c: Delete.
* pe-ppc.c: Delete.
* pei-ppc.c: Delete.
* Makefile.am (BFD32_BACKENDS, BFD32_BACKENDS_CFILES): Remove PE PPC.
* coffcode.h (coff_set_arch_mach_hook, coff_set_flags): Remove
PPCMAGIC code.
(coff_write_object_contents): Remove PPC_PE code.
* config.bfd: Move powerpcle-pe to removed targets.
* configure.ac: Remove powerpc PE entries.
* libcoff-in.h (ppc_allocate_toc_section): Delete.
(ppc_process_before_allocation): Delete.
* peXXigen.c: Remove POWERPC_LE_PE code and comments.
* targets.c: Remove powerpc PE vectors.
* po/SRC-POTFILES.in: Regenerate.
* libcoff.h: Regenerate.
* Makefile.in: Regenerate.
* configure: Regenerate.
binutils/
* dlltool.c: Remove powerpc PE support and comments.
* configure.ac: Remove powerpc PE dlltool config.
* configure: Regenerate.
gas/
* config/obj-coff.h: Remove TE_PE support.
* config/tc-ppc.c: Likewise.
* config/tc-ppc.h: Likewise.
* configure.tgt: Remove powerpc PE and powerpc lynxos.
* testsuite/gas/cfi/cfi.exp (cfi-common-6): Remove powerpc PE
condition.
* testsuite/gas/macros/macros.exp: Don't xfail powerpc PE.
include/
* coff/powerpc.h: Delete.
ld/
* emulparams/ppcpe.sh: Delete.
* scripttempl/ppcpe.sc: Delete.
* emulparams/ppclynx.sh: Delete.
* Makefile.am (ALL_EMULATION_SOURCES): Remove ppc PE and lynxos.
* configure.tgt: Likewise.
* emultempl/beos.em: Remove powerpc PE support.
* emultempl/pe.em: Likewise.
* po/BLD-POTFILES.in: Regenerate.
* Makefile.in: Regenerate.

powerpc garbage collect test

ld's garbage collection test on powerpc64 catered for old compilers
(pre -mcmodel=medium support), setting options that caused the test to
fail.  Which meant the test wasn't really testing anything.  Get rid
of that old compiler support, and avoid -fPIE fails on ppc32.

* testsuite/ld-gc/gc.exp: Don't set -mminimal-toc for powerpc64,
and remove powerpc64 xfail.  Use -fno-PIE for ppc32.

pr18841 tests on powerpc64

The PR18841 test does cross-module calls from within an ifunc
resolver, which is nasty, and not supported in general since the
called function may not be relocated.  In this case the called
function (zoo) is just a stub so doesn't need relocating, but on ppc64
the function descriptor for zoo in the executable won't be relocated
at the time the shared library ifunc resolver runs.  That means the
test will fail if your compiler generates PIEs by default.

PR 18841
* testsuite/ld-ifunc/ifunc.exp: Run pr18841 tests non-pie.

Update Turkish translation in the gprof sub-directory

Update French translation in the bfd sub-directory

Update the Windows Resource compiler (windres) to support the OWNERDRAW and BITMAP menuitem flags.

binutils* rclex.c: Add OWNERDRAW keyword.
* rcparse.y: Add OWNERDRAW token.
(menuitem_flag) Add BITMAP and OWNERDRAW entries.
* resrc.c (write_rc_menuitems): Add support for OWNERDRAW and
BITMAP flags.
* windres.c (extended_menuitems): Likewise.
* testsuite/binutils-all/windres/menuitem_flags.rc: New test.

asan: readelf: heap buffer overflow in slurp_hppa_unwind_table

This one isn't just a weird corner case requiring multiple
.PARISC.unwind sections in an object file to trigger the buffer
overflow, it's also a simple bug that would prevent relocations being
applied in the normal case of a single .PARISC.unwind section.

* readelf (slurp_hppa_unwind_table): Set table_len before use
in relocation sanity checks.

Automatic date update in version.in

Handle Windows drives in auto-load script paths

Fixes this testsuite fail on Windows:
FAIL: gdb.base/auto-load.exp: print $script_loaded

Converts the debugfile path from c:/dir/file to /c/dir/file, so it can be
appended to the auto-load path.

gdb/ChangeLog:

2020-07-08  Hannes Domani  <ssbssa@yahoo.de>

* auto-load.c (auto_load_objfile_script_1): Convert drive part
of debugfile path on Windows.

gdb/doc/ChangeLog:

2020-07-08  Hannes Domani  <ssbssa@yahoo.de>

* gdb.texinfo: Document Windows drive conversion of
'set auto-load scripts-directory'.

Rename the 'obfd' argument to fbsd_nat_target::find_memory_regions.

The argument is passed as a generic cookie value to the supplied
callback and is not necessarily a pointer to a bfd.

gdb/ChangeLog:

* fbsd-nat.c (fbsd_nat_target::find_memory_regions): Rename 'obfd'
argument to 'data'.

Use read_memory in ada_exception_message_1

Testing using the internal AdaCore test suite showed a regression from
the target string reading changes.  In particular, now
ada_exception_message_1 can get the wrong answer in some cases.  In
particular, when an Ada exception catchpoint is hit, sometimes the
exception name will be incorrect.  The case I was seeing changed from
the correct:

    Catchpoint 2, CONSTRAINT_ERROR (catch C_E) at [...]

to:

    Catchpoint 2, CONSTRAINT_ERROR (catch C_EE) at [...]

I was not able to reproduce this failure with the Fedora gnat.
Perhaps it is related to some local change to gnat; I do not know.

Meanwhile, because ada_exception_message_1 knows the length of the
string to read, we can use read_memory here.  This fixes the bug.

I've updated the test suite to at least exercise this code path.
However, as mentioned above, the new test does not actually provoke
the failure.

gdb/ChangeLog
2020-07-08  Tom Tromey  <tromey@adacore.com>

* ada-lang.c (ada_exception_message_1): Use read_memory.

gdb/testsuite/ChangeLog
2020-07-08  Tom Tromey  <tromey@adacore.com>

* gdb.ada/catch_ex/foo.adb: Pass string to raise.
* gdb.ada/catch_ex.exp: Examine catchpoint text.