The 'nd' architectures did not mention what the 'nd' stands for.
Document that these mean 'no brach delay slot'.

cpu/ChangeLog:

yyyy-mm-dd  Stafford Horne  <shorne@gmail.com>

	* or1k.cpu (or64nd, or32nd, or1200nd): Update comment.a
	(l-adrp): Improve comment.

Add support for new floating point unordered comparisons.  These have been
defined in OpenRISC architecture proposal 7[0] and are now included in the
architecture specification 1.3.

These new instructions provide the ability for floating point comparisons to
detect NaNs.

[0] https://openrisc.io/proposals/lfsf

cpu/ChangeLog:

yyyy-mm-dd  Stafford Horne  <shorne@gmail.com>

	* or1korfpx.cpu (insn-opcode-float-regreg): Add SFUEQ_S, SFUNE_S,
	SFUGT_S, SFUGE_S, SFULT_S, SFULE_S, SFUN_S, SFUEQ_D, SFUNE_D, SFUGT_D,
	SFUGE_D, SFULT_D, SFULE_D, SFUN_D opcodes.
	(float-setflag-insn-base): New pmacro based on float-setflag-insn.
	(float-setflag-symantics, float-setflag-unordered-cmp-symantics,
	float-setflag-unordered-symantics): New pmacro for instruction
	symantics.
	(float-setflag-insn): Update to use float-setflag-insn-base.
	(float-setflag-unordered-insn): New pmacro for generating instructions.

This patch adds support for OpenRISC 64-bit FPU operations on 32-bit cores by
using register pairs.  The functionality has been added to OpenRISC architecture
specification version 1.3 as per architecture proposal 14[0].

For supporting assembly of both 64-bit and 32-bit precision instructions we have
defined CGEN_VALIDATE_INSN_SUPPORTED.  This allows cgen to use 64-bit bit
architecture assembly parsing on 64-bit toolchains and 32-bit architecture
assembly parsing on 32-bit toolchains.  Without this the assembler has issues
parsing register pairs.

This patch also contains a few fixes to the symantics for existing OpenRISC
single and double precision FPU operations.

[0] https://openrisc.io/proposals/orfpx64a32

cpu/ChangeLog:

yyyy-mm-dd  Andrey Bacherov  <avbacherov@opencores.org>
	    Stafford Horne  <shorne@gmail.com>

	* or1k.cpu (ORFPX64A32-MACHS): New pmacro.
	(ORFPX-MACHS): Removed pmacro.
	* or1k.opc (or1k_cgen_insn_supported): New function.
	(CGEN_VALIDATE_INSN_SUPPORTED): Define macro.
	(parse_regpair, print_regpair): New functions.
	* or1kcommon.cpu (h-spr, spr-shift, spr-address, h-gpr): Reorder
	and add comments.
	(h-fdr): Update comment to indicate or64.
	(reg-pair-reg-lo, reg-pair-reg-hi): New pmacros for register pairs.
	(h-fd32r): New hardware for 64-bit fpu registers.
	(h-i64r): New hardware for 64-bit int registers.
	* or1korbis.cpu (f-resv-8-1): New field.
	* or1korfpx.cpu (rDSF, rASF, rBSF): Update attribute to ORFPX32-MACHS.
	(rDDF, rADF, rBDF): Update operand comment to indicate or64.
	(f-rdoff-10-1, f-raoff-9-1, f-rboff-8-1): New fields.
	(h-roff1): New hardware.
	(double-field-and-ops mnemonic): New pmacro to generate operations
	rDD32F, rAD32F, rBD32F, rDDI and rADI.
	(float-regreg-insn): Update single precision generator to MACH
	ORFPX32-MACHS.  Add generator for or32 64-bit instructions.
	(float-setflag-insn): Update single precision generator to MACH
	ORFPX32-MACHS.  Fix double instructions from single to double
	precision.  Add generator for or32 64-bit instructions.
	(float-cust-insn cust-num): Update single precision generator to MACH
	ORFPX32-MACHS.  Add generator for or32 64-bit instructions.
	(lf-rem-s, lf-itof-s, lf-ftoi-s, lf-madd-s): Update MACH to
	ORFPX32-MACHS.
	(lf-rem-d): Fix operation from mod to rem.
	(lf-rem-d32, lf-itof-d32, lf-ftoi-d32, lf-madd-d32): New instruction.
	(lf-itof-d): Fix operands from single to double.
	(lf-ftoi-d): Update operand mode from DI to WI.

opcodes/
	* ppc-opc.c (powerpc_opcodes) <ldmx>: Delete mnemonic.

gas/
	* testsuite/gas/ppc/power9.d: Delete ldmx tests.
	* testsuite/gas/ppc/power9.s: Likewise.

	PR 24643
	* elf32-arm.c (arm_elf_find_function): Fail if the symol table is
	absent, or the bfd is not in the ELF formart.
	* elfnn-aarch64.c (aarch64_elf_find_function): Likewise.

	PR 24663
	* readelf.c (process_netbsd_elf_note): Add support for
	NT_NETBSD_PAX.
	(process_note): Add support for PaX notes.

	PR 24665
	* readelf.c (get_netbsd_elfcore_note_type): Add support for SH
	core notes.

	PR 24664
	* readelf.c (get_netbsd_elfcore_note_type): Add support for NetBSD
	auxv notes.

Add missing ChangeLog entries for previous commit.

gdb/ChangeLog:
2019-06-11  Bernhard Heckel  <bernhard.heckel@intel.com>

	* dwarf2read.c (add_partial_symbol): Skip nameless modules.

gdb/testsuite/Changelog:
2019-06-11  Bernhard Heckel  <bernhard.heckel@intel.com>

	* gdb.fortran/block-data.f: New.
	* gdb.fortran/block-data.exp: New.

A name for BLOCK DATA in Fortran is optional.  If no name has been
assigned, GDB crashes during read-in of DWARF when BLOCK DATA is
represented via DW_TAG_module.  BLOCK DATA is used for one-time
initialization of non-pointer variables in named common blocks.

As of now there is no issue when gfortran is used as DW_TAG_module is
not emitted.  However, with Intel ifort the nameless DW_TAG_module is
present and has the following form:

 ...
  <1><dd>: Abbrev Number: 7 (DW_TAG_module)
     <de>   DW_AT_decl_line   : 46
     <df>   DW_AT_decl_file   : 1
     <e0>   DW_AT_description : (indirect string, offset: 0x110): block
 data
     <e4>   DW_AT_high_pc     : 0x402bb7
     <ec>   DW_AT_low_pc      : 0x402bb7
 ...

The missing name leads to a crash in add_partial_symbol, during length
calculation.

gdb/ChangeLog:
2019-06-11  Bernhard Heckel  <bernhard.heckel@intel.com>

	* dwarf2read.c (add_partial_symbol): Skip nameless modules.

gdb/testsuite/Changelog:
2019-06-11  Bernhard Heckel  <bernhard.heckel@intel.com>

	* gdb.fortran/block-data.f: New.
	* gdb.fortran/block-data.exp: New.

	PR 24662
	* readelf.c (get_alpha_symbol_other): New function.
	(get_symbol_other): Use for Alpha symbols.
	(is_32bit_pcrel_reloc): Add R_VAX_PCREL32.

When "common" becomes a library, linking will cause a symbol clash,
because "xmalloc" and some related symbols are defined in that
library, libiberty, and readline.

To work around this problem, this patch moves the clashing symbols to
a new file, which is then compiled separately for both gdb and
gdbserver.

gdb/ChangeLog
2019-06-11  Tom Tromey  <tom@tromey.com>

	* common/common-utils.c (xmalloc, xrealloc, xcalloc)
	(xmalloc_failed): Move to alloc.c.
	* alloc.c: New file.
	* Makefile.in (COMMON_SFILES): Add alloc.c.

gdb/gdbserver/ChangeLog
2019-06-11  Tom Tromey  <tom@tromey.com>

	* Makefile.in (SFILES): Add alloc.c.
	(OBS): Add alloc.o.
	(IPA_OBJS): Add alloc-ipa.o.
	(alloc-ipa.o): New target.
	(%.o: ../%.c): New pattern rule.

The debugging code in linux-waitpid.c is one of the few remaining
spots that depends on the gdb/gdbserver difference.

My first thought was that this code is not extremely useful, so this
patch removes this code.  (However, if it is actually useful to
someone, we could make it work by introducing a new abstraction.)

gdb/ChangeLog
2019-06-11  Tom Tromey  <tom@tromey.com>

	* nat/linux-waitpid.c: Don't include server.h.
	(linux_debug): Remove.
	(my_waitpid): Update.

	PR 24661
	* readelf.c (decode_arm_unwind): Ensure that the local variable
	'addr' is always initialised.

I noticed recently that some command had a trailing newline in its
"help" output.  So, I temporarily hacked cli-decode.c to print
something when a new command was installed that had a trailing newline
in its help message, and wrote this patch, which removes all the ones
I could find this way.  (There could still be a few more in *-nat
files.)

Tested on x86-64 Fedora 29.

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

	* infcall.c (_initialize_infcall): Remove trailing newline from
	help.
	* user-regs.c (_initialize_user_regs): Remove trailing newline
	from help.
	* typeprint.c (_initialize_typeprint): Remove trailing newline
	from help.
	* reverse.c (_initialize_reverse): Remove trailing newlines from
	help.
	* tracepoint.c (_initialize_tracepoint): Remove trailing newlines
	from help.
	* language.c (add_set_language_command): Remove trailing newline
	from help.
	* infcmd.c (_initialize_infcmd): Remove trailing newlines from
	help.
	* disasm.c (_initialize_disasm): Remove trailing newline from
	help.
	* top.c (init_main): Remove trailing newline from help.
	* interps.c (_initialize_interpreter): Remove trailing newline
	from help.
	* btrace.c (_initialize_btrace): Remove trailing newlines from
	help.
	* breakpoint.c (_initialize_breakpoint): Remove trailing newline
	from help.
	* python/python.c (_initialize_python): Remove trailing newline
	from help.
	* spu-tdep.c (_initialize_spu_tdep): Remove trailing newlines from
	help.
	* tui/tui-win.c (_initialize_tui_win): Remove trailing newlines
	from help.  Reformat some text.
	* tui/tui-stack.c (_initialize_tui_stack): Remove trailing newline
	from help.
	* tui/tui-layout.c (_initialize_tui_layout): Remove trailing
	newline from help.

We see this failure with the readnow board:
...
FAIL: gdb.multi/remove-inferiors.exp: load binary
...

When running with board readnow, an extra message "Expanding full symbols" is
emitted after the "Reading symbols" message, and the regexp corresponding to
the FAIL only allows the first message.

Fix this by allowing the extra message in the regexp.

gdb/testsuite/ChangeLog:

2019-06-11  Tom de Vries  <tdevries@suse.de>

	PR testsuite/24521
	* gdb.multi/remove-inferiors.exp: Allow "Expanding full symbols"
	message.

Building on Darwin with gcc showed that darwin-nat.c had some
shadowing variable declarations.  This removes them.

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

	* darwin-nat.c (darwin_decode_exception_message)
	(darwin_decode_message, darwin_nat_target::kill): Fix shadowing.

When running gdb.dwarf2/nonvar-access.exp with board readnow, we have:
...
FAIL: gdb.dwarf2/nonvar-access.exp: print/x def_implicit_s
...
and 12 more similar failures.

I've tracked this down to the range of main being hardcoded to
[_main, _main+0x10000) in the dwarf assembly:
...
            DW_TAG_subprogram {
                {name main}
                {DW_AT_external 1 flag}
                {low_pc [gdb_target_symbol main] DW_FORM_addr}
		{high_pc [gdb_target_symbol main]+0x10000 DW_FORM_addr}
            } {
...
which overlaps with the .debug_info for the elf-init.c CU (containing
__libc_csu_init and __libc_csu_fini).

Fix this by using function_range to find the actual range of main.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-06-11  Tom de Vries  <tdevries@suse.de>

	PR testsuite/24521
	* gdb.dwarf2/nonvar-access.exp: Fix main high_pc.

Add a target board to test -readnow.

gdb/testsuite/ChangeLog:

2019-06-11  Tom de Vries  <tdevries@suse.de>

	* boards/readnow.exp: New file.

When extracting an array slice we should give up if the array is
not-allocated or not-associated.  For Fortran, at least in gfortran
compiled code, the upper and lower bounds are undefined if the array
is not allocated or not associated, in which case performing checks
against these bounds will result in undefined behaviour.

Better then to throw an error if we try to slice such an array.  This
changes the error message that the user will receive in these
cases (if they got an error message before).  Previously they may have
gotten "slice out of range" now they'll get "array not allocated" or
"array not associated".

gdb/ChangeLog:

	* valops.c (value_slice): Check for not allocated or not
	associated values.

gdb/testsuite/ChangeLog:

	* gdb.fortran/vla-sizeof.exp: Update expected results.

When compiling gdb with '-lasan -fsanitizer=address' and running tests with:
- export ASAN_OPTIONS="detect_leaks=0:alloc_dealloc_mismatch=0",
- target board cc-with-gdb-index,
- the "[gdb/testsuite] Fix gdb.base/break-probes.exp with native-gdbserver"
  commit reverted to avoid running into PR24617,
we get with gdb.arch/amd64-init-x87-values.exp:
...
==31229==ERROR: AddressSanitizer: heap-buffer-overflow on address \
  0x62500098c93c at pc 0x000000bcc748 bp 0x7ffe39487660 sp 0x7ffe39487658
READ of size 1 at 0x62500098c93c thread T0
    #0 0xbcc747 in cp_find_first_component_aux src/gdb/cp-support.c:999
    #1 0xbcc6e9 in cp_find_first_component(char const*) \
                   src/gdb/cp-support.c:977
    #2 0xcc2cf3 in mapped_index_base::build_name_components() \
                   src/gdb/dwarf2read.c:4499
    #3 0xcc3322 in dw2_expand_symtabs_matching_symbol src/gdb/dwarf2read.c:4552
    #4 0xcc817f in dw2_expand_symtabs_matching src/gdb/dwarf2read.c:5228
    #5 0xfe8f48 in iterate_over_all_matching_symtabs src/gdb/linespec.c:1147
    #6 0x1003506 in add_matching_symbols_to_info src/gdb/linespec.c:4413
    #7 0xffe21b in find_function_symbols src/gdb/linespec.c:3886
    #8 0xffe4a2 in find_linespec_symbols src/gdb/linespec.c:3914
    #9 0xfee3ad in linespec_parse_basic src/gdb/linespec.c:1865
    #10 0xff5128 in parse_linespec src/gdb/linespec.c:2655
    #11 0xff8872 in event_location_to_sals src/gdb/linespec.c:3150
    #12 0xff90a8 in decode_line_full(event_location const*, int, \
                    program_space*, symtab*, int, linespec_result*, \
		    char const*, char const*) src/gdb/linespec.c:3230
    #13 0x9ce449 in parse_breakpoint_sals src/gdb/breakpoint.c:9057
    #14 0x9ea022 in create_sals_from_location_default src/gdb/breakpoint.c:13708
    #15 0x9e2c1f in bkpt_create_sals_from_location src/gdb/breakpoint.c:12514
    #16 0x9cff06 in create_breakpoint(gdbarch*, event_location const*, \
                    char const*, int, char const*, int, int, bptype, int, \
		    auto_boolean, breakpoint_ops const*, int, int, int, \
		    unsigned int) src/gdb/breakpoint.c:9238
    #17 0x9d114a in break_command_1 src/gdb/breakpoint.c:9402
    #18 0x9d1b60 in break_command(char const*, int) src/gdb/breakpoint.c:9473
    #19 0xac96aa in do_const_cfunc src/gdb/cli/cli-decode.c:106
    #20 0xad0e5a in cmd_func(cmd_list_element*, char const*, int) \
                    src/gdb/cli/cli-decode.c:1892
    #21 0x15226f6 in execute_command(char const*, int) src/gdb/top.c:630
    #22 0xddde37 in command_handler(char const*) src/gdb/event-top.c:586
    #23 0xdde7c1 in command_line_handler(std::unique_ptr<char, \
                    gdb::xfree_deleter<char> >&&) src/gdb/event-top.c:773
    #24 0xddc9e8 in gdb_rl_callback_handler src/gdb/event-top.c:217
    #25 0x16f2198 in rl_callback_read_char src/readline/callback.c:220
    #26 0xddc5a1 in gdb_rl_callback_read_char_wrapper_noexcept \
                    src/gdb/event-top.c:175
    #27 0xddc773 in gdb_rl_callback_read_char_wrapper src/gdb/event-top.c:192
    #28 0xddd9f5 in stdin_event_handler(int, void*) src/gdb/event-top.c:514
    #29 0xdd7d8f in handle_file_event src/gdb/event-loop.c:731
    #30 0xdd8607 in gdb_wait_for_event src/gdb/event-loop.c:857
    #31 0xdd629c in gdb_do_one_event() src/gdb/event-loop.c:321
    #32 0xdd6344 in start_event_loop() src/gdb/event-loop.c:370
    #33 0x10a7715 in captured_command_loop src/gdb/main.c:331
    #34 0x10aa548 in captured_main src/gdb/main.c:1173
    #35 0x10aa5d8 in gdb_main(captured_main_args*) src/gdb/main.c:1188
    #36 0x87bd35 in main src/gdb/gdb.c:32
    #37 0x7f16e1434f89 in __libc_start_main (/lib64/libc.so.6+0x20f89)
    #38 0x87bb49 in _start (build/gdb/gdb+0x87bb49)

0x62500098c93c is located 0 bytes to the right of 8252-byte region \
  [0x62500098a900,0x62500098c93c)
allocated by thread T0 here:
    #0 0x7f16e359a600 in malloc (/usr/lib64/libasan.so.5+0xeb600)
    #1 0x1742ddf in bfd_malloc src/bfd/libbfd.c:275
    #2 0x1738824 in bfd_get_full_section_contents src/bfd/compress.c:253
    #3 0xe30044 in gdb_bfd_map_section(bfd_section*, unsigned long*) \
                   src/gdb/gdb_bfd.c:704
    #4 0xcb56bf in dwarf2_read_section(objfile*, dwarf2_section_info*) \
                   src/gdb/dwarf2read.c:2539
    #5 0xd5bcd0 in get_gdb_index_contents_from_section<dwarf2_per_objfile> \
                   src/gdb/dwarf2read.c:6217
    #6 0xd7fc7d in gdb::function_view<gdb::array_view<unsigned char const> \
                   (...) const src/gdb/common/function-view.h:284
    #7 0xd7fddd in gdb::function_view<gdb::array_view<unsigned char const> \
                   (...) src/gdb/common/function-view.h:278
    #8 0xd730cf in gdb::function_view<gdb::array_view<unsigned char const> \
                   (...) const src/gdb/common/function-view.h:247
    #9 0xcbc7ee in dwarf2_read_gdb_index src/gdb/dwarf2read.c:3582
    #10 0xcce731 in dwarf2_initialize_objfile(objfile*, dw_index_kind*) \
                    src/gdb/dwarf2read.c:6297
    #11 0xdb88c4 in elf_symfile_read src/gdb/elfread.c:1256
    #12 0x141262a in read_symbols src/gdb/symfile.c:798
    #13 0x14140a7 in syms_from_objfile_1 src/gdb/symfile.c:1000
    #14 0x1414393 in syms_from_objfile src/gdb/symfile.c:1017
    #15 0x1414fb7 in symbol_file_add_with_addrs src/gdb/symfile.c:1124
    #16 0x14159b7 in symbol_file_add_from_bfd(bfd*, char const*, \
                     enum_flags<symfile_add_flag>, std::vector<other_sections, \
	             std::allocator<other_sections> >*, \
		     enum_flags<objfile_flag>, objfile*) src/gdb/symfile.c:1203
    #17 0x1415b6c in symbol_file_add(char const*,
                     enum_flags<symfile_add_flag>, std::vector<other_sections, \
		     std::allocator<other_sections> >*, \
		     enum_flags<objfile_flag>) src/gdb/symfile.c:1216
    #18 0x1415f2f in symbol_file_add_main_1 src/gdb/symfile.c:1240
    #19 0x1418599 in symbol_file_command(char const*, int) \
                     src/gdb/symfile.c:1675
    #20 0xde2fa6 in file_command src/gdb/exec.c:433
    #21 0xac96aa in do_const_cfunc src/gdb/cli/cli-decode.c:106
    #22 0xad0e5a in cmd_func(cmd_list_element*, char const*, int) \
                    src/gdb/cli/cli-decode.c:1892
    #23 0x15226f6 in execute_command(char const*, int) src/gdb/top.c:630
    #24 0xddde37 in command_handler(char const*) src/gdb/event-top.c:586
    #25 0xdde7c1 in command_line_handler(std::unique_ptr<char, \
                    gdb::xfree_deleter<char> >&&) src/gdb/event-top.c:773
    #26 0xddc9e8 in gdb_rl_callback_handler src/gdb/event-top.c:217
    #27 0x16f2198 in rl_callback_read_char src/readline/callback.c:220
    #28 0xddc5a1 in gdb_rl_callback_read_char_wrapper_noexcept \
                    src/gdb/event-top.c:175
    #29 0xddc773 in gdb_rl_callback_read_char_wrapper src/gdb/event-top.c:192

SUMMARY: AddressSanitizer: heap-buffer-overflow src/gdb/cp-support.c:999 in \
  cp_find_first_component_aux
Shadow bytes around the buggy address:
  0x0c4a801298d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c4a801298e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c4a801298f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c4a80129900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c4a80129910: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c4a80129920: 00 00 00 00 00 00 00[04]fa fa fa fa fa fa fa fa
  0x0c4a80129930: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a80129940: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a80129950: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a80129960: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c4a80129970: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==31229==ABORTING
...

The problem happens as follows.

The executable amd64-init-x87-values gets an index (due to target board
cc-with-gdb-index), which looks as follows:
...
Hex dump of section '.gdb_index':
  0x00000000 08000000 18000000 28000000 28000000 ........(...(...
  0x00000010 3c000000 3c200000 00000000 00000000 <...< ..........
  0x00000020 2e000000 00000000 d4004000 00000000 ..........@.....
  0x00000030 db004000 00000000 00000000 00000000 ..@.............
  0x00000040 00000000 00000000 00000000 00000000 ................
  0x00000050 00000000 00000000 00000000 00000000 ................
  ... more zeroes ...
  0x00002010 00000000 00000000 00000000 00000000 ................
  0x00002020 00000000 00000000 00000000 00000000 ................
  0x00002030 00000000 00000000 00000000          ............
...

The structure of this index is:
...
header       : [0x0, 0x18)     : size 0x18
culist       : [0x18 ,0x28)    : size 0x10
typesculist  : [0x28, 0x28)    : size 0x0
adress area  : [0x28, 0x3c)    : size 0x14
symbol table : [0x3c, 0x203c)  : size 0x2000
constant pool: [0x203c, 0x203c): size 0x0
EOF          : 0x203c
...

Note that the symbol table consists entirely of empty slots (where an empty
slot is a pair of 32-bit zeroes), and that the constant pool is empty.

The problem happens here in mapped_index_base::build_name_components:
...
  auto count = this->symbol_name_count ();
  for (offset_type idx = 0; idx < count; idx++)
    {
      if (this->symbol_name_slot_invalid (idx))
	continue;

      const char *name = this->symbol_name_at (idx);
...
when accessing the slot at idx == 0 in the symbol table,
symbol_name_slot_invalid returns false so we calculate name, which is
calculated using 'constant_pool + symbol_table[idx].name', which means we get
name == constant_pool.  And given that the constant pool is empty, name now
points past the memory allocated for the index, and when we access name[0] for
the first time in cp_find_first_component_aux, we run into the
heap-buffer-overflow.

Fix this by fixing the definition of symbol_name_slot_invalid:
...
-    return bucket.name == 0 && bucket.vec;
+    return bucket.name == 0 && bucket.vec == 0;
...

Tested on x86_64-linux.

gdb/ChangeLog:

2019-06-10  Tom de Vries  <tdevries@suse.de>

	PR gdb/24618
	* dwarf2read.c (struct mapped_index::symbol_name_slot_invalid): Make
	sure an empty slot (defined by a 32-bit zero pair) is recognized as
	invalid.

When compiling gdb with '-lasan -fsanitizer=address' and running tests with
'export ASAN_OPTIONS="detect_leaks=0:alloc_dealloc_mismatch=0"', I run into:
...
ERROR: GDB process no longer exists
UNRESOLVED: gdb.linespec/cpls-abi-tag.exp: \
  test_abi_tag: completion: at tag: tab complete "b test_abi_tag_function[abi:"
...

In more detail:
...
==3637==ERROR: AddressSanitizer: dynamic-stack-buffer-overflow on address \
  0x7fff5952bbdd at pc 0x000000fe5c57 bp 0x7fff5952af30 sp 0x7fff5952af28
READ of size 1 at 0x7fff5952bbdd thread T0
    #0 0xfe5c56 in linespec_lexer_lex_string src/gdb/linespec.c:727
    #1 0xfe7473 in linespec_lexer_lex_one src/gdb/linespec.c:946
    #2 0xfe799d in linespec_lexer_consume_token src/gdb/linespec.c:982
    #3 0xff446d in parse_linespec src/gdb/linespec.c:2564
    #4 0xff78be in linespec_complete(completion_tracker&, char const*, \
                   symbol_name_match_type) src/gdb/linespec.c:2961
    #5 0xb9299c in complete_address_and_linespec_locations \
                   src/gdb/completer.c:573
    #6 0xb93e90 in location_completer(cmd_list_element*, completion_tracker&, \
                   char const*, char const*) src/gdb/completer.c:919
    #7 0xb940c5 in location_completer_handle_brkchars src/gdb/completer.c:956
    #8 0xb957ec in complete_line_internal_normal_command \
                   src/gdb/completer.c:1208
    #9 0xb96507 in complete_line_internal_1 src/gdb/completer.c:1430
    #10 0xb965c2 in complete_line_internal src/gdb/completer.c:1449
    #11 0xb98630 in gdb_completion_word_break_characters_throw \
                    src/gdb/completer.c:1862
    #12 0xb98838 in gdb_completion_word_break_characters() \
                    src/gdb/completer.c:1897
    #13 0x16c6362 in _rl_find_completion_word src/readline/complete.c:943
    #14 0x16ca8d0 in rl_complete_internal src/readline/complete.c:1843
    #15 0x16c460c in rl_complete src/readline/complete.c:408
    #16 0x16b3368 in _rl_dispatch_subseq src/readline/readline.c:774
    #17 0x16b3092 in _rl_dispatch src/readline/readline.c:724
    #18 0x16b2939 in readline_internal_char src/readline/readline.c:552
    #19 0x16f1fb0 in rl_callback_read_char src/readline/callback.c:201
    #20 0xddc5a1 in gdb_rl_callback_read_char_wrapper_noexcept \
                    src/gdb/event-top.c:175
    #21 0xddc773 in gdb_rl_callback_read_char_wrapper src/gdb/event-top.c:192
    #22 0xddd9f5 in stdin_event_handler(int, void*) src/gdb/event-top.c:514
    #23 0xdd7d8f in handle_file_event src/gdb/event-loop.c:731
    #24 0xdd8607 in gdb_wait_for_event src/gdb/event-loop.c:857
    #25 0xdd629c in gdb_do_one_event() src/gdb/event-loop.c:321
    #26 0xdd6344 in start_event_loop() src/gdb/event-loop.c:370
    #27 0x10a7715 in captured_command_loop src/gdb/main.c:331
    #28 0x10aa548 in captured_main src/gdb/main.c:1173
    #29 0x10aa5d8 in gdb_main(captured_main_args*) src/gdb/main.c:1188
    #30 0x87bd35 in main src/gdb/gdb.c:32
    #31 0x7fb0364c6f89 in __libc_start_main (/lib64/libc.so.6+0x20f89)
    #32 0x87bb49 in _start (build/gdb/gdb+0x87bb49)

Address 0x7fff5952bbdd is located in stack of thread T0 at offset 557 in frame
    #0 0xb93702 in location_completer(cmd_list_element*, completion_tracker&, \
                   char const*, char const*) src/gdb/completer.c:831

  This frame has 4 object(s):
    [32, 40) 'copy'
    [96, 104) 'location'
    [160, 168) 'text'
    [224, 256) 'completion_info' <== Memory access at offset 557 overflows \
                                    this variable
HINT: this may be a false positive if your program uses some custom stack \
      unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: dynamic-stack-buffer-overflow \
         src/gdb/linespec.c:727 in linespec_lexer_lex_string
Shadow bytes around the buggy address:
  0x10006b29d720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006b29d730: 00 00 00 00 00 00 f1 f1 f1 f1 00 f2 f2 f2 f2 f2
  0x10006b29d740: f2 f2 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f2 f2
  0x10006b29d750: f2 f2 00 00 00 00 f3 f3 f3 f3 00 00 00 00 00 00
  0x10006b29d760: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10006b29d770: 00 00 00 00 ca ca ca ca 00 00 00[05]cb cb cb cb
  0x10006b29d780: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
  0x10006b29d790: 00 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f3 f3 f3 f3
  0x10006b29d7a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006b29d7b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10006b29d7c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==3637==ABORTING
...

The problem happens in linespec_lexer_lex_string when lexing
"b test_abi_tag_function[abi:\0" (using a notation where we make the implicit
terminating \0 explicit).

We arrrive here with (PARSER_STREAM (parser)) == ":\0":
...
             /* Do not tokenize ABI tags such as "[abi:cxx11]".  */
             else if (PARSER_STREAM (parser) - start > 4
                      && startswith (PARSER_STREAM (parser) - 4, "[abi"))
               ++(PARSER_STREAM (parser));
...
and consume ':', after which we end up here and consume '\0':
...
         /* Advance the stream.  */
         ++(PARSER_STREAM (parser));
...
after which (PARSER_STREAM (parser)) points past the end of the string.

Fix this by removing the first "++(PARSER_STREAM (parser))", and add an assert
to the second one to detect moving past the end-of-string.

Build and tested on x86_64-linux.

gdb/ChangeLog:

2019-06-10  Tom de Vries  <tdevries@suse.de>

	PR gdb/24611
	* linespec.c (linespec_lexer_lex_string): Remove incorrect
	"++(PARSER_STREAM (parser))" for "[abi"-prefixed colon.  Add assert.

The commit "[gdb/symtab] Fix language of duplicate static minimal symbol"
introduces a performance regression, when loading a cc1 executable build with
-O0 -g and gcc 7.4.0.  The performance regression, measured in 'real' time is
about 175%.

The slower execution comes from the fact that the fix in symbol_set_names
makes the call to symbol_find_demangled_name unconditional.

Fix this by reverting the commit, and redoing the fix as follows.

Recapturing the original problem, the first time symbol_set_names is called
with gsymbol.language == lang_auto and linkage_name == "_ZL3foov", the name is
not present in the per_bfd->demangled_names_hash hash table, so
symbol_find_demangled_name is called to demangle the name, after which the
mangled/demangled pair is added to the hashtable.  The call to
symbol_find_demangled_name also sets gsymbol.language to lang_cplus.
The second time symbol_set_names is called with gsymbol.language == lang_auto
and linkage_name == "_ZL3foov", the name is present in the hash table, so the
demangled name from the hash table is used.  However, the language of the
symbol remains lang_auto.

Fix this by adding a field language in struct demangled_name_entry, and using
the field in symbol_set_names to set the language of gsymbol, if necessary.

Tested on x86_64-linux.

gdb/ChangeLog:

2019-06-10  Tom de Vries  <tdevries@suse.de>

	PR symtab/24545
	* symtab.c (struct demangled_name_entry): Add language field.
	(symbol_set_names):  Revert "[gdb/symtab] Fix language of duplicate
	static minimal symbol".  Set and use language field.

	PR 24651
	* strings.c (print_strings): Use %u to print unsigned values in
	decimal.

I noticed that the "catch assert" help text erroneously claimed to
accept an argument, and while fixing this I went ahead and added
"Usage" text and made other minor updates to the commands in
ada-lang.c.

Tested on x86-64 Fedora 29.

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

	* ada-lang.c (_initialize_ada_language): Update help text.

ARI pointed out that a recent patch introduced a call to "warning"
with a string that ended in a newline:

    https://sourceware.org/ml/gdb-patches/2019-06/msg00000.html

This is generally forbidden, I believe, because warning adds its own
newline.

This patch removes all of the trailing newlines I was able to find.  I
searched for 'warning (.*\\n"' and then fixed the ones where the
newline appeared at the end of the string (some had internal
newlines).

Tested on x86-64 Fedora 29.

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

	* m32c-tdep.c (m32c_m16c_address_to_pointer): Don't end warning
	with a newline.
	* guile/guile.c (handle_boot_error): Don't end warning with a
	newline.
	* cli/cli-cmds.c (exit_status_set_internal_vars): Don't end
	warning with a newline.
	* s12z-tdep.c (s12z_skip_prologue): Don't end warning with a
	newline.
	(s12z_frame_cache): Likewise.
	* dwarf-index-cache.c (index_cache::store): Don't end warning with
	a newline.
	* solib-svr4.c (disable_probes_interface): Don't end warning with
	a newline.
	* nat/fork-inferior.c (fork_inferior): Don't end warning with a
	newline.
	* python/python.c (do_finish_initialization): Don't end warning
	with a newline.

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

	* remote-utils.c (look_up_one_symbol, relocate_instruction): Don't
	end warning with a newline.
	* linux-s390-low.c (s390_get_wordsize): Don't end warning with a
	newline.
	* thread-db.c (attach_thread): Don't end warning with a newline.
	(thread_db_notice_clone): Likewise.
	* tracepoint.c (gdb_agent_helper_thread): Don't end warning with a
	newline.
	* linux-x86-low.c (x86_get_min_fast_tracepoint_insn_len): Don't
	end warning with a newline.

Add support for NetBSD/sh3 core file sections.  Merge multiple copies of auxv section creation into one function.

	PR 24650
	* elf.c (elfcore_make_auxv_note_section): New function.
	(elfcore_grok_note): Use it.
	(elfcore_grok_freebsd_note): Likewise.
	(elfcore_grok_openbsd_note): Likewise.
	(elfcore_grok_netbsd_note): Likewise.  Plus add support for
	NT_NETBSDCORE_AUXV notes.

A few spots in py-breakpoint.c acquire the GIL manually.  However,
because these spots generate events, and because events are expected
to be arbitrary gdb-flavored Python code, it's important to use
gdbpy_enter instead, in order to ensure that the other gdb-related
Python globals are set correctly.

This patch makes this change.  Tested on x86-64 Fedora 29.

gdb/ChangeLog
2019-06-10  Tom Tromey  <tom@tromey.com>

	* python/py-breakpoint.c (gdbpy_breakpoint_created)
	(gdbpy_breakpoint_deleted, gdbpy_breakpoint_modified): Use
	gdbpy_enter.

I noticed that elfread.c always allocates a dbx_symfile_info, even
though this is only ever needed in the unusual case of reading stabs
in ELF.

This patch moves the allocation into dbxread.c, and applies the same
treatment to similar code in coffread.c.

Regression tested on x86-64 Fedora 29.

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

	* elfread.c (elf_read_minimal_symbols): Don't set the dbx objfile
	data.
	(elf_new_init): Don't call stabsread_new_init.
	* dbxread.c (coffstab_build_psymtabs): Set dbx objfile data.
	(elfstab_build_psymtabs): Likewise.  Call stabsread_new_init.
	* coffread.c (coff_symfile_init): Don't set the dbx objfile data.

	PR 24649
	* arsup.c (ar_open): Use asprintf in place of xmalloc and
	sprintf.

gold/ChangeLog:

2019-06-07  Martin Liska  <mliska@suse.cz>

	* errors.h: Include string.

DW_AT_main_subprogram is supported in normal mode in read_partial_die, but not
in -readnow mode.

Fix this by adding support for DW_AT_main_subprogram in read_func_scope.

Tested on x86_64-linux with native and RFC target board readnow (
https://sourceware.org/ml/gdb-patches/2019-05/msg00073.html ).

gdb/ChangeLog:

2019-06-10  Tom de Vries  <tdevries@suse.de>

	PR symtab/16264
	PR symtab/24517
	* dwarf2read.c (read_func_scope): Handle DW_AT_main_subprogram.

Mention in the description of the `-rpath' LD option the restrictions
the option has with respect to searching link-time dependencies of
shared objects referred in the link.  Previously these restrictions were
only documented along with the `-rpath-link' option, which may not be
the place one would consider when looking for the semantics of `-rpath'.

Copy the relevant part of the `-rpath-link' option description then,
splitting the now overlong paragraph into three, for legibility.

	ld/
	* ld.texi (Options): Also document `-rpath' option restrictions
	in the description of the option itself.

Not all platforms have it.  Use libiberty xstrndup() instead.

(The include of libiberty.h happens in an unusual place due to the
requirements of synchronization of most source files between this
project and another that does not use libiberty.  It serves to pull
libiberty.h in for all source files in libctf/, which does the trick.)

Tested on x86_64-pc-linux-gnu, x86_64-unknown-freebsd12.0,
sparc-sun-solaris2.11, i686-pc-cygwin, i686-w64-mingw32.

libctf/
	* ctf-decls.h: Include <libiberty.h>.
	* ctf-lookup.c (ctf_lookup_by_name): Call xstrndup(), not strndup().