Fix coff_start_symtab resource leak found by Coverity

This commit fixes a resource leak found by Coverity, where
coff_start_symtab performs an xstrdup that is now performed
within start_symtab by buildsym_compunit::buildsym_compunit.

gdb/ChangeLog:

* coffread.c (coff_start_symtab): Remove unnecessary xstrdup.

Binutils: Always skip only 1 byte for CIE version 1's return address register.

According to the specification for the CIE entries, when the CIE version is 1 then
the return address register field is always 1 byte.  Readelf does this correctly in
read_cie in dwarf.c but ld does this incorrectly and always tries to read a
skip_leb128.  If the value here has the top bit set then ld will incorrectly read
at least another byte, causing either an assert failure or an incorrect address to
be used in eh_frame.

I'm not sure how to generate a generic test for this as I'd need to write assembly,
and it's a bit hard to trigger. Essentially the relocated value needs to start with
something that & 0x70 != 0x10 while trying to write a personality.

bfd/ChangeLog:

* elf-eh-frame.c (_bfd_elf_write_section_eh_frame): Correct CIE parse.

PR24272, out-of-bounds read in pex64_xdata_print_uwd_codes

The fix here is to use an unsigned comparison for
    if (a->NumberOfRvaAndSizes > IMAGE_NUMBEROF_DIRECTORY_ENTRIES)

include/
PR 24272
* coff/internal.h (struct internal_extra_pe_aouthdr): Change type
of SizeOfCode, SizeOfInitializedData, and SizeOfUninitializedData
to bfd_vma.  Change type of SectionAlignment, FileAlignment,
Reserved1, SizeOfImage, SizeOfHeaders, CheckSum, LoaderFlags,
and NumberOfRvaAndSizes to uint32_t.
bfd/
PR 24272
* peXXigen.c (_bfd_XXi_swap_aouthdr_in): Use unsigned index.
(_bfd_XX_print_private_bfd_data_common): Adjust for type changes.

Automatic date update in version.in

Testsuite: Catch gdbserver socket listen errors

When launching gdbserver, the testsuite checks for binding failure but
does not check for failure to listen to socket error (which can happen
due to another gdbserver binding to the socket at the same time).

When this error occurs, the test will ignore the error and connect GDB
to the failed port.  This may succeed and GDB will now be connected to
the gdbserver from another test.  This eventually causes both tests to
fail.

When running the tests suite with native-gdbserver across many cores,
this issue may happen once or twice, each causing random failures for
two .exp testscripts.

Example gdb.log output for the failure:

The testsuite sucessfully notices a failure to connect to port 2348.
It launches again with port 2349, which also fails.  The testsuite
ignores this error and uses gdb to connect to the port - which succeeds.

spawn /work/build/gdb/testsuite/../gdbserver/gdbserver --once localhost:2348 /work/build/gdb/testsuite/outputs/gdb.ada/arrayidx/p^M
Can't bind address: Address already in use.^M
Exiting^M
Port 2348 is already in use.
spawn /work/build/gdb/testsuite/../gdbserver/gdbserver --once localhost:2349 /work/build/gdb/testsuite/outputs/gdb.ada/arrayidx/p^M
Can't listen on socket: Address already in use.^M
Exiting^M
target remote localhost:2349^M
Remote debugging using localhost:2349^M
Reading /lib/ld-linux-aarch64.so.1 from remote target...^M
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.^M
Reading /lib/ld-linux-aarch64.so.1 from remote target...^M
Reading symbols from target:/lib/ld-linux-aarch64.so.1...^M
Reading /lib/ld-2.23.so from remote target...^M
Reading /lib/.debug/ld-2.23.so from remote target...^M
Reading /work/build/install/lib/debug//lib/ld-2.23.so from remote target...^M
Reading /work/build/install/lib/debug/lib//ld-2.23.so from remote target...^M
Reading target:/work/build/install/lib/debug/lib//ld-2.23.so from remote target...^M
(No debugging symbols found in target:/lib/ld-linux-aarch64.so.1)^M
0x0000ffffbf6d2cc0 in ?? () from target:/lib/ld-linux-aarch64.so.1^M
(gdb) continue^M
Continuing.^M
Reading /lib/aarch64-linux-gnu/libc.so.6 from remote target...^M
Reading /lib/aarch64-linux-gnu/libc-2.23.so from remote target...^M
Reading /lib/aarch64-linux-gnu/.debug/libc-2.23.so from remote target...^M
Reading /work/build/install/lib/debug//lib/aarch64-linux-gnu/libc-2.23.so from remote target...^M
Reading /work/build/install/lib/debug/lib/aarch64-linux-gnu//libc-2.23.so from remote target...^M
Reading target:/work/build/install/lib/debug/lib/aarch64-linux-gnu//libc-2.23.so from remote target...^M
[Inferior 1 (process 35351) exited normally]^M
(gdb) FAIL: gdb.ada/arrayidx.exp: can't run to main

Meanwhile, at the same time, in another test, gdbserver successfully
connects to port 2349.  GDB then tries to connect to the port, but it
times out because the GDB in the test above has already connected to it.

spawn /work/build/gdb/testsuite/../gdbserver/gdbserver --once localhost:2348 /work/build/gdb/testsuite/outputs/gdb.ada/rdv_wait/foo^M
Can't bind address: Address already in use.^M
Exiting^M
Port 2348 is already in use.
spawn /work/build/gdb/testsuite/../gdbserver/gdbserver --once localhost:2349 /work/build/gdb/testsuite/outputs/gdb.ada/rdv_wait/foo^M
Process /work/build/gdb/testsuite/outputs/gdb.ada/rdv_wait/foo created; pid = 65162^M
Listening on port 2349^M
Remote debugging from host 127.0.0.1, port 45154^M
target remote localhost:2349^M
localhost:2349: Connection timed out.^M
(gdb) ^CQuit^M
(gdb) task 2^M
Cannot inspect Ada tasks when program is not running^M

gdb/testsuite/ChangeLog:

* lib/gdbserver-support.exp (gdbserver_start): Check for listen
failure.

Can't interrupt process without controlling terminal on Solaris (PR gdb/8527)

If gdb attaches to a process that either has no controlling terminal,
or the controlling terminal differs from the one gdb is running under,
break/^C doesn't interrupt the debugged process on Solaris.

Fixed as follows, analogous to what all all other targets do.  Patch from
the PR, recently re-submitted by Brian Vandenberg.

Tested on amd64-pc-solaris2.11, sparcv9-sun-solaris2.11, and
x86_64-pc-linux-gnu.

2019-02-28  Brian Vandenberg  <phantall@gmail.com>
    Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

gdb:
PR gdb/8527
* procfs.c (proc_wait_for_stop): Wrap write of PCWSTOP in
set_sigint_trap, clear_sigint_trap.

gdb/testsuite:
PR gdb/8527
* gdb.base/interrupt-daemon-attach.c,
gdb.base/interrupt-daemon-attach.exp: New test.

Prevent a buffer overrun error when attempting to parse a corrupt ELF file.

PR 24273
* elf.c (bfd_elf_string_from_elf_section): Check for a string
section that is not NUL terminated.

(gdb/sim) Move Mike Frysinger to past maintainers section

sim/ChangeLog:

* MAINTAINERS: Move Mike Frysinger to past maintainers' section.

Automatic date update in version.in

Fix regcache leak, and avoid possible regcache access after detach.

Valgrind reports leaks like the below in various tests,
e.g. gdb.threads/attach-slow-waitpid.exp, gdb.ada/task_switch_in_core.exp, ...

Fix the leak by clearing the regcache when detaching from an inferior.
Note that these leaks are 'created' when GDB exits,
when the regcache::current_regcache is destroyed : the elements
of the forward_list are pointers, and the 'pointed to' memory is not
deleted by the forward_list destructor.

Nevertheless, fixing this leak is good as it makes a bunch of
tests 'leak clean'.

Also, it seems strange to keep a register cache for a process from
which GDB detached : it is not clear if this cache is still valid
after detach.  And effectively, when clearing only the regcache,
(and not the frame cache), then the frame cache was still 'pointing'
at this regcache and was used when switching to the child process
in the test gdb.threads/watchpoint-fork.exp, which seems strange.

So, we solve the leak and avoid possible accesses to the regcache
and frame cache of the detached inferior, by clearing both the
regcache and the frame cache.

Tested on debian/amd64, natively, under Valgrind,
and with make check RUNTESTFLAGS="--target_board=native-gdbserver".

==27679== VALGRIND_GDB_ERROR_BEGIN
==27679== 1,123 (72 direct, 1,051 indirect) bytes in 1 blocks are definitely lost in loss record 2,942 of 3,400
==27679==    at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344)
==27679==    by 0x5CDF71: get_thread_arch_aspace_regcache(ptid_t, gdbarch*, address_space*) (regcache.c:330)
==27679==    by 0x5CE12A: get_thread_regcache (regcache.c:366)
==27679==    by 0x5CE12A: get_current_regcache() (regcache.c:372)
==27679==    by 0x4FF63D: post_create_inferior(target_ops*, int) (infcmd.c:452)
==27679==    by 0x43AF62: core_target_open(char const*, int) (corelow.c:458)
==27679==    by 0x408B68: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1892)
...

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

* target.c (target_detach): Clear the regcache and the
frame cache.

x86-64: Skip protected check on symbol defined by linker

Skip symbol defined by linker when checking copy reloc on protected
symbol.

bfd/

PR ld/24276
* elf64-x86-64.c (elf_x86_64_check_relocs): Skip symbol defined
by linker when checking copy reloc on protected symbol.

ld/

PR ld/24276
* testsuite/ld-i386/i386.exp: Run PR ld/24276 test.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
* testsuite/ld-i386/pr24276.dso: New file.
* testsuite/ld-i386/pr24276.warn: Likewise.
* testsuite/ld-x86-64/pr24276.dso: Likewise.
* testsuite/ld-x86-64/pr24276.warn: Likewise.

Handle \r\n in gdbreplay

I tried gdbreplay yesterday, but the remotelogfile I received was made
on Windows, so the lines were terminated with \r\n rather than plain
\n.

This patch changes gdbreplay to allow \r\n line termination when
reading the log file.

gdb/gdbserver/ChangeLog
2019-02-27  Tom Tromey  <tromey@adacore.com>

* gdbreplay.c (logchar): Handle \r\n.

Test "set width/height -1"

As a follow up to the previous commit, add a test for "set
width/height -1", to make sure we don't overflow in readline with
negative values either.

gdb/testsuite/ChangeLog:
2019-02-27  Pedro Alves  <palves@redhat.com>

* gdb.base/page.exp: Add tests for "set width/height -1".

Make 'show width/height' display "unlimited" when capped for readline

When we cap the height/width sizes before passing to readline, tweak
the corresponding command variable to show "unlimited":

  (gdb) set height 0x8000
  (gdb) show height
  Number of lines gdb thinks are in a page is unlimited.

Instead of the current output:
  (gdb) set height 0x8000
  (gdb) show height
  Number of lines gdb thinks are in a page is 32768.

gdb/ChangeLog:
2019-02-27  Pedro Alves  <palves@redhat.com>

* utils.c (set_screen_size): When we cap the height/width sizes,
tweak the corresponding command variable to show "unlimited":

gdb/testsuite/ChangeLog:
2019-02-27  Pedro Alves  <palves@redhat.com>

* gdb.base/page.exp: Add tests for "set/show width/height" with
"infinite" values.

Prevent overflow in rl_set_screen_size

GDB calls rl_set_screen_size in readline with the current screen size,
measured in rows and columns.  To represent "infinite" sizes, GDB
passes in INT_MAX; however, since rl_set_screen_size internally
multiplies the number of rows and columns, this causes a signed
integer overflow.  To prevent this we can instead pass in the
approximate square root of INT_MAX (which is still reasonably large),
so that even when the number of rows and columns is "infinite" we
don't overflow.

gdb/ChangeLog:
2019-02-27  Saagar Jha  <saagar@saagarjha.com>
    Pedro Alves  <palves@redhat.com>

* utils.c (set_screen_size): Reduce "infinite" rows and columns
before calling rl_set_screen_size.

Remove Python 2.4 and 2.5 support

This removes all the remainings spots I could find that work around
issues in Python 2.4 and 2.5.

I don't have a good way to test that Python 2.6 still works.

Tested by the buildbot.

gdb/ChangeLog
2019-02-27  Tom Tromey  <tromey@adacore.com>

* config.in, configure: Rebuild.
* configure.ac (HAVE_LIBPYTHON2_4, HAVE_LIBPYTHON2_5): Never
define.
* python/py-value.c: Remove Python 2.4 workaround.
* python/py-utils.c (gdb_pymodule_addobject): Remove Python 2.4
workaround.
* python/py-type.c (convert_field, gdbpy_initialize_types): Remove
Python 2.4 workaround.
* python/python-internal.h: Remove Python 2.4 comment.
(Py_ssize_t): Don't define.
(PyVarObject_HEAD_INIT, Py_TYPE): Don't define.
(gdb_Py_DECREF): Remove Python 2.4 workaround.
(gdb_PyObject_GetAttrString, PyObject_GetAttrString): Remove.
(gdb_PyObject_HasAttrString, PyObject_HasAttrString): Remove.
* python/python.c (do_start_initialization): Remove Python 2.4
workaround.
* python/py-prettyprint.c (class dummy_python_frame): Remove.
(print_children): Remove Python 2.4 workaround.
* python/py-inferior.c (buffer_procs): Remove Python 2.4
workaround.
(CHARBUFFERPROC_NAME): Remove.
* python/py-breakpoint.c (gdbpy_initialize_breakpoints): Remove
Python 2.4 workaround.

gdb/testsuite/ChangeLog
2019-02-27  Tom Tromey  <tromey@adacore.com>

* lib/gdb.exp (skip_python_tests_prompt): Don't check for Python
2.4.
* gdb.python/py-finish-breakpoint.exp: Remove Python 2.4
workaround.

gdb/ChangeLog
2019-02-27  Tom Tromey  <tromey@adacore.com>

* config.in, configure: Rebuild.
* configure.ac (HAVE_LIBPYTHON2_4, HAVE_LIBPYTHON2_5): Never
define.
* python/py-value.c: Remove Python 2.4 workaround.
* python/py-utils.c (gdb_pymodule_addobject): Remove Python 2.4
workaround.
* python/py-type.c (convert_field, gdbpy_initialize_types): Remove
Python 2.4 workaround.
* python/python-internal.h: Remove Python 2.4 comment.
(Py_ssize_t): Don't define.
(PyVarObject_HEAD_INIT, Py_TYPE): Don't define.
(gdb_Py_DECREF): Remove Python 2.4 workaround.
(gdb_PyObject_GetAttrString, PyObject_GetAttrString): Remove.
(gdb_PyObject_HasAttrString, PyObject_HasAttrString): Remove.
* python/python.c (do_start_initialization): Remove Python 2.4
workaround.
* python/py-prettyprint.c (class dummy_python_frame): Remove.
(print_children): Remove Python 2.4 workaround.
* python/py-inferior.c (buffer_procs): Remove Python 2.4
workaround.
(CHARBUFFERPROC_NAME): Remove.
* python/py-breakpoint.c (gdbpy_initialize_breakpoints): Remove
Python 2.4 workaround.

Document fact that mininum Python version is now 2.6

gdb/ChangeLog:

* NEWS: Note minimum Python version.

gdb/doc/ChangeLog:

* gdb.texinfo (Configure Options): Document minimum python
version.

Use Python 2.[67] / 3.X / PEP 3118 buffer protocol

This patch removes the non-IS_PY3K code in infpy_write_memory()
and infpy_search_memory().  In both cases, the remaining code
from these ifdefs is related to use of the PEP 3118 buffer protocol.
(Deleted code is either due to simplification or related to use of the
old buffer protocol.)  PEP 3118 is sometimes referred to as the "new"
buffer protocol, though it's not that new anymore.

The link below describes new features in Python 2.6.  In particular,
it says that the buffer protocol described by PEP 3118 is in Python
2.6.  It also says (at the top of the page) that Python 2.6 was
released on Oct 1, 2008.

https://docs.python.org/3/whatsnew/2.6.html#pep-3118-revised-buffer-protocol

The last security release for the Python 2.6 series was 2.6.9.  It was
released on Oct 29, 2013.  According to this document...

https://www.python.org/download/releases/2.6.9/

...support for the 2.6 series has ended:

    With the 2.6.9 release, and five years after its first release,
    the Python 2.6 series is now officially retired.  All official
    maintenance for Python 2.6, including security patches, has ended.
    For ongoing maintenance releases, please see the Python 2.7
    series.

As noted earlier, Python 2.6, Python 2.7, and Python 3.X all have
support for the PEP 3118 buffer protocol.  Python releases prior
to 2.6 use an older buffer protocol.  Since Python 2.6 has been
retired for a good while now, it seems reasonable to me to remove
code using the older buffer protocol from GDB.

I have also simplified some of the code via use of the Py_buffer
unique_ptr specialization which I introduced in the two argument
gdb.Value constructor patch series.  Therefore, there is a dependency
on patch #1 from that series.

I have tested against both Python 2.7.15 and 3.7.2.  I see no
regressions among the non-racy tests.  I've also verified that
PyBuffer_Release is being called when the affected functions exit
while running the tests in gdb.python/py-inferior.exp by hand.  I've
also tried running valgrind on GDB while running this test, but I'm
puzzled by the results that I'm seeing - I'm seeing no additional
leaks when I comment out the Py_buffer_up lines that I introduced.
That said, I'm not seeing any leaks that obviously originate from
either infpy_write_memory() or infpy_search_memory().

gdb/ChangeLog:

* python/py-inferior.c (infpy_write_memory): Remove non-IS_PY3K
code from these functions.  Remove corresponding ifdefs.  Use
Py_buffer_up instead of explicit calls to PyBuffer_Release.
Remove gotos and target of gotos.
(infpy_search_memory): Likewise.

gdb/hppa: Use default gdbarch method default_dummy_id.

Make use of the default gdbarch method for gdbarch_dummy_id.

I have not tested this change but, by inspecting the code, I believe
the default method is equivalent to the code being deleted.

gdb/ChangeLog:

* gdb/hppa-tdep.c (hppa_dummy_id): Delete.
(hppa_gdbarch_init): Don't register deleted functions with
gdbarch.

gdb/h8300: Use default gdbarch methods where possible

Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.

I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.

gdb/ChangeLog:

* gdb/h8300-tdep.c (h8300_unwind_pc): Delete.
(h8300_unwind_sp): Delete.
(h8300_dummy_id): Delete.
(h8300_gdbarch_init): Don't register deleted functions with
gdbarch.

gdb/ft32: Use default gdbarch methods where possible

Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.

I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.

gdb/ChangeLog:

* gdb/ft32-tdep.c (ft32_dummy_id): Delete.
(ft32_unwind_pc): Delete.
(ft32_unwind_sp): Delete.
(ft32_gdbarch_init): Don't register deleted functions with
gdbarch.

gdb/frv: Use default gdbarch methods where possible

Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.

I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.

gdb/ChangeLog:

* gdb/frv-tdep.c (frv_dummy_id): Delete.
(frv_unwind_pc): Delete.
(frv_unwind_sp): Delete.
(frv_gdbarch_init): Don't register deleted functions with
gdbarch.

gdb/riscv: Use default gdbarch methods where possible

Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.

This change has been tested with no regressions.

gdb/ChangeLog:

* gdb/riscv-tdep.c (riscv_dummy_id): Delete.
(riscv_unwind_pc): Delete.
(riscv_unwind_sp): Delete.
(riscv_gdbarch_init): Don't register deleted functions with
gdbarch.

gdb/csky: Use default gdbarch methods where possible

Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.

I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.

gdb/ChangeLog:

* gdb/csky-tdep.c (csky_dummy_id): Delete.
(csky_unwind_pc): Delete.
(csky_unwind_sp): Delete.
(csky_gdbarch_init): Don't register deleted functions with
gdbarch.

gdb/cris: Use default gdbarch methods where possible

Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.

I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.

gdb/ChangeLog:

* gdb/cris-tdep.c (cris_dummy_id): Delete.
(cris_unwind_pc): Delete.
(cris_unwind_sp): Delete.
(cris_gdbarch_init): Don't register deleted functions with
gdbarch.

gdb/bfin: Use default gdbarch methods where possible

Make use of the default gdbarch methods for gdbarch_dummy_id,
and gdbarch_unwind_pc.

I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.

gdb/ChangeLog:

* gdb/bfin-tdep.c (bfin_dummy_id): Delete.
(bfin_unwind_pc): Delete.
(bfin_gdbarch_init): Don't register deleted functions with gdbarch.

gdb/arm: Use default gdbarch methods where possible

Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.

I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.

gdb/ChangeLog:

* gdb/arm-tdep.c (arm_dummy_id): Delete.
(arm_unwind_pc): Delete.
(arm_unwind_sp): Delete.
(arm_gdbarch_init): Don't register deleted functions with gdbarch.

gdb/arc: Use default gdbarch methods where possible

Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.

I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.  The
only difference is that the old ARC specific methods had additional
debugging, however, this was discussed on the mailing list[1] and it
was agreed these methods could be removed.

[1] https://sourceware.org/ml/gdb-patches/2018-12/msg00386.html

gdb/ChangeLog:

* gdb/arc-tdep.c (arc_dummy_id): Delete.
(arc_unwind_pc): Delete.
(arc_unwind_sp): Delete.
(arc_gdbarch_init): Don't register deleted functions with gdbarch.

gdb/alpha: Use default gdbarch methods where possible

Make use of the default gdbarch methods for gdbarch_dummy_id, and
gdbarch_unwind_pc.

I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.

gdb/ChangeLog:

* gdb/alpha-tdep.c (alpha_dummy_id): Delete.
(alpha_unwind_pc): Delete.
(alpha_gdbarch_init): Don't register deleted functions with
gdbarch.

gdb/aarch64: Use default gdbarch methods where possible

Make use of the default gdbarch methods for gdbarch_dummy_id,
gdbarch_unwind_pc, and gdbarch_unwind_sp where possible.

I have not tested this change but, by inspecting the code, I believe
the default methods are equivalent to the code being deleted.

gdb/ChangeLog:

* gdb/aarch64-tdep.c (aarch64_dummy_id): Delete.
(aarch64_unwind_pc): Delete.
(aarch64_unwind_sp): Delete.
(aarch64_gdbarch_init): Don't register deleted functions with
gdbarch.

Testsuite: Allow multiple lines of "as" in testsuite.

Committed on behalf of Matthew Malcomson.

This allows checking the command line parsing more easily than before by
allowing many command line invokations from the same .d file.

Each line is used as a set of flags, and the tests are ran against the output
of the assembler with each set.
Each line of assembler is treated as another set of tests (as if the test file
were copied to another with a different #as: line).

This patch includes some example uses where multiple testcases can be merged
into one file using this new functionality.

binutils/ChangeLog:

* testsuite/lib/binutils-common.exp: Allow multiple "as" lines.

gas/ChangeLog:

* testsuite/gas/aarch64/dotproduct.d: Use multiple "as" lines.
* testsuite/gas/aarch64/dotproduct_armv8_4.d: Remove.
* testsuite/gas/aarch64/dotproduct_armv8_4.s: Remove.
* testsuite/gas/aarch64/illegal-dotproduct.d: Use multiple "as"
lines.
* testsuite/gas/aarch64/ldst-rcpc-armv8_2.d: Remove.
* testsuite/gas/aarch64/ldst-rcpc.d: Use multiple "as" lines.

gdb: Handle alignment for C++ structures with static members

In 'type_align' when computing the alignment of a structure we should
not consider the alignment of static structure members, these are
usually stored outside of the structure and therefore don't have any
impact on the structures alignment requirements.

I've extended the existing alignment calculating test to compile in
both C and C++ now so that we can create structures with static
members.

gdb/ChangeLog:

* gdbtypes.c (type_align): Don't consider static members when
computing structure alignment.

gdb/testsuite/ChangeLog:

* gdb.base/align.exp: Extend to compile in both C and C++, and add
tests for structs with static members.

gdb: Restructure type_align and gdbarch_type_align

This commit restructures the relationship between the type_align
function and the gdbarch_type_align method.

The problem being addressed with this commit is this; previously the
type_align function was structured so that for "basic" types (int,
float, etc) the gdbarch_type_align hook was called, which for
"compound" types (arrays, structs, etc) the common type_align code has
a fixed method for how to extract a "basic" type and would then call
itself on that "basic" type.

The problem is that if an architecture wants to modify the alignment
rules for a "compound" type then this is not currently possible.

In the revised structure, all types pass through the
gdbarch_type_align method.  If this method returns 0 then this
indicates that the architecture has no special rules for this type,
and GDB should apply the default rules for alignment.  However, the
architecture is free to provide an alignment for any type, both
"basic" and "compound".

After this commit the default alignment rules now all live in the
type_align function, the default_type_align only ever returns 0,
meaning apply the default rules.

I've updated the 3 targets (arc, i386, and nios2) that already
override the gdbarch_type_align method to fit the new scheme.

Tested on X86-64/GNU Linux with no regressions.

gdb/ChangeLog:

* arc-tdep.c (arc_type_align): Provide alignment for basic types,
return 0 for other types.
* arch-utils.c (default_type_align): Always return 0.
* gdbarch.h: Regenerate.
* gdbarch.sh (type_align): Extend comment.
* gdbtypes.c (type_align): Add additional comments, always call
gdbarch_type_align before applying the default rules.
* i386-tdep.c (i386_type_align): Return 0 as the default rule,
generic code will then apply a suitable default.
* nios2-tdep.c (nios2_type_align): Provide alignment for basic
types, return 0 for other types.

Update NEWS post GDB 8.3 branch creation.

gdb/ChangeLog:

* NEWS: Create a new section for the next release branch.
Rename the section of the current branch, now that it has
been cut.

Bump version to 8.3.50.DATE-git.

Now that the GDB 8.3 branch has been created, we can
bump the version number.

gdb/ChangeLog:

GDB 8.3 branch created (143420fb0d5ae54323ba9953f0818c194635228d):
* version.in: Bump version to 8.3.50.DATE-git.

Fix build errors in aix-thread.c

This patch fixes a few instances of unused variable and shadowed local
variable errors.

gdb/ChangeLog:

* aix-thread.c (ptid_cmp): Remove unused variable.
(get_signaled_thread): Likewise.
(store_regs_user_thread): Likewise.
(store_regs_kernel_thread): Likewise.
(fetch_regs_kernel_thread): Remove shadowed variable.

Automatic date update in version.in

gdb/riscv: Use legacy register numbers in default target description

When the target description support was added to RISC-V, the register
numbers assigned to the fflags, frm, and fcsr control registers in the
default target descriptions didn't match the register numbers used by
GDB before the target description support was added.

What this means is that if a tools exists in the wild that is using
hard-coded register number, setup to match GDB's old numbering, then
this will have been broken (for fflags, frm, and fcsr) by the move to
target descriptions.  QEMU is such a tool.

There are a couple of solutions that could be used to work around this
issue:

 - The user can create their own xml description file with the
   register numbers setup to match their old tool, then load this by
   telling GDB 'set tdesc filename FILENAME'.

 - Update their old tool to use the newer default numbering scheme, or
   better yet add proper target description support to their tool.

 - We could have RISC-V GDB change to maintain the old defaults.

This patch changes GDB back to using the old numbering scheme.

This change is only visible to remote targets that don't supply their
own xml description file and instead rely on GDB's default numbering.

Note that even though 32bit-cpu.xml and 64bit-cpu.xml have changed,
the corresponding .c file has not, this is because the numbering added
to the registers in the xml files is number 0, this doesn't result in
any new C code being generated .

gdb/ChangeLog:

* features/riscv/32bit-cpu.xml: Add register numbers.
* features/riscv/32bit-fpu.c: Regenerate.
* features/riscv/32bit-fpu.xml: Add register numbers.
* features/riscv/64bit-cpu.xml: Add register numbers.
* features/riscv/64bit-fpu.c: Regenerate.
* features/riscv/64bit-fpu.xml: Add register numbers.

Fix new py-value.exp test case

The new test case in py-value.exp fails -- the code was changed to
throw ValueError, but the test still checks for TypeError.  This patch
fixes the problem.

I'm checking this in.  Tested on x86-64 Fedora 29.

gdb/testsuite/ChangeLog
2019-02-26  Tom Tromey  <tromey@adacore.com>

* gdb.python/py-value.exp (test_value_from_buffer): Check for
ValueError, not TypeError.

Document two argument form of gdb.Value constructor

gdb/ChangeLog:

* NEWS: Mention two argument form of gdb.Value constructor.

gdb/doc/ChangeLog:

* python.texi (Values From Inferior): Document second form
of Value.__init__.

Add tests for gdb.Value(bufobj, type) constructor

gdb/testsuite/ChangeLog:

* gdb.python/py-value.exp (test_value_from_buffer): New proc with
call from main program.

Define gdb.Value(bufobj, type) constructor

Provided a buffer BUFOBJ and a type TYPE, construct a gdb.Value object
with type TYPE, where the value's contents are taken from BUFOBJ.

E.g...

(gdb) python import struct
(gdb) python unsigned_int_type=gdb.lookup_type('unsigned int')
(gdb) python b=struct.pack('=I',0xdeadbeef)
(gdb) python v=gdb.Value(b, unsigned_int_type) ; print("%#x" % v)
0xdeadbeef

This two argument form of the gdb.Value constructor may also be used
to obtain gdb values from selected portions of buffers read with
Inferior.read_memory().  The test case (which is in a separate patch)
demonstrates this use case.

gdb/ChangeLog:

* python/py-value.c (convert_buffer_and_type_to_value): New
function.
(valpy_new): Parse arguments via gdb_PyArg_ParseTupleAndKeywords.
Add support for handling an optional second argument.  Call
convert_buffer_and_type_to_value as appropriate.

Define unique_ptr specialization for Py_buffer.

This patch causes PyBuffer_Release() to be called when the associated
buffer goes out of scope.  I've been using it as follows:

 ...
 Py_buffer_up buffer_up;
 Py_buffer py_buf;

 if (PyObject_CheckBuffer (obj)
     && PyObject_GetBuffer (obj, &py_buf, PyBUF_SIMPLE) == 0)
   {
      /* Got a buffer, py_buf, out of obj.  Cause it to released
         when it goes out of scope.  */
     buffer_up.reset (&py_buf);
   }
   ...

This snippet of code was taken directly from an upcoming patch to
python-value.c.

gdb/ChangeLog:

* python/python-internal.h (Py_buffer_deleter): New struct.
(Py_buffer_up): New typedef.

Automatic date update in version.in

Fix BFD leak in dwarf2_get_dwz_file.

Previously if build_id_verify failed, dwz_bfd was cleared to NULL via
release(), but the BFD object was not destroyed.  Use reset() with
nullptr instead to delete the BFD.

gdb/ChangeLog:

* dwarf2read.c (dwarf2_get_dwz_file): Reset dwz_bfd to nullptr
instead of releasing ownership.

Fix crash when loading dwp files

When loading dwp files, we create an array of ELF sections indexed by the ELF
section index in the dwp file. The size of this array is calculated by
section_count, as returned by bfd_count_sections, plus 1 (to account for the
null section at index 0). However, when loading the bfd file, strtab/symtab
sections are not added to the list, nor do they increment section_count, so
section_count is actually smaller than the number of ELF sections.

This happens to work when using GNU dwp, which lays out .debug section first,
with sections like .shstrtab coming at the end. Other tools, like llvm-dwp, put
.strtab first, and gdb crashes when loading those dwp files.

For instance, with the current state of gdb, loading a file like this:
$ readelf -SW <file.dwp>
[ 0] <empty>
[ 1] .debug_foo PROGBITS ...
[ 2] .strtab    STRTAB ...

... results in section_count = 2 (.debug is the only thing placed into
bfd->sections, so section_count + 1 == 2), and sectp->this_idx = 1 when mapping
over .debug_foo in dwarf2_locate_common_dwp_sections, which passes the
assertion that 1 < 2.

However, using a dwp file produced by llvm-dwp:
$ readelf -SW <file.dwp>
[ 0] <empty>
[ 1] .strtab    STRTAB ...
[ 2] .debug_foo PROGBITS ...

... results in section_count = 2 (.debug is the only thing placed into
bfd->sections, so section_count + 1 == 2), and sectp->this_idx = 2 when mapping
over .debug_foo in dwarf2_locate_common_dwp_sections, which fails the assertion
that 2 < 2.

The assertion hit is:

gdb/dwarf2read.c:13009: internal-error: void dwarf2_locate_common_dwp_sections(bfd*, asection*, void*): Assertion `elf_section_nr < dwp_file->num_sections' failed.

This patch changes the calculation of section_count to use elf_numsections,
which should return the actual number of ELF sections.

Fix BFD leak in solib-darwin.c

commit 192b62ce0b4bb5c61188f570e127a26d2c32f716 ("Use class to manage
BFD reference counts") changed darwin_get_dyld_bfd to use:

+ dyld_bfd.release ();

rather than

-      do_cleanups (cleanup);

However, using release here leaks the BFD.  Instead, simply assigning
"sub" to "dyld_bfd" achieves what was meant.

gdb/ChangeLog
2019-02-25  Tom Tromey  <tromey@adacore.com>

* solib-darwin.c (darwin_get_dyld_bfd): Don't release dyld_bfd.

Extend objdump's --dwarf=follow-links option so that separate debug info files will also be affected by other dump function, and symbol tables from separate debug info files will be used when disassembling the main file.

* objdump.c (sym_ok): New function.
(find_symbol_for_address): Use new function.
(disassemble_section): Compare sections by name, not pointer.
(dump_dwarf): Move code to initialise byte_get pointer and iterate
over separate debug files from here to ...
(dump_bfd): ... here.  Add parameter indicating that a separate
debug info file is being dumped.  For main file, pull in the
symbol tables from all separate debug info files.
(display_object): Update call to dump_bfd.
* doc/binutils.texi: Document extened behaviour of the
--dwarf=follow-links option.
* NEWS: Mention this new feature.
* testsuite/binutils-all/objdump.WK2: Update expected output.
* testsuite/binutils-all/objdump.exp (test_follow_debuglink): Add
options and dump file parameters.
Add extra test.
* testsuite/binutils-all/objdump.WK3: New file.
* testsuite/binutils-all/readelf.exp: Change expected output for
readelf -wKis test.
* testsuite/binutils-all/readelf.wKis: New file.

Automatic date update in version.in

Re: PowerPC __tls_get_addr arg parsing

Fixes non-ELF powerpc build failure:
tc-ppc.c:3009:1: error: ‘parse_tls_arg’ defined but not used

* config/tc-ppc.c (parse_tls_arg): Wrap in #ifdef OBJ_ELF.

PR24144, pdp11-ld overwriting section data with zeros

bfd/
PR 24144
* pdp11.c (set_section_contents): Revert 2015-02-24 change.
gas/
PR 24144
* config/obj-aout.c (obj_aout_frob_file_before_fix): Write to end
of section to ensure file contents cover aligned section size.

Automatic date update in version.in

Use '--readnever' when invoking GDB from gcore.in

Back when I proposed the '--readnever' feature, I somehow forgot or
decided not to include the bits related to gcore.in in the original
patch.  This patch finally updates the gcore script to invoke GDB
using '--readnever'.

We've been carrying this patch on Fedora GDB for quite some time, and
as expected the corefiles generated by gcore on Fedora don't have
problems, which I think is the best indicator that the it's safe to
generate corefiles using '--readnever'.

gdb/ChangeLog:
2019-02-23  Sergio Durigan Junior  <sergiodj@redhat.com>

* gcore.in: Add '--readnever' option when invoking GDB.

Update copyright year range in gdb.ada/mi_ref_changeable testcase

This patch fixes the copyright year range which escaped
the 2019 update, because the patch was submitted in 2018, but
only really pushed in 2019.

    Pushed: https://www.sourceware.org/ml/gdb-patches/2019-02/msg00109.html
    Submitted: https://www.sourceware.org/ml/gdb-patches/2018-12/msg00444.html

We normally are pretty good at remembering those little things,
but this one fell through the cracks. This commit fixes this,
by re-running the copyright.py script and checking in the changes
made by that script.

gdb/testsuite/ChangeLog:

* gdb.ada/mi_ref_changeable.exp: Update copyright year range.
* gdb.ada/mi_ref_changeable/foo_rb20_056.adb: Likewise.
* gdb.ada/mi_ref_changeable/pck.adb: Likewise.
* gdb.ada/mi_ref_changeable/pck.ads: Likewise.
* gdb.dwarf2/inlined_subroutine-inheritance.exp: Likewise.

Update copyright year range in gdb.texinfo and refcard.tex

I missed those files which need to be updated manually when I did
the copyright year range update. The copyright.py script reminds
us of that fact with the following message at the end...

    REMINDER: Multiple copyright headers must be updated by hand:
       gdb/doc/gdb.texinfo
       gdb/doc/refcard.tex
       gdb/gdbarch.sh

... and somehow I missed this. This commit makes the change for
gdb.texinfo and refcard.tex. gdbarch.sh is being updated separately
by Andrew Burgess.

gdb/doc/ChangeLog:

* gdb.texinfo: Update copyright year ranges.
* refcard.tex: Likewise.

Automatic date update in version.in

Update my email address

Since this is my last day at Ericsson, I am changing my email for my
personal one in the MAINTAINERS file.

Look for build-id-based separate debug files under the sysroot

When looking for a separate debug file that matches a given build-id,
GDB only looks in the host's debug dir (typically /usr/lib/debug).  This
patch makes it look in the sysroot as well.  This is to match the
behavior of GDB when using debuglink-based separate debug files,
introduced in :

402d2bfec42 ("Look for separate debug files in debug directories under a sysroot.")

In the following example, my sysroot is "/tmp/sysroot" and I am trying
to load symbols for
/tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so.  This is
the current behavior:

    (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so
    Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so...

    Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so
      Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path

    <snip>
    (No debugging symbols found in /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so)

With this patch:

    (gdb) file /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so
    Reading symbols from /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so...

    Looking for separate debug info (build-id) for /tmp/sysroot/usr/lib/arm-linux-gnueabihf/gconv/EBCDIC-AT-DE.so
      Trying /usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... no, unable to compute real path
      Trying /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug... yes!
    Reading symbols from /tmp/sysroot/usr/lib/debug/.build-id/f3/d6594d2600e985812cd4ba2ad083ac2aceae22.debug...

In the original code, there is a suspicious "abfd.release ()" in
build_id_to_debug_bfd, that I don't understand.  If a file with the
right name exists but its build-id note doesn't match, we release (leak)
our reference, meaning the file will stay open?  I removed it in the new
code, so that the reference is dropped if we end up not using that file.
I tested briefly by corrupting a separate debug file to trigger this
code, nothing exploded.

gdb/ChangeLog:

* build-id.c (build_id_to_debug_bfd_1): New function.
(build_id_to_debug_bfd): Look for separate debug file in
sysroot.

gdb: Update copyright year range generated by gdbarch.sh

The copyright year that gdbarch.sh places into the generated files
gdbarch.{c,h} wasn't updated at the start of the year.  After this
commit the gdbarch.{c,h} files regenerate as the currently are in the
tree.

gdb/ChangeLog:

* gdbarch.sh: Update the copyright year range that is placed into
generated files.

Add missing ChangeLog entries for commit bb995d00b3eef2f48d0be895c3509a7ddd8280a1

Fix symtab/23853: symlinked default symtab

This patch attempts to fix a bug dealing with setting breakpoints
in default symtabs that are symlinks.  For example:

(gdb) list
11    GNU General Public License for more details.
12
13    You should have received a copy of the GNU General Public License
14    along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
15
16 static int
17 foo (void)
18 {
19   return 0; /* break here  */
20 }
(gdb)
21
22 int
23 main (void)
24 {
25   return foo ();
26 }
(gdb) b 19
No line 19 in the current file.
Make breakpoint pending on future shared library load? (y or [n])

The problem here is that when create_sals_line_offset sets the default
symtab, it immediately calls symtab_to_fullname, passing that fullname
to collect_symtabs_from_filename to find all matching symtabs.  This
fails because we end up looking for a symtab with the name of the
actual file on disk (which is different in this case because of the
symlink) instead of the one stored in the debug info.

Since we already have the lookup name of the default symtab, use it
instead of the fullname. [This fullname thing was originally added
in 2007 in a series dealing with *displaying* absolute file names.
Clearly, this instance has nothing to do with the display of file names.]

gdb/ChangeLog

PR symtab/23853
* linespec.c (create_sals_line_offset): Search for the default
symtab's filename instead of its fullname.

gdb/testsuite/ChangeLog

PR symtab/23853
* gdb.base/symlink-sourcefile.c: New file.
* gdb.base/symlink-sourcefile.exp: New file.

Extend readelf and objdump so that they will display and follow multiple links to separate debug information files.

PR 23843
* dwarf.h (struct separate_info): New structure for containing
information on separate debug info files.
* dwarf.c (struct dwo_info): New structure for containing dwo
links.
(first_dwo_info): Chain of dwo_info structures.
(first_separate_file): Chain of separate_info structures.
(separate_debug_file, separate_debug_filename): Delete.
(fetch_alt_indirect_string): Scan all separate debug info files
for the requested string.
(add_dwo_info): New function.
(add_dwo_name): New function.
(add_dwo_dir): New function.
(add_dwo_id: New function.
(free_dwo_info): New function.
(read_and_display_attr_value): Store DWO data using the new
functions.
(load_debug_section_with_follow): If necessary, scan the list of
separate debug info files for the requested section.
(add_separate_debug_file): New function.
(load_separate_debug_info): Call add_separate_debug_file to store
the information on the newly loaded file.
(load_dwo_file): Likewise.
(load_separate_debif_file): Rename to load_separate_debug_files.
Change return type to boolean.  If following links then attempt to
load all separate debug info files, not just the first one.
(free_debug_memory): Release memory in dwo_info and separate_info
chains.
* objdump.c (dump_dwarf): Iterate over all loaded debg info files.
* readelf.c (process_object): Likewise.
* doc/debug.options.texi: Update descriptions of links and
follow-links options.
* testsuite/binutils-all/objdump.WK2: Update expected output.
* testsuite/binutils-all/readelf.k2: Likewise.
* NEWS: Announce the new feature.

[arm][gas] Add support for Neoverse N1

This adds support for the Neoverse N1 CPU [1] to gas.
This was previously enabled under the Ares codename, which remains as
a valid option for -mcpu for compatibility reasons.

make check-gas passes on arm-none-eabi.

[1] https://community.arm.com/processors/b/blog/posts/arm-neoverse-n1-platform-accelerating-the-transformation-to-a-scalable-cloud-to-edge-infrastructure

2019-02-21  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

    * config/tc-arm.c (arm_cpus): Add neoverse-n1.
    * doc/c-arm.texi (-mcpu): Document neoverse-n1 value.

[AArch64][gas] Add support for Neoverse E1

This adds support for the Neoverse E1 CPU [1] to gas.

make check-gas passes on aarch64-none-elf.

[1] https://community.arm.com/processors/b/blog/posts/arm-neoverse-e1-platform-empowering-the-infrastructure-to-meet-next-generation-throughput-demands

2019-02-21  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

    * config/tc-aarch64.c (aarch64_cpus): Add neoverse-e1.
    * doc/c-aarch64.texi (-mcpu): Document neoverse-e1 value.

[AArch64][gas] Add support for Neoverse N1

This adds support for the Neoverse N1 [1] CPU to gas.
This was previously enabled under the Ares codename, which remains as
a valid option for -mcpu for compatibility reasons.

make check-gas passes on aarch64-none-elf.

[1] https://community.arm.com/processors/b/blog/posts/arm-neoverse-n1-platform-accelerating-the-transformation-to-a-scalable-cloud-to-edge-infrastructure

2019-02-21  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

    * config/tc-aarch64.c (aarch64_cpus): Add neoverse-n1.
    * doc/c-aarch64.texi (-mcpu): Document neoverse-n1 value.

Automatic date update in version.in

Document style behavior in batch mode.

Style is disabled when running in batch mode.

gdb/ChangeLog:

* NEWS: Update style defaults.

gdb/doc/ChangeLog:

* gdb.texinfo: Update style defaults.

Fix typo in "show remotelogfile" docs

I noticed a trailing "." in the @item for "show remotelogfile".
This removes it.  Committing as obvious.

gdb/doc/ChangeLog
2019-02-21  Tom Tromey  <tromey@adacore.com>

* gdb.texinfo (Remote Configuration): Remove trailing "." from
@item.

Disable styling when running in batch mode

The GCC Guality testsuite within GCC compiles C/C++ files in GCC at
various optimization levels then debugs them in GDB, checking that
program values can be read.  This is done within the dejagnu framework.

The new style options in GDB have broken many of the tests due to the
testsuite being unable to process the new control characters.  The fix
in Guality is to either to improve the string matching or to disable
styling on the cli or init file (after checking gdb is recent enough
to support styling).

This fix will also need making an any other testsuites in the wild
that use GDB.

An alternative would be to automatically disable styling when using GDB
in batch mode.  The reasoning here is that batch mode is only used when
automating GDB and any output will be processed later either with text
processing tools or viewed in text editors, many of these will not
correctly handle the control characters by default.  This ensures GDB
continues to work as expected.  Anyone who explicitly wants styling in
batch mode can enable it either in the init file or adding to the batch
file - but that would not be the standard use case.

Patch simply disables style after reading the batch command flag, before
reading in the init file or batch file.

gdb/ChangeLog:

* main.c (captured_main_1): Disable styling in batch mode.

Fix illegal memory accesses by readelf when parsing corrupt IA64 unwind information.

PR 24247
* unwind-ia64.c: Include sysdep.h.
(unw_decode_x1): Check current pointer against end pointer before
accessing memory.
(unw_decode_x2): Likewise.
(unw_decode_x3): Likewise.
(unw_decode_x4): Likewise.
(unw_decode_r2): Likewise.
(unw_decode_p2_p5): Likewise.
(unw_decode_p7_p10): Likewise.
(unw_decode): Likewise.

PowerPC __tls_get_addr arg parsing

The syntax we ended up with for -m32 -fPIC calls to __tls_get_addr is
rather weird.
    bl __tls_get_addr+0x8000(gd0@tlsgd)@plt
This came about by accident, probably due to requiring the arg reloc
before the call reloc.

Of course the @plt really belongs with __tls_get_addr since it affects
the call rather than the call arg, and it isn't a great deal of
trouble to ensure the relocs are emitted in the correct order.  This
patch supports a newer syntax, like so:
    bl __tls_get_addr+0x8000@plt(gd0@tlsgd)

gas/
* config/tc-ppc.c (parse_tls_arg): New function, extracted..
(md_assembler): ..from here.  Call it after parsing other
suffix modifiers too.
ld/
* testsuite/ld-powerpc/tls32.s: Test new @plt syntax.

Automatic date update in version.in

Fix typos in symtab_symbol_info

symtab_symbol_info has a couple of messages that say "regulation
expression".  I think "regular expression" was meant, so this patch
changes it.

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

* symtab.c (symtab_symbol_info): Fix typos.

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

* gdb.base/info_qt.exp: Update.

Fix potential illegal memory access by readelf when parsing a binary containing corrupt system tap notes.

PR 24246
* readelf.c (print_stapsdt_note): Harden against corrupt notes.

Fix potential illegal memory access by readelf when parsing corrupt IA64 unwind information.

PR 24244
* unwind-ia64.c (unw_decode_uleb128): Add end parameter, use it to
prevent walking off the end of the buffer.
(unw_decode_x1): Add end paramter, pass it to unw_decode_uleb128.
(unw_decode_x2): Likewise.
(unw_decode_x3): Likewise.
(unw_decode_x4): Likewise.
(unw_decode_r2): Pass the end parameter to unw_decode_uleb128.
(unw_decode_r3): Likewise.
(unw_decode_p7_p10): Likewise.
(unw_decode_b2): Likewise.
(unw_decode_b3_x4): Likewise.

Fix a illegal memory access fault when parsing a corrupt MIPS option section using readelf.

PR 24243
* readelf.c (process_mips_specific): Check for an options section
that is too small to even contain a single option.

Harden readelf's IA64 note display function so that it can handle corrupt notes.

PR 24242
* readelf.c (print_ia64_vms_note): Harden against corrupt notes.

Use upper case for metasyntactic variables in "help find"

While answering a user's question on irc, I realized that the
metasyntactic variables in "help find" are not in upper case.  As you
know this is one of my pet quests, so here is a patch to fix this.
Tested on x86-64 Fedora 29.

gdb/ChangeLog
2019-02-20  Tom Tromey  <tromey@adacore.com>

* findcmd.c (_initialize_mem_search): Use upper case for
metasyntactic variables.

AArch64: Add default reggroups

AArch64 does not define any reggroups.  This causes "maintenance print
reggroups" to dump the default set (which is ok).

However, if a new group is added via an xml file, then this now becomes
the only group.

Fixes gdb.xml/tdesc-regs.exp on AArch64.

gdb/ChangeLog:

* aarch64-tdep.c (aarch64_add_reggroups): New function
(aarch64_gdbarch_init): Call aarch64_add_reggroups.

bfd: xtensa: fix callx relaxation

Big section alignment requirements between source and destination of a
long call can result in making call range bigger than what's reachable
by the call opcode. Add biggest section alignment of sections between
the call site and call destination to the call distance when making
long call relaxation decision.

2019-02-20  Eric Tsai  <erictsai@cadence.com>
bfd/
* elf32-xtensa.c (is_resolvable_asm_expansion): Scan output
sections between the call site and call destination and adjust
call distance by the largest alignment.

ld/
* testsuite/ld-xtensa/call_overflow.d: New test definition.
* testsuite/ld-xtensa/call_overflow1.s: New test source.
* testsuite/ld-xtensa/call_overflow2.s: New test source.
* testsuite/ld-xtensa/call_overflow3.s: New test source.
* testsuite/ld-xtensa/xtensa.exp: Add call_overflow test.

AArch64: Add pauth core file section

Used for the AArch64 pointer authentication code mask registers in Arm v8.3-a.

NT_ARM_PAC_MASK matches the value in Linux include/uapi/linux/elf.h

include/ChangeLog:

* elf/common.h (NT_ARM_PAC_MASK): Add define.

bfd/ChangeLog:

* elf-bfd.h (elfcore_write_aarch_pauth): Add declaration.
* elf.c (elfcore_grok_aarch_pauth): New function.
(elfcore_grok_note): Check for NT_ARM_PAC_MASK.
(elfcore_write_aarch_pauth): New function.
(elfcore_write_register_note): Check for AArch64 pauth section.

Check asprintf return value

git a31b8bd9a05 introduced a warning (depending on your system
headers).

PR 24225
* elf32-nios2.c (nios2_elf32_relocate_section): Check asprintf
return value.

Unsigned integer overflows in readelf checks

PR 24132
PR 24138
* readelf.c (get_data): Avoid possibility of overflow when
checking for a read that may extend past end of file.
(process_program_headers): Likewise.

Use or1k-darwin host SHARED_LIBADD for *-darwin.

* configure.ac (SHARED_LIBADD): Add -liberty -lintl for all
Darwin hosts, not just or1k.
* configure: Regenerate.

PR24233, Out of memory

PR 24233
* objdump.c (dump_bfd_private_header): Print warning if
bfd_print_private_bfd_data returns false.

Fix error message and use-after-free on errors in nested sourced files

Errors that happen in nested sourced files (when a sourced file sources
another file) lead to a wrong error message, or use-after-free.

For example, if I put this in "a.gdb":

    command_that_doesnt_exist

and this in "b.gdb":

   source a.gdb

and try to "source b.gdb" in GDB, the result may look like this:

    (gdb) source b.gdb
    b.gdb:1: Error in sourced command file:
    _that_doesnt_exist:1: Error in sourced command file:
    Undefined command: "command_that_doesnt_exist".  Try "help".

Notice the wrong file name where "a.gdb" should be.  The exact result
may differ, depending on the feelings of the memory allocator.

What happens is:

- The "source a.gdb" command is saved by command_line_append_input_line
  in command_line_input's static buffer.
- Since we are sourcing a file, the script_from_file function stores the
  script name (a.gdb) in the source_file_name global.  However, it doesn't
  do a copy, it just saves a pointer to command_line_input's static buffer.
- The "command_that_doesnt_exist" command is saved by
  command_line_append_input_line in command_line_input's static buffer.
  Depending on what xrealloc does, source_file_name may now point to
  freed memory, or at the minimum the data it was pointing to was
  overwritten.
- When the error is handled in script_from_file, we dererence
  source_file_name to print the name of the file in which the error
  occured.

To fix it, I made source_file_name an std::string, so that keeps a copy of
the file name instead of pointing to a buffer with a too small
lifetime.

With this patch, the expected filename is printed, and no use-after-free
occurs:

    (gdb) source b.gdb
    b.gdb:1: Error in sourced command file:
    a.gdb:1: Error in sourced command file:
    Undefined command: "command_that_doesnt_exist".  Try "help".

I passed explicit template parameters to make_scoped_restore
(<std::string, const std::string &>), so that the second parameter is
passed by reference and avoid a copy.

It was not as obvious as I first thought to change gdb.base/source.exp
to test this, because source commands inside sourced files are
interpreted relative to GDB's current working directory, not the
directory of the currently sourced file.  As a workaround, I moved the
snippet that tests errors after the snippet that adds the source
directory to the search path.  This way, the "source source-error-1.gdb"
line in source-error.exp manages to find the file.

For reference, here is what ASAN reports when use-after-free occurs:

(gdb) source b.gdb
=================================================================
==18498==ERROR: AddressSanitizer: heap-use-after-free on address 0x60c000019847 at pc 0x7f1d3645de8e bp 0x7ffdcb892e50 sp 0x7ffdcb8925c8
READ of size 6 at 0x60c000019847 thread T0
    #0 0x7f1d3645de8d in printf_common /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:546
    #1 0x7f1d36477175 in __interceptor_vasprintf /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:1525
    #2 0x5632eaffa277 in xstrvprintf(char const*, __va_list_tag*) /home/simark/src/binutils-gdb/gdb/common/common-utils.c:122
    #3 0x5632eaff96d1 in throw_it /home/simark/src/binutils-gdb/gdb/common/common-exceptions.c:351
    #4 0x5632eaff98df in throw_verror(errors, char const*, __va_list_tag*) /home/simark/src/binutils-gdb/gdb/common/common-exceptions.c:379
    #5 0x5632eaff9a2a in throw_error(errors, char const*, ...) /home/simark/src/binutils-gdb/gdb/common/common-exceptions.c:394
    #6 0x5632eafca21a in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1553
    #7 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
    #8 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
    #9 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
    #10 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
    #11 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
    #12 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
    #13 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
    #14 0x5632ebf3cf09 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:425
    #15 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547
    #16 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
    #17 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
    #18 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
    #19 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
    #20 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
    #21 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
    #22 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
    #23 0x5632eb3b2f87 in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/simark/src/binutils-gdb/gdb/event-top.c:770
    #24 0x5632eb3b0fe1 in gdb_rl_callback_handler /home/simark/src/binutils-gdb/gdb/event-top.c:213
    #25 0x5632ec1c8729 in rl_callback_read_char /home/simark/src/binutils-gdb/readline/callback.c:220
    #26 0x5632eb3b0b8f in gdb_rl_callback_read_char_wrapper_noexcept /home/simark/src/binutils-gdb/gdb/event-top.c:175
    #27 0x5632eb3b0da1 in gdb_rl_callback_read_char_wrapper /home/simark/src/binutils-gdb/gdb/event-top.c:192
    #28 0x5632eb3b2186 in stdin_event_handler(int, void*) /home/simark/src/binutils-gdb/gdb/event-top.c:511
    #29 0x5632eb3aa6a9 in handle_file_event /home/simark/src/binutils-gdb/gdb/event-loop.c:733
    #30 0x5632eb3aaf41 in gdb_wait_for_event /home/simark/src/binutils-gdb/gdb/event-loop.c:859
    #31 0x5632eb3a88ea in gdb_do_one_event() /home/simark/src/binutils-gdb/gdb/event-loop.c:347
    #32 0x5632eb3a89bf in start_event_loop() /home/simark/src/binutils-gdb/gdb/event-loop.c:371
    #33 0x5632eb76fbfc in captured_command_loop /home/simark/src/binutils-gdb/gdb/main.c:330
    #34 0x5632eb772ea8 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1176
    #35 0x5632eb773071 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1192
    #36 0x5632eabfe7f9 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
    #37 0x7f1d3554f222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)
    #38 0x5632eabfe5dd in _start (/home/simark/build/binutils-gdb/gdb/gdb+0x195d5dd)

0x60c000019847 is located 7 bytes inside of 128-byte region [0x60c000019840,0x60c0000198c0)
freed by thread T0 here:
    #0 0x7f1d36502491 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:105
    #1 0x5632eaff9f47 in xrealloc /home/simark/src/binutils-gdb/gdb/common/common-utils.c:62
    #2 0x5632eaff6b44 in buffer_grow(buffer*, char const*, unsigned long) /home/simark/src/binutils-gdb/gdb/common/buffer.c:40
    #3 0x5632eb3b271d in command_line_append_input_line /home/simark/src/binutils-gdb/gdb/event-top.c:614
    #4 0x5632eb3b28c6 in handle_line_of_input(buffer*, char const*, int, char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:654
    #5 0x5632ebf402a6 in command_line_input(char const*, char const*) /home/simark/src/binutils-gdb/gdb/top.c:1252
    #6 0x5632ebf3cee9 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:422
    #7 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547
    #8 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
    #9 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
    #10 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
    #11 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
    #12 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
    #13 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
    #14 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
    #15 0x5632ebf3cf09 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:425
    #16 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547
    #17 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
    #18 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
    #19 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
    #20 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
    #21 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
    #22 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
    #23 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
    #24 0x5632eb3b2f87 in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/simark/src/binutils-gdb/gdb/event-top.c:770
    #25 0x5632eb3b0fe1 in gdb_rl_callback_handler /home/simark/src/binutils-gdb/gdb/event-top.c:213
    #26 0x5632ec1c8729 in rl_callback_read_char /home/simark/src/binutils-gdb/readline/callback.c:220
    #27 0x5632eb3b0b8f in gdb_rl_callback_read_char_wrapper_noexcept /home/simark/src/binutils-gdb/gdb/event-top.c:175
    #28 0x5632eb3b0da1 in gdb_rl_callback_read_char_wrapper /home/simark/src/binutils-gdb/gdb/event-top.c:192
    #29 0x5632eb3b2186 in stdin_event_handler(int, void*) /home/simark/src/binutils-gdb/gdb/event-top.c:511

previously allocated by thread T0 here:
    #0 0x7f1d36502491 in __interceptor_realloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:105
    #1 0x5632eaff9f47 in xrealloc /home/simark/src/binutils-gdb/gdb/common/common-utils.c:62
    #2 0x5632eaff6b44 in buffer_grow(buffer*, char const*, unsigned long) /home/simark/src/binutils-gdb/gdb/common/buffer.c:40
    #3 0x5632eb3b271d in command_line_append_input_line /home/simark/src/binutils-gdb/gdb/event-top.c:614
    #4 0x5632eb3b28c6 in handle_line_of_input(buffer*, char const*, int, char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:654
    #5 0x5632ebf402a6 in command_line_input(char const*, char const*) /home/simark/src/binutils-gdb/gdb/top.c:1252
    #6 0x5632ebf3cee9 in read_command_file(_IO_FILE*) /home/simark/src/binutils-gdb/gdb/top.c:422
    #7 0x5632eafca054 in script_from_file(_IO_FILE*, char const*) /home/simark/src/binutils-gdb/gdb/cli/cli-script.c:1547
    #8 0x5632eaf8a500 in source_script_from_stream /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:569
    #9 0x5632eaf8a735 in source_script_with_search /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:605
    #10 0x5632eaf8ab20 in source_command /home/simark/src/binutils-gdb/gdb/cli/cli-cmds.c:664
    #11 0x5632eafa8b4a in do_const_cfunc /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:106
    #12 0x5632eafb0687 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:1892
    #13 0x5632ebf3dd87 in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:630
    #14 0x5632eb3b25d3 in command_handler(char const*) /home/simark/src/binutils-gdb/gdb/event-top.c:583
    #15 0x5632eb3b2f87 in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /home/simark/src/binutils-gdb/gdb/event-top.c:770
    #16 0x5632eb3b0fe1 in gdb_rl_callback_handler /home/simark/src/binutils-gdb/gdb/event-top.c:213
    #17 0x5632ec1c8729 in rl_callback_read_char /home/simark/src/binutils-gdb/readline/callback.c:220
    #18 0x5632eb3b0b8f in gdb_rl_callback_read_char_wrapper_noexcept /home/simark/src/binutils-gdb/gdb/event-top.c:175
    #19 0x5632eb3b0da1 in gdb_rl_callback_read_char_wrapper /home/simark/src/binutils-gdb/gdb/event-top.c:192
    #20 0x5632eb3b2186 in stdin_event_handler(int, void*) /home/simark/src/binutils-gdb/gdb/event-top.c:511
    #21 0x5632eb3aa6a9 in handle_file_event /home/simark/src/binutils-gdb/gdb/event-loop.c:733
    #22 0x5632eb3aaf41 in gdb_wait_for_event /home/simark/src/binutils-gdb/gdb/event-loop.c:859
    #23 0x5632eb3a88ea in gdb_do_one_event() /home/simark/src/binutils-gdb/gdb/event-loop.c:347
    #24 0x5632eb3a89bf in start_event_loop() /home/simark/src/binutils-gdb/gdb/event-loop.c:371
    #25 0x5632eb76fbfc in captured_command_loop /home/simark/src/binutils-gdb/gdb/main.c:330
    #26 0x5632eb772ea8 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1176
    #27 0x5632eb773071 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1192
    #28 0x5632eabfe7f9 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
    #29 0x7f1d3554f222 in __libc_start_main (/usr/lib/libc.so.6+0x24222)

SUMMARY: AddressSanitizer: heap-use-after-free /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc:546 in printf_common

gdb/ChangeLog:

* top.h (source_file_name): Change to std::string.
* top.c (source_file_name): Likewise.
(command_line_input): Adjust.
* cli/cli-script.c (script_from_file): Adjust.

gdb/testsuite/ChangeLog:

* gdb.base/source.exp: Move "error in sourced script" code to
the end.
* gdb.base/source-error.gdb: Move contents to
source-error-1.gdb.  Add new code to source source-error-1.gdb.
* gdb.base/source-error-1.gdb: New file, from previous
source-error.gdb.

PR24236, Heap buffer overflow in _bfd_archive_64_bit_slurp_armap

PR 24236
* archive64.c (_bfd_archive_64_bit_slurp_armap): Move code adding
sentinel NUL to string buffer nearer to loop where it is used.
Don't go past sentinel when scanning strings, and don't write
NUL again.
* archive.c (do_slurp_coff_armap): Simplify string handling to
archive64.c style.

Check whether symbols with MOVW_.ABS relocations require PLT entries (aarch64).

2019-02-19  Egeyar Bagcioglu  <egeyar.bagcioglu@oracle.com>

gold/
     PR gold/23870
     * aarch64.cc (Target_aarch64::Scan::global): Check if a symbol with
     R_AARCH64_MOVW_.ABS_* relocations requires a PLT entry.
     * testsuite/Makefile.am: Add aarch64_pr23870 test case.
     * testsuite/Makefile.in: Regenerate.
     * testsuite/aarch64_pr23870_bar.c: New file.
     * testsuite/aarch64_pr23870_foo.c: New file.
     * testsuite/aarch64_pr23870_main.S: New file.

Automatic date update in version.in

Minor Ada task cleanups

While working on the Ada task code, I noticed a few things that could
be cleaned up:

* task_list_valid_p was not set in all cases in ada_build_task_list.
  This causes many needless re-fetches of the task list.

* task_list_valid_p can be bool, and various functions can also return
  bool.

* Nothing checks the return value of read_known_tasks, so it can be
  changed to return void.

* The call to ada_build_task_list in
  ravenscar_thread_target::update_thread_list is redundant, because
  this is the first thing done by iterate_over_live_ada_tasks.

Tested using the internal AdaCore test suite against a ravenscar
target.

gdb/ChangeLog
2019-02-19  Tom Tromey  <tromey@adacore.com>

* ravenscar-thread.c
(ravenscar_thread_target::update_thread_list): Don't call
ada_build_task_list.
* ada-lang.h (ada_build_task_list): Don't declare.
* ada-tasks.c (struct ada_tasks_inferior_data)
<task_list_valid_p>: Now bool.
(read_known_tasks, ada_task_list_changed)
(ada_tasks_invalidate_inferior_data): Update.
(read_known_tasks_array): Return bool.
(read_known_tasks_list): Likewise.
(read_known_tasks): Return void.
(ada_build_task_list): Now static.

Fix a potential deadlock in some older Loongson 3A1000 MIPS processors.

* NEWS: Mention -m[no-]fix-loongson3-llsc.
* configure.ac: Add --enable-mips-fix-loongson3-llsc.
Define DEFAULT_MIPS_FIX_LOONGSON3_LLSC.
* config.in: Regenerated.
* configure: Likewise.
* config/tc-mips.c (sync_insn, mips_fix_loongson3_llsc):
New variables.
(options): New OPTION_FIX_LOONGSON3_LLSC,
OPTION_NO_FIX_LOONGSON3_LLSC.
(md_longopts): Add -m[no-]fix-loongson3-llsc.
(md_begin): Initialize sync insn.
(fix_loongson3_llsc): New.
(append_insn): Call fix_loongson3_llsc.
(md_parse_option): Handle OPTION_FIX_LOONGSON3_LLSC,
OPTION_NO_FIX_LOONGSON3_LLSC.
(md_show_usage): Display -m[no-]fix-loongson3-llsc.
* doc/c-mips.texi: Document -m[no-]fix-loongson3-llsc,
--enable-mips-fix-loongson3-llsc=[yes|no].

PR24235, Read memory violation in pei-x86_64.c

PR 24235
* pei-x86_64.c (pex64_bfd_print_pdata_section): Correct checks
attempting to prevent read past end of section.

Automatic date update in version.in

gdb: Allow gdbarch to override alignment for method and member pointers

The code in type_align (gdbtypes.c) currently hard-codes the rules for
aligning method and member pointers.  It would seem better to forward
these types through the gdbarch hook, so that an architecture could
override the alignment of these types if needed.

Only 3 architectures currently override the gdbarch alignment hook,
these are arc, i386, and nio2.

For arc and nios the alignment rules are that alignment is the minimum
of 4-bytes and the type length.  As pointers are 4-bytes on these
targets, then (assuming method and members pointers are also 4-bytes)
there should be no change to the alignment after this patch.

For i386 the gdbarch alignment hook overrides for some INT and FLOAT
types only.  For method and member pointers we align on the type size
still, so there should be no change to the alignment after this patch.

I tested this on x86-64 GNU Linux with no regressions.

gdb/ChangeLog:

* gdbtypes.c (type_align): Allow alignment of TYPE_CODE_METHODPTR
and TYPE_CODE_MEMBERPTR to be overridden by the gdbarch.

Fix leaks of 'per program space' and 'per inferior' ada task data.

Valgrind reports leaks such as the below.
Fix these leaks by changing ada_tasks_pspace_data_handle
and ada_tasks_inferior_data_handle to use the 'with_cleanup' register variant.

Tested on debian/amd64 natively and under Valgrind.

==26346== 56 bytes in 1 blocks are definitely lost in loss record 631 of 3,249
==26346==    at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344)
==26346==    by 0x38F911: get_ada_tasks_inferior_data(inferior*) (ada-tasks.c:281)
==26346==    by 0x38FA3F: ada_tasks_invalidate_inferior_data (ada-tasks.c:1362)
==26346==    by 0x38FA3F: ada_tasks_new_objfile_observer(objfile*) (ada-tasks.c:1411)
==26346==    by 0x60CBC5: operator() (functional:2127)
==26346==    by 0x60CBC5: notify (observable.h:106)
==26346==    by 0x60CBC5: clear_symtab_users(enum_flags<symfile_add_flag>) (symfile.c:2903)
...

==26346== 104 bytes in 1 blocks are definitely lost in loss record 984 of 3,249
==26346==    at 0x4C2E0BC: calloc (vg_replace_malloc.c:762)
==26346==    by 0x4056F0: xcalloc (common-utils.c:84)
==26346==    by 0x38F8AE: xcnew<ada_tasks_pspace_data> (poison.h:122)
==26346==    by 0x38F8AE: get_ada_tasks_pspace_data(program_space*) (ada-tasks.c:253)
==26346==    by 0x38FA77: ada_tasks_invalidate_pspace_data (ada-tasks.c:1354)
==26346==    by 0x38FA77: ada_tasks_new_objfile_observer(objfile*) (ada-tasks.c:1394)
==26346==    by 0x60CBC5: operator() (functional:2127)
==26346==    by 0x60CBC5: notify (observable.h:106)
...

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

* ada-task.c (_initialize_tasks): Use 'with_cleanup' register
variant for ada_tasks_pspace_data_handle and
ada_tasks_inferior_data_handle.
(ada_tasks_pspace_data_cleanup): New function.
(ada_tasks_inferior_data_cleanup): New function.

PR24225, nios2 buffer overflow

PR 24225
* elf32-nios2.c (nios2_elf32_relocate_section): Use asprintf and
PRIx64 to generate warning messages.  Print local sym names too.

Automatic date update in version.in

Change macro_source_fullname to return a std::string

While working on the previous patch, I noticed that if
macro_source_fullname returned a std::string, then the callers would
be simplified.  This patch implements this idea.

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

* macrotab.h (macro_source_fullname): Return a std::string.
* macrotab.c (macro_include, check_for_redefinition)
(macro_undef, macro_lookup_definition, foreach_macro)
(foreach_macro_in_scope): Update.
(macro_source_fullname): Return a std::string.
* macrocmd.c (show_pp_source_pos): Update.

Add styling to macro commands

This adds filename styling to "info macro".

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

* macrocmd.c (show_pp_source_pos): Style the file names.

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

* gdb.base/style.exp: Use -g3 to compile when possible.  Add test
for macro styling.
* gdb.base/style.c (SOME_MACRO): New macro.

Fix some valgrind errors in the TUI

The styling series introduced some new errors in the TUI -- the series
changed how source lines are allocated, without updating
tui_set_source_content_nil.

There are several failures but a typical one looks like:

==6274== Use of uninitialised value of size 8
==6274==    at 0x4E4A095: wclrtoeol (in /usr/lib64/libncursesw.so.6.1)
==6274==    by 0x4E47617: waddch (in /usr/lib64/libncursesw.so.6.1)
==6274==    by 0x8325CB: tui_puts_internal(_win_st*, char const*, int*) (tui-io.c:393)
==6274==    by 0x82E89D: tui_file::puts(char const*) (tui-file.c:39)
==6274==    by 0x84BF5F: vfprintf_unfiltered(ui_file*, char const*, __va_list_tag*) (utils.c:2026)

This patch rewrites tui_set_source_content_nil, fixing the bug.

This was also reported as PR tui/24197.

Verified by running valgrind before and after on x86-64 Fedora 29.

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

PR tui/24197:
* tui/tui-source.c (tui_set_source_content_nil): Rewrite.