Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

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

gdb/ChangeLog:

* version.in: Set GDB version number to 7.12.1.DATE-git.
* PROBLEMS: Likewise.

Document the GDB 7.12.1 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 7.12.1 released.

Set GDB version number to 7.12.1.

gdb/ChangeLog:

* version.in: Set GDB version number to 7.12.1.
* PROBLEMS: Likewise.

Fix python-interactive with Python 3.6

New in v2:

 - Define PyMem_RawMalloc as PyMem_Malloc for Python < 3.4 and use
   PyMem_RawMalloc in the code.

Since Python 3.4, the callback installed in PyOS_ReadlineFunctionPointer
should return a value allocated with PyMem_RawMalloc instead of
PyMem_Malloc.  The reason is that PyMem_Malloc must be called with the
Python Global Interpreter Lock (GIL) held, which is not the case in the
context where this function is called.  PyMem_RawMalloc was introduced
for cases like this.

In Python 3.6, it looks like they added an assert to verify that
PyMem_Malloc was not called without the GIL.  The consequence is that
typing anything in the python-interactive mode of gdb crashes the
process.  The same behavior was observed with the official package on
Arch Linux as well as with a manual Python build on Ubuntu 14.04.

This is what is shown with a debug build of Python 3.6 (the error with a
non-debug build is far less clear):

  (gdb) pi
  >>> print(1)
  Fatal Python error: Python memory allocator called without holding the GIL

  Current thread 0x00007f1459af8780 (most recent call first):
  [1]    21326 abort      ./gdb

and the backtrace:

  #0  0x00007ffff618bc37 in raise () from /lib/x86_64-linux-gnu/libc.so.6
  #1  0x00007ffff618f028 in abort () from /lib/x86_64-linux-gnu/libc.so.6
  #2  0x00007ffff6b104d6 in Py_FatalError (msg=msg@entry=0x7ffff6ba15b8 "Python memory allocator called without holding the GIL") at Python/pylifecycle.c:1457
  #3  0x00007ffff6a37a68 in _PyMem_DebugCheckGIL () at Objects/obmalloc.c:1972
  #4  0x00007ffff6a3804e in _PyMem_DebugFree (ctx=0x7ffff6e65290 <_PyMem_Debug+48>, ptr=0x24f8830) at Objects/obmalloc.c:1994
  #5  0x00007ffff6a38e1d in PyMem_Free (ptr=<optimized out>) at Objects/obmalloc.c:442
  #6  0x00007ffff6b866c6 in _PyFaulthandler_Fini () at ./Modules/faulthandler.c:1369
  #7  0x00007ffff6b104bd in Py_FatalError (msg=msg@entry=0x7ffff6ba15b8 "Python memory allocator called without holding the GIL") at Python/pylifecycle.c:1431
  #8  0x00007ffff6a37a68 in _PyMem_DebugCheckGIL () at Objects/obmalloc.c:1972
  #9  0x00007ffff6a37aa3 in _PyMem_DebugMalloc (ctx=0x7ffff6e65290 <_PyMem_Debug+48>, nbytes=5) at Objects/obmalloc.c:1980
  #10 0x00007ffff6a38d91 in PyMem_Malloc (size=<optimized out>) at Objects/obmalloc.c:418
  #11 0x000000000064dbe2 in gdbpy_readline_wrapper (sys_stdin=0x7ffff6514640 <_IO_2_1_stdin_>, sys_stdout=0x7ffff6514400 <_IO_2_1_stdout_>, prompt=0x7ffff4d4f7d0 ">>> ")
    at /home/emaisin/src/binutils-gdb/gdb/python/py-gdb-readline.c:75

The documentation is very clear about it [1] and it was also mentioned
in the "What's New In Python 3.4" page [2].

[1] https://docs.python.org/3/c-api/veryhigh.html#c.PyOS_ReadlineFunctionPointer
[2] https://docs.python.org/3/whatsnew/3.4.html#changes-in-the-c-api

gdb/ChangeLog:

* python/python-internal.h (PyMem_RawMalloc): Define for
Python < 3.4.
* python/py-gdb-readline.c (gdbpy_readline_wrapper): Use
PyMem_RawMalloc instead of PyMem_Malloc.

Automatic date update in version.in

Throw SJ/LJ exception on error in disassembly

PR 20939 reports that GDB will abort on memory error in disassembly,

(gdb) disassemble 0x0,+4
Dump of assembler code from 0x0 to 0x4:
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
   0x0000000000000000: Aborted

(gdb) guile (print (arch-disassemble arch 0 #:size 4))^M
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'^M
ERROR: Process no longer exists

This patch fixes PR 20939 by catching C++ exception, throwing SJ/LJ
exception in the call back passed to C functions of opcodes, and
catching SJ/LJ exception in gdb, and throw exception.

The patch follows this commit

 89525768cd086a0798a504c81fdf7ebcd4c904e1
 Propagate GDB/C++ exceptions across readline using sj/lj-based TRY/CATCH

rather than "backport" the fix to this PR I posted for mainline
https://sourceware.org/ml/gdb-patches/2017-01/msg00288.html because the
fix for mainline includes 1) some changes to opcodes, 2) some refactors
in C++.  All of them are risky to backport to 7.12 branch.

With this patch applied to 7.12 branch, GDB doesn't abort on memory error
in disassembly.  It fixes some test failures in gdb.guile/scm-disasm.exp
and gdb.python/py-arch.exp on aarch64-linux.

-ERROR: Process no longer exists
-UNRESOLVED: gdb.guile/scm-disasm.exp: test bad memory access
+PASS: gdb.guile/scm-disasm.exp: test bad memory access

-ERROR: Process no longer exists
-UNRESOLVED: gdb.python/py-arch.exp: test bad memory access
+PASS: gdb.python/py-arch.exp: test bad memory access

I'll add the scm-disasm test to master later.

gdb:

2017-01-20  Yao Qi  <yao.qi@linaro.org>

PR gdb/20939
* disasm.c (dis_asm_memory_error): Catch the error and rethrow
it as a SJ/LJ exception.  Add GDB_NOEXCEPT.
(disasm_print_insn_noexcept): New function.
(disasm_print_insn): New function.
(gdb_pretty_print_insn): Call disasm_print_insn instead of
gdbarch_print_insn.
(gdb_print_insn): Likewise.
(gdb_buffered_insn_length): Likewise.
* event-top.c (GDB_NOEXCEPT): Move it to ...
* exceptions.h (GDB_NOEXCEPT): ... here.
* guile/scm-disasm.c (gdbscm_disasm_memory_error): Remove.
(gdbscm_print_insn_from_port): Don't set di.memory_errro_func.
Call disasm_print_insn rather than gdbarch_print_insn.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

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 some error-handling bugs in python frame filters

While writing a Python frame filter, I found a few bugs in the current
frame filter code.  In particular:

* One spot converts a Python long to a CORE_ADDR using PyLong_AsLong.
  However, this can fail on overflow.  I changed this to use
  get_addr_from_python.

* Another spot is doing the same but with PyLong_AsUnsignedLongLong; I
  changed this as well just for consistency.

* Converting line numbers can print "-1" if conversion from long
  fails.  This isn't fatal but just a bit ugly.

I've included a test case for the first issue.  The line number one
didn't seem important enough to bother with.

2016-11-08  Tom Tromey  <tom@tromey.com>

* python/py-framefilter.c (py_print_frame): Use
get_addr_from_python.  Check for errors when getting line number.

2016-11-08  Tom Tromey  <tom@tromey.com>

* gdb.python/py-framefilter.py (ElidingFrameDecorator.address):
New 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

update copyright year range in GDB files

This applies the second part of GDB's End of Year Procedure, which
updates the copyright year range in all of GDB's files (the first
part is ommitted on this branch).

gdb/ChangeLog:

        Update copyright year range in all GDB files.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

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 C and C++03 builds

The readline/sjlj-exceptions fix added an unconditional use of
noexcept, but that's only valid C++11, and 7.12 must build with C and
C++03 too.  Fix this by adding a GDB_EXCEPT macro that compiles away
to nothing in C, and to throw() in C++03, which I've confirmed fixes
the original issue just the same as noexcept, with GCC 7 + -std=gnu+03
+ sjlj-exceptions.

gdb/ChangeLog:
2016-12-20  Pedro Alves  <palves@redhat.com>

PR gdb/20977
* event-top.c (GDB_NOEXCEPT): Define.
(gdb_rl_callback_read_char_wrapper_noexcept): Use GDB_NOEXCEPT
instead of noexcept and use (void) instead of ().
(gdb_rl_callback_handler): Use GDB_NOEXCEPT instead of noexcept.

Fix longjmp across readline w/ --enable-sjlj-exceptions toolchains

Nowadays, GDB propagates C++ exceptions across readline using
setjmp/longjmp 89525768cd08 ("Propagate GDB/C++ exceptions across
readline using sj/lj-based TRY/CATCH") because DWARF-based unwinding
can't cross C functions compiled without -fexceptions (see details
from the commit above).

Unfortunately, toolchains that use SjLj-based C++ exceptions got
broken with that fix, because _Unwind_SjLj_Unregister, which is put at
the exit of a function, is not executed due to the longjmp added by
that commit.

 (gdb) [New Thread 2936.0xb80]
 kill

 Thread 1 received signal SIGSEGV, Segmentation fault.
 0x03ff662b in ?? ()
 top?bt 15
 #0  0x03ff662b in ?? ()
 #1  0x00526b92 in stdin_event_handler (error=0, client_data=0x172ed8)
    at ../../binutils-gdb/gdb/event-top.c:555
 #2  0x00525a94 in handle_file_event (ready_mask=<optimized out>,
    file_ptr=0x3ff5cb8) at ../../binutils-gdb/gdb/event-loop.c:733
 #3  gdb_wait_for_event (block=block@entry=1)
    at ../../binutils-gdb/gdb/event-loop.c:884
 #4  0x00525bfb in gdb_do_one_event ()
    at ../../binutils-gdb/gdb/event-loop.c:347
 #5  0x00525ce5 in start_event_loop ()
    at ../../binutils-gdb/gdb/event-loop.c:371
 #6  0x0051fada in captured_command_loop (data=0x0)
    at ../../binutils-gdb/gdb/main.c:324
 #7  0x0051cf5d in catch_errors (
    func=func@entry=0x51fab0 <captured_command_loop(void*)>,
    func_args=func_args@entry=0x0,
    errstring=errstring@entry=0x7922bf <VEC_interp_factory_p_quick_push(VEC_inte rp_factory_p*, interp_factory*, char const*, unsigned int)::__PRETTY_FUNCTION__+351> "", mask=mask@entry=RETURN_MASK_ALL)
    at ../../binutils-gdb/gdb/exceptions.c:236
 #8  0x00520f0c in captured_main (data=0x328feb4)
    at ../../binutils-gdb/gdb/main.c:1149
 #9  gdb_main (args=args@entry=0x328feb4) at ../../binutils-gdb/gdb/main.c:1159
 #10 0x0071e400 in main (argc=1, argv=0x171220)
    at ../../binutils-gdb/gdb/gdb.c:32

Fix this by making the functions involved in setjmp/longjmp as
noexcept, so that the compiler knows it doesn't need to emit the
_Unwind_SjLj_Register / _Unwind_SjLj_Unregister calls for C++
exceptions.

Tested on x86_64 Fedora 23 with:
 - GCC 5.3.1 w/ DWARF-based exceptions.
 - GCC 7 built with --enable-sjlj-exceptions.

gdb/ChangeLog:
2016-12-20  Pedro Alves  <palves@redhat.com>
    Yao Qi  <yao.qi@linaro.org>

PR gdb/20977
* event-top.c (gdb_rl_callback_read_char_wrapper_noexcept): New
noexcept function, factored out from ...
(gdb_rl_callback_read_char_wrapper): ... this.
(gdb_rl_callback_handler): Mark noexcept.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Remove assert on exec_bfd in cris_delayed_get_disassembler

cris_delayed_get_disassembler has an assert that exec_bfd can't be
NULL, but this assert can be triggered like this,

(gdb) set architecture cris
The target architecture is assumed to be cris
(gdb) disassemble 0x0,+4
Dump of assembler code from 0x0 to 0x4:
   0x00000000:
../../binutils-gdb/gdb/cris-tdep.c:3798: internal-error: int cris_delayed_get_disassembler(bfd_vma, disassemble_info*): Assertion `exec_bfd != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

however, cris_get_disassembler does have code to handle the case that
bfd is NULL,

  /* If there's no bfd in sight, we return what is valid as input in all
     contexts if fed back to the assembler: disassembly *with* register
     prefix.  Unfortunately this will be totally wrong for v32.  */
  if (abfd == NULL)
    return print_insn_cris_with_register_prefix;

This patch is to remove this assert.

gdb:

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

PR tdep/20955
* cris-tdep.c (cris_delayed_get_disassembler): Remove the
assert.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Create tdep->rx_psw_type and tdep->rx_fpsw_type lazily

I build GDB with all targets enabled, and "set architecture rx",
GDB crashes,

(gdb) set architecture rx

Program received signal SIGSEGV, Segmentation fault.
append_flags_type_flag (type=0x20cc360, bitpos=bitpos@entry=0, name=name@entry=0xd27529 "C") at ../../binutils-gdb/gdb/gdbtypes.c:4926
4926                               name);
(gdb) bt 10
 #0  append_flags_type_flag (type=0x20cc360, bitpos=bitpos@entry=0, name=name@entry=0xd27529 "C") at ../../binutils-gdb/gdb/gdbtypes.c:4926
 #1  0x00000000004ce725 in rx_gdbarch_init (info=..., arches=<optimized out>) at ../../binutils-gdb/gdb/rx-tdep.c:1051
 #2  0x00000000006b05a4 in gdbarch_find_by_info (info=...) at ../../binutils-gdb/gdb/gdbarch.c:5269
 #3  0x000000000060eee4 in gdbarch_update_p (info=...) at ../../binutils-gdb/gdb/arch-utils.c:557
 #4  0x000000000060f8a8 in set_architecture (ignore_args=<optimized out>, from_tty=1, c=<optimized out>) at ../../binutils-gdb/gdb/arch-utils.c:531
 #5  0x0000000000593d0b in do_set_command (arg=<optimized out>, arg@entry=0x20bee81 "rx ", from_tty=from_tty@entry=1, c=c@entry=0x20b1540)
    at ../../binutils-gdb/gdb/cli/cli-setshow.c:455
 #6  0x00000000007665c3 in execute_command (p=<optimized out>, p@entry=0x20bee70 "set architecture rx ", from_tty=1) at ../../binutils-gdb/gdb/top.c:666
 #7  0x00000000006935f4 in command_handler (command=0x20bee70 "set architecture rx ") at ../../binutils-gdb/gdb/event-top.c:577
 #8  0x00000000006938d8 in command_line_handler (rl=<optimized out>) at ../../binutils-gdb/gdb/event-top.c:767
 #9  0x0000000000692c2c in gdb_rl_callback_handler (rl=0x20be7f0 "") at ../../binutils-gdb/gdb/event-top.c:200

The cause is that we want to access some builtin types in gdbarch init, but
it is not initialized yet.  I fix it by creating the type when it is to be
used.  We've already done this in sparc, sparc64 and m68k.

gdb:

2016-12-09  Yao Qi  <yao.qi@linaro.org>

PR tdep/20954
* rx-tdep.c (rx_psw_type): New function.
(rx_fpsw_type): New function.
(rx_register_type): Call rx_psw_type and rx_fpsw_type.
(rx_gdbarch_init): Move code to rx_psw_type and
rx_fpsw_type.

Create tdep->rl78_psw_type lazily

I build GDB for all targets enabled.  When I "set architecture rl78",
GDB crashes,

(gdb) set architecture rl78

Program received signal SIGSEGV, Segmentation fault.
append_flags_type_flag (type=0x20cc0e0, bitpos=bitpos@entry=0, name=name@entry=0x11dba3f "CY") at ../../binutils-gdb/gdb/gdbtypes.c:4926
4926                               name);
(gdb) bt 10
 #0  append_flags_type_flag (type=0x20cc0e0, bitpos=bitpos@entry=0, name=name@entry=0x11dba3f "CY") at ../../binutils-gdb/gdb/gdbtypes.c:4926
 #1  0x00000000004aaca8 in rl78_gdbarch_init (info=..., arches=<optimized out>) at ../../binutils-gdb/gdb/rl78-tdep.c:1410
 #2  0x00000000006b05a4 in gdbarch_find_by_info (info=...) at ../../binutils-gdb/gdb/gdbarch.c:5269
 #3  0x000000000060eee4 in gdbarch_update_p (info=...) at ../../binutils-gdb/gdb/arch-utils.c:557
 #4  0x000000000060f8a8 in set_architecture (ignore_args=<optimized out>, from_tty=1, c=<optimized out>) at ../../binutils-gdb/gdb/arch-utils.c:531
 #5  0x0000000000593d0b in do_set_command (arg=<optimized out>, arg@entry=0x20be851 "rl78", from_tty=from_tty@entry=1, c=c@entry=0x20b1540)
    at ../../binutils-gdb/gdb/cli/cli-setshow.c:455
 #6  0x00000000007665c3 in execute_command (p=<optimized out>, p@entry=0x20be840 "set architecture rl78", from_tty=1) at ../../binutils-gdb/gdb/top.c:666
 #7  0x00000000006935f4 in command_handler (command=0x20be840 "set architecture rl78") at ../../binutils-gdb/gdb/event-top.c:577
 #8  0x00000000006938d8 in command_line_handler (rl=<optimized out>) at ../../binutils-gdb/gdb/event-top.c:767
 #9  0x0000000000692c2c in gdb_rl_callback_handler (rl=0x20be890 "") at ../../binutils-gdb/gdb/event-top.c:200

The cause is that we want to access some builtin types in gdbarch init, but
it is not initialized yet.  I fix it by creating the type when it is to be
used.  We've already done this in sparc, sparc64 and m68k.

gdb:

2016-12-09  Yao Qi  <yao.qi@linaro.org>

PR tdep/20953
* rl78-tdep.c (rl78_psw_type): New function.
(rl78_register_type): Call rl78_psw_type.
(rl78_gdbarch_init): Move code to rl78_psw_type.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in