Automatic date update in version.in

Fix gdb/python/python.c use-after-free

Valgrind shows:

 ==26964== Invalid read of size 1
 ==26964==    at 0x6E14100: __GI_strcmp (strcmp.S:180)
 ==26964==    by 0x6DB55AA: setlocale (setlocale.c:238)
 ==26964==    by 0x4E0455: _initialize_python() (python.c:1731)
 ==26964==    by 0x786731: initialize_all_files() (init.c:319)
 ==26964==    by 0x72EF0A: gdb_init(char*) (top.c:1929)
 ==26964==    by 0x60BCAC: captured_main(void*) (main.c:863)
 ==26964==    by 0x606AD5: catch_errors(int (*)(void*), void*, char*, return_mask) (exceptions.c:234)
 ==26964==    by 0x60C608: gdb_main(captured_main_args*) (main.c:1165)
 ==26964==    by 0x40CAEC: main (gdb.c:32)
 ==26964==  Address 0x81d30a0 is 0 bytes inside a block of size 181 free'd
 ==26964==    at 0x4C29CF0: free (vg_replace_malloc.c:530)
 ==26964==    by 0x6DB5B65: setname (setlocale.c:201)
 ==26964==    by 0x6DB5B65: setlocale (setlocale.c:388)
 ==26964==    by 0x4E037F: _initialize_python() (python.c:1712)
 ==26964==    by 0x786731: initialize_all_files() (init.c:319)
 ==26964==    by 0x72EF0A: gdb_init(char*) (top.c:1929)
 ==26964==    by 0x60BCAC: captured_main(void*) (main.c:863)
 ==26964==    by 0x606AD5: catch_errors(int (*)(void*), void*, char*, return_mask) (exceptions.c:234)
 ==26964==    by 0x60C608: gdb_main(captured_main_args*) (main.c:1165)
 ==26964==    by 0x40CAEC: main (gdb.c:32)

The problem is doing this:

  oldloc = setlocale (LC_ALL, NULL);
  setlocale (LC_ALL, "");
  ...
  setlocale (LC_ALL, oldloc);

I.e., the second setlocale call frees 'oldloc'.

From http://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html :

 "The returned string pointer might be invalidated or the string
 content might be overwritten by a subsequent call to setlocale()."

gdb/ChangeLog:
2016-05-03  Pedro Alves <palves@redhat.com>

PR python/20037
* python/python.c (_initialize_python) [IS_PY3K]: xstrdup/xfree
oldloc.

Remove gdb/python/python.c code that handles strlen failing with -1

This makes no sense -- strlen doesn't really ever fail with -1.

gdb/ChangeLog:
2016-05-03  Pedro Alves <palves@redhat.com>

* python/python.c (_initialize_python) [IS_PY3K]: Remove dead
code.

[gdb] Fix -Wparentheses warnings

2016-05-03  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

* symfile.c (find_pc_overlay): Add braces to avoid -Wparentheses
warning.
(find_pc_mapped_section): Likewise.
(list_overlays_command): 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

Workaround gdbserver<7.7 for setfs

With current FSF GDB HEAD and old FSF gdbserver I expected I could do:
gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234'
(supplying that unsupported qXfer:exec-file:read by "file")
But that does not work because:
Sending packet: $vFile:setfs:0#bf...Packet received: OK
Packet vFile:setfs (hostio-setfs) is supported
...
Sending packet: $vFile:setfs:104#24...Packet received: OK
"target:/root/redhat/threadit": could not open as an executable file: Invalid argument

GDB documentation says:
The valid responses to Host I/O packets are:
An empty response indicates that this operation is not recognized.

This "empty response" vs. "OK" was a bug in gdbserver < 7.7.  It was fixed by:
commit e7f0d979dd5cc4f8b658df892e93db69d6d660b7
Author: Yao Qi <yao@codesourcery.com>
Date:   Tue Dec 10 21:59:20 2013 +0800
    Fix a bug in matching notifications.
Message-ID: <1386684626-11415-1-git-send-email-yao@codesourcery.com>
https://sourceware.org/ml/gdb-patches/2013-12/msg00373.html
2013-12-10  Yao Qi  <yao@codesourcery.com>
* notif.c (handle_notif_ack): Return 0 if no notification
matches.

with unpatched old FSF gdbserver and patched FSF GDB HEAD:
gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234'
Sending packet: $vFile:setfs:0#bf...Packet received: OK
Packet vFile:setfs (hostio-setfs) is NOT supported
...
(gdb) info sharedlibrary
From                To                  Syms Read   Shared Object Library
0x00007ffff7ddbae0  0x00007ffff7df627a  Yes (*)     target:/lib64/ld-linux-x86-64.so.2
0x00007ffff7bc48a0  0x00007ffff7bcf514  Yes (*)     target:/lib64/libpthread.so.0

gdb/ChangeLog
2016-04-27  Jan Kratochvil  <jan.kratochvil@redhat.com>

* remote.c (remote_start_remote): Detect PACKET_vFile_setfs.support.

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

MIPS/Linux: Also recognize TRAP_BRKPT and TRAP_HWBKPT

This makes the MIPS Linux backends recognize TRAP_BRKPT and
TRAP_HWBKPT in siginfo.si_code in addition to SI_KERNEL, since Linux
4.6 now reports the finer-grained si_code values too.

Refs:
 https://sourceware.org/ml/gdb-patches/2016-02/msg00756.html
 https://sourceware.org/ml/gdb-patches/2016-04/msg00090.html

On kernels that report SI_KERNEL (<= 4.5), we'll enter the "ambiguous"
path of save_stop_reason:

  if (GDB_ARCH_IS_TRAP_BRKPT (siginfo.si_code)
      && GDB_ARCH_IS_TRAP_HWBKPT (siginfo.si_code))
    {
      /* The si_code is ambiguous on this arch -- check debug
 registers.  */
      if (!check_stopped_by_watchpoint (lp))
lp->stop_reason = TARGET_STOPPED_BY_SW_BREAKPOINT;
    }

while on kernels that report the finer-grained si_code values (>= 4.6),
we'll enter the corresponding branches:

  else if (GDB_ARCH_IS_TRAP_BRKPT (siginfo.si_code))
    {
    }
  else if (GDB_ARCH_IS_TRAP_HWBKPT (siginfo.si_code))
    {
      ...

gdb/ChangeLog:
2016-04-15  Pedro Alves  <palves@redhat.com>

* nat/linux-ptrace.h [__mips__] (GDB_ARCH_IS_TRAP_BRKPT): Also
accept TRAP_BRKPT.
 [__mips__] (GDB_ARCH_IS_TRAP_HWBKPT): Also accept TRAP_HWBKPT.

Handle MIPS Linux SIGTRAP siginfo.si_code values

This unbreaks pending/delayed breakpoints handling, as well as
hardware watchpoints, on MIPS.

Ref: https://sourceware.org/ml/gdb-patches/2016-02/msg00681.html

The MIPS kernel reports SI_KERNEL for all kernel generated traps,
instead of TRAP_BRKPT / TRAP_HWBKPT, but GDB isn't aware of this.

Basically, this commit:

- Folds watchpoints logic into check_stopped_by_breakpoint, and
  renames it to save_stop_reason.

- Adds GDB_ARCH_IS_TRAP_HWBKPT.

- Makes MIPS set both GDB_ARCH_IS_TRAP_BRPT and
  GDB_ARCH_IS_TRAP_HWBKPT to SI_KERNEL.  In save_stop_reason, we
  handle the case of the same si_code returning true for both
  TRAP_BRPT and TRAP_HWBKPT by looking at what the debug registers
  say.

Tested on x86-64 Fedora 20, native and gdbserver.

gdb/ChangeLog:
2016-04-15  Pedro Alves  <palves@redhat.com>

* linux-nat.c (save_sigtrap) Delete.
(stop_wait_callback): Call save_stop_reason instead of
save_sigtrap.
(check_stopped_by_breakpoint): Rename to ...
(save_stop_reason): ... this.  Bits of save_sigtrap folded here.
Use GDB_ARCH_IS_TRAP_HWBKPT and handle ambiguous
GDB_ARCH_IS_TRAP_BRKPT / GDB_ARCH_IS_TRAP_HWBKPT.  Factor out
common code between the USE_SIGTRAP_SIGINFO and
!USE_SIGTRAP_SIGINFO blocks.
(linux_nat_filter_event): Call save_stop_reason instead of
save_sigtrap.
* nat/linux-ptrace.h: Check for both SI_KERNEL and TRAP_BRKPT
si_code for MIPS.
* nat/linux-ptrace.h: Fix "TRAP_HWBPT" typo in x86 table.  Add
comments on MIPS behavior.
(GDB_ARCH_IS_TRAP_HWBKPT): Define for all archs.

gdb/gdbserver/ChangeLog:
2016-04-15  Pedro Alves  <palves@redhat.com>

* linux-low.c (check_stopped_by_breakpoint): Rename to ...
(save_stop_reason): ... this.  Use GDB_ARCH_IS_TRAP_HWBKPT and
handle ambiguous GDB_ARCH_IS_TRAP_BRKPT / GDB_ARCH_IS_TRAP_HWBKPT.
Factor out common code between the USE_SIGTRAP_SIGINFO and
!USE_SIGTRAP_SIGINFO blocks.
(linux_low_filter_event): Call save_stop_reason instead of
check_stopped_by_breakpoint and check_stopped_by_watchpoint.
Update comments.
(linux_wait_1): Update comments.

Automatic date update in version.in

Automatic date update in version.in

Fix PR remote/19840: gdb crashes on reverse-stepi

Reverse debugging against a remote target that does reverse debugging
itself (with the bs/bc packets) always trips on:

 (gdb) target remote localhost:...
 (gdb) reverse-stepi
 ../../gdb/target.c:602: internal-error: default_execution_direction: to_execution_direction must be implemented for reverse async

I missed adding a to_execution_direction method to remote.c in commit
3223143295b5 (Adds target_execution_direction to make record targets
support async mode), GDB 7.4 time.  Later, GDB 7.8 switched to
target-async on by default, making the regression user-visible by
default too.

Fix is simply to add the missing to_execution_direction implementation
to target remote.

Tested by Andi Kleen against Simics.

gdb/ChangeLog:
2016-04-13  Pedro Alves  <palves@redhat.com>

PR remote/19840
* remote.c (struct remote_state) <last_resume_exec_dir>: New
field.
(new_remote_state): Default last_resume_exec_dir to EXEC_FORWARD.
(remote_open_1): Reset last_resume_exec_dir to EXEC_FORWARD.
(remote_resume): Store the last execution direction.
(remote_execution_direction): New function.
(init_remote_ops): Install it as to_execution_direction target_ops
method.

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

Add regression test for PR gdb/19858 (JIT code registration on attach)

This test would fail without the previous gdb/jit.c fix:

  (gdb) attach 23031
  Attaching to program: .../build/gdb/testsuite/outputs/gdb.base/jit/jit-main, process 23031
  [...]
  207           WAIT_FOR_GDB; i = 0;  /* gdb break here 1 */
  (gdb) PASS: gdb.base/jit.exp: attach: one_jit_test-2: attach
  set var wait_for_gdb = 0
  (gdb) PASS: gdb.base/jit.exp: attach: one_jit_test-2: set var wait_for_gdb = 0
  info function ^jit_function
  All functions matching regular expression "^jit_function":
  (gdb) FAIL: gdb.base/jit.exp: attach: one_jit_test-2: info function ^jit_function

gdb/testsuite/ChangeLog:
2016-03-31  Pedro Alves  <palves@redhat.com>

PR gdb/19858
* gdb.base/jit-main.c: Include unistd.h.
(ATTACH): Define to 0 if not already defined.
(wait_for_gdb, mypid): New globals.
(WAIT_FOR_GDB): New macro.
(MAIN): Set an alarm.  Store the process's pid.  Wait for GDB at
some breakpoint locations.
* gdb.base/jit.exp (clean_reattach, continue_to_test_location):
New procedures.
(one_jit_test): Add REATTACH parameter, and handle it.  Use
continue_to_test_location.
(top level): Test attach, and adjusts calls to one_jit_test.

Make gdb.base/jit.exp binaries unique

This testcase compiles the same program and library differently
multiple times using the same file names.  Make them unique, to make
it easier to debug test problems.

gdb/testsuite/ChangeLog:
2016-03-31  Pedro Alves  <palves@redhat.com>

PR gdb/19858
* gdb.base/jit.exp (compile_jit_test): Add intro comment.  Add
BINSUFFIX parameter, and handle it.
(top level): Adjust calls compile_jit_test.

Fix PR gdb/19858: GDB doesn't register the JIT libraries on attach

Ref: https://sourceware.org/ml/gdb/2016-03/msg00023.html

GDB currently fails to fetch the list of already-registered JIT
modules on attach.

Nothing is calling jit_inferior_init, which is what is responsible for
walking the JIT object list at init time.

Despite the misleading naming, jit_inferior_created_hook ->
jit_inferior_init is only called when the inferior execs.

This regressed with the fix for PR gdb/13431 (03bef283c2d3):
 https://sourceware.org/ml/gdb-patches/2012-02/msg00023.html which
removed the inferior_created (jit_inferior_created_observer)
observer.

Adding an inferior_created observer back fixes the issue.

In turn, this exposes a bug in jit_breakpoint_re_set_internal as well,
which is returning the wrong result when we already have the
breakpoint at the right address.

gdb/ChangeLog:
2016-03-31  Yichao Yu  <yyc1992@gmail.com>

PR gdb/19858
* jit.c (jit_breakpoint_re_set_internal): Return 0 if we already
got the breakpoint at the right address.
(jit_inferior_created): New function.
(_initialize_jit): Install jit_inferior_created as
inferior_created observer.

Signed-off-by: Pedro Alves <palves@redhat.com>

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

btrace: fix PR gdb/19829

This is a backport of

33b4777ca1b7 btrace, frame: fix crash in get_frame_type
a038fa3e14a4 stack: check frame_unwind_caller_id
2f3ef606b912 frame: add skip_tailcall_frames

In skip_artificial_frames we repeatedly call get_prev_frame_always until we get
a non-inline and non-tailcall frame assuming that there must be such a frame
eventually.

For record targets, however, we may have a frame chain that consists only of
artificial frames.  This leads to a crash in get_frame_type when dereferencing a
NULL frame pointer.

Change skip_artificial_frames and skip_tailcall_frames to return NULL in such a
case and modify each caller to cope with a NULL return.

In frame_unwind_caller_pc and frame_unwind_caller_arch, we simply assert that
the returned value is not NULL.  Their caller was supposed to check
frame_unwind_caller_id before calling those functions.

In other cases, we thrown an error.

In infcmd further move the skip_tailcall_frames call to the forward-stepping
case since we don't need a frame for reverse execution and we don't want to fail
because of that.  Reverse-finish does make sense for a tailcall frame.

gdb/
* frame.h (skip_tailcall_frames): New.
* infcmd.c (finish_command): Call skip_tailcall_frames.
* frame.c (skip_artificial_frames): Return NULL if only artificial frames
are found.  Update comment.
(frame_pop): Call skip_tailcall_frames.
(frame_unwind_caller_id): Handle NULL return.
(frame_unwind_caller_pc, frame_unwind_caller_arch): Assert that
skip_artificial_frames does not return NULL.
(frame_pop): Add an error if only tailcall frames are found.
* infcmd.c (finish_command): Move skip_tailcall_frames call into forward-
execution case.  Add an error if only tailcall frames are found.
* stack.c (frame_info): Check frame_unwind_caller_id.

testsuite/
* gdb.btrace/tailcall-only.exp: New.
* gdb.btrace/tailcall-only.c: New.
* gdb.btrace/x86_64-tailcall-only.S: New.
* gdb.btrace/i686-tailcall-only.S: New.

Automatic date update in version.in

Automatic date update in version.in

Fix PR gdb/19676: Internal error in linux-thread.db.c if /proc not mounted

If /proc is not mounted, GDB fails an assertion in find_new_threads_once:

 Continuing.
 .../src/gdb/linux-thread-db.c:1249: internal-error: find_new_threads_once: Assertion `!target_has_execution' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n)

That was supposed to catch misuses of td_ta_thr_iter, which is unsafe
for live debugging.  However, if /proc is not mounted, we still
fallback to using it.

I didn't bother with a warning, because GDB already prints several
others related to failing to open /proc files.

gdb/ChangeLog:
2016-03-15  Pedro Alves  <palves@redhat.com>

PR gdb/19676
* linux-thread-db.c (try_thread_db_load_1): Leave
info->td_ta_thr_iter_p NULL iff debugging a live process and we
have /proc access.
(find_new_threads_once): Assert that we have a non-NULL
info->td_ta_thr_iter_p instead of checking whether the target has
execution.

Fix PR gdb/19676: Disable displaced stepping if /proc not mounted

On GNU/Linux archs that support displaced stepping, if /proc is not
mounted, GDB gets stuck not able to step past breakpoints:

 (gdb) c
 Continuing.
 dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2163
 2163      LIBC_PROBE (init_complete, 2, LM_ID_BASE, r);
 Cannot find AT_ENTRY auxiliary vector entry.
 (gdb) c
 Continuing.
 dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2163
 2163      LIBC_PROBE (init_complete, 2, LM_ID_BASE, r);
 Cannot find AT_ENTRY auxiliary vector entry.
 (gdb)

That's because GDB can't figure out where the scratch pad is.

This is a regression introduced by the earlier changes to make the
Linux native target always work in non-stop mode.

This commit makes GDB detect the case and fallback to stepping over
breakpoints in-line.

gdb/ChangeLog:
2016-03-15  Pedro Alves  <palves@redhat.com>

PR gdb/19676
* infrun.c (displaced_step_prepare): Also disable displaced
stepping on NOT_SUPPORTED_ERROR.
* linux-tdep.c (linux_displaced_step_location): If reading auxv
fails, throw NOT_SUPPORTED_ERROR instead of generic error.

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

gdb/ChangeLog:

* version.in: Set GDB version number to 7.11.0.DATE-git.

Document the GDB 7.11 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 7.11 released.

Set GDB version number to 7.11.

gdb/ChangeLog:

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

Automatic date update in version.in

Automatic date update in version.in

gdb-gdb.py: SyntaxError: Missing parentheses in call to 'print'

After building GDB
--with-python=/usr/bin/python3
and for example stripping ./gdb and running:
./gdb -data-directory data-directory/ -iex "add-auto-load-safe-path $PWD/gdb-gdb.gdb" -iex "add-auto-load-safe-path $PWD/gdb-gdb.
py" ./gdb
I get:
Make breakpoint pending on future shared library load? (y or [n]) [answered N; input not from terminal]
  File "/home/jkratoch/redhat/gdb-test-python3/gdb/gdb-gdb.py", line 91
    print "Warning: Cannot find enum type_flag_value type."
  ^
SyntaxError: Missing parentheses in call to 'print'
(top-gdb) q

gdb/ChangeLog
2016-02-22  Jan Kratochvil  <jan.kratochvil@redhat.com>

* gdb-gdb.py (class TypeFlagsPrinter): Use parentheses for print.

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

PR remote/19496, internal err forking-threads-plus-bkpt

This patch fixes an internal error that occurs in
gdb.threads/forking-threads-plus-breakpoint.exp:

/blah/binutils-gdb/gdb/target.c:2723: internal-error: Can't determine the
current address space of thread Thread 3170.3170

In default_thread_address_space, find_inferior_ptid couldn't find 3170.3170
because it had been overwritten in inferior_appeared, called as follows:

inferior_appeared
  remote_add_inferior
    remote_notice_new_inferior
      remote_update_thread_list

The cause of the problem was the following sequence of events:

* GDB knows only about the main thread

* the first fork event is reported to GDB, saved as pending_event

* qXfer:threads:read gets the threads from the remote.
  remove_new_fork_children id's the fork child from the pending event
  and removes it from the list reported to GDB.  All the rest of the
  threads, including the fork parent, are added to the GDB thread list.

* GDB stops all the threads.  All the stop events are pushed onto the
  stop reply queue behind the pending fork event.  The fork waitstatus
  is saved in the fork parent thread's pending status field
  thread_info.suspend.

* remote_wait_ns calls queued_stop_reply and process_stop_reply to
  remove the fork event from the front of the stop reply queue and save
  event information in the thread_info structure for the fork parent
  thread.  Unfortunately, none of the information saved in this way is
  the fork-specific information.

* A subsequent qXfer:threads:read packet gets the thread list including
  the fork parent and fork child.  remove_new_fork_children checks the
  thread list to see if there is a fork parent, doesn't find one, checks
  the stop reply queue for a pending fork event, doesn't find one, and
  allows the fork child thread to be reported to GDB before the fork
  event has been handled.  remote_update_thread_list calls
  remote_notice_new_thread and overwrites the current (main) thread in
  inferior_appeared.

So the fork event has been reported out of target_wait but it was left
pending on the infrun side (infrun.c:save_waitstatus).  IOW, the fork
event hasn't been processed by handle_inferior_event yet, so it hasn't
made it to tp->pending_follow yet.

The fix is to check thread_info.suspend along with the
thread_info.pending_follow in remote.c:remove_new_fork_children, to
prevent premature reporting of the fork child thread creation.

gdb/ChangeLog:

PR remote/19496
* remote.c (remove_new_fork_children): Check for pending
fork status in thread_info.suspend.

gdb/testsuite/ChangeLog:

PR remote/19496
* gdb.threads/forking-threads-plus-breakpoint.exp (do_test):
Remove kfail for PR remote/19496.

Fix cleanup in arm_linux_software_single_step

I see the following error in testing aarch64 GDB debugging arm
program.

(gdb) PASS: gdb.reverse/readv-reverse.exp: set breakpoint at marker2
continue
Continuing.
=================================================================
==32273==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x000000ce4c00 in thread T0
    #0 0x2ba5615645c7 in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x545c7)^M
    #1 0x4be8b5 in VEC_CORE_ADDR_cleanup /home/yao/SourceCode/gnu/gdb/git/gdb/common/gdb_vecs.h:34^M
    #2 0x5e6d95 in do_my_cleanups /home/yao/SourceCode/gnu/gdb/git/gdb/common/cleanups.c:154^M
    #3 0x64c99a in fetch_inferior_event /home/yao/SourceCode/gnu/gdb/git/gdb/infrun.c:3975^M
    #4 0x678437 in inferior_event_handler /home/yao/SourceCode/gnu/gdb/git/gdb/inf-loop.c:44^M
    #5 0x5078f6 in remote_async_serial_handler /home/yao/SourceCode/gnu/gdb/git/gdb/remote.c:13223^M
    #6 0x4cecfd in run_async_handler_and_reschedule /home/yao/SourceCode/gnu/gdb/git/gdb/ser-base.c:137^M
    #7 0x676864 in gdb_wait_for_event /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:834^M
    #8 0x676a27 in gdb_do_one_event /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:323^M
    #9 0x676aed in start_event_loop /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:347^M
    #10 0x6706d2 in captured_command_loop /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:318^M
    #11 0x66db8c in catch_errors /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:240^M
    #12 0x6716dd in captured_main /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:1157^M
    #13 0x66db8c in catch_errors /home/yao/SourceCode/gnu/gdb/git/gdb/exceptions.c:240^M
    #14 0x671b7a in gdb_main /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:1165^M
    #15 0x467684 in main /home/yao/SourceCode/gnu/gdb/git/gdb/gdb.c:32^M
    #16 0x2ba563ed7ec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)^M
    #17 0x4676b2 (/scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/gdb+0x4676b2)

looks we should discard cleanup if function
arm_linux_software_single_step returns early, or create cleanup when
it is needed.

gdb:

2016-02-16  Yao Qi  <yao.qi@linaro.org>

* arm-linux-tdep.c (arm_linux_software_single_step): Assign
'old_chain' later.

Automatic date update in version.in

Add missing gdb.arch/i386-prologue.c prototypes

The testfile has not ran because:
gdb.arch/i386-prologue.c:34:3: warning: implicit declaration of function 'standard' [-Wimplicit-function-declaration]
   standard ();
   ^
gdb.arch/i386-prologue.c:35:3: warning: implicit declaration of function 'stack_align_ecx' [-Wimplicit-function-declaration]
   stack_align_ecx ();
   ^
gdb.arch/i386-prologue.c:36:3: warning: implicit declaration of function 'stack_align_edx' [-Wimplicit-function-declaration]
   stack_align_edx ();
   ^
gdb.arch/i386-prologue.c:37:3: warning: implicit declaration of function 'stack_align_eax' [-Wimplicit-function-declaration]
   stack_align_eax ();
   ^

gdb/testsuite/ChangeLog
2016-02-15  Jan Kratochvil  <jan.kratochvil@redhat.com>

* gdb.arch/i386-prologue.c: Add missing prototypes.

Fix more testcases with standard_output_file.

Since
commit 2151ccc56c74b55a8f0debf0724a495368f92591
Author: Simon Marchi <simon.marchi@ericsson.com>
Date:   Mon Feb 8 14:02:36 2016 -0500
    Always organize test artifacts in a directory hierarchy
these testfiles could not build.

gdb/testsuite/ChangeLog
2016-02-15  Jan Kratochvil  <jan.kratochvil@redhat.com>

* gdb.arch/i386-gnu-cfi.exp: Use standard_output_file.
* gdb.arch/i386-prologue.exp: Likewise.
* gdb.arch/i386-size.exp: Likewise.