loongarch64_pei_vec garbage in objcopy'd relocs

Like commit a9c09a3667cc, but for loongarch64.

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

Automatic date update in version.in

gprofng: fix bug 29479 Collection fails when built without java support

gprofng/ChangeLog
2022-08-17  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29479
* libcollector/collector.c: Add #if defined(GPROFNG_JAVA_PROFILING) for
java specific code.
* libcollector/unwind.c: Likewise.

gdb: call check_typedef at beginning of dwarf_expr_context::fetch_result

Bug 29374 shows this crash:

    $ ./gdb -nx --data-directory=data-directory -q -batch -ex "catch throw" -ex r -ex bt a.out
    ...
    /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed.

The backtrace is:

    #0  internal_error (file=0x5555606504c0 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h", line=217, fmt=0x55556064b700 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:51
    #1  0x000055555d41c0bb in gdb::copy<unsigned char const, unsigned char> (src=..., dest=...) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217
    #2  0x000055555deef28c in dwarf_expr_context::fetch_result (this=0x7fffffffb830, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1040
    #3  0x000055555def0015 in dwarf_expr_context::evaluate (this=0x7fffffffb830, addr=0x62f00004313e "0", len=1, as_lval=false, per_cu=0x60b000069550, frame=0x621007c9e910, addr_info=0x0, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1091
    #4  0x000055555e084327 in dwarf2_evaluate_loc_desc_full (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, subobj_type=0x621007a86830, subobj_byte_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1485
    #5  0x000055555e0849e2 in dwarf2_evaluate_loc_desc (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1529
    #6  0x000055555e0828c6 in dwarf_entry_parameter_to_value (parameter=0x621007a96e58, deref_size=0x0, type=0x621007a86830, caller_frame=0x621007c9e910, per_cu=0x60b000069550, per_objfile=0x613000006080) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1235
    #7  0x000055555e082f55 in value_of_dwarf_reg_entry (type=0x621007a86890, frame=0x621007acc510, kind=CALL_SITE_PARAMETER_DWARF_REG, kind_u=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1332
    #8  0x000055555e083449 in value_of_dwarf_block_entry (type=0x621007a86890, frame=0x621007acc510, block=0x61e000033568 "T\004\205\001\240\004\004\243\001T\237\004\240\004\261\004\001T\004\261\004\304\005\004\243\001T\237\004\304\005\310\005\001T\004\310\005\311\005\004\243\001T\237", block_len=1) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1365
    #9  0x000055555e094d40 in loclist_read_variable_at_entry (symbol=0x621007a99bd0, frame=0x621007acc510) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:3889
    #10 0x000055555f5192e0 in read_frame_arg (fp_opts=..., sym=0x621007a99bd0, frame=0x621007acc510, argp=0x7fffffffbf20, entryargp=0x7fffffffbf60) at /home/simark/src/binutils-gdb/gdb/stack.c:559
    #11 0x000055555f51c352 in print_frame_args (fp_opts=..., func=0x621007a99ad0, frame=0x621007acc510, num=-1, stream=0x6030000bad90) at /home/simark/src/binutils-gdb/gdb/stack.c:887
    #12 0x000055555f521919 in print_frame (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1390
    #13 0x000055555f51f22e in print_frame_info (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, set_current_sal=0) at /home/simark/src/binutils-gdb/gdb/stack.c:1116
    #14 0x000055555f526c6d in backtrace_command_1 (fp_opts=..., bt_opts=..., count_exp=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2079
    #15 0x000055555f527ae5 in backtrace_command (arg=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2198

The problem is that the type that gets passed down to
dwarf_expr_context::fetch_result (the type of a variable of which we're
trying to read the entry value) is a typedef whose size has never been
computed yet (check_typedef has never been called on it).  As we get in
the DWARF_VALUE_STACK case (line 1028 of dwarf2/expr.c), the `len`
variable is therefore set to 0, instead of the actual type length.  We
then call allocate_value on subobj_type, which does call check_typedef,
so the length of the typedef gets filled in at that point.  We end up
passing to the copy function a source array view of length 0 and a
target array view of length 4, and the assertion fails.

Fix this by calling check_typedef on both type and subobj_type at the
beginning of fetch_result.

I tried writing a test for this using the DWARF assembler, but I haven't
succeeded.  It's possible that we need to get into this specific code
path (value_of_dwarf_reg_entry and all) to manage to get to
dwarf_expr_context::fetch_result with a typedef type that has never been
resolved.  In all my attempts, the typedef would always be resolved
already, so the bug wouldn't show up.

As a fallback, I made a gdb.dwarf2 test with compiler-generated .S
files.  I don't particularly like those, but I think it's better than no
test.  The .cpp source code is the smallest reproducer I am able to make
from the reproducer given in the bug (thanks to Pedro for suggestions on
how to minimize it further than I had).  Since I tested on both amd64
and aarch64, I added versions of the test for these two architectures.

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

[aarch64] Remove handling of ADR/ADRP from prologue analyzer

As reported by Tom in https://sourceware.org/pipermail/gdb-patches/2022-August/191357.html,
the aarch64 prologue analyzer considers the adrp instruction in the
gdb.dwarf2/dw2-dir-file-name.exp testcase to be part of a prologue.

The function has no prologue though, and it only loads the volatile variable
from memory.  GDB should not skip any instructions in this case.

Doing some archaeology, it seems handling for adr/adrp in prologues was
included with the original aarch64 port.  It might've been an oversight.

In the particular case of gdb.dwarf2/dw2-dir-file-name.exp, the analyzer skips
a couple instructions and leaves us in a nice spot where the address to the
variable "v" is already in w0. But no prologues exists.

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

Change bookmark allocation

This changes how bookmarks are allocated and stored, replacing a
linked list with a vector and removing some ALL_* iterator macros.
Regression tested on x86-64 Fedora 34.

Add test for AArch64 Scalable Vector Extension

It exercises a bug that GDB previously had where it would lose track of
some registers when the inferior changed its vector length.

It also checks that the vg register and the size of the z0-z31 registers
correctly reflect the new vector length.

Fix thread's gdbarch when SVE vector length changes

When the inferior program changes the SVE length, GDB can stop tracking
some registers as it obtains the new gdbarch that corresponds to the
updated length:

  Breakpoint 1, do_sve_ioctl_test () at sve-ioctls.c:44
  44              res = prctl(PR_SVE_SET_VL, i, 0, 0, 0, 0);
  (gdb) print i
  $2 = 32
  (gdb) info registers
          ⋮
  [ snip registers x0 to x30 ]
          ⋮
  sp             0xffffffffeff0      0xffffffffeff0
  pc             0xaaaaaaaaa8ac      0xaaaaaaaaa8ac <do_sve_ioctl_test+112>
  cpsr           0x60000000          [ EL=0 BTYPE=0 C Z ]
  fpsr           0x0                 0
  fpcr           0x0                 0
  vg             0x8                 8
  tpidr          0xfffff7fcb320      0xfffff7fcb320
  (gdb) next
  45              if (res < 0) {
  (gdb) info registers
          ⋮
  [ snip registers x0 to x30 ]
          ⋮
  sp             0xffffffffeff0      0xffffffffeff0
  pc             0xaaaaaaaaa8cc      0xaaaaaaaaa8cc <do_sve_ioctl_test+144>
  cpsr           0x200000            [ EL=0 BTYPE=0 SS ]
  fpsr           0x0                 0
  fpcr           0x0                 0
  vg             0x4                 4
  (gdb)

Notice that register tpidr disappeared when vg (which holds the vector
length) changed from 8 to 4.  The tpidr register is provided by the
org.gnu.gdb.aarch64.tls feature.

This happens because the code that searches for a new gdbarch to match the
new vector length in aarch64_linux_nat_target::thread_architecture doesn't
take into account the features present in the target description associated
with the previous gdbarch.  This patch makes it do that.

Since the id member of struct gdbarch_info is now unused, it's removed.

Missing linking test case for pe dll using a def file.

PR 28362
* testsuite/ld-pe/pe-run2-def.exp: New file.

gdbsupport/event-loop: add a timeout parameter to gdb_do_one_event

Since commit b2d8657, having a per-interpreter event/command loop is not
possible anymore.

As Insight uses a GUI that has its own event loop, gdb and GUI event
loops have then to be "merged" (i.e.: work together). But this is
problematic as gdb_do_one_event is not aware of this alternate event
loop and thus may wait forever.

A solution is to delegate GUI events handling to the gdb events handler.
Insight uses Tck/Tk as GUI and the latter offers a "notifier" feature to
implement such a delegation. The Tcl notifier spec requires the event wait
function to support a timeout parameter. Unfortunately gdb_do_one_event
does not feature such a parameter.
This timeout cannot be implemented externally with a gdb timer, because
it would become an event by itself and thus can cause a legitimate event to
be missed if the timeout is 0.
Tcl implements "idle events" that are (internally) triggered only when no
other event is pending. For this reason, it can call the event wait function
with a 0 timeout quite often.

This patch implements a wait timeout to gdb_do_one_event. The initial
pending events monitoring is performed as before without the possibility
to enter a wait state. If no pending event has been found during this
phase, a timer is then created for the given timeout in order to re-use
the implemented timeout logic and the event wait is then performed.
This "internal" timer only limits the wait time and should never be triggered.
It is deleted upon gdb_do_one_event exit.

The new parameter defaults to "no timeout" (-1): as it is used by Insight
only, there is no need to update calls from the gdb source tree.

gdb: add Patrick Monnerat to gdb/MAINTAINERS

x86: move / quiesce pre-386 non-16-bit warning

Emitting this warning for every insn, including ones having actual
errors, is annoying. Introduce a boolean variable to emit the warning
just once on the first insn after .arch may have changed the things, and
move the warning to output_insn(). (I didn't want to go as far as
checking whether the .arch actually turned off the i386 bit, but doing
so would be an option.)

x86: insert "no error" enumerator in i386_error enumeration

The value of zero would better not indicate any error, but rather hit
the abort() at the top of the consuming switch().

Automatic date update in version.in

GDB/testsuite: Fix PARAM_ZUINTEGER reported for PARAM_ZUINTEGER_UNLIMITED

Correctly report PARAM_ZUINTEGER_UNLIMITED rather than PARAM_ZUINTEGER
in testing a Python parameter of the PARAM_ZUINTEGER_UNLIMITED type.

bfd_elf_set_group_contents assertion

objcopy of broken SHT_GROUP sections shouldn't write garbage.

* elf.c (bfd_elf_set_group_contents): If number of entries is
unexpected, fill out section with zeros.

timeout in mmo_get_symbols

Fix mmo_get_byte to return a fail-safe value, not just on the first
call with a read error but on subsequent calls too.

* mmo.c (mmo_get_byte): Return the fail-safe value on every
call after a read error.

mmo.c leak in mmo_make_section

* mmo.c (mmo_make_section): Alloc name using bfd_alloc.  Use
bfd_error_no_memory.
(mmo_decide_section): Check for NULL return from mmo_make_section.

asan: heap buffer overflow in mmo_scan

mmo_get_loc needs to handle arbitrary vma and size chunks.  Fuzzers
found that it wasn't working so well when the end of chunks were
getting close to address wrap-around.

* mmo.c (mmo_get_loc): Make "size" unsigned.  Avoid arithmetic
overflow when calculating whether range hits an existing chunk.

elf.c tidy

Swap params of is_note, so they are section, segment like others used
in rewrite_elf_program_header.  Whitespace fixes, plus wrapping of
overlong lines.

Automatic date update in version.in

bfd: Define ___lc_codepage_func prototype for older MinGW-w64

In commit 68e80d96a84282d547f3b3c1234c99009521630c, the usage of
___lc_codepage_func was introduced to determine the current encoding.

Prior to version 9.0 of MinGW-w64, the function prototype for
___lc_codepage_func was missing and trying to build BFD caused the
following error:

error: implicit declaration of function ‘___lc_codepage_func’

This changeset adds a conditonal definition of
___lc_codepage_func to allow a sucessful build with MinGW-w64.

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

i386: Add MAX_OPERAND_BUFFER_SIZE

When displaying operands, invalid opcodes may overflow operand buffer
due to additional styling characters.  Each style is encoded with 3
bytes.  Define MAX_OPERAND_BUFFER_SIZE for operand buffer size and
increase it from 100 bytes to 128 bytes to accommodate 9 sets of styles
in an operand.

gas/

PR binutils/29483
* testsuite/gas/i386/i386.exp: Run pr29483.
* testsuite/gas/i386/pr29483.d: New file.
* testsuite/gas/i386/pr29483.s: Likewise.

opcodes/

PR binutils/29483
* i386-dis.c (MAX_OPERAND_BUFFER_SIZE): New.
(obuf): Replace 100 with MAX_OPERAND_BUFFER_SIZE.
(staging_area): Likewise.
(op_out): Likewise.

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.