arc: Determine a branch target of DBNZ correctly

DBNZ instruction was moved from BRANCH class to a separate one - DBNZ.
Thus, it must be processed separately in arc_insn_get_branch_target
to correctly determine an offset for a possible branch.

The testsuite for DBNZ instruction verifies these cases:

     1. Check that dbnz does not branch and falls through if its source
        register is 0 after decrementing. GDB must successfully break
        on the following instruction after stepping over.
     2. Check that dbnz branches to the target correctly if its source register
        is not 0 after decrementing - GDB must successfully break on the target
        instruction if a forward branch is performed after stepping over.
     3. The same as point 2 but for a backward branching case.

Signed-off-by: Yuriy Kolerov <kolerov93@gmail.com>

Re: PR29785, memory bloat after b43771b045fb

Commit 7bd1e04a3532 introduced "dwarf2.c:2152:29: runtime error: shift
exponent 64 is too large".  This is on the bucket_high_pc calculation
which was moved to the top of insert_arange_in_trie where previously
it was later, at a point where the overflow could not occur.  Move it
back and arrange for a duplicate calculation of bucket_high_pc which
is also protected from overflow.

PR 29785
* dwarf2.c (insert_arange_in_trie): Split bucket_high_pc.
Move trie_pc_bits < VMA_BITS into splitting_leaf_will_help.

Remove is_relocatable_executable from backend code

With the removal of symbian support, most targets no longer or never
did set is_relocatable_executable.  Remove the backend support that is
no longer relevant.

* elf32-arm.c (record_arm_to_thumb_glue, elf32_arm_create_thumb_stub),
(elf32_arm_final_link_relocate, elf32_arm_check_relocs),
(elf32_arm_adjust_dynamic_symbol, allocate_dynrelocs_for_symbol),
(elf32_arm_output_arch_local_syms): Remove is_relocatable_executable
code and comments.
* elf32-csky.c (csky_elf_adjust_dynamic_symbol): Likewise.
* elfnn-aarch64.c (elfNN_aarch64_final_link_relocate): Likewise.
* elfnn-kvx.c (elfNN_kvx_final_link_relocate): Likewise.
* elfxx-mips.c (count_section_dynsyms): Likewise.

aarch64: testsuite: move sysreg tests into sysreg sub-directory

This patch moves the existing sysreg tests for AArch64 into a subdirectory
(sysreg). The number of test files related to system registers grew
relatively big with time and makes the browsing of those files difficult.
Moreover, the difference of naming for the failure, working, and
feature-specific scenarios causes the tests not to appear next to one
another in the exploration tree when it is ordered alphabetically.

[gdb/dap] Join JSON writer thread with DAP thread

The DAP interpreter runs in its own thread, and starts a few threads:
- the JSON reader thread,
- the JSON writer thread, and
- the inferior output reader thread.

As part of the DAP shutdown, both the JSON reader thread and the JSON writer
thread, as well as the DAP main thread run to exit, but these exits are not
ordered in any way.

Wait in the main DAP thread for the exit of the JSON writer thread.

This makes sure that the responses are flushed to the DAP client before DAP
shutdown.

An earlier version of this patch used Queue.task_done() to accomplish the
same, but that didn't guarantee writing the "<thread name>: terminating"
log entry from thread_wrapper before DAP shutdown.

Tested on aarch64-linux.

Approved-By: Tom Tromey <tom@tromey.com>
PR dap/31380
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31380

[gdb/dap] Make dap log printing thread-safe

I read that printing from different python threads is thread-unsafe, and I
noticed that the dap log printing is used from different threads, but doesn't
take care to make the printing thread-safe.

Fix this by using a lock to access LoggingParam.log_file.

Tested on aarch64-linux.

Approved-By: Tom Tromey <tom@tromey.com>

[gdb/dap] Flush after printing in log_stack

I noticed that function log flushes the dap log file after printing, but
that function log_stack doesn't.

Fix this by also flushing the dap log file in log_stack.

Tested on aarch64-linux.

Approved-By: Tom Tromey <tom@tromey.com>

[gdb/testsuite] Set up dap log file in gdb.dap/type_checker.exp

While debugging a slow-down in test-case gdb.dap/type_checker.exp due to a WIP
patch, I noticed that test-case gdb.dap/type_checker.exp doesn't have a dap
log file.

This is normally set up by dap_gdb_start, but the test-case doesn't use it.

Fix this by doing "set debug dap-log-file $logfile" in the test-case.

To make it easy to do so, I've factored out a new proc new_dap_log_file, and
while at likewise a new proc current_dap_log_file.

Note that the log file is currently empty.

Tested on x86_64-linux.

Approved-By: Tom Tromey <tom@tromey.com>

gdb: Document C++17 build requirement.

We require C++17 to build for a while now:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f74dc26792a0679e29db45e56367331ff48666d1

Reviewed-By: Lancelot Six <lancelot.six@amd.com>

RISC-V: Fix local GOT and reloc size calculation for TLS.

The previous code did not account correctly for two cases:
* A TLS symbol can be referenced with multiple TLS types (although rare),
  in which case it only allocated the maximum slot size among the types,
  instead of the sum.
* TLS relocations are only needed for DLLs, unlike normal symbols which
  requires relocations for all PIE code.

Modify the logic to account for the two cases, so this fixes the redundant
dynamic R_RISCV_NONE in .rela.dyn when using --no-pie for TLS GD and IE.

Passed the gcc/binutils regressions of riscv-gnu-toolchain.

bfd/
    * elfnn-riscv.c (riscv_elf_size_dynamic_sections): Handle relocation
    sizing for TLS and non-TLS symbols differently, with the former
    requiring relocs on DLL while the latter requiring on PIE.
    Allocate GOT slots and relocation slots for each TLS type separately,
    accounting for the possibility of a TLS variable getting referenced by
    multiple symbols.
ld/
    * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
    * testsuite/ld-riscv-elf/tls*: New testcase for TLS GD and IE, with
    symbols referred by both types and global and local symbols.

RISC-V: Don't generate branch/jump relocation if symbol is local when no-relax.

Refer to commit, dff565fcca8137954d6ad571ef39f6aec5c0429c.  Theoretically,
assembler don't need to generate the pc-relative relocation and the refered
local .L symbol when relaxation is disabled.  The above commit improved the
pcrel_hi/pcrel_lo relocations, and this commit improves branch and jump
relocations.

Passed the gcc/binutils regressions of riscv-gnu-toolchain.

gas/
* config/tc-riscv.c (md_apply_fix): Raise fixP->fx_done for all
branch and jump relocations when -mno-relax.

Automatic date update in version.in

Rewrite Rust slice type handling

This patch rewrites the handling of slice types in Rust.

More recent versions of the Rust compiler changed how unsized types
were emitted, letting gdb inspect them more nicely.  However, gdb did
not do this, and in fact treated all such types as if they were slices
of arrays, which is incorrect.

This patch rewrites this handling and removes the restriction that
unsized types must be array slices.  I've added a comment explaining
how unsized types are represented to rust-lang.c as well.

I looked into a different approach, namely changing the DWARF reader
to fix up slice types to have a dynamic type.  However, the approach
taken here turned out to be simpler.

Tested on x86-64 Fedora 38 with a variety of Rust compiler versions.

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

Add obj_section::contains method

I noticed a number of spots checking whether an address is in an
obj_section.  This patch introduces a new method for this and changes
some code to use it.

Regression tested on x86-64 Fedora 38.

Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: pass frames as `const frame_info_ptr &`

We currently pass frames to function by value, as `frame_info_ptr`.
This is somewhat expensive:

 - the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass
   by value
 - the constructors and destructor link/unlink the object in the global
   `frame_info_ptr::frame_list` list.  This is an `intrusive_list`, so
   it's not so bad: it's just assigning a few points, there's no memory
   allocation as if it was `std::list`, but still it's useless to do
   that over and over.

As suggested by Tom Tromey, change many function signatures to accept
`const frame_info_ptr &` instead of `frame_info_ptr`.

Some functions reassign their `frame_info_ptr` parameter, like:

  void
  the_func (frame_info_ptr frame)
  {
    for (; frame != nullptr; frame = get_prev_frame (frame))
      {
        ...
      }
  }

I wondered what to do about them, do I leave them as-is or change them
(and need to introduce a separate local variable that can be
re-assigned).  I opted for the later for consistency.  It might not be
clear why some functions take `const frame_info_ptr &` while others take
`frame_info_ptr`.  Also, if a function took a `frame_info_ptr` because
it did re-assign its parameter, I doubt that we would think to change it
to `const frame_info_ptr &` should the implementation change such that
it doesn't need to take `frame_info_ptr` anymore.  It seems better to
have a simple rule and apply it everywhere.

Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0
Approved-By: Andrew Burgess <aburgess@redhat.com>

[gdb] Don't init history in batch mode

I noticed in captured_main_1 that init_history is called just before bailing
out if batch_flag is true.

The history is used only in an interactive session, so there's no need to
initialize it in batch mode.

Fix this by moving init_history to after the batch mode check.

Tested on x86_64-linux.

Approved-By: Andrew Burgess <aburgess@redhat.com>

kvx: gas: missing aliases for $r14r15 in assembler.

Most registers from a register-pair suffixed by .lo and .hi suffixes.
This was not the case of $r14 and $r15 since they are defined by the
ABI: $r14 is the frame pointer, and $r15 is used to return aggregates
from functions.  We do not add aliases for $r12 (the stack pointer) and
$r13 (the tls register).

opcodes/ChangeLog:

* kvx-opc.c: Regenerate.

gas/ChangeLog:

* config/kvx-parse.h: Regenerate.

kvx: enable magic immediates for integer multiply-accumulate and CMOVE*

Affected instructions:
 - alu unit:
    cmovewp cmovehq
 - mau unit:
     maddwdp madduwdp maddsuwdp mma msbfwdp msbfuwdp
     msbfsuwdp mms mulwdp muluwdp mulsuwdp mm

opcodes/ChangeLog:

* kvx-opc.c (struct kvxopc): Regenerate.

gas/ChangeLog:

* config/kvx-parse.h: Regenerate.

kvx: gas: rename: or -> ior, xor -> eor

TCA instructions start with an X, this introduces ambiguities when it
comes to XOR (Is it the OR on the TCA or the XOR of the core?).  For this
reason, we rename OR to IOR and XOR to EOR.

OR and XOR variants are still valid on KV3-1 and KV3-2.  However, they
have been completely removed from KV4-1.

opcodes/ChangeLog:

* kvx-opc.c: Regenerate.

include/ChangeLog:

* opcode/kvx.h: Regenerate.

gas/ChangeLog:

* config/kvx-parse.h: Regenerate.
* testsuite/gas/kvx/kv3-1-insns-32.d: Regenerate.
* testsuite/gas/kvx/kv3-1-insns-32.s: Regenerate.
* testsuite/gas/kvx/kv3-1-insns-64.d: Regenerate.
* testsuite/gas/kvx/kv3-1-insns-64.s: Regenerate.
* testsuite/gas/kvx/kv3-2-insns-32.d: Regenerate.
* testsuite/gas/kvx/kv3-2-insns-32.s: Regenerate.
* testsuite/gas/kvx/kv3-2-insns-64.d: Regenerate.
* testsuite/gas/kvx/kv3-2-insns-64.s: Regenerate.
* testsuite/gas/kvx/kv4-1-insns-32.d: Regenerate.
* testsuite/gas/kvx/kv4-1-insns-32.s: Regenerate.
* testsuite/gas/kvx/kv4-1-insns-64.d: Regenerate.
* testsuite/gas/kvx/kv4-1-insns-64.s: Regenerate.

kvx: gas: move the splat modifier to the immediate

The position of the splat modifier is now after the operand it
modifies and not attached directly to the opcode.

opcodes/ChangeLog:

* kvx-opc.c: Regenerate.

include/ChangeLog:

* opcode/kvx.h: Regenerate.

gas/ChangeLog:

* config/kvx-parse.h: Regenerate.
* testsuite/gas/kvx/kv3-1-insns-32.d: Regenerate.
* testsuite/gas/kvx/kv3-1-insns-32.s: Regenerate.
* testsuite/gas/kvx/kv3-1-insns-64.d: Regenerate.
* testsuite/gas/kvx/kv3-1-insns-64.s: Regenerate.
* testsuite/gas/kvx/kv3-2-insns-32.d: Regenerate.
* testsuite/gas/kvx/kv3-2-insns-32.s: Regenerate.
* testsuite/gas/kvx/kv3-2-insns-64.d: Regenerate.
* testsuite/gas/kvx/kv3-2-insns-64.s: Regenerate.
* testsuite/gas/kvx/kv4-1-insns-32.d: Regenerate.
* testsuite/gas/kvx/kv4-1-insns-32.s: Regenerate.
* testsuite/gas/kvx/kv4-1-insns-64.d: Regenerate.
* testsuite/gas/kvx/kv4-1-insns-64.s: Regenerate.

kvx: gas: fix leak

gas/ChangeLog:

* config/tc-kvx.c (md_apply_fix): Free memory at this end.

kvx: Improve lexing & parsing

Up until now, we used ENV.PROMOTE_IMMEDIATE to get the next candidates,
however this candidate can be directly extracted from the array (in
kvx-parse.h) registering all the immediates.

During lexing, we ignored trailing characters after a number, this is
not good enough since now number can be followed by a modifier.  The
function READ_TOKEN and GET_TOKEN_CLASS have been update to take this
into account.

gas/ChangeLog:

* config/kvx-parse.c (promote_token): Do not rely on
  env.promote_immediate anymore.
(get_token_class): Do not ignore trailing characters after a
number.
(read_token): Likewise.
(print_token_list): THIS SHOULD NOT BE HERE.

kvx: gas: fix the detection of negative powers of 2

The detection of negative powers of 2 was wrong and could lead to
well-formed bundles ending up taking more syllables than necessary.

gas/ChangeLog:

* config/kvx-parse.c (get_token_class): Use the signed value.
* testsuite/gas/kvx/np2-detection.d: New test.
* testsuite/gas/kvx/np2-detection.s: New test.

bpf: gas: add missing indcall-badoperand.* test files

This adds teh following files that were missing in the previous
commit ecd16ae4e47118f66447641d93a6aa1334e550d4

  testsuite/gas/bpf/indcall-badoperand.d
  testsuite/gas/bpf/indcall-badoperand.l
  testsuite/gas/bpf/indcall-badoperand.s

Automatic date update in version.in

bpf: fix bpf expression parsing regression in GAS

As a result of a switch instead of an if, as would issue non-specific
error messages when it encountered an operand it could not parse in bpf.
This patch fixes that regression and adds a test to prevent it from
reoccurring.

Tested for bpf-unknown-none on x86_64-redhat-linux.

gas/ChangeLog:

* config/tc-bpf.c (parse_expression): Change switch to if so that error
* condition is handled.
* testsuite/gas/bpf/bpf.exp: Invoke new test.
* testsuite/gas/bpf/indcall-badoperand.d: New test.
* testsuite/gas/bpf/indcall-badoperand.l: New test.
* testsuite/gas/bpf/indcall-badoperand.s: New test.

bpf: gas: avoid UB in pointer subtraction

The PARSE_ERROR macro in md_assemble performs pointer subtraction.  If
parse_expression returns NULL then the later will be part of the
subtraction and therefore UB will be incurred.

This patch changes md_assemble to:
1. Accommodate all invocations to parse_expression to the fact it will
   return NULL when a parse error occurs.
2. Avoid UB in PARSE_ERROR.

Tested in bpf-unknown-none target / x86_64-linux-gnu host.

gas/ChangeLog:

* config/tc-bpf.c (md_assemble): Fix to take into account that
parse_expression can return NULL.
(PARSE_ERROR): Avoid passing invalid length to parse_error.

arm: Add support for Armv9.5-A

aarch64: Add support for the id_aa64isar3_el1 system register

Hi,

[PATCH][Binutils] aarch64: Add support for the id_aa64isar3_el1 system register

AArch64 defines a read-only system register called id_aa64isar3_el1.
This patch also adds relevant tests.

Regression tested on the aarch64-none-elf and aarch64-none-linux-gnu targets
and no regressions was found.

Is this Ok for trunk? I do not have commit rights, if OK, can someone commit on my behalf?

Thanks,
Yury Khrustalev

From e42c835e8f2ee81150f498675f2faf108bbe79f8 Mon Sep 17 00:00:00 2001
From: Yury Khrustalev <yury.khrustalev@arm.com>
Date: Tue, 6 Feb 2024 11:05:39 +0000
Subject: [PATCH] [PATCH][Binutils] aarch64: Add support for the
 id_aa64isar3_el1 system register

AArch64 defines a read-only system register called id_aa64isar3_el1.
This patch also adds relevant tests.

Regression tested on the aarch64-none-elf and aarch64-none-linux-gnu targets
and no regressions was found.

testsuite, python: reformat python files using black

In the recent patch titled "gdb, python: selectively omit enabling
stdin in gdb.execute", the black tool found formatting issues.  Fix
them.

aarch64: Add new relocations and limit COFF AArch64 relocation offsets

The patch adds support for the IMAGE_REL_ARM64_REL32 coff relocation
type. This is needed for 32-bit relative address.

It also adds a check for relocation offsets over 21 bits. Offsets
inside coff files are stored in instruction code. In the case of ADRP
the actual value is stored, not a downshifted page offset. This means
values over 21 bits would otherwise be truncated.

Finally it adds a mapping for BFD_RELOC_AARCH64_ADR_GOT_PAGE and
BFD_RELOC_AARCH64_LD64_GOT_LO12_NC that were previously skipped.

ChangeLog:

* bfd/coff-aarch64.c (coff_aarch64_reloc_type_lookup): Add
BFD_RELOC_AARCH64_ADR_GOT_PAGE,
BFD_RELOC_AARCH64_LD64_GOT_LO12_NC and IMAGE_REL_ARM64_REL32
relocations.
(coff_pe_aarch64_relocate_section): Likewise.
* gas/write.c (adjust_reloc_syms): COFF AArch64 relocation
offsets need to be limited to 21bits
(defined): Likewise.

gdb, python: selectively omit enabling stdin in gdb.execute

From the Python API, we can execute GDB commands via gdb.execute.  If
the command gives an exception, however, we need to recover the GDB
prompt and enable stdin, because the exception does not reach
top-level GDB or normal_stop.  This was done in commit

  commit 1ba1ac88011703abcd0271e4f5d00927dc69a09a
  Author: Andrew Burgess <andrew.burgess@embecosm.com>
  Date:   Tue Nov 19 11:17:20 2019 +0000

    gdb: Enable stdin on exception in execute_gdb_command

with the following code:

  catch (const gdb_exception &except)
    {
      /* If an exception occurred then we won't hit normal_stop (), or have
         an exception reach the top level of the event loop, which are the
         two usual places in which stdin would be re-enabled. So, before we
         convert the exception and continue back in Python, we should
         re-enable stdin here.  */
      async_enable_stdin ();
      GDB_PY_HANDLE_EXCEPTION (except);
    }

In this patch, we explain what happens when we run a GDB command in
the context of a synchronous command, e.g.  via Python observer
notifications.

As an example, suppose we have the following objfile event listener,
specified in a file named file.py:

~~~
import gdb

class MyListener:
    def __init__(self):
        gdb.events.new_objfile.connect(self.handle_new_objfile_event)
        self.processed_objfile = False

    def handle_new_objfile_event(self, event):
        if self.processed_objfile:
            return

        print("loading " + event.new_objfile.filename)
        self.processed_objfile = True
        gdb.execute('add-inferior -no-connection')
        gdb.execute('inferior 2')
        gdb.execute('target remote | gdbserver - /tmp/a.out')
        gdb.execute('inferior 1')

the_listener = MyListener()
~~~

Using this Python file, we see the behavior below:

  $ gdb -q -ex "source file.py" -ex "run" --args a.out
  Reading symbols from a.out...
  Starting program: /tmp/a.out
  loading /lib64/ld-linux-x86-64.so.2
  [New inferior 2]
  Added inferior 2
  [Switching to inferior 2 [<null>] (<noexec>)]
  stdin/stdout redirected
  Process /tmp/a.out created; pid = 3075406
  Remote debugging using stdio
  Reading /tmp/a.out from remote target...
  ...
  [Switching to inferior 1 [process 3075400] (/tmp/a.out)]
  [Switching to thread 1.1 (process 3075400)]
  #0  0x00007ffff7fe3290 in ?? () from /lib64/ld-linux-x86-64.so.2
  (gdb) [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  [Inferior 1 (process 3075400) exited normally]

Note how the GDB prompt comes in-between the debugger output.  We have this
obscure behavior, because the executed command, "target remote", triggers
an invocation of `normal_stop` that enables stdin.  After that, however,
the Python notification context completes and GDB continues with its normal
flow of executing the 'run' command.  This can be seen in the call stack
below:

  (top-gdb) bt
  #0  async_enable_stdin () at src/gdb/event-top.c:523
  #1  0x00005555561c3acd in normal_stop () at src/gdb/infrun.c:9432
  #2  0x00005555561b328e in start_remote (from_tty=0) at src/gdb/infrun.c:3801
  #3  0x0000555556441224 in remote_target::start_remote_1 (this=0x5555587882e0, from_tty=0, extended_p=0) at src/gdb/remote.c:5225
  #4  0x000055555644166c in remote_target::start_remote (this=0x5555587882e0, from_tty=0, extended_p=0) at src/gdb/remote.c:5316
  #5  0x00005555564430cf in remote_target::open_1 (name=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0, extended_p=0) at src/gdb/remote.c:6175
  #6  0x0000555556441707 in remote_target::open (name=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0) at src/gdb/remote.c:5338
  #7  0x00005555565ea63f in open_target (args=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0, command=0x555558589280)  at src/gdb/target.c:824
  #8  0x0000555555f0d89a in cmd_func (cmd=0x555558589280, args=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0) at src/gdb/cli/cli-decode.c:2735
  #9  0x000055555661fb42 in execute_command (p=0x55555878529e "t", from_tty=0) at src/gdb/top.c:575
  #10 0x0000555555f1a506 in execute_control_command_1 (cmd=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:529
  #11 0x0000555555f1abea in execute_control_command (cmd=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:701
  #12 0x0000555555f19fc7 in execute_control_commands (cmdlines=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:411
  #13 0x0000555556400d91 in execute_gdb_command (self=0x7ffff43b5d00, args=0x7ffff440ab60, kw=0x0) at src/gdb/python/python.c:700
  #14 0x00007ffff7a96023 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
  #15 0x00007ffff7a4dadc in _PyObject_MakeTpCall () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
  #16 0x00007ffff79e9a1c in _PyEval_EvalFrameDefault () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
  #17 0x00007ffff7b303af in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
  #18 0x00007ffff7a50358 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
  #19 0x00007ffff7a4f3f4 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
  #20 0x00007ffff7a4f883 in PyObject_CallFunctionObjArgs () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
  #21 0x00005555563a9758 in evpy_emit_event (event=0x7ffff42b5430, registry=0x7ffff42b4690) at src/gdb/python/py-event.c:104
  #22 0x00005555563cb874 in emit_new_objfile_event (objfile=0x555558761700) at src/gdb/python/py-newobjfileevent.c:52
  #23 0x00005555563b53bc in python_new_objfile (objfile=0x555558761700) at src/gdb/python/py-inferior.c:195
  #24 0x0000555555d6dff0 in std::__invoke_impl<void, void (*&)(objfile*), objfile*> (__f=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile*)>) at /usr/include/c++/11/bits/invoke.h:61
  #25 0x0000555555d6be18 in std::__invoke_r<void, void (*&)(objfile*), objfile*> (__fn=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile*)>) at /usr/include/c++/11/bits/invoke.h:111
  #26 0x0000555555d69661 in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7fffffffd080: 0x555558761700) at /usr/include/c++/11/bits/std_function.h:290
  #27 0x0000555556314caf in std::function<void (objfile*)>::operator()(objfile*) const (this=0x5555585b5860, __args#0=0x555558761700) at /usr/include/c++/11/bits/std_function.h:590
  #28 0x000055555631444e in gdb::observers::observable<objfile*>::notify (this=0x55555836eea0 <gdb::observers::new_objfile>, args#0=0x555558761700) at src/gdb/../gdbsupport/observable.h:166
  #29 0x0000555556599b3f in symbol_file_add_with_addrs (abfd=..., name=0x55555875d310 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1125
  #30 0x0000555556599ca4 in symbol_file_add_from_bfd (abfd=..., name=0x55555875d310 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1160
  #31 0x0000555556546371 in solib_read_symbols (so=..., flags=...) at src/gdb/solib.c:692
  #32 0x0000555556546f0f in solib_add (pattern=0x0, from_tty=0, readsyms=1) at src/gdb/solib.c:1015
  #33 0x0000555556539891 in enable_break (info=0x55555874e180, from_tty=0) at src/gdb/solib-svr4.c:2416
  #34 0x000055555653b305 in svr4_solib_create_inferior_hook (from_tty=0) at src/gdb/solib-svr4.c:3058
  #35 0x0000555556547cee in solib_create_inferior_hook (from_tty=0) at src/gdb/solib.c:1217
  #36 0x0000555556196f6a in post_create_inferior (from_tty=0) at src/gdb/infcmd.c:275
  #37 0x0000555556197670 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at src/gdb/infcmd.c:486
  #38 0x000055555619783f in run_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:512
  #39 0x0000555555f0798d in do_simple_func (args=0x0, from_tty=1, c=0x555558567510) at src/gdb/cli/cli-decode.c:95
  #40 0x0000555555f0d89a in cmd_func (cmd=0x555558567510, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:2735
  #41 0x000055555661fb42 in execute_command (p=0x7fffffffe2c4 "", from_tty=1) at src/gdb/top.c:575
  #42 0x000055555626303b in catch_command_errors (command=0x55555661f4ab <execute_command(char const*, int)>, arg=0x7fffffffe2c1 "run", from_tty=1, do_bp_actions=true) at src/gdb/main.c:513
  #43 0x000055555626328a in execute_cmdargs (cmdarg_vec=0x7fffffffdaf0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffda3c) at src/gdb/main.c:612
  #44 0x0000555556264849 in captured_main_1 (context=0x7fffffffdd40) at src/gdb/main.c:1293
  #45 0x0000555556264a7f in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1314
  #46 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343
  #47 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39
  (top-gdb)

The use of the "target remote" command here is just an example.  In
principle, we would reproduce the problem with any command that
triggers an invocation of `normal_stop`.

To omit enabling the stdin in `normal_stop`, we would have to check the
context we are in.  Since we cannot do that, we add a new field to
`struct ui` to track whether the prompt was already blocked, and set
the tracker flag in the Python context before executing a GDB command.

After applying this patch, the output becomes

  ...
  Reading symbols from a.out...
  Starting program: /tmp/a.out
  loading /lib64/ld-linux-x86-64.so.2
  [New inferior 2]
  Added inferior 2
  [Switching to inferior 2 [<null>] (<noexec>)]
  stdin/stdout redirected
  Process /tmp/a.out created; pid = 3032261
  Remote debugging using stdio
  Reading /tmp/a.out from remote target...
  ...
  [Switching to inferior 1 [process 3032255] (/tmp/a.out)]
  [Switching to thread 1.1 (process 3032255)]
  #0  0x00007ffff7fe3290 in ?? () from /lib64/ld-linux-x86-64.so.2
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  [Inferior 1 (process 3032255) exited normally]
  (gdb)

Let's now consider a secondary scenario, where the command executed from
the Python raises an error.  As an example, suppose we have the Python
file below:

    def handle_new_objfile_event(self, event):
        ...
        print("loading " + event.new_objfile.filename)
        self.processed_objfile = True
        gdb.execute('print a')

The executed command, "print a", gives an error because "a" is not
defined.  Without this patch, we see the behavior below, where the
prompt is again placed incorrectly:

  ...
  Reading symbols from /tmp/a.out...
  Starting program: /tmp/a.out
  loading /lib64/ld-linux-x86-64.so.2
  Python Exception <class 'gdb.error'>: No symbol "a" in current context.
  (gdb) [Inferior 1 (process 3980401) exited normally]

This time, `async_enable_stdin` is called from the 'catch' block in
`execute_gdb_command`:

  (top-gdb) bt
  #0  async_enable_stdin () at src/gdb/event-top.c:523
  #1  0x0000555556400f0a in execute_gdb_command (self=0x7ffff43b5d00, args=0x7ffff440ab60, kw=0x0) at src/gdb/python/python.c:713
  #2  0x00007ffff7a96023 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
  #3  0x00007ffff7a4dadc in _PyObject_MakeTpCall () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
  #4  0x00007ffff79e9a1c in _PyEval_EvalFrameDefault () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
  #5  0x00007ffff7b303af in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
  #6  0x00007ffff7a50358 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
  #7  0x00007ffff7a4f3f4 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
  #8  0x00007ffff7a4f883 in PyObject_CallFunctionObjArgs () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
  #9  0x00005555563a9758 in evpy_emit_event (event=0x7ffff42b5430, registry=0x7ffff42b4690) at src/gdb/python/py-event.c:104
  #10 0x00005555563cb874 in emit_new_objfile_event (objfile=0x555558761410) at src/gdb/python/py-newobjfileevent.c:52
  #11 0x00005555563b53bc in python_new_objfile (objfile=0x555558761410) at src/gdb/python/py-inferior.c:195
  #12 0x0000555555d6dff0 in std::__invoke_impl<void, void (*&)(objfile*), objfile*> (__f=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile*)>) at /usr/include/c++/11/bits/invoke.h:61
  #13 0x0000555555d6be18 in std::__invoke_r<void, void (*&)(objfile*), objfile*> (__fn=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile*)>) at /usr/include/c++/11/bits/invoke.h:111
  #14 0x0000555555d69661 in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7fffffffd080: 0x555558761410) at /usr/include/c++/11/bits/std_function.h:290
  #15 0x0000555556314caf in std::function<void (objfile*)>::operator()(objfile*) const (this=0x5555585b5860, __args#0=0x555558761410) at /usr/include/c++/11/bits/std_function.h:590
  #16 0x000055555631444e in gdb::observers::observable<objfile*>::notify (this=0x55555836eea0 <gdb::observers::new_objfile>, args#0=0x555558761410) at src/gdb/../gdbsupport/observable.h:166
  #17 0x0000555556599b3f in symbol_file_add_with_addrs (abfd=..., name=0x55555875d020 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1125
  #18 0x0000555556599ca4 in symbol_file_add_from_bfd (abfd=..., name=0x55555875d020 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1160
  #19 0x0000555556546371 in solib_read_symbols (so=..., flags=...) at src/gdb/solib.c:692
  #20 0x0000555556546f0f in solib_add (pattern=0x0, from_tty=0, readsyms=1) at src/gdb/solib.c:1015
  #21 0x0000555556539891 in enable_break (info=0x55555874a670, from_tty=0) at src/gdb/solib-svr4.c:2416
  #22 0x000055555653b305 in svr4_solib_create_inferior_hook (from_tty=0) at src/gdb/solib-svr4.c:3058
  #23 0x0000555556547cee in solib_create_inferior_hook (from_tty=0) at src/gdb/solib.c:1217
  #24 0x0000555556196f6a in post_create_inferior (from_tty=0) at src/gdb/infcmd.c:275
  #25 0x0000555556197670 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at src/gdb/infcmd.c:486
  #26 0x000055555619783f in run_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:512
  #27 0x0000555555f0798d in do_simple_func (args=0x0, from_tty=1, c=0x555558567510) at src/gdb/cli/cli-decode.c:95
  #28 0x0000555555f0d89a in cmd_func (cmd=0x555558567510, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:2735
  #29 0x000055555661fb42 in execute_command (p=0x7fffffffe2c4 "", from_tty=1) at src/gdb/top.c:575
  #30 0x000055555626303b in catch_command_errors (command=0x55555661f4ab <execute_command(char const*, int)>, arg=0x7fffffffe2c1 "run", from_tty=1, do_bp_actions=true) at src/gdb/main.c:513
  #31 0x000055555626328a in execute_cmdargs (cmdarg_vec=0x7fffffffdaf0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffda3c) at src/gdb/main.c:612
  #32 0x0000555556264849 in captured_main_1 (context=0x7fffffffdd40) at src/gdb/main.c:1293
  #33 0x0000555556264a7f in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1314
  #34 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343
  #35 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39
  (top-gdb)

Again, after we enable stdin, GDB continues with its normal flow
of the 'run' command and receives the inferior's exit event, where
it would have enabled stdin, if we had not done it prematurely.

  (top-gdb) bt
  #0  async_enable_stdin () at src/gdb/event-top.c:523
  #1  0x00005555561c3acd in normal_stop () at src/gdb/infrun.c:9432
  #2  0x00005555561b5bf1 in fetch_inferior_event () at src/gdb/infrun.c:4700
  #3  0x000055555618d6a7 in inferior_event_handler (event_type=INF_REG_EVENT) at src/gdb/inf-loop.c:42
  #4  0x000055555620ecdb in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4316
  #5  0x0000555556f33035 in handle_file_event (file_ptr=0x5555587024e0, ready_mask=1) at src/gdbsupport/event-loop.cc:573
  #6  0x0000555556f3362f in gdb_wait_for_event (block=0) at src/gdbsupport/event-loop.cc:694
  #7  0x0000555556f322cd in gdb_do_one_event (mstimeout=-1) at src/gdbsupport/event-loop.cc:217
  #8  0x0000555556262df8 in start_event_loop () at src/gdb/main.c:407
  #9  0x0000555556262f85 in captured_command_loop () at src/gdb/main.c:471
  #10 0x0000555556264a84 in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1324
  #11 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343
  #12 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39
  (top-gdb)

The solution implemented by this patch addresses the problem.  After
applying the patch, the output becomes

  $ gdb -q -ex "source file.py" -ex "run" --args a.out
  Reading symbols from /tmp/a.out...
  Starting program: /tmp/a.out
  loading /lib64/ld-linux-x86-64.so.2
  Python Exception <class 'gdb.error'>: No symbol "a" in current context.
  [Inferior 1 (process 3984511) exited normally]
  (gdb)

Regression-tested on X86_64 Linux using the default board file (i.e.  unix).

Co-Authored-By: Oguzhan Karakaya <oguzhan.karakaya@intel.com>
Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>

[gdb/exp] Fix printing of out of bounds struct members

When building gdb with -O0 -fsanitize=address, and running test-case
gdb.ada/uninitialized_vars.exp, I run into:
...
(gdb) info locals
a = 0
z = (a => 1, b => false, c => 2.0)
=================================================================
==66372==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000097f58 at pc 0xffff52c0da1c bp 0xffffc90a1d40 sp 0xffffc90a1d80
READ of size 4 at 0x602000097f58 thread T0
    #0 0xffff52c0da18 in memmove (/lib64/libasan.so.8+0x6da18)
    #1 0xbcab24 in unsigned char* std::__copy_move_backward<false, true, std::random_access_iterator_tag>::__copy_move_b<unsigned char const, unsigned char>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:748
    #2 0xbc9bf4 in unsigned char* std::__copy_move_backward_a2<false, unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:769
    #3 0xbc898c in unsigned char* std::__copy_move_backward_a1<false, unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:778
    #4 0xbc715c in unsigned char* std::__copy_move_backward_a<false, unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:807
    #5 0xbc4e6c in unsigned char* std::copy_backward<unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:867
    #6 0xbc2934 in void gdb::copy<unsigned char const, unsigned char>(gdb::array_view<unsigned char const>, gdb::array_view<unsigned char>) gdb/../gdbsupport/array-view.h:223
    #7 0x20e0100 in value::contents_copy_raw(value*, long, long, long) gdb/value.c:1239
    #8 0x20e9830 in value::primitive_field(long, int, type*) gdb/value.c:3078
    #9 0x20e98f8 in value_field(value*, int) gdb/value.c:3095
    #10 0xcafd64 in print_field_values gdb/ada-valprint.c:658
    #11 0xcb0fa0 in ada_val_print_struct_union gdb/ada-valprint.c:857
    #12 0xcb1bb4 in ada_value_print_inner(value*, ui_file*, int, value_print_options const*) gdb/ada-valprint.c:1042
    #13 0xc66e04 in ada_language::value_print_inner(value*, ui_file*, int, value_print_options const*) const (/home/vries/gdb/build/gdb/gdb+0xc66e04)
    #14 0x20ca1e8 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1092
    #15 0x20caabc in common_val_print_checked(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1184
    #16 0x196c524 in print_variable_and_value(char const*, symbol*, frame_info_ptr, ui_file*, int) gdb/printcmd.c:2355
    #17 0x1d99ca0 in print_variable_and_value_data::operator()(char const*, symbol*) gdb/stack.c:2308
    #18 0x1dabca0 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::operator()(gdb::fv_detail::erased_callable, char const*, symbol*) const gdb/../gdbsupport/function-view.h:305
    #19 0x1dabd14 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::_FUN(gdb::fv_detail::erased_callable, char const*, symbol*) gdb/../gdbsupport/function-view.h:299
    #20 0x1dab34c in gdb::function_view<void (char const*, symbol*)>::operator()(char const*, symbol*) const gdb/../gdbsupport/function-view.h:289
    #21 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240
    #22 0x1d99790 in iterate_over_block_local_vars(block const*, gdb::function_view<void (char const*, symbol*)>) gdb/stack.c:2259
    #23 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380
    #24 0x1d9afac in info_locals_command(char const*, int) gdb/stack.c:2458
    #25 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95
    #26 0xfe5a2c in cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735
    #27 0x1f03790 in execute_command(char const*, int) gdb/top.c:575
    #28 0x1384080 in command_handler(char const*) gdb/event-top.c:566
    #29 0x1384e2c in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:802
    #30 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104
    #31 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259
    #32 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290
    #33 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195
    #34 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234
    #35 0x1fe9b40 in stdin_event_handler gdb/ui.c:155
    #36 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573
    #37 0x35ff9d8 in gdb_wait_for_event gdbsupport/event-loop.cc:694
    #38 0x35fd284 in gdb_do_one_event(int) gdbsupport/event-loop.cc:264
    #39 0x1768080 in start_event_loop gdb/main.c:408
    #40 0x17684c4 in captured_command_loop gdb/main.c:472
    #41 0x176cfc8 in captured_main gdb/main.c:1342
    #42 0x176d088 in gdb_main(captured_main_args*) gdb/main.c:1361
    #43 0xb73edc in main gdb/gdb.c:39
    #44 0xffff519b09d8 in __libc_start_call_main (/lib64/libc.so.6+0x309d8)
    #45 0xffff519b0aac in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x30aac)
    #46 0xb73c2c in _start (/home/vries/gdb/build/gdb/gdb+0xb73c2c)

0x602000097f58 is located 0 bytes after 8-byte region [0x602000097f50,0x602000097f58)
allocated by thread T0 here:
    #0 0xffff52c65218 in calloc (/lib64/libasan.so.8+0xc5218)
    #1 0xcbc278 in xcalloc gdb/alloc.c:97
    #2 0x35f21e8 in xzalloc(unsigned long) gdbsupport/common-utils.cc:29
    #3 0x20de270 in value::allocate_contents(bool) gdb/value.c:937
    #4 0x20edc08 in value::fetch_lazy() gdb/value.c:4033
    #5 0x20dadc0 in value::entirely_covered_by_range_vector(std::vector<range, std::allocator<range> > const&) gdb/value.c:229
    #6 0xcb2298 in value::entirely_optimized_out() gdb/value.h:560
    #7 0x20ca6fc in value_check_printable gdb/valprint.c:1133
    #8 0x20caa8c in common_val_print_checked(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1182
    #9 0x196c524 in print_variable_and_value(char const*, symbol*, frame_info_ptr, ui_file*, int) gdb/printcmd.c:2355
    #10 0x1d99ca0 in print_variable_and_value_data::operator()(char const*, symbol*) gdb/stack.c:2308
    #11 0x1dabca0 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::operator()(gdb::fv_detail::erased_callable, char const*, symbol*) const gdb/../gdbsupport/function-view.h:305
    #12 0x1dabd14 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::_FUN(gdb::fv_detail::erased_callable, char const*, symbol*) gdb/../gdbsupport/function-view.h:299
    #13 0x1dab34c in gdb::function_view<void (char const*, symbol*)>::operator()(char const*, symbol*) const gdb/../gdbsupport/function-view.h:289
    #14 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240
    #15 0x1d99790 in iterate_over_block_local_vars(block const*, gdb::function_view<void (char const*, symbol*)>) gdb/stack.c:2259
    #16 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380
    #17 0x1d9afac in info_locals_command(char const*, int) gdb/stack.c:2458
    #18 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95
    #19 0xfe5a2c in cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735
    #20 0x1f03790 in execute_command(char const*, int) gdb/top.c:575
    #21 0x1384080 in command_handler(char const*) gdb/event-top.c:566
    #22 0x1384e2c in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:802
    #23 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104
    #24 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259
    #25 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290
    #26 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195
    #27 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234
    #28 0x1fe9b40 in stdin_event_handler gdb/ui.c:155
    #29 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573

SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib64/libasan.so.8+0x6da18) in memmove
...

The error happens when trying to print either variable y or y2:
...
   type Variable_Record (A : Boolean := True) is record
      case A is
         when True =>
            B : Integer;
         when False =>
            C : Float;
            D : Integer;
      end case;
   end record;
   Y  : Variable_Record := (A => True, B => 1);
   Y2 : Variable_Record := (A => False, C => 1.0, D => 2);
...
when the variables are uninitialized.

The error happens only when printing the entire variable:
...
(gdb) p y.a
$2 = 216
(gdb) p y.b
There is no member named b.
(gdb) p y.c
$3 = 9.18340949e-41
(gdb) p y.d
$4 = 1
(gdb) p y
<AddressSanitizer: heap-buffer-overflow>
...

The error happens as follows:
- field a functions as discriminant, choosing either the b, or c+d variant.
- when y.a happens to be set to 216, as above, gdb interprets this as the
  variable having the c+d variant (which is why trying to print y.b fails).
- when printing y, gdb allocates a value, copies the bytes into it from the
  target, and then prints the value.
- gdb allocates the value using the type size, which is 8.  It's 8 because
  that's what the DW_AT_byte_size indicates.  Note that for valid values of a,
  it gives correct results: if a is 0 (c+d variant), size is 12, if a is 1
  (b variant), size is 8.
- gdb tries to print field d, which is at an 8 byte offset, and that results
  in a out-of-bounds access for the allocated 8-byte value.

Fix this by handling this case in value::contents_copy_raw, such that we have:
...
(gdb) p y
$1 = (a => 24, c => 9.18340949e-41,
      d => <error reading variable: access outside bounds of object>)
...

An alternative (additional) fix could be this: in compute_variant_fields_inner
gdb reads the discriminant y.a to decide which variant is active.  It would be
nice to detect that the value (y.a == 24) is not a valid Boolean, and give up
on choosing a variant altoghether.  However, the situation regarding the
internal type CODE_TYPE_BOOL is currently ambiguous (see PR31282) and it's not
possible to reliably decide what valid values are.

The test-case source file gdb.ada/uninitialized-variable-record/parse.adb is
a reduced version of gdb.ada/uninitialized_vars/parse.adb, so it copies the
copyright years.

Note that the test-case needs gcc-12 or newer, it's unsupported for older gcc
versions. [ So, it would be nice to rewrite it into a dwarf assembly
test-case. ]

The test-case loops over all languages.  This is inherited from an earlier
attempt to fix this, which had language-specific fixes (in print_field_values,
cp_print_value_fields, pascal_object_print_value_fields and
f_language::value_print_inner).  I've left this in, but I suppose it's not
strictly necessary anymore.

Tested on x86_64-linux.

PR exp/31258
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31258

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

ld: Add -plugin-save-temps

Add -plugin-save-temps to store plugin intermediate files permanently.
It can be used to exam the final input object files generated from IR
inputs.

* NEWS: Mention -plugin-save-temps.
* ld.h (ld_config_type): Add plugin_save_temps.
* ld.texi: Document -plugin-save-temps.
* ldlex.h (option_values): Add OPTION_PLUGIN_SAVE_TEMPS.
* lexsup.c (ld_options): Add -plugin-save-temps.
(parse_args): Handle OPTION_PLUGIN_SAVE_TEMPS.
* plugin.c (plugin_call_cleanup): Don't call plugin
cleanup_handler for -plugin-save-temps.

PR27597, nios: assertion fail in nios2_elf32_install_imm16

The assertion in nios2_elf32_install_imm16 triggers when the PLT is
twice the maximum allowable size for a branch from PLTn to reach
.PLTresolve, and on no other call to nios2_elf32_install_imm16.  That
makes the assertion completely useless.  We can handle a PIC PLT
exceeding 0x8000 in size by bouncing branches that won't reach through
previous branches.

PR 27597
* elf32-nios2.c (nios2_elf32_install_imm16): Delete BFD_ASSERT.
(nios2_build_one_stub): Don't bother masking value passed to
nios2_elf32_install_imm16.
(nios2_elf32_finish_dynamic_symbol): Likewise.  Handle overflow
of PLTn branch to .PLTresolve by bouncing through prior branches.

Update how-to-make-a-release document to reference new git repository for the documentation

x86/APX: drop stray IgnoreSize

While necessary on the legacy encodings, the EVEX ones don't need it.
Even more so when they're available for 64-bit mode only, when the
legacy encodings have the attribute only for correctly handling things
in 16-bit mode.

x86: don't use VexWIG in SSE2AVX templates

Several years ago it was decided that SSE2AVX templates should not be
sensitive to -mvexwig= (upon my suggestion to consistently make all
sensitive as long as they don't require a specific setting of VEX.W).
Adjust the four that still are, switching to use of Vex128 at the same
time.

x86: drop redundant Xmmword

While e20298da05f2 ("Remove redundant Byte, Word, Dword and Qword from
insn templates") did so for Byte/Word/Dword/Qword, the same kind of
redundancy was left in place for a few 128-bit SIMD operands.

SCFI: correct test names

Having multiple tests with the same name is confusing.

Automatic date update in version.in

x86: Display -msse-check= default as none

Display -msse-check= default as none for "as --help" since its default
is none, not warning.

PR gas/31389
* config/tc-i386.c (md_show_usage): Change -msse-check= default
to none.

S/390: 32-bit PIE undef weak failures

Like 10e7c0457cb7 but for elf32-s390.c

* elf32-s390.c (elf_s390_adjust_dynamic_symbol): Use
UNDEFWEAK_NO_DYNAMIC_RELOC.
(allocate_dynrelocs): Likewise.
(elf_s390_relocate_section): Check resolved_to_zero.
(elf_s390_finish_dynamic_symbol): Don't generate runtime reloc if
UNDEFWEAK_NO_DYNAMIC_RELOC.

Move lookup_name_info creation into basic_lookup_transparent_type

I noticed that basic_lookup_transparent_type calls two different
functions that both proceed to create a lookup_name_info.  It's more
efficient to create this object in the outermost layer possible.
Making this change required a few related changes, resulting in this
patch.

There are still more changes of this sort that could be made.

Regression tested on x86-64 Fedora 38.

objdump, as: add callx support for BPF CPU v1

Albeit not being a currently valid BPF instruction, callx is generated
by both clang and GCC when BPF programs are compiled unoptimized.
Until now, GCC would emit it only whe using the experimental
compiler-testing cpu version xbpf, whereas clang would emit it from
v1.  This patch makes GAS to accept callx also starting with cpu v1.

opcodes/ChangeLog

* bpf-opc.c: Move callx into the v1 BPF CPU variant.

gas/ChangeLog

* testsuite/gas/bpf/indcall-1-pseudoc.d: Do not select xbpf cpu
version.
* testsuite/gas/bpf/indcall-1.d: Likewise.

Make various gas symbol predicates and accessors take const args

* symbols.c (S_IS_FUNCTION, S_IS_EXTERNAL, S_IS_WEAK),
(S_IS_WEAKREFR, S_IS_WEAKREFD, S_IS_COMMON, S_IS_DEFINED),
(S_FORCE_RELOC, S_IS_DEBUG, S_IS_LOCAL, S_IS_STABD),
(symbol_previous, symbol_next, symbol_X_add_number),
(symbol_get_frag, symbol_used_p, symbol_used_in_reloc_p),
(symbol_mri_common_p, symbol_written_p, symbol_removed_p),
(symbol_resolved_p, symbol_resolving_p, symbol_section_p),
(symbol_equated_p, symbol_equated_reloc_p, symbol_constant_p),
(symbol_shadow_p, symbol_same_p): Constify sym args.
* symbols.h: Update prototypes.

Re: elf_backend_finish_dynamic_symbol returning false

Making a bfd_final_link failure noisy requires testsuite changes.

PR28448, Memory leak in function add_symbols(plugin.c)

PR 28448
* plugin.c (add_symbols): bfd_alloc memory for symptrs.  Check
bfd_make_empty_symbol return.

Re: elf_backend_finish_dynamic_symbol returning false

I didn't examine ld testsuite logs properly after cf95b909e2c2.
Replacing one of the "return false" with BFD_ASSERT in
finish_dynamic_symbol was wrong as it causes segmentation faults on
testcases expected to fail.  Revert those changes and instead make
a bfd_final_link failure noisy.

gdb/doc: Fix several typos in GDB documentation

Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
Approved-by: Eli Zaretskii <eliz@gnu.org>
Copyright-paperwork-exempt: yes

PR29785, memory bloat after b43771b045fb

Pathological cases of dwarf info with overlapping duplicate memory
ranges can cause splitting of trie leaf nodes, which in the worst case
will cause memory to increase without bounds.

PR 29785
* dwarf2.c (insert_arange_in_trie): Don't split leaf nodes
unless that reduces number of elements in at least one node.

PR30308, infinite recursion in i386_intel_simplify

This patch exposes the symbol "resolving" flag for use in
i386_intel_simplify, not only preventing infinite recursion on the
testcase in the PR but also more complicated cases like:

 .intel_syntax
 b = a
 a = b
 mov eax, [a]

PR 30308
* symbols.c (symbol_mark_resolving, symbol_clear_resolving),
(symbol_resolving_p): New functions.
* symbols.h: Declare them.
* config/tc-i386-intel.c (i386_intel_simplify): Delete forward
declaration.  Formatting.
(i386_intel_simplify_symbol): Use resolving flag to prevent
infinite recursion.

elf_backend_finish_dynamic_symbol returning false

Returning false from elf_backend_finish_dynamic_symbol will not result
in an error being printed unless bfd_error is set but will result in
the linker exiting with a non-zero status.  If just bfd_error is set
then a generic "final link failed" will result, which doesn't help a
user much.  So elf_backend_finish_dynamic_symbol should print its own
error message whenever returning false, or use BFD_ASSERT or abort to
print assertion failures for conditions that shouldn't occur.

This patch does that, and removes unnecessary "htab != NULL" tests in
elf_backend_finish_dynamic_symbol.  Such tests aren't needed in a
function only called via elf_backend_data.

Automatic date update in version.in

[gdb/dap] Fix exit race

When running test-case gdb.dap/eof.exp, we're likely to get a coredump due to
a segfault in new_threadstate.

At the point of the core dump, the gdb main thread looks like:
...
 (gdb) bt
 #0  0x0000fffee30d2280 in __pthread_kill_implementation () from /lib64/libc.so.6
 #1  0x0000fffee3085800 [PAC] in raise () from /lib64/libc.so.6
 #2  0x00000000007b03e8 [PAC] in handle_fatal_signal (sig=11)
     at gdb/event-top.c:926
 #3  0x00000000007b0470 in handle_sigsegv (sig=11)
     at gdb/event-top.c:976
 #4  <signal handler called>
 #5  0x0000fffee3a4db14 in new_threadstate () from /lib64/libpython3.12.so.1.0
 #6  0x0000fffee3ab0548 [PAC] in PyGILState_Ensure () from /lib64/libpython3.12.so.1.0
 #7  0x0000000000a6d034 [PAC] in gdbpy_gil::gdbpy_gil (this=0xffffcb279738)
     at gdb/python/python-internal.h:787
 #8  0x0000000000ab87ac in gdbpy_event::~gdbpy_event (this=0xfffea8001ee0,
     __in_chrg=<optimized out>) at gdb/python/python.c:1051
 #9  0x0000000000ab9460 in std::_Function_base::_Base_manager<...>::_M_destroy
     (__victim=...) at /usr/include/c++/13/bits/std_function.h:175
 #10 0x0000000000ab92dc in std::_Function_base::_Base_manager<...>::_M_manager
     (__dest=..., __source=..., __op=std::__destroy_functor)
     at /usr/include/c++/13/bits/std_function.h:203
 #11 0x0000000000ab8f14 in std::_Function_handler<...>::_M_manager(...) (...)
     at /usr/include/c++/13/bits/std_function.h:282
 #12 0x000000000042dd9c in std::_Function_base::~_Function_base (this=0xfffea8001c10,
     __in_chrg=<optimized out>) at /usr/include/c++/13/bits/std_function.h:244
 #13 0x000000000042e654 in std::function<void ()>::~function() (this=0xfffea8001c10,
     __in_chrg=<optimized out>) at /usr/include/c++/13/bits/std_function.h:334
 #14 0x0000000000b68e60 in std::_Destroy<std::function<void ()> >(...) (...)
     at /usr/include/c++/13/bits/stl_construct.h:151
 #15 0x0000000000b68cd0 in std::_Destroy_aux<false>::__destroy<...>(...) (...)
     at /usr/include/c++/13/bits/stl_construct.h:163
 #16 0x0000000000b689d8 in std::_Destroy<...>(...) (...)
     at /usr/include/c++/13/bits/stl_construct.h:196
 #17 0x0000000000b68414 in std::_Destroy<...>(...) (...)
     at /usr/include/c++/13/bits/alloc_traits.h:948
 #18 std::vector<...>::~vector() (this=0x2a183c8 <runnables>)
     at /usr/include/c++/13/bits/stl_vector.h:732
 #19 0x0000fffee3088370 in __run_exit_handlers () from /lib64/libc.so.6
 #20 0x0000fffee3088450 [PAC] in exit () from /lib64/libc.so.6
 #21 0x0000000000c95600 [PAC] in quit_force (exit_arg=0x0, from_tty=0)
     at gdb/top.c:1822
 #22 0x0000000000609140 in quit_command (args=0x0, from_tty=0)
     at gdb/cli/cli-cmds.c:508
 #23 0x0000000000c926a4 in quit_cover () at gdb/top.c:300
 #24 0x00000000007b09d4 in async_disconnect (arg=0x0)
     at gdb/event-top.c:1230
 #25 0x0000000000548acc in invoke_async_signal_handlers ()
     at gdb/async-event.c:234
 #26 0x000000000157d2d4 in gdb_do_one_event (mstimeout=-1)
     at gdbsupport/event-loop.cc:199
 #27 0x0000000000943a84 in start_event_loop () at gdb/main.c:401
 #28 0x0000000000943bfc in captured_command_loop () at gdb/main.c:465
 #29 0x000000000094567c in captured_main (data=0xffffcb279d08)
     at gdb/main.c:1335
 #30 0x0000000000945700 in gdb_main (args=0xffffcb279d08)
     at gdb/main.c:1354
 #31 0x0000000000423ab4 in main (argc=14, argv=0xffffcb279e98)
     at gdb/gdb.c:39
...

The direct cause of the segfault is calling PyGILState_Ensure after
calling Py_Finalize.

AFAICT the problem is a race between the gdb main thread and DAP's JSON writer
thread.

On one side, we have the following events:
- DAP's JSON reader thread reads an EOF, and lets DAP's main thread known
  by writing None into read_queue
- DAP's main thread lets DAP's JSON writer thread known by writing None into
  write_queue
- DAP's JSON writer thread sees the None in its queue, and calls
  send_gdb("quit")
- a corresponding gdbpy_event is deposited in the runnables vector, to be
  run by the gdb main thread

On the other side, we have the following events:
- the gdb main thread receives a SIGHUP
- the corresponding handler calls quit_force, which calls do_final_cleanups
- one of the final cleanups is finalize_python, which calls Py_Finalize
- quit_force calls exit, which triggers the exit handlers
- one of the exit handlers is the destructor of the runnables vector
- destruction of the vector triggers destruction of the remaining element
- the remaining element is a gdbpy_event, and the destructor (indirectly)
  calls PyGILState_Ensure

It's good to note that both events (EOF and SIGHUP) are caused by this line in
the test-case:
...
catch "close -i $gdb_spawn_id"
...
where "expect close" closes the stdin and stdout file descriptors, which
causes the SIGHUP to be send.

So, for the system I'm running this on, the send_gdb("quit") is actually not
needed.

I'm not sure if we support any systems where it's actually needed.

Fix this by removing the send_gdb("quit").

Tested on aarch64-linux.

PR dap/31306
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31306

gdb: Reformat amd64_dwarf_reg_to_regnum

Reformat amd64_dwarf_reg_to_regnum:

@@ -254,8 +254,7 @@ amd64_dwarf_reg_to_regnum (struct gdbarch *gdbarch, int reg)
   if (reg >= 0 && reg < amd64_dwarf_regmap_len)
     regnum = amd64_dwarf_regmap[reg];

-  if (ymm0_regnum >= 0
-    && i386_xmm_regnum_p (gdbarch, regnum))
+  if (ymm0_regnum >= 0 && i386_xmm_regnum_p (gdbarch, regnum))
     regnum += ymm0_regnum - I387_XMM0_REGNUM (tdep);

to remove the misaligned line.

Use typedef in definition of warning_hook

This changes the global 'warning_hook' to use the warning_hook_handler
typedef in its definition.  This makes it a little easier to change
the type, should that be needed.

arc: Put DBNZ instruction to a separate class

DBNZ instruction decrements its source register operand, and if
the result is non-zero it branches to the location defined by a signed
half-word displacement operand.

DBNZ instruction is in BRANCH class as other branch instrucitons
like B, Bcc, etc. However, DBNZ is the only branch instruction
that stores a branch offset in the second operand. Thus it must
be placed in a distinct class and treated differently.

For example, current logic of arc_insn_get_branch_target in GDB
assumes that a branch offset is always stored in the first operand
for BRANCH class and it's wrong for DBNZ.

include/ChangeLog:

2024-02-14  Yuriy Kolerov  <ykolerov@synopsys.com>

* opcode/arc.h (enum insn_class_t): Add DBNZ class.

opcodes/ChangeLog:

2024-02-14  Yuriy Kolerov  <ykolerov@synopsys.com>

* arc-tbl.h (dbnz): Use "DBNZ" class.
* arc-dis.c (arc_opcode_to_insn_type): Handle "DBNZ" class.

gas/ChangeLog:

2024-02-14  Yuriy Kolerov  <ykolerov@synopsys.com>

* config/tc-arc.c (is_br_jmp_insn_p): Add check against "DBNZ".

[gdb/testsuite] Fix another fail and tcl error in gdb.dap/sources.exp

With gdb.dap/sources.exp on aarch64-linux, I'm running into:
...
{"request_seq": 3, "type": "response", "command": "loadedSources", \
  "success": false, "message": "notStopped", "seq": 7}Content-Length: 92^M
^M
{"type": "event", "event": "thread", \
  "body": {"reason": "started", "threadId": 1}, \
  "seq": 8}FAIL: gdb.dap/sources.exp: loadedSources success
ERROR: tcl error sourcing gdb.dap/sources.exp.
ERROR: tcl error code TCL LOOKUP DICT body
ERROR: key "body" not known in dictionary
    while executing
"dict get [lindex $obj 0] body sources"
...

These are the same type of tcl error and FAIL I just fixed for a later
request in the same test-case.

Fix this by:
- moving the wait-for-stop to before the loadedSources request to fix the
  FAIL, and
- checking for $obj == "" to fix the tcl error.

Also make the code a bit less indented and more readable by wrapping the tests
in a proc, allowing the use of return to bail out, while still running
dap_shutdown afterwards.

Approved-By: Tom Tromey <tom@tromey.com>
Tested on aarch64-linux.

Automatic date update in version.in

arc: Don't use multiline in arc-disassembler-options.exp test

Breaking a TCL string to several lines leads to adding of extra
symbols to the resulting expect string. In turn, this leads to
failing of all test cases in gdb.arch/arc-disassembler-options.exp
testsuite. It's necessary to use multi_line function in such
cases.

Approved-By: Tom Tromey <tom@tromey.com>

[gdb/testsuite] Fix fail in gdb.dap/sources.exp

With test-case gdb.dap/sources.exp, I run into:
...
{"request_seq": 4, "type": "response", "command": "source", \
  "success": false, "message": "notStopped", \
  "seq": 11}FAIL: gdb.dap/sources.exp: get source success
...

The fail happens because the request races with the stopping at main as
requested by:
...
if {[dap_launch $testfile stop_at_main 1] == ""} {
...

Fix this by waiting for the stop, in the same way that is done in other
test-cases that use stop_at_main.

Tested on x86_64-linux.

Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31374
https://sourceware.org/bugzilla/show_bug.cgi?id=31374

sim: riscv: Add support for compressed integer instructions

Added support for simulation of compressed integer instruction set ("c").
Added test file sim/testsuite/riscv/c-ext.s to test compressed instructions.
The compressed instructions are available for models implementing C extension.
Such as RV32IC, RV64IC, RV32GC, RV64GC etc.

Approved-By: Andrew Burgess <aburgess@redhat.com>

[gdb/testsuite] Fix tcl error in gdb.dap/sources.exp

With test-case gdb.dap/sources.exp, I run into:
...
{"request_seq": 4, "type": "response", "command": "source", \
  "success": false, "message": "notStopped", \
  "seq": 11}FAIL: gdb.dap/sources.exp: get source success
ERROR: tcl error sourcing gdb.dap/sources.exp.
ERROR: key "body" not known in dictionary
...

The FAIL has been filed as PR dap/31374.

The ERROR happens because after the FAIL, dap_check_request_and_response
returns "", and the test-case doesn't check for that.

Fix this by checking for $obj != "" in the test-case.

Tested on x86_64-linux.

[gdb/tdep] Fix reverse execution of LDR(immediate) T4

When running test-case gdb.reverse/func-map-to-same-line.exp on arm-linux with
target board unix/-mthumb, we run into:
...
(gdb) reverse-step
func2 () at func-map-to-same-line.c:26
26 {
(gdb) FAIL: gdb.reverse/func-map-to-same-line.exp: \
  column_info_flag=column-info: step-test: reverse-step into func2
...

The FAIL is caused by incorrect recording of this insn:
...
4f6:   f85d 7b04       ldr.w   r7, [sp], #4
...

The insn updates the sp, but we don't record this:
...
$ gdb -q -batch func-map-to-same-line \
  -ex "b *func2+8" \
  -ex run \
  -ex record \
  -ex "set debug record 2" \
  -ex stepi
Breakpoint 1 at 0x4f6: file func-map-to-same-line.c, line 27.

Breakpoint 1, 0xaaaaa4f6 in func2 () at func-map-to-same-line.c:27
27 } /* END FUNC2 */
Process record: arm_process_record addr = 0xaaaaa4f6
Process record: add register num = 15 to record list.
Process record: record_full_arch_list_add 0xabc6c460.
Process record: add register num = 7 to record list.
Process record: record_full_arch_list_add 0xabc3b868.
Process record: add register num = 25 to record list.
...
[ Note that sp is r13, and we see here only r15 (pc), r7, and r25 (ps). ]

The problem is that the specific insn, an LDR(immediate) T4, is not handled in
thumb2_record_ld_word.

Fix this by detecting the insn in thumb2_record_ld_word, and recording the
updated base register.

Tested on arm-linux.

Reported-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/31278
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31278

Automatic date update in version.in

Introduce bfd_print_error function

gdb likes to control its own output; for example, this is important
for gdb's pager, and for logging.  While BFD provides a way to
intercept error output, via bfd_set_error_handler, it turns out to be
difficult for this function to truly generate the desired output in a
gdb-friendly way -- the error handler is expected to implement some
BFD printf format extensions.

This patch introduces a new function that an error handler can use to
format the text.  This way, gdb can set the error handler and arrange
for the output to be displayed as it likes.

* bfd.c (bfd_print_callback): Rename from print_func.  Move into
comment.
(_bfd_doprnt): Update.
(bfd_print_error): New function.
(error_handler_fprintf, error_handler_sprintf): Use
bfd_print_error.
* bfd-in2.h: Rebuild.

Do not call fputc from _bfd_doprnt

I noticed that _bfd_doprnt can unconditionally call fputc.  However,
when called from error_handler_sprintf, this will likely result in a
crash, as the stream argument does not actually point to a FILE.

* bfd.c (_bfd_doprnt): Do not call fputc.

[gdb] Re-format dap/startup.py with black

Commit 433ae2c2458 ("[gdb/dap] Catch and log exceptions in dap threads") made
some changes to gdb/python/lib/gdb/dap/startup.py.

Re-format it with black.

[gdb/dap] Catch and log exceptions in dap threads

When running test-case gdb.dap/eof.exp, it occasionally coredumps.

The thread triggering the coredump is:
...
 #0  0x0000ffff42bb2280 in __pthread_kill_implementation () from /lib64/libc.so.6
 #1  0x0000ffff42b65800 [PAC] in raise () from /lib64/libc.so.6
 #2  0x00000000007b03e8 [PAC] in handle_fatal_signal (sig=11)
     at gdb/event-top.c:926
 #3  0x00000000007b0470 in handle_sigsegv (sig=11)
     at gdb/event-top.c:976
 #4  <signal handler called>
 #5  0x0000000000606080 in cli_ui_out::do_message (this=0xffff2f7ed728, style=...,
     format=0xffff0c002af1 "%s", args=...) at gdb/cli-out.c:232
 #6  0x0000000000ce6358 in ui_out::call_do_message (this=0xffff2f7ed728, style=...,
     format=0xffff0c002af1 "%s") at gdb/ui-out.c:584
 #7  0x0000000000ce6610 in ui_out::vmessage (this=0xffff2f7ed728, in_style=...,
     format=0x16f93ea "", args=...) at gdb/ui-out.c:621
 #8  0x0000000000ce3a9c in ui_file::vprintf (this=0xfffffbea1b18, ...)
     at gdb/ui-file.c:74
 #9  0x0000000000d2b148 in gdb_vprintf (stream=0xfffffbea1b18, format=0x16f93e8 "%s",
     args=...) at gdb/utils.c:1898
 #10 0x0000000000d2b23c in gdb_printf (stream=0xfffffbea1b18, format=0x16f93e8 "%s")
     at gdb/utils.c:1913
 #11 0x0000000000ab5208 in gdbpy_write (self=0x33fe35d0, args=0x342ec280, kw=0x345c08b0)
     at gdb/python/python.c:1464
 #12 0x0000ffff434acedc in cfunction_call () from /lib64/libpython3.12.so.1.0
 #13 0x0000ffff4347c500 [PAC] in _PyObject_MakeTpCall ()
     from /lib64/libpython3.12.so.1.0
 #14 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault ()
    from /lib64/libpython3.12.so.1.0
 #15 0x0000ffff434d8cd0 [PAC] in method_vectorcall () from /lib64/libpython3.12.so.1.0
 #16 0x0000ffff434b9824 [PAC] in PyObject_CallOneArg () from /lib64/libpython3.12.so.1.0
 #17 0x0000ffff43557674 [PAC] in PyFile_WriteObject () from /lib64/libpython3.12.so.1.0
 #18 0x0000ffff435577a0 [PAC] in PyFile_WriteString () from /lib64/libpython3.12.so.1.0
 #19 0x0000ffff43465354 [PAC] in thread_excepthook () from /lib64/libpython3.12.so.1.0
 #20 0x0000ffff434ac6e0 [PAC] in cfunction_vectorcall_O ()
    from /lib64/libpython3.12.so.1.0
 #21 0x0000ffff434a32d8 [PAC] in PyObject_Vectorcall () from /lib64/libpython3.12.so.1.0
 #22 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault ()
    from /lib64/libpython3.12.so.1.0
 #23 0x0000ffff434d8d88 [PAC] in method_vectorcall () from /lib64/libpython3.12.so.1.0
 #24 0x0000ffff435e0ef4 [PAC] in thread_run () from /lib64/libpython3.12.so.1.0
 #25 0x0000ffff43591ec0 [PAC] in pythread_wrapper () from /lib64/libpython3.12.so.1.0
 #26 0x0000ffff42bb0584 [PAC] in start_thread () from /lib64/libc.so.6
 #27 0x0000ffff42c1fd4c [PAC] in thread_start () from /lib64/libc.so.6
...

The direct cause for the coredump seems to be that cli_ui_out::do_message
is trying to write to a stream variable which does not look sound:
...
(gdb) p *stream
$8 = {_vptr.ui_file = 0x0, m_applied_style = {m_foreground = {m_simple = true, {
        m_value = 0, {m_red = 0 '\000', m_green = 0 '\000', m_blue = 0 '\000'}}},
    m_background = {m_simple = 32, {m_value = 65535, {m_red = 255 '\377',
          m_green = 255 '\377', m_blue = 0 '\000'}}},
    m_intensity = (unknown: 0x438fe710), m_reverse = 255}}
...

The string that is being printed is:
...
(gdb) p str
$9 = "Exception in thread "
...
so AFAICT this is a DAP thread running into an exception and trying to print
it.

If we look at the state of gdb's main thread, we have:
...
 #0  0x0000ffff42bac914 in __futex_abstimed_wait_cancelable64 () from /lib64/libc.so.6
 #1  0x0000ffff42bafb44 [PAC] in pthread_cond_timedwait@@GLIBC_2.17 ()
    from /lib64/libc.so.6
 #2  0x0000ffff43466e9c [PAC] in take_gil () from /lib64/libpython3.12.so.1.0
 #3  0x0000ffff43484fe0 [PAC] in PyEval_RestoreThread ()
     from /lib64/libpython3.12.so.1.0
 #4  0x0000000000ab8698 [PAC] in gdbpy_allow_threads::~gdbpy_allow_threads (
     this=0xfffffbea1cf8, __in_chrg=<optimized out>)
     at gdb/python/python-internal.h:769
 #5  0x0000000000ab2fec in execute_gdb_command (self=0x33fe35d0, args=0x34297b60,
     kw=0x34553d20) at gdb/python/python.c:681
 #6  0x0000ffff434acedc in cfunction_call () from /lib64/libpython3.12.so.1.0
 #7  0x0000ffff4347c500 [PAC] in _PyObject_MakeTpCall ()
     from /lib64/libpython3.12.so.1.0
 #8  0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault ()
    from /lib64/libpython3.12.so.1.0
 #9  0x0000ffff4353bce8 [PAC] in _PyObject_VectorcallTstate.lto_priv.3 ()
    from /lib64/libpython3.12.so.1.0
 #10 0x0000000000ab87fc [PAC] in gdbpy_event::operator() (this=0xffff14005900)
     at gdb/python/python.c:1061
 #11 0x0000000000ab93e8 in std::__invoke_impl<void, gdbpy_event&> (__f=...)
     at /usr/include/c++/13/bits/invoke.h:61
 #12 0x0000000000ab9204 in std::__invoke_r<void, gdbpy_event&> (__fn=...)
     at /usr/include/c++/13/bits/invoke.h:111
 #13 0x0000000000ab8e90 in std::_Function_handler<..>::_M_invoke(...) (...)
     at /usr/include/c++/13/bits/std_function.h:290
 #14 0x000000000062e0d0 in std::function<void ()>::operator()() const (
     this=0xffff14005830) at /usr/include/c++/13/bits/std_function.h:591
 #15 0x0000000000b67f14 in run_events (error=0, client_data=0x0)
     at gdb/run-on-main-thread.c:76
 #16 0x000000000157e290 in handle_file_event (file_ptr=0x33dae3a0, ready_mask=1)
     at gdbsupport/event-loop.cc:573
 #17 0x000000000157e760 in gdb_wait_for_event (block=1)
     at gdbsupport/event-loop.cc:694
 #18 0x000000000157d464 in gdb_do_one_event (mstimeout=-1)
     at gdbsupport/event-loop.cc:264
 #19 0x0000000000943a84 in start_event_loop () at gdb/main.c:401
 #20 0x0000000000943bfc in captured_command_loop () at gdb/main.c:465
 #21 0x000000000094567c in captured_main (data=0xfffffbea23e8)
     at gdb/main.c:1335
 #22 0x0000000000945700 in gdb_main (args=0xfffffbea23e8)
     at gdb/main.c:1354
 #23 0x0000000000423ab4 in main (argc=14, argv=0xfffffbea2578)
     at gdb/gdb.c:39
...

AFAIU, there's a race between the two threads on gdb_stderr:
- the DAP thread samples the gdb_stderr value, and uses it a bit later to
  print to
- the gdb main thread changes the gdb_stderr value forth and back,
  using a temporary value for string capture purposes

The non-sound stream value is caused by gdb_stderr being sampled while
pointing to a str_file object, and used once the str_file object is already
destroyed.

The error here is that the DAP thread attempts to print to gdb_stderr.

Fix this by adding a thread_wrapper that:
- catches all exceptions and logs them to dap.log, and
- while we're at it, logs when exiting
and using the thread_wrapper for each DAP thread.

Tested on aarch64-linux.

Approved-By: Tom Tromey <tom@tromey.com>

Fix DAP launch and configurationDone requests

Co-workers at AdaCore pointed out that gdb incorrectly implements the
DAP launch and configurationDone requests.  It's somewhat strange to
me, but the spec does in fact say that configuration requests should
occur before the executable is known to gdb.  This was clarified in
this bug report against the spec:

    https://github.com/microsoft/debug-adapter-protocol/issues/452

Fixing 'launch' to start the inferior was straightforward, but this
then required some changes to how breakpoints are handled.  In
particular, now gdb will emit the "pending" reason on a breakpoint,
and will suppress breakpoint events during breakpoint setting.

Clean up suppress_new_breakpoint_event

Kévin pointed out that suppress_new_breakpoint_event would do the
wrong thing if it happened to be used reentrantly.  While I don't
think this can happen, it's also easy and clearly better to make it
robust.

Export dap_initialize

This changes the test suite to export dap_initialize.

gdb: re-format Python files with black 24.1.1

New year, new black version.

Change-Id: I664601e6dd255358063e15f6d73bc5f02c8f2b9d

Add support to readelf for the PT_OPENBSD_SYSCALLS segment type.

binutils * readelf.c (get_segment_type): Handle PT_OPENBSD_SYSCALLS segment type.
include  * elf/common.h (PT_OPENBSD_SYSCALLS): Define.

rs6000, unwind-on-each-instruction fix.

The function rs6000_epilogue_frame_cache assumes the LR and gprs have been
restored.  In fact register r31 and the link register, lr, may not have
been restored yet.  This patch adds support to store the lr and gpr
register unrolling rules in the cache.  The LR and GPR values can now be
unrolled correctly.

Patch fixes all 10 regresion test failures for the unwind-on-each-insn.exp.

remote.c: Make packet_check_result return a structure

packet_check_result currently returns an packet_result enum.
If GDB will recieve an error in a format E.errtext, which
is possible for some q packets, such errtext is lost if
treated by packet_check_result.
Introduce a new structure which bundles enum packet_result
with possible error message or error code returned by
the GDBserver.
I plan to make more GDBserver response checking functions to use
packet_check_result to make remote.c code more consistent.
This will also allow to use E.errtext more in the future.

Beside adding the unit test, I tested this by modifying
store_registers_using_G function to get an error message:

[remote] Sending packet: $GG00000000 ...

gdbserver: Wrong sized register packet (expected 1792 bytes, got 1793)
gdbserver: Invalid hex digit 71
Killing process(es): 1104002
[remote] Packet received: E01
Could not write registers; remote failure reply '01'

Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

Automatic date update in version.in

Fix crash when calling Frame.static_link

If you try to call Frame.static_link for a frame without debug info,
gdb crashes:
```
Temporary breakpoint 1, 0x000000013f821650 in main ()
(gdb) py print(gdb.selected_frame().static_link())

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```

The problem was a missing check if get_frame_block returns nullptr
inside frame_follow_static_link.

With this, it works:
```
Temporary breakpoint 1, 0x000000013f941650 in main ()
(gdb) py print(gdb.selected_frame().static_link())
None
```

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31366
Approved-By: Tom Tromey <tom@tromey.com>

Automatic date update in version.in

gdb/python: fix 'set python ignore-environment' white space

I noticed that the help text for set/show python ignore-environment
was messed up, some lines had unwanted leading white space, like this:

  (gdb) help set python ignore-environment
  Set whether the Python interpreter should ignore environment variables.
   When enabled GDB's Python interpreter will ignore any Python related
          flags in the environment.  This is equivalent to passing `-E' to a
          python executable.
  (gdb)

This has been present since the ignore-environment setting was added
in commit:

  commit edeaceda7b2f33b2c3bf78c732e67f3188e7f0b9
  Date:   Thu Aug 27 16:53:13 2020 +0100

      gdb: startup commands to control Python extension language

Fixed in this commit.

Automatic date update in version.in

Allow value repeat operator on references

Currently it's not possible to use the value repeat operator on references:
```
print ((int &) v_int_array_init[0])@2
Only values in memory can be extended with '@'.
```

This seems like an unnecessary restriction, since it also prevents
its use on iterators (which was the original reported problem):
```
(gdb) p *it@2
Only values in memory can be extended with '@'.
```

So this converts any references to the referenced value in value_repeat,
making this possible:
```
print ((int &) v_int_array_init[0])@2
$1 = {10, 20}
(gdb) p *it@2
$2 = {1, 2}
```

Approved-by: Kevin Buettner <kevinb@redhat.com>

PowerPC: Add support for Power11 options

binutils/
* doc/binutils.texi (PowerPC -M option): Mention power11 and pwr11.

gas/
* config/tc-ppc.c: (md_show_usage): Mention -mpower11 and -mpwr11.
* doc/c-ppc.texi: Likewise.

opcodes/
* ppc-dis.c (ppc_opts): Add "power11" and "pwr11" entries.
(powerpc_init_dialect): Default to "power11".

gdb: remove unnecessary nullptr check in remove_user_added_objfile

Since commit 74daa597e74 ("gdb: add all_objfiles_removed observer"), the
objfile passed to the free_objfile observable can't be nullptr.

Change-Id: If215aa051ab43c068b11746938022c7efca09caa
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: add program_space parameter to clear_solib

Make the current_program_space reference bubble up one level.

Remove one unnecessary declaration of clear_solib.

Change-Id: I234e2c8c0b71713364fc7b76cee2bee2b026bd6d
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: add program_space parameter to disable_breakpoints_in_shlibs

Make the current_program_space reference bubble up one level.

Change-Id: Ide917aa306bff1872d961244901d79f65d2da62e
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: add inferior parameter to breakpoint_init_inferior

By inspection, I believe that breakpoint_init_inferior doesn't call
anything that relies on the current program space or inferior.  So,
add an inferior parameter, to make the current inferior / program space
references bubble up one level.

Change-Id: Ib07b7a6d360e324f6ae1aa502dd314b8cce421b7
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: add program_space parameter to mark_breakpoints_out

Make the current_program_space reference bubble up one level.

Change-Id: Idc8ed78d23bf3bb2969f6963d8cc049f26901c29
Approved-By: Andrew Burgess <aburgess@redhat.com>

Fix crash in aarch64-linux gdbserver

Since commit 393a6b5947d0 ("Thread options & clone events (Linux
GDBserver)"), aarch64-linux gdbserver crashes when the inferior
vforks.  This happens in aarch64_get_debug_reg_state:

  struct process_info *proc = find_process_pid (pid);

  return &proc->priv->arch_private->debug_reg_state;

Here, find_process_pid returns nullptr -- the new inferior hasn't yet
been created in linux_process_target::handle_extended_wait.

This patch fixes the problem by having
linux_process_target::handle_extended_wait create the child process
earlier, before the child LWP is created.  This is what the function
did before it was reorganized by the commit referred above.

Change-Id: Ib8b3a2e6048c3ad2b91a92ea4430da507db03c50
Co-Authored-By: Tom Tromey <tromey@adacore.com>

x86/APX: with REX2 map 1 doesn't "chain" to maps 2 or 3

Don't wander into three_byte_table[] when REX2 is present.

While there also eliminate related confusion when accessing
dis386_twobyte[]: There's nothing 3-byte-ish involved there. Dropping
the odd variable gets things better in sync with 1-byte handling as
well.

x86/APX: V{BROADCAST,EXTRACT,INSERT}{F,I}128 can also be expressed

Interestingly unlike VROUND{P,S}{S,D} and VPERM{F,I}128 they weren't
even present in the x86-64-apx-egpr-inval testcase, hence why I
overlooked that these can actually be encoded, (again) using suitable
AVX512 counterparts.

While there also "modernize" the adjacent AVX/AVX2 entries.

x86/APX: VROUND{P,S}{S,D} encodings require AVX512{F,VL}

In eea4357967b6 ("x86/APX: VROUND{P,S}{S,D} can generally be encoded") I
failed to add the AVX512* ISA dependency of the two new entries.

x86: change type of Dwarf2 register numbers in register table

Already the %bnd<N> registers used numbers beyond 127, and eGPR ones are
all out of reach for "signed char", at least when CHAR_BITS=8. Switch to
"unsigned char", covering appropriately in places where the value
returned for "none" actually matters (in tc_x86_parse_to_dw2regnum()
this is actually achieved by altering how X_op is set).

gas: scfi: fix failing test on Solaris2

It has been observed that the run of scfi-unsupported-1 test with --x32
arg on a Solaris2 x86_64 system fails:

Executing on host: sh -c {../as-new  --x32 --scfi=experimental \
          <...>/scfi-unsupported-1.s 2>&1}  /dev/null dump.out (timeout = 300)
Assembler messages:
Fatal error: no compiled in support for 32bit x86_64
regexp_diff match failure
regexp "^Fatal error: SCFI is not supported for this ABI$"
line   "Fatal error: no compiled in support for 32bit x86_64"
FAIL: x86_64 scfi-unsupported-1

Fix the above by adding a check for --x32 support before running the
test.  While at it, also include a similar check for --32 support.

gas/testsuite/
* gas/scfi/x86_64/scfi-x86-64.exp: Add gas_x32_check and
gas_32_check.  Conditionalize the execution of affected
testcases.

PR 14962 testcase xcoff failure

Like https://sourceware.org/pipermail/binutils/2002-August/021279.html
but for symbols defined in an xcoff object but then made absolute by a
linker script.

* xcofflink.c (xcoff_link_input_bfd): Set n_scnum correctly
for symbols made absolute by a linker script.

Automatic date update in version.in