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

Fix Solaris regression (PR tdep/30252)

PR tdep/30252 reports that using GDB on Solaris fails an assertion in
target_resume:

 target.c:2648: internal-error: target_resume: Assertion `inferior_ptid != null_ptid' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n)

The backtrace, after running it through c++filt, looks like:

 ----- Backtrace -----
 0xa18914 gdb_internal_backtrace_1
 /root/binutils-gdb/gdb/bt-utils.c:122
 0xa18914 gdb_internal_backtrace()
 /root/binutils-gdb/gdb/bt-utils.c:168
 0xdec834 internal_vproblem
 /root/binutils-gdb/gdb/utils.c:401
 0xdecad8 internal_verror(char const*, int, char const*, __va_list_tag*)
 /root/binutils-gdb/gdb/utils.c:481
 0xf3638c internal_error_loc(char const*, int, char const*, ...)
 /root/binutils-gdb/gdbsupport/errors.cc:58
 0xd70580 target_resume(ptid_t, int, gdb_signal)
 /root/binutils-gdb/gdb/target.c:2648
 0xc59e85 procfs_target::wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>)
 /root/binutils-gdb/gdb/procfs.c:2187
 0xcf6da7 sol_thread_target::wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>)
 /root/binutils-gdb/gdb/sol-thread.c:442
 0xd73711 target_wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>)
 /root/binutils-gdb/gdb/target.c:2586
 ...

The problem is that the procfs backend, while inside target_wait,
called target_resume without switching to the leader thread of that
resumption.

The target_resume interface is:

 /* Resume execution (or prepare for execution) of the current thread
    (INFERIOR_PTID), while optionally letting other threads of the
    current process or all processes run free.
    ...

Thus calling target_resume with inferior_ptid == null_ptid is bogus.

target_wait (which leads to procfs_target::wait on Solaris) is called
with inferior_ptid == null_ptid on entry exactly to help catch such
bogus uses.

From the backtrace, it seems that the relevant line in question is
procfs.c:2187:

2186  /* How to keep going without returning to wfi: */
2187  target_continue_no_signal (ptid);
2188  goto wait_again;

target_continue_no_signal is a small wrapper around target_resume,
which would make sense.

The fix is to not call target_resume or go via the target stack at
all.  Instead, factor out a new proc_resume function out of
procfs_target::resume, and call that.  The new function does not rely
on inferior_ptid.

I've not been able to test it myself, but Petr confirmed it fixes the
assertion failure with his test case, and Marcel Telka also confirmed
it solves the problem.

Tested-By: Petr Šumbera <petr.sumbera@oracle.com>
Tested-By: Marcel Telka <marcel@telka.sk>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30252
Change-Id: I6213c59b081d400a22e799ee621c2eff6dcafbf3

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 13.2.90.DATE-git.

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

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

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

Set GDB version number to 13.2.

This commit changes gdb/version.in to 13.2.

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 post-hook execution for remote targets

Commit b5661ff2 ("gdb: fix possible use-after-free when
executing commands") attempted to fix possible use-after-free
in case command redefines itself.

Commit 37e5833d ("gdb: fix command lookup in execute_command ()")
updated the previous fix to handle subcommands as well by using the
original command string to lookup the command again after its execution.

This fixed the test in gdb.base/define.exp but it turned out that it
does not work (at least) for "target remote" and "target extended-remote".

The problem is that the command buffer P passed to execute_command ()
gets overwritten in dont_repeat () while executing "target remote"
command itself:

#0  dont_repeat () at top.c:822
#1  0x000055555730982a in target_preopen (from_tty=1) at target.c:2483
#2  0x000055555711e911 in remote_target::open_1 (name=0x55555881c7fe ":1234", from_tty=1, extended_p=0)
    at remote.c:5946
#3  0x000055555711d577 in remote_target::open (name=0x55555881c7fe ":1234", from_tty=1) at remote.c:5272
#4  0x00005555573062f2 in open_target (args=0x55555881c7fe ":1234", from_tty=1, command=0x5555589d0490)
    at target.c:853
#5  0x0000555556ad22fa in cmd_func (cmd=0x5555589d0490, args=0x55555881c7fe ":1234", from_tty=1)
    at cli/cli-decode.c:2737
#6  0x00005555573487fd in execute_command (p=0x55555881c802 "4", from_tty=1) at top.c:688

Therefore the second call to lookup_cmd () at line 697 fails to find
command because the original command string is gone.

This commit addresses this particular problem by creating a *copy* of
original command string for the sole purpose of using it after command
execution to lookup the command again. It may not be the most efficient
way but it's safer given that command buffer is shared and overwritten
in hard-to-foresee situations.

Tested on x86_64-linux.

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

Approved-By: Tom Tromey <tom@tromey.com>
(cherry picked from commit b69378ced6a2db6adfbea9974a246a65d931bab2)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdbserver/linux-low.cc: Fix a typo in ternary operator

Signed-off-by: Khem Raj <raj.khem@gmail.com>
(cherry picked from commit 2e977d9901393ea1bacbe1896af0929e968bc811)
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30450

Automatic date update in version.in