gdb: fix vfork with multiple threads

There is a problem with how a vfork happening in a multi-threaded
program is handled by GDB today.

When a program vforks, the parent thread is suspended by the kernel
until the child process exits or execs.  Specifically, in a
multi-threaded program, only the thread that called vfork is suspended,
other threads keep running freely. This is documented in the vfork man
page.

Let's suppose GDB is handling a vfork and the user's desire is to detach
from the child. Before detaching the child, GDB must remove the software
breakpoints inserted in the shared parent/child address space, in case
there's a breakpoint in the path the child is going to take (unlikely,
but possible). Otherwise the child could hit a breakpoint instruction
while running outside the control of GDB, which would make it crash. GDB
must also avoid re-inserting breakpoints in the parent as long as it
didn't receive the "vfork done" event (that is, when the child has
exited or execed): since the address space is shared with the child,
that would re-insert breakpoints in the child's process also. So what GDB
does is:

  1. Receive "vfork" event for the parent
  2. Remove breakpoints from address space
  3. Detach from the child thread
  4. Resume the parent
  5. Wait for and receive "vfork done" event for the parent
  6. Re-insert breakpoints
  7. Resume the parent

Step 4 is necessary in order for the kernel to generate the "vfork done"
event.  The kernel won't generate ptrace events for threads that are
ptrace-stopped.  But the theory behind this is that between steps 4 and 5,
the parent won't actually do any progress, because the kernel keeps it
suspended, waiting for the child to exit or exec, so it doesn't matter
if breakpoints are not inserted.

Now, the problem is when the program is multi-threaded. In step 4, GDB
resumes all threads of the parent. The thread that did the vfork stays
suspended, so that's fine. But other threads are running freely while
breakpoints are removed, which is a problem because they could miss a
breakpoint that they should have hit.

The problem is present with all-stop and non-stop targets.  The only
difference is that with an all-stop targets, the other threads are
stopped when the target reports the vfork event, and are resumed when
resuming the parent.  With a non-stop target, the other threads are
simply never stopped.

With all-stop targets, GDB should therefore only resume the thread that
has called vfork.  This thread won't make progress but will be able to
receive the vfork-done event.  With non-stop targets, GDB should
actively stop the other threads before removing the breakpoints.  This
has similarities with how in-line steps are done.

FIXME: finish commit message

 - When a vfork happens and the child is detached (is out of control of
   GDB), only the thread that called vfork is resumed, waiting for
   vfork-done
 - When a vfork happens and the child is in control of GDB (an inferior
   was created for it), only resume it, waiting for it to exec or
   exit.

Change-Id: Iec4dc8dbebabcee8061dcaad53c3e72a4092ebe5

gdb: test vfork + follow parent + detach-on-fork off

The particular behavior we have when using that combination of
settings doesn't seem tested at all (at least, I don't find it if I grep
for "Can not resume the parent process").  At a simple test for that.

Change-Id: Ib9454a615abba661b42f1b15056df73ed1bcd4c5

gdb, gdbserver: detach fork child when detaching from fork parent

FIXME: we should make target_ops::detach take a pid, not an inferior,
and have the core detach fork childs of pending events (stored in
thread_info's pending waitstatus).

While working with pending fork events, I wondered what would happen if
the user detached an inferior while a thread of that inferior had a
pending fork event.  What happens with the fork child, which is
ptrace-attached by the GDB process (or by GDBserver if using that), but
with the core of GDB not knowing about it.  Sure enough, neither the
core of GDB or the target detach the child process, so GDB (or
GDBserver) just stays ptrace-attached to the process.  The result is
that the fork child process is stuck, while you would expect it to be
detached and run.

I don't think there is anything the core of GDB can do
here, it's up to each target to detach a fork child if detaching a
thread with a pending fork event.  This affects the Linux native target
and the remote target (and probably the other targets that support fork,
but I haven't tried them).

Update the gdb.threads/pending-fork-event.exp to try to detach the
process while a thread has a pending fork event.  In order to verify
that the fork child process is correctly detached and resumes execution
outside of GDB's control, make that process create a file in the test
output directory, and make the test wait $timeout seconds for that file
to appear (it happens instantly if everything goes well).

The test catches a bug in linux-nat.c, also reported as PR 28512
("waitstatus.h:300: internal-error: gdb_signal target_waitstatus::sig()
const: Assertion `m_kind == TARGET_WAITKIND_STOPPED || m_kind ==
TARGET_WAITKIND_SIGNALLED' failed.).  When detaching a thread with a
pending event, get_detach_signal unconditionally fetches the signal
stored in the waitstatus (`tp->pending_waitstatus ().sig ()`).  However,
that is only valid if the pending event is of type
TARGET_WAITKIND_STOPPED, and this is now enforced using assertions (iit
would also be valid for TARGET_WAITKIND_SIGNALLED, but that would mean
the thread does not exist anymore, so we wouldn't be detaching it).  Add
a condition in get_detach_signal to access the signal number only if the
wait status is of kind TARGET_WAITKIND_STOPPED, and use GDB_SIGNAL_0
instead (since the thread was not stopped with a signal to begin with).

Change-Id: I6d811a56f520e3cb92d5ea563ad38976f92e93dd

Add ptid_t::to_string (gdb-11-branch only)

Change-Id: I0c3e9d4faf1bd79c18f2f60c1c32132b8e6e6052

gdbserver: hide fork child threads from GDB

This patch aims at fixing a bug where an inferior is unexpectedly
created when a fork happens at the same time as another, and that other
is reported to GDB (and the fork event stays pending in GDBserver).
This happens for example when we step a thread and another forks at the
same time.  The bug looks like (if I reproduce the included test by
hand):

    (gdb) show detach-on-fork
    Whether gdb will detach the child of a fork is on.
    (gdb) show follow-fork-mode
    Debugger response to a program call of fork or vfork is "parent".
    (gdb) si
    [New inferior 2]
    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...
    Reading /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread from remote target...
    Reading symbols from target:/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-while-fork-in-other-thread/step-while-fork-in-other-thread...
    [New Thread 965190.965190]
    [Switching to Thread 965190.965190]
    Remote 'g' packet reply is too long (expected 560 bytes, got 816 bytes): ... <long series of bytes>

The sequence of events leading to the problem is:

 - We are using the all-stop user-visible mode as well as the
   synchronous / all-stop variant of the remote protocol
 - We have two threads, thread A that we single-step and thread B that
   calls fork at the same time
 - linux_process_target::wait pulls the "single step complete SIGTRAP"
   and the "fork" events from the kernel.  It arbitrarily choses one
   event to report, it happens to be the single-step SIGTRAP.
 - GDBserver send that SIGTRAP as a stop reply to GDB
 - While in stop_all_threads, GDB calls update_thread_list, which ends
   up querying the remote thread list using qXfer:threads:read.
 - In the reply, GDBserver includes the fork child created as a result
   of thread B's fork.
 - GDB-side, the remote target sees the new PID, calls
   remote_notice_new_inferior, which ends up unexpectedly creating a new
   inferior, and things go downhill from there.

The problem here is that as long as GDB did not process the fork event,
it should pretend the fork child does not exist.

The remote target (GDB-side), has some code to remove from the reported
thread list the threads that are the result of forks not processed by
GDB yet.  But that only works for fork events that have made their way
to the remote target (GDB-side), but haven't been consumed by the code
yet, so are still lingering as pending stop replies in the remote target
(see remove_new_fork_children in remote.c).  But in our case, the fork
event hasn't made its way to the GDB-side remote target.  We need to
implement the same kind of logic GDBserver-side: if there exists a
thread / inferior that is the result of a fork event GDBserver hasn't
reported yet, it should exclude that thread / inferior from the reported
thread list.

This was actually discussed a while ago, but not implemented AFAIK:

    https://pi.simark.ca/gdb-patches/1ad9f5a8-d00e-9a26-b0c9-3f4066af5142@redhat.com/#t
    https://sourceware.org/pipermail/gdb-patches/2016-June/133906.html

Implementation details-wise, the fix for this is all in GDBserver.  The
Linux layer of GDBserver already tracks unreported fork parent / child
relationships using the lwp_info::fork_relative, in order to avoid
wildcard actions resuming fork childs unknown to GDB.  Move this
information to the common thread_info structure, so that it can be used
in handle_qxfer_threads_worker to filter out unreported fork child
threads.  Plus, that makes it usable for other OSes that use fork if
need be.

I split the field in two (fork_parent / fork_child), I think it's
clearer this way, easier to follow which thread is the parent and which
is the child, and helps ensure things are consistent.  That simplifies
things a bit in linux_set_resume_request.  Currently, when
lwp->fork_relative is set, we have to deduce whether this is a parent or
child using the pending event.  With separate fork_parent and fork_child
fields, it becomes more obvious.  If the thread has a fork parent, then
it means it's a fork child, and vice-versa.

Testing-wise, the test replicates pretty-much the sequence of events
shown above.  The setup of the test makes it such that the main thread
is about to fork.  We stepi the other thread, so that the step completes
very quickly, in a single event.  Meanwhile, the main thread is resumed,
so very likely has time to call fork.  This means that the bug may not
reproduce every time (if the main thread does not have time to call
fork), but it will reproduce more often than not.  The test fails
without the fix applied on the native-gdbserver and
native-extended-gdbserver boards.

At some point I suspected that which thread called fork and which thread
did the step influenced the order in which the events were reported, and
therefore the reproducibility of the bug.  So I made the test try  both
combinations: main thread forks while other thread steps, and vice
versa.  I'm not sure this is still necessary, but I left it there
anyway.  It doesn't hurt to test a few more combinations.

Change-Id: I2158d5732fc7d7ca06b0eb01f88cf27bf527b990

gdbserver: initialize the members of lwp_info in-class

Add a constructor to initialize the waitstatus members.  Initialize the
others in the class directly.

Change-Id: I10f885eb33adfae86e3c97b1e135335b540d7442

gdbserver: make thread_info non-POD

Add a constructor and a destructor.  The constructor takes care of the
initialization that happened in add_thread, while the destructor takes
care of the freeing that happened in free_one_thread.  This is needed to
make target_waitstatus non-POD, as thread_info contains a member of that
type.

Change-Id: I1db321b4de9dd233ede0d5c101950f1d6f1d13b7

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.

[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