gdb/fortran: Use TYPE_CODE_CHAR for character types

Switch to using TYPE_CODE_CHAR for character types.  This appears to
have little impact on the test results as gFortran uses the
DW_TAG_string_type to represent all character variables (as far as I
can see).  The only place this has an impact is when the user casts a
variable to a character type, in which case GDB does now use the CHAR
type, and prints the variable as both a value and a character, for
example, before:

    (gdb) p ((character) 97)
    $1 = 97

and after:

    (gdb) p ((character) 97)
    $1 = 97 'a'

gdb/ChangeLog:

* f-lang.c (build_fortran_types): Use TYPE_CODE_CHAR for character
types.

gdb/testsuite/ChangeLog:

* gdb.fortran/type-kinds.exp: Update expected results.

gdb/fortran: Add builtin 8-byte integer type with (kind=8) support

Add a new builtin type, an 8-byte integer, and allow GDB to parse
'integer (kind=8)', returning the new 8-byte integer.

gdb/ChangeLog:

* f-exp.y (convert_to_kind_type): Handle integer (kind=8).
* f-lang.c (build_fortran_types): Setup builtin_integer_s8.
* f-lang.h (struct builtin_f_type): Add builtin_integer_s8 field.

gdb/testsuite/ChangeLog:

* gdb.fortran/type-kinds.exp: Test new integer type kind.

gdb/fortran: Expand the set of types that support (kind=N)

Expand the number of types that can be adjusted with a (kind=N) type
extension.

gdb/ChangeLog:

* f-exp.y (convert_to_kind_type): Handle more type kinds.

gdb/testsuite/ChangeLog:

* gdb.fortran/type-kinds.exp (test_cast_1_to_type_kind): New
function.
(test_basic_parsing_of_type_kinds): Expand types tested.
(test_parsing_invalid_type_kinds): New function.

gdb/fortran: Add Fortran 'kind' intrinsic and keyword

The 'kind' keyword has two uses in Fortran, it is the name of a
builtin intrinsic function, and it is also a keyword used to create a
type of a specific kind.

This commit adds support for using kind as an intrinsic function, and
also adds some initial support for using kind to create types of a
specific kind.

This commit only allows the creation of the type 'character(kind=1)',
however, it will be easy enough to extend this in future to support
more type kinds.

The kind of any expression can be queried using the kind intrinsic
function.  At the moment the kind returned corresponds to the size of
the type, this matches how gfortran handles kinds.  However, the
correspondence between kind and type size depends on the compiler
and/or the specific target, so this might not be correct for
everyone.  If we want to support different compilers/targets in future
the code to compute the kind from a type will need to be updated.

gdb/ChangeLog:

* expprint.c (dump_subexp_body_standard): Support UNOP_KIND.
* f-exp.y: Define 'KIND' token.
(exp): New pattern for KIND expressions.
(ptype): Handle types with a kind extension.
(direct_abs_decl): Extend to spot kind extensions.
(f77_keywords): Add 'kind' to the list.
(push_kind_type): New function.
(convert_to_kind_type): New function.
* f-lang.c (evaluate_subexp_f): Support UNOP_KIND.
* parse.c (operator_length_standard): Likewise.
* parser-defs.h (enum type_pieces): Add tp_kind.
* std-operator.def: Add UNOP_KIND.

gdb/testsuite/ChangeLog:

* gdb.fortran/intrinsics.exp: New file.
* gdb.fortran/intrinsics.f90: New file.
* gdb.fortran/type-kinds.exp: New file.

gdb/fortran: Enable debugging of the Fortran parser

This commit allows 'set debug parser on' to work for the Fortran
parser.

gdb/ChangeLog:

* f-exp.y (f_parse): Set yydebug.

gdb/fortran: Add new function to evaluate Fortran expressions

This is an initial restructure, it adds a new function in which
Fortran specific expressions can be evaluated.  No Fortran specific
expressions are added with this commit though, so for now, the new
function just forwards all expressions to the default expression
handler, as such, there should be no user visible changes after this
commit.  However, the new function will be useful in later commits.

gdb/ChangeLog:

* f-lang.c (evaluate_subexp_f): New function.
(exp_descriptor_f): New global.
(f_language_defn): Use exp_descriptor_f instead of
exp_descriptor_standard.

gdb/fortran: Simplify handling of Fortran dot operations and keywords

Use strncasecmp to compare Fortran dot operations (like .AND.) and for
the keywords list.  This allows for some duplication to be removed
from the token arrays.  I've also performed whitespace cleanup around
the code I've changed.

I have added some tests to ensure that upper and lowercase dot
operations are correctly tested.  The keywords list remains always
lowercase for now.

There should be no user visible changes after this commit.

gdb/ChangeLog:

* f-exp.y (struct token): Add comments.
(dot_ops): Remove uppercase versions and the end marker.
(f77_keywords): Likewise.
(yylex): Use ARRAY_SIZE to iterate over dot_ops, assert all
entries in the dot_ops array are case insensitive, and use
strncasecmp to compare strings.  Also some whitespace cleanup in
this area.  Similar for the f77_keywords array, except entries in
this list might be case sensitive.

gdb/testsuite/ChangeLog:

* gdb.fortran/dot-ops.exp: New file.

gdb/fortran: Cleanup code for parsing logical constants

This patch cleans up the code used for parsing the Fortran logical
constants '.TRUE.' and '.FALSE.'.  Instead of listing both upper and
lowercase versions of these strings we now use strncasecmp.

I've also switched to use ARRAY_SIZE for the array iteration, and I've
cleaned up whitespace in the vicinity of the code I've changed.

Finally, I've added a test to ensure that both the upper and lower
case versions of the logical constants are understood by GDB,
something that was missing previously.

There should be no user visible changes after this commit.

gdb/ChangeLog:

* f-exp.y (struct f77_boolean_val): Add comments.
(boolean_values): Remove uppercase versions, and end marker.
(yylex): Use ARRAY_SIZE for iterating over boolean_values array,
and use strncasecmp to achieve case insensitivity.  Additionally,
perform whitespace cleanup around this code.

gdb/testsuite/ChangeLog:

* gdb.fortran/types.exp (test_logical_literal_types_accepted):
Check upper and lower case logical literals.

gdb/fortran: Remove some duplicate tests

Make the test names unique in gdb.fortran/types.exp by removing a few
duplicate tests.

gdb/testsuite/ChangeLog:

* gdb.fortran/types.exp (test_float_literal_types_accepted):
Remove duplicate tests.

Allow the use of the ORIGIN and LENGTH attributes in expressions inside MEMORY regions.

PR 24289
* ldexp.c (fold_name): Allow lookups of the LENGTH and ORIGIN
attributes during the first phase.

Fix remote-sim.c build after warn-unused-result change

John Darrington pointed out that commit 18cb7c9f3 ("Introduce
ATTRIBUTE_UNUSED_RESULT and use it") broke the build:

/home/john/binutils-gdb/gdb/remote-sim.c: In function 'void gdbsim_target_open(const char*, int)':
/home/john/binutils-gdb/gdb/remote-sim.c:765:18: error: ignoring return value of 'char** gdb_argv::release()', declared with attribute warn_unused_result [-Werror=unused-result]

This patch fixes the problem by arranging to use the result of the
release method.

Tested by rebuilding with a simulator enabled.

gdb/ChangeLog
2019-03-06  Tom Tromey  <tromey@adacore.com>

* remote-sim.c (gdbsim_target_open): Use result of
gdb_argv::release.

Testsuite: Ensure changing directory does not break the log file

get_compiler_info switches to a new log file before checking the compiler
to ensure the checks are not logged. Afterwards it restores back to using
the original log file. However, the logfile uses a relative path name -
if the current test has changed the current directory then all further
output for the test will be lost.  This can confuse the code that collates
the main gdb.log file at the end of a FORCE_PARALLEL run.

fullpath-expand.exp calls gdb_compile after changing the current directory.

The "Ensure stack protection is off for GCC" patch added a call to
get_compiler_info from inside of gdb_compile, causing log file collection
to break for FORCE_PARALLEL runs.

The ideal solution would be to ensure the log file is always created using
an absolute path name. However, this is set at multiple points in
Makefile.in and in some instances just relies on dejagnu common code to set
the log file directory to "."

The simpler and safer solution is to override the builtin cd function. The
new function checks the current log file and if the path is relative, then
it resets the logging using an absolute path. Finally it calls the builtin
cd.  This ensures get_compiler_info (and any other code) can correctly
backup and restore the current log file.

gdb/testsuite/ChangeLog:

* lib/gdb.exp (builtin_cd): rename of cd.
(cd): Override builtin.

Fix a segmentation fault triggered by disassembling an EFi file with source included.

* dwarf2.c (_bfd_dwarf2_find_symbol_bias): Check for a NULL symbol
table pointer.
* coffgen.c (coff_find_nearest_line_with_names): Do not call
_bfd_dwarf2_find_symbol_bias if there is no symbol table available.

https://bugzilla.redhat.com/show_bug.cgi?id=1685727

Fortran function calls with arguments

Prior to this patch, calling functions on the inferior with arguments and
then using these arguments within a function resulted in an invalid
memory access. This is because Fortran arguments are typically passed as
pointers to values.

It is possible to call Fortran functions, but memory must be allocated in
the inferior, so a pointer can be passed to the function, and the
language must be set to C to enable C-style casting. This is cumbersome
and not a pleasant debug experience.

This patch implements the GNU Fortran argument passing conventions with
caveats. Firstly, it does not handle the VALUE attribute as there is
insufficient DWARF information to determine when this is the case.
Secondly, functions with optional parameters can only be called with all
parameters present. Both these cases are marked as KFAILS in the test.

Since the GNU Fortran argument passing convention has been implemented,
there is no guarantee that this patch will work correctly, in all cases,
with other compilers.

Despite these limitations, this patch improves the ease with which
functions can be called in many cases, without taking away the existing
approach of calling with the language set to C.

Regression tested on x86_64, aarch64 and POWER9 with GCC 7.3.0.
Regression tested with Ada on x86_64.
Regression tested with native-extended-gdbserver target board.

gdb/ChangeLog:

* eval.c (evaluate_subexp_standard): Call Fortran argument
wrapping logic.
* f-lang.c (struct value): A value which can be passed into a
Fortran function call.
(fortran_argument_convert): Wrap Fortran arguments in a pointer
where appropriate.
(struct type): Value ready for a Fortran function call.
(fortran_preserve_arg_pointer): Undo check_typedef, the pointer
is needed.
* f-lang.h (fortran_argument_convert): Declaration.
(fortran_preserve_arg_pointer): Declaration.
* infcall.c (value_arg_coerce): Call Fortran argument logic.

gdb/testsuite/ChangeLog:

* gdb.fortran/function-calls.exp: New file.
* gdb.fortran/function-calls.f90: New test.

Automatic date update in version.in

Remove some Python 3 #ifs

A recent patch from Kevin Buettner taught me that the PyBytes API is
available on Python 2.  This patch removes a couple of related #ifs in
the Python code.

Tested on x86-64 Fedora 29, using both Python 3.7 and Python 2.7.

gdb/ChangeLog
2019-03-05  Tom Tromey  <tromey@adacore.com>

* python/py-prettyprint.c (print_string_repr): Remove #if.
* python/py-utils.c (unicode_to_encoded_string): Remove #if.

Change the_dummy_target to be a global

While debugging gdb, I printed the target stack and got:

    (top-gdb) p g_target_stack
    $10 = {
      m_top = thread_stratum,
      m_stack = {0x142b0b0, 0x13da600 <exec_ops>, 0x1c70690, 0x13d63b0 <ravenscar_ops>, 0x0, 0x0, 0x0}
    }

(This is clearly from before the change to make ravenscar
multi-target-capable.)

Here, 0x142b0b0 is the singleton dummy target.  It seems to me that
since this is always a singleton, it would be a bit nicer if it were a
global, so that it would be noted in the above.

This patch implements this idea, and now I get:

    (top-gdb) p g_target_stack
    $2 = {
      m_top = dummy_stratum,
      m_stack = {0x1f1b040 <the_dummy_target>, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}
    }

I did not do the same for the debug target.  It didn't seem as useful
to me.

gdb/ChangeLog
2019-03-05  Tom Tromey  <tromey@adacore.com>

* target.c (the_dummy_target): Move later.  Change type to
"dummy_target".
(initialize_targets): Don't initialize the_dummy_target.

Small fix to gdb.Value constructor doc

The synopsis of the two-parameters form of the gdb.Value constructor is
currently shown as

    Value.__init__ (val, [, type ])

in the documentation.

First, there is an extra comma, which I think we can remove in any
case.

Then, since the type parameter is not optional, I would not put in
between square brackets.  Those usually indicate that something is
optional.

With this patch, it appears as:

    Value.__init__ (val, type)

gdb/doc/ChangeLog:

* python.texi (Values From Inferior): Change synopsys of the
second form of Value.__init__.

Fix a spelling mistake: "complaint" instead of "compliant".

PR 24295
* doc/binutils.texi (ar cmdline): Fix spelling mistake.

Remove gdb_bfd_fdopenr

I noticed that gdb_bfd_fdopenr is no longer used, so this patch
removes it.  Tested by rebuilding and by grep.

gdb/ChangeLog
2019-03-05  Tom Tromey  <tromey@adacore.com>

* gdb_bfd.c (gdb_bfd_fdopenr): Remove.
* gdb_bfd.h (gdb_bfd_fdopenr): Don't declare.

Updated Swedish translation for the binutils sub-directory.

Remove excess calls to gdb_flush

A customer noticed some mildly odd MI output, where CLI output was
split into multiple MI strings at unusual boundaries, like this:

    ~"$1 = (b => true"
    ~", p => 0x407260"

This is technically correct according to the MI spec, but still
unusual, in that there's no particular reason for the string to be
split where it is.

I tracked this down to a call to gdb_flush in generic_val_print.
Then, I went through all calls to gdb_flush and removed the ones I
thought were superfluous.  In particular:

* Any call in the value-printing code;
* Likewise the type-printing code (just a single call); and
* Any call that immediately followed a printf that obviously
  ended with a newline, my belief being that gdb's standard output
  streams are line buffered (by inheriting the behavior from stdio)

Regression tested on x86-64 Fedora 29.

I didn't add a new test case.  I tend to think we don't necessarily
want to specify this behavior in the tests.  Let me know what you
think of this.

gdb/ChangeLog
2019-03-05  Tom Tromey  <tromey@adacore.com>

* windows-nat.c (windows_nat_target::attach)
(windows_nat_target::detach): Don't call gdb_flush.
* valprint.c (generic_val_print, val_print, val_print_string):
Don't call gdb_flush.
* utils.c (defaulted_query): Don't call gdb_flush.
* typeprint.c (print_type_scalar): Don't call gdb_flush.
* target.c (target_announce_detach): Don't call gdb_flush.
* sparc64-tdep.c (adi_print_versions): Don't call gdb_flush.
* remote.c (extended_remote_target::attach): Don't call
gdb_flush.
* procfs.c (procfs_target::detach): Don't call gdb_flush.
* printcmd.c (do_examine): Don't call gdb_flush.
(info_display_command): Don't call gdb_flush.
* p-valprint.c (pascal_val_print): Don't call gdb_flush.
* nto-procfs.c (nto_procfs_target::attach): Don't call gdb_flush.
* memattr.c (info_mem_command): Don't call gdb_flush.
* mdebugread.c (mdebug_build_psymtabs): Don't call gdb_flush.
* m2-valprint.c (m2_val_print): Don't call gdb_flush.
* infrun.c (follow_exec, handle_command): Don't call gdb_flush.
* inf-ptrace.c (inf_ptrace_target::attach): Don't call gdb_flush.
* hppa-tdep.c (unwind_command): Don't call gdb_flush.
* gnu-nat.c (gnu_nat_target::attach): Don't call gdb_flush.
(gnu_nat_target::detach): Don't call gdb_flush.
* f-valprint.c (f_val_print): Don't call gdb_flush.
* darwin-nat.c (darwin_nat_target::attach): Don't call gdb_flush.
* cli/cli-script.c (read_command_lines): Don't call gdb_flush.
* cli/cli-cmds.c (shell_escape, print_disassembly): Don't call
gdb_flush.
* c-valprint.c (c_val_print): Don't call gdb_flush.
* ada-valprint.c (ada_print_scalar): Don't call gdb_flush.

Add ATTRIBUTE_UNUSED_RESULT to ref_ptr::release

This applies ATTRIBUTE_UNUSED_RESULT to ref_ptr::release and updates a
few spots to comply.  I believe one use in install_default_visualizer
was in error, fixed by this patch.

gdb/ChangeLog
2019-03-05  Tom Tromey  <tromey@adacore.com>

* varobj.c (update_dynamic_varobj_children): Update.
(install_default_visualizer): Use reset, not release.
* value.c (set_internalvar): Update.
* dwarf2loc.c (value_of_dwarf_reg_entry): Update.
* common/gdb_ref_ptr.h (class ref_ptr) <release>: Add
ATTRIBUTE_UNUSED_RESULT.

Add ATTRIBUTE_UNUSED_RESULT to scoped_remote_fd::release

This applies ATTRIBUTE_UNUSED_RESULT to scoped_remote_fd::release.

gdb/ChangeLog
2019-03-05  Tom Tromey  <tromey@adacore.com>

* remote.c (class scoped_remote_fd) <release>: Add
ATTRIBUTE_UNUSED_RESULT.

Add ATTRIBUTE_UNUSED_RESULT to macro_buffer

This applies ATTRIBUTE_UNUSED_RESULT to macro_buffer::release.

gdb/ChangeLog
2019-03-05  Tom Tromey  <tromey@adacore.com>

* macroexp.c (struct macro_buffer) <release>: Add
ATTRIBUTE_UNUSED_RESULT.

Add ATTRIBUTE_UNUSED_RESULT to scoped_mmap

This applies ATTRIBUTE_UNUSED_RESULT to scoped_mmap::release and fixes
a couple of spots to comply.

gdb/ChangeLog
2019-03-05  Tom Tromey  <tromey@adacore.com>

* nat/linux-btrace.c (linux_enable_bts, linux_enable_pt): Update.
* common/scoped_mmap.h (class scoped_mmap) <release>: Add
ATTRIBUTE_UNUSED_RESULT.

Add ATTRIBUTE_UNUSED_RESULT to scoped_fd

This applies ATTRIBUTE_UNUSED_RESULT to scoped_fd::release.

gdb/ChangeLog
2019-03-05  Tom Tromey  <tromey@adacore.com>

* common/scoped_fd.h (class scoped_fd) <release>: Add
ATTRIBUTE_UNUSED_RESULT.

Add ATTRIBUTE_UNUSED_RESULT to parser_state

This applies ATTRIBUTE_UNUSED_RESULT to parser_state::release.

gdb/ChangeLog
2019-03-05  Tom Tromey  <tromey@adacore.com>

* parser-defs.h (struct parser_state) <release>: Add
ATTRIBUTE_UNUSED_RESULT.

Introduce ATTRIBUTE_UNUSED_RESULT and use it

This introduces the new ATTRIBUTE_UNUSED_RESULT define, and applies it
to gdb_argv::release.

gdb/ChangeLog
2019-03-05  Tom Tromey  <tromey@adacore.com>

* utils.h (class gdb_argv) <release>: Add
ATTRIBUTE_UNUSED_RESULT.
* common/common-defs.h (ATTRIBUTE_UNUSED_RESULT): Define.

Allow multiple tests to be run on systems with older versions of TCL installed.

PR 24287
* testsuite/lib/binutils-common.exp (run_dump_test): Replace a use
of "lmap" with a "foreach" loop.

Automatic date update in version.in

Use '$enable_unittest' instead of '$development' on gdbserver/configure.srv (for 'aarch64*-*-linux*' case)

On commit 8ecfd7bd4acd69213c06fac6de9af38299123547 ("Add parameter to
allow enabling/disabling selftests via configure") it seems that I
forgot to use the proper '$enable_unittest' variable when checking to
see whether to add selftest-related objects to 'srv_regobj'.  This
causes a build failure on Aarch64 when 'development=false' (which is
the case for the 8.3 branch) and 'enable_unittest=true'.

This patch fixes the problem by using '$enable_unittest' instead of
'$development' when performing the check.  As a reminder, it's
important to notice that '$enable_unittest's default value (i.e., when
the option '--enable-unit-tests' is not passed to configure) is the
same as '$development', so this patch doesn't affect the current
build.

I'd like to install this patch both on master and on the 8.3 branch.

OK?

gdb/gdbserver/ChangeLog:
2019-03-04  Sergio Durigan Junior  <sergiodj@redhat.com>

* configure.srv: Use '$enable_unittest' instead of '$development'
when checking whether to fill 'srv_regobj' on 'aarch64*-*-linux*'
case.

gdbserver short-circuit-argument-list failures

This patch fixes test case failures observed when running
short-circuit-argument-list.exp with gdb server boards. Thanks to Sergio
Durigan Junior for pointing this out.

Assertions failed with the native{,-extended}-gdbserver boards as the
standard output from the test program appears in a different location
than observed on non-gdbserver boards. This standard output was used to
determine whether a function, which had been logically short-circuited,
was called or not. Since the location of the standard out cannot be
relied upon to verify this, a new mechanism was needed.

The test program now records function calls in variables named the same
as the function with a "_called" suffix. These variables can then be
queried from the test case to verify the occurrence of a call.

A method to reset the call counts has been included in the test case, so
that any future assertions added to this test can ensure a fresh set of
initial values before proceeding. Not resetting values between groups of
assertions creates a dependency between them, which increases the
likelihood that a single failure causes subsequent assertions to fail.

Regression tested on x86_64, aarch64 and ppc64le.
Regression tested with Ada on x86_64.
Regression tested with the native{,-extended}-gdbserver boards on x86_64.

Stop objcopy from attempting to copy thin archives.

PR 24281
* objcopy.c (copy_archive): Do not copy thin  archives.

Automatic date update in version.in

Automatic date update in version.in

Fix documentation of styles.

gdb/doc/ChangeLog:
2019-03-02  Eli Zaretskii  <eliz@gnu.org>

* gdb.texinfo (Output Styling): Fix typos.  Document the default
foreground colors of the available styles.

Avoid compilation warnings on MinGW.

gdb/ChangeLog:
2019-03-02  Eli Zaretskii  <eliz@gnu.org>

* xml-syscall.c (xml_list_syscalls_by_group): Drop 'struct' from
for-loop range, to avoid compiler warnings.

* tui/tui.c (tui_enable) [__MINGW32__]: Don't declare 'cap', to
avoid compiler warnings about unused variables.

GDB no longer supports Windows before XP.

gdb/ChangeLog:
2019-03-02  Eli Zaretskii  <eliz@gnu.org>

* NEWS: Mention end of support for native debugging on MS-Windows
before XP.

Fix GDB compilation on MinGW (PR gdb/24292)

gdb/ChangeLog:

2019-03-02  Eli Zaretskii  <eliz@gnu.org>

PR gdb/24292
* common/netstuff.c:
* gdbserver/gdbreplay.c
* gdbserver/remote-utils.c:
* ser-tcp.c:
* unittests/parse-connection-spec-selftests.c [USE_WIN32API]:
Include ws2tcpip.h instead of wsiapi.h and winsock2.h.  Redefine
_WIN32_WINNT to 0x0501 if defined to a smaller value, as
'getaddrinfo' and 'freeaddrinfo' were not available before
Windows XP, and mingw.org's MinGW headers by default define
_WIN32_WINNT to 0x500.

Automatic date update in version.in

Revert "Add support to GNU ld to separate got related plt entries"

bfd/ChangeLog:

2019-03-01  Andreas Krebbel  <krebbel@linux.ibm.com>

This reverts commit 5a12586d44fa8d5dfc74cbca4f2f36a273a16335.
2019-01-14  Maamoun Tarsha  <maamountk@hotmail.com>

PR 20113
* elf32-s390.c (allocate_dynrelocs): Update comment.

ld/ChangeLog:

2019-03-01  Andreas Krebbel  <krebbel@linux.ibm.com>

This reverts commit 5a12586d44fa8d5dfc74cbca4f2f36a273a16335.
2019-01-14  Maamoun Tarsha  <maamountk@hotmail.com>

PR 20113
* emulparams/elf64_s390.sh (SEPARATE_GOTPLT): Define.
* emulparams/elf_s390.sh (SEPARATE_GOTPLT): Define.
* testsuite/ld-s390/gotreloc_31-1.dd: Update expected output.
* testsuite/ld-s390/tlsbin.dd: Likewise.
* testsuite/ld-s390/tlsbin.rd: Likewise.
* testsuite/ld-s390/tlsbin.sd: Likewise.
* testsuite/ld-s390/tlsbin_64.dd: Likewise.
* testsuite/ld-s390/tlsbin_64.rd: Likewise.
* testsuite/ld-s390/tlsbin_64.sd: Likewise.
* testsuite/ld-s390/tlspic.dd: Likewise.
* testsuite/ld-s390/tlspic.rd: Likewise.
* testsuite/ld-s390/tlspic.sd: Likewise.
* testsuite/ld-s390/tlspic_64.dd: Likewise.
* testsuite/ld-s390/tlspic_64.rd: Likewise.
* testsuite/ld-s390/tlspic_64.sd: Likewise.
* testsuite/ld-s390/s390.exp: Skip s390 tests for tpf targets.

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.