gdb/riscv: fix gdb.arch/riscv-unwind-long-insn.exp on RV64

I noticed that the gdb.arch/riscv-unwind-long-insn.exp test was
failing when run on a 64-bit RISC-V target.

The problem was that GDB was failing to stop after a finish command,
and was then running to an unexpected location.

The reason GDB failed to stop at the finish breakpoint was that the
frame-id of the inferior, when we reached the finish breakpoint,
didn't match the expected frame-id that was stored on the breakpoint.

The reason for this mismatch was that the assembler code that is
included in this test, was written only taking 32-bit RISC-V into
account, as a result, the $fp register was being corrupted, and this
was causing the frame-id mismatch.

Specifically, the $fp register would end up being sign-extended from
32 to 64 bits.  If the expected $fp value has some significant bits
above bit 31 then the computed and expected frame-ids would not match.

To fix this I propose merging the two .s files into a single .S file,
and making use of preprocessor macros to specialise the file for the
correct size of $fp.  There are plenty of existing tests that already
make use of preprocessor macros in assembler files, so I assume this
approach is fine.

Once I'd decided to make use of preprocessor macros to solve the 32/64
bit issue, then I figured I might as well merge the two test assembler
files, they only differed by a single instruction.

With this change in place I now see this test fully passing on 32 and
64 bit RISC-V targets.

gdb/testsuite: fix breakpoint script output in gdb.mi/mi-break.exp

Commit 9db0d8536dbc ("gdb/mi: fix breakpoint script field output") fixed
the output of the script key in the MI breakpoint output, from

  script={"print 10","continue"}

to

  script=["print 10","continue"]

However, it missed updating this test case, which still tests for the
old (broken) form, causing:

    FAIL: gdb.mi/mi-break.exp: mi-mode=main: test_breakpoint_commands: breakpoint commands: check that commands are set (unexpected output)
    FAIL: gdb.mi/mi-break.exp: mi-mode=separate: test_breakpoint_commands: breakpoint commands: check that commands are set (unexpected output)

Update the test to expect the new form.

Change-Id: I174919d4eea53e96d914ca9bd1cf6f01c8de30b8

Use strwinerror in gdb/windows-nat.c

When working on windows-nat.c, it's useful to see an error message in
addition to the error number given by GetLastError.  This patch moves
strwinerror from gdbserver to gdbsupport, and then updates
windows-nat.c to use it.  A couple of minor changes to strwinerror
(constify the return type and use the ARRAY_SIZE macro) are also
included.

Remove register_gdbarch_init

This removes the deprecated register_gdbarch_init in favor a default
argument to gdbarch_register.  Regression tested on x86-64 Fedora 34.

PR29495, rewrite_elf_program_header looping

This patch, in order of significance:
1) Replaces some macros with inline functions.
2) Those inline functions catch and avoid arithmetic overflows when
   comparing addresses.
3) When assigning sections to segments (IS_SECTION_IN_INPUT_SEGMENT)
   use bed->want_p_paddr_set_to_zero to decide whether lma vs p_paddr
   or vma vs p_vaddr should be tested.  When remapping, use the same
   test, and use is_note rather than the more restrictive
   IS_COREFILE_NOTE.

It's important that the later tests not be more restrictive.  If they
are it can lead to the situation triggered by the testcases, where a
section seemingly didn't fit and thus needed a new mapping.  It didn't
fit the new mapping either, and this repeated until memory exhausted.

PR 29495
* elf.c (SEGMENT_END, SECTION_SIZE, IS_CONTAINED_BY_VMA): Delete.
(IS_CONTAINED_BY_LMA, IS_NOTE, IS_COREFILE_NOTE): Delete.
(segment_size, segment_end, section_size): New inline function.
(is_contained_by, is_note): Likewise.
(rewrite_elf_program_header): Use new functions.

x86: shorten certain template names

Now that we can purge templates, let's use this to improve readability a
little by shortening a few of their names, making functionally similar
ones also have identical names in their multiple incarnations.

x86: template-ize certain vector conversion insns

Many of the vector conversion insns come with X/Y/Z suffixed forms, for
disambiguation purposes in AT&T syntax. All of these gorups follow
certain patterns. Introduce "xy" and "xyz" templates to reduce
redundancy.

To facilitate using a uniform name for both AVX and AVX512, further
introduce a means to purge a previously defined template: A standalone
<name> will be recognized to have this effect.

Note that in the course of the conversion VFPCLASSPH is properly split
to separate AT&T and Intel syntax forms, matching VFPCLASSP{S,D} and
yielding the intended "ambiguous operand size" diagnostic in Intel mode.

x86: template-ize vector packed byte/word integer insns

Many of the vector integer insns come in byte/word element pairs. Most
of these pairs follow certain encoding patterns. Introduce a "bw"
template to reduce redundancy.

Note that in the course of the conversion
- the AVX VPEXTRW template which is not being touched needs to remain
  ahead of the new "combined" ones, as (a) this should be tried first
  when matching insns against templates and (b) its Load attributes
  requires it to be first,
- this add a benign/meaningless IgnoreSize attribute to the memory form
  of PEXTRB; it didn't seem worth avoiding this.

x86: re-order AVX512 S/G templates

The AVX2 gather ones are nicely grouped - do the same for the various
AVX512 scatter/gather ones. On the moved lines also convert EVex=<n> to
EVex<N>.

x86: template-ize vector packed dword/qword integer insns

Many of the vector integer insns come in dword/qword element pairs. Most
of these pairs follow certain encoding patterns. Introduce a "dq"
template to reduce redundancy.

Note that in the course of the conversion
- a few otherwise untouched templates are moved, so they end up next to
  their siblings),
- drop an unhelpful Cpu64 from the GPR form of VPBROADCASTQ, matching
  what we already have for KMOVQ - the diagnostic is better this way for
  insns with multiple forms (i.e. the same Cpu64 attributes on {,V}MOVQ,
  {,V}PEXTRQ, and  {,V}PINSRQ are useful to keep),
- this adds benign/meaningless IgnoreSize attributes to the GPR forms of
  KMOVD and VPBROADCASTD; it didn't seem worth avoiding this.

x86: template-ize packed/scalar vector floating point insns

The vast majority of vector FP insns comes in single/double pairs. Many
pairs follow certain encoding patterns. Introduce an "sd" template to
reduce redundancy. Similarly, to further cover similarities between
AVX512F and AVX512-FP16, introduce an "sdh" template.

For element-size Disp8 shift generalize i386-gen's broadcast size
determination, allowing Disp8MemShift to be specified without an operand
in the affected templated templates. While doing the adjustment also
eliminate an unhelpful (lost information) diagnostic combined with a use
after free in what is now get_element_size().

Note that in the course of the conversion
- the AVX512F form of VMOVUPD has a stray (leftover) Load attribute
  dropped,
- VMOVSH has a benign IgnoreSize added (the attribute is still strictly
  necessary for VMOVSD, and necessary for VMOVSS as long as we permit
  strange combinations like "-march=i286+avx"),
- VFPCLASSPH is properly split to separate AT&T and Intel syntax forms,
  matching VFPCLASSP{S,D}.

revert "x86: Also pass -P to $(CPP) when processing i386-opc.tbl"

This reverts commit 384f368958f2a5bb083660e58e5f8a010e6ad429, which
broke i386-gen's emitting of diagnostics. As a replacement to address
the original issue of newer gcc no longer splicing lines when dropping
the line continuation backslashes, switch to using + as the line
continuation character, doing the line splicing in i386-gen.

Automatic date update in version.in

PR29362, some binutils memory leaks

2022-08-16  Alan Modra  <amodra@gmail.com>
    Cunlong Li  <shenxiaogll@163.com>

PR 29362
* dwarf.c (free_debug_information): New function, extracted..
(free_debug_memory): ..from here.
(process_debug_info): Use it when before clearing out unit
debug_information.  Clear all fields.
* objcopy.c (delete_symbol_htabs): New function.
(main): Call it via xatexit.
(copy_archive): Free "dir".
* objdump.c (free_debug_section): Free reloc_info.

gdb/csky add unwinder for sigtramp frame when kernel 4.x and later

When kernel veriosn >= V4.x, the characteristic values used to
determine whether it is a signal function call are:
    movi r7, 139
    trap 0

Registers are saved at (sp + CSKY_SIGINFO_OFFSET + CSKY_SIGINFO_SIZE
+ CSKY_UCONTEXT_SIGCONTEXT + CSKY_SIGCONTEXT_PT_REGS_TLS). The order
is described in csky_linux_rt_sigreturn_init_pt_regs.

aarch64_pei_vec

I know this target is just a skeleton, but let's not write out relocs
with uninitialised garbage.

* coff-aarch64.c (SWAP_IN_RELOC_OFFSET): Define.
(SWAP_OUT_RELOC_OFFSET): Define.

Automatic date update in version.in

gdb/riscv: improve a comment about fcsr, fflags, and frm registers

There's a comment in riscv-tdep.c that explains some of the background
about how we check for the fcsr, fflags, and frm registers within a
riscv target description.

This comment (and the functionality it describes) relates to how QEMU
advertises these registers within its target description.

Unfortunately, QEMU includes these three registers in both the fpu and
crs target description features.  To work around this GDB uses one of
the register declarations, and ignores the other, this means the GDB
user sees a single copy of each register, and things just work.

When I originally wrote the comment I thought it didn't matter which
copy of the register GDB selected, the fpu copy or the csr copy, so
long as we just used one of them.  The comment reflected this belief.

Upon further investigation, it turns out I was wrong.  GDB has to use
the csr copy of the register.  If GDB tries to use the register from
the fpu feature then QEMU will return an error when GDB tries to read
or write the register.

Luckily, the code within GDB (currently) will always select the csr
copy of the register, so nothing is broken, but the comment is wrong.
This commit updates the comment to better describe what is actually
going on.

Of course, I should probably also send a patch to QEMU to fix up the
target description that is sent to GDB.

gdb/nds32: update features/nds32.c

After this commit:

  commit 7b7c365c5c663ffdfb2b3f696db35c23cdccd921
  Date:   Wed Sep 15 10:10:46 2021 +0200

      [bfd] Ensure unique printable names for bfd archs

The printable name field of the default nds32 bfd_arch_info changed
from 'n1h' to 'n1'.  As a consequence the generated feature file
within GDB should have been recreated.  Recreate it now.

Move decode_location_spec to code_breakpoint

breakpoint::decode_location_spec just asserts if called.  It turned
out to be relatively easy to remove this method from breakpoint and
instead move the base implementation to code_breakpoint.

Change location_spec_to_sals to a method

location_spec_to_sals is only ever called for code breakpoints, so
make it a protected method there.

Change breakpoint_re_set_default to a method

breakpoint_re_set_default is only ever called from breakpoint re_set
methods, so make it a protected method on code_breakpoint.

Automatic date update in version.in

PR29482 - strip: heap-buffer-overflow

PR 29482
* coffcode.h (coff_set_section_contents): Sanity check _LIB.

asan: NULL dereference in spu_elf_object_p

* elf32-spu.c (spu_elf_object_p): Don't dereference NULL
shdr->bfd_section.

ubsan: undefined shift in sign_extend

* libhppa.h (sign_extend): Avoid undefined behaviour.

asan: NULL dereference in som_set_reloc_info

* som.c (som_set_reloc_info): Ignore non-existent previous
fixup references.

readelf: print 0x0 as 0, and remove trailing spaces

This changes readelf output a little, removing the 0x prefix on hex
output when the value is 0, except in cases where a fixed field
width is shown.  %#010x is not a good replacement for 0x%08x.

Make dwarf_vma uint64_t

This replaces dwarf_vma, dwarf_size_type and dwarf_signed_vma with
uint64_t and int64_t everywhere.  The patch also gets rid of
DWARF_VMA_FMT since we can't use that with uint64_t, and all of the
configure support for deciding the flavour of HOST_WIDEST_INT.
dwarf_vmatoa also disappears, replacing most uses with one of
PRIx64, PRId64 or PRIu64.  Printing of size_t and ptrdiff_t values
now use %z and %t rather than by casting to unsigned long.  Also,
most warning messages that used 0x%lx or similar now use %#lx and a
few that didn't print the 0x hex prefix now also use %#.  The patch
doesn't change normal readelf output, except in odd cases where values
previously might have been truncated.

Don't use bfd_vma in readelf.c

This replaces bfd_vma with uint64_t in readelf, defines BFD64
unconditionally, removes tests of BFD64 and sizeof (bfd_vma), and
removes quite a few now unnecessary casts.

Don't use bfd_size_type in readelf.c and dwarf.c

Replacing bfd_size_type with dwarf_size_type or uint64_t is mostly
cosmetic.  The point of the change is to avoid use of a BFD type
in readelf, where we'd like to keep as independent of BFD as
possible.  Also, the patch is a step towards using standard types.

Replace elf_vma with uint64_t

This patch replaces all uses of elf_vma with uint64_t, removes
tests of sizeof (elf_vma), and does a little tidying of
byte_get_little_endian and byte_get_big_endian.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp

When running test-case gdb.dwarf2/dw2-dir-file-name.exp on x86_64-linux, we
have:
...
(gdb) break compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line 999.^M
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, 0x00000000004004c4 in \
  compdir_missing__ldir_missing__file_basename () \
  at tmp-dw2-dir-file-name.c:999^M
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
  compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
  compdir_missing__ldir_missing__file_basename
...

When trying to set a breakpoint on
compdir_missing__ldir_missing__file_basename, the architecture-specific
prologue skipper starts at 0x4004c0 and skips past two insns, to 0x4004c4:
...
00000000004004c0 <compdir_missing__ldir_missing__file_basename>:
  4004c0: 55                      push   %rbp
  4004c1: 48 89 e5                mov    %rsp,%rbp
  4004c4: 8b 05 72 1b 20 00       mov    0x201b72(%rip),%eax        # 60203c <v>
  4004ca: 83 c0 01                add    $0x1,%eax
  4004cd: 89 05 69 1b 20 00       mov    %eax,0x201b69(%rip)        # 60203c <v>
  4004d3: 90                      nop
  4004d4: 5d                      pop    %rbp
  4004d5: c3                      ret
...

And because the line table info is rudamentary:
...
CU: tmp-dw2-dir-file-name.c:
File name                    Line number    Starting address    View    Stmt
tmp-dw2-dir-file-name.c              999            0x4004c0               x
tmp-dw2-dir-file-name.c             1000            0x4004d6               x
tmp-dw2-dir-file-name.c                -            0x4004d6
...
the address does not fall at an actual line, so the breakpoint is shown with
address, both when setting it and hitting it.

when running the test-case with aarch64-linux, we have similarly:
...
(gdb) break compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line 999.^M
...
due to the architecture-specific prologue skipper starting at 0x400610 and
skipping past two insns, to 0x400618:
...
0000000000400610 <compdir_missing__ldir_missing__file_basename>:
  400610:       90000100        adrp    x0, 420000 <__libc_start_main@GLIBC_2.17>
  400614:       9100b000        add     x0, x0, #0x2c
  400618:       b9400000        ldr     w0, [x0]
  40061c:       11000401        add     w1, w0, #0x1
  400620:       90000100        adrp    x0, 420000 <__libc_start_main@GLIBC_2.17>
  400624:       9100b000        add     x0, x0, #0x2c
  400628:       b9000001        str     w1, [x0]
  40062c:       d503201f        nop
  400630:       d65f03c0        ret
...

But interestingly, the aarch64 architecture-specific prologue skipper is
wrong.  There is no prologue, and the breakpoint should be set at 0x400610.

By using "break *compdir_missing__ldir_missing__file_basename"
we can get the breakpoint set at 0x400610:
...
(gdb) break *compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line 999.^M
...
and make the test-case independent of prologue analysis.

This requires us to update the expected patterns.

The fix ensures that once the aarch64 architecture-specific prologue skipper
will be fixed, this test-case won't start failing.

Tested on x86_64-linux.

Automatic date update in version.in

gdb/varobj: Only re-evaluate invalid globals during re_set

When doing varobj_re_set, we currently try to recreate floating varobj.
This was introduced by 4e969b4f0128 "Re-evaluate floating varobj as part
of varobj_invalidate" to deal with use a after free issue.  However
since bc20e562ec0 "Fix use after free in varobj" we now ensure that we
never have dangling pointers so this all recreation is not strictly
needed anymore for floating varobjs.

This commit proposes to remove this recreation process for floating
varobjs.

Tested on x86_64-linux.

gdb/varobj: Reset varobj after relocations have been computed

[This patch is a followup to the discussion in
https://sourceware.org/pipermail/gdb-patches/2022-August/191188.html]

PR/29426 shows failures when running the gdb.mi/mi-var-invalidate-shlib
test when using a compiler which does not produce a PIE executable by
default.

In the testcase, a varobj is created to track a global variable, and
then the main binary is reloaded in GDB (using the file command).

During the load of the new binary, GDB tries to recreate the varobj to
track the global in the new binary (varobj_invalidate_iter).  At this
point, the old process is still in flight.  So when we try to access to
the value of the global, in a PIE executable we only have access to the
unrelocated address (the objfile's text_section_offset () is 0).  As a
consequence down the line read_value_memory fails to read the unrelated
address, so cannot evaluate the value of the global.  Note that the
expression used to access to the global’s value is valid, so the varobj
can be created.  When using a non PIE executable, the address of the
global GDB knows about at this point does not need relocation, so
read_value_memory can access the (old binary’s) value.

So at this point, in the case of a non-PIE executable the value field is
set, while it is cleared in the case of PIE executable.  Later when the
test issues a "-var-update global_var", the command sees no change in
the case of the non-PIE executable, while in the case of the PIE
executable install_new_value sees that value changes, leading to a
different output.

This patch makes sure that, as we do for breakpoints, we wait until
relocation has happened before we try to recreate varobjs.  This way we
have a consistent behavior between PIE and non-PIE binaries.

Tested on x86_64-linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29426
Co-authored-by: Lancelot SIX <lancelot.six@amd.com>

gdb/varobj: Do not invalidate locals in varobj_invalidate_iter

The varobj_invalidate_iter function has logic to invalidate any local
varobj it can find.  However since bc20e562ec0 "gdb/varobj: Fix use
after free in varobj" all varobj containing references to an objfile are
cleared when the objfile goes out of scope.  This means that at this
point any local varobj seen by varobj_invalidate_iter either has
already been invalidated by varobj_invalidate_if_uses_objfile or only
contains valid references and there is no reason to invalidate it.

This patch proposes to remove this unnecessary invalidation and adds a
testcase which exercises a scenario where a local varobj can legitimately
survive a call to varobj_invalidate_iter.

At this point the varobj_invalidate and varobj_invalidate_iter seem
misnamed since they deal with re-creating invalid objects and do not do
invalidation, but this will be fixed in a following patch.

Tested on x86_64-linux.

ppc/svp64: support svindex instruction

https://libre-soc.org/openpower/sv/
https://libre-soc.org/openpower/sv/remap/#svindex
https://libre-soc.org/openpower/isa/simplev/

ppc/svp64: support svremap instruction

https://libre-soc.org/openpower/sv/
https://libre-soc.org/openpower/sv/remap/#svremap
https://libre-soc.org/openpower/isa/simplev/

ppc/svp64: support svshape instruction

https://libre-soc.org/openpower/sv/
https://libre-soc.org/openpower/sv/remap/#svshape
https://libre-soc.org/openpower/isa/simplev/

ppc/svp64: support svstep instructions

https://libre-soc.org/openpower/sv/
https://libre-soc.org/openpower/sv/svstep/
https://libre-soc.org/openpower/isa/simplev/

ppc/svp64: support setvl instructions

https://libre-soc.org/openpower/sv/
https://libre-soc.org/openpower/sv/setvl/
https://libre-soc.org/openpower/isa/simplev/

ppc/svp64: introduce non-zero operand flag

svstep and svshape instructions subtract 1 before encoding some of the
operands. Obviously zero is not supported for these operands. Whilst
PPC_OPERAND_PLUS1 fits perfectly to mark that maximal value should be
incremented, there is no flag which marks the fact that zero values are
not allowed. This patch adds a new flag, PPC_OPERAND_NONZERO, for this
purpose.

ppc/svp64: support LibreSOC architecture

This patch adds support for LibreSOC machine and SVP64 extension flag
for PowerPC architecture. SV (Simple-V) is a strict RISC-paradigm
Scalable Vector Extension for the Power ISA. SVP64 is the 64-bit
Prefixed instruction format implementing SV. Funded by NLnet through EU
Grants No: 825310 and 825322, SV is in DRAFT form and is to be publicly
submitted via the OpenPOWER Foundation ISA Working Group via the
newly-created External RFC Process.

For more details, visit https://libre-soc.org.

[Arm] Cleanup arm_m_exception_cache

With this change, only valid contents of LR are accepted when unwinding
exception frames for m-profile targets.

If the contents of LR are anything but EXC_RETURN or FNC_RETURN, it
will cause GDB to print an error and/or abort unwinding of the frame as
it's an invalid state for the unwinder.

The FNC_RETURN pattern requires Security Extensions to be enabled.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

RISC-V: Remove R_RISCV_GNU_VTINHERIT/R_RISCV_GNU_VTENTRY

They were legacy relocation types copied from other ports.  The related
-fvtable-gc was removed from GCC in 2003.

The associated assembler directives (.vtable_inherit and .vtable_entry)
have never been supported by the RISC-V port.  Remove related ld code.

Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/323

PR29466, APP/NO_APP with .linefile

Commit 53f2b36a54b9 exposed a bug in sb_scrub_and_add_sb that could
result in losing input.  If scrubbing results in expansion past the
holding capacity of do_scrub_chars output buffer, then do_scrub_chars
stashes the extra input for the next call.  That call never came
because sb_scrub_and_add_sb wrongly decided it was done.  Fix that by
allowing sb_scrub_and_add_sb to see whether there is pending input.
Also allow a little extra space so that in most cases we won't need
to resize the output buffer.

sb_scrub_and_add_sb also limited output to the size of the input,
rather than the actual output buffer size.  Fixing that resulted in a
fail of gas/testsuite/macros/dot with an extra warning: "end of file
not at end of a line; newline inserted".  OK, so the macro in dot.s
really does finish without end-of-line.  Apparently the macro
expansion code relied on do_scrub_chars returning early.  So fix that
too by adding a newline if needed in macro_expand_body.

PR 29466
* app.c (do_scrub_pending): New function.
* as.h: Declare it.
* input-scrub.c (input_scrub_include_sb): Add extra space for
two .linefile directives.
* sb.c (sb_scrub_and_add_sb): Take into account pending input.
Allow output to max.
* macro.c (macro_expand_body): Add terminating newline.
* testsuite/config/default.exp (SIZE, SIZEFLAGS): Define.
* testsuite/gas/macros/app5.d,
* testsuite/gas/macros/app5.s: New test.
* testsuite/gas/macros/macros.exp: Run it.

regen potfiles

Automatic date update in version.in

gdb/mi: fix breakpoint script field output

The "script" field, output whenever information about a breakpoint with
commands is output, uses wrong MI syntax.

    $ ./gdb -nx -q --data-directory=data-directory -x script -i mi
    =thread-group-added,id="i1"
    =breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",original-location="main"}
    =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",script={"aaa","bbb","ccc"},original-location="main"}
    (gdb)
    -break-info
    ^done,BreakpointTable={nr_rows="1",nr_cols="6",hdr=[{width="7",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="18",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",script={"aaa","bbb","ccc"},original-location="main"}]}
    (gdb)

In both the =breakpoint-modified and -break-info output, we have:

     script={"aaa","bbb","ccc"}

According to the output syntax [1], curly braces means tuple, and a
tuple contains key=value pairs.  This looks like it should be a list,
but uses curly braces by mistake.  This would make more sense:

    script=["aaa","bbb","ccc"]

Fix it, keeping the backwards compatibility by introducing a new MI
version (MI4), in exactly the same way as was done when fixing
multi-locations breakpoint output in [2].

 - Add a fix_breakpoint_script_output uiout flag.  MI uiouts will use
   this flag if the version is >= 4.
 - Add a fix_breakpoint_script_output_globally variable and the
   -fix-breakpoint-script-output MI command to set it, if frontends want
   to use the fixed output for this without using the newer MI version.
 - When emitting the script field, use list instead of tuple, if we want
   the fixed output (depending on the two criteria above)
 -

[1] https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Output-Syntax.html#GDB_002fMI-Output-Syntax
[2] https://gitlab.com/gnutools/binutils-gdb/-/commit/b4be1b0648608a2578bbed39841c8ee411773edd

Change-Id: I7113c6892832c8d6805badb06ce42496677e2242
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24285

objdump: fix extended (256) disassembler colors

After commit:

  commit a88c79b77036e4778e70d62081c3cfd1044bb8e3
  Date:   Tue Aug 9 14:57:48 2022 +0100

      Default to enabling colored disassembly if output is to a terminal.

The 256 extended-color support for --disassembler-color was broken.
This is fixed in this commit.

PR 29457
* objdump (objdump_styled_sprintf): Check disassembler_color
against an enum value, don't treat it as a bool.

gdb/riscv: implement cannot_store_register gdbarch method

The x0 (zero) register is read-only on RISC-V.  Implement the
cannot_store_register gdbarch method to tell GDB this.

Without this method GDB will try to write to x0, and relies on the
target to ignore such writes.  If you are using a target that
complains (or throws an error) when writing to x0, this change will
prevent this from happening.

The gdb.arch/riscv-reg-aliases.exp test exercises writing to x0, and
will show the errors when using a suitable target.

Disable year 2038 support on 32-bit hosts by default

With a recent import of gnulib, code has been pulled that tests and enables
64-bit time_t by default on 32-bit hosts that support it.

Although gdb can use the gnulib support, bfd doesn't use gnulib and currently
doesn't do these checks.

As a consequence, if we have a 32-bit host that supports 64-bit time_t, we'll
have a mismatch between gdb's notion of time_t and bfd's notion of time_t.

This will lead to mismatches in the struct stat size, leading to memory
corruption and crashes.

This patch disables the year 2038 check for now, which makes things work
reliably again.

I'd consider this a temporary fix until we have proper bfd checks for the year
2038, if it makes sense.  64-bit hosts seems to be more common these days, so
I'm not sure how important it is to have this support enabled and how soon
we want to enable it.

Thoughts?

gas/Dwarf: properly skip zero-size functions

PR gas/29451

While out_debug_abbrev() properly skips such functions, out_debug_info()
mistakenly didn't. It needs to calculate the high_pc expression ahead of
time, in order to skip emitting any data for the function if the value
is zero.

The one case which would still leave a zero-size entry is when
symbol_get_obj(symp)->size ends up evaluating to zero. I hope we can
expect that to not be the case, otherwise we'd need to have a way to
post-process .debug_info contents between resolving expressions and
actually writing the data out to the file. Even then it wouldn't be
entirely obvious in which way to alter the data.

PR29462, internal error in relocate, at powerpc.cc:10796

Prior to the inline plt call support (commit 08be322439), the only
local syms with plt entries were local ifunc symbols.  There shouldn't
be stubs for other local symbols so don't look for them.  The patch
also fixes minor bugs in get_reference_flags; Many relocs are valid
only for ppc64 and a couple only for ppc32.

PR 29462
* powerpc.cc (Target_powerpc::Relocate::relocate): Rename
use_plt_offset to pltcal_to_direct, invert logic.  For relocs
not used with inline plt sequences against local symbols, only
look for stubs when the symbol is an ifunc.
(Target_powerpc::Scan::get_reference_flags): Correct reloc
handling for relocs not valid for both 32-bit and 64-bit.

bfd: Add support for LoongArch64 EFI (efi-*-loongarch64).

This adds support for efi-loongarch64 by virtue of adding a new PEI target
pei-loongarch64.  This is not a full target and only exists to support EFI at
this time.

This means that this target does not support relocation processing and is mostly
a container format.  This format has been added to elf based loongarch64 targets
such that efi images can be made natively on Linux.

However this target is not valid for use with gas but only with objcopy.

We should't limit addresses to 32-bits for 64-bit vma, otherwise there will be
"RVA truncated" error when using objcopy on loongarch64.

With these changes the resulting file is recognized as an efi image.

Any magic number is based on the Microsoft PE specification [1].

The test results are as follows:
$ make check-binutils RUNTESTFLAGS='loongarch64.exp'
  PASS: Check if efi app format is recognized

$ objdump -h -f tmpdir/loongarch64copy.o
  tmpdir/loongarch64copy.o:     file format pei-loongarch64
  architecture: Loongarch64, flags 0x00000132:
  EXEC_P, HAS_SYMS, HAS_LOCALS, D_PAGED
  start address 0x0000000000000000

  Sections:
  Idx Name          Size      VMA               LMA               File off  Algn
    0 .text         0000003c  00000000200000b0  00000000200000b0  00000200  2**2
                    CONTENTS, ALLOC, LOAD, READONLY, CODE

[1] https://docs.microsoft.com/en-us/windows/win32/debug/pe-format

bfd:
  * .gitignore (pe-loongarch64igen.c): New.
  * Makefile.am (pei-loongarch64.lo, pe-loongarch64igen.lo, pei-loongarch64.c,
  pe-loongarch64igen.c): Add support.
  * Makefile.in: Likewise.
  * bfd.c (bfd_get_sign_extend_vma): Add pei-loongarch64.
  * coff-loongarch64.c: New file.
  * coffcode.h (coff_set_arch_mach_hook, coff_set_flags,
  coff_write_object_contents) Add loongarch64 (loongarch64_pei_vec) support.
  * config.bfd: Likewise.
  * configure: Likewise.
  * configure.ac: Likewise.
  * libpei.h (GET_OPTHDR_IMAGE_BASE, PUT_OPTHDR_IMAGE_BASE,
  GET_OPTHDR_SIZE_OF_STACK_RESERVE, PUT_OPTHDR_SIZE_OF_STACK_RESERVE,
  GET_OPTHDR_SIZE_OF_STACK_COMMIT, PUT_OPTHDR_SIZE_OF_STACK_COMMIT,
  GET_OPTHDR_SIZE_OF_HEAP_RESERVE, PUT_OPTHDR_SIZE_OF_HEAP_RESERVE,
  GET_OPTHDR_SIZE_OF_HEAP_COMMIT, PUT_OPTHDR_SIZE_OF_HEAP_COMMIT,
  GET_PDATA_ENTRY, _bfd_peLoongArch64_bfd_copy_private_bfd_data_common,
  _bfd_peLoongArch64_bfd_copy_private_section_data,
  _bfd_peLoongArch64_get_symbol_info, _bfd_peLoongArch64_only_swap_filehdr_out,
  _bfd_peLoongArch64_print_private_bfd_data_common,
  _bfd_peLoongArch64i_final_link_postscript,
  _bfd_peLoongArch64i_only_swap_filehdr_out, _bfd_peLoongArch64i_swap_aouthdr_in,
  _bfd_peLoongArch64i_swap_aouthdr_out, _bfd_peLoongArch64i_swap_aux_in,
  _bfd_peLoongArch64i_swap_aux_out, _bfd_peLoongArch64i_swap_lineno_in,
  _bfd_peLoongArch64i_swap_lineno_out, _bfd_peLoongArch64i_swap_scnhdr_out,
  _bfd_peLoongArch64i_swap_sym_in, _bfd_peLoongArch64i_swap_sym_out,
  _bfd_peLoongArch64i_swap_debugdir_in, _bfd_peLoongArch64i_swap_debugdir_out,
  _bfd_peLoongArch64i_write_codeview_record,
  _bfd_peLoongArch64i_slurp_codeview_record,
  _bfd_peLoongArch64_print_ce_compressed_pdata): New.
  * peXXigen.c (_bfd_XXi_swap_aouthdr_in, _bfd_XXi_swap_aouthdr_out,
  _bfd_XXi_swap_scnhdr_out, pe_print_pdata, _bfd_XX_print_private_bfd_data_common,
  _bfd_XX_bfd_copy_private_section_data, _bfd_XXi_final_link_postscript):
  Support COFF_WITH_peLoongArch64,
  * pei-loongarch64.c: New file.
  * peicode.h (coff_swap_scnhdr_in, pe_ILF_build_a_bfd, pe_ILF_object_p):
  Support COFF_WITH_peLoongArch64.
  (jtab): Add dummy entry that traps.
  * targets.c (loongarch64_pei_vec): New.

binutils
  * testsuite/binutils-all/loongarch64/loongarch64.exp: New file.
  * testsuite/binutils-all/loongarch64/pei-loongarch64.d: New test.
  * testsuite/binutils-all/loongarch64/pei-loongarch64.s: New test.

include
  * coff/loongarch64.h: New file.
  * coff/pe.h (IMAGE_FILE_MACHINE_LOONGARCH64): New.

Signed-off-by: Youling Tang <tangyouling@loongson.cn>

Automatic date update in version.in

gdb/riscv/testsuite: fix failures in gdb.arch/riscv-reg-aliases.exp

When running on a native RISC-V Linux target I currently see failures
in the gdb.arch/riscv-reg-aliases.exp test like this:

  set $ft0.float = 501
  (gdb) PASS: gdb.arch/riscv-reg-aliases.exp: write non-zero value to ft0
  p/d $ft0.float
  $263 = 1140490240
  (gdb) FAIL: gdb.arch/riscv-reg-aliases.exp: read ft0 after non-zero write to ft0

This test started failing after this commit:

  commit 56262a931b7ca8ee3ec9104bc7e9e0b40cf3d64e
  Date:   Thu Feb 17 13:43:59 2022 -0700

      Change how "print/x" displays floating-point value

The problem is that when 501 is written to $ft0.float the value is
converted to floating point format and stored in the register.  Prior
to the above commit printing with /x and /d would first extract the
value as a float, and then convert the value to an integer for
display.  After the above commit GDB now uses the raw register value
when displaying /x and /d, and so we see this behaviour:

  (gdb) info registers $ft0
  ft0            {float = 501, double = 5.6347704700123827e-315} (raw 0x0000000043fa8000)
  (gdb) p/f $ft0.float
  $1 = 501
  (gdb) p/d $ft0.float
  $2 = 1140490240
  (gdb) p/x $ft0.float
  $3 = 0x43fa8000

To fix this test I now print the float registers using the /f format
rather than /d.  With this change the test now passes.

Another gas manual typo correction.

Fix typos in assembler documentation.

gdb/gdbserver: LoongArch: Improve implementation of fcc registers

The current implementation of the fcc register is referenced to the
user_fp_state structure of the kernel uapi [1].

struct user_fp_state {
uint64_t    fpr[32];
uint64_t    fcc;
uint32_t    fcsr;
};

But it is mistakenly defined as a 64-bit fputype register, resulting
in a confusing output of "info register".

(gdb) info register
...
fcc            {f = 0x0, d = 0x0}  {f = 0, d = 0}
...

According to "Condition Flag Register" in "LoongArch Reference Manual"
[2], there are 8 condition flag registers of size 1. Use 8 registers of
uint8 to make it easier for users to view the fcc register groups.

(gdb) info register
...
fcc0           0x1                 1
fcc1           0x0                 0
fcc2           0x0                 0
fcc3           0x0                 0
fcc4           0x0                 0
fcc5           0x0                 0
fcc6           0x0                 0
fcc7           0x0                 0
...

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/uapi/asm/ptrace.h
[2] https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#_condition_flag_register

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

Default to enabling colored disassembly if output is to a terminal.

PR 29457
* objdump.c (disassembler_color): Change type to an enum.
(disassembler_extended_color): Remove.
(usage): Update.
(objdump_color_for_assembler_style): Update.
(main): Update initialisation of disassembler_color.  If not
initialised via a command line option, set based upon terminal
output.
* doc/binutils.texi: Update description of disassmbler-color
option.
* testsuite/binutils-all/arc/objdump.exp: Add
--disassembler-color=off option when disassembling.
* testsuite/binutils-all/arm/objdump.exp: Likewise.

Fix-for-multiple-thread-detection-in-AIX.

In AIX multiple threads were not added. This patch is a fix for the same

When we create a pthread debug session we have callbacks to read
symbols and memory.  One of those call backs is pdc_read_data.

Before we come into aix-thread wait() we switch to no thread and
therefore the current thread is null.

When we get into pdc_read_data we have a dependency that we need to
be in the correct current thread that has caused an event of new
thread, inorder to read memory.

Hence we switch to the correct thread.

This is done by passing the pid in the pthdb_user_t user_current_pid
parameter in every call back.

[gdb/testsuite] Fix gdb.dwarf2/debug-names.exp

When running test-case gdb.dwarf2/debug-names.exp on openSUSE Tumbleweed, I
run into:
...
(gdb) maint info symtabs^M
  ...
ERROR: internal buffer is full.
UNRESOLVED: gdb.dwarf2/debug-names.exp: break _start expanded symtab
...

Fix this by simplifying the test-case to print _start rather running to it.

Tested on x86_64-linux.

gdb/riscv: use register name enum values in riscv-linux-nat.c

There were a few places where we were using integer values rather than
the RISCV_*_REGNUM constants defined in riscv-tdep.h.  This commit
replaces 0 with RISCV_ZERO_REGNUM and 32 with RISCV_PC_REGNUM in a few
places.

There should be no user visible changes after this commit.

x86-64: adjust MOVQ to/from SReg attributes

It is unclear to me why the corresponding MOV (no Q suffix) can be
issued without REX.W, but MOVQ has to have that prefix (bit). Add
NoRex64 and in exchange drop Size64.

x86: adjust MOVSD attributes

The non-SSE2AVX form of the SIMD variant of the instruction needlessly
has the (still multi-purpose) IgnoreSize attribute. All other similar
SSE2 insns use NoRex64 instead. Make this consistent, noting that the
SSE2AVX form can't have the same change made - there the memory operand
doesn't at the same time permit RegXMM (which logic uses when deciding
whether a Q suffix is okay outside of 64-bit mode).

x86: fold AVX VGATHERDPD / VPGATHERDQ

While the other three variants each differ in attributes and hence can't
be folded, these two pairs actually can be (and were previously
overlooked). This effectively matches their AVX512VL counterparts, which
are also expressed as a single template.

x86: allow use of broadcast with X/Y/Z-suffixed AVX512-FP16 insns

While the x/y/z suffix isn't necessary to use in this case, it is still
odd that these forms don't support broadcast (unlike their AVX512F /
AVX512DQ counterparts). The lack thereof can e.g. make macro-ized
programming more difficult.

x86/Intel: split certain AVX512-FP16 VCVT*2PH templates

One more place where pre-existing templates should have been taken as a
basis: In Intel syntax we want to consistently issue an "ambiguous
operand size" error when a size-less memory operand is specified for an
insn where register use alone isn't sufficient for disambiguation.

gdb/csky fix build error in ubuntu20_04

build error in: https://builder.sourceware.org/buildbot/#/builders/170/builds/246
...
../../binutils-gdb/gdb/csky-linux-tdep.c: In function ‘void
csky_supply_fregset(const regset*, regcache*, int, const void*, size_t)’:
../../binutils-gdb/gdb/csky-linux-tdep.c:194:18: error: format ‘%ld’
expects argument of type ‘long int’, but argument 2 has type ‘size_t’
{aka ‘unsigned int’} [-Werror=format=]
   194 |       warning (_("Unknow size %ld of section .reg2, can not get
value"
       |
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   195 |    " of float registers."), len);
...

Fix it via using %s vs pulongest suggested by Tom.

Automatic date update in version.in

Fix regression from gdbarch registry change

The gdbarch registry patch introduced a regression that could cause a
crash when opening files in gdb.  The bug is that, previously, the
solib ops would default to current_target_so_ops; but the patch
changed this code to default to nullptr.  This patch fixes the bug by
reintroducing the earlier behavior.  This is PR gdb/29449.

I managed to reproduce the bug with a riscv-elf build and then
verified that this fixes the problem.

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

add splay tree for info_ptr -> CU mapping

While using perf top for MozillaThunderbird I noticed quite some slow
dissably call with source code involved. E.g.

time ./objdump --start-address=0x0000000004e0dcd0 --stop-address=0x0000000004e0df8b -l -d --no-show-raw-insn -S -C /usr/lib64/thunderbird/libxul.so

took 2.071s and I noticed quite some time is spent in
find_abstract_instance:

    33.46%  objdump  objdump               [.] find_abstract_instance
    18.22%  objdump  objdump               [.] arange_add
    13.77%  objdump  objdump               [.] read_attribute_value
     4.82%  objdump  objdump               [.] comp_unit_maybe_decode_line_info
     3.10%  objdump  libc.so.6             [.] __memset_avx2_unaligned_erms

where linked list of CU is iterated when searing for where info_ptr
belongs to:

         : 3452   for (u = unit->prev_unit; u != NULL; u = u->prev_unit)
    0.00 :   4c61f7: mov    0x10(%rbx),%rax
    0.00 :   4c61fb: test   %rax,%rax
    0.00 :   4c61fe: je     4c6215 <find_abstract_instance+0x365>
         : 3453   if (info_ptr >= u->info_ptr_unit && info_ptr < u->end_ptr)
    0.00 :   4c6200: cmp    0x60(%rax),%rdx
   83.20 :   4c6204: jb     4c620c <find_abstract_instance+0x35c>
    0.00 :   4c6206: cmp    0x78(%rax),%rdx
    6.89 :   4c620a: jb     4c6270 <find_abstract_instance+0x3c0>
         : 3452   for (u = unit->prev_unit; u != NULL; u = u->prev_unit)
    0.00 :   4c620c: mov    0x10(%rax),%rax
    7.90 :   4c6210: test   %rax,%rax
    0.00 :   4c6213: jne    4c6200 <find_abstract_instance+0x350>

The following scan can be replaced with search in a splay tree and with
that I can get to 1.5s and there are other symbols where the difference
is even bigger.

bfd/ChangeLog:

PR 29081
* dwarf2.c (struct addr_range): New.
(addr_range_intersects): Likewise.
(splay_tree_compare_addr_range): Likewise.
(splay_tree_free_addr_range): Likewise.
(struct dwarf2_debug_file): Add comp_unit_tree.
(find_abstract_instance): Use the splay tree when searching
for a info_ptr.
(stash_comp_unit): Insert to the splay tree.
(_bfd_dwarf2_cleanup_debug_info): Clean up the splay tree.

dwarf: use find_abstract_instance for vars and DW_AT_specification

The following simple test case fails when dwz is used:

$ cat demo.C
namespace std {
  enum { _S_fixed, _S_floatfield = _S_fixed };
  struct {
    struct {};
  }
  __ioinit;
}

int main() {
  return 0;
}

$ g++ demo.C -g && cp a.out b.out && dwz -m xxx.so a.out b.out && objdump -S a.out >/dev/null
objdump: DWARF error: could not find variable specification at offset 0x3d3

As seen the reference is defined in xxx.so shared part:

$ eu-readelf -w -N a.out | grep -A3 -B3 3d3
             decl_column          (data1) 11
             sibling              (ref_udata) [   387]
 [   387]    variable             abbrev: 30
             specification        (GNU_ref_alt) [   3d3]
             location             (exprloc)
              [ 0] addr 0x404019
 [   396]    subprogram           abbrev: 32

$ eu-readelf -w -N a.out | less

...

 Compilation unit at offset 920:
 Version: 5, Abbreviation section offset: 0, Address size: 8, Offset size: 4
 Unit type: partial (3)
...
 [   3d3]      variable             abbrev: 31
               name                 (strp) "__ioinit"
               decl_file            (data1) demo.C (10)
               decl_line            (data1) 6
               decl_column          (data1) 3
               type                 (ref_udata) [   3c4]
               declaration          (flag_present) yes

With the patch the same output is emitted as before usage of dwz.

bfd/ChangeLog:

PR 29442
* dwarf2.c (struct varinfo): Use const char * type.
(scan_unit_for_symbols): Call find_abstract_instance for
DW_AT_specification for variables that can be in a different CU
(e.g. done by dwz)

Mach-O: i18n enablement on some error messages.

* config/obj-macho.c (obj_mach_o_get_section_names): Wrap two
string literals within with gettext macro.

ld: fix NEWS typos

ld/ChangeLog:

* NEWS: Fix 2 typos.

Add a link to the NEWS files in the release announcement email.

gdb/csky support .reg2 for kernel 4.x and later

When kernel's version >= 4.x, the size of .reg2 section will be 400.
Contents of .reg2 are {
    unsigned long vr[96];
    unsigned long fcr;
    unsigned long fesr;
    unsigned long fid;
    unsigned long reserved;
};

VR[96] means: (vr0~vr15) + (fr16~fr31), each Vector register is
128-bits, each Float register is 64 bits, the total size is
(4*96).

In addition, for fr0~fr15, each FRx is the lower 64 bits of the
corresponding VRx. So fr0~fr15 and vr0~vr15 regisetrs use the same
offset.

Automatic date update in version.in

[gdb/build] Fix build with gcc 4.8.5

When building with gcc 4.8.5, I run into:
...
user-regs.c:85:1: error: could not convert \
  ‘{0l, (& builtin_user_regs.gdb_user_regs::first)}’ from \
  ‘<brace-enclosed initializer list>’ to ‘gdb_user_regs’
 };
 ^
...

Fix this by removing the initialization and handling regs.last == nullptr in
append_user_reg.

Tested on x86_64-linux.

[gdb/symtab] Fix assert in read_addrmap_from_aranges

When loading the debug-names-duplicate-cu executable included in this
test-case, we run into:
...
(gdb) file debug-names-duplicate-cu^M
Reading symbols from debug-names-duplicate-cu...^M
src/gdb/dwarf2/read.c:2353: internal-error: read_addrmap_from_aranges: \
  Assertion `insertpair.second' failed.^M
...

This assert was added in recent commit 75337cbc147 ("[gdb/symtab] Fix
.debug_aranges duplicate offset warning").

The assert triggers because the CU table in the .debug_names section contains
a duplicate:
...
Version 5
Augmentation string: 47 44 42 00  ("GDB")
CU table:
[  0] 0x0
[  1] 0x0
...

Fix this by rejecting the .debug_names index:
...
(gdb) file debug-names-duplicate-cu^M
Reading symbols from debug-names-duplicate-cu...^M
warning: Section .debug_names has duplicate entry in CU table, \
  ignoring .debug_names.^M
...

Likewise for the case where the CU table is not sorted by increasing offset.

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

[gdb/testsuite] Add support for .debug_names in dwarf assembler

Add:
- support for a per-module .debug_names section in the dwarf assembler, and
- a test-case excercising this new functionality.

A per-module .debug_names section needs to have an entry in the CU list for
each CU in the module, which is made more difficult by two things:
- linking in other objects, which may contain additional CUs
  (typically the case on openSUSE), and
- adding dummy CUs in the dwarf assembler.
We handle this by:
- compiling with -nostartfiles (so the test-case contains _start rather than
  main), and
- disabling the dummy CU generation for the test-case.

I've kept things simple by having the test-case specify the hash value, rather
than adding that functionality in the dwarf assembler.

Also I've kept the bucket count to 1, which makes it trivial to satisfy the
requirement that "the symbol is entered into a bucket whose index is the hash
value modulo bucket_count".

The readelf dump of the .debug_names section from the test-case looks like:
...
Version 5
Augmentation string: 47 44 42 00  ("GDB")
CU table:
[  0] 0x0

TU table:

Foreign TU table:

Used 1 of 1 bucket.
Out of 2 items there are 1 bucket clashes (longest of 1 entries).

Symbol table:
[  0] #eddb6232 _start: <1> DW_TAG_subprogram DW_IDX_compile_unit=0
[  1] #0b888030 int: <2> DW_TAG_base_type DW_IDX_compile_unit=0
...

Tested on x86_64-linux.

Automatic date update in version.in

asan: heap buffer overflow in _bfd_error_handler

On coff_slurp_symbol_table printing "unrecognized storage class"
for a symbol error.  If the symbol name is the last string in its
section and not terminated, we run off the end of the buffer.

* coffgen.c (build_debug_section): Terminate the section with
an extra 0.

asan: segfault in coff_write_auxent_fname

More fuzzed input file nonsense.

* coffgen.c (coff_write_symbol): Don't call coff_write_auxent_fname
when extrap is NULL.

msan: bfd_mach_o_layout_commands use of uninitialised value

Catches fuzzed input with unterminated strings that later run off the
end of their buffers when calling strlen.

* mach-o.c: Use size_t vars where approprite.
(bfd_mach_o_alloc_and_read): Add "extra" param.  Allocate that
much extra and clear.  Update all callers, those that set up
strings with one extra byte.

objcopy section alignment

bfd_set_section_alignment currently always returns true.  This patch
changes it to return false on silly alignment values, avoiding yet
another way to trigger ubsan errors like coffcode.h:3192:12: runtime
error: shift exponent 299 is too large for 32-bit type 'int'.  We'll
catch that one in objcopy.c:setup_sections.  However, setup_sections
gives up on other setup operations that are necessary even after an
error of some sort.  Change that to keep going, which might change the
error message but that shouldn't matter in the least.

bfd/
* section.c (bfd_set_section_alignment): Return false and
don't set alignment_power for stupidly large alignments.
* bfd-in2.h: Regenerate.
* coffcode.h (coff_compute_section_file_positions): Don't use
an int constant when calculating alignment.
binutils/
* objcopy.c (setup_section): Keep on going after hitting
non-fatal errors.

ubsan: som.c undefined shift in som_set_reloc_info

Do the shift using unsigned variables to avoid UB on << 8.

* som.c (som_set_reloc_info): Make v unsigned.  Localise some
variables to their blocks.

Automatic date update in version.in

Get rid of BFD_VMA_FMT

Remove the BFD_VMA_FMT defines in bfd.h and configure support.

* bfd-in.h (BFD_VMA_FMT): Don't define.
* configure.ac (BFD_INT64_FMT): Remove configure test.
* configure.com: Likewise.
* Makefile.in: Regenerate.
* bfd-in2.h: Regenerate.
* configure: Regenerate.

Don't use BFD_VMA_FMT in gdb and sim

Like commit b82817674f, this replaces BFD_VMA_FMT "x" in sim/ with
PRIx64 and casts to promote bfd_vma to uint64_t.  The one file using
BFD_VMA_FMT in gdb/ instead now uses hex_string, and a typo in the
warning message is fixed.

[gdb/build] Fix build breaker in language.c with gcc 7.5.0

When building gdb on openSUSE Leap 15.3, using gcc 7.5.0, I run into:
...
gdb/language.c: In constructor ‘constexpr language_gdbarch::language_gdbarch()’:
gdb/language.c:921:8: error: use of deleted function \
  ‘language_arch_info::language_arch_info(const language_arch_info&)’
 struct language_gdbarch
        ^~~~~~~~~~~~~~~~
In file included from gdbsupport/common-defs.h:104:0,
                 from gdb/defs.h:28,
                 from gdb/language.c:31:
gdb/language.h:95:28: note: declared here
   DISABLE_COPY_AND_ASSIGN (language_arch_info);
                            ^
include/ansidecl.h:342:3: note: in definition of macro \
  ‘DISABLE_COPY_AND_ASSIGN’
   TYPE (const TYPE&) = delete;   \
   ^~~~
gdb/language.c: In function ‘language_gdbarch* get_language_gdbarch(gdbarch*)’:
gdb/language.c:936:22: note: synthesized method ‘constexpr \
  language_gdbarch::language_gdbarch()’ first required here
       l = new struct language_gdbarch;
                      ^~~~~~~~~~~~~~~~
...

This seems to be fixed by this change in the struct language_gdbarch
definition:
...
-  struct language_arch_info arch_info[nr_languages] {};
+  struct language_arch_info arch_info[nr_languages];
...

Tested on x86_64-linux.

[gdb] Add unit test for gdb::sequential_for_each

With commit 18a5766d09c ("[gdbsupport] Add sequential_for_each") I added a
drop-in replacement for gdb::parallel_for_each, but there's nothing making
sure that the two remain in sync.

Extend the unit test for gdb::parallel_for_each to test both.

Do this using a slightly unusual file-self-inclusion.  Doing so keep things
readable and maintainable, and avoids macrofying functions.

Tested on x86_64-linux.

[gdb/symtab] Use task size in parallel_for_each in dwarf2_build_psymtabs_hard

In dwarf2_build_psymtabs_hard, we use a parallel_for_each to distribute CUs
over threads.

Ensuring a fair distribution over the worker threads and main thread in terms
of number of CUs might not be the most efficient way, given that CUs can vary
in size.

Fix this by using per_cu->get_length () as the task size.

I've used this experiment to verify the performance impact:
...
$ for n in $(seq 1 10); do \
    time gdb -q -batch ~/firefox/libxul.so-93.0-1.1.x86_64.debug \
    2>&1 \
    | grep "real:"; \
  done
...
and without the patch got:
...
real: 4.71
real: 4.88
real: 4.29
real: 4.30
real: 4.65
real: 4.27
real: 4.27
real: 4.27
real: 4.75
real: 4.41
...
and with the patch:
...
real: 3.68
real: 3.81
real: 3.80
real: 3.68
real: 3.75
real: 3.69
real: 3.69
real: 3.74
real: 3.67
real: 3.74
...
so that seems a reasonable improvement.

With parallel_for_each_debug set to true, we get some more detail about
the difference in behaviour.  Without the patch we have:
...
Parallel for: n_elements: 2818
Parallel for: minimum elements per thread: 1
Parallel for: elts_per_thread: 704
Parallel for: elements on worker thread 0       : 705
Parallel for: elements on worker thread 1       : 705
Parallel for: elements on worker thread 2       : 704
Parallel for: elements on worker thread 3       : 0
Parallel for: elements on main thread           : 704
...
and with the patch:
...
Parallel for: n_elements: 2818
Parallel for: total_size: 1483674865
Parallel for: size_per_thread: 370918716
Parallel for: elements on worker thread 0       : 752   (size: 371811790)
Parallel for: elements on worker thread 1       : 360   (size: 371509370)
Parallel for: elements on worker thread 2       : 1130  (size: 372681710)
Parallel for: elements on worker thread 3       : 0     (size: 0)
Parallel for: elements on main thread           : 576   (size: 367671995)
...

Tested on x86_64-linux.

[gdbsupport] Add task size parameter in parallel_for_each

Add a task_size parameter to parallel_for_each, defaulting to nullptr, and use
the task size to distribute similarly-sized chunks to the threads.

Tested on x86_64-linux.

Introduce gdb::make_function_view

This adds gdb::make_function_view, which lets you create a function
view from a callable without specifying the function_view's template
parameter.  For example, this:

    auto lambda = [&] (int) { ... };
    auto fv = gdb::make_function_view (lambda);

instead of:

    auto lambda = [&] (int) { ... };
    gdb::function_view<void (int)> fv = lambda;

It is particularly useful if you have a template function with an
optional function_view parameter, whose type depends on the function's
template parameters.  Like:

    template<typename T>
    void my_function (T v, gdb::function_view<void(T)> callback = nullptr);

For such a function, the type of the callback argument you pass must
already be a function_view.  I.e., this wouldn't compile:

    auto lambda = [&] (int) { ... };
    my_function (1, lambda);

With gdb::make_function_view, you can write the call like so:

    auto lambda = [&] (int) { ... };
    my_function (1, gdb::make_function_view (lambda));

Unit tests included.

Tested by building with GCC 9.4, Clang 10, and GCC 4.8.5, on x86_64
GNU/Linux, and running the unit tests.

Change-Id: I5c4b3b4455ed6f0d8878cf1be189bea3ee63f626

Update following 2.39 release

asan: ppc64_elf_get_synthetic_symtab heap buffer overflow

Fuzzed input files with sizes of .dynamic not a multiple of dynamic
tag size can result in reading past the end of the buffer with the
current simple checks.  Fix that, and use the same check in other
files that process input object .dynamic section.  (There is no need
for buffer overflow checks in the linker's generated .dynamic
section.)

* elf32-ppc.c (ppc_elf_get_synthetic_symtab): Sanity check
.dynamic content buffer reads.
* elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise.
* elf64-ia64-vms.c (elf64_vms_link_add_object_symbols): Likewise.
* elf.c (_bfd_elf_print_private_bfd_data): Simplify .dynamic
buffer sanity checks.
* elflink.c (elf_link_add_object_symbols): Avoid possible UB
subtracting sizeof_dyn from pointer.