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

Bump GDB version number to 11.1.90.DATE-git.

gdb/ChangeLog:

* version.in: Set GDB version number to 11.1.90.DATE-git.

gdb/testsuite/ChangeLog:

* gdb.base/default.exp: Change $_gdb_minor to 2.

Document the GDB 11.1 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 11.1 released.

Set GDB version number to 11.1.

gdb/ChangeLog:

* version.in: Set GDB version number to 11.1.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[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