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

gdb/ChangeLog:

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

Document the GDB 7.11.1 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 7.11.1 released.

Set GDB version number to 7.11.1.

gdb/ChangeLog:

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

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 PR gdb/19828: gdb -p <process from a container>: internal error

When GDB attaches to a process, it looks at the /proc/PID/task/ dir
for all clone threads of that process, and attaches to each of them.

Usually, if there is more than one clone thread, it means the program
is multi threaded and linked with pthreads.  Thus when GDB soon after
attaching finds and loads a libthread_db matching the process, it'll
add a thread to the thread list for each of the initially found
lower-level LWPs.

If, however, GDB fails to find/load a matching libthread_db, nothing
is adding the LWPs to the thread list.  And because of that, "detach"
hits an internal error:

  (gdb) PASS: gdb.threads/clone-attach-detach.exp: fg attach 1: attach
  info threads
    Id   Target Id         Frame
  * 1    LWP 6891 "clone-attach-de" 0x00007f87e5fd0790 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84
  (gdb) FAIL: gdb.threads/clone-attach-detach.exp: fg attach 1: info threads shows two LWPs
  detach
  .../src/gdb/thread.c:1010: internal-error: is_executing: Assertion `tp' failed.
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  Quit this debugging session? (y or n)
  FAIL: gdb.threads/clone-attach-detach.exp: fg attach 1: detach (GDB internal error)

From here:

  ...
  #8  0x00000000007ba7cc in internal_error (file=0x98ea68 ".../src/gdb/thread.c", line=1010, fmt=0x98ea30 "%s: Assertion `%s' failed.")
      at .../src/gdb/common/errors.c:55
  #9  0x000000000064bb83 in is_executing (ptid=...) at .../src/gdb/thread.c:1010
  #10 0x00000000004c23bb in get_pending_status (lp=0x12c5cc0, status=0x7fffffffdc0c) at .../src/gdb/linux-nat.c:1235
  #11 0x00000000004c2738 in detach_callback (lp=0x12c5cc0, data=0x0) at .../src/gdb/linux-nat.c:1317
  #12 0x00000000004c1a2a in iterate_over_lwps (filter=..., callback=0x4c2599 <detach_callback>, data=0x0) at .../src/gdb/linux-nat.c:899
  #13 0x00000000004c295c in linux_nat_detach (ops=0xe7bd30, args=0x0, from_tty=1) at .../src/gdb/linux-nat.c:1358
  #14 0x000000000068284d in delegate_detach (self=0xe7bd30, arg1=0x0, arg2=1) at .../src/gdb/target-delegates.c:34
  #15 0x0000000000694141 in target_detach (args=0x0, from_tty=1) at .../src/gdb/target.c:2241
  #16 0x0000000000630582 in detach_command (args=0x0, from_tty=1) at .../src/gdb/infcmd.c:2975
  ...

Tested on x86-64 Fedora 23.  Also confirmed the test passes against
gdbserver with "maint set target-non-stop".

Unfortunately, making GDB add LWPs to the thread list sooner exposes
inefficiencies that in turn result in
gdb.threads/attach-many-short-lived-threads.exp timing out frequently.
Since that testcase is really a contrived use case designed to stress
some aspects of attach/detach and thread listing, not really
representative of real programs, this commit disables the test.

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

PR gdb/19828
* linux-nat.c (attach_proc_task_lwp_callback): Mark the lwp
resumed, and add the thread to GDB's thread list.

testsuite/ChangeLog:
2016-05-25  Pedro Alves  <palves@redhat.com>

PR gdb/19828
* gdb.threads/clone-attach-detach.c: New file.
* gdb.threads/clone-attach-detach.exp: New file.
* gdb.threads/attach-many-short-lived-threads.exp: Skip.

Make gdb/linux-nat.c consider a waitstatus pending on the infrun side

Working on the fix for gdb/19828, I saw
gdb.threads/attach-many-short-lived-threads.exp fail once in an
unusual way.  Unfortunately I didn't keep debug logs, but it's an
issue similar to what's been fixed in remote.c a while ago --
linux-nat.c was not fetching the pending status from the right place.

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

PR gdb/19828
* linux-nat.c (get_pending_status): If the thread reported the
event to the core and it's pending, use the pending status signal
number.

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 mi-threads-interrupt.exp test (PR 20039)

Add a new test for PR 20039.  The test spawns new threads, then tries to
interrupt, continue, and interrupt again.  This use case was fixed by
commit 5fe966540d6b748f825774868463003700f0c878 in master, but gdb 7.11
is affected (so if you try it on the gdb-7.11-branch right now, the test
will fail).

New in v2, the test now handles mi-async on mode properly.  The failure
was specific to mi-async off, but I don't think it's bad to test the
same thing under async on mode.  I added a little hack when running in
async mode to work around bug 20045.

I also removed one continue/interrupt pair, as a single one was enough to
trigger the problem.

gdb/testsuite/ChangeLog:

* gdb.mi/mi-threads-interrupt.c: New file.
* gdb.mi/mi-threads-interrupt.exp: New file.

Fix double prompt output after run control MI commands with mi-async on (PR 20045)

When you use a run control command (-exec-run, -exec-continue,
-exec-next, ...) with mi-async on, an extra (gdb) prompt is displayed:

  -exec-continue
  ^running
  *running,thread-id="all"
  (gdb)
  (gdb)

It doesn't seem to be a big problem for front-ends, since this behavior
started in gdb 7.9 and we haven't heard anything about that.  However,
it caused me some trouble while writing a test for PR 20039 [1].

The problem comes from an extra (gdb) prompt that we write when running
in mi-async off mode to emulate a past buggy behavior.  When executing a
run control command synchronously, previous gdbs always printed a prompt
right away, even though they are not ready to accept new MI commands
until the target stops.  Only at this time should they display a prompt.
But to keep backwards compatibility apparently, we print it anyway.
Since commit 198297aaf, the condition that decides whether we should
print that "bogus" prompt or not has become true, even when running with
mi-async on.  Since we already print a prompt at the end of the
asynchronous command execution, it results in two prompts for one
command.

The proposed fix is to call target_can_async_p instead of
target_is_async_p, to make the condition:

  if (!target_can_async_p () || sync_execution)
    ... show prompt ...

That shows the prompt if we are emulating a synchronous command on top
of an asynchronous target (sync_execution) or if the target simply can't
run asynchronously (!target_can_async_p ()).

Note that this code is changed and this bug fixed by Pedro's separate
console series, but I think it would be nice to have it fixed in the
mean time.

I ran the gdb.mi directory of the testsuite with mi-async on and off, I
didn't see any regressions.

gdb/ChangeLog:

* mi/mi-main.c (mi_on_resume): Call target_can_async_p instead
of target_is_async_p.

[1] https://sourceware.org/ml/gdb-patches/2016-05/msg00075.html

Automatic date update in version.in

Fix -exec-run not running asynchronously with mi-async on (PR gdb/18077)

When doing -exec-run on a freshly started GDB, the only target on the
target stack at the time the dummy one.  When mi_async_p is called to
know whether the run should be async, it queries whether the current
target (dummy) supports async, and the answer is no.  The fix is to make
the code query the target that will be used for the run, which is not
necessarily the current target.

No regressions in the gdb.mi directory using the unix, native-gdbserver
and native-extended-gdbserver boards.  The test doesn't pass when
forcing maint set target-async off, obviously, since it makes mi-async
have no effect.  It doesn't seem like other tests are checking for that
eventuality, so I didn't in the new test.

gdb/ChangeLog:

* mi/mi-main.c (run_one_inferior): Use run target to determine
whether to run async or not.
(mi_cmd_exec_run): Likewise.

gdb/testsuite/ChangeLog:

* gdb.mi/mi-async-run.exp: New file.
* gdb.mi/mi-async-run.c: New file.

Automatic date update in version.in

Use target_terminal_ours_for_output in MI

The MI code only does output, so leave raw/cooked mode alone, as well
as the SIGINT handler.  Restore terminal settings after output, while
at it.  Also, a couple events missed calling target_terminal_ours
before output, even.

[Backported to the 7.11 branch by Simon Marchi, as it fixes PR 20039.]

gdb/ChangeLog:
YYYY-MM-DD  Pedro Alves  <palves@redhat.com>

* mi/mi-interp.c (mi_new_thread): Put
target_terminal_ours_for_output in effect while outputting.
(mi_thread_exit): Use target_terminal_ours_for_output instead of
target_terminal_ours.
(mi_record_changed, mi_inferior_added, mi_inferior_appeared)
(mi_inferior_exit, mi_inferior_removed, mi_traceframe_changed)
(mi_tsv_created, mi_tsv_deleted, mi_tsv_modified)
(mi_breakpoint_created, mi_breakpoint_deleted)
(mi_breakpoint_modified, mi_solib_loaded, mi_solib_unloaded)
(mi_command_param_changed, mi_memory_changed)
(report_initial_inferior): Use target_terminal_ours_for_output
instead of target_terminal_ours.  Restore terminal settings.
* mi/mi-main.c (mi_execute_command): Use
target_terminal_ours_for_output instead of target_terminal_ours.
Restore terminal settings.

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 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