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

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

Fix build on rhES5

The rhES5 build failed due to an upstream import a while back.  The
bug here is that, while the 'personality' function exists,
ADDR_NO_RANDOMIZE is only defined in <linux/personality.h>, not
<sys/personality.h>.

However, <linux/personality.h> does not declare the 'personality'
function, and <sys/personality.h> and <linux/personality.h> cannot
both be included.

This patch restores one of the removed configure checks and updates
the code to check it.

We had this as a local patch at AdaCore, because it seemed like there
was no interest upstream.  However, now it turns out that this fixes
PR build/28555, so I'm sending it now.

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

[AArch64] Make gdbserver register set selection dynamic

The current register set selection mechanism for AArch64 is static, based
on a pre-populated array of register sets.

This means that we might potentially probe register sets that are not
available. This is OK if the kernel errors out during ptrace, but probing the
tag_ctl register, for example, does not result in a ptrace error if the kernel
supports the tagged address ABI but not MTE (PR 28355).

Making the register set selection dynamic, based on feature checks, solves
this and simplifies the code a bit. It allows us to list all of the register
sets only once, and pick and choose based on HWCAP/HWCAP2 or other properties.

gdb/ChangeLog:

2021-11-03  Luis Machado  <luis.machado@linaro.org>

PR gdb/28355

* arch/aarch64.h (struct aarch64_features): New struct.

gdbserver/ChangeLog:

2021-11-03  Luis Machado  <luis.machado@linaro.org>

PR gdb/28355

* linux-aarch64-low.cc (is_sve_tdesc): Remove.
(aarch64_target::low_arch_setup): Rework to adjust the register sets.
(aarch64_regsets): Update to list all register sets.
(aarch64_regsets_info, regs_info_aarch64): Replace NULL with nullptr.
(aarch64_sve_regsets, aarch64_sve_regsets_info)
(regs_info_aarch64_sve): Remove.
(aarch64_adjust_register_sets): New.
(aarch64_target::get_regs_info): Remove references to removed structs.
(initialize_low_arch): Likewise.

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

Automatic date update in version.in

Automatic date update in version.in

[gdb/tui] Fix breakpoint display functionality

In commit 81e6b8eb208 "Make tui-winsource not use breakpoint_chain", a loop
body was transformed into a lambda function body:
...
-      for (bp = breakpoint_chain;
-           bp != NULL;
-           bp = bp->next)
+      iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
...
and consequently:
- a continue was replaced by a return, and
- a final return was added.

Then in commit 240edef62f0 "gdb: remove iterate_over_breakpoints function", we
transformed back to a loop body:
...
-      iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
+      for (breakpoint *bp : all_breakpoints ())
...
but without reverting the changes that introduced the two returns.

Consequently, breakpoints no longer show up in the tui source window.

Fix this by reverting the changes that introduced the two returns.

Build on x86_64-linux, tested with all .exp test-cases that contain
tuiterm_env.

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

gdb/ChangeLog:

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

PR tui/28483
* tui/tui-winsource.c (tui_source_window_base::update_breakpoint_info):
Fix returns in loop body.

gdb/testsuite/ChangeLog:

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

PR tui/28483
* gdb.tui/break.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

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/build] Add CXX_DIALECT to CXX

Say we use a gcc version that (while supporting c++11) does not support c++11
by default, and needs an -std setting to enable it.

If gdb would use the default AX_CXX_COMPILE_STDCXX from autoconf-archive, then
we'd have:
...
CXX="g++ -std=gnu++11"
...

That mechanism however has the following problem (quoting from commit
0bcda685399):
...
the top level Makefile passes CXX down to subdirs, and that overrides whatever
gdb/Makefile may set CXX to.  The result would be that a make invocation from
the build/gdb/ directory would use "g++ -std=gnu++11" as expected, while a
make invocation at the top level would not.
...

Commit 0bcda685399 fixes this by using a custom AX_CXX_COMPILE_STDCXX which
does:
...
CXX=g++
CXX_DIALECT=-std=gnu++11
...

The problem reported in PR28318 is that using the custom instead of the
default AX_CXX_COMPILE_STDCXX makes the configure test for std::thread
support fail.

We could simply add $CXX_DIALECT to the test for std::thread support, but
that would have to be repeated for each added c++ support test.

Instead, fix this by doing:
...
CXX="g++ -std=gnu++11"
CXX_DIALECT=-std=gnu++11
...

This is somewhat awkward, since it results in -std=gnu++11 occuring twice in
some situations:
...
$ touch src/gdb/dwarf2/read.c
$ ( cd build/gdb; make V=1 dwarf2/read.o )
g++-4.8 -std=gnu++11 -x c++ -std=gnu++11 ...
...

However, both settings are needed:
 - the switch in CXX for the std::thread tests (and other tests)
 - the switch in CXX_DIALECT so it can be appended in Makefiles, to
   counteract the fact that the top-level Makefile overrides CXX

The code added in gdb/ax_cxx_compile_stdcxx.m4 is copied from the default
AX_CXX_COMPILE_STDCXX from autoconf-archive.

Tested on x86_64-linux.

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

gdb/ChangeLog:

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

PR build/28318
* ax_cxx_compile_stdcxx.m4: Add CXX_DIALECT to CXX.
* configure: Regenerate.

gdbserver/ChangeLog:

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

PR build/28318
* configure: Regenerate.

gdbsupport/ChangeLog:

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

PR build/28318
* configure: Regenerate.

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

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.