[gdb/testsuite] Handle unrecognized command line option in gdb_compile_test

When running the gdb testsuite with gnatmake-4.8, I get many fails of the
following form:
...
gcc: error: unrecognized command line option '-fgnat-encodings=all'^M
gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error^M
compiler exited with status 1
compilation failed: gcc ... gdb.ada/O2_float_param/foo.adb
gcc: error: unrecognized command line option '-fgnat-encodings=all'
gnatmake: "gdb.ada/O2_float_param/foo.adb" compilation error
FAIL: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb
...

Fix this by marking the test unsupported instead, such that we have:
...
UNSUPPORTED: gdb.ada/O2_float_param.exp: scenario=all: compilation foo.adb \
  (unsupported option '-fgnat-encodings=all')
...

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-09-10  Tom de Vries  <tdevries@suse.de>

* lib/gdb.exp (gdb_compile_test): Handle unrecognized command line
option.

Automatic date update in version.in

Add ChangeLog entry for previous patch

I forgot to 'git commit' the ChangeLog for the previous patch.

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

* dwarf2/read.h (dwarf2_per_objfile::resize_symtabs): Remove.
* dwarf2/read.c (all_comp_units_iterator, all_comp_units_range):
New classes.
(dwarf2_per_objfile::symtab_set_p)
(dwarf2_per_objfile::get_symtab, dwarf2_per_objfile::set_symtab):
Adjust to resizeable vectors.
(dwarf2_gdb_index::expand_symtabs_matching)
(dwarf2_base_index_functions::map_symbol_filenames)
(dwarf2_debug_names_index::expand_symtabs_matching): Use
all_comp_units_range.
(dwarf2_initialize_objfile, dwarf2_build_psymtabs)
(add_type_unit): Don't call resize_symtabs.

[gdb/testsuite] Fix gdb.base/coredump-filter-build-id.exp with older eu-unstrip

On openSUSE Leap 42.3 with eu-unstrip 0.158, we run into:
...
(gdb) PASS: gdb.base/coredump-filter-build-id.exp: save corefile
First line of eu-unstrip: \
  0x400000+0x202000 f4ae8502bd6a14770182382316bc595e9dc6f08b@0x400284 - - [exe]
FAIL: gdb.base/coredump-filter-build-id.exp: gcore dumped mapping with build-id
...

The test expects an actual file name instead of '[exe]', but that only got
introduced with eu-unstrip 0.161.  Before it printed '[exe]' or '[pie]'.

Fix this by updating the regexp.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-09-09  Tom de Vries  <tdevries@suse.de>

* gdb.base/coredump-filter-build-id.exp: Handle older eu-unstrip.

[gdb/testsuite] Fix various issues in gdb.mi/mi-sym-info.exp

I noticed this failure in gdb.mi/mi-sym-info.exp with gcc-4.8:
...
FAIL: gdb.mi/mi-sym-info.exp: -symbol-info-functions --max-results 1 \
  (unexpected output)
...
due to function f2 instead of f3 being listed.

AFAICT, this is caused by a difference in debug info:
...
$ readelf -wi outputs/gdb.mi/mi-sym-info/mi-sym-info1.o \
  | egrep "DW_AT_name.*: f[1-3]"
    <72>   DW_AT_name        : f1
    <a1>   DW_AT_name        : f2
    <d0>   DW_AT_name        : f3
...
vs:
...
$ readelf -wi outputs/gdb.mi/mi-sym-info/mi-sym-info1.o \
  | egrep "DW_AT_name.*: f[1-3]"
    <f4>   DW_AT_name        : f3
    <123>   DW_AT_name        : f2
    <152>   DW_AT_name        : f1
...
and the command documentation does not mention an imposed order, so fix this
by allowing f2 as well.

Doing this fix, it made sense to do a refactoring of adding f2_re and f3_re
variables, in order to write (?:$f2_re|$f3_re), and I applied the same pattern
overall.

Furthermore, I found a silent FAIL due to calling mi_gdb_proc with 2 args, fix
by updating the regexp.

Then I ran with clang and found another FAIL, fix by updating the regexp.

Tested on x86_64-linux with gcc-4.8.5, gcc-7.5.0, gcc-11.2.1, clang-7.0.1 and
clang-12.0.1.

gdb/testsuite/ChangeLog:

2021-09-09  Tom de Vries  <tdevries@suse.de>

* gdb.mi/mi-sym-info.exp: Fix regexps.  Add missing message argument
to mi_gdb_test.  Factor out regexps for functions and variables.

Automatic date update in version.in

Fix two regressions caused by CU / TU merging

PR symtab/28160 and PR symtab/27893 concern GDB crashes in the test
suite when using the "fission" target board.  They are both caused by
the patches that merge the list of CUs with the list of TUs (and to a
lesser degree by the patches to share DWARF data across objfiles), and
the underlying issue is the same: it turns out that reading a DWO can
cause new type units to be created.  This means that the list of
dwarf2_per_cu_data objects depends on precisely which CUs have been
expanded.  However, because the type units can be created while
expanding a CU means that the vector of CUs can expand while it is
being iterated over -- a classic mistake.  Also, because a TU can be
added later, it means the resize_symtabs approach is incorrect.

This patch fixes resize_symtabs by removing it, and having set_symtab
resize the vector on demand.  It fixes the iteration problem by
introducing a safe (index-based) iterator and changing the relevant
spots to use it.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28160
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27893

(cherry picked from commit d58e54bd277b90d847be09ae4b18bfdbc0dc2066)

Revert: [AArch64] MTE corefile support

bfd     * elf.c (elfcore_make_memtag_note_section): New function.
(elfcore_grok_note): Handle NT_MEMTAG note types.

binutils* readelf.c (get_note_type): Handle NT_MEMTAG note types.

include * elf/common.h (NT_MEMTAG): New constant.
(NT_MEMTAG_TYPE_AARCH_MTE): New constant.

Automatic date update in version.in

fbsd-nat: Don't use '%jd' and '%ju' with printf_filtered.

The handler for 'info proc status' for native processes on FreeBSD
uses the 'j' size modifier along with uintmax_t / intmax_t casts to
output integer values for types such as off_t that are not aliases of
a basic C type such as 'int' or 'long'.  printf_filtered does not
support the 'j' modifer, so this resulted in runtime errors in
practice:

(gdb) info proc stat
process 8674
Name: ls
State: T (stopped)
Parent process: 8673
Process group: 8674
Session id: 2779
Unrecognized format specifier 'j' in printf

Instead, use plongest and pulongest to generate the output strings of
these integer values.

gdb/ChangeLog:

* fbsd-nat.c (fbsd_nat_target::info_proc): Use plongest and
pulongest instead of %j.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[gdb/testsuite] Check avx support in gdb.arch/amd64-disp-step-avx.exp

On a machine on Open Build Service I'm running into a SIGILL for test-case
gdb.arch/amd64-disp-step-avx.exp:
...
Program received signal SIGILL, Illegal instruction.^M
test_rip_vex2 () at gdb.arch/amd64-disp-step-avx.S:40^M
40              vmovsd ro_var(%rip),%xmm0^M
(gdb) FAIL: gdb.arch/amd64-disp-step-avx.exp: vex2: \
  continue to test_rip_vex2_end
...
The SIGILL happens when trying to execute the first avx instruction in the
executable.

I can't directly access the machine, but looking at the log for test-case
gdb.arch/i386-avx.exp, it seems that there's no avx support:
...
Breakpoint 1, main (argc=1, argv=0x7fffffffd6b8) at gdb.arch/i386-avx.c:68^M
68        if (have_avx ())^M
(gdb) print have_avx ()^M
$1 = 0^M
...

Fix this by:
- adding a gdb_caching_proc have_avx, similar to have_mpx, using the have_avx
  function from gdb.arch/i386-avx.c
- using proc have_avx in both gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp
  and gdb/testsuite/gdb.arch/i386-avx.exp.

Tested on my x86_64-linux laptop with avx support, where both test-cases pass.

gdb/testsuite/ChangeLog:

2021-09-04  Tom de Vries  <tdevries@suse.de>

PR testsuite/26950
* gdb/testsuite/gdb.arch/i386-avx.c (main): Remove call to have_avx.
(have_avx): Move ...
* gdb/testsuite/lib/gdb.exp (have_avx): ... here.  New proc.
* gdb/testsuite/gdb.arch/amd64-disp-step-avx.exp: Use have_avx.
* gdb/testsuite/gdb.arch/i386-avx.exp: Same.

Automatic date update in version.in

[gdb/testsuite] Add untested case in gdb.gdb/complaints.exp

When building gdb with "-Wall -O2 -g -flto=auto", I run into:
...
(gdb) call clear_complaints()^M
No symbol "clear_complaints" in current context.^M
(gdb) FAIL: gdb.gdb/complaints.exp: clear complaints
...

The problem is that lto has optimized away clear_complaints, and consequently
the selftests cannot run.

Fix this by:
- using info function to detect presence of clear_complaints
- handling the absence of clear_complaints by calling untested
...
(gdb) UNTESTED: gdb.gdb/complaints.exp: \
  Cannot find clear_complaints, skipping test
...

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-09-03  Tom de Vries  <tdevries@suse.de>

* gdb.gdb/complaints.exp: Use untested if clear_complaints cannot
be found.

[gdb/testsuite] Add untested case in selftest_setup

When building gdb with "-Wall -O2 -g -flto=auto", I run into:
...
FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \
  (got interactive prompt)
FAIL: gdb.gdb/python-helper.exp: run until breakpoint at captured_main
WARNING: Couldn't test self
...
and similar in gdb.gdb/selftest.exp.

The first FAIL in more detail:
...
(gdb) break captured_main^M
Function "captured_main" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.gdb/python-helper.exp: breakpoint in captured_main \
  (got interactive prompt)
...

The problem is that lto has optimized away the captured_main function
and consequently the selftests dependent on that cannot run.

Fix this by:
- using gdb_breakpoint to detect failure to set the breakpoint
- handling the failure to set a breakpoint by calling untested
- not emitting the warning if we've already got untested
such that we have:
...
(gdb) UNTESTED: gdb.gdb/python-helper.exp: Cannot set breakpoint at \
  captured_main, skipping testcase.
...

gdb/testsuite/ChangeLog:

2021-09-03  Tom de Vries  <tdevries@suse.de>

* lib/selftest-support.exp: Emit untested when not being able to set
breakpoint.

Automatic date update in version.in

Automatic date update in version.in

[gdb/testsuite] Fix dwo path in fission-*.S

[ Using $build for /home/vries/gdb_versions/devel/build to make things a bit
more readable. ]

When using make check// to run test-case gdb.dwarf2/fission-base.exp:
...
( cd $build/gdb; make check//unix RUNTESTFLAGS="fission-base.exp" )
...
we run into:
...
(gdb) file \
  $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base^M
Reading symbols from \
  $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base...^M
warning: Could not find DWO CU \
  $build/gdb/testsuite.1/outputs/gdb.dwarf2/fission-base/fission-base.dwo \
  (0x807060504030201) referenced by CU at offset 0xc7 [in module \
  $build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base]^M
...

The problem is that the executable refers to the dwo file using path name
$build/gdb/testsuite.1/outputs/gdb.dwarf2/fission-base/fission-base.dwo,
while the actual dwo file is at
$build/gdb/testsuite.unix/outputs/gdb.dwarf2/fission-base/fission-base.dwo.

This is caused by this trick in fission-base.S:
...
 #define XSTR(s) STR(s)
 #define STR(s) #s
   ...
   .asciz XSTR(DWO)        # DW_AT_GNU_dwo_name
...
and:
...
$ echo | gcc -E -dD - | grep "define unix"
...

I used this trick to avoid doing additional_flags=-DDWO=\"$dwo\", since I was
concerned that there could be quoting issues.

However, I've found other uses of this pattern, f.i. in
gdb/testsuite/gdb.base/corefile-buildid.exp:
...
  additional_flags=-DSHLIB_NAME=\"$dlopen_lib\"]
...

So, fix this by:
- using additional_flags=-DDWO=\"$dwo\" and
- using plain DWO instead of XSTR(DWO)

Likewise in other gdb.dwarf2/fission*.exp test-cases.

Tested on x86_64-linux, using make check//unix.

gdb/testsuite/ChangeLog:

2021-09-01  Tom de Vries  <tdevries@suse.de>

PR testsuite/28298
* gdb.dwarf2/fission-base.S: Use DWO instead of XSTR(DWO).
* gdb.dwarf2/fission-loclists-pie.S: Same.
* gdb.dwarf2/fission-loclists.S: Same.
* gdb.dwarf2/fission-reread.S: Same.
* gdb.dwarf2/fission-base.exp: Use additional_flags=-DDWO=\"$dwo\".
* gdb.dwarf2/fission-loclists-pie.exp: Same.
* gdb.dwarf2/fission-loclists.exp: Same.
* gdb.dwarf2/fission-reread.exp: Same.

[gdb/testsuite] Fix gdb.fortran/call-no-debug.exp symbol search

On openSUSE Tumbleweed I ran into:
...
(gdb) ptype outstring_func.part^M
No symbol "outstring_func" in current context.^M
(gdb) FAIL: gdb.fortran/call-no-debug.exp: ptype outstring_func.part
...
while on openSUSE Leap 15.2 I have instead:
...
(gdb) ptype string_func_^M
type = <unknown return type> ()^M
(gdb) PASS: gdb.fortran/call-no-debug.exp: ptype string_func_
...

The difference is caused by the result for "info function string_func", which
is this for the latter:
...
(gdb) info function string_func^M
All functions matching regular expression "string_func":^M
^M
Non-debugging symbols:^M
0x000000000040089c  string_func_^M
...
but this for the former:
...
(gdb) info function string_func^M
All functions matching regular expression "string_func":^M
^M
Non-debugging symbols:^M
0x00000000004012bb  string_func_^M
0x00007ffff7bac5b0  outstring_func.part^M
0x00007ffff7bb1a00  outstring_func.part^M
...

The extra symbols are part of glibc:
...
$ nm /lib64/libc.so.6 | grep string_func
00000000000695b0 t outstring_func.part.0
000000000006ea00 t outstring_func.part.0
...

If glibc debug info is installed, we get instead:
...
(gdb) info function string_func^M
All functions matching regular expression "string_func":^M
^M
File /usr/src/debug/glibc-2.33-9.1.x86_64/stdio-common/vfprintf-internal.c:^M
236:    static int outstring_func(int, size_t, const unsigned int *, FILE *);^M
^M
File vfprintf-internal.c:^M
236:    static int outstring_func(int, size_t, const unsigned char *, FILE *);^M
^M
Non-debugging symbols:^M
0x00000000004012bb  string_func_^M
...
and the FAIL doesn't trigger.

Fix this by calling "info function string_func" before starting the exec, such
that only symbols of the exec are taken into account.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-09-01  Tom de Vries  <tdevries@suse.de>

* gdb.fortran/call-no-debug.exp: Avoid shared lib symbols for
find_mangled_name calls.

Automatic date update in version.in

Automatic date update in version.in

[gdb/cli] Don't assert on empty string for core-file

With current gdb we run into:
...
$ gdb -batch '' ''
: No such file or directory.
pathstuff.cc:132: internal-error: \
  gdb::unique_xmalloc_ptr<char> gdb_abspath(const char*): \
  Assertion `path != NULL && path[0] != '\0'' failed.
...

Fix this by skipping the call to gdb_abspath in core_target_open in the
empty-string case, such that we have instead:
...
$ gdb -batch '' ''
: No such file or directory.
: No such file or directory.
$
...

Tested on x86_64-linux.

gdb/ChangeLog:

2021-08-30  Tom de Vries  <tdevries@suse.de>

PR cli/28290
* gdb/corelow.c (core_target_open): Skip call to gdb_abspath in the
empty-string case.

gdb/testsuite/ChangeLog:

2021-08-30  Tom de Vries  <tdevries@suse.de>

PR cli/28290
* gdb.base/batch-exit-status.exp: Add gdb '' and gdb '' '' tests.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[gdb] Fix 'not in executable format' error message

With trying to load a non-executable file into gdb, we run into PR26880:
...
$ gdb -q -batch test.c
"0x7ffc87bfc8d0s": not in executable format: \
  file format not recognized
...

The problem is caused by using %ps in combination with the error function
(note that confusingly, it does work in combination with the warning
function).

Fix this by using plain "%s" instead.

Tested on x86_64-linux.

gdb/ChangeLog:

2021-08-23  Tom de Vries  <tdevries@suse.de>

PR gdb/26880
* gdb/exec.c (exec_file_attach): Use %s instead of %ps in call to
error function.

gdb/testsuite/ChangeLog:

2021-08-23  Tom de Vries  <tdevries@suse.de>

PR gdb/26880
* gdb.base/non-executable.exp: New file.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Update documentation to mention Pygments

Philippe Blain pointed out that the gdb documentation does not mention
that Pygments may be used for source highlighting.  This patch updates
the docs to reflect how highlighting is actually done.

(cherry picked from commit 6a33fa0efec5aa87230a84bcab3c097237dd7f90)

gdb/doc/ChangeLog
2021-08-12  Tom Tromey  <tromey@adacore.com>

* gdb.texinfo (Output Styling): Mention Pygments.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[gdb/symtab] Fix zero address complaint for shlib

In PR28004 the following warning / Internal error is reported:
...
$ gdb -q -batch \
    -iex "set sysroot $(pwd -P)/repro" \
    ./repro/gdb \
    ./repro/core \
    -ex bt
  ...
 Program terminated with signal SIGABRT, Aborted.
 #0  0x00007ff8fe8e5d22 in raise () from repro/usr/lib/libc.so.6
 [Current thread is 1 (LWP 1762498)]
 #1  0x00007ff8fe8cf862 in abort () from repro/usr/lib/libc.so.6
 warning: (Internal error: pc 0x7ff8feb2c21d in read in psymtab, \
           but not in symtab.)
 warning: (Internal error: pc 0x7ff8feb2c218 in read in psymtab, \
           but not in symtab.)
  ...
 #2  0x00007ff8feb2c21e in __gnu_debug::_Error_formatter::_M_error() const \
   [clone .cold] (warning: (Internal error: pc 0x7ff8feb2c21d in read in \
   psymtab, but not in symtab.)

) from repro/usr/lib/libstdc++.so.6
...

The warning is about the following:
- in find_pc_sect_compunit_symtab we try to find the address
  (0x7ff8feb2c218 / 0x7ff8feb2c21d) in the symtabs.
- that fails, so we try again in the partial symtabs.
- we find a matching partial symtab
- however, the partial symtab has a full symtab, so
  we should have found a matching symtab in the first step.

The addresses are:
...
(gdb) info sym 0x7ff8feb2c218
__gnu_debug::_Error_formatter::_M_error() const [clone .cold] in \
  section .text of repro/usr/lib/libstdc++.so.6
(gdb) info sym 0x7ff8feb2c21d
__gnu_debug::_Error_formatter::_M_error() const [clone .cold] + 5 in \
  section .text of repro/usr/lib/libstdc++.so.6
...
which correspond to unrelocated addresses 0x9c218 and 0x9c21d:
...
$ nm -C  repro/usr/lib/libstdc++.so.6.0.29 | grep 000000000009c218
000000000009c218 t __gnu_debug::_Error_formatter::_M_error() const \
  [clone .cold]
...
which belong to function __gnu_debug::_Error_formatter::_M_error() in
/build/gcc/src/gcc/libstdc++-v3/src/c++11/debug.cc.

The partial symtab that is found for the addresses is instead the one for
/build/gcc/src/gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc, which is
incorrect.

This happens as follows.

The bitmap_allocator.cc CU has DW_AT_ranges at .debug_rnglist offset 0x4b50:
...
    00004b50 0000000000000000 0000000000000056
    00004b5a 00000000000a4790 00000000000a479c
    00004b64 00000000000a47a0 00000000000a47ac
...

When reading the first range 0x0..0x56, it doesn't trigger the "start address
of zero" complaint here:
...
      /* A not-uncommon case of bad debug info.
         Don't pollute the addrmap with bad data.  */
      if (range_beginning + baseaddr == 0
          && !per_objfile->per_bfd->has_section_at_zero)
        {
          complaint (_(".debug_rnglists entry has start address of zero"
                       " [in module %s]"), objfile_name (objfile));
          continue;
        }
...
because baseaddr != 0, which seems incorrect given that when loading the
shared library individually in gdb (and consequently baseaddr == 0), we do see
the complaint.

Consequently, we run into this case in dwarf2_get_pc_bounds:
...
  if (low == 0 && !per_objfile->per_bfd->has_section_at_zero)
    return PC_BOUNDS_INVALID;
...
which then results in this code in process_psymtab_comp_unit_reader being
called with cu_bounds_kind == PC_BOUNDS_INVALID, which sets the set_addrmap
argument to 1:
...
      scan_partial_symbols (first_die, &lowpc, &highpc,
                            cu_bounds_kind <= PC_BOUNDS_INVALID, cu);
...
and consequently, the CU addrmap gets build using address info from the
functions.

During that process, addrmap_set_empty is called with a range that includes
0x9c218 and 0x9c21d:
...
(gdb) p /x start
$7 = 0x9989c
(gdb) p /x end_inclusive
$8 = 0xb200d
...
but it's called for a function at DIE 0x54153 with DW_AT_ranges at 0x40ae:
...
    000040ae 00000000000b1ee0 00000000000b200e
    000040b9 000000000009989c 00000000000998c4
    000040c3 <End of list>
...
and neither range includes 0x9c218 and 0x9c21d.

This is caused by this code in partial_die_info::read:
...
            if (dwarf2_ranges_read (ranges_offset, &lowpc, &highpc, cu,
                                    nullptr, tag))
             has_pc_info = 1;
...
which pretends that the function is located at addresses 0x9989c..0xb200d,
which is indeed not the case.

This patch fixes the first problem encountered: fix the "start address of
zero" complaint warning by removing the baseaddr part from the condition.
Same for dwarf2_ranges_process.

The effect is that:
- the complaint is triggered, and
- the warning / Internal error is no longer triggered.

This does not fix the observed problem in partial_die_info::read, which is
filed as PR28200.

Tested on x86_64-linux.

Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>
gdb/ChangeLog:

2021-08-06  Simon Marchi  <simon.marchi@polymtl.ca>
    Tom de Vries  <tdevries@suse.de>

PR symtab/28004
* dwarf2/read.c (dwarf2_rnglists_process, dwarf2_ranges_process):
Fix zero address complaint.

gdb/testsuite/ChangeLog:

2021-08-06  Simon Marchi  <simon.marchi@polymtl.ca>
    Tom de Vries  <tdevries@suse.de>

PR symtab/28004
* gdb.dwarf2/dw2-zero-range-shlib.c: New test.
* gdb.dwarf2/dw2-zero-range.c: New test.
* gdb.dwarf2/dw2-zero-range.exp: New file.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Avoid crash in varobj deletion

PR varobj/28131 points out a crash in the varobj deletion code.  It
took a while to reproduce this, but essentially what happens is that a
top-level varobj deletes its root object, then deletes the "dynamic"
object.  However, deletion of the dynamic object may cause
~py_varobj_iter to run, which in turn uses gdbpy_enter_varobj:

gdbpy_enter_varobj::gdbpy_enter_varobj (const struct varobj *var)
: gdbpy_enter (var->root->exp->gdbarch, var->root->exp->language_defn)
{
}

However, because var->root has already been destroyed, this is
invalid.

I've added a new test case.  This doesn't reliably crash, but the
problem can easily be seen under valgrind (and, I presume, with ASAN,
though I did not try this).

Tested on x86-64 Fedora 32.  I also propose putting this on the GDB 11
branch, with a suitable ChangeLog entry of course.

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

(cherry picked from commit 4d0754c5f572b01cf2fe6c8ab292adba83331cbc)

gdb/ChangeLog
2021-08-02  Tom Tromey  <tromey@adacore.com>

PR varobj/28131
* varobj.c (~varobj): Delete 'dynamic' before 'root'.

gdb/testsuite/ChangeLog
2021-08-02  Tom Tromey  <tromey@adacore.com>

PR varobj/28131
* gdb.python/py-mi-var-info-path-expression.exp: Add regression
test.

gdb: Make the builtin "boolean" type an unsigned type

When printing the fields of a register that is of a custom struct type,
the "unpack_bits_as_long ()" function is used:

    do_val_print (...)
      cp_print_value_fields (...)
        value_field_bitfield (...)
          unpack_value_bitfield (...)
            unpack_bits_as_long (...)

This function may sign-extend the extracted field while returning it:

    val >>= lsbcount;

    if (...)
      {
        valmask = (((ULONGEST) 1) << bitsize) - 1;
        val &= valmask;
        if (!field_type->is_unsigned ())
     if (val & (valmask ^ (valmask >> 1)))
         val |= ~valmask;
      }

    return val;

lsbcount:   Number of lower bits to get rid of.
bitsize:    The bit length of the field to be extracted.
val:        The register value.
field_type: The type of field that is being handled.

While the logic here is correct, there is a problem when it is
handling "field_type"s of "boolean".  Those types are NOT marked
as "unsigned" and therefore they end up being sign extended.
Although this is not a problem for "false" (0), it definitely
causes trouble for "true".

This patch constructs the builtin boolean type as such that it is
marked as an "unsigned" entity.

The issue tackled here was first encountered for arc-elf32 target
running on an x86_64 machine.  The unit-test introduced in this change
has passed for all the targets (--enable-targets=all) running on the
same x86_64 host.

gdb/ChangeLog:

PR gdb/28104
* gdbtypes.c (gdbtypes_post_init): Use
"arch_boolean_type (..., unsigned=1, ...) to construct
"boolean".
cp-valprint.c (test_print_flags): New.
(_initialize_cp_valprint): Run the "test_print_flags" unit-test.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[gdb/build] Disable attribute nonnull

With trunk gcc (12.0) we're running into a -Werror=nonnull-compare build
breaker in gdb, which caused a broader review of the usage of the nonnull
attribute.

The current conclusion is that it's best to disable this.  This is explained
at length in the gdbsupport/common-defs.h comment.

Tested by building with trunk gcc.

gdbsupport/ChangeLog:

2021-07-30  Tom de Vries  <tdevries@suse.de>

* common-defs.h (ATTRIBUTE_NONNULL): Disable.

Automatic date update in version.in

Automatic date update in version.in

[gdb/symtab] Fix unhandled dwarf expression opcode with gcc-11 -gdwarf-5

[ I've confused things by forgetting to add -gdwarf-4 in $subject of
commit 0057a7ee0d9 "[gdb/testsuite] Add KFAILs for gdb.ada FAILs with
gcc-11".  So I'm adding here -gdwarf-5 in $subject, even though -gdwarf-5 is
the default for gcc-11.  I keep getting confused because of working with a
system gcc-11 compiler that was patched to switch the default back to
-gdwarf-4. ]

When running test-case gdb.ada/arrayptr.exp with gcc-11 (and default
-gdwarf-5), I run into:
...
(gdb) print pa_ptr.all^M
Unhandled dwarf expression opcode 0xff^M
(gdb) FAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all
...

What happens is that pa_ptr:
...
 <2><1523>: Abbrev Number: 3 (DW_TAG_variable)
    <1524>   DW_AT_name        : pa_ptr
    <1529>   DW_AT_type        : <0x14fa>
...
has type:
...
 <2><14fa>: Abbrev Number: 2 (DW_TAG_typedef)
    <14fb>   DW_AT_name        : foo__packed_array_ptr
    <1500>   DW_AT_type        : <0x1504>
 <2><1504>: Abbrev Number: 4 (DW_TAG_pointer_type)
    <1505>   DW_AT_byte_size   : 8
    <1505>   DW_AT_type        : <0x1509>
...
which is a pointer to a subrange:
...
 <2><1509>: Abbrev Number: 12 (DW_TAG_subrange_type)
    <150a>   DW_AT_lower_bound : 0
    <150b>   DW_AT_upper_bound : 0x3fffffffffffffffff
    <151b>   DW_AT_name        : foo__packed_array
    <151f>   DW_AT_type        : <0x15cc>
    <1523>   DW_AT_artificial  : 1
 <1><15cc>: Abbrev Number: 5 (DW_TAG_base_type)
    <15cd>   DW_AT_byte_size   : 16
    <15ce>   DW_AT_encoding    : 7      (unsigned)
    <15cf>   DW_AT_name        : long_long_long_unsigned
    <15d3>   DW_AT_artificial  : 1
...
with upper bound of form DW_FORM_data16.

In gdb/dwarf/attribute.h we have:
...
  /* Return non-zero if ATTR's value falls in the 'constant' class, or
     zero otherwise.  When this function returns true, you can apply
     the constant_value method to it.
     ...
     DW_FORM_data16 is not considered as constant_value cannot handle
     that.  */
  bool form_is_constant () const;
...
so instead we have attribute::form_is_block (DW_FORM_data16) == true.

Then in attr_to_dynamic_prop for the upper bound, we get a PROC_LOCEXPR
instead of a PROP_CONST and end up trying to evaluate the constant
0x3fffffffffffffffff as if it were a locexpr, which causes the
"Unhandled dwarf expression opcode 0xff".

In contrast, with -gdwarf-4 we have:
...
    <164c>   DW_AT_upper_bound : 18 byte block: \
      9e 10 ff ff ff ff ff ff ff ff 3f 0 0 0 0 0 0 0 \
      (DW_OP_implicit_value 16 byte block: \
        ff ff ff ff ff ff ff ff 3f 0 0 0 0 0 0 0 )
...

Fix the dwarf error by translating the DW_FORM_data16 constant into a
PROC_LOCEXPR, effectively by prepending 0x9e 0x10, such that we have same
result as with -gdwarf-4:
...
(gdb) print pa_ptr.all^M
That operation is not available on integers of more than 8 bytes.^M
(gdb) KFAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all \
  (PRMS: gdb/20991)
...

Tested on x86_64-linux, with gcc-11 and target board
unix/gdb:debug_flags=-gdwarf-5.

gdb/ChangeLog:

2021-07-28  Tom de Vries  <tdevries@suse.de>

* dwarf2/read.c (attr_to_dynamic_prop): Handle DW_FORM_data16.

Automatic date update in version.in

[gdb/testsuite] Add xfail for PR gcc/101643

With gcc 8.5.0 I run into:
...
(gdb) print bad^M
$2 = (0 => 0 <repeats 25 times>)^M
(gdb) FAIL: gdb.ada/big_packed_array.exp: scenario=minimal: print bad
...
while with gcc 9.3.1 we have instead:
...
(gdb) print bad^M
$2 = (false <repeats 196 times>)^M
(gdb) PASS: gdb.ada/big_packed_array.exp: scenario=minimal: print bad
...

This is caused by gcc PR, which I've filed at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101643 "[debug, ada] packed array
not described as packed".

Fix by marking this as XFAIL.

Tested on x86_64-linux.

gdb/ChangeLog:

2021-07-27  Tom de Vries  <tdevries@suse.de>

PR testsuite/26904
* gdb/testsuite/gdb.ada/big_packed_array.exp: Add xfail.

[gdb/testsuite] Add xfail for PR gcc/101633

With gcc 7.5.0, I run into:
...
(gdb) print objects^M
$1 = ((tag => object, values => ()), (tag => unused))^M
(gdb) FAIL: gdb.ada/array_of_variant.exp: scenario=minimal: print entire array
...
while with gcc 8.5.0 we have:
...
(gdb) print objects^M
$1 = ((tag => object, values => (2, 2, 2, 2, 2)), (tag => unused))^M
(gdb) PASS: gdb.ada/array_of_variant.exp: scenario=minimal: print entire array
...

This is due to a gcc PR, which I've filed at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101633 "Bug 101633 - [debug]
DW_TAG_subrange_type missing DW_AT_upper_bound".

Fix by marking this and related FAILs as XFAIL.

Tested on x86_64-linux.

gdb/ChangeLog:

2021-07-27  Tom de Vries  <tdevries@suse.de>

PR testsuite/26903
* gdb/testsuite/gdb.ada/array_of_variant.exp: Add xfails.

Automatic date update in version.in

Update the NetBSD system call table to match NetBSD-current.

Generated from sys/sys/syscall.h revision 1.319.

We can safely remove the _lwp_gettid syscall, which was never exposed
in libc and never made it into a release.

gdb/ChangeLog:

2021-07-26  Frederic Cambus  <fred@statdns.com>

* syscalls/netbsd.xml: Regenerate.

gdb: Fix numerical field extraction for target description "flags"

The "val_print_type_code_flags ()" function is responsible for
extraction of fields for "flags" data type.  These data types are
used when describing a custom register type in a target description
XML.  The logic used for the extraction though is not sound:

    unsigned field_len = TYPE_FIELD_BITSIZE (type, field);
    ULONGEST field_val
      = val >> (TYPE_FIELD_BITPOS (type, field) - field_len + 1);

TYPE_FIELD_BITSIZE: The bit length of the field to be extracted.
TYPE_FIELD_BITPOS:  The starting position of the field; 0 is LSB.
val:                The register value.

Imagine you have a field that starts at position 1 and its length
is 4 bits.  According to the third line of the code snippet the
shifting right would become "val >> -2", or "val >> 0xfff...fe"
to be precise.  That will result in a "field_val" of 0.

The correct extraction should be:

    ULONGEST field_val = val >> TYPE_FIELD_BITPOS (type, field);

The rest of the algorithm that masks out the higher bits is OK.

gdb/ChangeLog:
2021-07-26  Shahab Vahedi  <shahab@synopsys.com>
            Simon Marchi  <simon.marchi@efficios.com>

PR gdb/28103
* valprint.c (val_print_type_code_flags): Merely shift the VAL
to the right to get rid of the lower bits.
(test_print_flags): New.
(_initialize_valprint): Invoke the "test_print_flags" as a unit-test.

Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>

gdb/mi: handle no condition argument case for -break-condition

As reported in PR gdb/28076 [1], passing no condition argument to the
-break-condition command (e.g.: "-break-condition 2") should clear the
condition for breakpoint 2, just like CLI's "condition 2", but instead
an error message is returned:

  ^error,msg="-break-condition: Missing the <number> and/or <expr> argument"

The current implementation of the -break-condition command's argument
handling (79aabb7308c "gdb/mi: add a '--force' flag to the
'-break-condition' command") was done according to the documentation,
where the condition argument seemed mandatory.  However, the
-break-condition command originally (i.e. before the 79aabb7308c
patch) used the CLI's "cond" command, and back then not passing a
condition argument was clearing out the condition.  So, this is a
regression in terms of the behavior.

Fix the argument handling of the -break-condition command to allow not
having a condition argument, and also update the document to make the
behavior clear.  Also add test cases to test the scenarios which were
previously not covered.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28076

gdb/ChangeLog:
2021-07-26  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

PR gdb/28076
* mi/mi-cmd-break.c (mi_cmd_break_condition): Handle the case
of having no condition argument.

gdb/doc/ChangeLog:
2021-07-26  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

PR gdb/28076
* gdb.texinfo (GDB/MI Breakpoint Commands): Mention clearing
the condition in the -break-condition command.

gdb/testsuite/ChangeLog:
2021-07-26  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

PR gdb/28076
* gdb.mi/mi-break.exp: Add more tests to check clearing the
breakpoint condition.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[gdb/testsuite] Fix FAILs due to PR gcc/101575

When running test-case gdb.ada/formatted_ref.exp with gcc-11 and target board
unix/gdb:debug_flags=-gdwarf-4 we run into:
...
(gdb) print/x s^M
No definition of "s" in current context.^M
(gdb) FAIL: gdb.ada/formatted_ref.exp: print/x s
...
which is caused by "runto defs.adb:20" taking us to defs__struct1IP:
...
(gdb) break defs.adb:20^M
Breakpoint 1 at 0x402cfd: defs.adb:20. (2 locations)^M
(gdb) run ^M
Starting program: formatted_ref ^M
^M
Breakpoint 1, defs__struct1IP () at defs.adb:20^M
20            return s.x;                   -- Set breakpoint marker here.^M
(gdb) print s1'access^M
...
instead of the expected defs.f1:
...
(gdb) break defs.adb:20^M
Breakpoint 1 at 0x402d0e: file defs.adb, line 20.^M
(gdb) run ^M
Starting program: formatted_ref ^M
^M
Breakpoint 1, defs.f1 (s=...) at defs.adb:20^M
20            return s.x;                   -- Set breakpoint marker here.^M
...

This is caused by incorrect line info due to gcc PR 101575 - "[gcc-11,
-gdwarf-4] Missing .file <n> directive causes invalid line info".

Fix this by when landing in defs__struct1IP:
- xfailing the runto, and
- issuing a continue to land in defs.f1.

Likewise in a few other test-cases.

Tested on x86_64-linux, with:
- system gcc.
- gcc-11 and target boards unix/gdb:debug_flags=-gdwarf-4 and
  unix/gdb:debug_flags=-gdwarf-5.

gdb/testsuite/ChangeLog:

2021-07-22  Tom de Vries  <tdevries@suse.de>

* gdb.ada/formatted_ref.exp: Add xfail for PR gcc/101575.
* gdb.ada/iwide.exp: Same.
* gdb.ada/pkd_arr_elem.exp: Same.

[gdb/testsuite] Fix gdb.cp/step-and-next-inline.exp with gcc-11

When running test-case gdb.cp/step-and-next-inline.exp with gcc-11, I run
into:
...
KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 1 \
  (PRMS symtab/25507)
FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 2
KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 3 \
  (PRMS symtab/25507)
...

[ Note that I get the same result with gcc-11 and target board
unix/gdb:debug_flags=-gdwarf-4, so this is not a dwarf 4 vs 5 issue. ]

With gcc-10, I have this trace:
...
64        get_alias_set (&xx);
get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51
51        if (t != NULL
40        if (t->x != i)
52            && TREE_TYPE (t).z != 1
43        return x;
53            && TREE_TYPE (t).z != 2
43        return x;
54            && TREE_TYPE (t).z != 3)
43        return x;
main () at step-and-next-inline.cc:65
65        return 0;
...
and with gcc-11, I have instead:
...
64        get_alias_set (&xx);
get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51
51        if (t != NULL
52            && TREE_TYPE (t).z != 1
43        return x;
53            && TREE_TYPE (t).z != 2
43        return x;
54            && TREE_TYPE (t).z != 3)
43        return x;
main () at step-and-next-inline.cc:65
65        return 0;
...
and with clang-10, I have instead:
...
64        get_alias_set (&xx);
get_alias_set (t=0x601034 <xx>) at step-and-next-inline.cc:51
51        if (t != NULL
52            && TREE_TYPE (t).z != 1
53            && TREE_TYPE (t).z != 2
54            && TREE_TYPE (t).z != 3)
51        if (t != NULL
57      }
main () at step-and-next-inline.cc:65
65        return 0;
...

The test-case tries to verify that we don't step into inlined function
tree_check (lines 40-43) (so, with the clang trace we get that right).

The test-case then tries to kfail the problems when using gcc, but this is
done in such a way that the testing still gets out of sync after a failure.
That is: the "next step 2" check that is supposed to match
"TREE_TYPE (t).z != 2" is actually matching "TREE_TYPE (t).z != 1":
...
(gdb) next^M
52            && TREE_TYPE (t).z != 1^M
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: next step 2
...

Fix this by issuing extra nexts to arrive at the required lines.

Tested on x86_64-linux, with gcc-8, gcc-9, gcc-10, gcc-11, clang-8, clang-10
and clang-12.

gdb/testsuite/ChangeLog:

2021-07-22  Tom de Vries  <tdevries@suse.de>

* gdb.cp/step-and-next-inline.cc (tree_check, get_alias_set, main):
Tag closing brace with comment.
* gdb.cp/step-and-next-inline.h: Update to keep identical with
step-and-next-inline.cc.
* gdb.cp/step-and-next-inline.exp: Issue extra next when required.

Automatic date update in version.in

[gdb/testsuite] Fix FAILs due to PR gcc/101452

When running test-case gdb.base/ptype-offsets.exp with gcc-11 (with -gdwarf-5
default) or gcc-10 with target board unix/gdb:debug_flags=-gdwarf-5 we run
into this regression:
...
 (gdb) ptype/o static_member^M
 /* offset      |    size */  type = struct static_member {^M
-                               static static_member Empty;^M
 /*      0      |       4 */    int abc;^M
 ^M
                                /* total size (bytes):    4 */^M
                              }^M
-(gdb) PASS: gdb.base/ptype-offsets.exp: ptype/o static_member
+(gdb) FAIL: gdb.base/ptype-offsets.exp: ptype/o static_member
...

This is caused by missing debug info, which I filed as gcc PR101452 - "[debug,
dwarf-5] undefined static member removed by
-feliminate-unused-debug-symbols".

It's not clear yet whether this is a bug or a feature, but work around this in
the test-cases by:
- defining the static member
- adding additional_flags=-fno-eliminate-unused-debug-types.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* lib/gdb.exp (gcc_major_version): New proc.
* gdb.base/ptype-offsets.cc: Define static member static_member::Empty.
* gdb.cp/templates.exp: Define static member using -DGCC_BUG.
* gdb.cp/m-static.exp: Add
additional_flags=-fno-eliminate-unused-debug-types.
* gdb.cp/pr-574.exp: Same.
* gdb.cp/pr9167.exp: Same.

[gdb/testsuite] Add KFAILs for gdb.ada FAILs with gcc-11

With gcc-11 we run into:
...
(gdb) print pa_ptr.all^M
That operation is not available on integers of more than 8 bytes.^M
(gdb) KFAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all (PRMS: gdb/20991)
...

This is due to PR exp/20991 - "__int128 type support".  Mark this and similar
FAILs as KFAIL.

Also mark this FAIL:
....
(gdb) print pa_ptr(3)^M
cannot subscript or call something of type `foo__packed_array_ptr'^M
(gdb) FAIL: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr(3)
...
as a KFAIL for PR ada/28115 - "Support packed array encoded as
DW_TAG_subrange_type".

Tested on x86_64-linux, with gcc-10 and gcc-11.

gdb/testsuite/ChangeLog:

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

* gdb.ada/arrayptr.exp: Add KFAILs for PR20991 and PR28115.
* gdb.ada/exprs.exp: Add KFAILs for PR20991.
* gdb.ada/packed_array_assign.exp: Same.

Automatic date update in version.in

Fix printing of non-address types when memory tagging is enabled

When the architecture supports memory tagging, we handle
pointer/reference types in a special way, so we can validate tags and
show mismatches.

Unfortunately, the currently implementation errors out when the user
prints non-address values: composite types, floats, references, member
functions and other things.

Vector registers:

 (gdb) p $v0
 Value can't be converted to integer.

Non-existent internal variables:

 (gdb) p $foo
 Value can't be converted to integer.

The same happens for complex types and printing struct/union types.

There are a few problems here.

The first one is that after print_command_1 evaluates the expression
to print, the tag validation code call value_as_address
unconditionally, without making sure we have have a suitable type
where it makes to sense to call it.  That results in value_as_address
(if it isn't given a pointer-like type) trying to treat the value as
an integer and convert it to an address, which #1 - doesn't make sense
(i.e., no sense in validating tags after "print 1"), and throws for
non-integer-convertible types.  We fix this by making sure we have a
pointer or reference type first, and only if so then proceed to check
if the address-like value has tags.

The second is that we're calling value_as_address even if we have an
optimized out or unavailable value, which throws, because the value's
contents aren't fully accessible/readable.  This error currently
escapes out and aborts the print.  This case is fixed by checking for
optimized out / unavailable explicitly.

Third, the tag checking process does not gracefully handle exceptions.
If any exception is thrown from the tag validation code, we abort the
print.  E.g., the target may fail to access tags via a running thread.
Or the needed /proc files aren't available.  Or some other untold
reason.  This is a bit too rigid.  This commit changes print_command_1
to catch errors, print them, and still continue with the normal
expression printing path instead of erroring out and printing nothing
useful.

With this patch, printing works correctly again:

 (gdb) p $v0
 $1 = {d = {f = {2.0546950501119882e-81, 2.0546950501119882e-81}, u = {3399988123389603631, 3399988123389603631}, s = {
       3399988123389603631, 3399988123389603631}}, s = {f = {1.59329203e-10, 1.59329203e-10, 1.59329203e-10, 1.59329203e-10}, u = {
       791621423, 791621423, 791621423, 791621423}, s = {791621423, 791621423, 791621423, 791621423}}, h = {bf = {1.592e-10,
       1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10}, f = {0.11224, 0.11224, 0.11224, 0.11224, 0.11224,
       0.11224, 0.11224, 0.11224}, u = {12079, 12079, 12079, 12079, 12079, 12079, 12079, 12079}, s = {12079, 12079, 12079, 12079,
       12079, 12079, 12079, 12079}}, b = {u = {47 <repeats 16 times>}, s = {47 <repeats 16 times>}}, q = {u = {
       62718710765820030520700417840365121327}, s = {62718710765820030520700417840365121327}}}
 (gdb) p $foo
 $2 = void
 (gdb) p 2 + 2i
 $3 = 2 + 2i

gdb/ChangeLog

2021-07-20  Luis Machado  <luis.machado@linaro.org>
    Pedro Alves  <pedro@palves.net>

PR gdb/28110
* gdbarch.sh: Updated documentation for gdbarch_tagged_address_p.
* gdbarch.h: Regenerate.
* printcmd.c (should_validate_memtags): Reorder comparisons and only
validate tags for pointer and reference types.  Skip validation of
optimized out or unavailable values.
(print_command_1): Guard call memory tagging validation code with
a try/catch block.

Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: I82bf00ac88d23553b3f7563c9872dfa6ca1f2207

Automatic date update in version.in

Avoid expression parsing crash with unknown language

PR gdb/28093 points out that gdb crashes when language is set to
"unknown" and expression parsing is attempted.  At first I thought
this was a regression due to the expression rewrite, but it turns out
that older versions crash as well.

This patch avoids the crash by changing the default expression parser
to throw an exception.  I think this is preferable -- the current
behavior of silently doing nothing does not really make sense.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28093
(cherry picked from commit dcd482c1b756d9da2130552a6eb58b852d6efb97)

gdb/ChangeLog
2021-07-19  Tom Tromey  <tromey@adacore.com>

PR gdb/28093
* language.c (auto_or_unknown_language::parser): Call error.

gdb/testsuite/ChangeLog
2021-07-19  Tom Tromey  <tromey@adacore.com>

PR gdb/28093
* gdb.base/langs.exp: Add tests.

Automatic date update in version.in

Automatic date update in version.in

Add basic Z80 CPU support

Supported ISAs:
- Z80 (all undocumented instructions)
- Z180
- eZ80 (Z80 mode only)

Datasheets:
Z80: https://www.zilog.com/manage_directlink.php?filepath=docs/z80/um0080&extn=.pdf
Z180: https://www.zilog.com/manage_directlink.php?filepath=docs/z180/ps0140&extn=.pdf
eZ80: http://www.zilog.com/force_download.php?filepath=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTlWVFRBd056Y3VjR1Jt

To debug Z80 programs using GDB you must configure and embed
z80-stub.c to your program (SDCC compiler is required). Or
you may use some simulator with GDB support.

gdb/ChangeLog:

* Makefile.in (ALL_TARGET_OBS): Add z80-tdep.c.
* NEWS: Mention z80 support.
* configure.tgt: Handle z80*.
* features/Makefile (XMLTOC): Add z80.xml.
* features/z80-cpu.xml: New.
* features/z80.c: Generate.
* features/z80.xml: New.
* z80-tdep.c: New file.
* z80-tdep.h: New file.

gdb/stubs/ChangeLog:

* z80-stub.c: New file.

Change-Id: Id0b7a6e210c3f93c6853c5e3031b7bcee47d0db9

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[gdb/testsuite] Fix gdb.base/gold-gdb-index.exp

When running test-case gdb.base/gold-gdb-index.exp on openSUSE Tumbleweed,
I run into:
...
FAIL: gdb.base/gold-gdb-index.exp: maint info symtabs
...

This is due to a dummy .gdb_index:
...
Contents of the .gdb_index section:

Version 7

CU table:

TU table:

Address table:

Symbol table:
...

The dummy .gdb_index is ignored when loading the symbols, and instead partial
symbols are used.  Consequently, we get the same result as if we'd removed
-Wl,--gdb-index from the compilation.

Presumably, gold fails to generate a proper .gdb_index because it lacks
DWARF5 support.

Anyway, without a proper .gdb_index we can't test the gdb behaviour we're
trying to excercise.  Fix this by detecting whether we actually used a
.gdb_index for symbol loading.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* lib/gdb.exp (have_index): New proc.
* gdb.base/gold-gdb-index.exp: Use have_index.

Automatic date update in version.in

Use /bin/sh as shebang in gdb/make-init-c

While testing the NixOS[1] packaging for gdb-11.0.90.tar.xz, I got the
following error:

  [...]
  CXX    aarch32-tdep.o
  CXX    gdb.o
  GEN    init.c
  /nix/store/26a78ync552m8j4sbjavhvkmnqir8c9y-bash-4.4-p23/bin/bash: ./make-init-c: /usr/bin/env: bad interpreter: No such file or directory
  make[2]: *** [Makefile:1866: stamp-init] Error 126
  make[2]: *** Waiting for unfinished jobs....
  make[2]: Leaving directory '/build/gdb-11.0.90/gdb'
  make[1]: *** [Makefile:9814: all-gdb] Error 2
  make[1]: Leaving directory '/build/gdb-11.0.90'
  make: *** [Makefile:903: all] Error 2
  builder for '/nix/store/xs8my3rrc3l4kdlbpx0azh6q0v0jxphr-gdb-gdb-11.0.90.drv' failed with exit code 2
  error: build of '/nix/store/xs8my3rrc3l4kdlbpx0azh6q0v0jxphr-gdb-gdb-11.0.90.drv' failed

In the nix build environment, /usr/bin/env is not present, only /bin/sh
is.  This patch makes sure that gdb/make-init-c uses '/bin/sh' as
interpreter as this is the only one available on this platform.

I do not think this change will cause regressions on any other
configuration.

[1] https://nixos.org/

gdb/Changelog

* make-init-c: Use /bin/sh as shebang.

Avoid letting exceptions escape gdb_bfd_iovec_fileio_close (PR gdb/28080)

Before PR gdb/28080 was fixed by the previous patch, GDB was crashing
like this:

 (gdb) detach
 Detaching from program: target:/any/program, process 3671843
 Detaching from process 3671843
 Ending remote debugging.
 [Inferior 1 (process 3671843) detached]
 In main
 terminate called after throwing an instance of 'gdb_exception_error'
 Aborted (core dumped)

Here's the exception above being thrown:

 (top-gdb) bt
 #0  throw_error (error=TARGET_CLOSE_ERROR, fmt=0x555556035588 "Remote connection closed") at src/gdbsupport/common-exceptions.cc:222
 #1  0x0000555555bbaa46 in remote_target::readchar (this=0x555556a11040, timeout=10000) at src/gdb/remote.c:9440
 #2  0x0000555555bbb9e5 in remote_target::getpkt_or_notif_sane_1 (this=0x555556a11040, buf=0x555556a11058, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9928
 #3  0x0000555555bbbda9 in remote_target::getpkt_sane (this=0x555556a11040, buf=0x555556a11058, forever=0) at src/gdb/remote.c:10030
 #4  0x0000555555bc0e75 in remote_target::remote_hostio_send_command (this=0x555556a11040, command_bytes=13, which_packet=14, remote_errno=0x7fffffffcfd0, attachment=0x0, attachment_len=0x0) at src/gdb/remote.c:12137
 #5  0x0000555555bc1b6c in remote_target::remote_hostio_close (this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12455
 #6  0x0000555555bc1bb4 in remote_target::fileio_close (During symbol reading: .debug_line address at offset 0x64f417 is 0 [in module build/gdb/gdb]
 this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12462
 #7  0x0000555555c9274c in target_fileio_close (fd=3, target_errno=0x7fffffffcfd0) at src/gdb/target.c:3365
 #8  0x000055555595a19d in gdb_bfd_iovec_fileio_close (abfd=0x555556b9f8a0, stream=0x555556b11530) at src/gdb/gdb_bfd.c:439
 #9  0x0000555555e09e3f in opncls_bclose (abfd=0x555556b9f8a0) at src/bfd/opncls.c:599
 #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556b9f8a0) at src/bfd/opncls.c:847
 #11 0x0000555555e0a27a in bfd_close (abfd=0x555556b9f8a0) at src/bfd/opncls.c:814
 #12 0x000055555595a9d3 in gdb_bfd_close_or_warn (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:626
 #13 0x000055555595ad29 in gdb_bfd_unref (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:715
 #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573
 #15 0x0000555555ae955a in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:377
 #16 0x000055555572b7c8 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
 #17 0x00005555557263c3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x555556bf0588, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:730
 #18 0x0000555555ae745e in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
 #19 0x0000555555ae747e in std::shared_ptr<objfile>::~shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr.h:103
 #20 0x0000555555b1c1dc in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x5555564cdd60, __p=0x555556bf0580) at /usr/include/c++/9/ext/new_allocator.h:153
 #21 0x0000555555b1bb1d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556bf0580) at /usr/include/c++/9/bits/alloc_traits.h:497
 #22 0x0000555555b1b73e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/stl_list.h:1921
 #23 0x0000555555b1afeb in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/list.tcc:158
 #24 0x0000555555b19576 in program_space::remove_objfile (this=0x5555564cdd20, objfile=0x555556515540) at src/gdb/progspace.c:210
 #25 0x0000555555ae4502 in objfile::unlink (this=0x555556515540) at src/gdb/objfiles.c:487
 #26 0x0000555555ae5a12 in objfile_purge_solibs () at src/gdb/objfiles.c:875
 #27 0x0000555555c09686 in no_shared_libraries (ignored=0x0, from_tty=1) at src/gdb/solib.c:1236
 #28 0x00005555559e3f5f in detach_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:2769

Note frame #14:

 #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573

That's a dtor, thus noexcept.  That's the reason for the
std::terminate.

The previous patch fixed things such that the exception above isn't
thrown anymore.  However, it's possible that e.g., the remote
connection drops just while a user types "nosharedlibrary", or some
other reason that leads to objfile::~objfile, and then we end up the
same std::terminate problem.

Also notice that frames #9-#11 are BFD frames:

 #9  0x0000555555e09e3f in opncls_bclose (abfd=0x555556bc27e0) at src/bfd/opncls.c:599
 #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556bc27e0) at src/bfd/opncls.c:847
 #11 0x0000555555e0a27a in bfd_close (abfd=0x555556bc27e0) at src/bfd/opncls.c:814

BFD is written in C and thus throwing exceptions over such frames may
either not clean up properly, or, may abort if bfd is not compiled
with -fasynchronous-unwind-tables (x86-64 defaults that on, but not
all GCC ports do).

Thus frame #8 seems like a good place to swallow exceptions.  More so
since in this spot we already ignore target_fileio_close return
errors.  That's what this commit does.  Without the previous fix, we'd
see:

 (gdb) detach
 Detaching from program: target:/any/program, process 2197701
 Ending remote debugging.
 [Inferior 1 (process 2197701) detached]
 warning: cannot close "target:/lib64/ld-linux-x86-64.so.2": Remote connection closed

Note it prints a warning, which would still be a regression compared
to GDB 10, if it weren't for the previous fix.

gdb/ChangeLog:
yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

PR gdb/28080
* gdb_bfd.c (gdb_bfd_close_warning): New.
(gdb_bfd_iovec_fileio_close): Wrap target_fileio_close in
try/catch and print warning on exception.
(gdb_bfd_close_or_warn): Use gdb_bfd_close_warning.

Change-Id: Ic7a26ddba0a4444e3377b0e7c1c89934a84545d7

Fix detach with target remote (PR gdb/28080)

Commit 408f66864a1a823591b26420410c982174c239a2 ("detach in all-stop
with threads running") regressed "detach" with "target remote":

 (gdb) detach
 Detaching from program: target:/any/program, process 3671843
 Detaching from process 3671843
 Ending remote debugging.
 [Inferior 1 (process 3671843) detached]
 In main
 terminate called after throwing an instance of 'gdb_exception_error'
 Aborted (core dumped)

Here's the exception above being thrown:

 (top-gdb) bt
 #0  throw_error (error=TARGET_CLOSE_ERROR, fmt=0x555556035588 "Remote connection closed") at src/gdbsupport/common-exceptions.cc:222
 #1  0x0000555555bbaa46 in remote_target::readchar (this=0x555556a11040, timeout=10000) at src/gdb/remote.c:9440
 #2  0x0000555555bbb9e5 in remote_target::getpkt_or_notif_sane_1 (this=0x555556a11040, buf=0x555556a11058, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9928
 #3  0x0000555555bbbda9 in remote_target::getpkt_sane (this=0x555556a11040, buf=0x555556a11058, forever=0) at src/gdb/remote.c:10030
 #4  0x0000555555bc0e75 in remote_target::remote_hostio_send_command (this=0x555556a11040, command_bytes=13, which_packet=14, remote_errno=0x7fffffffcfd0, attachment=0x0, attachment_len=0x0) at src/gdb/remote.c:12137
 #5  0x0000555555bc1b6c in remote_target::remote_hostio_close (this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12455
 #6  0x0000555555bc1bb4 in remote_target::fileio_close (During symbol reading: .debug_line address at offset 0x64f417 is 0 [in module build/gdb/gdb]
 this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12462
 #7  0x0000555555c9274c in target_fileio_close (fd=3, target_errno=0x7fffffffcfd0) at src/gdb/target.c:3365
 #8  0x000055555595a19d in gdb_bfd_iovec_fileio_close (abfd=0x555556b9f8a0, stream=0x555556b11530) at src/gdb/gdb_bfd.c:439
 #9  0x0000555555e09e3f in opncls_bclose (abfd=0x555556b9f8a0) at src/bfd/opncls.c:599
 #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556b9f8a0) at src/bfd/opncls.c:847
 #11 0x0000555555e0a27a in bfd_close (abfd=0x555556b9f8a0) at src/bfd/opncls.c:814
 #12 0x000055555595a9d3 in gdb_bfd_close_or_warn (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:626
 #13 0x000055555595ad29 in gdb_bfd_unref (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:715
 #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573
 #15 0x0000555555ae955a in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:377
 #16 0x000055555572b7c8 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
 #17 0x00005555557263c3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x555556bf0588, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:730
 #18 0x0000555555ae745e in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
 #19 0x0000555555ae747e in std::shared_ptr<objfile>::~shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr.h:103
 #20 0x0000555555b1c1dc in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x5555564cdd60, __p=0x555556bf0580) at /usr/include/c++/9/ext/new_allocator.h:153
 #21 0x0000555555b1bb1d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556bf0580) at /usr/include/c++/9/bits/alloc_traits.h:497
 #22 0x0000555555b1b73e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/stl_list.h:1921
 #23 0x0000555555b1afeb in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/list.tcc:158
 #24 0x0000555555b19576 in program_space::remove_objfile (this=0x5555564cdd20, objfile=0x555556515540) at src/gdb/progspace.c:210
 #25 0x0000555555ae4502 in objfile::unlink (this=0x555556515540) at src/gdb/objfiles.c:487
 #26 0x0000555555ae5a12 in objfile_purge_solibs () at src/gdb/objfiles.c:875
 #27 0x0000555555c09686 in no_shared_libraries (ignored=0x0, from_tty=1) at src/gdb/solib.c:1236
 #28 0x00005555559e3f5f in detach_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:2769

So frame #28 already detached the remote process, and then we're
purging the shared libraries.  GDB had opened remote shared libraries
via the target: sysroot, so it tries closing them.  GDBserver is
tearing down already, so remote communication breaks down and we close
the remote target and throw TARGET_CLOSE_ERROR.

Note frame #14:

 #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573

That's a dtor, thus noexcept.  That's the reason for the
std::terminate.

Stepping back a bit, why do we still have open remote files if we've
managed to detach already, and, we're debugging with "target remote"?
The reason is that commit 408f66864a1a823591b26420410c982174c239a2
makes detach_command hold a reference to the target, so the remote
target won't be finally closed until frame #28 returns.  It's closing
the target that invalidates target file I/O handles.

This commit fixes the issue by not relying on target_close to
invalidate the target file I/O handles, instead invalidate them
immediately in remote_unpush_target.  So when GDB purges the solibs,
and we end up in target_fileio_close (frame #7 above), there's nothing
to do, and we don't try to talk with the remote target anymore.

The regression isn't seen when testing with
--target_board=native-gdbserver, because that does "set sysroot" to
disable the "target:" sysroot, for test run speed reasons.  So this
commit adds a testcase that explicitly tests detach with "set sysroot
target:".

gdb/ChangeLog:
yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

PR gdb/28080
* remote.c (remote_unpush_target): Invalidate file I/O target
handles.
* target.c (fileio_handles_invalidate_target): Make extern.
* target.h (fileio_handles_invalidate_target): Declare.

gdb/testsuite/ChangeLog:
yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

PR gdb/28080
* gdb.base/detach-sysroot-target.exp: New.
* gdb.base/detach-sysroot-target.c: New.

Reported-By: Jonah Graham <jonah@kichwacoders.com>
Change-Id: I851234910172f42a1b30e731161376c344d2727d

[gdb/testsuite] Fix check-libthread-db.exp FAILs with glibc 2.33

When running test-case gdb.threads/check-libthread-db.exp on openSUSE
Tumbleweed with glibc 2.33, I get:
...
(gdb) maint check libthread-db^M
Running libthread_db integrity checks:^M
  Got thread 0x7ffff7c79b80 => 9354 => 0x7ffff7c79b80; errno = 0 ... OK^M
libthread_db integrity checks passed.^M
(gdb) FAIL: gdb.threads/check-libthread-db.exp: user-initiated check: \
  libpthread.so not initialized (pattern 2)
...

The test-case expects instead:
...
  Got thread 0x0 => 9354 => 0x0 ... OK^M
...
which is what I get on openSUSE Leap 15.2 with glibc 2.26, and what is
described in the test-case like this:
...
    # libthread_db should fake a single thread with th_unique == NULL.
...

Using a breakpoint on check_thread_db_callback we can compare the two
scenarios, and find that in the latter case we hit this code in glibc function
iterate_thread_list in nptl_db/td_ta_thr_iter.c:
...
  if (next == 0 && fake_empty)
    {
      /* __pthread_initialize_minimal has not run.  There is just the main
         thread to return.  We cannot rely on its thread register.  They
         sometimes contain garbage that would confuse us, left by the
         kernel at exec.  So if it looks like initialization is incomplete,
         we only fake a special descriptor for the initial thread.  */
      td_thrhandle_t th = { ta, 0 };
      return callback (&th, cbdata_p) != 0 ? TD_DBERR : TD_OK;
    }
...
while in the former case we don't because this preceding statement doesn't
result in next == 0:
...
  err = DB_GET_FIELD (next, ta, head, list_t, next, 0);
...

Note that the comment mentions __pthread_initialize_minimal, but in both cases
it has already run before we hit the callback, so it's possible the comment is
no longer accurate.

The change in behaviour bisect to glibc commit 1daccf403b "nptl: Move stack
list variables into _rtld_global", which moves the initialization of stack
list variables such as __stack_user to an earlier moment, which explains well
enough the observed difference.

Fix this by updating the regexp patterns to agree with what libthread-db is
telling us.

Tested on x86_64-linux, both with glibc 2.33 and 2.26.

gdb/testsuite/ChangeLog:

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

PR testsuite/27690
* gdb.threads/check-libthread-db.exp: Update patterns for glibc 2.33.

gdb: disable commit-resumed on -exec-interrupt --thread-group

As reported in PR gdb/28077, we hit an internal error when using
-exec-interrupt with --thread-group:

    info threads
    &"info threads\n"
    ~"  Id   Target Id             Frame \n"
    ~"* 1    process 403312 \"loop\" (running)\n"
    ^done
    (gdb)
    -exec-interrupt --thread-group i1
    ~"/home/simark/src/binutils-gdb/gdb/target.c:3768: internal-error: void target_stop(ptid_t): Assertion `!proc_target->commit_resumed_state' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? (y or n) "

This is because this code path never disables commit-resumed (a
requirement for calling target_stop, as documented in
process_stratum_target::»commit_resumed_state) before calling
target_stop.

The other 3 code paths in mi_cmd_exec_interrupt use interrupt_target_1,
which does it.  But the --thread-group code path uses its own thing
which doesn't do it.  Fix this by adding a scoped_disable_commit_resumed
in this code path.

Calling -exec-interrupt with --thread-group is apparently not tested at
the moment (which is why this bug could creep in).  Add a new test for
that.  The test runs two inferiors and tries to interrupt them with
"-exec-interrupt --thread-group X".

This will need to be merged in the gdb-11-branch, so here are ChangeLog
entries:

gdb/ChangeLog:

* mi/mi-main.c (mi_cmd_exec_interrupt): Use
scoped_disable_commit_resumed in the --thread-group case.

gdb/testsuite/ChangeLog:

* gdb.mi/interrupt-thread-group.c: New.
* gdb.mi/interrupt-thread-group.exp: New.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28077
Change-Id: I615efefcbcaf2c15d47caf5e4b9d82854b2a2fcb

Fix some dangling references to `netbsd-tdep`

These files were renamed in 1b71cfcfdc3e13a655fefa6566b5564cec044c10,
but evidentially a few dangling references were left behind. This causes
builds to fail:

    $ ./configure --target i686-netbsdelf
    $ make
    make: *** No rule to make target 'nbsd-tdep.c', needed by 'nbsd-tdep.o'.  Stop.

gdb/ChangeLog:

* sparc-tdep.h: Fix comment.
* netbsd-tdep.c (nbsd_info_proc_mappings_header): Fix comment.
(nbsd_init_abi): Fix comment.
* configure.tgt (*-*-netbsd* | *-*-knetbsd*-gnu): Fix netbsd
file name.
(alpha*-*-openbsd*): Likewise.
(sparc-*-openbsd*): Likewise.
(sparc64-*-openbsd*): Likewise.

Change-Id: I18a0873902dccadd238615577aac4e08772fa2c8

Automatic date update in version.in

[gdb/testsuite] Fix gdb.btrace/tsx.exp on system with tsx disabled in microcode

Recently I started to see this fail with trunk:
...
(gdb) record instruction-history^M
1          0x00000000004004ab <main+4>: call   0x4004b7 <test>^M
2          0x00000000004004c6 <test+15>:        mov    $0x1,%eax^M
3          0x00000000004004cb <test+20>:        ret    ^M
(gdb) FAIL: gdb.btrace/tsx.exp: speculation indication
...

This is due to an intel microcode update (1) that disables Intel TSX by default.

Fix this by updating the pattern.

Tested on x86_64-linux, with both gcc 7.5.0 and clang 12.0.1.

[1] https://www.intel.com/content/www/us/en/support/articles/000059422/processors.html

gdb/testsuite/ChangeLog:

2021-07-12  Tom de Vries  <tdevries@suse.de>

PR testsuite/28057
* gdb.btrace/tsx.exp: Add pattern for system with tsx disabled in
microcode.