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.

Sanity check loc_offsets index

Fixes a segfault found by the fuzzers.

* dwarf.c (fetch_indexed_value): Return -1 on error.
(read_and_display_attr_value): Don't display string when
fetch_indexed_value returns an error.  Sanity check loc_offsets
index.

binutils/Dwarf: avoid "shadowing" of glibc function name

As before: Old enough glibc has an (unguarded) declaration of index()
in string.h, which triggers a "shadows a global declaration" warning.

gas: fix a testcase broken by new ZSTD support

The commit 1369522f36eece1b37139a81f7f2139ba3915172 ("Recognize the new ELF
compression type for ZSTD.") added the new ELF compression type but it
accidentally broke a GAS testcase.  Since testing for the section type
"2048" (SHF_COMPRESSED) is not going to be portable in the long term, it
now tests SHF_LINK_ORDER ("128") instead.

Using SHF_LINK_ORDER (with possibly sh_link == 0) is an idea by Jan Beulich.

gas/ChangeLog:

* testsuite/gas/elf/section10.s: Use SHF_LINK_ORDER to test
mixed numeric and alpha values.
* testsuite/gas/elf/section10.d: Reflect the change above.

When gas/read.c calls mbstowcs with a NULL destination, it should set size to 0

PR 29447
* read.c (read_symbol_name): Pass 0 as the length parameter when
invoking mbstowc in order to check the validity of a wide string.

[gdb] Add debug_{exp,val}

When debugging cc1 I heavily rely on simple one-parameter debug functions
that allow me to inspect a variable of a common type, like:
- debug_generic_expr
- debug_gimple_stmt
- debug_rtx
and I miss similar functions in gdb.

Add functions to dump variables of types 'value' and 'expression':
- debug_exp, and
- debug_val.

Tested on x86_64-linux, by breaking on varobj_create, and doing:
...
(gdb) call debug_exp (var->root->exp.get ())
&"Operation: OP_VAR_VALUE\n"
&" Block symbol:\n"
&"  Symbol: aaa\n"
&"  Block: 0x2d064f0\n"
(gdb)
...
and:
...
(gdb) call debug_val (value)
&"5"
(gdb)
...

Add gold support for --package-metadata option.

Following the same format as the implementation in ld:
9e2bb0cb5e74aed4158f08495534922d7108f928

Generate a .note.package FDO package metadata ELF note, following
the spec: https://systemd.io/ELF_PACKAGE_METADATA/

If the jansson library is available at build time (and it is explicitly
enabled), link ld to it, and use it to validate that the input is
correct JSON, to avoid writing garbage to the file. The
configure option --enable-jansson has to be used to explicitly enable
it (error out when not found). This allows bootstrappers (or others who
are not interested) to seamlessly skip it without issues.

elfcpp/
* elfcpp.h: Add FDO_PACKAGING_METADATA note type.

gold/
* Makefile.am: Add jansson flags and libraries.
* configure.ac: Check for jansson library.
* layout.cc (Layout::create_notes): Call create_package_metadata().
(Layout::create_package_metadata): New function.
* layout.h (Layout::create_package_metadata): New function.
(Layout::package_metadata_note_): New data member.
* options.h (class General_options): Add --package-metadata option.
* testsuite/Makefile.am (object_unittest): Add jansson libraries.
(binary_unittest): Likewise.
(leb128_unittest): Likewise.
(overflow_unittest): Likewise.
(package_metadata_test): New test.
* testsuite/package_metadata_main.c: New test source.

Recognize the new ELF compression type for ZSTD.

There is more work to be done to actually support compression and
decompression using the zstd library, but I will leave that to the
champions of the new compression option.

binutils/
* binutils/readelf.c (process_section_headers): Add support for
ELFCOMPRESS_ZSTD.

Automatic date update in version.in

Use registry in gdbarch

gdbarch implements its own registry-like approach.  This patch changes
it to instead use registry.h.  It's a rather large patch but largely
uninteresting -- it's mostly a straightforward conversion from the old
approach to the new one.

The main benefit of this change is that it introduces type safety to
the gdbarch registry.  It also removes a bunch of code.

One possible drawback is that, previously, the gdbarch registry
differentiated between pre- and post-initialization setup.  This
doesn't seem very important to me, though.

Allow registry to refer to const types

So far, the registry hasn't been used to refer to a 'const' type, but
this changes with the gdbarch change.  This patch arranges to let the
registry store a pointer-to-const, by removing const in the 'set'
method.

Use new and delete for gdbarch

This changes gdbarch to use new and delete.

Use bool in gdbarch

This changes gdbarch to use bool for initialized_p.

[gdb/testsuite] Fix .debug_aranges in gdb.dwarf2/fission-loclists.S

When running test-case gdb.dwarf2/fission-loclists.exp, I noticed:
...
warning: Section .debug_aranges in fission-loclists has duplicate \
  debug_info_offset 0x8f, ignoring .debug_aranges.^M
...

Fix this by removing the duplicate .debug_aranges entry.

Tested on x86_64-linux.

[gdb/testsuite] Fix ERROR in gdb.base/watchpoint-unaligned.exp

In PR23888 an error is reported:
...
ERROR: tcl error sourcing watchpoint-unaligned.exp.
ERROR: expected boolean value but got ""
    while executing
"if {$wpnum} {
...

This presumably happens when:
- skip_hw_watchpoint_tests returns 0 meaning hw watchpoints are supported
- gdb fails to set a hw watchpoint and instead sets a sw watchpoint

That particular situation is handled for arm:
...
    -re "Watchpoint (\[0-9\]+): .*\r\n$gdb_prompt $" {
        if {[istarget "arm*-*-*"]} {
            untested $test
            set wpnum 0
        }
    }
...
but not for any other targets so wpnum remains "", triggering the ERROR.

Possibly this has been fixed for powerpc by commit 8d4e4d13afb ("gdb Power 9
add test for HW watchpoint support."), but it's still possible for other
targets.

Fix this by:
- initializing wpnum to 0 instead of ""
- signalling the failure to set a hw watchpoint by a fail

Tested on x86_64-linux, also by adding:
...
gdb_test_no_output "set can-use-hw-watchpoints 0"
...
and verifying that it triggers the fail.

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

[gdb/tdep] Fix gdb.base/large-frame.exp for aarch64

On aarch64, I run into:
...
FAIL: gdb.base/large-frame.exp: optimize=-O0: backtrace
...

The problem is that the architecture-specific prologue analyzer fails to
handle the first two insns in the prologue properly:
...
0000000000400610 <func>:
  400610:       d2880210        mov     x16, #0x4010
  400614:       cb3063ff        sub     sp, sp, x16
  400618:       a9007bfd        stp     x29, x30, [sp]
  40061c:       910003fd        mov     x29, sp
  400620:       910043a0        add     x0, x29, #0x10
  400624:       97fffff0        bl      4005e4 <blah>
...
so we get:
...
$ gdb -q -batch ./outputs/gdb.base/large-frame/large-frame-O0 -ex "b func"
Breakpoint 1 at 0x400614
...

Fix this by:
- fixing the support for the first insn to extract the immediate operand, and
- adding support for the second insn,
such that we have:
...
Breakpoint 1 at 0x400624
...
Note that we're overshooting by one insn (0x400620 is the first insn after the
prologue), but that's a pre-existing problem.

Tested on aarch64-linux.

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

Don't use BFD_VMA_FMT in binutils

BFD_VMA_FMT can't be used in format strings that need to be
translated, because the translation won't work when the type of
bfd_vma differs from the machine used to compile .pot files.  We've
known about this for a long time, but patches slip through review.

So just get rid of BFD_VMA_FMT, instead using the appropriate PRId64,
PRIu64, PRIx64 or PRIo64 and SCN variants for scanf.  The patch is
mostly mechanical, the only thing requiring any thought is casts
needed to preserve PRId64 output from bfd_vma values, or to preserve
one of the unsigned output formats from bfd_signed_vma values.

Re: Get rid of fprintf_vma and sprintf_vma

Commit f493c2174e messed the formatting in linker map files,
particularly for 32-bit builds where a number of tests using map files
regressed.  I should have noticed the BFD64 conditional printing of
spaces to line up output due to the original %V printing hex vmas with
16 digits when BFD64 and 8 digits when not.  Besides that, it is nicer
to print 32-bit vmas for 32-bit targets.  So change %V back to be
target dependent, now using bfd_sprintf_vma.  Since minfo doesn't
return the number of chars printed, that means some places that
currently use %V must instead sprintf to a buffer in order to find the
length printed.

* ldmisc.h (print_spaces): Declare.
(print_space): Change to a macro.
* ldmisc.c (vfinfo): Use bfd_sprintf_vma for %V.  Tidy %W case.
(print_space): Delete.
(print_spaces): New function.
* emultempl/aix.em (print_symbol): Use print_spaces.
* ldctor.c (ldctor_build_sets): Likewise.
* ldmain.c (add_archive_element): Likewise.
* ldlang.c (print_one_symbol, lang_print_asneeded): Likewise.
(print_output_section_statement, print_data_statement): Likewise.
(print_reloc_statement, print_padding_statement): Likewise.
(print_assignment): Likewise.  Also replace %V printing of vmas
with printing to a buffer in order to properly format output.
(print_input_section, lang_one_common): Likewise.

MIPS: Use R_MIPS_REL16 for BFD_RELOC_16

R_MIPS_REL16 isn't a pc-relative reloc as the name might indicate.

* elf64-mips.c (mips_reloc_map): Map BFD_RELOC_16 to R_MIPS_REL16.
* elfn32-mips.c (mips_reloc_map): Likewise.

Automatic date update in version.in

elf: Reset alignment for each PT_LOAD segment

Reset alignment for each PT_LOAD segment to avoid using alignment from
the previous PT_LOAD segment.

bfd/

PR ld/29435
* elf.c (assign_file_positions_for_load_sections): Reset
alignment for each PT_LOAD segment.

ld/

PR ld/29435
* testsuite/ld-elf/pr29435.d: New file.
* testsuite/ld-elf/pr29435.s: Likewise.

Use unique_ptr to destroy per-bfd object

In some cases, the objfile owns the per-bfd object.  This is yet
another object that can sometimes be destroyed before the registry is
destroyed, possibly reslting in a use-after-free.  Also, I noticed
that the condition for deleting the object is not the same as the
condition used to create it -- so it could possibly result in a memory
leak in some situations.  This patch fixes the problem by introducing
a new unique_ptr that holds this object when necessary.

Use auto_obstack in objfile

This changes objfile to use an auto_obstack.  This helps prevent
use-after-free bugs, because it ensures that anything allocated on the
objfile obstack will live past the point at which the registry object
is destroyed.

Use gdb_bfd_ref_ptr in objfile

This changes struct objfile to use a gdb_bfd_ref_ptr.  In addition to
removing some manual memory management, this fixes a use-after-free
that was introduced by the registry rewrite series.  The issue there
was that, in some cases, registry shutdown could refer to memory that
had already been freed.  This help fix the bug by delaying the
destruction of the BFD reference (and thus the per-bfd object) until
after the registry has been shut down.

gprofng: fix bug 29410 - Argument "&nbsp;0." isn't numeric in numeric gt (>)

gprofng/Changelog:
2022-08-02  Ruud van der Pas  <ruud.vanderpas@oracle.com>

PR gprofng/29410
* gp-display-html/gp-display-html.in: Remove non-breaking spaces.

Fix a conflict between the linker's need to rename some PE format input libraries and the BFD library's file caching mechanism.

PR 29389
bfd * bfd.c (BFD_CLOSED_BY_CACHE): New bfd flag.
* cache.c (bfd_cache_delete): Set BFD_CLOSED_BY_DELETE on the
closed bfd.
(bfd_cache_lookup_worker): Clear BFD_CLOSED_BY_DELETE on the newly
reopened bfd.
* opncls.c (bfd_set_filename): Refuse to change the name of a bfd
that has been closed by bfd_cache_delete.  Mark changed bfds as
uncacheable.
* bfd-in2.h: Regenerate.

ld * ldlang.h (lang_input_statement_struct): Add sort_key field.
* emultempl/pe.em (after_open): If multiple import libraries refer
to the same bfd, store their names in the sort_key field.
* emultempl/pep.em (after_open): Likewise.
* ldlang.c (sort_filename): New function.  Returns the filename to
be used when sorting input files.
(wild_sort): Use the sort_filename function.

gdb/amd64: clean up unused variable

When building with clang 15, I got this,

  CXX    amd64-tdep.o
amd64-tdep.c:1410:13: error: variable 'insn' set but not used[-Werror,-Wunused-but-set-variable]
    gdb_byte *insn = insn_details->raw_insn + modrm_offset;
                ^
1 error generated.

The function that uses this variable has been removed in this commit,

commit 870f88f7551b0f2d6aaaa36fb684b5ff8f468107
Date:   Mon Apr 18 13:16:27 2016 -0400

    remove trivialy unused variables

Fix this by removing unused variable.

Tested by rebuilding on x86_64-linux with clang 15 and gcc 12.

gdb: Fix regression in varobj recreation

Commit bc20e562ec0 "Fix use after free in varobj" introduced a
regression.  This commit makes sure that the varobj object does not
keeps stale references to object being freed when we unload an objfile.
This includes the "valid_block" field which is reset to nullptr if the
pointed to block is tied to an objfile being freed.

However, at some point varobj_invalidate_iter might try to recreate
varobjs tracking either floating or globals.  Varobj tracking globals
are identified as having the "valid_block" field set nullptr, but as
bc20e562ec0 might clear this field, we have lost the ability to
distinguish between varobj referring to globals and non globals.

Fix this by introducing a "global" flag which tracks if a given varobj
was initially created as tracking a global.

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

Re: PE objdump -x

All of these buffer overrun tests are better written as a comparison
against size remaining, due to ISO C 9899 standard 6.5.2 para 8
regarding adding a constant to a pointer:

"If both the pointer operand and the result point to elements of the
same array object, or one past the last element of the array object,
the evaluation shall not produce an overflow; otherwise, the behavior
is undefined."

So "ex_dta + 4" might be undefined behaviour, if you interpret "the
array object" in this case to be the malloc'd section contents!

* pei-x86_64.c (pex64_get_unwind_info): Tidy sanity checks.
(pex64_xdata_print_uwd_codes): Likewise.