[gdb] [rs6000] Add ppc64*_gnu_triplet_regexp methods.

Add methods to set the target triplet so we can
find the proper gcc when our gcc is named of
the form powerpc64{le}-<foo>-gcc or ppc64{le}-<foo>-gcc.

Re: as: Replace the removed symbol with the versioned symbol

Some targets, typically embedded without shared libraries, replace the
relocation symbol with a section symbol (see tc_fix_adjustable).
Allow the test to pass for such targets.  Fixes the following.

avr-elf  +FAIL: symver symver16
d10v-elf  +FAIL: symver symver16
dlx-elf  +FAIL: symver symver16
ip2k-elf  +FAIL: symver symver16
m68k-elf  +FAIL: symver symver16
mcore-elf  +FAIL: symver symver16
pj-elf  +FAIL: symver symver16
s12z-elf  +FAIL: symver symver16
visium-elf  +FAIL: symver symver16
z80-elf  +FAIL: symver symver16

PR gas/28157
* testsuite/gas/symver/symver16.d: Relax reloc match.

[GOLD] PowerPC64 relocation overflow for -Os register save/restore funcs

Fixes a silly mistake in calculating the address of -Os out-of-line
register save/restore function copies.  Copies of these linker defined
functions are added to stub sections when the original (in
target->savres_section) can't be reached.

* powerpc.cc (Target_powerpc::Relocate::relocate): Correct address
calculation of out-of-line save/restore function copies.

Another ld script backtrack

* ldgram.y (length_spec): Throw away look-ahead NAME.

gdb: fix spacing on CCLD silent rules

sim: nltvals: localize TARGET_<ERRNO> defines

Code should not be using these directly, instead they should be
resolving these dynamically via cb_host_to_target_errno maps.
Fix the Blackfin code and remove the defines out of the header
so no new code can rely on them.

sim: rename ChangeLog files to ChangeLog-2021

Now that ChangeLog entries are no longer used for sim patches,
this commit renames all relevant sim ChangeLog to ChangeLog-2021,
similar to what we would do in the context of the "Start of New
Year" procedure.

The purpose of this change is to avoid people merging ChangeLog
entries by mistake when applying existing commits that they are
currently working on.

Also throw in a .gitignore entry to keep people from adding new
ChangeLog files anywhere in the sim tree.

Automatic date update in version.in

gdb: fix thread_step_over_chain_length

If I debug a single-thread program and look at the infrun debug logs, I
see:

    [infrun] start_step_over: stealing global queue of threads to step, length = 2

That makes no sense... turns out there's a buglet in
thread_step_over_chain_length, "num" should be initialized to 0.  I
think this bug is a leftover from an earlier version of the code (not
merged upstream) that manually walked the list, where the first item was
implicitly counted (hence the 1).

Change-Id: I0af03aa93509aed36528be5076894dc156a0b5ce

opcodes: Fix the auxiliary register numbers for ARC HS

The numbers for the auxiliary registers "tlbindex" and
"tlbcommand" of ARCv2HS are incorrect.  This patch makes
the following changes to correct that error.

 ,------------.-----------------.---------------.
 | aux. reg.  | old (incorrect) | new (correct) |
 |------------+-----------------+---------------|
 | tlbindex   |      0x463      |     0x464     |
 | tlbcommand |      0x464      |     0x465     |
 `------------^-----------------^---------------'

opcodes/
2021-08-17  Shahab Vahedi <shahab@synopsys.com>

* arc-regs.h (DEF): Fix the register numbers.

gdb: Don't assume r_ldsomap when r_version > 1 on Linux

The r_ldsomap field is specific to Solaris (part of librtld_db), and
should never be accessed for Linux.  glibc is planning to add a field
to support multiple namespaces.  But there will be no r_ldsomap when
r_version is bumped to 2.  Add linux_[ilp32|lp64]_fetch_link_map_offsets
to set r_ldsomap_offset to -1 and use them for Linux targets.

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

gdbserver: Check r_version < 1 for Linux debugger interface

Update gdbserver to check r_version < 1 instead of r_version != 1 so
that r_version can be bumped for a new field in the glibc debugger
interface to support multiple namespaces.  Since so far, the gdbserver
only reads fields defined for r_version == 1, it is compatible with
r_version >= 1.

All future glibc debugger interface changes will be backward compatible.
If there is ever the need for backward incompatible change to the glibc
debugger interface, a new DT_XXX element will be provided to access the
new incompatible interface.

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

PATCH [4/4] arm: Add Tag_PACRET_use build attribute

bfd/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* elf32-arm.c (elf32_arm_merge_eabi_attributes): Add
'Tag_PACRET_use' case.

binutils/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* readelf.c (arm_attr_tag_PAC_extension): Declare.
(arm_attr_public_tags): Add 'PAC_extension' lookup.

elfcpp/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* arm.h: Define 'Tag_PACRET_use' enum.

gas/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* config/tc-arm.c (arm_convert_symbolic_attribute): Add
'Tag_PACRET_use' to the attribute_table.

include/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* elf/arm.h (elf_arm_reloc_type): Add 'Tag_PACRET_use'.

PATCH [3/4] arm: Add Tag_BTI_use build attribute

bfd/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* elf32-arm.c (elf32_arm_merge_eabi_attributes): Add
'Tag_BTI_use' case.

binutils/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* readelf.c (arm_attr_tag_PAC_extension): Declare.
(arm_attr_public_tags): Add 'PAC_extension' lookup.

elfcpp/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* arm.h: Define 'Tag_BTI_use' enum.

gas/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* config/tc-arm.c (arm_convert_symbolic_attribute): Add
'Tag_BTI_use' to the attribute_table.

include/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* elf/arm.h (elf_arm_reloc_type): Add 'Tag_BTI_use'.

PATCH [2/4] arm: Add Tag_BTI_extension build attribute

bfd/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* elf32-arm.c (elf32_arm_merge_eabi_attributes): Add
'Tag_BTI_extension' case.

binutils/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* readelf.c (arm_attr_tag_PAC_extension): Declare.
(arm_attr_public_tags): Add 'PAC_extension' lookup.

elfcpp/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* arm.h: Define 'Tag_BTI_extension' enum.

gas/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* config/tc-arm.c (arm_convert_symbolic_attribute): Add
'Tag_BTI_extension' to the attribute_table.

include/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* elf/arm.h (elf_arm_reloc_type): Add 'Tag_BTI_extension'.

PATCH [1/4] arm: Add Tag_PAC_extension build attribute

bfd/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* elf32-arm.c (elf32_arm_merge_eabi_attributes): Add
'Tag_PAC_extension' case.

binutils/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* readelf.c (arm_attr_tag_PAC_extension): Declare.
(arm_attr_public_tags): Add 'PAC_extension' lookup.

elfcpp/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* arm.h: Define 'Tag_PAC_extension' enum.

gas/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* config/tc-arm.c (arm_convert_symbolic_attribute): Add
'Tag_PAC_extension' to the attribute_table.

include/
2021-07-06  Andrea Corallo  <andrea.corallo@arm.com>

* elf/arm.h (elf_arm_reloc_type): Add 'Tag_PAC_extension'.

x86: Always run fp tests

Always run fp tests since the size of .tfloat, .ds.x, .dc.x and .dcb.x
directive outputs is always 10 bytes.  There is no need for fp-elf32 nor
fp-elf64.

PR gas/28230
* testsuite/gas/i386/fp-elf32.d: Removed.
* testsuite/gas/i386/fp-elf64.d: Likewise.
* testsuite/gas/i386/fp.s: Remove NO_TFLOAT_PADDING codes.
* testsuite/gas/i386/i386.exp: Don't run fp-elf32 nor fp-elf64.
Always run fp.

Automatic date update in version.in

x86: Don't pad .tfloat directive output

.tfloat output should always be 10 bytes without padding, independent
of psABIs.  In glibc, x86 assembly codes expect 10-byte .tfloat output.
This also reduces .ds.x output and .tfloat output with hex input from
12 bytes to 10 bytes to match .tfloat output.

PR gas/28230
* NEWS: Mention changes of .ds.x output and .tfloat output with
hex input.
* config/tc-i386.c (x86_tfloat_pad): Removed.
* config/tc-i386.h (X_PRECISION_PAD): Changed to 0.
(x86_tfloat_pad): Removed.
* testsuite/gas/i386/fp.s: If NO_TFLOAT_PADDING isn't defined,
add explicit paddings after .tfloat, .ds.x, .dc.x and .dcb.x
directives.
* testsuite/gas/i386/i386.exp (ASFLAGS): Append
"--defsym NO_TFLOAT_PADDING=1" when running the fp test.

Fix register regression in DWARF evaluator

On an internal test case, using an arm-elf target, commit ba5bc3e5a92
("Make DWARF evaluator return a single struct value") causes a
regression.  (It doesn't happen for any of the other cross targets
that I test when importing upstream gdb.)

I don't know if there's an upstream gdb test case showing the same
problem... I can only really run native tests with dejagnu AFAIK.

The failure manifests like this:

    Breakpoint 1, file_1.export_1 (param_1=<error reading variable: Unable to access DWARF register number 64>, str=...) at [...]/file_1.adb:5

Whereas when it works it looks like:

    Breakpoint 1, file_1.export_1 (param_1=99.0, str=...) at [...]/file_1.adb:5

The difference is that the new code uses the passed-in gdbarch,
whereas the old code used the frame's gdbarch, when handling
DWARF_VALUE_REGISTER.

This patch restores the use of the frame's arch.

Fix Ada regression due to DWARF expression series

Commit 0579205aec4 ("Simplify dwarf_expr_context class interface")
caused a regression in the internal AdaCore test suite.  I didn't try
to reproduce this with the GDB test suite, but the test is identical
to gdb.dwarf2/dynarr-ptr.exp.

The problem is that this change:

  case DW_OP_push_object_address:
    /* Return the address of the object we are currently observing.  */
-   if (this->data_view.data () == nullptr
-       && this->obj_address == 0)
+   if (this->m_addr_info == nullptr)

... slightly changes the logic here.  In particular, it's possible for
the caller to pass in a non-NULL m_addr_info, but one that looks like:

    (top) p *this.m_addr_info
    $15 = {
      type = 0x29b7a70,
      valaddr = {
m_array = 0x0,
m_size = 0
      },
      addr = 0,
      next = 0x0
    }

In this case, an additional check is needed.  With the current code,
what happens instead is that the computation computes an incorrect
address -- but one that does not fail in read_memory, due to the
precise memory map of the embedded target in question.

This patch restores the old logic.

Notify observer of breakpoint auto-disabling

As breakpoint_modified observer is currently notified upon breakpoint stop
before handling auto-disabling when enable count is reached, the observer
is never notified of the disabling.

The problem affects:
- The MI interpreter enabled= value when reporting =breakpoint-modified
- A Python event handler for breakpoint_modified using the "enabled"
  member of its parameter
- insight: breakpoint GUI window is not properly updated upon auto-disable

This patch moves the observer notification after the auto-disabling
code and implements corresponding tests for the MI and Python cases.

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

Change-Id: I0c50df4789334071e5390cb46b3ca0d4a7f83c61

as: Replace the removed symbol with the versioned symbol

When a symbol removed by .symver is used in relocation and there is one
and only one versioned symbol, don't remove the symbol.  Instead, mark
it to be removed and replace the removed symbol used in relocation with
the versioned symbol before generating relocation.

PR gas/28157
* symbols.c (symbol_flags): Add removed.
(symbol_entry_find): Updated.
(symbol_mark_removed): New function.
(symbol_removed_p): Likewise.
* symbols.h (symbol_mark_removed): New prototype.
(symbol_removed_p): Likewise.
* write.c (write_relocs): Call obj_fixup_removed_symbol on
removed fixp->fx_addsy and fixp->fx_subsy if defined.
(set_symtab): Don't add a symbol if symbol_removed_p returns true.
* config/obj-elf.c (elf_frob_symbol):  Don't remove the symbol
if it is used on relocation.  Instead, mark it as to be removed
and issue an error if the symbol has more than one versioned name.
(elf_fixup_removed_symbol): New function.
* config/obj-elf.h (elf_fixup_removed_symbol): New prototype.
(obj_fixup_removed_symbol): New.
* testsuite/gas/symver/symver11.d: Updated expected error
message.
* testsuite/gas/symver/symver16.d: New file.
* testsuite/gas/symver/symver16.s: Likewise.

Automatic date update in version.in

Automatic date update in version.in

ld script fill pattern expression

It turns out we do need to backtrack when parsing after all.  The
fill_opt component in the section rule swiches to EXPRESSION and back
to SCRIPT, and to find the end of an expression it is necessary to
look ahead one token.

* ldgram.y (section): Throw away lookahead NAME token.
(overlay_section): Likewise.
* testsuite/ld-elf/overlay.t: Add fill pattern on overlays.
Test fill pattern before stupidly named normal sections too,
and before /DISCARD/.

Automatic date update in version.in

ld lexer tidy, possibly break the world

This tidies the states in which ld lexer rules are enabled.
This change will quite likely trip over issues similar to those
mentioned in the new ldlex.l comments, so please test it out.

* ldgram.y (wildcard_name): Remove now unnecessary components.
* ldlex.l: Restrict many rules' states.  Remove -l expression
state rule.  Comment on lookahead state madness and need for
/DISCARD/ in expression state.

ld script lower-case absolute and sizeof_headers

I think these happened by accident, so let's see what breaks if they
are removed.

* ldlex.l: Remove lower case "absolute" and "sizeof_headers"
in non-mri mode.
* ld.texi: Remove sizeof_headers index.
* testsuite/ld-mmix/mmohdr1.ld: Use SIZEOF_HEADERS.

tidy mri script extern

MRI mode generally doesn't flip lexer states, so let's make MRI mode
"extern" not do so either.

* ldgram.y (extern_name_list): Don't change lex state here.
(ifile_p1): Change state here on EXTERN instead.

Re: PR28217, Syntax error when memory region contains a hyphen

I discovered some more errors when tightening up the lexer rules.
Just because we INCLUDE a file doesn't mean we've switched states.

PR 28217
* ldgram.y (statement): Don't switch lexer state on INCLUDE.
(mri_script_command, ifile_p1, memory_spec, section): Likewise.

PR28168: [CSKY] Fix stack overflow in disassembler

PR 28168:
Stack overflow with a large float. %f is not a goot choice for this.
%f should be replaced with %.7g.

gas/
* testsuite/gas/csky/pr28168.d: New testcase for PR 28168.
* testsuite/gas/csky/pr28168.s: Likewise.
* testsuite/gas/csky/v2_float_part2.d: Following the new format.
* opcodes/csky-dis.c (csky_output_operand): %.7g replaces %f.

PR28217, Syntax error when memory region contains a hyphen

The saga of commit 40726f16a8d7 continues.  This attacks the problem
of switching between SCRIPT and EXPRESSION state lexing by removing
the need to do so for phdrs like ":text".  Instead {WILDCHAR}*
matching, the reason why ":text" lexed as one token, is restricted to
within the braces of a section or overlay statement.  The new WILD
lexer state is switched at the non-optional brace tokens, so
ldlex_backup is no longer needed.  I've also removed the BOTH state,
which doesn't seem to be needed any more.  Besides rules involving
error reporting, there was just one place where SCRIPT appeared
without BOTH, the {WILDCHAR}* rule, three where BOTH appears without
SCRIPT for tokens that only need EXPRESSION state, and two where BOTH
appears alongside INPUT_LIST.  (Since I'm editing the wild and
filename rules, removing BOTH and adding WILD can also be seen as
renaming the old BOTH state to SCRIPT and renaming the old SCRIPT
state to WILD with a reduced scope.)

As a followup, I'll look at removing EXPRESSION state from some lexer
rules that no longer need it due to this cleanup.

PR 28217
* ldgram.y (exp <ORIGIN, LENGTH>): Use paren_script_name.
(section): Parse within braces of section in wild mode, and
after brace back in script mode.  Remove ldlex_backup call.
Similarly for OVERLAY.
(overlay_section): Similarly.
(script_file): Replace ldlex_both with ldlex_script.
* ldlex.h (ldlex_wild): Declare.
(ldlex_both): Delete.
* ldlex.l (BOTH): Delete.  Remove state from all rules.
(WILD): New state.  Enable many tokens in this state.
Enable filename match in SCRIPT mode.  Enable WILDCHAR match
in WILD state, disable in SCRIPT mode.
(ldlex_wild): New function.
* ldfile.c (ldfile_try_open_bfd): Replace ldlex_both call with
ldlex_script.

ns32k configury

Since ns32k-netbsd is as yet not removed, just marked obsolete,
the target should still be accepted with --enable-obsolete.

I also enabled ns32k-openbsd in ld since there doesn't seem to be a
good reason why that target is not supported there but is elsewhere.

bfd/
* config.bfd: Allow ns32k-netbsd.
ld/
* configure.tgt: Allow ns32k-openbsd.

Automatic date update in version.in

gdb: riscv_scan_prologue: handle LD and LW instructions

While working on the testsuite, I ended up noticing that GDB fails to
produce a full backtrace from a thread waiting in pthread_join.  When
selecting the waiting thread and using the 'bt' command, the following
result can be observed:

(gdb) bt
#0  0x0000003ff7fccd20 in __futex_abstimed_wait_common64 () from /lib/riscv64-linux-gnu/libpthread.so.0
#1  0x0000003ff7fc43da in __pthread_clockjoin_ex () from /lib/riscv64-linux-gnu/libpthread.so.0
Backtrace stopped: frame did not save the PC

On my platform, I do not have debug symbols for glibc, so I need to rely
on prologue analysis in order to unwind stack.

Here is what the function prologue looks like:

(gdb) disassemble __pthread_clockjoin_ex
Dump of assembler code for function __pthread_clockjoin_ex:
   0x0000003ff7fc42de <+0>:     addi    sp,sp,-144
   0x0000003ff7fc42e0 <+2>:     sd      s5,88(sp)
   0x0000003ff7fc42e2 <+4>:     auipc   s5,0xd
   0x0000003ff7fc42e6 <+8>:     ld      s5,-2(s5) # 0x3ff7fd12e0
   0x0000003ff7fc42ea <+12>:    ld      a5,0(s5)
   0x0000003ff7fc42ee <+16>:    sd      ra,136(sp)
   0x0000003ff7fc42f0 <+18>:    sd      s0,128(sp)
   0x0000003ff7fc42f2 <+20>:    sd      s1,120(sp)
   0x0000003ff7fc42f4 <+22>:    sd      s2,112(sp)
   0x0000003ff7fc42f6 <+24>:    sd      s3,104(sp)
   0x0000003ff7fc42f8 <+26>:    sd      s4,96(sp)
   0x0000003ff7fc42fa <+28>:    sd      s6,80(sp)
   0x0000003ff7fc42fc <+30>:    sd      s7,72(sp)
   0x0000003ff7fc42fe <+32>:    sd      s8,64(sp)
   0x0000003ff7fc4300 <+34>:    sd      s9,56(sp)
   0x0000003ff7fc4302 <+36>:    sd      a5,40(sp)

As far as prologue analysis is concerned, the most interesting part is
done at address 0x0000003ff7fc42ee (<+16>): 'sd ra,136(sp)'. This stores
the RA (return address) register on the stack, which is the information
we are looking for in order to identify the caller.

In the current implementation of the prologue scanner, GDB stops when
hitting 0x0000003ff7fc42e6 (<+8>) because it does not know what to do
with the 'ld' instruction.  GDB thinks it reached the end of the
prologue but have not yet reached the important part, which explain
GDB's inability to unwind past this point.

The section of the prologue starting at <+4> until <+12> is used to load
the stack canary[1], which will then be placed on the stack at <+36> at
the end of the prologue.

In order to have the prologue properly handled, this commit proposes to
add support for the ld instruction in the RISC-V prologue scanner.
I guess riscv32 would use lw in such situation so this patch also adds
support for this instruction.

With this patch applied, gdb is now able to unwind past pthread_join:

(gdb) bt
#0  0x0000003ff7fccd20 in __futex_abstimed_wait_common64 () from /lib/riscv64-linux-gnu/libpthread.so.0
#1  0x0000003ff7fc43da in __pthread_clockjoin_ex () from /lib/riscv64-linux-gnu/libpthread.so.0
#2  0x0000002aaaaaa88e in bar() ()
#3  0x0000002aaaaaa8c4 in foo() ()
#4  0x0000002aaaaaa8da in main ()

I have had a look to see if I could reproduce this easily, but in my
simple testcases using '-fstack-protector-all', the canary is loaded
after the RA register is saved.  I do not have a reliable way of
generating a prologue similar to the problematic one so I forged one
instead.

The testsuite have been run on riscv64 ubuntu 21.01 with no regression
observed.

[1] https://en.wikipedia.org/wiki/Buffer_overflow_protection#Canaries

Update documentation to mention Pygments

Philippe Blain pointed out that the gdb documentation does not mention
that Pygments may be used for source highlighting.  This patch updates
the docs to reflect how highlighting is actually done.

gdb: make gdbarch_printable_names return a vector

I noticed that gdbarch_selftest::operator() leaked the value returned by
gdbarch_printable_names.  Make gdbarch_printable_names return an
std::vector and update callers.  That makes it easier for everyone
involved, less manual memory management.

Change-Id: Ia8fc028bdb91f787410cca34f10bf3c5a6da1498

Improve forward progress test in python.exp

The test steps into func2 and than does an up to get back to the previous
frame. The test checks that the line number you are at after the up command
is greater than the line where the function was called from. The
assembly/codegen for the powerpc target includes a NOP after the
branch-link.

func2 (); /* Break at func2 call site. /
10000694: 59 00 00 48 bl 100006ec
10000698: 00 00 00 60 nop
return 0; / Break to end. */
1000069c: 00 00 20 39 li r9,0

The PC at the instruction following the branch-link is 0x10000698 which
GDB.find_pc_line() maps to the same line number as the bl instruction.
GDB did move past the branch-link location thus making forward progress.

The following proposed fix adds an additional PC check to see if forward
progress was made.  The line test is changed from greater than to greater
than or equal.

gdb:csky rm tdesc_has_registers in csky_register_name

As CSKY arch has not parsed target-description.xml in csky_gdbarch_init,
when a remote server, like csky-qemu or gdbserver, send a target-description.xml
to gdb, tdesc_has_registers will return ture, but tdesc_register_name (gdbarch, 0)
will return NULL, so a cmd "info registers r0" will not work.

Function of parsing target-description.xml will be add later for CSKY arch,
now it is temporarily removed to allow me to do other supported tests.

2021-07-15 Jiangshuai Li  <jiangshuai_li@c-sky.com>

            * csky-tdep.c : not using tdesc funtions in csky_register_name

Re: gas: support NaN flavors

Fixes tic4x-coff FAIL: simple FP constants

* testsuite/gas/all/float.s: Make NaN tests conditional on hasnan.
* testsuite/gas/all/gas.exp: Define hasnan.

Automatic date update in version.in

ld: Update the pass and fail strings of PR ld/28138 test

PR ld/28138
* testsuite/ld-plugin/lto.exp: Update the pass and fail strings
of PR ld/28138 test to indicate which part of the test passed
and failed.

Fix a typo in the RX asse,bler.  The Double-precision floating-point exception handling control register name is DECNT not DCENT.

* config/rx-parse.y (DECNT): Fixed typo.
* testsuite/gas/rx/dpopm.sm (DECNT): Fixed typo.
* testsuite/gas/rx/dpushm.sm (DECNT): Fixed typo.
* testsuite/gas/rx/macros.inc (DECNT): Fixed typo.

Fix an internal error in the CSKY assembler when asked to resolve an overlarge constant.

PR 28215
* config/tc-csky.c (md_apply_fix): Correctly handle a fixup that
involves an overlarge constant.

Add 3 new PAC-related ARM note types

The following patch synchronizes includes/objdump/readelf with the Linux
Kernel in terms of ARM regset notes.

We're currently missing 3 of them:

NT_ARM_PACA_KEYS
NT_ARM_PACG_KEYS
NT_ARM_PAC_ENABLED_KEYS

We don't need GDB to bother with this at the moment, so this doesn't update
bfd/elf.c. If needed, we can do it in the future.

binutils/

* readelf.c (get_note_type): Handle new ARM PAC notes.

include/elf/

* common.h (NT_ARM_PACA_KEYS, NT_ARM_PACG_KEYS)
(NT_ARM_PAC_ENABLED_KEYS): New constants.

Updated Portuguese translation for the binutils sub-directory.

Deprecate a.out support for NetBSD targets.

As discussed previously, a.out support is now quite deprecated, and in
some cases removed, in both Binutils itself and NetBSD, so this legacy
default makes little sense. `netbsdelf*` and `netbsdaout*` still work
allowing the user to be explicit about there choice. Additionally, the
configure script warns about the change as Nick Clifton requested.

One possible concern was the status of NetBSD on NS32K, where only a.out
was supported. But per [1] NetBSD has removed support, and if it were to
come back, it would be with ELF. The binutils implementation is
therefore marked obsolete, per the instructions in the last message.

With that patch and this one applied, I have confirmed the following:

--target=i686-unknown-netbsd
--target=i686-unknown-netbsdelf
  builds completely

--target=i686-unknown-netbsdaout
  properly fails because target is deprecated.

--target=vax-unknown-netbsdaout builds completely except for gas, where
the target is deprecated.

[1]: https://mail-index.netbsd.org/tech-toolchain/2021/07/19/msg004025.html
---
 bfd/config.bfd                             | 43 +++++++++++++--------
 bfd/configure.ac                           |  5 +--
 binutils/testsuite/binutils-all/nm.exp     |  2 +-
 binutils/testsuite/lib/binutils-common.exp |  7 +---
 config/picflag.m4                          |  4 +-
 gas/configure.tgt                          |  9 +++--
 gas/testsuite/gas/arm/blx-bl-convert.d     |  2 +-
 gas/testsuite/gas/arm/blx-local-thumb.d    |  2 +-
 gas/testsuite/gas/sh/basic.exp             |  2 +-
 gdb/configure.host                         | 34 +++++++----------
 gdb/configure.tgt                          |  2 +-
 gdb/testsuite/gdb.asm/asm-source.exp       |  6 +--
 intl/configure                             |  2 +-
 ld/configure.tgt                           | 44 +++++++++++-----------
 ld/testsuite/ld-arm/arm-elf.exp            |  4 +-
 ld/testsuite/ld-elf/elf.exp                |  2 +-
 ld/testsuite/ld-elf/shared.exp             |  4 +-
 libiberty/configure                        |  4 +-

gdb: don't print backtrace when dumping core after an internal error

Currently, when GDB hits an internal error, and the user selects to
dump core, the recently added feature to write a backtrace to the
console will kick in, and print a backtrace as well as dumping the
core.

This was certainly not my intention when adding the backtrace on fatal
signal functionality, this feature was intended to produce a backtrace
when GDB crashes due to some fatal signal, internal errors should have
continued to behave as they did before, unchanged.

In this commit I set the signal disposition of SIGABRT back to SIG_DFL
just prior to the call to abort() that GDB uses to trigger the core
dump, this prevents GDB reaching the code that writes the backtrace to
the console.

I've also added a test that checks we don't see a backtrace on the
console after an internal error.

gdb: register SIGBUS, SIGFPE, and SIGABRT handlers

Register handlers for SIGBUS, SIGFPE, and SIGABRT.  All of these
signals are setup as fatal signals that will cause GDB to terminate.
However, by passing these signals through the handle_fatal_signal
function, a user can arrange to see a backtrace when GDB
terminates (see maint set backtrace-on-fatal-signal).

In normal use of GDB there should be no user visible changes after
this commit.  Only if GDB terminates with one of the above signals
will GDB change slightly, potentially printing a backtrace before
aborting.

I've added new tests for SIGFPE, SIGBUS, and SIGABRT.

gdb: print backtrace on fatal SIGSEGV

This commit adds a new maintenance feature, the ability to print
a (limited) backtrace if GDB dies due to a fatal signal.

The backtrace is produced using the backtrace and backtrace_symbols_fd
functions which are declared in the execinfo.h header, and both of
which are async signal safe.  A configure check has been added to
check for these features, if they are not available then the new code
is not compiled into GDB and the backtrace will not be printed.

The motivation for this new feature is to aid in debugging GDB in
situations where GDB has crashed at a users site, but the user is
reluctant to share core files, possibly due to concerns about what
might be in the memory image within the core file.  Such a user might
be happy to share a simple backtrace that was written to stderr.

The production of the backtrace is on by default, but can switched off
using the new commands:

  maintenance set backtrace-on-fatal-signal on|off
  maintenance show backtrace-on-fatal-signal

Right now, I have hooked this feature in to GDB's existing handling of
SIGSEGV only, but this will be extended to more signals in a later
commit.

One additional change I have made in this commit is that, when we
decide GDB should terminate due to the fatal signal, we now
raise the same fatal signal rather than raising SIGABRT.

Currently, this is only effecting our handling of SIGSEGV.  So,
previously, if GDB hit a SEGV then we would terminate GDB with a
SIGABRT.  After this commit we will terminate GDB with a SIGSEGV.

This feels like an improvement to me, we should still get a core dump,
but in many shells, the user will see a more specific message once GDB
exits, in bash for example "Segmentation fault" rather than "Aborted".

Finally then, here is an example of the output a user would see if GDB
should hit an internal SIGSEGV:

  Fatal signal: Segmentation fault
  ----- Backtrace -----
  ./gdb/gdb[0x8078e6]
  ./gdb/gdb[0x807b20]
  /lib64/libpthread.so.0(+0x14b20)[0x7f6648c92b20]
  /lib64/libc.so.6(__poll+0x4f)[0x7f66484d3a5f]
  ./gdb/gdb[0x1540f4c]
  ./gdb/gdb[0x154034a]
  ./gdb/gdb[0x9b002d]
  ./gdb/gdb[0x9b014d]
  ./gdb/gdb[0x9b1aa6]
  ./gdb/gdb[0x9b1b0c]
  ./gdb/gdb[0x41756d]
  /lib64/libc.so.6(__libc_start_main+0xf3)[0x7f66484041a3]
  ./gdb/gdb[0x41746e]
  ---------------------
  A fatal error internal to GDB has been detected, further
  debugging is not possible.  GDB will now terminate.

  This is a bug, please report it.  For instructions, see:
  <https://www.gnu.org/software/gdb/bugs/>.

  Segmentation fault (core dumped)

It is disappointing that backtrace_symbols_fd does not actually map
the addresses back to symbols, this appears, in part, to be due to GDB
not being built with -rdynamic as the manual page for
backtrace_symbols_fd suggests, however, even when I do add -rdynamic
to the build of GDB I only see symbols for some addresses.

We could potentially look at alternative libraries to provide the
backtrace (e.g. libunwind) however, the solution presented here, which
is available as part of glibc is probably a good baseline from which
we might improve things in future.

gdb: rename async_init_signals to gdb_init_signals

The async_init_signals has, for some time, dealt with async and sync
signals, so removing the async prefix makes sense I think.

Additionally, as pointed out by Pedro:

  .....

The comments relating to SIGTRAP and SIGQUIT within this function are
out of date.

The comments for SIGTRAP talk about the signal disposition (SIG_IGN)
being passed to the inferior, meaning the signal disposition being
inherited by GDB's fork children.  However, we now call
restore_original_signals_state prior to forking, so the comment on
SIGTRAP is redundant.

The comments for SIGQUIT are similarly out of date, further, the
comment on SIGQUIT talks about problems with BSD4.3 and vfork,
however, we have not supported BSD4.3 for several years now.

Given the above, it seems that changing the disposition of SIGTRAP is
no longer needed, so I've deleted the signal() call for SIGTRAP.

Finally, the header comment on the function now called
gdb_init_signals was getting quite out of date, so I've updated it
to (hopefully) better reflect reality.

There should be no user visible change after this commit.

gdb: register signal handler after setting up event token

This commit fixes the smallest of small possible bug related to signal
handling.  If we look in async_init_signals we see code like this:

  signal (SIGQUIT, handle_sigquit);
  sigquit_token =
    create_async_signal_handler (async_do_nothing, NULL, "sigquit");

Then if we look in handle_sigquit we see code like this:

  mark_async_signal_handler (sigquit_token);
  signal (sig, handle_sigquit);

Finally, in mark_async_signal_handler we have:

  async_handler_ptr->ready = 1;

Where async_handler_ptr will be sigquit_token.

What this means is that if a SIGQUIT arrive in async_init_signals
after handle_sigquit has been registered, but before sigquit_token has
been initialised, then GDB will most likely crash.

The chance of this happening is tiny, but fixing this is trivial, just
ensure we call create_async_signal_handler before calling signal, so
lets do that.

There are no tests for this.  Trying to land a signal in the right
spot is pretty hit and miss.  I did try changing the current HEAD GDB
like this:

  signal (SIGQUIT, handle_sigquit);
  raise (SIGQUIT);
  sigquit_token =
    create_async_signal_handler (async_do_nothing, NULL, "sigquit");

And confirmed that this did result in a crash, after my change I tried
this:

  sigquit_token =
    create_async_signal_handler (async_do_nothing, NULL, "sigquit");
  signal (SIGQUIT, handle_sigquit);
  raise (SIGQUIT);

And GDB now starts up just fine.

gdb/ChangeLog:

* event-top.c (async_init_signals): For each signal, call signal
only after calling create_async_signal_handler.

gdb: terminate upon receipt of SIGFPE

GDB's SIGFPE handling is broken, this is PR gdb/16505 and
PR gdb/17891.

We currently try to use an async event token to process SIGFPE.  So,
when a SIGFPE arrives the signal handler calls
mark_async_signal_handler then returns, effectively ignoring the
signal (for now).

The intention is that later the event loop will see that the async
token associated with SIGFPE has been marked and will call the async
handler, which just throws an error.

The problem is that SIGFPE is not safe to ignore.  Ignoring a
SIGFPE (unless it is generated artificially, e.g. by raise()) is
undefined behaviour, after ignoring the signal on many targets we
return to the instruction that caused the SIGFPE to be raised, which
immediately causes another SIGFPE to be raised, we get stuck in an
infinite loop.  The behaviour is certainly true on x86-64.

To view this behaviour I simply added some dummy code to GDB that
performed an integer divide by zero, compiled this on x86-64
GNU/Linux, ran GDB and saw GDB hang.

In this commit, I propose to remove all special handling of SIGFPE and
instead just let GDB make use of the default SIGFPE action, that is,
to terminate the process.

The only user visible change here should be:

  - If a user sends a SIGFPE to GDB using something like kill,
    previously GDB would just print an error and remain alive, now GDB
    will terminate.  This is inline with what happens if the user
    sends GDB a SIGSEGV from kill though, so I don't see this as an
    issue.

  - If a bug in GDB causes a real SIGFPE, previously the users GDB
    session would hang.  Now the GDB session will terminate.  Again,
    this is inline with what happens if GDB receives a SIGSEGV due to
    an internal bug.

In bug gdb/16505 there is mention that it would be nice if GDB did
more than just terminate when receiving a fatal signal.  I haven't
done that in this commit, but later commits will move in that
direction.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16505
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17891

PR28198, Support # as linker script comment marker

PR 28198
* ldlex.l: Combine rules for handling newline, whitespace and
comments.  Extend # comment handling to all states.

ldgram.y tidies

I've been tripped up before thinking the "end" rule was the "END"
token.  Let's use a better name.  The formatting changes are for
consistency within rules, and making it a little easier to visually
separate tokens from mid-rule actions.

* ldgram.y (separator): Rename from "end".  Update uses.
(statement): Formatting.  Move ';' match to beginning.
(paren_script_name): Formatting.  Simplify.
(must_be_exp, section): Formatting.

Mention whitespace in script expressions

Inside an output section statement, ld's parser can't tell whether a
line
    .+=4;
is an assignment to dot or a file named ".+=4".

* ld.texi (expressions): Mention need for whitespace.

Add a -mno-dollar-line-separator command line option to the AVR assembler.

Some frontends, like the gcc Objective-C frontend, emit symbols with $
characters in them.  The AVR target code in gas treats $ as a line separator,
so the code doesn?t assemble correctly.

Provide a machine-specific option to disable treating $ as a line separator.

* config/tc-avr.c (enum options): Add option flag.
(struct option): Add option -mno-dollar-line-separator.
(md_parse_option): Adjust treatment of $ when option is present.
* config/tc-avr.h: Use avr_line_separator_chars.

Fix typo in previous delta

gas: fold IEEE encoding of -Inf with that of +Inf

The respective results differ only by the sign bits - there's no need to
have basically identical (partially even arch-specific) logic twice.
Simply set the sign bit at the end of encoding the various formats.

gas: support NaN flavors

Like for infinity, there isn't just a single NaN. The sign bit may be
of interest and, going beyond infinity, whether the value is quiet or
signalling may be even more relevant to be able to encode.

Note that an anomaly with x86'es double extended precision NaN values
gets taken care of at the same time: For all other formats a positive
value with all mantissa bits set was used, while here a negative value
with all non-significant mantissa bits clear was chose for an unknown
reason.

For m68k, since I don't know their X_PRECISION floating point value
layout, a warning gets issued if any of the new flavors was attempted
to be encoded that way. However likely it may be that, given that the
code lives in a source file supposedly implementing IEEE-compliant
formats, the bit patterns of the individual words match x86'es, I didn't
want to guess so. And my very, very old paper doc doesn't even mention
floating point formats other than single and double.

Arm64: leave .bfloat16 processing to common code

With x86 support having been implemented by extending atof-ieee.c, avoid
unnecessary code duplication in md_atof(). This will then also allow to
take advantage of adjustments made there without needing to mirror them
here.

Arm32: leave more .bfloat16 processing to common code

With x86 support having been implemented by extending atof-ieee.c, avoid
unnecessary code duplication in md_atof(). This will then also allow to
take advantage of adjustments made there without needing to mirror them
here.

gas: make 2nd argument of .dcb.* consistently optional

Unlike the forms consuming/producing integer data, the floating point
ones so far required the 2nd argument to be present, contrary to
documentation. To avoid code duplication, split float_length() out of
hex_float() (taking the opportunity to adjust error message wording).

x86: introduce .bfloat16 directive

This is to be able to generate data acted upon by AVX512-BF16 and
AMX-BF16 insns. While not part of the IEEE standard, the format is
sufficiently standardized to warrant handling in config/atof-ieee.c.
Arm, where custom handling was implemented, may want to leverage this as
well. To be able to also use the hex forms supported for other floating
point formats, a small addition to the generic hex_float() is needed.

Extend existing x86 testcases.

x86: introduce .hfloat directive

This is to be able to generate data passed to {,V}CVTPH2PS and acted
upon by AVX512-FP16 insns. To be able to also use the hex forms
supported for other floating point formats, a small addition to the
generic hex_float() is needed.

Extend existing x86 testcases.

x86/ELF: fix .tfloat output with hex input

The ELF psABI-s are quite clear here: On 32-bit the data type is 12
bytes long (with 2 bytes of trailing padding), while on 64-bit it is 16
bytes long (with 6 bytes of padding). Make hex_float() capable of
handling such padding.

Note that this brings the emitted data size of .dc.x / .dcb.x in line
also for non-ELF targets; so far they were different depending on input
format (dec vs hex).

Extend the existing x86 testcases.

x86/ELF: fix .ds.x output

The ELF psABI-s are quite clear here: On 32-bit the underlying data type
is 12 bytes long (with 2 bytes of trailing padding), while on 64-bit it
is 16 bytes long (with 6 bytes of padding). Make s_space() capable of
handling 'x' (and 'p') type floating point being other than 12 bytes
wide (also adjusting documentation). This requires duplicating the
definition of X_PRECISION in the target speciifc header; the compiler
would complain if this was out of sync with config/atof-ieee.c.

Note that for now padding space doesn't get separated from actual
storage, which means that things will work correctly only for little-
endian cases, and which also means that by specifying large enough
numbers padding space can be set to non-zero. Since the logic is needed
for a single little-endian architecture only for now, I'm hoping that
this might be acceptable for the time being; otherwise the change will
become more intrusive.

Note also that this brings the emitted data size of .ds.x vs .tfloat in
line for non-ELF targets as well; the issue will be even more obvious
when further taking into account a subsequent patch fixing .dc.x/.dcb.x
(where output sizes currently differ depending on input format).

Extend existing x86 testcases.

x86/ELF: fix .tfloat output

The ELF psABI-s are quite clear here: On 32-bit the data type is 12
bytes long (with 2 bytes of trailing padding), while on 64-bit it is 16
bytes long (with 6 bytes of padding). Make ieee_md_atof() capable of
handling such padding, and specify the needed padding for x86 (leaving
non-ELF targets alone for now). Split the existing x86 testcase.

x86: have non-PE/COFF BEOS be recognized as ELF

BEOS, unless explicitly requesting *-*-beospe* targets, uses standard
ELF. None of the newly enabled tests in the testsuite fail for me.

PR28163, Segment fault in function rl78_special_reloc

Relocation offset checks were completely missing in the rl78 backend,
allowing a relocation to write over memory anywhere.  This was true
for rl78_special_reloc, a function primarily used when applying debug
relocations, and in rl78_elf_relocate_section used by the linker.

This patch fixes those problems by correcting inaccuracies in the
relocation howtos, then uses those howtos to sanity check relocation
offsets before applying relocations.  In addition, the patch
implements overflow checking using the howto information rather than
the ad-hoc scheme implemented in relocate_section.  I implemented the
overflow checking in rl78_special_reloc too.

* elf32-rl78.c (RL78REL, RL78_OP_REL): Add mask parameter.
(rl78_elf_howto_table): Set destination masks.  Correct size and
bitsize of DIR32_REV.  Correct complain_on_overflow for many relocs
as per tests in relocate_section.  Add RH_SFR.  Correct bitsize
for RH_SADDR.  Set size to 3 and bitsize to 0 for all OP relocs.
(check_overflow): New function.
(rl78_special_reloc): Check that reloc address is within section.
Apply relocations using reloc howto.  Check for overflow.
(RANGE): Delete.
(rl78_elf_relocate_section): Sanity check r_offset.  Perform
overflow checking using reloc howto.

Automatic date update in version.in

Ignore .debug_types when reading .debug_aranges

I noticed that the fission-reread.exp test case can cause a complaint
when run with --target_board=cc-with-debug-names:

warning: Section .debug_aranges in [...]/fission-reread has duplicate debug_info_offset 0x0, ignoring .debug_aranges.

The bug here is that this executable has both .debug_info and
.debug_types, and both have a CU at offset 0x0.  This triggers the
duplicate warning.

Because .debug_types doesn't provide any address ranges, these CUs can
be ignored.  That is, this bug turns out to be another regression from
the info/types merger patch.

This patch fixes the problem by having this loop igore type units.
fission-reread.exp is updated to test for the bug.

Generalize addrmap dumping

While debugging another patch series, I wanted to dump an addrmap.  I
came up with this patch, which generalizes the addrmap-dumping code
from psymtab.c and moves it to addrmap.c.  psymtab.c is changed to use
the new code.

gdb: iterate only on vfork parent threads in handle_vfork_child_exec_or_exit

I spotted what I think is a buglet in proceed_after_vfork_done.  After a
vfork child exits or execs, we resume all the threads of the parent.  To
do so, we iterate on all threads using iterate_over_threads with the
proceed_after_vfork_done callback.  Each thread is resumed if the
following condition is true:

    if (thread->ptid.pid () == pid
&& thread->state == THREAD_RUNNING
&& !thread->executing
&& !thread->stop_requested
&& thread->stop_signal () == GDB_SIGNAL_0)

where `pid` is the pid of the vfork parent.  This is not multi-target
aware: since it only filters on pid, if there is an inferior with the
same pid in another target, we could end up resuming a thread of that
other inferior.  The chances of the stars aligning for this to happen
are tiny, but still.

Fix that by iterating only on the vfork parent's threads, instead of on
all threads.  This is more efficient, as we iterate on just the required
threads (inferiors have their own thread list), and we can drop the pid
check.  The resulting code is also more straightforward in my opinion,
so it's a win-win.

Change-Id: I14647da72e2bf65592e82fbe6efb77a413a4be3a

Updated Serbian and Russian translations for various sub-directories

guile: fix smob exports

Before Guile v2.1 [1], calls to `scm_make_smob_type' implicitly added
the created class to the exports list of (oop goops); v2.1+ does not
implicitly create bindings in any modules. This means that the GDB
manual subsection documenting exported types is not quite right when GDB
is linked against Guile <v2.1 (types are exported from (oop goops))
instead of (gdb)) and incorrect when linked against Guile v2.1+ (types
are not bound to any variables at all!).

There is a range of cases in which it's necessary or convenient to be
able to refer to a GDB smob type, for instance:

 - Pattern matching based on the type of a value.
 - Defining GOOPS methods handling values from GDB (GOOPS methods
   typically use dynamic dispatch based on the types of the arguments).
 - Type-checking assertions when applying some defensive programming on
   an interface.
 - Generally any other situation one might encounter in a dynamically
   typed language that might need some introspection.

If you're more familiar with Python, it would be quite similar to being
unable to refer to the classes exported from the GDB module (which is to
say: not crippling for the most part, but makes certain tasks more
difficult than necessary).

This commit makes a small change to GDB's smob registration machinery
to make sure registered smobs get exported from the current
module. This will likely cause warnings to the user about conflicting
exports if they load both (gdb) and (oop goops) from a GDB linked
against Guile v2.0, but it shouldn't impact functionality (and seemed
preferable to trying to un-export bindings from (oop goops) if v2.0
was detected).

[1]: This changed with Guile commit
     28d0871b553a3959a6c59e2e4caec1c1509f8595

gdb/ChangeLog:

2021-06-07  George Barrett  <bob@bob131.so>

* guile/scm-gsmob.c (gdbscm_make_smob_type): Export registered
smob type from the current module.

gdb/testsuite/ChangeLog:

2021-06-07  George Barrett  <bob@bob131.so>

* gdb.guile/scm-gsmob.exp (test exports): Add tests to make
sure the smob types currently listed in the GDB manual get
exported from the (gdb) module.

Change-Id: I7dcd791276b48dfc9edb64fc71170bbb42a6f6e7

Automatic date update in version.in

GAS: DWARF-5: Ensure that the 0'th entry in the directory table contains the current working directory.

* dwarf2dbg.c (get_directory_table_entry): Ensure that dir[0]
contains current working directory.
(out_dir_and_file_list): Likewise.
* testsuite/gas/elf/dwarf-5-dir0.s: New test source file.
* testsuite/gas/elf/dwarf-5-dir0.d: New test driver.
* testsuite/gas/elf/elf.exp: Run the new test.
* testsuite/gas/elf/dwarf-5-file0.d: Adjust expected output.
* testsuite/gas/i386/dwarf5-line-1.d: Likewise.
* testsuite/gas/i386/dwarf5-line-2.d: Likewise.

Automatic date update in version.in

Include objfiles.h in a few .c files

I found a few .c files that rely on objfiles.h, but that only include
it indirectly, via dwarf2/read.h -> psympriv.h.  If that include is
removed (something my new DWARF indexer series does), then the build
will break.

It seemed harmless and correct to add these includes now, making the
eventual series a little smaller.

Automatic date update in version.in

PR28186, SEGV elf.c:7991:30 in _bfd_elf_fixup_group_sections

PR 28186
* elf.c (_bfd_elf_fixup_group_sections): Don't segfault on
objcopy/strip with NULL output_section.

PR28176, rl78 complex reloc divide by zero

This is a bit more than just preventing the divide by zero.  Most of
the patch is tidying up error reporting, so that for example, linking
an object file with a reloc stack underflow produces a linker error
rather than just displaying a message that might be ignored.

PR 28176
* elf32-rl78.c (RL78_STACK_PUSH, RL78_STACK_POP): Delete.
(rl78_stack_push, rl78_stack_pop): New inline functions.
(rl78_compute_complex_reloc): Add status and error message params.
Use new inline stack handling functions.  Report stack overflow
or underflow, and divide by zero.
(rl78_special_reloc): Return status and error message from
rl78_compute_complex_reloc.
(rl78_elf_relocate_section): Similarly.  Modernise reloc error
reporting.  Delete unused bfd_reloc_other case.  Don't assume
DIR24S_PCREL overflow is due to undefined function.
(rl78_offset_for_reloc): Adjust to suit rl78_compute_complex_reloc.

Automatic date update in version.in

[gdb/symtab] Recognize .gdb_index symbol table with empty entries as empty

When reading a .gdb_index that contains a non-empty symbol table with only
empty entries, gdb doesn't recognize it as empty.

Fix this by recognizing that the constant pool is empty, and then setting the
symbol table to empty.

Tested on x86_64-linux.

gdb/ChangeLog:

2021-08-01  Tom de Vries  <tdevries@suse.de>

PR symtab/28159
* dwarf2/read.c (read_gdb_index_from_buffer): Handle symbol table
filled with empty entries.

gdb/testsuite/ChangeLog:

2021-08-01  Tom de Vries  <tdevries@suse.de>

PR symtab/28159
* gdb.dwarf2/dw2-zero-range.exp: Remove kfail.

Unconditionally define _initialize_addrmap

The way that init.c is generated does not allow for an initialization
function to be conditionally defined -- doing so will result in a link
error.

This patch fixes a build problem that arises from such a conditional
definition.  It can be reproduce with --disable-unit-tests.

[gdb/symtab] Fix zero address complaint for shlib

In PR28004 the following warning / Internal error is reported:
...
$ gdb -q -batch \
    -iex "set sysroot $(pwd -P)/repro" \
    ./repro/gdb \
    ./repro/core \
    -ex bt
  ...
 Program terminated with signal SIGABRT, Aborted.
 #0  0x00007ff8fe8e5d22 in raise () from repro/usr/lib/libc.so.6
 [Current thread is 1 (LWP 1762498)]
 #1  0x00007ff8fe8cf862 in abort () from repro/usr/lib/libc.so.6
 warning: (Internal error: pc 0x7ff8feb2c21d in read in psymtab, \
           but not in symtab.)
 warning: (Internal error: pc 0x7ff8feb2c218 in read in psymtab, \
           but not in symtab.)
  ...
 #2  0x00007ff8feb2c21e in __gnu_debug::_Error_formatter::_M_error() const \
   [clone .cold] (warning: (Internal error: pc 0x7ff8feb2c21d in read in \
   psymtab, but not in symtab.)

) from repro/usr/lib/libstdc++.so.6
...

The warning is about the following:
- in find_pc_sect_compunit_symtab we try to find the address
  (0x7ff8feb2c218 / 0x7ff8feb2c21d) in the symtabs.
- that fails, so we try again in the partial symtabs.
- we find a matching partial symtab
- however, the partial symtab has a full symtab, so
  we should have found a matching symtab in the first step.

The addresses are:
...
(gdb) info sym 0x7ff8feb2c218
__gnu_debug::_Error_formatter::_M_error() const [clone .cold] in \
  section .text of repro/usr/lib/libstdc++.so.6
(gdb) info sym 0x7ff8feb2c21d
__gnu_debug::_Error_formatter::_M_error() const [clone .cold] + 5 in \
  section .text of repro/usr/lib/libstdc++.so.6
...
which correspond to unrelocated addresses 0x9c218 and 0x9c21d:
...
$ nm -C  repro/usr/lib/libstdc++.so.6.0.29 | grep 000000000009c218
000000000009c218 t __gnu_debug::_Error_formatter::_M_error() const \
  [clone .cold]
...
which belong to function __gnu_debug::_Error_formatter::_M_error() in
/build/gcc/src/gcc/libstdc++-v3/src/c++11/debug.cc.

The partial symtab that is found for the addresses is instead the one for
/build/gcc/src/gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc, which is
incorrect.

This happens as follows.

The bitmap_allocator.cc CU has DW_AT_ranges at .debug_rnglist offset 0x4b50:
...
    00004b50 0000000000000000 0000000000000056
    00004b5a 00000000000a4790 00000000000a479c
    00004b64 00000000000a47a0 00000000000a47ac
...

When reading the first range 0x0..0x56, it doesn't trigger the "start address
of zero" complaint here:
...
      /* A not-uncommon case of bad debug info.
         Don't pollute the addrmap with bad data.  */
      if (range_beginning + baseaddr == 0
          && !per_objfile->per_bfd->has_section_at_zero)
        {
          complaint (_(".debug_rnglists entry has start address of zero"
                       " [in module %s]"), objfile_name (objfile));
          continue;
        }
...
because baseaddr != 0, which seems incorrect given that when loading the
shared library individually in gdb (and consequently baseaddr == 0), we do see
the complaint.

Consequently, we run into this case in dwarf2_get_pc_bounds:
...
  if (low == 0 && !per_objfile->per_bfd->has_section_at_zero)
    return PC_BOUNDS_INVALID;
...
which then results in this code in process_psymtab_comp_unit_reader being
called with cu_bounds_kind == PC_BOUNDS_INVALID, which sets the set_addrmap
argument to 1:
...
      scan_partial_symbols (first_die, &lowpc, &highpc,
                            cu_bounds_kind <= PC_BOUNDS_INVALID, cu);
...
and consequently, the CU addrmap gets build using address info from the
functions.

During that process, addrmap_set_empty is called with a range that includes
0x9c218 and 0x9c21d:
...
(gdb) p /x start
$7 = 0x9989c
(gdb) p /x end_inclusive
$8 = 0xb200d
...
but it's called for a function at DIE 0x54153 with DW_AT_ranges at 0x40ae:
...
    000040ae 00000000000b1ee0 00000000000b200e
    000040b9 000000000009989c 00000000000998c4
    000040c3 <End of list>
...
and neither range includes 0x9c218 and 0x9c21d.

This is caused by this code in partial_die_info::read:
...
            if (dwarf2_ranges_read (ranges_offset, &lowpc, &highpc, cu,
                                    nullptr, tag))
             has_pc_info = 1;
...
which pretends that the function is located at addresses 0x9989c..0xb200d,
which is indeed not the case.

This patch fixes the first problem encountered: fix the "start address of
zero" complaint warning by removing the baseaddr part from the condition.
Same for dwarf2_ranges_process.

The effect is that:
- the complaint is triggered, and
- the warning / Internal error is no longer triggered.

This does not fix the observed problem in partial_die_info::read, which is
filed as PR28200.

Tested on x86_64-linux.

Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>
gdb/ChangeLog:

2021-07-29  Simon Marchi  <simon.marchi@polymtl.ca>
    Tom de Vries  <tdevries@suse.de>

PR symtab/28004
* gdb/dwarf2/read.c (dwarf2_rnglists_process, dwarf2_ranges_process):
Fix zero address complaint.
* gdb/testsuite/gdb.dwarf2/dw2-zero-range-shlib.c: New test.
* gdb/testsuite/gdb.dwarf2/dw2-zero-range.c: New test.
* gdb/testsuite/gdb.dwarf2/dw2-zero-range.exp: New file.

Re: Add tests for Intel AVX512_FP16 instructions

* testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.d: Pass with
mingw section padding.

chew ubsan warning

It matters not at all if pc is incremented from its initial NULL
value, but avoid this silly runtime ubsan error.

* doc/chew.c (perform): Avoid incrementing NULL pc.

bfd_reloc_offset_in_range overflow

This patch is more about the style of bounds checking we ought to use,
rather than a real problem.  An overflow of "octet + reloc_size" can
only happen with huge sections which would certainly cause out of
memory errors.

* reloc.c (bfd_reloc_offset_in_range): Avoid possible overflow.

PR28175, Segment fault in coff-tic30.c reloc_processing

The obj_convert table shouldn't be accessed without first checking the
index against the table size.

PR 28175
* coff-tic30.c (reloc_processing): Sanity check reloc symbol index.
* coff-z80.c (reloc_processing): Likewise.
* coff-z8k.c (reloc_processing): Likewise.

PR28173, nds32_elf_howto_table index out of bounds

Indexing the howto table was seriously broken by a missing entry, and
use of assertions about user input rather than testing the input.

PR 28173
* elf32-nds32.c (nds32_elf_howto_table): Add missing empty howto.
(bfd_elf32_bfd_reloc_type_table_lookup): Replace assertions with
range checks.  Return NULL if unsupported reloc type.  Remove
dead code.  Take an unsigned int param.
(nds32_info_to_howto_rel): Test for NULL howto or howto name
return from lookup.  Remove assertion.
(nds32_info_to_howto): Remove unnecessary ATTRIBUTE_UNUSED.
Test for NULL howto or howto name return from lookup.

PR28172, bfin_pcrel24_reloc heap-buffer-overflow

bfin pcrel24 relocs are weird, they apply to the reloc address minus
two.  That means reloc addresses of 0 and 1 are invalid.  Check that,
and fix other reloc range checking.

PR 28172
* elf32-bfin.c (bfin_pcrel24_reloc): Correct reloc range check.
(bfin_imm16_reloc, bfin_byte4_reloc, bfin_bfd_reloc): Likewise.
(bfin_final_link_relocate): Likewise.

Automatic date update in version.in

[PATCH] GDB Testsuite, update compile-cplus.exp

[PATCH] GDB Testsuite, update compile-cplus.exp

Update the gdb.compile/compile-cplus.exp test to
handle errors generated when passing bad arguments
into the gdb-compile command.
This matches changes made to gdb.compile/compile.exp
in the past as part of
"Migrate rest of compile commands to new options framework"
         e6ed716cd5514c08b9d7c469d185b1aa177dbc22

[gdb] Handle .TOC. sections during gdb-compile for rs6000 target.

[gdb] Handle .TOC. sections during gdb-compile for rs6000 target.

  When we encounter a .TOC. symbol in the object we are loading,
we need to associate this with the .toc section in order to
properly resolve other symbols in the object.  IF a .toc section
is not found, iterate the sections until we find one with the
SEC_ALLOC flag.  If that also fails, fall back to using
the *ABS* section, pointed to by bfd_abs_section_ptr.

gdb/testsuite: gdb.base/attach.exp: expose bug when testing with native-extended-gdbserver

In gdb.base/attach.exp, proc do_attach_failure_tests, we attach to a
process.  When then try to attach to the same process in another
inferior, expecting it to fail.  We then come back to the first inferior
and try to kill it, to clean up the test.  When using the
native-extended-gdbserver board, this "kill" test passes, even though it
didn't actually work:

    add-inferior
    [New inferior 2]
    Added inferior 2 on connection 1 (extended-remote localhost:2347)
    (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: add empty inferior 2
    inferior 2
    [Switching to inferior 2 [<null>] (<noexec>)]
    (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: switch to inferior 2
    attach 817032
    Attaching to process 817032
    Attaching to process 817032 failed
    (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: fail to attach again
    inferior 1
    [Switching to inferior 1 [process 817032] (/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/attach/attach)]
    [Switching to thread 1.1 (Thread 817032.817032)]
    #0  main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/attach.c:19
    19   while (! should_exit)
    (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: switch to inferior 1
    kill
    Kill the program being debugged? (y or n) y
    Remote connection closed  <==== That's unexpected
    (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: exit after attach failures

When the second attach fails, gdbserver seems to break the connection
(it hangs up on the existing remote target) and start listening again
for incoming connections.  This is documented in PR 19558 [1].

Make the expected output regexp for the kill command tighter (it
currently accepts anything).  Use "set confirm off" so we don't have to
deal with the confirmation.  And to be really sure the extended-remote
target still works, try to run the inferior again after killing.  The
now tests are kfail'ed when the target is gdbserver.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=19558

gdb/testsuite/ChangeLog:

* gdb.base/attach.exp (do_attach_failure_tests): Make kill
regexp tighter, run inferior after killing it.  Kfail when
target is gdbserver.

Change-Id: I99c5cd3968ce2ec962ace35b016f842a243b7a0d

gdb/testsuite: gdb.base/attach.exp: fix support check in test_command_line_attach_run

When running this test with the native-extended-gdbserver, we get:

    main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/attach.c:19
    19   while (! should_exit)
    The program being debugged has been started already.
    Start it from the beginning? (y or n) PASS: gdb.base/attach.exp: cmdline attach run: run to prompt
    y
    Don't know how to run.  Try "help target".
    (gdb) FAIL: gdb.base/attach.exp: cmdline attach run: run to main

This test tests using both "-p <pid>" and "-ex start" on the command line,
making sure that we first attach and then run.

Normally, after that "y", we should see the program running again.
However, a particuliarity of the native-extended-gdbserver is that it
uses "set auto-connect-native-target off" on the command line.  The full
GDB command line is:

    ./gdb -nw -nx -data-directory /home/simark/build/binutils-gdb/gdb/testsuite/../data-directory \
          -iex set height 0 -iex set width 0 -ex set auto-connect-native-target off \
  -ex set sysroot -quiet -iex set height 0 -iex set width 0 --pid=536609 -ex start

The attach succeeds.  I guess it is done before "set
auto-connect-native-target off", or it somehow bypasses it.  When the
"start" is executed, the native target is unpushed, while killing the
existing process, but not re-pushed, due to "set
auto-connect-native-target off".  So we get that "Don't know how to run"
message.

Really, I think it's a case of the test doing things incompatible with
the board, I think it should just be skipped.  And as we can see with
the current code, there were some attempts at doing this, just using the
wrong checks:

 - isnative: this is a dejagnu proc which checks if the target board has
   the same triplet as the build machine.  In the case of
   native-extended-gdbserver, it does.
 - is_remote target: this checks whether the target board is remote, as
   in executing on a different machin.  native-extended-gdbserver is not
   remote.

Since the --pid option specifically attaches to a process using the
native target, change the test to use gdb_is_target_native instead.

gdb/testsuite/ChangeLog:

* gdb.base/attach.exp (test_command_line_attach_run): Use
gdb_is_target_native to check if test is supported.

Change-Id: I762e127f39623889999dc9ed2185540a0951bfb0

gdb: target_waitstatus_to_string: print extra info for FORKED, VFORKED, EXECD

Print the extra information contained in target_waitstatus for these
events.  For TARGET_WAITKIND_{FORKED,VFORKED}, the extra information is
contained in related_pid, and is the ptid of the new process.  For
TARGET_WAITKIND_EXECD, it,s the exec'd path name in execd_pathname.
Print it using the same format used for TARGET_WAITKIND_STOPPED and
others.

Here are sample outputs for all three events:

    [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
    [infrun] print_target_wait_results:   726890.726890.0 [process 726890],
    [infrun] print_target_wait_results:   status->kind = vforked, related_pid = 726894.726894.0

    [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
    [infrun] print_target_wait_results:   727045.727045.0 [process 727045],
    [infrun] print_target_wait_results:   status->kind = forked, related_pid = 727049.727049.0

    [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
    [infrun] print_target_wait_results:   727119.727119.0 [process 727119],
    [infrun] print_target_wait_results:   status->kind = execd, execd_pathname = /usr/bin/ls

Change-Id: I4416a74e3bf792a625a68bf26c51689e170f2184