deliverable/binutils-gdb.git
2 years agoAutomatic date update in version.in
GDB Administrator [Sat, 6 Nov 2021 00:00:37 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Fri, 5 Nov 2021 00:00:45 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Thu, 4 Nov 2021 00:00:30 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years ago[AArch64] Make gdbserver register set selection dynamic
Luis Machado [Fri, 29 Oct 2021 17:54:36 +0000 (14:54 -0300)] 
[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.

2 years agoAutomatic date update in version.in
GDB Administrator [Wed, 3 Nov 2021 00:00:31 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Tue, 2 Nov 2021 00:00:34 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Mon, 1 Nov 2021 00:00:30 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sun, 31 Oct 2021 00:00:35 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sat, 30 Oct 2021 00:00:54 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Fri, 29 Oct 2021 00:00:43 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Thu, 28 Oct 2021 00:00:40 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Wed, 27 Oct 2021 00:00:32 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Tue, 26 Oct 2021 00:00:42 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Mon, 25 Oct 2021 00:00:42 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sun, 24 Oct 2021 00:00:29 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sat, 23 Oct 2021 00:00:28 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Fri, 22 Oct 2021 00:00:32 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years ago[gdb/tui] Fix breakpoint display functionality
Tom de Vries [Thu, 21 Oct 2021 22:28:14 +0000 (00:28 +0200)] 
[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.

2 years agoAutomatic date update in version.in
GDB Administrator [Thu, 21 Oct 2021 00:00:34 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Wed, 20 Oct 2021 00:00:24 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Tue, 19 Oct 2021 00:00:40 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Mon, 18 Oct 2021 00:00:26 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sun, 17 Oct 2021 00:00:30 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sat, 16 Oct 2021 00:00:26 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Fri, 15 Oct 2021 00:00:23 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Thu, 14 Oct 2021 00:00:26 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Wed, 13 Oct 2021 00:00:19 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Tue, 12 Oct 2021 00:00:27 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Mon, 11 Oct 2021 00:00:30 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sun, 10 Oct 2021 00:00:32 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sat, 9 Oct 2021 00:00:32 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Fri, 8 Oct 2021 00:00:25 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Thu, 7 Oct 2021 00:00:20 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Wed, 6 Oct 2021 00:00:25 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Tue, 5 Oct 2021 00:00:20 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years ago[gdb/build] Add CXX_DIALECT to CXX
Tom de Vries [Mon, 4 Oct 2021 16:56:42 +0000 (18:56 +0200)] 
[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.

2 years agoAutomatic date update in version.in
GDB Administrator [Mon, 4 Oct 2021 00:00:21 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sun, 3 Oct 2021 00:00:26 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sat, 2 Oct 2021 00:00:24 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Fri, 1 Oct 2021 00:00:26 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Thu, 30 Sep 2021 00:00:21 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Wed, 29 Sep 2021 00:00:28 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Tue, 28 Sep 2021 00:00:19 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Mon, 27 Sep 2021 00:00:21 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sun, 26 Sep 2021 00:00:17 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sat, 25 Sep 2021 00:00:34 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Fri, 24 Sep 2021 00:00:26 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Thu, 23 Sep 2021 00:00:20 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Wed, 22 Sep 2021 00:00:21 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Tue, 21 Sep 2021 00:00:28 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Mon, 20 Sep 2021 00:00:29 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sun, 19 Sep 2021 00:00:32 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sat, 18 Sep 2021 00:00:19 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Fri, 17 Sep 2021 00:00:20 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Thu, 16 Sep 2021 00:00:36 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Wed, 15 Sep 2021 00:00:20 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Tue, 14 Sep 2021 00:00:31 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoBump GDB version number to 11.1.90.DATE-git.
Joel Brobecker [Mon, 13 Sep 2021 01:54:34 +0000 (18:54 -0700)] 
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.

2 years agoDocument the GDB 11.1 release in gdb/ChangeLog
Joel Brobecker [Mon, 13 Sep 2021 01:41:19 +0000 (18:41 -0700)] 
Document the GDB 11.1 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 11.1 released.

2 years agoSet GDB version number to 11.1.
Joel Brobecker [Mon, 13 Sep 2021 01:32:10 +0000 (18:32 -0700)] 
Set GDB version number to 11.1.

gdb/ChangeLog:

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

2 years agoAutomatic date update in version.in
GDB Administrator [Mon, 13 Sep 2021 00:00:33 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sun, 12 Sep 2021 00:00:16 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sat, 11 Sep 2021 00:00:19 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years ago[gdb/testsuite] Handle unrecognized command line option in gdb_compile_test
Tom de Vries [Fri, 10 Sep 2021 16:36:36 +0000 (18:36 +0200)] 
[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.

2 years agoAutomatic date update in version.in
GDB Administrator [Fri, 10 Sep 2021 00:00:19 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAdd ChangeLog entry for previous patch
Tom Tromey [Thu, 9 Sep 2021 15:53:16 +0000 (09:53 -0600)] 
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.

2 years ago[gdb/testsuite] Fix gdb.base/coredump-filter-build-id.exp with older eu-unstrip
Tom de Vries [Thu, 9 Sep 2021 11:55:02 +0000 (13:55 +0200)] 
[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.

2 years ago[gdb/testsuite] Fix various issues in gdb.mi/mi-sym-info.exp
Tom de Vries [Thu, 9 Sep 2021 11:55:02 +0000 (13:55 +0200)] 
[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.

2 years agoAutomatic date update in version.in
GDB Administrator [Thu, 9 Sep 2021 00:00:21 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoFix two regressions caused by CU / TU merging
Tom Tromey [Wed, 4 Aug 2021 18:44:10 +0000 (12:44 -0600)] 
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)

2 years agoRevert: [AArch64] MTE corefile support
Luis Machado [Wed, 8 Sep 2021 11:58:44 +0000 (08:58 -0300)] 
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.

2 years agoAutomatic date update in version.in
GDB Administrator [Wed, 8 Sep 2021 00:00:27 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agofbsd-nat: Don't use '%jd' and '%ju' with printf_filtered.
John Baldwin [Mon, 30 Aug 2021 18:08:38 +0000 (11:08 -0700)] 
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.

2 years agoAutomatic date update in version.in
GDB Administrator [Tue, 7 Sep 2021 00:00:19 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Mon, 6 Sep 2021 00:00:26 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sun, 5 Sep 2021 00:00:30 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years ago[gdb/testsuite] Check avx support in gdb.arch/amd64-disp-step-avx.exp
Tom de Vries [Sat, 4 Sep 2021 10:11:35 +0000 (12:11 +0200)] 
[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.

2 years agoAutomatic date update in version.in
GDB Administrator [Sat, 4 Sep 2021 00:00:24 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years ago[gdb/testsuite] Add untested case in gdb.gdb/complaints.exp
Tom de Vries [Fri, 3 Sep 2021 15:40:10 +0000 (17:40 +0200)] 
[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.

2 years ago[gdb/testsuite] Add untested case in selftest_setup
Tom de Vries [Fri, 3 Sep 2021 13:13:14 +0000 (15:13 +0200)] 
[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.

2 years agoAutomatic date update in version.in
GDB Administrator [Fri, 3 Sep 2021 00:00:38 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Thu, 2 Sep 2021 00:00:29 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years ago[gdb/testsuite] Fix dwo path in fission-*.S
Tom de Vries [Wed, 1 Sep 2021 18:14:53 +0000 (20:14 +0200)] 
[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.

2 years ago[gdb/testsuite] Fix gdb.fortran/call-no-debug.exp symbol search
Tom de Vries [Wed, 1 Sep 2021 09:38:02 +0000 (11:38 +0200)] 
[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.

2 years agoAutomatic date update in version.in
GDB Administrator [Wed, 1 Sep 2021 00:00:25 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Tue, 31 Aug 2021 00:00:22 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years ago[gdb/cli] Don't assert on empty string for core-file
Tom de Vries [Mon, 30 Aug 2021 14:03:15 +0000 (16:03 +0200)] 
[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.

2 years agoAutomatic date update in version.in
GDB Administrator [Mon, 30 Aug 2021 00:00:17 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sun, 29 Aug 2021 00:00:20 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sat, 28 Aug 2021 00:00:22 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Fri, 27 Aug 2021 00:00:23 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Thu, 26 Aug 2021 00:00:27 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Wed, 25 Aug 2021 00:00:21 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Tue, 24 Aug 2021 00:00:23 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years ago[gdb] Fix 'not in executable format' error message
Tom de Vries [Mon, 23 Aug 2021 19:08:51 +0000 (21:08 +0200)] 
[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.

2 years agoAutomatic date update in version.in
GDB Administrator [Mon, 23 Aug 2021 00:00:18 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sun, 22 Aug 2021 00:00:22 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Sat, 21 Aug 2021 00:00:30 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Fri, 20 Aug 2021 00:00:19 +0000 (00:00 +0000)] 
Automatic date update in version.in

2 years agoAutomatic date update in version.in
GDB Administrator [Thu, 19 Aug 2021 00:00:56 +0000 (00:00 +0000)] 
Automatic date update in version.in

This page took 0.042747 seconds and 4 git commands to generate.