Remove old gdb_bfd_openr_iovec

This removes the old gdb_bfd_openr_iovec entirely.  I think any new
code should use the type-safe approach.

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

Convert solib-rocm to new type-safe gdb_bfd_openr_iovec

This converts the solib-rocm BFD iovec implementations to the new
type-safe gdb_bfd_openr_iovec.  They were already essentially using
this approach, just without the type-safe wrapper.

Thanks to Lancelot Six for testing and fixing this patch.

Co-Authored-By: Lancelot Six <lancelot.six@amd.com>
Acked-by: Lancelot Six <lancelot.six@amd.com>
Reviewed-By: Lancelot Six <lancelot.six@amd.com>

Convert minidebug to new type-safe gdb_bfd_openr_iovec

This converts the minidebug BFD iovec implementation to the new
type-safe gdb_bfd_openr_iovec.

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

Convert target fileio to new type-safe gdb_bfd_openr_iovec

This converts the target fileio BFD iovec implementation to use the
new type-safe gdb_bfd_openr_iovec.

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

Convert mem_bfd_iovec to new type-safe gdb_bfd_openr_iovec

This converts the mem_bfd_iovec / target_buffer code to use the new
type-safe gdb_bfd_openr_iovec.

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

Small constructor change to target_buffer

This changes the target_buffer constructor to initialize m_filename
rather than assign to it.

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

Introduce type-safe variant of gdb_bfd_openr_iovec

This patch adds a new, type-safe variant of gdb_bfd_openr_iovec.  In
this approach, the underlying user data is simply an object, the
callbacks are methods, and the "open" function is a function view.
Nothing uses this new code yet.

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

gdb: use reopen_exec_file from reread_symbols

This commit fixes an issue that was discovered while writing the tests
for the previous commit.

I noticed that, when GDB restarts an inferior, the executable_changed
event would trigger twice.  The first notification would originate
from:

  #0  exec_file_attach (filename=0x4046680 "/tmp/hello.x", from_tty=0) at ../../src/gdb/exec.c:513
  #1  0x00000000006f3adb in reopen_exec_file () at ../../src/gdb/corefile.c:122
  #2  0x0000000000e6a3f2 in generic_mourn_inferior () at ../../src/gdb/target.c:3682
  #3  0x0000000000995121 in inf_child_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/inf-child.c:192
  #4  0x0000000000995cff in inf_ptrace_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/inf-ptrace.c:125
  #5  0x0000000000a32472 in linux_nat_target::mourn_inferior (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3609
  #6  0x0000000000e68a40 in target_mourn_inferior (ptid=...) at ../../src/gdb/target.c:2761
  #7  0x0000000000a323ec in linux_nat_target::kill (this=0x2fe95c0 <the_amd64_linux_nat_target>) at ../../src/gdb/linux-nat.c:3593
  #8  0x0000000000e64d1c in target_kill () at ../../src/gdb/target.c:924
  #9  0x00000000009a19bc in kill_if_already_running (from_tty=1) at ../../src/gdb/infcmd.c:328
  #10 0x00000000009a1a6f in run_command_1 (args=0x0, from_tty=1, run_how=RUN_STOP_AT_MAIN) at ../../src/gdb/infcmd.c:381
  #11 0x00000000009a20a5 in start_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:527
  #12 0x000000000068dc5d in do_simple_func (args=0x0, from_tty=1, c=0x35c7200) at ../../src/gdb/cli/cli-decode.c:95

While the second originates from:

  #0  exec_file_attach (filename=0x3d7a1d0 "/tmp/hello.x", from_tty=0) at ../../src/gdb/exec.c:513
  #1  0x0000000000dfe525 in reread_symbols (from_tty=1) at ../../src/gdb/symfile.c:2517
  #2  0x00000000009a1a98 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_STOP_AT_MAIN) at ../../src/gdb/infcmd.c:398
  #3  0x00000000009a20a5 in start_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:527
  #4  0x000000000068dc5d in do_simple_func (args=0x0, from_tty=1, c=0x35c7200) at ../../src/gdb/cli/cli-decode.c:95

In the first case the call to exec_file_attach first passes through
reopen_exec_file.  The reopen_exec_file performs a modification time
check on the executable file, and only calls exec_file_attach if the
executable has changed on disk since it was last loaded.

However, in the second case things work a little differently.  In this
case GDB is really trying to reread the debug symbol.  As such, we
iterate over the objfiles list, and for each of those we check the
modification time, if the file on disk has changed then we reload the
debug symbols from that file.

However, there is an additional check, if the objfile has the same
name as the executable then we will call exec_file_attach, but we do
so without checking the cached modification time that indicates when
the executable was last reloaded, as a result, we reload the
executable twice.

In this commit I propose that reread_symbols be changed to
unconditionally call reopen_exec_file before performing the objfile
iteration.  This will ensure that, if the executable has changed, then
the executable will be reloaded, however, if the executable has
already been recently reloaded, we will not reload it for a second
time.

After handling the executable, GDB can then iterate over the objfiles
list and reload them in the normal way.

With this done I now see the executable reloaded only once when GDB
restarts an inferior, which means I can remove the kfail that I added
to the gdb.python/py-exec-file.exp test in the previous commit.

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

gdb/python: make the executable_changed event available from Python

This commit makes the executable_changed observable available through
the Python API as an event.  There's nothing particularly interesting
going on here, it just follows the same pattern as many of the other
Python events we support.

The new event registry is called events.executable_changed, and this
emits an ExecutableChangedEvent object which has two attributes, a
gdb.Progspace called 'progspace', this is the program space in which
the executable changed, and a Boolean called 'reload', which is True
if the same executable changed on disk and has been reloaded, or is
False when a new executable has been loaded.

One interesting thing did come up during testing though, you'll notice
the test contains a setup_kfail call.  During testing I observed that
the executable_changed event would trigger twice when GDB restarted an
inferior.  However, the ExecutableChangedEvent object is identical for
both calls, so the wrong information is never sent out, we just see
one too many events.

I tracked this down to how the reload_symbols function (symfile.c)
takes care to also reload the executable, however, I've split fixing
this into a separate commit, so see the next commit for details.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb: pass more arguments to the executable_changed observer

This commit continues the work of the previous few commits.

My goal is to expose the executable_changed observer through the
Python API as an event.

At this point adding executable_changed as an event to the Python API
is trivial, but before I do that I would like to add some additional
arguments to the observable, which currently has no arguments at all.

The new arguments I wish to add are:

 1. The program_space in which the executable was changed, and

 2. A boolean flag that will indicate if the executable changed to a
 whole new path, or if GDB just spotted that the executable changed on
 disk (e.g. the user recompiled the executable).

In this commit I change the signature of the observable and then pass
the arguments through at the one place where this observable is
notified.

As there are (currently) no users of this observable nothing else
needs updating.  In the next commit I'll add a listener for this
observable in the Python code, and expose this as an event in the
Python API.

Additionally, with this change, it should be possible to update the
insight debugger to make use of this observable rather than using the
deprecated_exec_file_display_hook (as it currently does), which will
then allow this hook to be removed from GDB.

There should be no user visible changes after this commit.

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

gdb: remove unnecessary notification of executable_changed observer

This commit continues the work of the previous two commits.

My goal, in the next couple of commits, is to expose the
executable_changed observable in the Python API as an event.  However,
before I do that I want to remove the use of the executable_changed
observable from the reread_symbols function in symfile.c as this use
isn't directly associated with a change of the executable file, and so
seems wrong.

In the previous two commits I have removed all users of the
executable_changed observer as I believe those users can, and should,
actually be listening for the new_objfile observable instead, so now
there are no users of the executable_changed observable.

As such, I think removing the use of executable_changed from the
function reread_symbols is perfectly safe, and correct.  At this point
the executable has not been changed, so we shouldn't be sending an
executable_changed notification, and, as there is nobody listening to
this observable, we can't break anything by removing this call.

There should be no user visible changes after this commit.

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

gdb: remove final user of the executable_changed observer

This commit continues with the task started in the previous commit,
and is similar in many ways.

The goal of the next couple of commits is to expose the
executable_changed observable in the Python API as an event.  Before I
do this I would like to remove the additional call to the
executable_changed observable which can be found in the reread_symbols
function in the symfile.c file, as I don't believe that this use
actually corresponds to a change in the current executable.

The previous commit removed one user of the executable_changed
observable and replaced it with a new_obfile observer instead, and
this commit does the same thing.

In auxv.c we use the executable_changed observable to call
invalidate_auxv_cache, which then calls:

  invalidate_auxv_cache_inf (current_inferior ());

The auxv cache is already (additionally) cleared when an inferior
exits and when an inferior appears.

As with the previous commit, I think we can safely replace the use of
the executable_changed observable with a use of the new_obfile
observable.  All the tests still pass, and with some locally placed
printf calls, I think that the cache is still being cleared in all the
cases that should matter.

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

gdb: remove one user of the executable changed observer

My goal for the next few commits is to expose the executable_changed
observable from the Python API.

However, there is call to the executable_changed observable in the
reread_symbols function (in symfile.c), and this doesn't actually
correspond to the executable changing.  My idea then, is to remove
this use of the executable_changed observable, but, before I can do
that, I need to check that nothing is going to break, and that
requires my to think about the current users of this observable.

One current user of executable_changed is in symtab.c.  We add an
executable_changed observer that calls:

  set_main_name (nullptr, language_unknown);

to discard all information about the main function when the executable
changes.

However, changing the executable doesn't actually change the debug
information.  The debug information changes when the symbol-file
changes, so I think this observer is in slightly the wrong place.

The new_objfile observable is (unfortunately) overloaded, it is called
when a new objfile is loaded, and also (when its argument is nullptr),
when all debug information should be discarded.

It turns out that there is already a new_objfile observer in
symtab.c.  I propose that, when the argument is nullptr (indicating
all debug info should be discarded), that we should call set_main_name
to discard the information about the main function.  We can then
remove the executable_changed observer from symtab.c.

All tests still pass, and, in my local world, I added some debug
printf calls, and I think we are still discarded the main information
everywhere we need to.

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

gdb/python: new Progspace.executable_filename attribute

Add a new Progspace.executable_filename attribute that contains the
path to the executable for this program space, or None if no
executable is set.

The path within this attribute will be set by the "exec-file" and/or
"file" commands.

Accessing this attribute for an invalid program space will raise an
exception.

This new attribute is similar too, but not the same as the existing
gdb.Progspace.filename attribute.  If I could change the past, I'd
change the 'filename' attribute to 'symbol_filename', which is what it
actually represents.  The old attribute will be set by the
'symbol-file' command, while the new attribute is set by the
'exec-file' command.  Obviously the 'file' command sets both of these
attributes.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/python: new Progspace.symbol_file attribute

Add a new Progspace.symbol_file attribute.  This attribute holds the
gdb.Objfile object that corresponds to Progspace.filename, or None if
there is no main symbol file currently set.

Currently, to get this gdb.Objfile, a user would need to use
Progspace.objfiles, and then search for the objfile with a name that
matches Progspace.filename -- which should work just fine, but having
direct access seems a little nicer.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/doc: extend the description for Progspace.filename

Extend the description for Progspace.filename in the documentation to
mention what the returned string is actually the filename
for (e.g. that it is the filename passed to the 'symbol-file' or
'file' command).

Also document that this attribute will be None if no symbol file is
currently loaded.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/x86: use size of XSAVE area of enabled features

Since commit b42405a1594 ("gdb: Update x86 Linux architectures to
support XSAVE layouts."), the test gdb.base/gcore.exp fails on my AMD
Ryzen 3700X machine:

    FAIL: gdb.base/gcore.exp: corefile restored all registers

The test gets the register state (saves the output of "info
all-registers"), saves a core with the "gcore" command, loads the core,
and checks the register state against the one previously saved.  The
problem is that when reading registers from the core file, the last half
of ymm registers is unavailable:

    (gdb) print $ymm0.v32_int8
    $1 = {0, -77, -23, -9, -1, 127, 0, 0, 0, -77, -23, -9, -1, 127, 0, 0, <unavailable> <repeats 16 times>}

One strange thing with this machine is that the bitset of state
components supported by XCR0 is 0x207, meaning "x87 | SSE | AVX | PKRU",
but XCR0 at runtime is 0x7, meaning "x87 | SSE | AVX".  So, PKRU appears
to be supported by the processor, but disabled by the kernel.  I didn't
find why yet.

From CPUID leaf EAX=0Dh, ECX=00h, GDB can get:

 - from EBX: max size of the XSAVE area required by features currently
   enabled in XCR0.  On my machine, it's 0x340 (832).
 - from ECX: max size of the XSAVE area required by all features
   supported by XCR0.  On my machine, it's 0x380 (896).

At runtime, GDB uses ECX (max size required by all supported features)
to fill the x86_xsave_layout::sizeof_xsave.  So, when writing the core
file note for the XSAVE state, it writes a note of size 896, even though
it doesn't write the PKRU state.  When loading back the core, GDB tries
to figure out the layout of the XSAVE area based on what features are
enabled in XCR0 and the size of the note (the size of the XSAVE area).
Since my combination of XCR0 and size of XSAVE area doesn't match any
combination known by GDB, GDB falls back to a gdbarch supporting only
x87 and SSE.

This patch changes GDB to populate the x86_xsave_layout::sizeof_xsave
field (and consequently the size of the XSAVE state note in core files)
using EBX, the size of the XSAVE area required by currently enabled
features in XCR0.  This makes i387_guess_xsave_layout recognize my case
with this condition:

  else if (HAS_AVX (xcr0) && xsave_size == 832)
    {
      /* Intel and AMD CPUs supporting AVX.  */
      layout.avx_offset = 576;
    }

In other words, just as if my machine didn't support PKRU at all.

Another reason why I think this change makes sense is that XSAVE state
notes in kernel-generated cores on this machine have size 832.  So this
change makes GDB-generated cores more similar to kernel-generated ones,
reducing the diversity of XSAVE state notes that GDB needs to be able to
figure out.

Note that if PKRU was enabled on my machine, then the effective XSAVE
area size would be 896 bytes.  We would need to add a case in
i387_guess_xsave_layout for that combination, since there is no
currently.  But I don't have a way to test that right now, since I don't
know why PKRU is disabled.

Relevant review note from John Baldwin:

  One further note is that the Linux x86 arches use x86_xsave_length()
  to infer ("guess") the size of the XSAVE register set that the Linux
  kernel writes out in core dumps.  On FreeBSD x86 arches, GDB is able
  to query this size directly from the kernel via ptrace.  My use of ECX
  for this guess earlier was just not the best guess.  In the case that
  the kernel enables all of the available features, then ECX and EBX
  have the same values, so this only matters for a system where the
  kernel has enabled a subset of available XSAVE extensions.

Change-Id: If64f30307f3a2e5ca3e1fd1cb7379ea840805a85
Reviewed-By: John Baldwin <jhb@FreeBSD.org>

Add support to readelf for the PT_OPENBSD_NOBTCFI segment type.

Fix: nm: SEGV on unknow address at nm.c:718 in print_symname

  PR 30886 * elf-bfd.h (struct elf_obj_tdata): Add dt_strsz field.
  * elf.c (_bfd_elf_get_dynamic_symbols): Add a NUL byte at the end of the string table. Initialise the dt_strsz field. (_bfd_elf_slurp_version_tables): Only free the contents if they were malloc'ed. Add checks before setting string pointers in the dt_strtab buffer.

[gdb/testsuite] Add nopie to gdb.base/unwind-on-each-insn-amd64-2.exp

When running test-case gdb.base/unwind-on-each-insn-amd64-2.exp with target
board unix/-fPIE/-pie, I run into:
...
gdb compile failed, ld: unwind-on-each-insn-amd64-21.o: relocation \
  R_X86_64_32S against `.text' can not be used when making a PIE object; \
  recompile with -fPIE
ld: failed to set dynamic section sizes: bad value
...

Fix this by hardcoding nopie in the test-case, and for good measure in the
other test-cases that source unwind-on-each-insn.exp.tcl and use a .s file.

Tested on x86_64-linux.

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

Automatic date update in version.in

config/debuginfod.m4: Add check for libdebuginfod 0.188

Add check for libdebuginfod 0.188 in AC_DEBUGINFOD and if found
define macro HAVE_LIBDEBUGINFOD_FIND_SECTION.

This macro indicates support for downloading ELF sections from
debuginfod servers.

nm: heap-buffer-overflow at elfcode.h:1507 in bfd_elf64_slurp_symbol_table

  PR 30885
  * elfcode.h (elf_slurp_symbol_table): Compute the symcount for non dynamic symbols in the same way as _bfd_elf_get_symtab_upper_bound.

x86: prefer VEX encodings over EVEX ones when possible

AVX-* features / insns paralleling earlier introduced AVX512* ones can
be encoded more compactly when the respective feature was explicitly
enabled by the user.

x86: drop cpu_arch_tune_flags

Apparently from its introduction the variable was only ever written (the
only read is merely to determine whether to write it with another value).
(Since, due to the need to re-indent, the adjacent lines setting
cpu_arch_tune need touching anyway, switch to using PREOCESSOR_*
constants where applicable, to make more obvious what the resulting
state is going to be.)

x86: correct cpu_arch_isa_flags maintenance

These may not be set from a value derived from cpu_arch_flags: That
starts with (almost) all functionality enabled, while cpu_arch_isa_flags
is supposed to track features that were explicitly enabled (and perhaps
later disabled) by the user.

To avoid needing to do any such adjustment in two places (each),
introduce helper functions used by both command line handling and
directive processing.

Adjust gdb.thread/pthreads.exp for Cygwin

The Cygwin runtime spawns a few extra threads, so using hardcoded
thread numbers in tests rarely works correctly.  Thankfully, this
testcase already records the ids of the important threads in globals.
It just so happens that they are not used in a few tests.  This commit
fixes that.

With this, the test passes cleanly on Cygwin [1].  Still passes cleanly on
x86-64 GNU/Linux.

[1] - with system GDB.  Upstream GDB is missing a couple patches
Cygwin carries downstream.

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

In gdb.threads/pthreads.c, handle pthread_attr_setscope ENOTSUP

On Cygwin, I see:

 (gdb) PASS: gdb.threads/pthreads.exp: break thread1
 continue
 Continuing.
 pthread_attr_setscope 1: Not supported (134)
 [Thread 3732.0x265c exited with code 1]
 [Thread 3732.0x2834 exited with code 1]
 [Thread 3732.0x2690 exited with code 1]

 Program terminated with signal SIGHUP, Hangup.
 The program no longer exists.
 (gdb) FAIL: gdb.threads/pthreads.exp: Continue to creation of first thread

 ... and then a set of cascading failures.

Fix this by treating ENOTSUP the same way as if PTHREAD_SCOPE_SYSTEM
were not defined.  I.e., ignore ENOTSUP errors, and proceed with
testing.

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

Fix gdb.threads/pthreads.exp error handling/printing

On Cygwin, I noticed:

 (gdb) PASS: gdb.threads/pthreads.exp: break thread1
 continue
 Continuing.
 pthread_attr_setscope 1: No error
 [Thread 8732.0x28f8 exited with code 1]
 [Thread 8732.0xb50 exited with code 1]
 [Thread 8732.0x17f8 exited with code 1]

 Program terminated with signal SIGHUP, Hangup.
 The program no longer exists.
 (gdb) FAIL: gdb.threads/pthreads.exp: Continue to creation of first thread

Note "No error" in "pthread_attr_setscope 1: No error".  That is a bug
in the test.  It is using perror, but that prints errno, while the
pthread functions return the error directly.  Fix all cases of the
same problem, by adding a new print_error function and using it.

We now get:

  ...
  pthread_attr_setscope 1: Not supported (134)
  ...

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

Fix gdb.threads/pthreads.c formatting

Just some GNU formatting fixes throughout.

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

gdb.threads/pthreads.c, K&R -> ANSI function style

gdb.threads/pthreads.c is declaring functions with old K&R style.
This commit converts them to ANSI style.

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

opcodes: microblaze: Add wdc.ext.clear and wdc.ext.flush insns

Fix: Output section type does not been applied to section forced output by `. = .` assignment

  PR 30875
  * ldlang.c (get_os_init_flag): New function. (exp_init_os, map_input_to_output_sections): Use it.

x86: fold FMA VEX and EVEX templates

Following the folding of some generic AVX/AVX2 templates with their
AVX512F counterpart ones, do this for FMA ones as well, requiring one
further adjustment to cpu_flags_match().

x86: fold VAES/VPCLMULQDQ VEX and EVEX templates

Following the folding of some generic AVX/AVX2 templates with their
AVX512F counterpart ones, do this for VAES and VPCLMULQDQ ones as well.

x86: fold certain VEX and EVEX templates

In anticipation of APX introduce logic to reduce the number of templates
we have now, allowing to limit some the number of ones we then need to
gain.

The fundamental requirements are that
- attributes be compatible, which specifically means VexW needs to be
  the same in the templates (which often isn't the case, for VEX
  encodings having far more WIG tha, EVEX ones),
- the EVEX form being AVX512F (with or without AVX512VL), not any of its
  extensions (the same will then be required for APX - it'll need to be
  APX_F).

Note that in check_register() there's now a redundant zmm check. Since
this logic will need revisiting for APX anyway, I'd like to keep it that
way for now. (Similarly a couple of if()-s which could be folded are
kept separate, to reduce code churn when adding APX support.)

x86: tighten .insn SAE and broadcast checking

SAE / embedded rounding are invalid when there's the memory operand, as
the bit encoding this specifies broadcast in that case.

Broadcast needs to be specified on the memory operand.

x86-64: REX.W overrides DATA_PREFIX

REX.W needs to be respected when immediate size and relocation type are
determined.

x86-64: fix suffix-less PUSH of symbol address

PR gas/30856

In 5cc007751cdb ("x86: further adjust extend-to-32bit-address
conditions") I neglected the case of PUSH, which is the only insn
allowing (proper) symbol addresses to be used as immediates (not
displacements, like CALL/JMP) in the absence of any register operands.
Since it defaults to 64-bit operand size, guessing an L suffix is wrong
there.

gdb: Fix an ODR warning with byacc with GDB_YY_REMAP

With byacc, we get an ODR warning with YYSTACKDATA between ada-exp.c.tmp
and c-exp.c.tmp. Just include it in the list of symbols we rename.

PR gdb/30839

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30839
Approved-By: Tom de Vries <tdevries@suse.de>
Copyright-paperwork-exempt: yes

Add support for "pcaddi rd, symbol"

Add a macro pcaddi instruction to support "pcaddi rd, symbol".

pcaddi has a 20-bit signed immediate, it can address a +/- 2MB pc relative
address, and the address should be 4-byte aligned.

Automatic date update in version.in

gdb/testsuite: add xfail for gdb/29965 in gdb.threads/process-exit-status-is-leader-exit-status.exp

Bug 29965 shows on a Linux kernel >= 6.1, that test fails consistently
with:

    FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=0: continue (the program exited)
    ...
    FAIL: gdb.threads/process-exit-status-is-leader-exit-status.exp: iteration=9: continue (the program exited)

This is due to a change in Linux kernel behavior [1] that affects
exactly what this test tests.  That is, if multiple threads (including
the leader) call SYS_exit, the exit status of the process should be the
exit status of the leader.  After that change in the kernel, it is no
longer the case.

Add an xfail in the test, based on the Linux kernel version.  The goal
is that if a regression is introduced in GDB regarding this feature, it
should be caught if running on an older kernel where the behavior was
consistent.

[1] https://bugzilla.suse.com/show_bug.cgi?id=1206926

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29965
Change-Id: If6ab7171c92bfc1a3b961c7179e26611773969eb
Approved-By: Tom de Vries <tdevries@suse.de>

[gdb/testsuite] Fix gdb.ada/mi_task_arg.exp with newer gcc

When running test-case gdb.ada/mi_task_arg.exp on openSUSE Tumbleweed using
gcc 13.2.1, I run into (layout adapted for readability):
...
-stack-list-arguments 1^M
^done,stack-args=[
  frame={level="0",args=[]},
  frame={level="1",args=[{name="<_task>",value="0x464820"},
                         {name="<_taskL>",value="129"}]},
  frame={level="2",args=[{name="self_id",value="0x464840"}]},
  frame={level="3",args=[]},
  frame={level="4",args=[]}
]^M
(gdb) ^M
FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output)
...

On openSUSE Leap 15.4 with gcc 7.5.0 I get instead:
...
-stack-list-arguments 1^M
^done,stack-args=[
  frame={level="0",args=[]},
  frame={level="1",args=[{name="<_task>",value="0x444830"}]},
  frame={level="2",args=[{name="self_id",value="0x444850"}]},
  frame={level="3",args=[]},
  frame={level="4",args=[]}]^M
(gdb) ^M
PASS: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1
...

The difference in gdb output is due to difference in the dwarf generated by
the compiler, so I don't see a problem with gdb here.

Fix this by updating the test-case to accept this output.

Tested on x86_64-linux.

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

Remove some unnecessary qualification from printing.py

printing.py references "gdb.printing" in a few spots, but there's no
need for this.  I think this is leftover from when this code was
(briefly) in some other module.  This patch removes the unnecessary
qualifications.  Tested on x86-64 Fedora 36.

Add two new pretty-printer methods

This adds two new pretty-printer methods, to support random access to
children.  The methods are implemented for the no-op array printer,
and DAP is updated to use this.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Introduce gdb.ValuePrinter

There was an earlier thread about adding new methods to
pretty-printers:

https://sourceware.org/pipermail/gdb-patches/2023-June/200503.html

We've known about the need for printer extensibility for a while, but
have been hampered by backward-compatibilty concerns: gdb never
documented that printers might acquire new methods, and so existing
printers may have attribute name clashes.

To solve this problem, this patch adds a new pretty-printer tag class
that signals to gdb that the printer follows new extensibility rules.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30816
Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Fix a snafu in the new tests for reproducible archives that assumed a umask of 22.

[gdb/testsuite] Fix gdb.server/ext-run.exp in container

When running the gdb testsuite inside a container, I run into:
...
(gdb) gdb_expect_list pattern: /1 +root +[/a-z]*(init|systemd)/
FAIL: gdb.server/ext-run.exp: get process list (pattern 2)
...
because there's no process with pid 1 and cmd init or systemd.

In the host system (where the test passes), I have:
...
$ ps -f 1
UID        PID  PPID  C STIME TTY      STAT   TIME CMD
root         1     0  0 Sep25 ?        Ss     0:03 /usr/lib/systemd/systemd ...
...
but in the container instead:
...
UID        PID  PPID  C STIME TTY      STAT   TIME CMD
root         1     0  0 11:45 pts/0    Ss     0:00 /bin/bash
...

Fix this by also accepting bash as a valid cmd.

Tested on x86_64-linux.

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

aarch64: Allow feature flags to occupy >64 bits

Following on from the previous patch to make the feature macros take
a word number, this one increases the number of flag words from 1 to 2.

The patch uses some dummy features to push the number of features
over 64.  The intention is that these should be reused by real
features rather than kept as-is.

aarch64: Restructure feature flag handling

The AArch64 feature-flag code is currently limited to a maximum
of 64 features.  This patch reworks it so that the limit can be
increased more easily.  The basic idea is:

(1) Turn the ARM_FEATURE_FOO macros into an enum, with the enum
    counting bit positions.

(2) Make the feature-list macros take an array index argument
    (currently always 0).  The macros then return the
    aarch64_feature_set contents for that array index.

    An N-element array would then be initialised as:

      { MACRO (0), ..., MACRO (N - 1) }

(3) Provide convenience macros for initialising an
    aarch64_feature_set for:

    - a single feature
    - a list of individual features
    - an architecture version
    - an architecture version + a list of additional features

(2) and (3) use the preprocessor to generate static initialisers.
The main restriction was that uses of the same preprocessor macro
cannot be nested.  So if a macro wants to do something for N individual
arguments, it needs to use a chain of N macros to do it.  There then
needs to be a way of deriving N, as a preprocessor token suitable for
pasting.

The easiest way of doing that was to precede each list of features
by the number of features in the list.  So an aarch64_feature_set
initialiser for three features A, B and C would be written:

  AARCH64_FEATURES (3, A, B, C)

This scheme makes it difficult to keep AARCH64_FEATURE_CRYPTO as a
synonym for SHA2+AES, so the patch expands the former to the latter.

[gdb/dap] Fix dap for python < 3.8

With any gdb.dap test and python 3.6 I run into:
...
Error occurred in Python: 'code' object has no attribute 'co_posonlyargcount'
ERROR: eof reading json header
...

The attribute is not supported before python 3.8, which introduced the
"Positional−only Parameters" concept.

Fix this by using try/except AttributeError.

Tested on x86_64-linux:
- openSUSE Leap 15.4 with python 3.6, and
- openSUSE Tumbleweed with python 3.11.5.

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

fbsd-nat: Fix build failure with GCC 12

A user pointed out that the build failed on FreeBSD/amd64 with my last
commit.  The problem is that I'm not using the proper way to tell the
compiler that the variable has been "used".  This patch fixes this issue
as suggested by John.  Pushed as obvious.

Tested both on FreeBSD/amd64 and FreeBSD/aarch64 by rebuilding.

Suggested-By: John Baldwin <jhb@FreeBSD.org>

Fix to step instruction due to P10 prefix instruction.

In AIX, power 10 instructions like paddi occupy 8 bytes, while the other instructions
4 bytes of space. Due to this when we do a stepi on paddi instruction we get a SIGILL interrupt. Hence, we
need to check during stepi if we are able to step 8 bytes during this instruction execution and is the
breakpoint to this instruction set correctly in both 32- and 64-bit mode.

This patch is a fix to the same.

Allow the use of SOURCE_DATE_EPOCH in the timestamps for members of static archives.

(For some reason this commit was not applied at the time that the patch was approved).

Use string_file::release in some places

I found a few spots like:

    string_file f;
    std::string x = f.string ();

However, string_file::string returns a 'const std::string &'...  so it
seems to me that this must be copying the string (? I find it hard to
reason about this in C++).

This patch changes these spots to use release() instead, which moves
the string.

Reviewed-by: Keith Seitz <keiths@redhat.com>
Reviewed-by: Lancelot Six <lancelot.six@amd.com>

Automatic date update in version.in

Fix readelf's display of dwarf v5 range lists

  PR 30792
  * dwarf.h (struct debug_info): Remove range_versions field.
  * dwarf.c (fetch_indexed_offset): New function. (read_and_display_attr_value): Use it for DW_FORM_rnglistx. Remove code to initialise range_versions. (skip_attribute): New function. (read_bases): Read and reccord all range and address bases in a CU. (process_debug_info): Call read_bases. (display_debug_rnglists): Rename to display_debug_rnglists_unit_header and only display the range list header information. (display_debug_ranges): Adjust.

Revert "arc: Add new GAS tests for ARCv3."

This reverts commit 462693a455f04fc52c1c91ffc52ea2446a086444.

Revert "arc: Add new LD tests for ARCv3."

This reverts commit 6e467e9a94c1135bd11d985e9263d43204a9258b.

Revert "arc: Add new ARCv3 ISA to BFD."

This reverts commit 06e8d9861d16c5b7e6920ad0e89889ccf45c575a.

Revert "arc: Add new linker emulation and scripts for ARCv3 ISA."

This reverts commit 4deb1ee57fdb711cac6f36fed75b3c8cb5112d99.

Revert "arc: Update opcode related include files for ARCv3."

This reverts commit 04414221df53bb5129e34bec354dae3121db436a.

Revert "arc: Update ARC's Gnu Assembler backend with ARCv3 ISA."

This reverts commit f3d38d7d0b7346515ba603454feeddc58a3fc451.

Revert "arc: Add new opcode functions for ARCv3 ISA."

This reverts commit c99dc76089a2de97ea0ee755aa8e87037a17b6d6.

Revert "arc: New ARCv3 ISA instruction table"

This reverts commit 67036dfacf87e79317984f51892bfc0eda0e597f.

Revert "arc: Update arc's gas tests"

This reverts commit ef90c0991e78c28bebdd3ed31a77c05be0444191.

Revert "arc: Update NEWS files"

This reverts commit a47d304b1229ecf8912fac17ee9c48d1bf3c729a.

Revert "arc: Update bfd arc pattern file to allow enable-targets=all"

This reverts commit 5e5116071b09e187ee3c6b7e86e86114f6a65ef3.

arc: Update bfd arc pattern file to allow enable-targets=all

The ARC backend uses a BFD pattern file to generate three ARC targets:
- an BFD ARC target for ARCv1 and ARCv2 CPU families. It also works
for big-endian variants.
- an BFD ARC64 target for ARCv3 64bit machines. It also allows working
with ARCv3 32bit machines.
- an BFD ARC32 target for ARCv4 32bit machines. It also allows working
with ARCv3 64bit machines.

When configuring with `--enable-targets=all` some patterns are defined
multiple times. Fix this issue.

Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>

RISC-V: Protect .got with relro

Move .got before .data so that it can be protected with -zrelro.  Also
separate .got.plt from .got if -znow is not in effect; the first two words
of .got.plt are placed within the relro region.

ld:
PR ld/30877
* emulparams/elf32lriscv-defs.sh (DATA_GOT, SEPARATE_GOTPLT):
Define.
* emulparams/elf64lriscv-defs.sh (SEPARATE_GOTPLT): Define.
* testsuite/ld-elf/binutils.exp (binutils_test): Remove riscv*-*-*
from relro_got expression.

arc: Update NEWS files

Add ARCv3 support in NEWS files.

Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>

arc: Update arc's gas tests

The disassembler can recognize the alternative register names ILINK1
and ILINK2.  Update tests.

gas/testsuite/gas/arc
xxxx-xx-xx  Claudiu Zissulescu <claziss@synopsys.com>

* gas/testsuite/gas/arc/adc.d: Update ILINK1/INLINK2 reg names.
* gas/testsuite/gas/arc/add.d: Likewise.
* gas/testsuite/gas/arc/and.d: Likewise.
* gas/testsuite/gas/arc/asl.d: Likewise.
* gas/testsuite/gas/arc/asr.d: Likewise.
* gas/testsuite/gas/arc/bic.d: Likewise.
* gas/testsuite/gas/arc/lsr.d: Likewise.
* gas/testsuite/gas/arc/nps400-1.d: Likewise.
* gas/testsuite/gas/arc/or.d: Likewise.
* gas/testsuite/gas/arc/ror.d: Likewise.
* gas/testsuite/gas/arc/sbc.d: Likewise.
* gas/testsuite/gas/arc/sub.d: Likewise.
* gas/testsuite/gas/arc/textinsn3op.d: Likewise.
* gas/testsuite/gas/arc/warn.exp: Update predicate.
* gas/testsuite/gas/arc/arc.exp: Likewise.

Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>

arc: New ARCv3 ISA instruction table

opcodes/
xxxx-xx-xx  Claudiu Zissulescu <claziss@synopsys.com>

* opcodes/arc64-tbl.h: New file.

Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>

arc: Add new opcode functions for ARCv3 ISA.

opcodes/
xxxx-xx-xx  Claudiu Zissulescu <claziss@synopsys.com>
            Cupertino Miranda <cmiranda@synopsys.com>

        * opcodes/Makefile.am: Add ARC64 opcode file.
        * opcodes/Makefile.in: Regenerate.
        * opcodes/arc-opc.c: Move the common functionality to
        arcxx-opc.inc. Keep only ARCv2 ARCv1 specifics.
        * opcodes/arc-ext-tbl.h: Deleted file.
        * opcodes/arcxx-opc.inc: New file.
        * opcodes/arc64-opc.c: Likewise.
        * opcodes/arc-fxi.h (insert_uimm9_a32_11_s): New function.
        (extract_uimm9_a32_11_s): Likewise.
        (insert_uimm10_13_s): Likewise.
        (extract_uimm10_13_s): Likewise.
        * opcodes/configure: Regenerate.
        * opcodes/configure.ac: Add ARC64 target.
        * opcodes/disassemble.c: Likewise.
        * opcodes/arc-dis.c (regmod_t): New type.
        (regmods): New structure.
        (fpnames): New strings with fp-regs name.
        (REG_PCL, REG_LIMM, REG_LIMM_S, REG_U32, REG_S32): New defines.
        (getregname): New function.
        (find_format_from_table): Discriminate between signed and unsigned
        32bit immediates.
        (find_format): Handle extract function for flags.
        (arc_insn_length): Update insn lengths to various architectures.
        (print_insn_arc): Update printing for various ARC architectures.
* opcodes/arc-flag-classes.def: New file.
* opcodes/arc-flag.def: New file.
* opcodes/arc-operands.def: New file.
* opcodes/arc-regs.h: Changed.

Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>

arc: Update ARC's Gnu Assembler backend with ARCv3 ISA.

The new Synopsys ARCv3 ISA has a similar instruction format like
the old ARCv1 and ARCv2 ISA.  Thus, the ARCv3 addition is using
whatever we have for old ARC processors plus some ARCv3 spcific mods.

To distinguish between various ARC variants, we introduced two new
configure defines named TARGET_ARCv3_32 and TARGET_ARCv3_64 which are
set when we choose either an ARC32 (ARCv3/32) ISA toolchain or an
ARC64 (ARCv3/64) ISA toolchain.

gas/
xxxx-xx-xx  Claudiu Zissulescu <claziss@synopsys.com>

* gas/config/tc-arc.h: Selectively define default target macros.
* gas/configure.ac: Add ARC64 target.
* gas/configure.tgt: Likewise.
* gas/configure: Regenerate
* gas/config.in: Regenerate.
* gas/config/tc-arc.c (DEFAULT_ARCH): New macro.
(default_arch): New variable.
(md_pseudo_table): Add xword.
(md_shortopts): Only a few options are recognized by the new ARC64
assembler.
(md_longopts): Likewise.
(ARC_CPU_TYPE_A64x): New define.
(ARC_CPU_TYPE_A32x): Likewise.
(cpu_type): New arch field.
(selected_cpu): Update fields.
(arc_opcode_hash_entry_iterator_init): Formating.
(arc_opcode_hash_entry_iterator_next): Likewise.
(arc_select_cpu): Likewise.
(arc_option): Likewise.
(check_cpu_feature): Likewise.
(debug_exp): Recognize new expression operands.
(parse_reloc_symbol): Parse new signed/unsigend cases.
(parse_opcode_flags): Update for the case when the flags needs
insert/extract functions.
(find_opcode_match): Match new signed/unsigned 32-bit immediates.
(autodetect_attributes): PLT34 only available for ARC64.
(md_assemble): Extend match characters.
(declare_fp_set): New function.
(init_default_arch): Likewise.
(md_begin): Detect and initialize the correct CPU and coresponding
registers.
(md_pcrel_from_section): Add new relocs.
(arc_target_format): New function.
(md_apply_fix): Add new relocs.
(md_parse_option): Update options.
(arc_show_cpu_list): Update with ARC64 cpus.
(md_show_usage): Update messages.
(may_relax_expr): Add PLT34 case.
(assemble_insn): Update for ARC64.
(arc_make_nops): New function.
(arc_handle_align): Refurbish this function, use arc_make_nops.
(tc_arc_fix_adjustable): Update messages.

Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>

arc: Update opcode related include files for ARCv3.

Add new ARCv3 CPUs and required bits to decode/encode ARCv3 ISA
opcodes. Fix 32 bit relocations which were set as signed but should be
bitfield: ARC_32_ME, ARC_GLOB_DAT, ARC_JMP_SLOT, ARC_RELATIVE. Remove
non-ABI relocation ARC_32_ME_S.

include/
xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>
    Cupertino Miranda  <cupertinomiranda@gmail.com>
    Bruno Mauricio <brunoasmauricio@gmail.com>

* include/elf/arc-cpu.def: Add new HS5x and HS6x CPUs.
* include/elf/arc-reloc.def: Add new ARC64 relocations.
* include/elf/arc.h (EF_ARC_CPU_ARC64): New define.
* include/opcode/arc-attrs.h (FEATURE_LIST_NAME): Update predicate.
* include/opcode/arc-func.h: Update formating.
(replace_disp8ls): New function.
(replace_disp9s): Likewise.
(replace_disp6s): Likewise.
(replace_disp7s): Likewise.
(replace_disp12s): Likewise.
* include/opcode/arc.h (ARC_OPCODE_ARC64): New define.
(ARC_OPCODE_ARC32): Likewise.
(ARC_OPERAND_FP): Likewise.
(HARD_FIELDF): Likewise.
(ARC_OPCODE_ARCVx): New macro.
(arc_flag_class): Update structure to hold new extract/insert
functions for flags.
(INSN3OP): Update macro.
(FP_SIZE, TPOF, DPOF, SOPF, COPF, CONVOPS): New enums.

Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>

arc: Add new linker emulation and scripts for ARCv3 ISA.

Add ARCv3's linker bits. Remove obsolete tests.

ld/
xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>

* ld/Makefile.am: Add ARC64 targets.
* ld/configure.tgt: Likewise.
* ld/Makefile.in: Regenerate.
* ld/emulparams/arc64elf32.sh: New file.
* ld/emulparams/arc64elf64.sh: Likewise.
* ld/emulparams/arc64linux32.sh: Likewise.
* ld/emulparams/arc64linux64.sh: Likewise.
* ld/scripttempl/elfarc.sc: Update stack and heap definitions.
* ld/testsuite/ld-arc/got-weak.d: Deleted file.
* ld/testsuite/ld-arc/got-weak.s: Likewise.

Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>

arc: Add new ARCv3 ISA to BFD.

The new Synopsys's ARCv3 ISA is capable to run either 64-bit or
32-bit ISA.  The new 32-bit ISA is not compatible with the old
Synopsys ARCv1/ARCv2 ISA, however, it retains a lot of common
concepts.  Thus, this patch is reusing the old ARC BFD backend and
adds the necessary bits for the new architecture in a similar way as
it is done for RISCV backend.

bfd/
xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>
    Cupertino Miranda  <cupertinomiranda@gmail.com>

* bfd/Makefile.am: Add ARC64 files.
* bfd/Makefile.in: Regerate.
* bfd/arc-got.h (TCB_SIZE): Depends on the target architecture.
(GOT_ENTRY_SIZE): New define.
(write_in_got): Likewise.
(read_from_got): Likewise.
(align_power): Likewise.
(arc_got_entry_type_for_reloc): Use RELA_SIZE and GOT_ENTRY_SIZE.
(arc_fill_got_info_for_reloc): Update formating.
(relocate_fix_got_relocs_for_got_info): Likewise.
(arc_static_sym_data): Deleted structure.
(get_static_sym_data): Deleted function.
(relocate_fix_got_relocs_for_got_info): Use symbol static data.
(create_got_dynrelocs_for_single_entry): Update formating.
(create_got_dynrelocs_for_got_info): Likewise.
* bfd/arc-plt.c: New file.
* bfd/arc-plt.def: Add ARC64 PLT entry.
* bfd/arc-plt.h: Clean it up, move functionality to arc-plt.c file.
* bfd/archures.c: Add ARC64 target.
* bfd/config.bfd: Likewise.
* bfd/configure.ac: Likewise.
* bfd/bfd-in2.h: Regenerate.
* bfd/configure: Likewise.
* bfd/libbfd.h: Likewise.
* bfd/cpu-arc.c: Clean it up.
* bfd/cpu-arc64.c: New file.
* bfd/elf32-arc.c: Renamed to elfnn-arc.c.
* bfd/elfnn-arc.c: New file.
* bfd/reloc.c: Add new ARC64 relocs.
* bfd/targets.c: Add ARC64 target.

Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>

arc: Add new LD tests for ARCv3.

Add new linker tests for ARCv3 ISA. All the new tests are added in a
distinct new folder named arc64.

ld/
xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>

* ld/testsuite/ld-arc64/arcv3_64-reloc-near-exe.dd: New file.
* ld/testsuite/ld-arc64/arcv3_64-reloc-near-so.dd: Likewise.
* ld/testsuite/ld-arc64/arcv3_64-reloc-near.s: Likewise.
* ld/testsuite/ld-arc64/arcv3_64.exp: Likewise.
* ld/testsuite/ld-arc64/bl34.dd: Likewise.
* ld/testsuite/ld-arc64/bl34.s: Likewise.
* ld/testsuite/ld-arc64/linkscript.ld: Likewise.
* ld/testsuite/ld-arc64/plt34-got.dd: Likewise.
* ld/testsuite/ld-arc64/plt34-got.s: Likewise.
* ld/testsuite/ld-arc64/plt34-reloc.dd: Likewise.
* ld/testsuite/ld-arc64/plt34-reloc.s: Likewise.

Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>

arc: Add new GAS tests for ARCv3.

Add new assembler tests for ARCv3 ISA. All the new tests are added in
a distinct folder named arc64.

gas/
xxxx-xx-xx  Claudiu Zissulescu <claziss@synopsys.com>

* gas/testsuite/gas/arc64/arc64.exp: New file.
* gas/testsuite/gas/arc64/float01.d: Likewise.
* gas/testsuite/gas/arc64/float01.s: Likewise.
* gas/testsuite/gas/arc64/ldd.d: Likewise.
* gas/testsuite/gas/arc64/ldd.s: Likewise.
* gas/testsuite/gas/arc64/lddl.d: Likewise.
* gas/testsuite/gas/arc64/lddl.s: Likewise.
* gas/testsuite/gas/arc64/load.d: Likewise.
* gas/testsuite/gas/arc64/load.s: Likewise.
* gas/testsuite/gas/arc64/st.d: Likewise.
* gas/testsuite/gas/arc64/st.s: Likewise.
* gas/testsuite/gas/arc64/std.d: Likewise.
* gas/testsuite/gas/arc64/std.s: Likewise.
* gas/testsuite/gas/arc64/stdl.d: Likewise.
* gas/testsuite/gas/arc64/stdl.s: Likewise.
* gas/testsuite/gas/arc64/stl.d: Likewise.
* gas/testsuite/gas/arc64/stl.s: Likewise.

Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>

arc: Update binutils arc predicate for tests.

binutils/testsuite/binutils-all
xxxx-xx-xx  Claudiu Zissulescu  <claziss@synopsys.com>

* binutils/testsuite/binutils-all/arc/objdump.exp: Update predicate.

Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Update the NetBSD system call table to add memfd_create(2) and epoll(2).

Generated from sys/sys/syscall.h revision 1.324.

fbsd-nat: Pacify gcc with no functional changes

I see these errors on FreeBSD/aarch64 when using gcc 12 without passing
--disable-werror.

=====================================================================
  CXX    fbsd-nat.o
fbsd-nat.c: In member function 'void fbsd_nat_target::resume_one_process(ptid_t, int, gdb_signal)':
fbsd-nat.c:1208:11: error: unused variable 'request' [-Werror=unused-variable]
 1208 |       int request;
      |           ^~~~~~~
fbsd-nat.c: In member function 'virtual ptid_t fbsd_nat_target::wait(ptid_t, target_waitstatus*, target_wait_flags)':
fbsd-nat.c:1726:22: error: declaration of 'inf' shadows a previous local [-Werror=shadow=compatible-local]
 1726 |       for (inferior *inf : all_non_exited_inferiors (this))
      |                      ^~~
fbsd-nat.c:1697:17: note: shadowed declaration is here
 1697 |       inferior *inf = find_inferior_ptid (this, wptid);
      |                 ^~~
fbsd-nat.c: In member function 'virtual void fbsd_nat_target::detach(inferior*, int)':
fbsd-nat.c:2044:18: error: variable 'wptid' set but not used [-Werror=unused-but-set-variable]
 2044 |           ptid_t wptid = wait_1 (ptid, &ws, 0);
      |                  ^~~~~
cc1plus: all warnings being treated as errors
=====================================================================

This patch includes the following non-functional changes,

1. Remove unused variable "request".
2. Rename inf to inf_p to avoid shadowed declaration warnings.
3. Mark wptid as used when USE_SIGTRAP_SIGINFO is defined.

Tested on FreeBSD/aarch64 by rebuilding.

Approved-By: John Baldwin <jhb@FreeBSD.org>

Remove keywords from target debug printer names

I recently checked in a patch that removed the use of the "struct"
keyword in some spots.  Doing this pointed out that the target
delegate code preserves this keyword -- but, with C++, it does not
really need to.  This patch changes make-target-delegates.py to remove
these keywords, and updates target-debug.h to follow.  This pointed
out that there was already one redudancy: both
target_debug_print_struct_inferior_p and target_debug_print_inferior_p
existed.

Tested by rebuilding.

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

gprofng: 30834 improve disassembly output for call and branch instructions

This patch makes the gprofng disassembler to emit, e.g.
    call   fprintf@plt [ 0x401060, .-0x49c]
instead of
    call   0xfffffffffffffb64

I use bfd_get_synthetic_symtab() to get function names in the .plt section.
I have not yet modified Elf-reader in gprofng to remove parsing of .symtab or
.dynsym sections. But we plan to do it.

gprofng/ChangeLog
2023-09-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/30834
* src/Disasm.cc: Show the function name in the call instruction
and the relative address in the branch instruction. Remove unused code.
* src/Disasm.h (map_PC_to_func, get_funcname_in_plt): New functions.
* src/Elf.cc: Get function names for the .plt section.
* src/Elf.h (get_funcname_in_plt, get_bfd_symbols): New functions.
* src/Stabs.cc: Add pltSym to SymLst. Remove the conversion to uint32_t.

Automatic date update in version.in

ld: write resolved path to included file to dependency-file

In ldfile_open_command_file_1() name written to the dependency files is
the name as specified passed to the "INCLUDE" directive.
This is before include-path processing so the tracked dependency
location is most likely wrong.

Instead track the opened file at the point where the resolved path is
actually available, in try_open().

Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>

Automatic date update in version.in

Remove stray trailing "," from DAP breakpoint.py

The buildbot pointed out that the last DAP series I checked in had an
issue.  Looking into it, it seems there is a stray trailing "," in
breakpoint.py.  This patch removes it.

This seems to point out a test suite deficiency.  I will look into
fixing that.

Remove explanatory comments from includes

I noticed a comment by an include and remembered that I think these
don't really provide much value -- sometimes they are just editorial,
and sometimes they are obsolete.  I think it's better to just remove
them.  Tested by rebuilding.

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

gdb/dap: only include sourceReference if file path does not exist

According to the DAP specification if the "sourceReference" field is
included in a Source object, then the DAP client _must_ make a "source"
request to the debugger to retrieve file contents, even if the Source
object also includes path information.

If the Source's path field is a valid path that the DAP client is able
to read from the filesystem, having to make another request to the
debugger to get the file contents is wasteful and leads to incorrect
results (DAP clients will try to get the contents from the server and
display those contents as a file with the name in "source.path", but
this will conflict with the _acutal_ existing file at "source.path").

Instead, only set "sourceReference" if the source file path does not
exist.

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

gdb/dap: use breakpoint fullname to resolve source

If the breakpoint has a fullname, use that as the source path when
resolving the breakpoint source information. This is consistent with
other callers of make_source which also use "fullname" if it exists (see
e.g. DAPFrameDecorator which returns the symtab's fullname).

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

gdb/dap: ignore unused keyword args in step_out

Some DAP clients may send additional parameters in the stepOut command
(e.g. "granularity") which are not used by GDB, but should nonetheless
be accepted without error.

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

gdb/dap: check for breakpoint source before unpacking

Not all breakpoints have a source location. For example, a breakpoint
set on a raw address will have only the "address" field populated, but
"source" will be None, which leads to a RuntimeError when attempting to
unpack the filename and line number.

Before attempting to unpack the filename and line number from the
breakpoint, ensure that the source information is not None. Also
populate the source and line information separately from the
"instructionReference" field, so that breakpoints that include only an
address are still included.

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

Run 'black' on printing.py

The buildbot pointed out that I neglected to re-run 'black' after
making some changes.  This patch fixes the oversight.

gdb/tui: add 'set tui mouse-events off' to restore mouse selection

Rationale:
I use the mouse with my terminal to select and copy text. In gdb, I use
the mouse to select a function name to set a breakpoint, or a variable
name to print, for example.

When gdb is compiled with ncurses mouse support, gdb's TUI mode
intercepts mouse events. Left-clicking and dragging, which would
normally select text, seems to do nothing. This means I cannot select
text using my mouse anymore. This makes it harder to set breakpoints,
print variables, etc.

Solution:
I tried to fix this issue by editing the 'mousemask' call to only enable
buttons 4 and 5. However, this still caused my terminal (gnome-terminal)
to not allow text to be selected. The only way I could make it work is
by calling 'mousemask (0, NULL);'. But doing so disables the mouse code
entirely, which other people might want.

I therefore decided to make a setting in gdb called 'tui mouse-events'.
If enabled (the default), the behavior is as it is now: terminal mouse
events are given to gdb, disabling the terminal's default behavior.
If disabled (opt-in), the behavior is as it was before the year 2020:
terminal mouse events are not given to gdb, therefore the mouse can be
used to select and copy text.

Notes:
I am not attached to the setting name or its description. Feel free to
suggest better wording.

Testing:
I tested this change in gnome-terminal by performing the following steps
manually:

1. Run: gdb --args ./myprogram
2. Enable TUI: press ctrl-x ctrl-a
3. Click and drag text with the mouse. Observe no selection.
4. Input: set tui mouse-events off
5. Click and drag text with the mouse. Observe that selection works now.
6. Input: set tui mouse-events on.
7. Click and drag text with the mouse. Observe no selection.