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

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

Fix core-file -> detach -> crash (corefiles/29275)

After loading a core file, you're supposed to be able to use "detach"
to unload the core file.  That unfortunately regressed starting with
GDB 11, with these commits:

 1192f124a308 - gdb: generalize commit_resume, avoid commit-resuming when threads have pending statuses
 408f66864a1a - detach in all-stop with threads running

resulting in a GDB crash:

 ...
 Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
 0x0000555555e842bf in maybe_set_commit_resumed_all_targets () at ../../src/gdb/infrun.c:2899
 2899          if (proc_target->commit_resumed_state)
 (top-gdb) bt
 #0  0x0000555555e842bf in maybe_set_commit_resumed_all_targets () at ../../src/gdb/infrun.c:2899
 #1  0x0000555555e848bf in scoped_disable_commit_resumed::reset (this=0x7fffffffd440) at ../../src/gdb/infrun.c:3023
 #2  0x0000555555e84a0c in scoped_disable_commit_resumed::reset_and_commit (this=0x7fffffffd440) at ../../src/gdb/infrun.c:3049
 #3  0x0000555555e739cd in detach_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:2791
 #4  0x0000555555c0ba46 in do_simple_func (args=0x0, from_tty=1, c=0x55555662a600) at ../../src/gdb/cli/cli-decode.c:95
 #5  0x0000555555c112b0 in cmd_func (cmd=0x55555662a600, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:2514
 #6  0x0000555556173b1f in execute_command (p=0x5555565c5916 "", from_tty=1) at ../../src/gdb/top.c:699

The code that crashes looks like:

 static void
 maybe_set_commit_resumed_all_targets ()
 {
   scoped_restore_current_thread restore_thread;

   for (inferior *inf : all_non_exited_inferiors ())
     {
       process_stratum_target *proc_target = inf->process_target ();

       if (proc_target->commit_resumed_state)
           ^^^^^^^^^^^

With 'proc_target' above being null.  all_non_exited_inferiors filters
out inferiors that have pid==0.  We get here at the end of
detach_command, after core_target::detach has already run, at which
point the inferior _should_ have pid==0 and no process target.  It is
clear it no longer has a process target, but, it still has a pid!=0
somehow.

The reason the inferior still has pid!=0, is that core_target::detach
just unpushes, and relies on core_target::close to actually do the
getting rid of the core and exiting the inferior.  The problem with
that is that detach_command grabs an extra strong reference to the
process stratum target, so the unpush_target inside
core_target::detach doesn't actually result in a call to
core_target::close.

Fix this my moving the cleaning up the core inferior to a shared
routine called by both core_target::close and core_target::detach.  We
still need to cleanup the inferior from within core_file::close
because there are paths to it that want to get rid of the core without
going through detach.  E.g., "core-file" -> "run".

This commit includes a new test added to gdb.base/corefile.exp to
cover the "core-file core" -> "detach" scenario.

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

Change-Id: Ic42bdd03182166b19f598428b0dbc2ce6f67c893

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

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

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's version number to 12.1.90.DATE-git.

This commit changes gdb/version.in to 12.1.90.DATE-git.

This commit also makes the following changes in gdb/testsuite:

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

Set GDB version number to 12.1.

This commit changes gdb/version.in to 12.1.

Import gnulib changes

This imports the gnulib patches that were mentioned by Eli.  I created
the patches from gnulib git, ran them through filterdiff, and then
applied them using update-gnulib.sh's patch-applying facility.

I think the patches are either obviously Windows-specific or harmless,
but I encourage you to look for yourself.

I tested by rebuilding on x86-64 Fedora 34, and also using the Fedora
mingw cross toolchain.

gdb: move setbuf calls out of gdb_readline_no_editing_callback

After this commit:

  commit d08cbc5d3203118da5583296e49273cf82378042
  Date:   Wed Dec 22 12:57:44 2021 +0000

      gdb: unbuffer all input streams when not using readline

Issues were reported with some MS-Windows hosts, see the thread
starting here:

  https://sourceware.org/pipermail/gdb-patches/2022-March/187004.html

Filed in bugzilla as: PR mi/29002

The problem seems to be that calling setbuf on terminal file handles
is not always acceptable, see this mail for more details:

  https://sourceware.org/pipermail/gdb-patches/2022-April/187310.html

This commit does two things, first moving the setbuf calls out of
gdb_readline_no_editing_callback so that we don't end up calling
setbuf so often.

Then, for MS-Windows hosts, we don't call setbuf for terminals, this
appears to resolve the issues that have been reported.

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

gdb: fix 'remote show FOO-packet' aliases

The following behaviour was observed in GDB:

  (gdb) show remote X-packet
  Support for the `p' packet is auto-detected, currently unknown.

Note the message mentions the 'p' packet.  This is a regression since
this commit:

  commit 8579fd136a614985bd27f20539c7bb7c5a51287d
  Date:   Mon Nov 8 14:58:46 2021 +0000

      gdb/gdbsupport: make xstrprintf and xstrvprintf return a unique_ptr

Before this commit the behaviour was:

  (gdb) show remote X-packet
  Support for the `X' packet is auto-detected, currently unknown.

The problem was caused by a failed attempt to ensure that some
allocated strings were deleted when GDB exits.  The code in the above
commit attempted to make use of 'static' to solve this problem,
however, the solution was just wrong.

In this new commit I instead allocate a static vector into which all
the allocated strings are stored, this ensures the strings are
released when GDB exits (which makes output from tools like valgrind
cleaner), but each string within the vector can be unique, which fixes
the regression.

[gdb/testsuite] Fix gdb.ada/float-bits.exp with -m32

With test-case gdb.ada/float-bits.exp and native we get:
...
(gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M
$9 = 5.0e+25^M
(gdb) PASS: gdb.ada/float-bits.exp: print 16llf#7FFFF7FF4054A56FA5B99019A5C8#
...
but with target board unix/-m32 we have instead:
...
(gdb) print 16llf#7FFFF7FF4054A56FA5B99019A5C8#^M
Cannot export value 2596145952482202326224873165792712 as 96-bits \
  unsigned integer (must be between 0 and 79228162514264337593543950335)^M
(gdb) FAIL: gdb.ada/float-bits.exp: print 16llf#7FFFF7FF4054A56FA5B99019A5C8#
...

Fix this by testing whether 16llf is supported by doing ptype long_long_float
which gets us either:
...
type = <16-byte float>^M
...
or:
...
type = <12-byte float>^M
...

Tested on x86_64-linux with native and unix/-m32.

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

[gdb/testsuite] Fix gdb.go/methods.exp with check-readmore

When running test-case gdb.go/methods.exp with make check we have:
...
(gdb) break main.T.Foo^M
Function "main.T.Foo" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) XFAIL: gdb.go/methods.exp: gdb_breakpoint: set breakpoint at main.T.Foo
...
but with make check-readmore the XFAIL fails to trigger:
...
(gdb) break main.T.Foo^M
Function "main.T.Foo" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.go/methods.exp: gdb_breakpoint: set breakpoint at main.T.Foo
...

This happens because this gdb_test_multiple "maintenance print symbols"
regexp:
...
    -re "\r\n$gdb_prompt $" {
...
matches the entire command output.

Fix this by adding the missing ^ at the regexp start.

Tested on x86_64-linux.

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