gdb/python: Reuse gdb.RegisterDescriptor objects where possible

Instead of having the gdb.RegisterDescriptorIterator creating new
gdb.RegisterDescriptor objects for each regnum, instead cache
gdb.RegisterDescriptor objects on the gdbarch object and reuse these.

This means that for every gdbarch/regnum pair there is a single unique
gdb.RegisterDescriptor, this feels like a neater implementation than
the existing one.

It is possible for a user to see (in Python code) that the descriptors
are now identical, but as the descriptors are read-only this should
make no real difference.

There should be no other user visible changes.

gdb/ChangeLog:

* python/py-registers.c (gdbpy_register_object_data): New static
global.
(gdbpy_register_object_data_init): New function.
(gdbpy_new_register_descriptor): Renamed to...
(gdbpy_get_register_descriptor): ...this, and update to reuse
existing register descriptors where possible.
(gdbpy_register_descriptor_iter_next): Update.
(gdbpy_initialize_registers): Register new gdbarch data.

gdb/testsuite/ChangeLog:

* gdb.python/py-arch-reg-names.exp: Additional tests.

gdb, gdbserver: make stopped_pids global variables static

I noticed that my IDE was confusing the two stopped_pids variables.
There is one in GDB and one in GDBserver.  They should be static, make
them so.

gdb/ChangeLog:

* linux-nat.c (stopped_pids): Make static.

gdbserver/ChangeLog:

* linux-low.cc (stopped_pids): Make static.

Change-Id: If4a2bdcd45d32eb3a732d266a0f686a4e4c23672

gdb: handle undefined properties in ada_discrete_type_{low,high}_bound

This patch fixes a failure in test `gdb.ada/access_to_packed_array.exp`.
The failure was introduced by 8c2e4e0689ea24 ("gdb: add accessors to
struct dynamic_prop"), but I think it in fact exposed a latent buglet.

Note that to reproduce it, I had to use AdaCore's Ada "distribution"
[1].  The one that comes with my distro doesn't have debug info for the
standard library stuff, so the bug wouldn't trigger.

The bug is that while executing the `maint print symbols` command, we
are accessing the value of a range type's high bound dynamic prop as a
"const" value (PROP_CONST), when it is actually undefined
(PROP_UNDEFINED).  It results in this failed assertion:

    /home/simark/src/binutils-gdb/gdb/gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.

`ada_discrete_type_high_bound` calls `resolve_dynamic_type`, which
eventually calls `resolve_dynamic_range`.  This one is responsible for
evaluating a range type's dynamic bounds in the current context and
returning static values.  It returns a new range type with these static
bounds.

The resulting bounds are typically properties of the PROP_CONST kind.
But when it's not possible to evaluate the properties, the properties
are PROP_UNDEFINED.  In the case we are looking at, it's not possible to
evaluate the dynamic high bound, which is of type PROP_LOCLIST.  It
would require a target with registers and a frame, but we run `maint
print symbols` without a live process.

`ada_discrete_type_high_bound` then accesses the high bound
unconditionally as a const value, which triggers the assert.

Note that the previous code in resolve_dynamic_range (before commit
8c2e4e0689ea24) did this:

    prop = &TYPE_RANGE_DATA (dyn_range_type)->high;
    if (dwarf2_evaluate_property (prop, NULL, addr_stack, &value))
      {
        high_bound.kind = PROP_CONST;
        high_bound.data.const_val = value;

        if (TYPE_RANGE_DATA (dyn_range_type)->flag_upper_bound_is_count)
   high_bound.data.const_val
     = low_bound.data.const_val + high_bound.data.const_val - 1;
      }
    else
      {
        high_bound.kind = PROP_UNDEFINED;
        high_bound.data.const_val = 0;
      }

That did not really made sense, setting the kind to `PROP_UNDEFINED` but
also setting the `const_val` field.  The `const_val` field is only
meaningful if the kind if `PROP_CONST`.  The new code
(post-8c2e4e0689ea24) simply calls `set_undefined ()`.

Fix this by making the caller, `ada_discrete_type_high_bound`, consider
that a range high bound could be of kind `PROP_UNDEFINED`, and return
0 in this case.  I made the same change in ada_discrete_type_low_bound.
I didn't encounter a problem with this function, but the same could in
theory happen there.

Returning 0 here is kind of a lie, but the goal here is just to restore
the behavior of pre-8c2e4e0689ea24.

The output of `maint print symbols` is:

     typedef <ada__exceptions__exception_data__append_info_basic_exception_information__TTnameSP1: range 1 .. 0;
     record
         ada__exceptions__exception_data__append_info_basic_exception_information__TTnameSP1: range 1 .. 0;
     end record;

Instead of `1 .. 0`, which does not make sense, we could say something
like `1 .. <dynamic>`.  But that would require more changes than I'm
willing to do at the moment.

[1] https://www.adacore.com/download

gdb/ChangeLog:

PR ada/26235
* gdbtypes.c (ada_discrete_type_low_bound,
ada_discrete_type_high_bound): Handle undefined bounds.

Change-Id: Ia12167e61ef030941c0790f83294f3418e6a7c12

[gdb/testsuite] Fix gdb.reverse/solib-{precsave,reverse}.exp with gcc-8

With gcc-8, we have the following FAILs, which are not there for gcc-7:
...
FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function one
FAIL: gdb.reverse/solib-precsave.exp: reverse-step within solib function one
FAIL: gdb.reverse/solib-precsave.exp: reverse-step back to main one
FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function two
FAIL: gdb.reverse/solib-precsave.exp: reverse-step within solib function two
FAIL: gdb.reverse/solib-precsave.exp: reverse-step back to main two
FAIL: gdb.reverse/solib-precsave.exp: run until end part two
FAIL: gdb.reverse/solib-precsave.exp: reverse-next over solib function one
FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function one
FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function one
FAIL: gdb.reverse/solib-reverse.exp: reverse-step back to main one
FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function two
FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function two
FAIL: gdb.reverse/solib-reverse.exp: reverse-step back to main two
FAIL: gdb.reverse/solib-reverse.exp: run until end part two
FAIL: gdb.reverse/solib-reverse.exp: reverse-next over solib function one
...

Looking at the first FAIL for gdb.reverse/solib-precsave.exp, we have:
...
 (gdb) PASS: reverse-next first shr1
 reverse-next^M
 40        b[0] = 6;   b[1] = 9;     /* generic statement, end part two */^M
 (gdb) PASS: reverse-next generic
 reverse-step^M
-shr2 (x=17) at gdb.reverse/shr2.c:23^M
-23      }^M
-(gdb) PASS: reverse-step into solib function one
+38        b[1] = shr2(17);              /* middle part two */^M
+(gdb) FAIL: reverse-step into solib function one
...

There's a difference in line number info for line 38, where for gcc-7 we have:
...
Line number    Starting address    View    Stmt
         38            0x4005c6               x
...
and for gcc-8:
...
         38            0x4005c1               x
         38            0x4005cb               x
...
which explains why we don't step directly into "solib function one".

Fix this by recognizing the extra "recommended breakpoint location" and
issuing an additional reverse-next/step.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.reverse/solib-precsave.exp: Handle additional "recommended
breakpoint locations".
* gdb.reverse/solib-reverse.exp: Same.

[gdb/testsuite] Fix step-reverse.c with gcc-10

The file gdb.reverse/step-reverse.c is used in test-cases:
- gdb.reverse/step-reverse.exp
- gdb.reverse/next-reverse-bkpt-over-sr.exp
- gdb.reverse/step-precsave.exp

With gcc-7, there are only PASSes (apart from one KFAIL), but with gcc-10, we
have the following FAILs:
...
FAIL: gdb.reverse/step-reverse.exp: reverse stepi from a function call \
  (start statement)
FAIL: gdb.reverse/step-reverse.exp: simple reverse stepi
FAIL: gdb.reverse/step-reverse.exp: reverse step out of called fn
FAIL: gdb.reverse/step-reverse.exp: reverse next over call
FAIL: gdb.reverse/step-reverse.exp: reverse step test 1
FAIL: gdb.reverse/step-reverse.exp: reverse next test 1
FAIL: gdb.reverse/step-reverse.exp: reverse step test 2
FAIL: gdb.reverse/step-reverse.exp: reverse next test 2
FAIL: gdb.reverse/step-precsave.exp: reverse stepi from a function call \
  (start statement)
FAIL: gdb.reverse/step-precsave.exp: simple reverse stepi
FAIL: gdb.reverse/step-precsave.exp: reverse step out of called fn
FAIL: gdb.reverse/step-precsave.exp: reverse next over call
FAIL: gdb.reverse/step-precsave.exp: reverse step test 1
FAIL: gdb.reverse/step-precsave.exp: reverse next test 1
FAIL: gdb.reverse/step-precsave.exp: reverse step test 2
FAIL: gdb.reverse/step-precsave.exp: reverse next test 2
...

Looking at the first step-precsave.exp FAIL, we have:
...
(gdb) stepi^M
26        myglob++; return 0;   /* ARRIVED IN CALLEE */^M
(gdb) PASS: gdb.reverse/step-precsave.exp: reverse stepi thru function return
stepi^M
0x000000000040055f      26        myglob++; return 0;   /* ARRIVED IN CALLEE */^M
(gdb) FAIL: gdb.reverse/step-precsave.exp: reverse stepi from a function call \
  (start statement)
...

There's a difference in line info for callee:
...
    25  int callee() {          /* ENTER CALLEE */
    26    myglob++; return 0;   /* ARRIVED IN CALLEE */
    27  }                       /* RETURN FROM CALLEE */
...
between gcc-7:
...
Line number    Starting address    View    Stmt
         25            0x400557               x
         26            0x40055b               x
         27            0x40056f               x
...
and gcc-10:
...
         25            0x400552               x
         26            0x400556               x
         26            0x400565               x
         27            0x40056a               x
...

The two "recommend breakpoint location" entries at line 26 are for the two
statements ("myglob++" and "return 0"), but the test-case expects to hit line
26 only once.

Fix this by rewriting the two statements into a single statement:
...
-  myglob++; return 0;  /* ARRIVED IN CALLEE */
+  return myglob++;     /* ARRIVED IN CALLEE */
...

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.reverse/step-reverse.c (callee): Merge statements.

Enable multi-process mode in the NetBSD native target.

This enables proper support for multiple inferiors and ptrace(2)
assisted management of the inferior processes and their threads.

(gdb) info inferior
  Num  Description       Connection           Executable
* 1    process 14952     1 (native)           /usr/bin/dig
  2    <null>            1 (native)
  3    process 25684     1 (native)           /bin/ls
  4    <null>            1 (native)           /bin/ls

Without this patch, additional inferiors can be added, but not
properly controlled.

gdb/ChangeLog:

        * nbsd-nat.h (nbsd_nat_target::supports_multi_process): New
        declaration.
        * nbsd-nat.c (nbsd_nat_target::supports_multi_process): New
        function.

Revert "x86: Don't display eiz with no scale"

This reverts commit 04c662e2b66bedd050f97adec19afe0fcfce9ea7.
In my underlying suggestion I neglected the fact that in those
cases (,%eiz,1) is the only visible indication that 32-bit
addressing is in effect.

Fix Unreasonable arch and cpu conflict warning for ther CSky architecture.

* config/tc-csky.c (md_begin): Fix tests of arch and mach flags.

Updated Swedish translation for the binutils sub-directory

[gdb/testsuite] Fix gdb.fortran/info-modules.exp with gcc-8

When using test-case gdb.fortran/info-modules.exp with gcc 8.4.0, I run into:
...
FAIL: gdb.fortran/info-modules.exp: info module variables: check for entry \
  'info-types.f90', '35', 'Type m1t1 mod1::__def_init_mod1_M1t1;'
FAIL: gdb.fortran/info-modules.exp: info module variables: check for entry \
  'info-types.f90', '35', 'Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;'
...

This is caused by this change in gdb output:
...
 (gdb) info module variables
    ...
 File gdb.fortran/info-types.f90:
-35:     Type m1t1 mod1::__def_init_mod1_M1t1;
+        Type m1t1 mod1::__def_init_mod1_M1t1;
-35:     Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;
+        Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;
 21:     real(kind=4) mod1::mod1_var_1;
 22:     integer(kind=4) mod1::mod1_var_2;
...
caused by a change in debug info.

Fix this by allowing those entries without line number.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.fortran/info-modules.exp (info module variables): Allow missing
line numbers for some variables.

Revert "x86: Replace evex-no-scale.s with evex-no-scale-[32|64].s"

This reverts commit 19449d7c67690c641b1ec9c13ff3531677a5afcc, addressing
the issue that was run into back then: There was no relationship to i686-*
and/or cross builds on 64-bit hosts. The sole problem was the use of / as
as comment character in certain ELF targets. Instead of division, use a
comparison operation.

At the same time also revert the ELF related part of 99c2d522f7a7 ("x86:
Update assembler tests for non-ELF targets") by replacing the construct
that's problematic for non-ELF, and by adding the "#pass" patterns to
the expected output files to cover for the tail padding generated into
COFF output.

[gdb/testsuite] Make inline-locals.c deterministic

When running testcase gdb.opt/inline-locals.exp on openSUSE Tumbleweed, I get:
...
(gdb) info locals^M
array = {0 <repeats 48 times>, 15775231, 0, 194, 0, -11497, 32767, 4199061, \
  0, 0, 0, 0, 0, 4198992, 0, 4198432, 0}^M
(gdb) FAIL: gdb.opt/inline-locals.exp: info locals above bar 2
...

Fix this by:
- completely initializing array before printing any value
- updating the pattern to match "array = {0 <repeats 64 times>}"

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.opt/inline-locals.c (init_array): New func.
(func1): Use init_array.
* gdb.opt/inline-locals.exp: Update pattern.

[gdb/testsuite] Don't leak env vars in gdb.debuginfod/fetch_src_and_symbols.exp

Test-case gdb.debuginfod/fetch_src_and_symbols.exp leaks env vars
DEBUGINFOD_URLS, DEBUGINFOD_TIMEOUT and DEBUGINFOD_CACHE_PATH, causing
timeouts in subsequent tests.

Fix this by using save_vars.  Also, fix PATH and DUPLICATE errors.  Finally,
cleanup whitespace.

gdb/testsuite/ChangeLog:

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

* gdb.debuginfod/fetch_src_and_symbols.exp: Use save_vars for env
vars.  Fix PATH and DUPLICATE errors.  Cleanup whitespace.

MIPS/GAS: Remove stale `prev_reloc_op_frag' variable

Ever since commit 4d7206a284ee ("Rework MIPS macro relaxation, fix string
merging bug"), <https://sourceware.org/ml/binutils/2004-01/msg00248.html>,
`prev_reloc_op_frag' has only been set and never used.  Remove it then.

gas/
* config/tc-mips.c (prev_reloc_op_frag): Remove variable.
(my_getSmallExpression): Adjust accordingly.

Automatic date update in version.in

Implement the skip_solib_resolver gdbarch hook for FreeBSD architectures.

The ELF runtime linker on all FreeBSD architectures uses the
"_rtld_bind" entry point for unresolved PTL entries.  FreeBSD/mips has
an additional entry point called "_mips_rtld_bind".

gdb/ChangeLog:

* fbsd-tdep.c (fbsd_skip_solib_resolver): New function.
(fbsd_init_abi): Install gdbarch "skip_solib_resolver" method.
* fbsd-tdep.h (fbsd_skip_solib_resolver): New prototype.
* mips-fbsd-tdep.c (mips_fbsd_skip_solib_resolver): New function.
(mips_fbsd_init_abi): Install gdbarch "skip_solib_resolver"
method.

guile: Add support for Guile 3.0.

gdb/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>

* guile/scm-math.c (vlscm_integer_fits_p): Use 'uintmax_t'
and 'intmax_t' instead of 'scm_t_uintmax' and 'scm_t_intmax',
which are deprecated in Guile 3.0.
* configure.ac (try_guile_versions): Add "guile-3.0".
* configure (try_guile_versions): Regenerate.
* NEWS: Update entry.

gdb/testsuite/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>

* gdb.guile/source2.scm: Add #f first argument to 'format'.
* gdb.guile/types-module.exp: Remove "ERROR:" from
regexps since Guile 3.0 no longer prints that.

gdb/doc/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>

* doc/guile.texi (Guile Introduction): Mention Guile 3.0.

Change-Id: Iff116c2e40f334e4e0ca4e759a097bfd23634679

guile: Add support for Guile 2.2.

This primarily updates code that uses the I/O port API of Guile.

gdb/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>
            Doug Evans  <dje@google.com>

PR gdb/21104
* guile/scm-ports.c (USING_GUILE_BEFORE_2_2): New macro.
(ioscm_memory_port)[read_buf_size, write_buf_size]: Wrap in #if
USING_GUILE_BEFORE_2_2.
(stdio_port_desc, memory_port_desc) [!USING_GUILE_BEFORE_2_2]:
Change type to 'scm_t_port_type *'.
(natural_buffer_size) [!USING_GUILE_BEFORE_2_2]: New variable.
(ioscm_open_port) [USING_GUILE_BEFORE_2_2]: Add 'stream'
parameter and honor it.  Update callers.
(ioscm_open_port) [!USING_GUILE_BEFORE_2_2]: New function.
(ioscm_read_from_port, ioscm_write) [!USING_GUILE_BEFORE_2_2]: New
functions.
(ioscm_fill_input, ioscm_input_waiting, ioscm_flush): Wrap in #if
USING_GUILE_BEFORE_2_2.
(ioscm_init_gdb_stdio_port) [!USING_GUILE_BEFORE_2_2]: Use
'ioscm_read_from_port'.  Call 'scm_set_port_read_wait_fd'.
(ioscm_init_stdio_buffers) [!USING_GUILE_BEFORE_2_2]: New function.
(gdbscm_stdio_port_p) [!USING_GUILE_BEFORE_2_2]: Use 'SCM_PORTP'
and 'SCM_PORT_TYPE'.
(gdbscm_memory_port_end_input, gdbscm_memory_port_seek)
(ioscm_reinit_memory_port): Wrap in #if USING_GUILE_BEFORE_2_2.
(gdbscm_memory_port_read, gdbscm_memory_port_write)
(gdbscm_memory_port_seek, gdbscm_memory_port_close)
[!USING_GUILE_BEFORE_2_2]: New functions.
(gdbscm_memory_port_print): Remove use of 'SCM_PTOB_NAME'.
(ioscm_init_memory_port_type) [!USING_GUILE_BEFORE_2_2]: Use
'gdbscm_memory_port_read'.
Wrap 'scm_set_port_end_input', 'scm_set_port_flush', and
'scm_set_port_free' calls in #if USING_GUILE_BEFORE_2_2.
(gdbscm_get_natural_buffer_sizes) [!USING_GUILE_BEFORE_2_2]: New
function.
(ioscm_init_memory_port): Remove.
(ioscm_init_memory_port_stream): New function
(ioscm_init_memory_port_buffers) [USING_GUILE_BEFORE_2_2]: New
function.
(gdbscm_memory_port_read_buffer_size) [!USING_GUILE_BEFORE_2_2]:
Return scm_from_uint (0).
(gdbscm_set_memory_port_read_buffer_size_x)
[!USING_GUILE_BEFORE_2_2]: Call 'scm_setvbuf'.
(gdbscm_memory_port_write_buffer_size) [!USING_GUILE_BEFORE_2_2]:
Return scm_from_uint (0).
(gdbscm_set_memory_port_write_buffer_size_x)
[!USING_GUILE_BEFORE_2_2]: Call 'scm_setvbuf'.
* configure.ac (try_guile_versions): Add "guile-2.2".
* configure: Regenerate.
* NEWS: Add entry.

gdb/testsuite/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>

* gdb.guile/scm-error.exp ("source $remote_guile_file_1"): Relax
error regexp to match on Guile 2.2.

gdb/doc/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>

* guile.texi (Memory Ports in Guile): Mark
'memory-port-read-buffer-size',
'set-memory-port-read-buffer-size!',
'memory-port-write-buffer-size',
'set-memory-port-read-buffer-size!' as deprecated.
* doc/guile.texi (Guile Introduction): Clarify which Guile
versions are supported.

Change-Id: Ib119b10a2787446e0ae482a5e1b36d809c44bb31

Skip tests requiring "alignof (void)" when compiling using clang

As an extension, GCC allows void pointer arithmetic, with sizeof(void)
and alignof(void) both 1.  GDB supports this extension, but clang does
not, and fails to compile the generated output of gdb.cp/align.exp
with the following error:

 gdb compile failed, /gdbtest/build/gdb/testsuite/outputs/gdb.cp/align/align.cc:28:23:
       error: invalid application of 'alignof' to an incomplete type 'void'
    unsigned a_void = alignof (void);
                      ^       ~~~~~~
 1 error generated.

This commit adds preprocessor conditionals to the generated output, to
omit the unsupported code when using clang, and supplies the expected
value so the test can complete.

gdb/testsuite/ChangeLog:

* gdb.cp/align.exp: Fix "alignof (void)" tests when compiling
with clang.

Fix problem running a few PowerPC linker tests when the .data section is retained.

* testsuite/ld-powerpc/powerpc.exp (ppcelftests): Use section name
.PPC.EMB.apuinfo instead of section number 2 in apuinfo tests.

PR26265, Spurious 'gc-sections requires ... when --init or --fini

bfd/
* elflink.c (_bfd_elf_gc_keep): Use bfd_is_const_section.
ld/
PR 26265
* ldlang.c (undef_from_cmdline): Delete.
(ldlang_add_undef): Mark "cmdline" param unused.
(lang_end): Traverse gc_sym_list to determine whether a symbol root
has been specified.  Update error message.
* testsuite/ld-gc/noent.d: Adjust for changed error message.

[gdb/testsuite] Stabilize execution order in omp-par-scope.c

In openmp test-case gdb.threads/omp-par-scope.exp we xfail and kfail dependent
on omp_get_thread_num ().  Since execution order of the threads can vary from
execution to execution, this can cause changes in test results.

F.i., we can see this difference between two test runs:
...
-KFAIL: single_scope: first thread: print i3 (PRMS: gdb/22214)
+PASS: single_scope: first thread: print i3
-PASS: single_scope: second thread: print i3
+KFAIL: single_scope: second thread: print i3 (PRMS: gdb/22214)
...
In both cases, the KFAIL is for omp_get_thread_num () == 1, but in one case
that corresponds to the first thread executing that bit of code, and in the
other case to the second thread.

Get rid of this difference by stabilizing execution order.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.threads/omp-par-scope.c (lock, lock2): New variable.
(omp_set_lock_in_order): New function.
(single_scope, multi_scope, nested_func, nested_parallel): Use
omp_set_lock_in_order and omp_unset_lock.
(main): Init and destroy lock and lock2.

x86: Update PR gas/26263 linker tests

Update and run PR gas/26263 linker tests for all x86 ELF targets to
accept any program header layout.

PR gas/26263
* testsuite/ld-i386/pr26263.d: Updated.
* testsuite/ld-x86-64/pr26263.d: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Run gas/26263 test for all ELF
targets.

[gdb/testsuite] Fix valgrind-infcall-2.exp without libc debug info

When running test-case gdb.base/valgrind-infcall-2.exp on a system without
libc debug info installed, I run into:
...
(gdb) p printf ("bla")^M
'printf' has unknown return type; cast the call to its declared return type^M
(gdb) FAIL: gdb.base/valgrind-infcall-2.exp: do printf
...

Fix this by casting the result of the printf call to int.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.base/valgrind-infcall-2.exp: Handle printf unknown return type.

[gdb/testsuite] Bail out after gdb_start error in gdb.threads/attach-slow-waitpid.exp

When building gdb using CFLAGS/CXXFLAGS+=-fsanitizer=address and
LDFLAGS+=-lasan, and running test-case gdb.threads/attach-slow-waitpid.exp,
we get:
...
spawn gdb -nw -nx -data-directory data-directory^M
==16079==ASan runtime does not come first in initial library list; \
  you should either link runtime to your application or manually preload \
  it with LD_PRELOAD.^M
ERROR: (eof) GDB never initialized.
ERROR: : spawn id exp10 not open
    while executing
"expect {
-i exp10 -timeout 120
        -re "Kill the program being debugged. .y or n. $" {
            send_gdb "y\n" answer
            verbose "\t\tKilling previous pro..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $body" NONE : spawn id exp10 not open
WARNING: remote_expect statement without a default case
ERROR: : spawn id exp10 not open
    while executing
"expect {
-i exp10 -timeout 120
        -re "Reading symbols from.*LZMA support was disabled.*$gdb_prompt $" {
            verbose "\t\tLoaded $arg into $GDB; .gnu_..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $body" NONE : spawn id exp10 not open
ERROR: Couldn't load attach-slow-waitpid into GDB (eof).
ERROR: Couldn't send attach 16070 to GDB.
UNRESOLVED: gdb.threads/attach-slow-waitpid.exp: attach to target
...

Bail out at the first ERROR, such that we have instead:
...
ERROR: (eof) GDB never initialized.
UNTESTED: gdb.threads/attach-slow-waitpid.exp: \
  Couldn't start GDB with preloaded lib
...

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.threads/attach-slow-waitpid.exp: Bail out if gdb_start fails.

x86: handle SVR4 escaped binary operators

PR gas/4572

When / is a comment character, its use as binary "divide" operator needs
escaping by a backslash. Besides the scrubber needing to support this
(addressed in an earlier change), there are also a few provisions needed
in target specific operator handling.

As the spec calls for % and * to also be escaped because of being
"overloaded", also recognize these, despite the overloading there not
really preventing their use as operators in most (%) or all (*) cases,
given the way how the rest of the assembler works.

To bring source and testsuite in line, also drop the TE_I386AIX part of
the respective conditional, as i?86-*-aix* support had been removed a
while ago.

gas: generalize comment character escaping recognition

PR gas/4572

Generalize what ab1fadc6b2f0 ("PR22714, Assembler preprocessor loses
track of \@") did to always honor escaped comment chars. Use this then
to support escaped /, %, and * operators on x86, when / is a comment
char (to match the Sun assembler's behavior).

x86: honor absolute section when emitting code

Various provisions exist for insns to be placed in the absolute section,
yet actually trying to do so didn't work. While data emission (of non-
zero values) is not allowed by generic code, I think this functionality
is useful for the programmer to be able to determine the size of insns.
Therefore, rather than turning the silnet failure into a verbose one,
make things mostly work; the one class of insns not supported (yet) are
branches (JMP and Jcc) with dynamically determined displacement widths.
In this one case, an error now gets reported instead of silently
ignoring the code.

Also avoid recording ISA / feature usage for insns emitted to the
absolute section.

ix86: enable more ELF tests for VxWorks

The tree-wide is_elf_format predicate excludes VxWorks, but the majority
of ELF specific tests is quite fine for this target.

Automatic date update in version.in

gold: Update x32 test

* testsuite/split_x32.sh: Likewise.

gold: Update x86-64 tests

commit 36938cabf0efcb053d1585e8580a4b3db438ca4e
Author: Jan Beulich <jbeulich@suse.com>
Date:   Wed Jul 15 08:53:55 2020 +0200

    x86: avoid attaching suffixes to unambiguous insns

removed the 'a' suffix on call and jmp from disassembler output.  Update
gold x86-64 tests.

* testsuite/bnd_ifunc_1.sh: Updated.
* testsuite/bnd_plt_1.sh: Likewise.
* testsuite/split_x86_64.sh: Likewise.
* testsuite/x86_64_indirect_call_to_direct.sh: Likewise.

x86: Change PLT32 reloc against section to PC32

Commit 292676c1 resolved PLT32 reloc aganst local symbol to section.
Since PLT32 relocation must be against symbols, turn such PLT32
relocation into PC32 relocation.

gas/

PR gas/26263
* config/tc-i386.c (i386_validate_fix): Change PLT32 reloc
against section to PC32 reloc.
* testsuite/gas/i386/relax-5.d: Updated.
* testsuite/gas/i386/x86-64-relax-4.d: Likewise.

ld/

PR gas/26263
* testsuite/ld-i386/i386.exp: Run PR gas/26263 test.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
* testsuite/ld-i386/pr26263.d: New file.
* testsuite/ld-x86-64/pr26263.d: Likewise.
* testsuite/ld-x86-64/pr26263.s: Likewise.

ld: optionally emit _etext last, before .data

So, here's my suggestion for making _init .. __etext cover .text +
.rodata (including things like the read-only exception tables) for
elf64mmix.  A quick web search gives that __etext (and friends) isn't
well defined, so each target can interpret the "end of text segment"
to their own liking.  It seems likely this change is also a better fit
than the default for other ports, at least those with .rodata after
.text in the same segment.

The presence of a separate rodata-segment is optional (and not true
for elf64mmix).  This is reflected in the name as SEPARATE_TEXT /
SEPARATE_CODE isn't considered, to keep it simple; each target has to
make sure their settings of variables make sense.

ld:
* scripttempl/elf.sc (ETEXT_LAST_IN_RODATA_SEGMENT): New variable.
* emulparams/elf64mmix.sh (ETEXT_LAST_IN_RODATA_SEGMENT): Define.
* testsuite/ld-mmix/sec-1.d: Adjust.

Power10 stub selection

This patch better supports mixing of power10 and non-power10 code,
as might be seen in a cpu-optimized library using ifuncs to select
functions optimized for a given cpu.  Using -Wl,--no-power10-stubs
isn't that good in this situation since non-power10 notoc stubs are
slower and larger than the power10 variants, which you'd like to use
on power10 code paths.

With this change, power10 pc-relative code that makes calls marked
@notoc uses power10 stubs if stubs are necessary, and other calls use
non-power10 instructions in stubs.  This will mean that if gcc is
generating code for -mcpu=power10 but with pc-rel disabled then you'll
get the older stubs even on power10 (unless you force with
-Wl,--power10-stubs).  That shouldn't be too big a problem: stubs that
use r2 are reasonable.  It's just the ones that set up addressing
using "mflr 12; bcl 20,31,.+4; mflr 11; mtlr 12" that should be
avoided if possible.

bfd/
* elf64-ppc.c (struct ppc_link_hash_table): Add has_power10_relocs.
(select_alt_stub): New function.
(ppc_get_stub_entry): Use it here.
(ppc64_elf_check_relocs): Set had_power10_relocs rather than
power10_stubs.
(ppc64_elf_size_stubs): Clear power10_stubs here instead.  Don't
merge notoc stubs with other varieties when power10_stubs is "auto".
Instead dup the stub hash table entry.
(plt_stub_size, ppc_build_one_stub, ppc_size_one_stub): Adjust
tests of power10_stubs.
ld/
* emultempl/ppc64elf.em (power10-stubs): Accept optional "auto" arg.
* ld.texi (power10-stubs): Update.
* testsuite/ld-powerpc/callstub-1.d: Force --power10-stubs.
* testsuite/ld-powerpc/callstub-2.d: Relax branch offset comparison.
* testsuite/ld-powerpc/callstub-4.d: New test.
* testsuite/ld-powerpc/notoc.d: Force --no-power10-stubs.
* testsuite/ld-powerpc/notoc3.d,
* testsuite/ld-powerpc/notoc3.s,
* testsuite/ld-powerpc/notoc3.wf: New test.
* testsuite/ld-powerpc/powerpc.exp: Run new tests.  Pass
--no-power10-stubs for notoc link.

Automatic date update in version.in

Remove "linux_multi_process" global

The "linux_multi_process" is initialized but never modified.  I
discussed this with Pedro on irc, and he said that, while it was
useful when developing this feature, it is now no longer needed.  So,
this removes it.

gdb/ChangeLog
2020-07-18  Tom Tromey  <tom@tromey.com>

* linux-nat.c (linux_multi_process): Remove.
(linux_nat_target::supports_multi_process): Return true.

Automatic date update in version.in

gdb/riscv: delete target descriptions when gdb exits

It was pointed out on IRC that the RISC-V target allocates target
descriptions and stores them in a global map, and doesn't delete these
target descriptions when GDB shuts down.

This isn't a particular problem, the total number of target
descriptions we can create is very limited so creating these on demand
and holding them for the entire run on GDB seems reasonable.

However, not deleting these objects on GDB exit means extra warnings
are printed from tools like valgrind, and the address sanitiser,
making it harder to spot real issues.  As it's reasonably easy to have
GDB correctly delete these objects on exit, lets just do that.

I started by noticing that we already have a target_desc_up type, a
wrapper around unique_ptr that calls a function that will correctly
delete target descriptions, so I want to use that, but....

...that type is declared in gdb/target-descriptions.h.  If I try to
include that file in gdb/arch/riscv.c I run into a problem, that file
is compiled into both GDB and GDBServer.

OK, I could guard the include with #ifdef, but surely we can do
better.

So then I decided to move the target_desc_up type into
gdbsupport/tdesc.h, this is the interface file for generic code shared
between GDB and GDBserver (relating to target descriptions).  The
actual implementation for the delete function still lives in
gdb/target-description.c, but now gdb/arch/riscv.c can see the
declaration.  Problem solved....

... but, though RISC-V doesn't use it I've now exposed the
target_desc_up type to gdbserver, so in future someone _might_ start
using it, which is fine, except right now there's no definition of the
delete function - remember the delete I used is only defined in GDB
code.

No problem, I add an implementation of the delete operator into
gdbserver/tdesc.cc, and all is good..... except....

I start getting this error from GCC:

  tdesc.cc:109:10: error: deleting object of polymorphic class type ‘target_desc’ which has non-virtual destructor might cause undefined behavior [-Werror=delete-non-virtual-dtor]

Which is caused because gdbserver's target_desc type inherits from
tdesc_element which has a virtual method, and so GCC worries that
target_desc might be used as a base class.

The solution is to declare gdbserver's target_desc class as final.
This is fine so long as we never intent to inherit from
target_desc (in gdbserver).  But if we did then we'd want to make
target_desc's destructor virtual anyway, so the error above would be
resolved, and there wouldn't be an issue.

gdb/ChangeLog:

* arch/riscv.c (riscv_tdesc_cache): Change map type.
(riscv_lookup_target_description): Return pointer out of
unique_ptr.
* target-descriptions.c (allocate_target_description): Add
comment.
(target_desc_deleter::operator()): Likewise.
* target-descriptions.h (struct target_desc_deleter): Moved to
gdbsupport/tdesc.h.
(target_desc_up): Likewise.

gdbserver/ChangeLog:

* tdesc.cc (allocate_target_description): Add header comment.
(target_desc_deleter::operator()): New function.
* tdesc.h (struct target_desc): Declare as final.

gdbsupport/ChangeLog:

* tdesc.h (struct target_desc_deleter): Moved here
from gdb/target-descriptions.h, extend comment.
(target_desc_up): Likewise.

[gdb/testsuite] Add gdb.base/valgrind-infcall-2.exp

In commit ee3c5f8968 "Fix GDB crash when registers cannot be modified", we
fix a GDB crash:
...
$ valgrind /usr/bin/sleep 10000
==31595== Memcheck, a memory error detector
==31595== Command: /usr/bin/sleep 10000
==31595==
$ gdb /usr/bin/sleep
(gdb) target remote | vgdb --pid=31595
Remote debugging using | vgdb --pid=31595
  ...
$hex in __GI___nanosleep () at nanosleep.c:27
27   return SYSCALL_CANCEL (nanosleep, requested_time, remaining);
(gdb) p printf ("bla")
terminate called after throwing an instance of 'gdb_exception_error'
Aborted (core dumped)
...

This patch adds a test-case for it.

Unfortunately, I was not able to trigger the error condition using a regular
vgdb_start, so I've added a parameter active_at_startup, and when set to 0
this causes valgrind to be started without --vgdb-error=0.

Tested on x86_64-linux.

Tested with the commit mentioned above reverted, resulting in:
...
(gdb) p printf ("bla")^M
terminate called after throwing an instance of 'gdb_exception_error'^M
ERROR: GDB process no longer exists
GDB process exited with wait status 6152 exp10 0 0 CHILDKILLED SIGABRT SIGABRT
UNRESOLVED: gdb.base/valgrind-infcall-2.exp: do printf
...

gdb/testsuite/ChangeLog:

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

* gdb.base/valgrind-infcall-2.c: New test.
* gdb.base/valgrind-infcall-2.exp: New file.
* lib/valgrind.exp (vgdb_start): Add and handle active_at_startup.

Use boolean literals in linux-nat.c

I noticed a couple of spots in linux-nat.c that use 0/1 where boolean
literals would be more idiomatic.  This patch makes this change.

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

* linux-nat.c (linux_nat_target::supports_non_stop)
(linux_nat_target::always_non_stop_p): Use "true".
(linux_nat_target::supports_disable_randomization): Use "true" and
"false".

[gdb/testsuite] Use MACRO_AT_{func,range}

Use dwarf assembly procs MACRO_AT_func and MACRO_AT_range in test-cases where
that's appropriate.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.dlang/circular.c (found): Use found_label as label name.
* gdb.dwarf2/arr-subrange.c (main): Use main_label as label name.
* gdb.dwarf2/comp-unit-lang.c (func): Use func_label as label name.
* gdb.dlang/circular.exp: Use MACRO_AT_func and MACRO_AT_range.
* gdb.dwarf2/ada-linkage-name.exp: Same.
* gdb.dwarf2/arr-subrange.exp: Same.
* gdb.dwarf2/atomic-type.exp: Same.
* gdb.dwarf2/comp-unit-lang.exp: Same.
* gdb.dwarf2/cpp-linkage-name.exp: Same.
* gdb.dwarf2/dw2-bad-mips-linkage-name.exp: Same.
* gdb.dwarf2/dw2-lexical-block-bare.exp: Same.
* gdb.dwarf2/dw2-regno-invalid.exp: Same.
* gdb.dwarf2/implptr-64bit.exp: Same.
* gdb.dwarf2/imported-unit-abstract-const-value.exp: Same.
* gdb.dwarf2/imported-unit-runto-main.exp: Same.
* gdb.dwarf2/imported-unit.exp: Same.
* gdb.dwarf2/main-subprogram.exp: Same.
* gdb.dwarf2/missing-type-name.exp: Same.
* gdb.dwarf2/nonvar-access.exp: Same.
* gdb.dwarf2/struct-with-sig.exp: Same.
* gdb.dwarf2/typedef-void-finish.exp: Same.
* gdb.dwarf2/void-type.exp: Same.

[gdb/testsuite] Drop src arg of MACRO_AT_{func,range}

The dwarf assembly procs MACRO_AT_func and MACRO_AT_range have a src
parameter, which is set to $srcdir/$subdir/$srcfile in every single call.

Drop the src parameter and hardcode usage of $srcdir/$subdir/$srcfile in the
procs.

Build and reg-tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* lib/dwarf.exp (Dwarf::MACRO_AT_func, Dwarf::MACRO_AT_range): Drop
src parameter.
* gdb.dlang/watch-loc.exp: Update MACRO_AT_{func,range} calls.
* gdb.dwarf2/bitfield-parent-optimized-out.exp: Same.
* gdb.dwarf2/dw2-ifort-parameter.exp: Same.
* gdb.dwarf2/dw2-opt-structptr.exp: Same.
* gdb.dwarf2/dwz.exp: Same.
* gdb.dwarf2/implptr-optimized-out.exp: Same.
* gdb.dwarf2/implref-array.exp: Same.
* gdb.dwarf2/implref-const.exp: Same.
* gdb.dwarf2/implref-global.exp: Same.
* gdb.dwarf2/implref-struct.exp: Same.
* gdb.dwarf2/info-locals-optimized-out.exp: Same.
* gdb.dwarf2/opaque-type-lookup.exp: Same.
* gdb.dwarf2/var-access.exp: Same.
* gdb.dwarf2/varval.exp: Same.
* gdb.trace/entry-values.exp: Same.

[gdb/testsuite] Remove Dwarf::extern

The file lib/dwarf.exp contains:
...
    # Declare a global label.  This is typically used to refer to
    # labels defined in other files, for example a function defined in
    # a .c file.
    proc extern {args} {
foreach name $args {
    _op .global $name
}
    }
...

The assembler directive to refer to labels defined in other files is
not .global, but .extern, and that one is ignored by gas.

Since we require gas for all dwarf assembly test-cases, remove the proc and
all it's uses.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* lib/dwarf.exp (Dwarf::extern): Remove.
* gdb.compile/compile-ops.exp: Remove use of Dwarf::extern.
* gdb.dlang/circular.exp: Same.
* gdb.dwarf2/comp-unit-lang.exp: Same.
* gdb.dwarf2/dw2-ifort-parameter.exp: Same.
* gdb.dwarf2/dw2-symtab-includes.exp: Same.
* gdb.dwarf2/dwz.exp: Same.
* gdb.dwarf2/imported-unit-abstract-const-value.exp: Same.
* gdb.dwarf2/imported-unit-runto-main.exp: Same.
* gdb.dwarf2/imported-unit.exp: Same.
* gdb.dwarf2/opaque-type-lookup.exp: Same.

Automatic date update in version.in

mmix ld: move .init (and _init) first.

This both makes the section layout more similar to that of the general
default for ELF and fixes (makes true) an assumption that code and
rodata is located between _init and __etext, in
libgcc/config/mmix/crti.S.  Sadly, that's not actually true for ELF
(generally and for elf64mmix), where exception-tables and .rodata is
after _etext; I'm pondering what to do about that.

The original mmix simulator behavior is that memory magically appears
on access, initialized with 0, which is not preferable when chasing
bugs by throwing code the size of the gcc test-suite to the simulator.
The code in crti.S compatibly enables simulator machinery to identify
undefined memory and instead stopping the simulator with an error
(going to interactive mode for interactive runs).  See
http://gcc.gnu.org/legacy-ml/gcc-patches/2012-10/msg01871.html for
more, including the mmix-sim.ch "patch file".

This fixes only one error in the gcc testsuite,
gcc.c-torture/execute/pr20621-1.c with LTO, where for some reason
gcc/lto chooses to move (writable) data that is only used to read 0 to
.rodata.  An access (sufficiently far inside a block) in an
unregistered place is flagged as an invalid access.

The bpo-9m test that I had to adjust, actually exposes a wart: mmo
does not have the notion of symbol types (or sections) and the
test-case now has leading zeros at "Main" eventually leading to it
being misdiagnosed as being outside .text and .data, thus here mapped
to BFD as an absolute symbol.  The test is not intended to check the
mmo symbol-type machinery, so I'm just tweaking it to be
symbol-type-neutral for "Main".

Since you have to jump through hoops to see the problem, I don't think
this commit is worth putting on the 2.35-branch.

ld:
* scripttempt/mmo.sc: Move .init first in .text output section.
* testsuite/ld-mmix/bpo-9m.d: Adjust accordingly.

Fix POSIX-isms in gdb.base/shell.exp

Some recent tests added to gdb.base/shell.exp have been failing on
Windows host due to assumptions that the shell is a POSIX variant.  On
Windows, GDB uses CMD.EXE via the system() call to run shell commands
instead.

There seems to be no obvious CMD.EXE equivalent for "kill -2 $$" to
signal the shell process, so this patch skips those tests on Windows
host.  The second problem addressed here is that CMD.EXE only
recognizes double quotes, not single quotes; that change can be made
unconditionally since POSIX shells recognize double quotes as well.

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

gdb/testsuite/
* gdb.base/shell.exp: Skip pipe tests dependent on sh on Windows host.
Use double quotes instead of single quotes.

gdb: fix issues with handling DWARF v5 rnglists & .dwo files.

While experimenting with GDB on DWARF 5 with split debug (dwo files),
I discovered that GDB was not reading the rnglist index
properly (it needed to be reprocessed in the same way the loclist
index does), and that there was no code for reading rnglists out of
dwo files at all.  Also, the rnglist address reading function
(dwarf2_rnglists_process) was adding the base address to all rnglist
entries, when it's only supposed to add it to the DW_RLE_offset_pair
entries (http://dwarfstd.org/doc/DWARF5.pdf, p. 53), and was not
handling several entry types.

- Added 'reprocessing' for reading rnglist index (as is done for loclist
  index).
- Added code for reading rnglists out of .dwo files.
- Added several missing rnglist forms to dwarf2_rnglists_process.
- Fixed bug that was alwayas adding base address for rnglists (only
  one form needs that).
- Updated dwarf2_rnglists_process to read rnglist out of dwo file when
  appropriate.
- Added new functions cu_debug_rnglist_section & read_rnglist_index.
- Added new testcase, dw5-rnglist-test.{cc,exp}

Special note about the new testcase:

In order for the test case to test anything meaningful, it must be
compiled with clang, not GCC.  The way to do this is as follows:

$ make check RUNTESTFLAGS="CC_FOR_TARGET=/path/to/clang CXX_FOR_TARGET=/path/to/clang++ dw5-rnglist-test.exp"

This following version of clang was used for this testing:

clang version 9.0.1-11
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Change-Id: I3053c5ddc345720b8ed81e23a88fe537ab38748d

[gdb/testsuite] Add pseudo line number program instruction: line

There's an idiom in dwarf assembly test-cases:
...
set line1 [gdb_get_line_number "line 1"]
set line2 [gdb_get_line_number "line 2"]
set line3 [gdb_get_line_number "line 3"]
  ...
            {DW_LNS_advance_line [expr $line1 - 1]}
  ...
            {DW_LNS_advance_line [expr $line2 - $line1]}
  ...
            {DW_LNS_advance_line [expr $line3 - $line2]}
...

Add a pseudo line number program instruction "line", such that we can simply
write:
...
            {line $line1}
  ...
            {line $line2}
  ...
            {line $line3}
...

Build and reg-tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* lib/dwarf.exp (program): Initialize _line.
(DW_LNE_end_sequence): Reinitialize _line.
(DW_LNS_advance_line): Update _line.
(line): New proc.
* gdb.dwarf2/dw2-inline-many-frames.exp: Use line.
* gdb.dwarf2/dw2-inline-small-func.exp: Same.
* gdb.dwarf2/dw2-inline-stepping.exp: Same.
* gdb.dwarf2/dw2-is-stmt-2.exp: Same.
* gdb.dwarf2/dw2-is-stmt.exp: Same.
* gdb.dwarf2/dw2-ranges-func.exp: Same.

Automatic date update in version.in

gdb/testsuite: Update test pattern in ptype-on-functions.exp

It was pointed out that the recently added test
gdb.fortran/ptype-on-functions.exp fails on older versions of
gfortran.  This is because the ABI for passing string lengths changed
from a 4-byte to 8-byte value (on some targets).

This change is documented here:
  https://gcc.gnu.org/gcc-8/changes.html.

  Character variables longer than HUGE(0) elements are now possible on
  64-bit targets. Note that this changes the procedure call ABI for
  all procedures with character arguments on 64-bit targets, as the
  type of the hidden character length argument has changed. The hidden
  character length argument is now of type INTEGER(C_SIZE_T).

This commit just relaxes the pattern to accept any size of integer for
the string length argument.

gdb/testsuite/ChangeLog:

* gdb.fortran/ptype-on-functions.exp: Make the result pattern more
generic.

x86: Don't display eiz with no scale

Change

67 48 8b 1c 25 ef cd ab 89  mov    0x89abcdef(,%eiz,1),%rbx

to

67 48 8b 1c 25 ef cd ab 89  mov    0x89abcdef,%rbx

in AT&T syntax and

67 48 8b 1c 25 ef cd ab 89  mov    rbx,QWORD PTR [eiz*1+0x89abcdef]

to

67 48 8b 1c 25 ef cd ab 89  mov    rbx,QWORD PTR ds:0x89abcdef

in Intel syntax.

gas/

PR gas/26237
* testsuite/gas/i386/evex-no-scale-64.d: Updated.
* testsuite/gas/i386/addr32.d: Likewise.
* testsuite/gas/i386/x86-64-addr32-intel.d: Likewise.
* testsuite/gas/i386/x86-64-addr32.d: Likewise.

opcodes/

PR gas/26237
* i386-dis.c (OP_E_memory): Don't display eiz with no scale
without base nor index registers.

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.