gdb: Remove final cleanup from find_overload_match

This patch removes the setup of a null_cleanup in
valops.c:find_overload_match, and all the calls to do_cleanups.

gdb/ChangeLog:

* valops.c (find_overload_match): Remove use of null_cleanup, and
calls to do_cleanups.

gdb: Remove a cleanup from find_overload_match

This patch changes cp-support.c:cp_func_name to return a
'gdb::unique_xmalloc_ptr<char>' instead of a 'char *'.  This allows a
cleanup to be removed from valops.c:find_overload_match.

gdb/ChangeLog:

* compile/compile-cplus-types.c
(compile_cplus_instance::decl_name): Handle changes to
cp_func_name.
* cp-support.c (cp_func_name): Update header comment, update
return type.
* cp-support.h (cp_func_name): Update return type in declaration.
* valops.c (find_overload_match): Move temp_func local to top
level of function and change its type.  Use temp_func to hold and
delete temporary string obtained from cp_func_name.

gdb/remote: Remove a cleanup in remote_check_symbols

Convert one of the variables that requires a cleanup from a 'char *'
to a 'gdb::char_vector' in remote_target::remote_check_symbols.

Tested on x86-64/Linux with target_board native-gdbserver and
native-extended-gdbserver.

gdb/ChangeLog:

* remote.c (remote_target::remote_check_symbols): Convert `msg` to
gdb::char_vector, remove cleanup, and update uses of `msg`.

RISC-V: Fix wrong use of s0 register name.

s0 is listed as both an int register name and an FP register name.  The FP reg
name is wrong.  This looks like a simple editting error, and has an easy fix.
Tested with riscv64-linux build and check, with no regressions.

gdb/
* riscv-tdep.c (riscv_freg_feature): Drop s0 name from f8.

S12Z: opcodes: Separate the decoding of operations from their display.

This change adds an abstraction layer between the decoding of machine
operations and their disassembled textual representation.  This allows
the decoding routines to be re-used for other purposes (at the expense)
of slightly slower running time.

ChangeLog: opcodes/

   * s12z-opc.c: New file.
   * s12z-opc.h: New file.
   * s12z-dis.c: Removed all code not directly related to display
     of instructions.  Used the interface provided by the new files
     instead.
   * Makefile.am (TARGET_LIBOPCODES_CFILES) Add s12z-opc.c.
   * Makefile.in: regenerate.
   * configure.ac (bfd_s12z_arch): Correct the dependencies.
   * configure: regenerate.

Add 'extern C' if simulator is written in C++

sim/common/Changelog:
2018-12-31  Pavel I. Kryukov  <kryukov@frtk.ru>

        * sim-base.h: Add 'extern C' if header is compiled with C++

Don't build readline/libreadline.a, when --with-system-readline is supplied

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

The bundled libreadline is always built, even if the system is
./configure'd --with-system-readline and the build libreadline.a is not
used.

Proposed patch:

Fix ./configure.ac not to proceed readline/, when --with-system-
readline is provided

Automatic date update in version.in

Remove a cleanup from target-descriptions.c

This removes a cleanup from target-descriptions.c, by changing it to
use a unique_ptr instead.  Note that a deletion adapter is used, even
though target_desc is allocated with new, to avoid moving target_desc
to target-descriptions.h.

gdb/ChangeLog
2019-01-02  Tom Tromey  <tom@tromey.com>

* xml-tdesc.c (xml_cache): Hold a target_desc_up.
(tdesc_parse_xml): Remove cleanups.
* target-descriptions.h (make_cleanup_free_target_description):
Don't declare.
(target_desc_deleter): New struct.
(target_desc_up): New typedef.
* target-descriptions.c (target_desc_deleter::operator()): Rename
from free_target_description.
(make_cleanup_free_target_description): Remove.

Remove cleanups from linespec.c

This removes the remaining cleanups from linespec.c.  This adds a
constructor and destructor to linespec_parser, but in a minimal way --
the parser could still benefit from a bit more C++-ification.

gdb/ChangeLog
2019-01-02  Tom Tromey  <tom@tromey.com>

* linespec.c (struct linespec_parser): Rename from ls_parser.  Add
constructor, destructor.
(linespec_parser): Remove typedef.
(~linespec_parser): Rename from linespec_parser_delete.
(linespec_lex_to_end, linespec_complete_label)
(linespec_complete): Update.
(decode_line_full): Remove cleanups.
(decode_line_1): Update.

Change inferior_to_inferior_object to return a gdbpy_ref

Most callers of inferior_to_inferior_object already use a gdbpy_ref,
so this changes inferior_to_inferior_object to return one.  Doing this
revealed that create_thread_object was not correctly handling the case
where inferior_to_inferior_object failed, so this patch fixes this as
well.

gdb/ChangeLog
2019-01-02  Tom Tromey  <tom@tromey.com>

* python/python-internal.h (inferior_to_inferior_object): Change
return type.
* python/py-exitedevent.c (create_exited_event_object): Update.
* python/py-inferior.c (inferior_to_inferior_object): Return
gdbpy_ref.
(python_new_inferior, python_inferior_deleted)
(thread_to_thread_object, delete_thread_object)
(build_inferior_list, gdbpy_selected_inferior): Update.
* python/py-infthread.c (create_thread_object): Update.  Also fail
if inferior_to_inferior_object fails.

Place displaced step data directly in inferior structure

This patch moves the per-inferior data related to displaced stepping to
be directly in the inferior structure, rather than in a container on the
side.

On notable difference is that previously, we deleted the state on
inferior exit, which guaranteed a clean state if re-using the inferior
for a new run or attach.  We now need to reset the state manually.

At the same time, I changed step_saved_copy to be a gdb::byte_vector, so
it is automatically freed on destruction (which should plug the leak
reported here [1]).

[1] https://sourceware.org/ml/gdb-patches/2018-11/msg00202.html

gdb/ChangeLog:

* inferior.h (class inferior) <displaced_step_state>: New field.
* infrun.h (struct displaced_step_state): Move here from
infrun.c.  Initialize fields, add constructor.
<inf>: Remove field.
<reset>: New method.
* infrun.c (struct displaced_step_inferior_state): Move to
infrun.h.
(displaced_step_inferior_states): Remove.
(get_displaced_stepping_state): Adust.
(displaced_step_in_progress_any_inferior): Adjust.
(displaced_step_in_progress_thread): Adjust.
(displaced_step_in_progress): Adjust.
(add_displaced_stepping_state): Remove.
(get_displaced_step_closure_by_addr): Adjust.
(remove_displaced_stepping_state): Remove.
(infrun_inferior_exit): Call displaced_step_state.reset.
(use_displaced_stepping): Don't check for NULL.
(displaced_step_prepare_throw): Call
get_displaced_stepping_state.
(displaced_step_fixup): Don't check for NULL.
(prepare_for_detach): Don't check for NULL.

Fix leak of struct call_thread_fsm in call_function_by_hand_dummy.

When the call does not complete, the call_thread_fsm allocated
by new_call_thread_fsm is not cleaned up and deleted, which causes
the following leak e.g. in gdb.base/callfuncs.exp:

==29263== 560 bytes in 7 blocks are definitely lost in loss record 2,833 of 3,341
==29263==    at 0x4C2E0BC: calloc (vg_replace_malloc.c:762)
==29263==    by 0x405110: xcalloc (common-utils.c:84)
==29263==    by 0x4E67EB: xcnew<call_thread_fsm> (poison.h:122)
==29263==    by 0x4E67EB: new_call_thread_fsm (infcall.c:516)
==29263==    by 0x4E67EB: call_function_by_hand_dummy(value*, type*, gdb::array_view<value*>, void (*)(void*, int), void*) (infcall.c:1154)
==29263==    by 0x4E784E: call_function_by_hand(value*, type*, gdb::array_view<value*>) (infcall.c:693)
==29263==    by 0x496111: eval_call(expression*, noside, int, value**, char const*, type*) [clone .isra.5] (eval.c:835)

Fix the leak by similarly doing cleanup/destroy when restoring
previous state machine.

Tested on debian/amd64, natively and under valgrind.

2019-01-02  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* infcall.c (call_function_by_hand_dummy): cleanup/destroy sm
 in case of call that did not complete.

Fix search of debug files for remote debuggee

When using remote debugging server, and when debuggee filename is
inferred via qXfer:exec-file:read request, or sysroot starts with
"target:", this "target:" prefix of filepaths is not treated correctly
during debug file search - it appears in the middle of the looked up
paths.

In the following example, unpatched GDB can't find separate debug files for
neither the executable, nor standard libraries:

     $ gdb -ex 'set debug separate-debug-file 1' -ex 'set sysroot target:/' -ex 'set debug-file-directory /usr/lib/debug:/home/j/hide' -ex 'target remote :3333' -ex 'break main' -ex 'continue' -ex 'bt' -ex 'info sharedlibrary' -ex 'set confirm off' -ex 'quit'
    GNU gdb (Gentoo 9999 vanilla) 8.2.50.20181109-git
    Copyright (C) 2018 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    Type "show copying" and "show warranty" for details.
    This GDB was configured as "x86_64-pc-linux-gnu".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <https://bugs.gentoo.org/>.
    Find the GDB manual and other documentation resources online at:
        <http://www.gnu.org/software/gdb/documentation/>.

    For help, type "help".
    Type "apropos word" to search for commands related to "word".
    Remote debugging using :3333
    Reading /home/j/test from remote target...
    warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
    Reading /home/j/test from remote target...
    Reading symbols from target:/home/j/test...

    Looking for separate debug info (debug link) for target:/home/j/test
      Trying target:/home/j/test.debug
    Reading /home/j/test.debug from remote target...
      Trying target:/home/j/.debug/test.debug
    Reading /home/j/.debug/test.debug from remote target...
      Trying /usr/lib/debug/target:/home/j/test.debug
      Trying /home/j/hide/target:/home/j/test.debug
    (No debugging symbols found in target:/home/j/test)
    Reading /lib64/ld-linux-x86-64.so.2 from remote target...
    Reading /lib64/ld-linux-x86-64.so.2 from remote target...
    Reading symbols from target:/lib64/ld-linux-x86-64.so.2...

    Looking for separate debug info (debug link) for target:/lib64/ld-linux-x86-64.so.2
      Trying target:/lib64/ld-2.27.so.debug
    Reading /lib64/ld-2.27.so.debug from remote target...
      Trying target:/lib64/.debug/ld-2.27.so.debug
    Reading /lib64/.debug/ld-2.27.so.debug from remote target...
      Trying /usr/lib/debug/target:/lib64/ld-2.27.so.debug
      Trying /home/j/hide/target:/lib64/ld-2.27.so.debug
    (No debugging symbols found in target:/lib64/ld-linux-x86-64.so.2)

    Looking for separate debug info (build-id) for system-supplied DSO at 0x7ffff7ffa000
      Trying /usr/lib/debug/.build-id/fd/03d584bc1a90ba28be457635a02662c9f9c1f2.debug
      Trying /home/j/hide/.build-id/fd/03d584bc1a90ba28be457635a02662c9f9c1f2.debug
    0x00007ffff7dd7000 in ?? () from target:/lib64/ld-linux-x86-64.so.2
    Breakpoint 1 at 0x4005eb
    Continuing.
    Reading /lib64/libpthread.so.0 from remote target...
    Reading /lib64/libc.so.6 from remote target...

    Looking for separate debug info (debug link) for target:/lib64/libpthread.so.0
      Trying target:/lib64/libpthread-2.27.so.debug
    Reading /lib64/libpthread-2.27.so.debug from remote target...
      Trying target:/lib64/.debug/libpthread-2.27.so.debug
    Reading /lib64/.debug/libpthread-2.27.so.debug from remote target...
      Trying /usr/lib/debug/target:/lib64/libpthread-2.27.so.debug
      Trying /home/j/hide/target:/lib64/libpthread-2.27.so.debug

    Looking for separate debug info (debug link) for target:/lib64/libc.so.6
      Trying target:/lib64/libc-2.27.so.debug
    Reading /lib64/libc-2.27.so.debug from remote target...
      Trying target:/lib64/.debug/libc-2.27.so.debug
    Reading /lib64/.debug/libc-2.27.so.debug from remote target...
      Trying /usr/lib/debug/target:/lib64/libc-2.27.so.debug
      Trying /home/j/hide/target:/lib64/libc-2.27.so.debug

    Breakpoint 1, 0x00000000004005eb in main ()
    #0  0x00000000004005eb in main ()
    From                To                  Syms Read   Shared Object Library
    0x00007ffff7dd6e80  0x00007ffff7df4650  Yes (*)     target:/lib64/ld-linux-x86-64.so.2
    0x00007ffff7bbbb70  0x00007ffff7bcbfee  Yes (*)     target:/lib64/libpthread.so.0
    0x00007ffff780f200  0x00007ffff7962d7c  Yes (*)     target:/lib64/libc.so.6
    (*): Shared library is missing debugging information.

With current fix, the paths used always have target: in the beginning
and this helps to find all debug files:

     $ gdb -ex 'set debug separate-debug-file 1' -ex 'set sysroot target:/' -ex 'set debug-file-directory /usr/lib/debug:/home/j/hide' -ex 'target remote :3333' -ex 'break main' -ex 'continue' -ex 'bt' -ex 'info sharedlibrary' -ex 'set confirm off' -ex 'quit'
    GNU gdb (Gentoo 9999 vanilla) 8.2.50.20181109-git
    Copyright (C) 2018 Free Software Foundation, Inc.
    License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
    This is free software: you are free to change and redistribute it.
    There is NO WARRANTY, to the extent permitted by law.
    Type "show copying" and "show warranty" for details.
    This GDB was configured as "x86_64-pc-linux-gnu".
    Type "show configuration" for configuration details.
    For bug reporting instructions, please see:
    <https://bugs.gentoo.org/>.
    Find the GDB manual and other documentation resources online at:
        <http://www.gnu.org/software/gdb/documentation/>.

    For help, type "help".
    Type "apropos word" to search for commands related to "word".
    Remote debugging using :3333
    Reading /home/j/test from remote target...
    warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
    Reading /home/j/test from remote target...
    Reading symbols from target:/home/j/test...

    Looking for separate debug info (debug link) for target:/home/j/test
      Trying target:/home/j/test.debug
    Reading /home/j/test.debug from remote target...
      Trying target:/home/j/.debug/test.debug
    Reading /home/j/.debug/test.debug from remote target...
      Trying target:/usr/lib/debug//home/j/test.debug
    Reading /usr/lib/debug//home/j/test.debug from remote target...
      Trying target:/home/j/hide//home/j/test.debug
    Reading /home/j/hide//home/j/test.debug from remote target...
    Reading /home/j/hide//home/j/test.debug from remote target...
    Reading symbols from target:/home/j/hide//home/j/test.debug...
    Reading /lib64/ld-linux-x86-64.so.2 from remote target...
    Reading /lib64/ld-linux-x86-64.so.2 from remote target...
    Reading symbols from target:/lib64/ld-linux-x86-64.so.2...

    Looking for separate debug info (debug link) for target:/lib64/ld-linux-x86-64.so.2
      Trying target:/lib64/ld-2.27.so.debug
    Reading /lib64/ld-2.27.so.debug from remote target...
      Trying target:/lib64/.debug/ld-2.27.so.debug
    Reading /lib64/.debug/ld-2.27.so.debug from remote target...
      Trying target:/usr/lib/debug//lib64/ld-2.27.so.debug
    Reading /usr/lib/debug//lib64/ld-2.27.so.debug from remote target...
    Reading /usr/lib/debug//lib64/ld-2.27.so.debug from remote target...
    Reading symbols from target:/usr/lib/debug//lib64/ld-2.27.so.debug...

    Looking for separate debug info (build-id) for system-supplied DSO at 0x7ffff7ffa000
      Trying /usr/lib/debug/.build-id/fd/03d584bc1a90ba28be457635a02662c9f9c1f2.debug
      Trying /home/j/hide/.build-id/fd/03d584bc1a90ba28be457635a02662c9f9c1f2.debug
    0x00007ffff7dd7000 in _start () from target:/lib64/ld-linux-x86-64.so.2
    Breakpoint 1 at 0x4005ef: file test/test16.c, line 13.
    Continuing.
    Reading /lib64/libpthread.so.0 from remote target...
    Reading /lib64/libc.so.6 from remote target...

    Looking for separate debug info (debug link) for target:/lib64/libpthread.so.0
      Trying target:/lib64/libpthread-2.27.so.debug
    Reading /lib64/libpthread-2.27.so.debug from remote target...
      Trying target:/lib64/.debug/libpthread-2.27.so.debug
    Reading /lib64/.debug/libpthread-2.27.so.debug from remote target...
      Trying target:/usr/lib/debug//lib64/libpthread-2.27.so.debug
    Reading /usr/lib/debug//lib64/libpthread-2.27.so.debug from remote target...
    Reading /usr/lib/debug//lib64/libpthread-2.27.so.debug from remote target...

    Looking for separate debug info (debug link) for target:/lib64/libc.so.6
      Trying target:/lib64/libc-2.27.so.debug
    Reading /lib64/libc-2.27.so.debug from remote target...
      Trying target:/lib64/.debug/libc-2.27.so.debug
    Reading /lib64/.debug/libc-2.27.so.debug from remote target...
      Trying target:/usr/lib/debug//lib64/libc-2.27.so.debug
    Reading /usr/lib/debug//lib64/libc-2.27.so.debug from remote target...
    Reading /usr/lib/debug//lib64/libc-2.27.so.debug from remote target...

    Breakpoint 1, main () at test/test16.c:13
    13          for ( i=0; i<10; ++i)
    #0  main () at test/test16.c:13
    From                To                  Syms Read   Shared Object Library
    0x00007ffff7dd6e80  0x00007ffff7df4650  Yes         target:/lib64/ld-linux-x86-64.so.2
    0x00007ffff7bbbb70  0x00007ffff7bcbfee  Yes         target:/lib64/libpthread.so.0
    0x00007ffff780f200  0x00007ffff7962d7c  Yes         target:/lib64/libc.so.6

gdb/ChangeLog:

2018-11-09  Andrey Utkin  <autkin@undo.io>

        * symfile.c (find_separate_debug_file): Fix search of debug files for
        remote debuggee.

Signed-off-by: Andrey Utkin <autkin@undo.io>

Style improvements in gdb/python

This fixes a few minor style issues I found in gdb/python: some
unnecessary casts, the removal of an unnecessary local variable, and
one instance of incorrect formatting.

Tested by rebuilding and re-running gdb.python.

gdb/ChangeLog
2019-01-02  Tom Tromey  <tom@tromey.com>

* python/py-inferior.c (gdbpy_initialize_inferior): Fix
indentation.
* python/py-frame.c (frapy_older): Remove cast.
(frapy_newer): Likewise.
* python/py-breakpoint.c (local_setattro): Remove cast.
* python/py-arch.c (archpy_name): Remove local variable.
* python/py-type.c (gdbpy_lookup_type): Remove cast.

Fix year range in unittests/.../char/empty.cc copyright header

The year range in the copyright header of that file was incorrect:

    // Copyright (C) 3 Free Software Foundation, Inc.

Tracing the origin of this file down, I found that it was copied
from GCC's libstdc++-v3 testsuite:

    Adapt and integrate string_view tests
    https://www.sourceware.org/ml/gdb-patches/2018-04/msg00113.html

Looking at the version in GCC, I found the same issue, so sent
a fix there:

    https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00000.html

Now that the fix is in GCC, this commit applies the same fix
to our copy.

gdb/ChangeLog:

* unittests/basic_string_view/element_access/char/empty.cc:
Fix year range in copyright header.

Automatic date update in version.in

gdb/riscv: Split ISA and ABI features

The goal of this commit is to allow RV64 binaries compiled for the 'F'
extension to run on a target that supports both the 'F' and 'D'
extensions.

The 'D' extension depends on the 'F' extension and chapter 9 of the
RISC-V ISA manual implies that running a program compiled for 'F' on
a 'D' target should be fine.

To support this the gdbarch now holds two feature sets, one represents
the features that are present on the target, and one represents the
features requested in the ELF flags.

The existing error checks are relaxed slightly to allow binaries
compiled for 32-bit 'F' extension to run on targets with the 64-bit
'D' extension.

A new set of functions called riscv_abi_{xlen,flen} are added to
compliment the existing riscv_isa_{xlen,flen}, and some callers to the
isa functions now call the abi functions when that is appropriate.

In riscv_call_arg_struct two asserts are removed, these asserts no
longer make sense.  The asserts were both like this:

    gdb_assert (TYPE_LENGTH (ainfo->type)
                <= (cinfo->flen + cinfo->xlen));

And were made in two cases, when passing structures like these:

   struct {
     integer field1;
     float   field2;
   };

or,

   struct {
     float   field1;
     integer field2;
   };

When running on an RV64 target which only has 32-bit float then the
integer field could be 64-bits, while if the float field is 32-bits
the overall size of the structure can be 128-bits (with 32-bits of
padding).  In this case the assertion would fail, however, the code
isn't incorrect, so its safe to just remove the assertion.

This was tested by running on an RV64IMFDC target using a compiler
configured for RV64IMFC, and comparing the results with those obtained
when using a compiler configured for RV64IMFDC.  The only regressions
I see (now) are in gdb.base/store.exp and are related too different
code generation choices GCC makes between the two targets.

Finally, this commit does not make any attempt to support running
binaries compiled for RV32 on an RV64 target, though nothing in here
should prevent that being supported in the future.

gdb/ChangeLog:

* arch/riscv.h (struct riscv_gdbarch_features) <hw_float_abi>:
Delete.
<operator==>: Update with for removed field.
<hash>: Likewise.
* riscv-tdep.h (struct gdbarch_tdep) <features>: Renamed to...
<isa_features>: ...this.
<abi_features>: New field.
(riscv_isa_flen): Update comment.
(riscv_abi_xlen): New declaration.
(riscv_abi_flen): New declaration.
* riscv-tdep.c (riscv_isa_xlen): Update to get answer from
isa_features.
(riscv_abi_xlen): New function.
(riscv_isa_flen): Update to get answer from isa_features.
(riscv_abi_flen): New function.
(riscv_has_fp_abi): Update to get answer from abi_features.
(riscv_call_info::riscv_call_info): Use abi xlen and flen, not isa
xlen and flen.
(riscv_call_info) <xlen, flen>: Update comment.
(riscv_call_arg_struct): Remove invalid assertions
(riscv_features_from_gdbarch_info): Update now hw_float_abi field
is removed.
(riscv_gdbarch_init): Gather isa features and abi features
separately, ensure both match on the gdbarch when reusing an old
gdbarch.  Relax an error check to allow 32-bit abi float to run on
a target with 64-bit float hardware.

Fix 'Invalid read of size 4' in search_command_helper

Valgrind detects the below error in gdb.base/list.exp.
==14763== Invalid read of size 4
==14763==    at 0x60B584: search_command_helper(char const*, int, bool) [clone .constprop.91] (source.c:1601)
==14763==    by 0x408888: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1892)
==14763==    by 0x668550: execute_command(char const*, int) (top.c:630)
==14763==    by 0x4B2F7B: command_handler(char const*) (event-top.c:583)
==14763==    by 0x4B326C: command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) (event-top.c:772)
...
==14763==  Address 0x6d9f09c is 4 bytes before a block of size 156 alloc'd
==14763==    at 0x4C2E2B3: realloc (vg_replace_malloc.c:836)
==14763==    by 0x41904C: xrealloc (common-utils.c:62)
==14763==    by 0x60A300: find_source_lines(symtab*, int) (source.c:1203)
==14763==    by 0x608219: source_cache::get_plain_source_lines(symtab*, int, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*) (source-cache.c:51)
==14763==    by 0x60A46B: print_source_lines_base(symtab*, int, int, enum_flags<print_source_lines_flag>) (source.c:1350)
==14763==    by 0x404E2D: list_command(char const*, int) (cli-cmds.c:1080)
....

Add the missing condition to end the loop once line 1 has been
reversed-searched.

gdb/ChangeLog
2019-01-01  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* source.c (search_command_helper): Stop reverse search
when line 1 has been searched.

Fix leak in record-full.c

valgrind detects leaks in several gdb.reverse tests,
such as the below in gdb.reverse/watch-precsave.exp.

Fix the leak by rewriting the loop that frees
record_full_core_buf_list.

gdb/ChangeLog
2019-01-01  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* record-full.c (record_full_base_target::close): Rewrite
record_full_core_buf_list free logic.

==18847== VALGRIND_GDB_ERROR_BEGIN
==18847== 4,120 (24 direct, 4,096 indirect) bytes in 1 blocks are definitely lost in loss record 3,094 of 3,199
==18847==    at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==18847==    by 0x405097: xmalloc (common-utils.c:44)
==18847==    by 0x5AF8EA: xnew<record_full_core_buf_entry> (poison.h:110)
==18847==    by 0x5AF8EA: record_full_core_target::xfer_partial(target_object, char const*, unsigned char*, unsigned char const*, unsigned long, unsigned long, unsigned long*) (record-full.c:2182)
==18847==    by 0x64677D: raw_memory_xfer_partial(target_ops*, unsigned char*, unsigned char const*, unsigned long, long, unsigned long*) (target.c:956)
==18847==    by 0x64691E: memory_xfer_partial_1(target_ops*, target_object, unsigned char*, unsigned char const*, unsigned long, unsigned long, unsigned long*) (target.c:1086)

Fix leak in print_one_catch_syscall.

The last text produced was not freed, causing the below leak
(e.g. in gdb.base/catch-syscall.exp):

==24970== 56 bytes in 12 blocks are definitely lost in loss record 626 of 3,289
==24970==    at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==24970==    by 0x66B9C3F: __vasprintf_chk (vasprintf_chk.c:80)
==24970==    by 0x405181: vasprintf (stdio2.h:210)
==24970==    by 0x405181: xstrvprintf(char const*, __va_list_tag*) (common-utils.c:122)
==24970==    by 0x40524B: xstrprintf(char const*, ...) (common-utils.c:113)
==24970==    by 0x3B49DB: print_one_catch_syscall(breakpoint*, bp_location**) (break-catch-syscall.c:275)
==24970==    by 0x3C698F: print_one_breakpoint_location(breakpoint*, bp_location*, int, bp_location**, int) (breakpoint.c:6076)
==24970==    by 0x3C75B1: print_one_breakpoint(breakpoint*, bp_location**, int) (breakpoint.c:6373)
==24970==    by 0x3C7D0E: breakpoint_1(char const*, int, int (*)(breakpoint const*)) (breakpoint.c:6571)
==24970==    by 0x3C822C: info_breakpoints_command(char const*, int) (breakpoint.c:6625)

2019-01-01  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* break-catch-syscall.c (print_one_catch_syscall): xfree
the last text.

Update year range in copyright notice of binutils files

ChangeLog rotation

update copyright year printed by gdb, gdbserver and gdbreplay

gdb/ChangeLog:

* top.c (print_gdb_version): Update Copyright year in version
message.

gdb/gdbserver/ChangeLog:

* gdbreplay.c (gdbreplay_version): Update copyright year in
version message.
* server.c (gdbserver_version): Likewise.

Update copyright year range in all GDB files.

This commit applies all changes made after running the gdb/copyright.py
script.

Note that one file was flagged by the script, due to an invalid
copyright header
(gdb/unittests/basic_string_view/element_access/char/empty.cc).
As the file was copied from GCC's libstdc++-v3 testsuite, this commit
leaves this file untouched for the time being; a patch to fix the header
was sent to gcc-patches first.

gdb/ChangeLog:

Update copyright year range in all GDB files.

rotate gdb/ChangeLog

Automatic date update in version.in

Use gdb::unique_xmalloc_ptr<char> in command_line_input to fix a leak

Following the change of logic where the input_handler gets a
gdb::unique_xmalloc_ptr<char>, a call to readline directly
followed by a call to handle_line_of_input is missing a free,
and causes the below leak.

Use gdb::unique_xmalloc_ptr<char> to solve the leak.

==16291== VALGRIND_GDB_ERROR_BEGIN
==16291== 64 bytes in 1 blocks are definitely lost in loss record 1,815 of 4,111
==16291==    at 0x4C2E2B3: realloc (vg_replace_malloc.c:836)
==16291==    by 0x41EB1C: xrealloc (common-utils.c:62)
==16291==    by 0x41DBD3: buffer_grow(buffer*, char const*, unsigned long) [clone .part.1] (buffer.c:40)
==16291==    by 0x66E8FF: buffer_grow_char (buffer.h:40)
==16291==    by 0x66E8FF: gdb_readline_no_editing (top.c:798)
==16291==    by 0x66E8FF: command_line_input(char const*, char const*) (top.c:1249)
==16291==    by 0x66EBD8: read_command_file(_IO_FILE*) (top.c:421)
==16291==    by 0x412C0C: script_from_file(_IO_FILE*, char const*) (cli-script.c:1547)
==16291==    by 0x40BE90: source_script_from_stream (cli-cmds.c:569)
==16291==    by 0x40BE90: source_script_with_search(char const*, int, int) (cli-cmds.c:606)
==16291==    by 0x54D567: catch_command_errors(void (*)(char const*, int), char const*, int) (main.c:379)
==16291==    by 0x54EA84: captured_main_1 (main.c:994)
==16291==    by 0x54EA84: captured_main (main.c:1167)
==16291==    by 0x54EA84: gdb_main(captured_main_args*) (main.c:1193)
==16291==    by 0x29DA27: main (gdb.c:32)
==16291==
==16291== VALGRIND_GDB_ERROR_END

gdb/ChangeLog
2018-12-31  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* top.c (command_line_input): Use unique_xmalloc_ptr to
manage memory allocated by readline.

PR24042, Global-buffer-overflow problem in output_rel_find

place_orphan handled ELF SHT_REL/SHT_RELA specially, output_rel_find
didn't.  This mismatch was a bug and also meant it was possible to
craft an object where ld accessed section->name out of bounds.

PR 24042
* emultempl/elf32.em (output_rel_find): Drop "sec" param.  Add
"rela".
(gld${EMULATION_NAME}_place_orphan): Use sh_type to calculate
"rela" param of output_rel_find when ELF.  Tidy uses of elfinput.

PR24041, Invalid Memory Address Dereference in elf_link_add_object_symbols

PR 24041
* elflink.c (elf_link_add_object_symbols): Don't segfault on
crafted ET_DYN with no program headers.

[PowerPC64] Nop out ld 2,24(1) after old-style __tls_get_addr

When optimising inline plt calls to __tls_get_addr without tls marker
relocs, ld should zap any toc restore insn after the bctrl, to stop a
load-hit-store stall.

* elf64-ppc.c (ppc64_elf_relocate_section <tls_ldgd_opt>): When
editing an old-style __tls_get_addr call, replace a toc restore
insn with a nop.

Automatic date update in version.in

Change input_handler to take a unique_xmalloc_ptr

This changes ui::input_handler to take a unique_xmalloc_ptr.  This
clarifies the ownership transfer of input_handler's argument.

gdb/ChangeLog
2018-12-30  Tom Tromey  <tom@tromey.com>

* event-top.h (command_line_handler): Update.
* top.c (class gdb_readline_wrapper_cleanup) <m_handler_orig>:
Update.
(gdb_readline_wrapper_line): Update.
* top.h (struct ui) <input_handler>: Take a unique_xmalloc_ptr.
(handle_line_of_input): Update.
* event-top.c: Update.
(gdb_readline_no_editing_callback): Update.
(command_line_handler): Take a unique_xmalloc_ptr.
(handle_line_of_input): Take a const char *.
(command_line_append_input_line): Take a const char *.

Fix 'help set/show style' strange layouts/results.

The layout for 'help set address|variable' is strange, e.g.:
  (gdb) help set style address
  style address

  List of show Address display styling
  Configure address colors and display intensity subcommands:

  show Address display styling
  Configure address colors and display intensity background -- Set the background color for this property
  show Address display styling
  Configure address colors and display intensity foreground -- Set the foreground color for this property
  show Address display styling
  Configure address colors and display intensity intensity -- Set the display intensity color for this property

  Type "help show Address display styling
  Configure address colors and display intensity" followed by show Address display styling
  Configure address colors and display intensity subcommand name for full documentation.
  Type "apropos word" to search for commands related to "word".
  Command name abbreviations are allowed if unambiguous.
  (gdb)

The help for 'set style function|filename' gives help for 'Show':
  (gdb) help set style filename
  Filename display styling
  Configure filename colors and display intensity.

  List of show style filename subcommands:

  show style filename background -- Set the background color for this property
  show style filename foreground -- Set the foreground color for this property
  show style filename intensity -- Set the display intensity color for this property

The help for 'show style function|filename' is equally strange, as it speaks
about commands, instead of sub commands:
  (gdb) help show style filename
  Filename display styling
  Configure filename colors and display intensity.

  List of commands:

  background -- Show the background color for this property
  foreground -- Show the foreground color for this property
  intensity -- Show the display intensity color for this property

  Type "help" followed by command name for full documentation.
  Type "apropos word" to search for commands related to "word".
  Command name abbreviations are allowed if unambiguous.
  (gdb)

This patch fixes all this.

Note that the 'set style' and 'show style' have the same prefix_doc:
  (gdb) help show style
  Style-specific settings
  Configure various style-related variables, such as colors
  ...
  (gdb) help set style
  Style-specific settings
  Configure various style-related variables, such as colors
  ...

Other similar commands (such as set|show history) have typically
a more specific prefix:
  (gdb) help show history
  Generic command for showing command history parameters.
  ...
  (gdb) help set history
  Generic command for setting command history parameters.
  ...

This could be fixed by having set_prefix_doc and show_prefix_doc instead of
the single prefix_doc argument to cli_style_option::add_setshow_commands.
That could be improved if deemed better.

2018-12-29  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* cli/cli-style.c (cli_style_option::add_setshow_commands):
Initialize m_set_prefix with "set", instead of re-assigning
m_show_prefix.  Use m_set_prefix for set_list and m_show_prefix
for show_list.
(_initialize_cli_style): Correct the order of arguments in
variable_name_style.add_setshow_commands and
address_style.add_setshow_commands calls.

Automatic date update in version.in

Fix the build when GNU Source Highlight is not available

The builder pointed out that, when GNU Source Highlight is not
available, get_language_name is not used.  This patch makes it
conditional, fixing the build problem.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* source-cache.c (get_language_name): Conditionally compile.

Automatic date update in version.in

Fix a crash in jit.c

A user at Mozilla pointed out a crash in jit.c.  In his situation, an
inferior using the JIT API exec'd an executable that did not use it.
This caused an assertion failure when jit.c:free_objfile_data called
delete_breakpoint with NULL.

This patch fixes the problem in the obvious way.  New test case
included.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* jit.c (free_objfile_data): Only delete breakpoint if non-null.

gdb/testsuite/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>
    Simon Marchi <simark@simark.ca>

* gdb.base/jit-exec.exp: New file.
* gdb.base/jit-exec.c: New file.
* gdb.base/jit-execd.c: New file.

Document the "set style" commands

This documents the new "set style" commands.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* NEWS: Mention terminal styling.

gdb/doc/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* gdb.texinfo (Output Styling): New node.

Highlight source code using GNU Source Highlight

This changes gdb to highlight source using GNU Source Highlight, if it
is available.

This affects the output of the "list" command and also the TUI source
window.

No new test because I didn't see a way to make it work when Source
Highlight is not found.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* utils.h (can_emit_style_escape): Declare.
* utils.c (can_emit_style_escape): No longer static.
* cli/cli-style.c (set_style_enabled): New function.
(_initialize_cli_style): Use it.
* tui/tui-winsource.c (tui_show_source_line): Use tui_puts.
(tui_alloc_source_buffer): Change how source lines are allocated.
* tui/tui-source.c (copy_source_line): New function.
(tui_set_source_content): Use source cache.
* tui/tui-io.h (tui_puts): Update.
* tui/tui-io.c (tui_puts_internal): Add window parameter.
(tui_puts): Likewise.
(tui_redisplay_readline): Update.
* tui/tui-data.c (free_content_elements): Change how source window
contents are freed.
* source.c (forget_cached_source_info): Clear the source cache.
(print_source_lines_base): Use the source cache.
* source-cache.h: New file.
* source-cache.c: New file.
* configure.ac: Check for GNU Source Highlight library.
* configure: Update.
* config.in: Update.
* Makefile.in (SRCHIGH_LIBS, SRCHIGH_CFLAGS): New variables.
(INTERNAL_CFLAGS_BASE): Add SRCHIGH_CFLAGS.
(CLIBS): Add SRCHIGH_LIBS.
(COMMON_SFILES): Add source-cache.c.
(HFILES_NO_SRCDIR): Add source-cache.h.

Use wclrtoeol in tui_show_source_line

This changes tui_show_source_line to use wclrtoeol rather than
manually emitting a sequence of spaces.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* tui/tui-winsource.c (tui_show_source_line): Use wclrtoeol.

Make ANSI terminal escape sequences work in TUI

PR tui/14126 notes that ANSI terminal escape sequences don't affect
the colors shown in the TUI.  A simple way to see this is to try the
extended-prompt example from the gdb manual.

Curses does not pass escape sequences through to the terminal.
Instead, it replaces non-printable characters with a visible
representation, for example "^[" for the ESC character.

This patch fixes the problem by adding a simple ANSI terminal sequence
parser to gdb.  These sequences are decoded and those that are
recognized are turned into the appropriate curses calls.

The curses approach to color handling is unusual and so there are some
oddities in the implementation.

Standard curses has no notion of the default colors of the terminal.
So, if you set the foreground color, it is not possible to reset it --
you have to pick some other color.  ncurses provides an extension to
handle this, so this patch updates configure and uses it when
available.

Second, in curses, colors always come in pairs: you cannot set just
the foreground.  This patch handles this by tracking actually-used
pairs of colors and keeping a table of these for reuse.

Third, there are a limited number of such pairs available.  In this
patch, if you try to use too many color combinations, gdb will just
ignore some color changes.

Finally, in addition to limiting the number of color pairs, curses
also limits the number of colors.  This means that, when using
extended 8- or 24-bit color sequences, it may be possible to exhaust
the curses color table.

I am very sour on the curses design now.

I do not know how to write a test for this, so I did not.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

PR tui/14126:
* tui/tui.c (tui_enable): Call start_color and
use_default_colors.
* tui/tui-io.c (struct color_pair): New.
(color_pair_map, last_color_pair, last_style): New globals.
(tui_setup_io): Clean up color map when shutting down.
(curses_colors): New constant.
(get_color_pair, apply_ansi_escape): New functions.
(tui_write): Rewrite.
(tui_puts_internal): New function, from tui_puts.  Add "height"
parameter.
(tui_puts): Use tui_puts_internal.
(tui_redisplay_readline): Use tui_puts_internal.
(_initialize_tui_io): New function.
(color_map): New globals.
(get_color): New function.
* configure.ac: Check for use_default_colors.
* config.in, configure: Rebuild.

Style addresses

This changes gdb to style addresses.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* ui-out.h (enum class ui_out_style_kind) <ADDRESS>: New
constant.
* ui-out.c (ui_out::field_core_addr): Add styling.
* stack.c (print_frame): Add styling.
* printcmd.c (print_address): Add styling.
(print_address_demangle, info_address_command): Likewise.
* cli/cli-style.h (address_style): Declare.
* cli/cli-style.c (address_style): New global.
(_initialize_cli_style): Register new commands.
* cli-out.c (cli_ui_out::do_field_string): Update.

gdb/testsuite/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* gdb.base/style.exp: Update test to check for address styling.

Style the "Reading symbols" message

The "Reading symbols" message does not use ui-out (perhaps it
should?), so this styles it using the low-level API.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* symfile.c (symbol_file_add_with_addrs): Style file name.

gdb/testsuite/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* gdb.base/style.exp: Add test for styling of "Reading symbols"
message.

Style the gdb welcome message

This changes gdb to style the welcome message that is shown by
default.  The styling is only done interactively.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* top.c (print_gdb_version): Style gdb version number.

gdb/testsuite/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* gdb.base/style.exp: Add test for version number styling.

Style print_address_symbolic

print_address_symbolic does not use ui-out, so it did not style
function names.  This patch changes it to use the low-level style code
directly.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* printcmd.c (print_address_symbolic): Style function name.

gdb/testsuite/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* gdb.base/style.exp: Add test for print_address_symbolic.

Style locations when setting a breakpoint

say_where does not use ui-out, so function and file names printed by
it were not styled.  This patch changes say_where to use the low-level
style code directly.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* breakpoint.c (say_where): Style file name.

gdb/testsuite/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* gdb.base/style.exp: Add test for breakpoint setting.

Style variable names

This adds style support for variable names.  For the time being, this
is only done in backtraces, not in ptype or print; those places do not
use ui-out and so would need ad hoc changes.

This also adds styling to the names printed for local variables in
"backtrace full".  This code does not use ui-out, so the styling is
done using the low-level API.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* ui-out.h (enum class ui_out_style_kind) <VARIABLE>: New global.
* stack.c (print_frame_arg): Style name.
* printcmd.c (print_variable_and_value): Style variable name.
* cli/cli-style.h (variable_name_style): Declare.
* cli/cli-style.c (variable_name_style): New global.
(_initialize_cli_style): Update.
* cli-out.c (cli_ui_out::do_field_string): Update.

gdb/testsuite/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* gdb.base/style.exp: Add test for variable names.

Reset terminal styles

This adds a function that can be used to reset terminal styles,
regardless of what style the low-level output routines currently think
is applied.

This is used to make "echo" and "printf" work properly when emitting
ANSI terminal escapes -- now gdb will reset the style at the end of
the command.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* utils.h (reset_terminal_style): Declare.
* utils.c (can_emit_style_escape): New function.
(set_output_style): Use it.
(reset_terminal_style): New function.
* printcmd.c (printf_command): Call reset_terminal_style.
* cli/cli-cmds.c (echo_command): Call reset_terminal_style.

Add output styles to gdb

This adds some output styling to the CLI.

A style is currently a foreground color, a background color, and an
intensity (dim or bold).  (This list could be expanded depending on
terminal capabilities.)

A style can be applied while printing.  For ui-out, this is done by
passing the style constant as an argument.  For low-level cases,
fprintf_styled and fputs_styled are provided.

Users can control the style via a number of new set/show commands.  In
the interest of not typing many nearly-identical documentation
strings, I automated this.  On the down side, this is not very
i18n-friendly.

I've chose some default colors to use.  I think it would be good to
enable this by default, so that when users start the new gdb, they
will see the new feature.

Stylizing is done if TERM is set and is not "dumb".  This could be
improved when the TUI is available by using the curses has_colors
call.  That is, the lowest layer could call this without committing to
using curses everywhere; see my other patch for TUI colorizing.

I considered adding a new "set_style" method to ui_file.  However,
because the implementation had to interact with the pager code, I
didn't take this approach.  But, one idea might be to put the isatty
check there and then have it defer to the lower layers.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* utils.h (set_output_style, fprintf_styled)
(fputs_styled): Declare.
* utils.c (applied_style, desired_style): New globals.
(emit_style_escape, set_output_style): New function.
(prompt_for_continue): Emit style escapes.
(fputs_maybe_filtered): Likewise.
(fputs_styled, fprintf_styled): New functions.
* ui-out.h (enum class ui_out_style_kind): New.
(class ui_out) <field_string, field_stream, do_field_string>: Add
style parameter.
* ui-out.c (ui_out::field_stream, ui_out::field_string): Add style
parameter.
* tui/tui-out.h (class tui_ui_out) <do_field_string>: Add style
parameter.
* tui/tui-out.c (tui_ui_out::do_field_string): Add style
parameter.
(tui_ui_out::do_field_string): Update.
* tracepoint.c (print_one_static_tracepoint_marker): Style
output.
* stack.c (print_frame_info, print_frame): Style output.
* source.c (print_source_lines_base): Style output.
* skip.c (info_skip_command): Style output.
* record-btrace.c (btrace_call_history_src_line): Style output.
(btrace_call_history): Likewise.
* python/py-framefilter.c (py_print_frame): Style output.
* mi/mi-out.h (class mi_ui_out) <do_field_string>: Add style
parameter.
* mi/mi-out.c (mi_ui_out::do_table_header)
(mi_ui_out::do_field_int): Update.
(mi_ui_out::do_field_string): Update.
* disasm.c (gdb_pretty_print_disassembler::pretty_print_insn):
Style output.
* cli/cli-style.h: New file.
* cli/cli-style.c: New file.
* cli-out.h (class cli_ui_out) <do_field_string>: Add style
parameter.
* cli-out.c (cli_ui_out::do_table_header)
(cli_ui_out::do_field_int, cli_ui_out::do_field_skip): Update.
(cli_ui_out::do_field_string): Add style parameter.  Style the
output.
* breakpoint.c (print_breakpoint_location): Style output.
(update_static_tracepoint): Likewise.
* Makefile.in (SUBDIR_CLI_SRCS): Add cli-style.c.
(HFILES_NO_SRCDIR): Add cli-style.h.

gdb/testsuite/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* gdb.base/style.exp: New file.
* gdb.base/style.c: New file.

Change gdb test suite's TERM setting

This changes the gdb test suite to set TERM to "dumb" by default.
This setting disables terminal styling, so that the existing tests do
not need to be updated.

gdb/testsuite/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* lib/gdb.exp (gdb_init): Set the TERM environment variable to
"dumb".
* gdb.base/readline.exp (operate_and_get_next): Save and restore
the TERM environment variable.

Introduce ui_file_style

This introduces the new ui_file_style class and various helpers.  This
class represents a terminal style and provides methods for parsing and
emitting the corresponding ANSI terminal escape sequences.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* unittests/style-selftests.c: New file.
* ui-style.c: New file.
* ui-style.h: New file.
* ui-file.h: Include ui-style.h.
* Makefile.in (COMMON_SFILES): Add ui-style.c.
(HFILES_NO_SRCDIR): Add ui-style.h.
(SUBDIR_UNITTESTS_SRCS): Add style-selftests.c.

Add a "context" argument to add_setshow_enum_cmd

This adds a "context" argument to add_setshow_enum_cmd.  Now
add_setshow_enum_cmd will call set_cmd_context on both of the new
commands.  This is used in a later patch.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* command.h (add_setshow_enum_cmd): Add "context" argument.
* cli/cli-decode.c (add_setshow_enum_cmd): Add "context"
argument.  Call set_cmd_context.

Change wrap buffering to use a std::string

Currently wrap buffering is implemented by allocating a string that is
the same width as the window, and then writing characters into it.
However, if gdb emits terminal escapes, then these could possibly
overflow the buffer.

To prevent this, change the wrap buffer to be a std::string and update
the various uses.

This also changes utils.c to always emit characters to the wrap
buffer.  This simplifies future patches which emit terminal escape
sequences, and also makes it possible for the "echo" and "printf"
commands to be used to emit terminal escapes and have these work in
the TUI.

gdb/ChangeLog
2018-12-28  Tom Tromey  <tom@tromey.com>

* utils.c (filter_initialized): New global.
(wrap_buffer): Now a std::string.
(wrap_pointer): Remove.
(flush_wrap_buffer): New function.
(filtered_printing_initialized, set_width, wrap_here)
(fputs_maybe_filtered): Update.

Fix leak of set/show verbose doc, avoid xfree of static string

In the tests
  py-pp-registration/gdb.log
  default/gdb.log
  foll-fork/gdb.log
  setshow/gdb.log
  break-interp/gdb.log
Valgrind detects a leak of the doc strings for the set and show verbose cmd.

Here is the stacktrace of the leaked set doc:
==25548== 15 bytes in 1 blocks are definitely lost in loss record 101 of 3,120
==25548==    at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==25548==    by 0x409C27: xmalloc (common-utils.c:44)
==25548==    by 0x778AF9: xstrdup (xstrdup.c:34)
==25548==    by 0x3F860F: add_setshow_cmd_full(char const*, command_class, var_types, void*, char const*, char const*, char const*, void (*)(char const*, int, cmd_list_element*), void (*)(ui_file*, int, cmd_list_element*, char const*), cmd_list_element**, cmd_list_element**, cmd_list_element**, cmd_list_element**) [clone .constprop.10] (cli-decode.c:495)
==25548==    by 0x3F8ADB: add_setshow_boolean_cmd(char const*, command_class, int*, char const*, char const*, char const*, void (*)(char const*, int, cmd_list_element*), void (*)(ui_file*, int, cmd_list_element*, char const*), cmd_list_element**, cmd_list_element**) (cli-decode.c:593)
==25548==    by 0x3F7442: _initialize_cli_cmds() (cli-cmds.c:1768)
==25548==    by 0x69EED3: initialize_all_files() (init.c:365)
==25548==    by 0x658A84: gdb_init(char*) (top.c:2163)
==25548==    by 0x5403E1: captured_main_1 (main.c:863)
==25548==    by 0x5403E1: captured_main (main.c:1167)
==25548==    by 0x5403E1: gdb_main(captured_main_args*) (main.c:1193)
==25548==    by 0x289CA7: main (gdb.c:32)

The leak is created by top.c set_verbose 'elaborate joke':
the doc string is changed according to the verbosity:
  (gdb) help set verbose
  Set verbosity.
  (gdb) set verbose on
  (gdb) help set verbose
  Set verbose printing of informational messages.
  (gdb)

set_verbose creates the leak as it replaces the string allocated in
the above stacktrace by a static (non translated) string:
...
  if (info_verbose)
    {
      c->doc = "Set verbose printing of informational messages.";
...

Also, this can possibly trigger a call to 'free' of a static string,
as c->doc_allocated is kept true, while the string is not allocated anymore.

This patch:
 * fixes the leak by freeing the previous docs if doc_allocated.
 * internationalize the messages.
 * properly sets doc_allocated to 0 once doc strings are static.

gdb/ChangeLog
2018-12-28  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* top.c (set_verbose): Free previous docs if doc_allocated.
Internationalize messages.  Set doc_allocated to 0.

Avoid internal errors when stepping outside 'main' on MinGW

When one steps with "next" past the 'main's 'return' statement
in MinGW programs built by mingw.org's tools, PC lands in a
function whose symbol is not in any symtab.  GDB then looks
up the nearest symbol, and should find none, because all those
with addresses below PC are not real functions.  Having
unresolved symbols, whose address is zero, in minsyms tricked
GDB into using these bogus symbols, which then caused
assertion violation and internal_error.  See the discussion at
https://sourceware.org/ml/gdb-patches/2018-12/msg00176.html
for more details.

gdb/ChangeLog
2018-12-28  Eli Zaretskii  <eliz@gnu.org>

* coffread.c (coff_symtab_read): Don't record in minsyms symbols
that are unresolved.  This avoids triggering an internal error
when stepping outside of 'main' in MinGW programs.

PR24015, glibc-2.28 on little-endian mips32 broken

Commit 2bf2bf23da exposed a bug on targets that create common sections
other than the standard ELF SHN_COMMON.  If these are output by ld -r,
then their type becomes SHT_PROGBITS unless the target handles them
specially (eg. by elf_backend_special_sections), and if they are
merged into .bss/.sbss by ld -r then that section becomes SHT_PROGBITS.

Worse, if they are output by ld -r, then their size is increased by
bfd_generic_define_common_symbol during final link, which leads to
bogus file contents being copied to output.

For mips, it seems to me that the .scommon section should not be
output for ld -r, but I haven't made that change in this patch.

PR 24015
* elf.c (bfd_elf_get_default_section_type): Make common sections
SHT_NOBITS.
* linker.c (bfd_generic_define_common_symbol): Clear
SEC_HAS_CONTENTS.

PR23966, mingw failure due to 32-bit long

PR 23966
* libbfd.c (SSIZE_MAX): Define.
(bfd_malloc, bfd_realloc): Don't cast size to long to check for
"negative" values, compare against SSIZE_MAX instead.

PR24028, PPC_INT_FMT

PPC_INT_FMT is redundant now that bfd.h pulls in inttypes.h if
available.  Apparently MacOS Mojave defines int64_t as long long even
though long is also 64 bits, which confuses the logic selecting
PPC_INT_FMT (and BFD_PRI64 too).  Hopefully inttypes.h is available on
Mojave.

PR 24028
include/
* opcode/ppc.h (PPC_INT_FMT): Delete.
opcodes/
* ppc-dis.c (print_insn_powerpc): Replace PPC_INT_FMT uses with
PRId64/PRIx64.

Automatic date update in version.in

Translate PyExc_KeyboardInterrupt to gdb "quit"

A while back I typed "info pretty-printers" with a large number of
printers installed, and I typed "q" to stop the pagination.  I noticed
that gdb printed a Python exception in this case.

It seems to me that, instead, quitting pagination (or control-c'ing a
Python command generally) should be handled the same way that gdb
normally handles a quit.

This patch implements this idea by changing gdbpy_handle_exception to
treat PyExc_KeyboardInterrupt specially.

gdb/ChangeLog
2018-12-27  Tom Tromey  <tom@tromey.com>

* python/py-utils.c (gdbpy_handle_exception): Translate
PyExc_KeyboardInterrupt to quit.

gdb/testsuite/ChangeLog
2018-12-27  Tom Tromey  <tom@tromey.com>

* gdb.python/py-cmd.exp (test_python_inline_or_multiline): Add
pagination test.

Consolidate some Python exception-printing functions

A few places in the Python code would either call gdbpy_print_stack,
or throw a gdb "quit", depending on the pending exception.  This patch
consolidates these into a helper function.

gdb/ChangeLog
2018-12-27  Tom Tromey  <tom@tromey.com>

* python/python-internal.h (gdbpy_print_stack_or_quit): Declare.
* python/py-unwind.c (pyuw_sniffer): Use
gdbpy_print_stack_or_quit.
* python/py-framefilter.c (throw_quit_or_print_exception):
Remove.
(gdbpy_apply_frame_filter): Use gdbpy_print_stack_or_quit.
* python/python.c (gdbpy_print_stack_or_quit): New function.

Use gdbpy_convert_exception in a few more spots

I noticed a few places were converting a gdb exception to a Python
exception "by hand".  It's better to use the existing
gdbpy_convert_exception helper function, as this handles memory errors
correctly, and in the future may be enhanced in other ways.

gdb/ChangeLog
2018-12-27  Tom Tromey  <tom@tromey.com>

* python/py-value.c (convert_value_from_python): Use
gdbpy_convert_exception.
* python/py-param.c (parmpy_init): Use gdbpy_convert_exception.
* python/py-cmd.c (cmdpy_init): Use gdbpy_convert_exception.
* python/py-breakpoint.c (bppy_init): Use
gdbpy_convert_exception.

Build gdb "nat" files in subdirectory

This moves the various "nat" object files into the nat/ subdirectory.
This allows for the removal of a pattern rule from the gdb Makefile,
which is a small cleanup.

I made the configure.nat change in a (semi-) automated way, hopefully
meaning that it is more likely to be correct than had I done it by
hand.

Eventually I would like for the various configure scripts to only
mention source files, and let the Makefile compute the object file
names.

gdb/ChangeLog
2018-12-27  Tom Tromey  <tom@tromey.com>

* configure.nat (NATDEPFILES): Use nat/ prefix.
* Makefile.in (CONFIG_SRC_SUBDIR): Add nat.
(%.o: ${srcdir}/nat/%.c): Remove rule.
(INIT_FILES): Do not filter out NATDEPFILES.

Make init.c depend on source files

I noticed that init.c depends on the object files that go into gdb.
Because init.c actually only requires the contents of the
corresponding source files, this unnecessarily serializes the step
that builds init.c.

This patch changes gdb's Makefile to make init.c depend on the source
files.  This also simplifies the rule to build init.c.

gdb/ChangeLog
2018-12-27  Tom Tromey  <tom@tromey.com>

* Makefile.in (INIT_FILES): Redefine.
(stamp-init): Remove sed, tr invocations.  Use for loop.  Don't
set LANG or LC_ALL.

Remove gdbtypes special case from init.c rule

The rule to make init.c has a special case for gdbtypes, with a long
explanatory comment.  All of this is obsolete, as the globals referred
to by the comment no longer exist.  This patch simplifies the rule.

gdb/ChangeLog
2018-12-27  Tom Tromey  <tom@tromey.com>

* Makefile.in (stamp-init): Remove gdbtypes special case.

Remove empty nm-fbsd.h header for FreeBSD/i386 native target.

gdb/ChangeLog:

* config/i386/nm-fbsd.h: Remove file.
* Makefile.in (HFILES_NO_SRCDIR): Remove config/i386/nm-fbsd.h.
* configure.nat: Remove NAT_FILE for FreeBSD/i386.

Use DISABLE_COPY_AND_ASSIGN in minimal_symbol_reader

This changes minimal_symbol_reader to use DISABLE_COPY_AND_ASSIGN,
rather than the manual approach it currently uses.

Tested by rebuilding.

gdb/ChangeLog
2018-12-27  Tom Tromey  <tom@tromey.com>

* minsyms.h (class minimal_symbol_reader): Use
DISABLE_COPY_AND_ASSIGN.

Remove more calls to xfree from Python

This changes the Python code to remove some more calls to xfree, in
favor of self-managing data structures.

Tested on x86-64 Fedora 28.

gdb/ChangeLog
2018-12-27  Tom Tromey  <tom@tromey.com>

* python/python.c (python_interactive_command): Use std::string.
(gdbpy_parameter): Likewise.
* python/py-utils.c (unicode_to_encoded_string): Update comment.
* python/py-symtab.c (salpy_str): Use PyString_FromFormat.
* python/py-record-btrace.c (recpy_bt_insn_data): Use
byte_vector.
* python/py-objfile.c (objfpy_get_build_id): Use
unique_xmalloc_ptr.
* python/py-inferior.c (infpy_read_memory): Use
unique_xmalloc_ptr.
* python/py-cmd.c (gdbpy_parse_command_name): Use std::string.

Fix gdb.ada/fun_renaming.exp by using more unique names.

The test fails due to conflict between var 'next' and s-pooloc.adb next:
(gdb) print next(1)
Multiple matches for next
[0] cancel
[1] pack.next (integer) return integer at /bd/home/philippe/gdb/git/binutils-gdb/gdb/testsuite/gdb.ada/fun_renaming/pack.adb:19
[2] system.pool_local.next (system.address) return system.pool_local.acc_address at s-pooloc.adb:151
> FAIL: gdb.ada/fun_renaming.exp: print next(1) (timeout)

Fix by making the names and renamings more unique.

gdb/testsuite/ChangeLog
2018-12-26  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* gdb.ada/fun_renaming/pack.ads (Next): Rename to Fun_Rename_Test_Next.
(Renamed_Next): Rename to Renamed_Fun_Rename_Test_Next.
gdb.ada/fun_renaming/pack.adb (Next): Rename to Fun_Rename_Test_Next.
gdb.ada/fun_renaming/fun_renaming.adb (N): Rename to Fun_Rename_Test_N.
gdb.ada/fun_renaming.exp: Update accordingly.

Fix gdb.ada/assign_arr.exp by using more unique names.

The test fails (timeout) due to conflict between var 'input' and s-ststop.adb 'input':
(gdb) print input.u2 := (0.25,0.5,0.75)
Multiple matches for input
[0] cancel
[1] system.strings.stream_ops.storage_array_ops.input (access ada.streams.root_stream_type; system.strings.stream_ops.io_kind; natural) return system.storage_elements.storage_array at s-ststop.adb:127
[2] system.strings.stream_ops.stream_element_array_ops.input (access ada.streams.root_stream_type; system.strings.stream_ops.io_kind; natural) return ada.streams.stream_element_array at s-ststop.adb:127
[3] system.strings.stream_ops.string_ops.input (access ada.streams.root_stream_type; system.strings.stream_ops.io_kind; natural) return string at s-ststop.adb:127
[4] system.strings.stream_ops.wide_string_ops.input (access ada.streams.root_stream_type; system.strings.stream_ops.io_kind; natural) return wide_string at s-ststop.adb:127
[5] system.strings.stream_ops.wide_wide_string_ops.input (access ada.streams.root_stream_type; system.strings.stream_ops.io_kind; natural) return wide_wide_string at s-ststop.adb:127
[6] target_wrapper.input at /bd/home/philippe/gdb/git/info_t/gdb/testsuite/gdb.ada/assign_arr/target_wrapper.ads:24
> FAIL: gdb.ada/assign_arr.exp: print input.u2 := (0.25,0.5,0.75) (timeout)

gdb/testsuite/ChangeLog
2018-12-26  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* gdb.ada/assign_arr/target_wrapper.ads (Input): Rename to
Assign_Arr_Input.
main_p324_051.adb: Update accordingly.
gdb.ada/assign_arr.exp: Likewise.

Improve gdb.ada/rename_subscript_param.exp by using more unique names.

With old compilers, the test fails because no debug info is generated
for 'B' and GDB finds some 'b' in atnat.h:

(gdb) print b
Multiple matches for b
[0] cancel
[1] b at ../sysdeps/ieee754/dbl-64/atnat.h:106
[2] b at ../sysdeps/ieee754/dbl-64/atnat.h:106
[3] b at ../sysdeps/ieee754/dbl-64/atnat.h:106
> FAIL: gdb.ada/rename_subscript_param.exp: print b before changing its value (timeout)

Avoid the timeout by renaming 'b' to rename_subscript_param_b.

Also, change 'before' to 'after' in the gdb_test message that prints
the value after changing it.

The test still fails with old compilers that do not properly
generate debug info for this renaming:
(gdb) print rename_subscript_param_b
No definition of "rename_subscript_param_b" in current context.
(gdb) FAIL: gdb.ada/rename_subscript_param.exp: print rename_subscript_param_b before changing its value

Note: if the compiler would generate the correct debug info, the test should
succeed with the name B.  However, waiting for this fix, changing the name
ensures that the test fails directly, instead of causing a timeout.

2018-12-26  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

PR ada/23381
* gdb.ada/rename_subscript_param/pkg.adb (B): Rename to
Rename_Subscript_Param_B.  All users updated.
gdb.ada/rename_subscript_param.exp: Test names made unique.
Note that PR ada/23381 is only fully fixed when using a recent
compiler.

Fix gdb.ada/packed_array_assign.exp by using more unique names.

The test gdb.ada/packed_array_assign fails due to conflict between component 'w'
and system.dim.mks.w:

(gdb) print pra := ((x => 2, y => 0, w => 17), pr, (x => 7, y => 1, w => 23))
Unknown component name: system.dim.mks.w.
(gdb) FAIL: gdb.ada/packed_array_assign.exp: print pra := ((x => 2, y => 0, w => 17), pr, (x => 7, y => 1, w => 23))

Also, depending on the compiler version, the component w might be reordered
and placed before components x and y.
So, change the component order in the source, so that both an old
compiler (GNATMAKE 6.3.0, gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516)
and a new compiler (GNATMAKE Pro 20.0w (20181210-82), based on gcc 8.2.1)
produce the same component order (checked by using -gnatR3s).

So, update to test the new (more unique) names in the source order.

2018-12-26  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* gdb.ada/packed_array_assign/aggregates.ads (Packed_Rec):
Rename components to Packed_Array_Assign_[X|Y|W].  Place
component Packed_Array_Assign_W as first component, to ensure
old and new compilers have the same representation.
All users updated.

target.c: Remove struct keyword in range-based for

I get this when compiling with a gcc 6.3.0-based cross-compiler:

  CXX    target.o
/home/simark/src/binutils-gdb/gdb/target.c: In static member function 'static void target_terminal::restore_inferior()':
/home/simark/src/binutils-gdb/gdb/target.c:396:10: error: types may not be defined in a for-range-declaration [-Werror]
     for (struct inferior *inf : all_inferiors ())
          ^~~~~~

Accomodate it by dropping the unnecessary struct keyword.  Actually, I used
"::inferior", otherwise it resolves to the inferior method of the
target_terminal class.

gdb/ChangeLog:

* target.c (target_terminal::restore_inferior): Remove struct keyword.

Automatic date update in version.in

Improve "set debug separate-debug-file"

"set debug separate-debug-file" shows which candidates are considered,
when trying to find separate debug info.  But it's not clear if GDB used
a certain candidate, and if not, why not.  This patch adds some
precision:

Before:

  Looking for separate debug info (debug link) for /lib/x86_64-linux-gnu/libc.so.6
    Trying /lib/x86_64-linux-gnu/libc-2.23.so
    Trying /lib/x86_64-linux-gnu/.debug/libc-2.23.so
    Trying /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.23.so

After:

  Looking for separate debug info (debug link) for /lib/x86_64-linux-gnu/libc.so.6
    Trying /lib/x86_64-linux-gnu/libc-2.23.so... no, same file as the objfile.
    Trying /lib/x86_64-linux-gnu/.debug/libc-2.23.so... no, unable to open.
    Trying /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.23.so... yes!

gdb/ChangeLog:

* build-id.c (build_id_to_debug_bfd): Enhance debug output.
* symfile.c (separate_debug_file_exists): Likewise.

Automatic date update in version.in

Automatic date update in version.in

gdb: Allow struct fields named double

The 64-bit RISC-V target currently models the floating point registers
as having the following type:

    union riscv_double
    {
        builtin_type_ieee_single float;
        builtin_type_ieee_double double;
    }

Notice the choice of names for the fields of this struct, possibly not
ideal choices, as these are not valid field names in C.  However, this
type is only ever defined within GDB (or in the target description),
and no restriction seems to exist on the field names in that case.

The problem though is that currently:

    (gdb) info registers $ft0
    ft0            {float = 0, double = 0} (raw 0x0000000000000000)
    (gdb) p $ft0.float
    $1 = 0
    (gdb) p $ft0.double
    A syntax error in expression, near `double'.

We can access the 'float' field, but not the 'double' field.  This is
because the string 'double' is handled differently to the string
'float' in c-exp.y.

In both cases the string '$ft0' is parsed as a VARIABLE expression.

In the 'float' case, the string 'float' becomes a generic NAME token
in 'lex_one_token', which then allows the rule "exp '.' name" to match
and the field name lookup to occur.

The 'double' case is different.  In order to allow parsing of the type
string 'long double', the 'double' string becomes the token
DOUBLE_KEYWORD.  At this point there's no rule to match "exp '.'
DOUBLE_KEYWORD", so we can never lookup the field named 'double'.

We could rename the fields for RISC-V, and maybe that would be the
best solution.  However, its not hard to allow for fields named
'double', which is what this patch does.

A new case is added to the 'field_name' rule to match the
DOUBLE_KEYWORD, and create a suitable 'struct stoken'.  With this done
the "exp '.'  field_name" pattern can now match, and we can lookup the
double field.

With this patch in place I now see this behaviour:

    (gdb) info registers $ft0
    ft0            {float = 0, double = 0} (raw 0x0000000000000000)
    (gdb) p $ft0.float
    $1 = 0
    (gdb) p $ft0.double
    $2 = 0

I've gone ahead and handled INT_KEYWORD, LONG, SHORT, SIGNED_KEYWORD,
and UNSIGNED as well within field_name.

I've added a new test for this functionality.

This change was tested on x86-64 GNU/Linux with no regressions.

gdb/ChangeLog:

* c-exp.y (field_name): Allow DOUBLE_KEYWORD, INT_KEYWORD, LONG,
SHORT, SIGNED_KEYWORD, and UNSIGNED tokens to act as a field
names.
(typename_stoken): New function.

gdb/testsuite/ChangeLog:

* gdb.dwarf2/dw2-unusual-field-names.c: New file.
* gdb.dwarf2/dw2-unusual-field-names.exp: New file.

gdb: Add new parser rule for structure field names

Introduces a new rule in c-exp.y for matching structure field names.

This is a restructure in preparation for the next commit, this commit
shouldn't result in any user visible changes.

gdb/ChangeLog:

* c-exp.y (field_name): New %token, and new rule.
(exp): Replace uses of 'name' with 'field_name' where appropriate.

gdb: Extend the comments in c-exp.y

In an attempt to fix PR gdb/13368 this commit adds some comments to
c-exp.y which hopefully makes the type parsing code a little clearer.
There are no code changes here, so there should be no user visible
changes after this commit.

gdb/ChangeLog:

PR gdb/13368
* c-exp.y (typebase): Extend the comment.
(ident_tokens): Likewise.

Simplify dwarf2_find_containing_comp_unit

In an earlier patch discussion we noticed that
dwarf2_find_containing_comp_unit takes the address of sect_off, but
doesn't actually need to.  This is a leftover from before
C++-ification.  This patch simplifies the function.

Tested using gdb.dwarf2 on x86-64 Fedora 28.

gdb/ChangeLog
2018-12-18  Tom Tromey  <tom@tromey.com>

* dwarf2read.c (dwarf2_find_containing_comp_unit): Don't take
address of sect_off.

Fix gdb.ada bp_fun_addr failure due to conflict between fun 'a' and s-dimmks.ads 'A'.

The test fails (timeout) due to:
  (gdb) PASS: gdb.ada/bp_fun_addr.exp: break *a'address
  run
  Starting program: /bd/home/philippe/gdb/git/build_info_t/gdb/testsuite/outputs/gdb.ada/bp_fun_addr/a
  Multiple matches for a
  [0] cancel
  [1] a at /bd/home/philippe/gdb/git/info_t/gdb/testsuite/gdb.ada/bp_fun_addr/a.adb:18
  [2] system.dim.mks.a at s-dimmks.ads:115
  > FAIL: gdb.ada/bp_fun_addr.exp: run until breakpoint at a'address (timeout)
  testcase /home/philippe/gdb/git/build_info_t/gdb/testsuite/../../../info_t/gdb/testsuite/gdb.ada/bp_fun_addr.exp completed in 10 seconds

Fix this by using a fun name that has more chances to be unique.

2018-12-24  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

* gdb.ada/bp_fun_addr/a.adb (a): Rename to bp_fun_addr.
Filename a.adb changed to bp_fun_addr.adb.
gdb.ada/bp_fun_addr.exp: Update test accordingly.

Automatic date update in version.in

i386: Remove the unused bfd pointer argument

Remove the unused bfd pointer argument of elf_i386_rtype_to_howto.

* elf32-i386.c (elf_i386_rtype_to_howto): Remove the unused bfd
pointer argument.
(elf_i386_info_to_howto_rel): Updated.
(elf_i386_tls_transition): Likewise.
(elf_i386_relocate_section): Likewise.

Document the GDB 8.2.1 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 8.2.1 released.

Automatic date update in version.in

gdb/riscv: Prevent buffer overflow in riscv_return_value

The existing code for reading and writing the return value can
overflow the passed in buffers in a couple of situations.  This commit
aims to resolve these issues.

The problems were detected using valgrind, here are two examples,
first from gdb.base/structs.exp:

    (gdb) p/x fun9()
    ==31353== Invalid write of size 8
    ==31353==    at 0x4C34153: memmove (vg_replace_strmem.c:1270)
    ==31353==    by 0x632EBB: memcpy (string_fortified.h:34)
    ==31353==    by 0x632EBB: readable_regcache::raw_read(int, unsigned char*) (regcache.c:538)
    ==31353==    by 0x659D3F: riscv_return_value(gdbarch*, value*, type*, regcache*, unsigned char*, unsigned char const*) (riscv-tdep.c:2593)
    ==31353==    by 0x583641: get_call_return_value (infcall.c:448)
    ==31353==    by 0x583641: call_thread_fsm_should_stop(thread_fsm*, thread_info*) (infcall.c:546)
    ==31353==    by 0x59BBEC: fetch_inferior_event(void*) (infrun.c:3883)
    ==31353==    by 0x53890B: check_async_event_handlers (event-loop.c:1064)
    ==31353==    by 0x53890B: gdb_do_one_event() [clone .part.4] (event-loop.c:326)
    ==31353==    by 0x6CA34B: wait_sync_command_done() (top.c:503)
    ==31353==    by 0x584653: run_inferior_call (infcall.c:621)
    ...

And from gdb.base/call-sc.exp:

    (gdb) advance fun
    fun () at /gdb/gdb/testsuite/gdb.base/call-sc.c:41
    41   return foo;
    (gdb) finish
    ==1968== Invalid write of size 8
    ==1968==    at 0x4C34153: memmove (vg_replace_strmem.c:1270)
    ==1968==    by 0x632EBB: memcpy (string_fortified.h:34)
    ==1968==    by 0x632EBB: readable_regcache::raw_read(int, unsigned char*) (regcache.c:538)
    ==1968==    by 0x659D01: riscv_return_value(gdbarch*, value*, type*, regcache*, unsigned char*, unsigned char const*) (riscv-tdep.c:2576)
    ==1968==    by 0x5891E4: get_return_value(value*, type*) (infcmd.c:1640)
    ==1968==    by 0x5892C4: finish_command_fsm_should_stop(thread_fsm*, thread_info*) (infcmd.c:1808)
    ==1968==    by 0x59BBEC: fetch_inferior_event(void*) (infrun.c:3883)
    ==1968==    by 0x53890B: check_async_event_handlers (event-loop.c:1064)
    ==1968==    by 0x53890B: gdb_do_one_event() [clone .part.4] (event-loop.c:326)
    ==1968==    by 0x6CA34B: wait_sync_command_done() (top.c:503)
    ...

There are a couple of problems with the existing code, that are all
related.

In riscv_call_arg_struct we incorrectly rounded up the size of a
structure argument.  This is unnecessary, and caused GDB to read too
much data into the output buffer when extracting a struct return
value.

In fixing this it became clear that we were incorrectly assuming that
any value being placed in a register (or read from a register) would
always access the entire register.  This is not true, for example a
9-byte struct on a 64-bit target places 8-bytes in one registers and
1-byte in a second register (assuming available registers).  To handle
this I switch from using cooked_read to cooked_read_part.

Finally, when processing basic integer return value types these are
extended to xlen sized types and then passed in registers.  We
currently don't handle this type expansion in riscv_return_value, but
we do in riscv_push_dummy_call.  The result is that small integer
types (like char) result in a full xlen sized register being written
into the output buffer, which results in buffer overflow.  To address
this issue we now create a value of the expanded type and use this
values contents buffer to hold the return value before casting the
value down to the smaller expected type.

This patch resolves all of the valgrind issues I have found so far,
and causes no regressions.  Tested against RV32/64 with and without
floating point support.

gdb/ChangeLog:

* riscv-tdep.c (riscv_call_arg_struct): Don't adjust size before
assigning locations.
(riscv_return_value): Take more care not to read/write outside of
argument buffer.  Cast return value between the declared type and
the abi type.

gdb/riscv: Add float status registers to save and restore reggroups

We should save and restore the floating point status registers.  This
became an issue when testing 32-bit float on a target with 64-bit with
the gdb.base/callfuncs.exp test.

gdb/ChangeLog:

* riscv-tdep.c (riscv_register_reggroup_p): Save and restore fcsr,
fflags, and frm registers.

gdb/riscv: Add gdb to dwarf register number mapping

Provide a mapping between GDB's register numbers and DWARF's register
numbers.  This resolves some failures that I was seeing on
gdb.base/store.exp when running on an rv64imfdc target.

gdb/ChangeLog:

* riscv-tdep.c (riscv_dwarf_reg_to_regnum): New function.
(riscv_gdbarch_init): Register new function with gdbarch.
* riscv-tdep.h: New enum to define RISC-V DWARF register numbers.

Add debug output for recorded minsyms

While discussing this issue:

  https://sourceware.org/ml/gdb-patches/2018-12/threads.html#00082

I added a printf gated by "set debug symtab-create" to be able to
quickly see all minimal symbols recorded by GDB.  I thought it would be
useful to have it built-in, for the future.  Here's how the output
looks:

  Recording minsym:  mst_data                         0x400780    15  _IO_stdin_used
  Recording minsym:  mst_text                         0x400700    13  __libc_csu_init
  Recording minsym:  mst_bss                          0x601058    25  _end

gdb/ChangeLog:

* minsyms.c (mst_str): New.
(minimal_symbol_reader::record_full): Add debug output.

Automatic date update in version.in

Fix various tests to use -no-pie linker flag when needed

Various tests use test code written in i386 / x86_64 assembly that cannot
be used to create PIE executables. Therefore compilation of test programs
failed on systems where the compiler default is to create PIE executable.

The solution is to use -no-pie linker flag, however, such flag may not
(is not) supported by all compilers GDB needs to support (e.g. gcc 4.8).
To handle this, introduce a new flag to gdb_compile - nopie - which
inserts -no-pie linker flag where supported and is no-op where it is
not. By default, -no-pie flag is inserted since most modern compiler do
support it.

Workaround a FreeBSD kernel bug resulting in spurious SIGTRAP events.

The ptrace command PT_LWPINFO to request detailed information about a
stopped thread can return stale signal information from an earlier
stop.  Events which are reporting an intercepted signal will always
report the correct information, but signal stops for some other events
such as system call enter/exit events might include stale siginfo from
an earlier signal.  In particular, if a thread reports a system call
entry or exit event after previously reporting a single-step or
breakpoint event via SIGTRAP, fbsd_handle_debug_trap believed the
system call event was the previous event and claimed it resulting in a
spurious SIGTRAP event.

True breakpoint and single-step events will never report another event
in the pl_flags member of struct ptrace_lwpinfo.  Use this to detect
stale siginfo by requiring pl_flags to have only the PL_FLAG_SI flag
and no other flags before treating a SIGTRAP as a single-step or
breakpoint trap.

gdb/ChangeLog:

* fbsd-nat.c (fbsd_handle_debug_trap): Require pl.pl_flags to
equal PL_FLAG_SI.
(fbsd_nat_target::stopped_by_sw_breakpoint): Likewise.

gdb: Fix "info os <unknown>" command

Running `info os someUnknownOsType` is crashing when gdb is built with
-D_GLIBCXX_DEBUG:

/usr/include/c++/5/debug/vector:439:error: attempt to
access an element in an empty container.

In target_read_stralloc from target.c, the call to
target_read_alloc_1 can return an empty vector, we then call vector::back on
this vector, which is invalid.

This commit adds a check for emptiness before trying to call
vector::back on it. It also adds test to check for `info os <unknown>`
to return the proper error message.

This is a regression in gdb 8.2 and this patch restores the behavior of
previous versions.

gdb/ChangeLog:

PR gdb/23974
* target.c (target_read_stralloc): Check for empty vector.

gdb/testsuite/ChangeLog:

PR gdb/23974
* gdb.base/info-os.exp: Check return for unknown "info os" type.

when printing the GDB config, explicitly say if configured without python

When using the --configuration command line switch, or using
the "show configuration" command with a version of GDB which
was configured without Python supoprt, this patch changes
the resulting output to include...

    --without-python

... instead of not printing anything about Python support.

gdb/ChangeLog:

        * top.c (print_gdb_configuration): Print "--without-python"
        if GDB was configured without Python.

Tested on x86_64-linux by rebuilding GDB with and without Python,
and checking the output of "gdb --configuration" in both cases.

gdb/riscv: Format CORE_ADDR as a string for printing

Avoid compiler errors caused by trying to print CORE_ADDR using '%ld'
format, instead convert to a string and print that instead.

gdb/ChangeLog:

* riscv-tdep.c (riscv_scan_prologue): Use plongest to format
a signed offset as a string.

Fix compile error with clang 3.8

When compiling with clang 3.8 (default clang version on Debian
Stretch, the current stable), we get errors like this:

  CXX    dtrace-probe.o
../../binutils-gdb/gdb/dtrace-probe.c:103:31: error: default initialization of an object of const type 'const dtrace_static_probe_ops' without a user-provided default constructor
const dtrace_static_probe_ops dtrace_static_probe_ops;
                              ^

Silence them by value-initializing those objects.  It's not necessary
with other compilers (later clang versions, gcc), but it shouldn't
hurt either.

Automatic date update in version.in

x86: Call rtype_to_howto to get reloc_howto_type pointer

* elf32-i386.c (elf_i386_relocate_section): Call
elf_i386_rtype_to_howto to get reloc_howto_type pointer.
* elf64-x86-64.c (elf_x86_64_relocate_section): Call
elf_x86_64_rtype_to_howto to get reloc_howto_type pointer.