Remove some unused functions from guile code

The guile code has a couple of unused functions that touch on the
registry API.  This patch removes them.

Change allocation of type-copying hash table

When an objfile is destroyed, types that are still in use and
allocated on that objfile are copied.  A temporary hash map is created
during this process, and it is allocated on the destroyed objfile's
obstack -- which normally is fine, as that is going to be destroyed
shortly anyway.

However, this approach requires that the objfile be passed to registry
destruction, and this won't be possible in the rewritten registry.
This patch changes the copied type hash table to simply use the heap
instead.  It also removes the 'objfile' parameter from
copy_type_recursive, to make this all more clear.

This patch also fixes an apparent bug in copy_type_recursive.
Previously it was copying the dynamic property list to the dying
objfile's obstack:

-      = copy_dynamic_prop_list (&objfile->objfile_obstack,

However I think this is incorrect -- that obstack is about to be
destroyed.

Change address_space to use new and delete

This changes address_space to use new and delete, and makes some other
small C++-ification changes as well, like changing address_space_num
to be a method.

This patch was needed for the subsequent patch to rewrite the registry
system.

gdb/python: Add BreakpointLocation type

PR python/18385

v7:
This version addresses the issues pointed out by Tom.

Added nullchecks for Python object creations.

Changed from using PyLong_FromLong to the gdb_py-versions.

Re-factored some code to make it look more cohesive.

Also added the more safe Python reference count decrement PY_XDECREF,
even though the BreakpointLocation type is never instantiated by the
user (explicitly documented in the docs) decrementing < 0 is made
impossible with the safe call.

Tom pointed out that using the policy class explicitly to decrement a
reference counted object was not the way to go, so this has instead been
wrapped in a ref_ptr that handles that for us in blocpy_dealloc.

Moved macro from py-internal to py-breakpoint.c.

Renamed section at the bottom of commit message "Patch Description".

v6:
This version addresses the points Pedro gave in review to this patch.

Added the attributes `function`, `fullname` and `thread_groups`
as per request by Pedro with the argument that it more resembles the
output of the MI-command "-break-list".  Added documentation for these attributes.

Cleaned up left overs from copy+paste in test suite, removed hard coding
of line numbers where possible.

Refactored some code to use more c++-y style range for loops
wrt to breakpoint locations.

Changed terminology, naming was very inconsistent. Used a variety of "parent",
"owner". Now "owner" is the only term used, and the field in the
gdb_breakpoint_location_object now also called "owner".

v5:

Changes in response to review by Tom Tromey:
- Replaced manual INCREF/DECREF calls with
  gdbpy_ref ptrs in places where possible.
- Fixed non-gdb style conforming formatting
- Get parent of bploc increases ref count of parent.
- moved bploc Python definition to py-breakpoint.c

The INCREF of self in bppy_get_locations is due
to the individual locations holding a reference to
it's owner. This is decremented at de-alloc time.

The reason why this needs to be here is, if the user writes
for instance;

py loc = gdb.breakpoints()[X].locations[Y]

The breakpoint owner object is immediately going
out of scope (GC'd/dealloced), and the location
object requires it to be alive for as long as it is alive.

Thanks for your review, Tom!

v4:
Fixed remaining doc issues as per request
by Eli.

v3:
Rewritten commit message, shortened + reworded,
added tests.

Patch Description

Currently, the Python API lacks the ability to
query breakpoints for their installed locations,
and subsequently, can't query any information about them, or
enable/disable individual locations.

This patch solves this by adding Python type gdb.BreakpointLocation.
The type is never instantiated by the user of the Python API directly,
but is produced by the gdb.Breakpoint.locations attribute returning
a list of gdb.BreakpointLocation.

gdb.Breakpoint.locations:
The attribute for retrieving the currently installed breakpoint
locations for gdb.Breakpoint. Matches behavior of
the "info breakpoints" command in that it only
returns the last known or currently inserted breakpoint locations.

BreakpointLocation contains 7 attributes

6 read-only attributes:
owner: location owner's Python companion object
source: file path and line number tuple: (string, long) / None
address: installed address of the location
function: function name where location was set
fullname: fullname where location was set
thread_groups: thread groups (inferiors) where location was set.

1 writeable attribute:
enabled: get/set enable/disable this location (bool)

Access/calls to these, can all throw Python exceptions (documented in
the online documentation), and that's due to the nature
of how breakpoint locations can be invalidated
"behind the scenes", either by them being removed
from the original breakpoint or changed,
like for instance when a new symbol file is loaded, at
which point all breakpoint locations are re-created by GDB.
Therefore this patch has chosen to be non-intrusive:
it's up to the Python user to re-request the locations if
they become invalid.

Also there's event handlers that handle new object files etc, if a Python
user is storing breakpoint locations in some larger state they've
built up, refreshing the locations is easy and it only comes
with runtime overhead when the Python user wants to use them.

gdb.BreakpointLocation Python type
struct "gdbpy_breakpoint_location_object" is found in python-internal.h

Its definition, layout, methods and functions
are found in the same file as gdb.Breakpoint (py-breakpoint.c)

1 change was also made to breakpoint.h/c to make it possible
to enable and disable a bp_location* specifically,
without having its LOC_NUM, as this number
also can change arbitrarily behind the scenes.

Updated docs & news file as per request.

Testsuite: tests the .source attribute and the disabling of
individual locations.

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

Change-Id: I302c1c50a557ad59d5d18c88ca19014731d736b0

gdb/gdb_mbuild.sh: use return instead of continue to avoid shellcheck error

Fix:

    In gdb_mbuild.sh line 174:
                continue
                ^------^ SC2104 (error): In functions, use return instead of continue.

Change-Id: I5ce95b01359c5cfbb1612f2f48b80bfeea66c96c

Automatic date update in version.in

Automatic date update in version.in

gprofng: check for the makeinfo version

gprofng/ChangeLog
2022-07-25  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29368
* configure.ac: Check for the makeinfo version.
* configure: Rebuild.

gdb/linux_nat: Write memory using ptrace if /proc/pid/mem is not writable

Commit 05c06f318fd9a112529dfc313e6512b399a645e4 enabled GDB to access
memory while threads are running.  It did this by accessing
/proc/PID/task/LWP/mem.

Unfortunately, this interface is not implemented for writing in older
kernels (such as RHEL6).  This means that GDB is unable to insert
breakpoints on these hosts:

 $ ./gdb -q gdb -ex start
 Reading symbols from gdb...
 Temporary breakpoint 1 at 0x40fdd5: file ../../src/gdb/gdb.c, line 28.
 Starting program: /home/rhel6/fsf/linux/gdb/gdb
 Warning:
 Cannot insert breakpoint 1.
 Cannot access memory at address 0x40fdd5

 (gdb)

Before this patch, linux_proc_xfer_memory_partial (previously called
linux_proc_xfer_partial) would return TARGET_XFER_EOF if the write to
/proc/PID/mem failed. [More specifically, linux_proc_xfer_partial
would not "bother for one word," but the effect is the essentially
same.]

This status was checked by linux_nat_target::xfer_partial, which would
then fallback to using ptrace to perform the operation.

This is the specific hunk that removed the fallback:

-  xfer = linux_proc_xfer_partial (object, annex, readbuf, writebuf,
-                                 offset, len, xfered_len);
-  if (xfer != TARGET_XFER_EOF)
-    return xfer;
+      return linux_proc_xfer_memory_partial (readbuf, writebuf,
+                                            offset, len, xfered_len);
+    }

   return inf_ptrace_target::xfer_partial (object, annex, readbuf, writebuf,
                                          offset, len, xfered_len);

This patch makes linux_nat_target::xfer_partial go straight to writing
memory via ptrace if writing via /proc/pid/mem is not possible in the
running kernel, enabling GDB to insert breakpoints on these older
kernels.  Note that a recent patch changed the return status from
TARGET_XFER_EOF to TARGET_XFER_E_IO.

Tested on {unix,native-gdbserver,native-extended-gdbserver}/-m{32,64}
on x86_64, s390x, aarch64, and ppc64le.

Change-Id: If1d884278e8c4ea71d8836bedd56e6a6c242a415

gdb/linux-nat: Check whether /proc/pid/mem is writable

Probe whether /proc/pid/mem is writable, by using it to write to a GDB
variable.  This will be used in the following patch to avoid falling
back to writing to inferior memory with ptrace if /proc/pid/mem _is_
writable.

Change-Id: If87eff0b46cbe5e32a583e2977a9e17d29d0ed3e

gdb: LoongArch: Handle the function return value

According to LoongArch ELF ABI specification [1], handle the function
return value of various types.

[1] https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_return_values

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

gdb: LoongArch: Fix code style issues

Fix some code style issues suggested by Tom Tromey and Andrew Burgess,
thank you.

(1) Put an introductory comment to explain the purpose for some functions.

(2) Modify the the attribute code to make it portable.

(3) Remove globals and pass pointers to locals.

(4) Remove "*" in the subsequent comment lines.

(5) Put two spaces before "{" and "}".

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

Stop the linker from complaining about RWX segments in sparc-solaris targets.

PR 29411
* configure.tgt (ac_default_ld_warn_rwx_segments): Disable for
sparc-solaris configurations.

[gdb/testsuite] Fix gdb.opt/inline-small-func.exp with clang

When running test-case gdb.opt/inline-small-func.exp with clang 12.0.1, I run
into:
...
gdb compile failed, /usr/bin/ld: inline-small-func0.o: in function `main':
inline-small-func.c:21: undefined reference to `callee'
clang-12.0: error: linker command failed with exit code 1 \
  (use -v to see invocation)
UNTESTED: gdb.opt/inline-small-func.exp: failed to prepare
...

Fix this by using __attribute__((always_inline)).

Tested on x86_64-linux.

PowerPC32 ld test fails with --enable-targets=all

Three pppc32 ld tests fail when spe support is included in the linker
due to this snippet in ld/emulparams/elf32ppc.sh.

if grep -q 'ld_elf32_spu_emulation' ldemul-list.h; then
  DATA_START_SYMBOLS="${RELOCATING+*crt1.o(.data .data.* .gnu.linkonce.d.*)
    PROVIDE (__spe_handle = .);
    *(.data.spehandle)
    . += 4 * (DEFINED (__spe_handle) || . != 0);}"
fi

* testsuite/ld-powerpc/tlsexe32.r: Pass with .data section present.
* testsuite/ld-powerpc/tlsexe32no.r: Likewise.
* testsuite/ld-powerpc/tlsso32.r: Likewise.

gdb/hurd: pass memory_tagged as false to find_memory_region_ftype

I tried building GDB on GNU/Hurd, and ran into this error:

  CXX    gnu-nat.o
gnu-nat.c: In member function ‘virtual int gnu_nat_target::find_memory_regions(find_memory_region_ftype, void*)’:
gnu-nat.c:2620:21: error: too few arguments to function
 2620 |             (*func) (last_region_address,
      |             ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
 2621 |                      last_region_end - last_region_address,
      |                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2622 |                      last_protection & VM_PROT_READ,
      |                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2623 |                      last_protection & VM_PROT_WRITE,
      |                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2624 |                      last_protection & VM_PROT_EXECUTE,
      |                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2625 |                      1, /* MODIFIED is unknown, pass it as true.  */
      |                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2626 |                      data);
      |                      ~~~~~
gnu-nat.c:2635:13: error: too few arguments to function
 2635 |     (*func) (last_region_address, last_region_end - last_region_address,
      |     ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2636 |              last_protection & VM_PROT_READ,
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2637 |              last_protection & VM_PROT_WRITE,
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2638 |              last_protection & VM_PROT_EXECUTE,
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2639 |              1, /* MODIFIED is unknown, pass it as true.  */
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 2640 |              data);
      |              ~~~~~
make[2]: *** [Makefile:1926: gnu-nat.o] Error 1

This is because in this commit:

  commit 68cffbbd4406b4efe1aa6e18460b1d7ca02549f1
  Date:   Thu Mar 31 11:42:35 2022 +0100

      [AArch64] MTE corefile support

Added a new argument to find_memory_region_ftype, but did not pass it to
the function in gnu-nat.c.  Fix this by passing memory_tagged as false.

As Luis pointed out, similar bugs may also appear on FreeBSD and NetBSD,
and I have reproduced them on both systems.  This patch fixes them
incidentally.

Tested by rebuilding on GNU/Hurd, FreeBSD/amd64 and NetBSD/amd64.

gdb/netbsd: add missing header file

I ran into this error when building GDB on NetBSD:

  CXX    netbsd-nat.o
netbsd-nat.c: In member function 'virtual bool nbsd_nat_target::info_proc(const char*, info_proc_what)':
netbsd-nat.c:314:3: error: 'gdb_argv' was not declared in this scope
   gdb_argv built_argv (args);
   ^~~~~~~~
netbsd-nat.c:314:3: note: suggested alternative: 'gdbarch'
   gdb_argv built_argv (args);
   ^~~~~~~~
   gdbarch
netbsd-nat.c:315:7: error: 'built_argv' was not declared in this scope
   if (built_argv.count () == 0)
       ^~~~~~~~~~
netbsd-nat.c:315:7: note: suggested alternative: 'buildargv'
   if (built_argv.count () == 0)
       ^~~~~~~~~~
       buildargv
gmake[2]: *** [Makefile:1893: netbsd-nat.o] Error 1

Fix this by adding the missing header file, as it is obvious.

Tested by rebuilding on NetBSD/amd64.

Updated translations for various sub-directories

gdb: rename gdbarch_tdep struct to fix g++ 4.8 build

After the commit:

  commit 08106042d9f5fdff60c129bf33190639f1a98b2a
  Date:   Thu May 19 13:20:17 2022 +0100

      gdb: move the type cast into gdbarch_tdep

GDB would no longer build using g++ 4.8.  The issue appears to be some
confusion caused by GDB having 'struct gdbarch_tdep', but also a
templated function called 'gdbarch_tdep'.  Prior to the above commit
the gdbarch_tdep function was not templated, and this compiled just
fine.  Note that the above commit compiles just fine with later
versions of g++, so this issue was clearly fixed at some point, though
I've not tried to track down exactly when.

In this commit I propose to fix the g++ 4.8 build problem by renaming
'struct gdbarch_tdep' to 'struct gdbarch_tdep_base'.  This rename
better represents that the struct is only ever used as a base class,
and removes the overloading of the name, which allows GDB to build
with g++ 4.8.

I've also updated the comment on 'struct gdbarch_tdep_base' to fix a
typo, and the comment on the 'gdbarch_tdep' function, to mention that
in maintainer mode a run-time type check is performed.

Fix indentation in loongarch code, preventing a compile time warning.

gdb/varobj: Fix varobj_invalidate_iter

The varobj_invalidate function is meant to be called when restarting a
process, and check at this point if some of the previously existing
varobj can be recreated in the context of the new process.

Two kind of varobj are subject to re-creation:  global varobj (i.e.
varobj which reference a global variable), and floating varobj (i.e.
varobj which are always re-evaluated in the context of whatever is
the currently selected frame at the time of evaluation).

However, in the re-creation process, the varobj_invalidate_iter
recreates floating varobj as non-floating, due to an invalid parameter.
This patches fixes this and adds an assertion to check that if a varobj
is indeed recreated, it matches the original varobj "floating" property.

Another issue is that if at this recreation time the expression watched
by the floating varobj is not in scope, then the varobj is marked as
invalid.  If later the user selects a frame where the expression becomes
valid, the varobj remains invalid and this is wrong.  This patch also
make sure that floating varobj are not invalidated if they cannot be
evaluated.

The last important thing to note is that due to the previous patch, when
varobj_invalidate is executed (in the context of a new process), any
global var have already been invalidated (this has been done when the
objfile it referred to got invalidated).  As a consequence,
varobj_invalidate tries to recreate vars which are already marked as
invalid.  This does not entirely feels right, but I keep this behavior
for backward compatibility.

Tested on x86_64-linux

gdb/varobj: Fix use after free in varobj

Varobj object contains references to types, variables (i.e. struct
variable) and expression.  All of those can reference data on an
objfile's obstack.  It is possible for this objfile to be deleted (and
the obstack to be feed), while the varobj remains valid.  Later, if the
user uses the varobj, this will result in a use-after-free error.  With
address sanitizer build, this leads to a plain error.  For non address
sanitizer build we might see undefined behaviour, which manifest
themself as assertion failures when accessing data backed by feed
memory.

This can be observed if we create a varobj that refers to ta symbol in a
shared library, after either the objfile gets reloaded (using the `file`
command) or after the shared library is unloaded (with a call to dlclose
for example).

This patch fixes those issues by:

- Adding cleanup procedure to the free_objfile observable.  When
  activated this observer clears expressions referencing the objfile
  being freed, and removes references to blocks belonging to this
  objfile.
- Adding varobj support in the `preserve_values` (gdb.value.c).  This
  ensures that before the objfile is unloaded, any type owned by the
  objfile referenced by the varobj is replaced by an equivalent type
  not owned by the objfile.  This process is done here instead of in the
  free_objfile observer in order to reuse the type hash table already
  used for similar purpose when replacing types of values kept in the
  value history.

This patch also makes sure to keep a reference to the expression's
gdbarch and language_defn members when the varobj->root->exp is
initialized.  Those structures outlive the objfile, so this is safe.
This is done because those references might be used initialize a python
context even after exp is invalidated.  Another approach could have been
to initialize the python context with default gdbarch and language_defn
(i.e. nullptr) if expr is NULL, but since we might still try to display
the value which was obtained by evaluating exp when it was still valid,
keeping track of the context which was used at this time seems
reasonable.

Tested on x86_64-Linux.

Co-Authored-By: Pedro Alves <pedro@palves.net>

MI: mi_runto -pending

With the CLI testsuite's runto proc, we can pass "allow-pending" as an
option, like:

  runto func allow-pending

That is currently not possible with MI's mi_runto, however.  This
patch makes it possible, by adding a new "-pending" option to
mi_runto.

A pending breakpoint shows different MI attributes compared to a
breakpoint with a location, so the regexp returned by
mi_make_breakpoint isn't suitable.  Thus, add a new
mi_make_breakpoint_pending proc for pending breakpoints.

Tweak mi_runto to let it take and pass down arguments.

Change-Id: I185fef00ab545a1df2ce12b4dbc3da908783a37c

Automatic date update in version.in

gprofng: fix bug 29356 - Execution fails if gprofng is not included in PATH

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

PR gprofng/29356
* gp-display-html/gp-display-html.in: fixed a problem to execute
gp-display-text in case gprofng is not included in the search
path.

gprofng: fix bug 29392 - Unexpected line format in summary file

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

PR gprofng/29392
* gp-display-html/gp-display-html.in: modified a regex, plus the
code to handle the results; renamed a variable to improve the
consistency in naming.

gprofng: fix bug 29353 - Fix a lay-out issue in the html disassembly files

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

PR gprofng/29353
* gp-display-html/gp-display-html.in: fixed a problem in the
generation of html for the disassembly where instructions
without arguments were not handled correctly.

gprofng: fix bug 29352 - Fix the message Hexadecimal number > 0xffffffff non-portable

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

PR gprofng/29352
* gp-display-html/gp-display-html.in: the hex subroutine from
the bigint module is now used.

gprofng: fix bug 29351 - Move dynamic loading of modules to a later stage

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

PR gprofng/29351
* gp-display-html/gp-display-html.in: the dynamic loading of
modules occurred too early, resulting in the generation of the
man page to fail in case a module is missing; the loading part is
now done somewhat later in the execution to avoid this problem.

set/show python dont-write-bytecode fixes

GDB uses the environment variable PYTHONDONTWRITEBYTECODE to
determine whether or not to write the result of byte-compiling
python modules when the "python dont-write-bytecode" setting
is "auto".  Simon noticed that GDB's implementation doesn't
follow the Python documentation.

At present, GDB only checks for the existence of this environment
variable.  That is not sufficient though.  Regarding
PYTHONDONTWRITEBYTECODE, this document...

    https://docs.python.org/3/using/cmdline.html

...says:

    If this is set to a non-empty string, Python won't try to write
    .pyc files on the import of source modules.

This commit fixes GDB's handling of PYTHONDONTWRITEBYTECODE by adding
an empty string check.

This commit also corrects the set/show command documentation for
"python dont-write-bytecode".  The current doc was just a copy
of that for set/show python ignore-environment.

During his review of an earlier version of this patch, Eli Zaretskii
asked that the help text that I proposed for "set/show python
dont-write-bytecode" be expanded.  I've done that in addition to
clarifying the documentation of this option in the GDB manual.

gdb/python: fix invalid use disassemble_info::stream

After this commit:

  commit 81384924cdcc9eb2676dd9084b76845d7d0e0759
  Date:   Tue Apr 5 11:06:16 2022 +0100

      gdb: have gdb_disassemble_info carry 'this' in its stream pointer

The disassemble_info::stream field will no longer be a ui_file*.  That
commit failed to update one location in py-disasm.c though.

While running some tests using the Python disassembler API, I
triggered a call to gdbpy_disassembler::print_address_func, and, as I
had compiled GDB with the undefined behaviour sanitizer, GDB crashed
as the code currently (incorrectly) casts the stream field to be a
ui_file*.

In this commit I fix this error.

In order to test this case I had to tweak the existing test case a
little.  I also spotted some debug printf statements in py-disasm.py,
which I have removed.

gdb: fix use of uninitialised gdb_printing_disassembler::m_in_comment

Simon pointed out that gdb_printing_disassembler::m_in_comment can be
used uninitialised by the Python disassembler API code.  This issue
was spotted when GDB was built with the undefined behaviour sanitizer,
and causes the gdb.python/py-disasm.exp test to fail like this:

  (gdb) PASS: gdb.python/py-disasm.exp: global_disassembler=GlobalPreInfoDisassembler: python add_global_disassembler(GlobalPreInfoDisassembler)
  disassemble main
  Dump of assembler code for function main:
     0x0000555555555119 <+0>:     push   %rbp
     0x000055555555511a <+1>:     mov    %rsp,%rbp
     0x000055555555511d <+4>:     nop
  /home/user/src/binutils-gdb/gdb/disasm.h:144:12: runtime error: load of value 118, which is not a valid value for type 'bool'

The problem is that in disasmpy_builtin_disassemble we create a new
instance of gdbpy_disassembler, which is a sub-class of
gdb_printing_disassembler, however, the m_in_comment field is never
initialised.

This commit fixes the issue by providing a default initialisation
value for m_in_comment in disasm.h.  As we only ever disassemble a
single instruction in disasmpy_builtin_disassemble then we don't need
to worry about reseting m_in_comment back to false after the single
instruction has been disassembled.

With this commit the above issue is resolved and
gdb.python/py-disasm.exp now passes.

ld: Compile 2 CTF tests with -O2

When GCC 12 is used to build binutils with -O0, the following 2 tests
failed:

FAIL: Conflicted data syms, partially indexed, stripped, with variables
FAIL: Conflicted data syms, partially indexed, stripped

Compile 2 tests with -O2 to avoid test failures.

PR ld/29378
* testsuite/ld-ctf/data-func-conflicted-vars.d: Compile with -O2.
* testsuite/ld-ctf/data-func-conflicted.d: Likewise.

struct packed: Add fallback byte array implementation

Attribute gcc_struct is not implemented in Clang targeting Windows, so
add a fallback standard-conforming implementation based on arrays.

I ran the testsuite on x86_64 GNU/Linux with this implementation
forced, and saw no regressions.

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

Change-Id: I023315ee03622c59c397bf4affc0b68179c32374

struct packed: Unit tests and more operators

For PR gdb/29373, I wrote an alternative implementation of struct
packed that uses a gdb_byte array for internal representation, needed
for mingw+clang.  While adding that, I wrote some unit tests to make
sure both implementations behave the same.  While at it, I implemented
all relational operators.  This commit adds said unit tests and
relational operators.  The alternative gdb_byte array implementation
will come next.

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

Change-Id: I023315ee03622c59c397bf4affc0b68179c32374

struct packed: Use gcc_struct on Windows

Building GDB on mingw/gcc hosts is currently broken, due to a static
assertion failure in gdbsupport/packed.h:

  In file included from ../../../../../binutils-gdb/gdb/../gdbsupport/common-defs.h:201,
   from ../../../../../binutils-gdb/gdb/defs.h:28,
   from ../../../../../binutils-gdb/gdb/dwarf2/read.c:31:
  ../../../../../binutils-gdb/gdb/../gdbsupport/packed.h: In instantiation of 'packed<T, Bytes>::packed(T) [with T = dwarf_unit_type; long long unsigned int Bytes = 1]':
  ../../../../../binutils-gdb/gdb/dwarf2/read.h:181:74:   required from here
  ../../../../../binutils-gdb/gdb/../gdbsupport/packed.h:41:40: error: static assertion failed
     41 |     gdb_static_assert (sizeof (packed) == Bytes);
|                        ~~~~~~~~~~~~~~~~^~~~~~~~
  ../../../../../binutils-gdb/gdb/../gdbsupport/gdb_assert.h:27:48: note: in definition of macro 'gdb_static_assert'
     27 | #define gdb_static_assert(expr) static_assert (expr, "")
|                                                ^~~~
  ../../../../../binutils-gdb/gdb/../gdbsupport/packed.h:41:40: note: the comparison reduces to '(4 == 1)'
     41 |     gdb_static_assert (sizeof (packed) == Bytes);
|                        ~~~~~~~~~~~~~~~~^~~~~~~~

The issue is that mingw gcc defaults to "-mms-bitfields", which
affects how bitfields are laid out.  We can however tell GCC that we
want the regular GCC layout instead using attribute gcc_struct.

Attribute gcc_struct is not implemented in "clang -target
x86_64-pc-windows-gnu", so that will need a different fix.

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

Change-Id: I023315ee03622c59c397bf4affc0b68179c32374

binutils-gdb/git: highlight whitespace errors in source files

For a long time I've had this in my ~/.gitconfig:

  [core]
          whitespace = space-before-tab,indent-with-non-tab,trailing-space

which causes git to show me if I muck up and use spaces instead of
tabs, or leave in trailing whitespace.  I find this really useful.

I recently proposed adding something like this to the .gitattributes
files for the GDB sub-directories (gdb, gdbsupport, and gdbserver)[1],
however, the question was asked - couldn't this be done at the top
level?

So, in this commit, I propose to update the top-level .gitattributes
file, after this commit, any git diff on a C, C++, Expect, or TCL
source file, will highlight the following whitespace errors:

  (a) Use a space before a tab at the start of a line,

  (b) Use of spaces where a tab could be used at the start of a line,
  and

  (c) Any trailing whitespace.

Errors are only highlighted in the diff on new or modified lines, so
you don't get spammed for errors on context lines that you haven't
modified.

The only downside I see to adding this at the top level is if there
are any sub-directories that don't follow the tabs/spaces indentation
rules very well already, in those directories you'll end up hitting
issues any time you edit a line.  For GDB we're usually pretty good,
so having this highlighting isn't an issue.

[1] https://sourceware.org/pipermail/gdb-patches/2022-July/190843.html

gdb/arm: Sync sp with other *sp registers

For Arm Cortex-M33 with security extensions, there are 4 different
stack pointers (msp_s, msp_ns, psp_s, psp_ns), without security
extensions and for other Cortex-M targets, there are 2 different
stack pointers (msp and psp).

With this patch, sp will always be in sync with one of the real stack
pointers on Arm targets that contain more than one stack pointer.

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

gdb/arm: Use if-else if instead of switch

As the register numbers for the alternative Arm SP registers are not
constant, it's not possible to use switch statement to define the
rules.  In order to not have a mix, replace the few existing
switch statements with regular if-else if statements

Remove dead code from windows_nat_target::detach

windows_nat_target::detach has a variable 'detached' that is only set
after a call to 'error'.  However, this can't happen because 'error'
throws an exception.

This patch removes the dead code.

gdb: handle dis_style_sub_mnemonic disassembler style

In commit:

  commit 4f46c0bc36471b725de0253bfec1a42a36e2c5c5
  Date:   Mon Jul 4 17:45:25 2022 +0100

      opcodes: add new sub-mnemonic disassembler style

I added a new disassembler style dis_style_sub_mnemonic, but forgot to
add GDB support for this style.  Fix this oversight in this commit.

libopcodes/ppc: add support for disassembler styling

This commit adds disassembler styling to the libopcodes ppc
disassembler.  This conversion was pretty straight forward, I just
converted the fprintf_func calls to fprintf_styled_func calls and
added an appropriate style.

For testing the new styling I just assembled then disassembled the
source files in gas/testsuite/gas/ppc and manually checked that the
styling looked reasonable.

I think the only slightly weird case was how things like '4*cr1+eq'
are styled.  As best I can tell, this construct, used for example in
this instruction:

  crand   4*cr1+lt,4*cr1+gt,4*cr1+eq

is used to access a field of a control register.  I initially tried
styling this whole construct as a register[1], but during review it
was suggested that instead different parts of the text should have
different styles.  In this commit I propose styling '4*cr1+lt' like
this:

  4    - immediate,
  *    - text,
  cr1  - register
  +    - text
  lt   - sub-mnemonic

If the user does not request styled output from objdump, then there
should be no change in the disassembler output after this commit.

[1] https://sourceware.org/pipermail/binutils/2022-July/121771.html

opcodes: add new sub-mnemonic disassembler style

When adding libopcodes disassembler styling support for AArch64, it
feels like the results would be improved by having a new sub-mnemonic
style.  This will be used in cases like:

  add    w16, w7, w1, uxtb #2
                      ^^^^----- Here

And:

  cinc   w0, w1, ne
                 ^^----- Here

This commit just adds the new style, and prepares objdump to handle
the style.  A later commit will add AArch64 styling, and will actually
make use of the style.

As this style is currently unused, there should be no user visible
changes after this commit.

LoongArch: Add testcases for new relocate types.

  gas/testsuite/gas/all/
    gas.exp
  gas/testsuite/gas/loongarch/
    jmp_op.d
    jmp_op.s
    macro_op.d
    macro_op.s
    macro_op_32.d
    macro_op_32.s
    macro_op_large_abs.d
    macro_op_large_abs.s
    macro_op_large_pc.d
    macro_op_large_pc.s
    reloc.d
    reloc.s

  ld/testsuite/ld-elf/
    pr26936.d
    shared.exp
  ld/testsuite/ld-loongarch-elf/
    attr-ifunc-4.c
    attr-ifunc-4.out
    disas-jirl.d
    ifunc.exp
    jmp_op.d
    jmp_op.s
    libnopic-global.s
    macro_op.d
    macro_op.s
    macro_op_32.d
    macro_op_32.s
    nopic-global-so.rd
    nopic-global-so.sd
    nopic-global.out
    nopic-global.s
    nopic-global.sd
    nopic-global.xd
    nopic-local.out
    nopic-local.rd
    nopic-local.s
    nopic-local.sd
    nopic-local.xd
    nopic-weak-global-so.rd
    nopic-weak-global-so.sd
    nopic-weak-global.out
    nopic-weak-global.s
    nopic-weak-global.sd
    nopic-weak-global.xd
    nopic-weak-local.out
    nopic-weak-local.rd
    nopic-weak-local.s
    nopic-weak-local.sd
    nopic-weak-local.xd
    pic.exp
    pic.ld

bfd: Delete R_LARCH_NONE from dyn info of LoongArch.

  Some R_LARCH_64 in section .eh_frame will to generate
  R_LARCH_NONE, we change relocation to R_LARCH_32_PCREL
  from R_LARCH_64 in setction .eh_frame and not generate
  dynamic relocation for R_LARCH_32_PCREL.

  Add New relocate type R_LARCH_32_PCREL for .eh_frame.

  include/elf/
    loongarch.h

  bfd/
    bfd/bfd-in2.h
    libbfd.h
    reloc.c
    elfxx-loongarch.c
    elfnn-loongarch.c

  gas/config/
    tc-loongarch.c

  binutils/
    readelf.c

  ld/testsuite/ld-elf/
    eh5.d

LoongArch: Move ifunc info to rela.dyn from rela.plt.

  Delete R_LARCH_IRELATIVE from dynamic loader (glibc ld.so) when
  loading lazy function (rela.plt section).

  In dynamic programes, move ifunc dynamic relocate info to section
  srelgot from srelplt.

  bfd/
    elfnn-loongarch.c

LoongArch: gas: Add new reloc types.

  Generate new relocate types while use new macro insns.

  gas/config/
    loongarch-lex.h
    loongarch-parse.y
    tc-loongarch.c
    tc-loongarch.h

LoongArch:opcodes: Add new reloc types.

  opcodes: Replace old insns with news and generate new relocate types
  while macro insns expanding.

  opcodes/
    loongarch-opc.c

bfd: Add supported for LoongArch new relocations.

  Define new reloc types according to linker needs.

  include/elf/
    loongarch.h

  bfd/
    bfd-in2.h
    libbfd.h
    reloc.c
    elfnn-loongarch.c
    elfxx-loongarch.c
    elfxx-loongarch.h

Re: PowerPC64 .branch_lt address

On seeing PR29369 my suspicion was naturally on a recent powerpc64
change, commit 0ab80031430e.  Without a reproducer, I spent time
wondering what could have gone wrong, and while I doubt this patch
would have fixed the PR, there are some improvements that can be made
to cater for user silliness.

I also noticed that when -z relro -z now sections are created out of
order, with .got before .plt in the section headers but .got is laid
out at a higher address.  That's due to the address expression for
.branch_lt referencing SIZEOF(.got) and so calling init_os (which
creates a bfd section) for .got before the .plt section is created.
Fix that by ignoring SIZEOF in exp_init_os.  Unlike ADDR and LOADADDR
which need to reference section vma and lma respectively, SIZEOF can
and does cope with a missing bfd section by returning zero for its
size, which of course is correct.

PR 29369
* ldlang.c (exp_init_os): Don't create a bfd section for SIZEOF.
* emulparams/elf64ppc.sh (OTHER_RELRO_SECTIONS_2): Revise
.branch_lt address to take into account possible user sections
with alignment larger than 8 bytes.

Automatic date update in version.in

gdb/testsuite: add a clear test to py-breakpoint.exp

This patch adds a test case to try to clear an internal python
breakpoint using the clear command.

This was suggested by Pedro during a code review of the following
commit.

  commit a5c69b1e49bae4d0dcb20f324cebb310c63495c6
  Date:   Sun Apr 17 15:09:46 2022 +0800

    gdb: fix using clear command to delete non-user breakpoints(PR cli/7161)

Tested on x86_64 openSUSE Tumbleweed.

gdb/testsuite: rename get_maint_bp_addr and move it to gdb-utils.exp

The get_maint_bp_addr procedure will be shared by other test suite, so
move it to gdb-utils.exp.

Following Andrew's suggestion, I renamed get_maint_bp_addr to
gdb_get_bp_addr, since it would have handled normal breakpoints in
addition to the internal ones.  Note that there is still room for
improvement in this procedure, which I indicated in comments nearby.

Automatic date update in version.in

Automatic date update in version.in

[gdb/symtab] Fix duplicate CUs in all_comp_units

When running test-case gdb.cp/cpexprs-debug-types.exp with target board
cc-with-debug-names on a system with gcc 12.1.1 (defaulting to dwarf 5), I
run into:
...
(gdb) file cpexprs-debug-types^M
Reading symbols from cpexprs-debug-types...^M
warning: Section .debug_aranges in cpexprs-debug-types has duplicate \
  debug_info_offset 0x0, ignoring .debug_aranges.^M
gdb/dwarf2/read.h:309: internal-error: set_length: \
  Assertion `m_length == length' failed.^M
...

The exec contains a .debug_names section, which gdb rejects due to
.debug_names containing a list of TUs, while the exec doesn't contain a
.debug_types section (which is what you'd expect for dwarf 4).

Gdb then falls back onto the cooked index, which calls create_all_comp_units
to create all_comp_units.  However, the failed index reading left some
elements in all_comp_units, so we end up with duplicates in all_comp_units,
which causes the misleading complaint and the assert.

Fix this by:
- asserting at the start of create_all_comp_units that all_comp_units is empty,
  as we do in create_cus_from_index and create_cus_from_debug_names, and
- cleaning up all_comp_units when failing in dwarf2_read_debug_names.

Add a similar cleanup in dwarf2_read_gdb_index.

Tested on x86_64-linux.

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

gdb/testsuite: give binaries distinct names in Ada tests

Some Ada tests repeat their test sequence with different gnat-encodings,
typically "all" and "minimal".  However, they give the same name to both
binaries, meaning the second run overwrites the binary of the first run.
This makes it difficult and confusing when trying to reproduce problems
manually with the test artifacts.  Change those tests to use unique
names for each pass.

Change-Id: Iaa3c9f041241249a7d67392e785c31aa189dcc88

Change target_ops::async to accept bool

This changes the parameter of target_ops::async from int to bool.
Regression tested on x86-64 Fedora 34.

Fix typo in windows-nat.c

I noticed a typo in a printf in windows-nat.c.  This fixes it.

[gdb] Add empty range unit test for gdb::parallel_for_each

Add a unit test that verifies that we can call gdb::parallel_for_each with an
empty range.

Tested on x86_64-linux.

PR17122, OSX 10.9 build failure

sbrk hasn't been used in binutils/ or ld/ for quite some time (so the
PR was fixed a while ago).  Tidy up configury.

PR 17122
binutils/
* configure.ac: Don't check for sbrk.
* sysdep.h (sbrk): Don't supply fallback declaration.
* config.in: Regenerate.
* configure: Regenerate.
ld/
* configure.ac: Don't check for sbrk.
* config.in: Regenerate.
* configure: Regenerate.

gdb/csky modify registers list for general_reggroup

There are two modification points here:
1. For the debugging of csky architecture, after executing "info register",
   we hope to print out GPRs, PC and the registers related to exceptions.
2. With tdesc-xml, users can view the register groups described in XML.

PR15951, binutils testsuite builds status wrapper unconditionally

PR 15951
* testsuite/binutils-all/objcopy.exp: Build testglue.o when
needs_status_wrapper.

Automatic date update in version.in

Add ChangeLog entry from previous commit

PowerPC: Create new MMA instruction masks and use them

The MMA instructions use XX3_MASK|3<<21 as an instruction mask, but that
misses the RC bit/bit 31, so if we disassemble a .long that represents an
MMA instruction except that it also has bit 31 set, we will erroneously
disassemble it to that MMA instruction.  We create new masks defines that
contain bit 31 so that doesn't happen anymore.

opcodes/
* ppc-opc.c (XACC_MASK, XX3ACC_MASK): New defines.
(P_GER_MASK, xxmfacc, xxmtacc, xxsetaccz, xvi8ger4pp, xvi8ger4,
xvf16ger2pp, xvf16ger2, xvf32gerpp, xvf32ger, xvi4ger8pp, xvi4ger8,
xvi16ger2spp, xvi16ger2s, xvbf16ger2pp, xvbf16ger2, xvf64gerpp,
xvf64ger, xvi16ger2, xvf16ger2np, xvf32gernp, xvi8ger4spp, xvi16ger2pp,
xvbf16ger2np, xvf64gernp, xvf16ger2pn, xvf32gerpn, xvbf16ger2pn,
xvf64gerpn, xvf16ger2nn, xvf32gernn, xvbf16ger2nn, xvf64gernn: Use them.

i386: Don't allow GOTOFF relocation against IFUNC symbol for PIC

We can't use the PLT entry as the function address for PIC since the PIC
register may not be set up properly for indirect call.

bfd/

PR ld/27998
* elf32-i386.c (elf_i386_relocate_section): Don't allow GOTOFF
relocation against IFUNC symbol for PIC.

ld/

PR ld/27998
* testsuite/ld-i386/pr27998a.d: Replace -shared with -e bar.
* testsuite/ld-i386/pr27998b.d: Expect a linker error.
* testsuite/ld-ifunc/ifunc-2-i386-now.d: Updated.
* testsuite/ld-ifunc/ifunc-2-local-i386-now.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-i386.s: Replace @GOTOFF with @GOT.
* testsuite/ld-ifunc/ifunc-2-local-i386.s: Likewise.

gdb: ensure the cast in gdbarch_tdep is valid

This commit makes use of gdb::checked_static_cast when casting the
generic gdbarch_tdep pointer to a specific sub-class type.  This means
that, when compiled in developer mode, GDB will validate that the cast
is correct.

In order to use gdb::checked_static_cast the types involved must have
RTTI, which is why the gdbarch_tdep base class now has a virtual
destructor.

Assuming there are no bugs in GDB where we cast a gdbarch_tdep pointer
to the wrong type, then there should be no changes after this commit.

If any bugs do exist, then GDB will now assert (in a developer build).

gdbsupport: add checked_static_cast

This commit was inspired by these mailing list posts:

  https://sourceware.org/pipermail/gdb-patches/2022-June/190323.html
  https://sourceware.org/pipermail/gdb-patches/2022-April/188098.html

The idea is to add a new function gdb::checked_static_cast, which can,
in some cases, be used as a drop-in replacement for static_cast.  And
so, if I previously wrote this:

  BaseClass *base = get_base_class_pointer ();
  DerivedClass *derived = static_cast<DerivedClass *> (base);

I can now write:

  BaseClass *base = get_base_class_pointer ();
  DerivedClass *derived = gdb::checked_static_cast<DerivedClass *> (base);

The requirement is that BaseClass and DerivedClass must be
polymorphic.

The benefit of making this change is that, when GDB is built in
developer mode, a run-time check will be made to ensure that `base`
really is of type DerivedClass before the cast is performed.  If
`base` is not of type DerivedClass then GDB will assert.

In a non-developer build gdb::checked_static_cast is equivalent to a
static_cast, and there should be no performance difference.

This commit adds the support function, but does not make use of this
function, a use will be added in the next commit.

Co-Authored-By: Pedro Alves <pedro@palves.net>
Co-Authored-By: Tom Tromey <tom@tromey.com>

gdb: move the type cast into gdbarch_tdep

I built GDB for all targets on a x86-64/GNU-Linux system, and
then (accidentally) passed GDB a RISC-V binary, and asked GDB to "run"
the binary on the native target.  I got this error:

  (gdb) show architecture
  The target architecture is set to "auto" (currently "i386").
  (gdb) file /tmp/hello.rv32.exe
  Reading symbols from /tmp/hello.rv32.exe...
  (gdb) show architecture
  The target architecture is set to "auto" (currently "riscv:rv32").
  (gdb) run
  Starting program: /tmp/hello.rv32.exe
  ../../src/gdb/i387-tdep.c:596: internal-error: i387_supply_fxsave: Assertion `tdep->st0_regnum >= I386_ST0_REGNUM' failed.

What's going on here is this; initially the architecture is i386, this
is based on the default architecture, which is set based on the native
target.  After loading the RISC-V executable the architecture of the
current inferior is updated based on the architecture of the
executable.

When we "run", GDB does a fork & exec, with the inferior being
controlled through ptrace.  GDB sees an initial stop from the inferior
as soon as the inferior comes to life.  In response to this stop GDB
ends up calling save_stop_reason (linux-nat.c), which ends up trying
to read register from the inferior, to do this we end up calling
target_ops::fetch_registers, which, for the x86-64 native target,
calls amd64_linux_nat_target::fetch_registers.

After this I eventually end up in i387_supply_fxsave, different x86
based targets will end in different functions to fetch registers, but
it doesn't really matter which function we end up in, the problem is
this line, which is repeated in many places:

  i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch);

The problem here is that the ARCH in this line comes from the current
inferior, which, as we discussed above, will be a RISC-V gdbarch, the
tdep field will actually be of type riscv_gdbarch_tdep, not
i386_gdbarch_tdep.  After this cast we are relying on undefined
behaviour, in my case I happen to trigger an assert, but this might
not always be the case.

The thing I tried that exposed this problem was of course, trying to
start an executable of the wrong architecture on a native target.  I
don't think that the correct solution for this problem is to detect,
at the point of cast, that the gdbarch_tdep object is of the wrong
type, but, I did wonder, is there a way that we could protect
ourselves from incorrectly casting the gdbarch_tdep object?

I think that there is something we can do here, and this commit is the
first step in that direction, though no actual check is added by this
commit.

This commit can be split into two parts:

 (1) In gdbarch.h and arch-utils.c.  In these files I have modified
 gdbarch_tdep (the function) so that it now takes a template argument,
 like this:

    template<typename TDepType>
    static inline TDepType *
    gdbarch_tdep (struct gdbarch *gdbarch)
    {
      struct gdbarch_tdep *tdep = gdbarch_tdep_1 (gdbarch);
      return static_cast<TDepType *> (tdep);
    }

  After this change we are no better protected, but the cast is now
  done within the gdbarch_tdep function rather than at the call sites,
  this leads to the second, much larger change in this commit,

  (2) Everywhere gdbarch_tdep is called, we make changes like this:

    -  i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch);
    +  i386_gdbarch_tdep *tdep = gdbarch_tdep<i386_gdbarch_tdep> (arch);

There should be no functional change after this commit.

In the next commit I will build on this change to add an assertion in
gdbarch_tdep that checks we are casting to the correct type.

gdb: select suitable thread for gdbarch_adjust_breakpoint_address

The three targets that implement gdbarch_adjust_breakpoint_address are
arm, frv, and mips.  In each of these targets the adjust breakpoint
address function does some combination of reading the symbol table, or
reading memory at the location the breakpoint could be placed.

The problem is that performing these actions requires that the current
inferior and program space be the one in which the breakpoint will be
placed, and this is not currently always the case.

Consider a GDB session with multiple inferiors.  One inferior might be
a native target while another could be a remote target of a completely
different architecture.  Alternatively, if we consider ARM and
AArch64, one native inferior might be AArch64, while a second native
inferior could be ARM.

In these cases it is possible, and valid, for a user to have one
inferior selected, and place a breakpoint in the other inferior by
placing a breakpoint on a particular symbol.

If this happens, then currently, when
gdbarch_adjust_breakpoint_address is called, the wrong inferior (and
program space) will be selected, and memory reads, and symbol look
ups, will not return the expected results, this could lead to
breakpoints being placed in the wrong location.

There are currently two places where gdbarch_adjust_breakpoint_address
is called:

  1. In infrun.c, in the function handle_step_into_function.  In this
  case, I believe that the correct inferior and program space will
  already be selected as this is called as part of the stop event
  handling, so I don't think we need to worry about this case, and

  2. In breakpoint.c, in the function adjust_breakpoint_address, which
  is itself called from code_breakpoint::add_location and
  watch_command_1.

  The watch_command_1 case I don't think we need to worry about, this
  is for when a local watch expression is created, which can only be
  in the currently selected inferior, so this case should be fine.

  The code_breakpoint::add_location case is the one that needs fixing,
  this is what allows a breakpoint to be created between inferiors.

To fix the code_breakpoint::add_location case, I propose that we pass
the "correct" program_space (i.e. the program space in which the
breakpoint will be created) to the adjust_breakpoint_address function.
Then in adjust_breakpoint_address we can make use of
switch_to_program_space_and_thread to switch program_space and
inferior before calling gdbarch_adjust_breakpoint_address.

I discovered this issue while working on a later patch in this
series.  This later patch will detect when we cast the result of
gdbarch_tdep to the wrong type.

With this later patch in place I ran gdb.multi/multi-arch.exp on an
AArch64 target.  In this situation, two inferiors are created, an
AArch64 inferior, and an ARM inferior.  The test selected the AArch64
inferior and tries to create a breakpoint in the ARM inferior.

As a result of this we end up in arm_adjust_breakpoint_address, which
calls arm_pc_is_thumb.  Before this commit the AArch64 inferior would
be current.  As a result, all of the checks in arm_pc_is_thumb would
fail (they rely on reading symbols from the current program space),
and so, at the end of arm_pc_is_thumb we would call
arm_frame_is_thumb.  However, remember, at this point the current
inferior is the AArch64 inferior, so the current frame is an AArch64
frame.

In arm_frame_is_thumb we call arm_psr_thumb_bit, which calls
gdbarch_tdep and casts the result to arm_gdbarch_tdep.  This is wrong,
the tdep field is of type aarch64_gdbarch_tdep.  After this we have
undefined behaviour.

With this patch in place, we will have switched to a thread in the ARM
program space before calling arm_adjust_breakpoint_address.  As a
result, we now succeed in looking up the required symbols in
arm_pc_is_thumb, and so we never call arm_frame_is_thumb.

However, in the worst case scenario, if we did end up calling
arm_frame_is_thumb, as the current inferior should now be the ARM
inferior, the current frame should be an ARM frame, so we still should
not hit undefined behaviour.

I have added an assert to arm_frame_is_thumb.

gdb/mips: rewrite show_mask_address

This commit is similar to the previous commit, but in this case GDB is
actually relying on undefined behaviour.

Consider building GDB for all targets on x86-64/GNU-Linux, then doing
this:

  (gdb) show mips mask-address
  Zeroing of upper 32 bits of 64-bit addresses is auto.
  The 32 bit address mask is set automatically.  Currently disabled
  (gdb)

The 'show mips mask-address' command ends up in show_mask_address in
mips-tdep.c, and this function does this:

  mips_gdbarch_tdep *tdep
    = (mips_gdbarch_tdep *) gdbarch_tdep (target_gdbarch ());

Later we might pass TDEP to mips_mask_address_p.  However, in my
example above, on an x86-64 native target, the current target
architecture will be an x86-64 gdbarch, and the tdep field within the
gdbarch will be of type i386_gdbarch_tdep, not of type
mips_gdbarch_tdep, as a result the cast above was incorrect, and TDEP
is not pointing at what it thinks it is.

I also think the current output is a little confusing, we appear to
have two lines that show the same information, but using different
words.

The first line comes from calling deprecated_show_value_hack, while
the second line is printed directly from show_mask_address.  However,
both of these lines are printing the same mask_address_var value.  I
don't think the two lines actually adds any value here.

Finally, none of the text in this function is passed through the
internationalisation mechanism.

It would be nice to remove another use of deprecated_show_value_hack
if possible, so this commit does a complete rewrite of
show_mask_address.

After this commit the output of the above example command, still on my
x86-64 native target is:

    (gdb) show mips mask-address
    Zeroing of upper 32 bits of 64-bit addresses is "auto" (current architecture is not MIPS).

The 'current architecture is not MIPS' text is only displayed when the
current architecture is not MIPS.  If the architecture is mips then we
get the more commonly seen 'currently "on"' or 'currently "off"', like
this:

  (gdb) set architecture mips
  The target architecture is set to "mips".
  (gdb) show mips mask-address
  Zeroing of upper 32 bits of 64-bit addresses is "auto" (currently "off").
  (gdb)

All the text is passed through the internationalisation mechanism, and
we only call gdbarch_tdep when we know the gdbarch architecture is
bfd_arch_mips.

gdb/arm: move fetch of arm_gdbarch_tdep to a more inner scope

This is a small refactor to resolve an issue before it becomes a
problem in a later commit.

Move the fetching of an arm_gdbarch_tdep into a more inner scope
within two functions in arm-tdep.c.

The problem with the current code is that the functions in question
are used as the callbacks for two set/show parameters.  These set/show
parameters are available no matter the current architecture, but are
really about controlling an ARM architecture specific setting.  And
so, if I build GDB for all targets on an x86-64/GNU-Linux system, I
can still do this:

  (gdb) show arm fpu
  (gdb) show arm abi

After these calls we end up in show_fp_model and arm_show_abi
respectively, where we unconditionally do this:

  arm_gdbarch_tdep *tdep
    = (arm_gdbarch_tdep *) gdbarch_tdep (target_gdbarch ());

However, the gdbarch_tdep() result will only be a arm_gdbarch_tdep if
the current architecture is ARM, otherwise the result will actually be
of some other type.

This isn't actually a problem, as in both cases the use of tdep is
guarded by a later check that the gdbarch architecture is
bfd_arch_arm.

This commit just moves the call to gdbarch_tdep() after the
architecture check.

In a later commit gdbarch_tdep() will be able to spot when we are
casting the result to the wrong type, and this function will trigger
assertion failures if things are not fixed.

There should be not user visible changes after this commit.

[arm] Rename arm_cache_is_sp_register to arm_is_alternative_sp_register

All usages of this helper are really made to check if the register is
one of the alternative SP registers (MSP/MSP_S/MSP_NS/PSP/PSP_S/PSP_NS)
with the ARM_SP_REGNUM case being handled separately.

Signed-off-by: Luis Machado <luis.machado@arm.com>
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>

[gdb/python] Fix typo in test_python

Fix typo in ref_output_0 variable in test_python.

Tested by running the selftest on x86_64-linux with python 3.11.

[gdb/python] Fix python selftest with python 3.11

With python 3.11 I noticed:
...
$ gdb -q -batch -ex "maint selftest python"
Running selftest python.
Self test failed: self-test failed at gdb/python/python.c:2246
Ran 1 unit tests, 1 failed
...

In more detail:
...
(gdb) p output
$5 = "Traceback (most recent call last):\n  File \"<string>\", line 0, \
  in <module>\nKeyboardInterrupt\n"
(gdb) p ref_output
$6 = "Traceback (most recent call last):\n  File \"<string>\", line 1, \
  in <module>\nKeyboardInterrupt\n"
...

Fix this by also allowing line number 0.

Tested on x86_64-linux.

This should hopefully fix buildbot builder gdb-rawhide-x86_64.

[gdbsupport] Fix type of parallel_for_each_debug

When I changed the initialization of parallel_for_each_debug from 0 to false,
I forgot to change the type from int to bool.  Fix this.

Tested by rebuilding on x86_64-linux.

[gdb/symtab] Fix bad compile unit index complaint

I noticed this code in dw2_debug_names_iterator::next:
...
        case DW_IDX_compile_unit:
          /* Don't crash on bad data.  */
          if (ull >= per_bfd->all_comp_units.size ())
            {
              complaint (_(".debug_names entry has bad CU index %s"
                           " [in module %s]"),
                         pulongest (ull),
                         objfile_name (objfile));
              continue;
            }
          per_cu = per_bfd->get_cu (ull);
          break;
...

This code used to DTRT, before we started keeping both CUs and TUs in
all_comp_units.

Fix by using "per_bfd->all_comp_units.size () - per_bfd->tu_stats.nr_tus"
instead.

It's hard to produce a test-case for this, but let's try at least to trigger
the complaint somehow.  We start out by creating an exec with .debug_types and
.debug_names:
...
$ gcc -g ~/hello.c -fdebug-types-section
$ gdb-add-index -dwarf-5 a.out
...
and verify that we don't see any complaints:
...
$ gdb -q -batch -iex "set complaints 100" ./a.out
...

We look at the CU and TU table using readelf -w and conclude that we have
nr_cus == 6 and nr_tus == 1.

Now override ull in dw2_debug_names_iterator::next for the DW_IDX_compile_unit
case to 6, and we have:
...
$ gdb -q -batch -iex "set complaints 100" ./a.out
During symbol reading: .debug_names entry has bad CU index 6 [in module a.out]
...

After this, it still crashes because this code in
dw2_debug_names_iterator::next:
...
  /* Skip if already read in.  */
  if (m_per_objfile->symtab_set_p (per_cu))
    goto again;
...
is called with per_cu == nullptr.

Fix this by skipping the entry if per_cu == nullptr.

Now revert the fix and observe that the complaint disappears, so we've
confirmed that the fix is required.

A somewhat similar issue for .gdb_index in dw2_symtab_iter_next has been filed
as PR29367.

Tested on x86_64-linux, with native and target board cc-with-debug-names.

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

x86: replace wrong attributes on VCVTDQ2PH{X,Y}

A standalone (without SAE) StaticRounding attribute is meaningless, and
indeed all other similar insns have ATTSyntax there instead. I can only
assume this was some strange copy-and-paste mistake.

x86/Intel: correct AVX512F scatter insn element sizes

I clearly screwed up in 6ff00b5e12e7 ("x86/Intel: correct permitted
operand sizes for AVX512 scatter/gather") giving all AVX512F scatter
insns Dword element size. Update testcases (also their gather parts),
utilizing that there previously were two identical lines each (for no
apparent reason).

PR29390, DW_CFA_AARCH64_negate_ra_state vs. DW_CFA_GNU_window_save

PR 29390
binutils/
* dwarf.c (is_aarch64, DW_CFA_GNU_window_save_name): New.
(display_debug_frames): Use them.
(init_dwarf_regnames_aarch64): Set is_aarch64.
(init_dwarf_regnames_by_elf_machine_code): Clear is_aarch64.
(init_dwarf_regnames_by_bfd_arch_and_mach): Likewise.
gas/
* testsuite/gas/aarch64/pac_ab_key.d: Adjust expected output.
* testsuite/gas/aarch64/pac_negate_ra_state.d: Likewise.

PR29337, readelf CU/TU mixup in .gdb_index

Commit 244e19c79111 changed a number of variables in display_gdb_index
to count entries rather than words.

PR 29337
* dwarf.c (display_gdb_index): Correct use of cu_list_elements.

PR29370, infinite loop in display_debug_abbrev

The PR29370 testcase is a fuzzed object file with multiple
.trace_abbrev sections.  Multiple .trace_abbrev or .debug_abbrev
sections are not a violation of the DWARF standard.  The DWARF5
standard even gives an example of multiple .debug_abbrev sections
contained in groups.  Caching and lookup of processed abbrevs thus
needs to be done by section and offset rather than base and offset.
(Why base anyway?)  Or, since section contents are kept, by a pointer
into the contents.

PR 29370
* dwarf.c (struct abbrev_list): Replace abbrev_base and
abbrev_offset with raw field.
(find_abbrev_list_by_abbrev_offset): Delete.
(find_abbrev_list_by_raw_abbrev): New function.
(process_abbrev_set): Set list->raw and list->next.
(find_and_process_abbrev_set): Replace abbrev list lookup with
new function.  Don't set list abbrev_base, abbrev_offset or next.

binutils/dwarf.c: abbrev caching

I'm inclined to think that abbrev caching is counter-productive.  The
time taken to search the list of abbrevs converted to internal form is
non-zero, and it's easy to decode the raw abbrevs.  It's especially
silly to cache empty lists of decoded abbrevs (happens with zero
padding in .debug_abbrev), or abbrevs as they are displayed when there
is no further use of those abbrevs.  This patch stops caching in those
cases.

* dwarf.c (record_abbrev_list_for_cu): Add free_list param.
Put abbrevs on abbrev_lists here.
(new_abbrev_list): Delete function.
(process_abbrev_set): Return newly allocated list.  Move
abbrev base, offset and size checking to..
(find_and_process_abbrev_set): ..here, new function.  Handle
lookup of cached abbrevs here, and calculate start and end
for process_abbrev_set.  Return free_list if newly alloc'd.
(process_debug_info): Consolidate cached list lookup, new list
alloc and processing into find_and_process_abbrev_set call.
Free list when not cached.
(display_debug_abbrev): Similarly.

miscellaneous dwarf.c tidies

* dwarf.c: Leading and trailing whitespace fixes.
(free_abbrev_list): New function.
(free_all_abbrevs): Use the above.  Free cu_abbrev_map here too.
(process_abbrev_set): Print actual section name on error.
(get_type_abbrev_from_form): Add overflow check.
(free_debug_memory): Don't free cu_abbrev_map here..
(process_debug_info): ..or here.  Warn on another case of not
finding a neeeded abbrev.

PowerPC64: fix build error on 32-bit hosts

elf64-ppc.c:11673:33: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘bfd_vma’ {aka ‘long long unsigned int’} [-Werror=format=]
11673 |   fprintf (stderr, "offset = %#lx:", stub_entry->stub_offset);
      |                              ~~~^    ~~~~~~~~~~~~~~~~~~~~~~~
      |                                 |              |
      |                                 |              bfd_vma {aka long long unsigned int}
      |                                 long unsigned int
      |                              %#llx

* elf64-ppc.c (dump_stub): Use BFD_VMA_FMT.

Wrap python_write_bytecode with HAVE_PYTHON ifdef

This commit fixes a build error on machines lacking python headers
and/or libraries.

Automatic date update in version.in

Handle Python 3.11 deprecation of PySys_SetPath and Py_SetProgramName

Python 3.11 deprecates PySys_SetPath and Py_SetProgramName.  The
PyConfig API replaces these and other functions.  This commit uses the
PyConfig API to provide equivalent functionality while also preserving
support for older versions of Python, i.e. those before Python 3.8.

A beta version of Python 3.11 is available in Fedora Rawhide.  Both
Fedora 35 and Fedora 36 use Python 3.10, while Fedora 34 still used
Python 3.9.  I've tested these changes on Fedora 34, Fedora 36, and
rawhide, though complete testing was not possible on rawhide due to
a kernel bug.  That being the case, I decided to enable the newer
PyConfig API by testing PY_VERSION_HEX against 0x030a0000.  This
corresponds to Python 3.10.

We could try to use the PyConfig API for Python versions as early as 3.8,
but I'm reluctant to do this as there may have been PyConfig related
bugs in earlier versions which have since been fixed.  Recent linux
distributions should have support for Python 3.10.  This should be
more than adequate for testing the new Python initialization code in
GDB.

Information about the PyConfig API as well as the motivation behind
deprecating the old interface can be found at these links:

https://github.com/python/cpython/issues/88279
https://peps.python.org/pep-0587/
https://docs.python.org/3.11/c-api/init_config.html

The v2 commit also addresses several problems that Simon found in
the v1 version.

In v1, I had used Py_DontWriteBytecodeFlag in the new initialization
code, but Simon pointed out that this global configuration variable
will be deprecated in Python 3.12.  This version of the patch no longer
uses Py_DontWriteBytecodeFlag in the new initialization code.
Additionally, both Py_DontWriteBytecodeFlag and Py_IgnoreEnvironmentFlag
will no longer be used when building GDB against Python 3.10 or higher.
While it's true that both of these global configuration variables are
deprecated in Python 3.12, it makes sense to disable their use for
gdb builds against 3.10 and higher since those are the versions for
which the PyConfig API is now being used by GDB.  (The PyConfig API
includes different mechanisms for making the same settings afforded
by use of the soon-to-be deprecated global configuration variables.)

Simon also noted that PyConfig_Clear() would not have be called for
one of the failure paths.  I've fixed that problem and also made the
rest of the "bail out" code more direct.  In particular,
PyConfig_Clear() will always be called, both for success and failure.

The v3 patch addresses some rebase conflicts related to module
initialization .  Commit 3acd9a692dd ("Make 'import gdb.events' work")
uses PyImport_ExtendInittab instead of PyImport_AppendInittab.  That
commit also initializes a struct for each module to import.  Both the
initialization and the call to were moved ahead of the ifdefs to avoid
having to replicate (at least some of) the code three times in various
portions of the ifdefs.

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

gdb/value.c: add several headers to the include list

Building GDB currently fails to build with libc++, because libc++ is
stricter about which headers "leak" entities they're not guaranteed
to support. The following headers have been added:

* `<iterator>`, to support `std::back_inserter`
* `<utility>`, to support `std::move` and `std::swap`
* `<vector>`, to support `std::vector`

Change-Id: Iaeb15057c5fbb43217df77ce34d4e54446dbcf3d

Don't stop all threads prematurely after first step of "step N"

In all-stop mode, when the target is itself in non-stop mode (like
GNU/Linux), if you use the "step N" (or "stepi/next/nexti N") to step
a thread a number of times:

 (gdb) help step
 step, s
 Step program until it reaches a different source line.
 Usage: step [N]
 Argument N means step N times (or till program stops for another reason).

... GDB prematurely stops all threads after the first step, and
doesn't re-resume them for the subsequent N-1 steps.  It's as if for
the 2nd and subsequent steps, the command was running with
scheduler-locking enabled.

This can be observed with the testcase added by this commit, which
looks like this:

 static pthread_barrier_t barrier;

 static void *
 thread_func (void *arg)
 {
   pthread_barrier_wait (&barrier);
   return NULL;
 }

 int
 main ()
 {
   pthread_t thread;
   int ret;

   pthread_barrier_init (&barrier, NULL, 2);

   /* We run to this line below, and then issue "next 3".  That should
      step over the 3 lines below and land on the return statement.  If
      GDB prematurely stops the thread_func thread after the first of
      the 3 nexts (and never resumes it again), then the join won't
      ever return.  */
   pthread_create (&thread, NULL, thread_func, NULL); /* set break here */
   pthread_barrier_wait (&barrier);
   pthread_join (thread, NULL);

   return 0;
 }

The test hangs and times out without the GDB fix:

 (gdb) next 3
 [New Thread 0x7ffff7d89700 (LWP 525772)]
 FAIL: gdb.threads/step-N-all-progress.exp: non-stop=off: target-non-stop=on: next 3 (timeout)

The problem is a core gdb bug.

When you do "step/stepi/next/nexti N", GDB internally creates a
thread_fsm object and associates it with the stepping thread.  For the
stepping commands, the FSM's class is step_command_fsm.  That object
is what keeps track of how many steps are left to make.  When one step
finishes, handle_inferior_event calls stop_waiting and returns, and
then fetch_inferior_event calls the "should_stop" method of the event
thread's FSM.  The implementation of that method decrements the
steps-left counter.  If the counter is 0, it returns true and we
proceed to presenting the stop to the user.  If it isn't 0 yet, then
the method returns false, indicating to fetch_inferior_event to "keep
going".

Focusing now on when the first step finishes -- we're in "all-stop"
mode, with the target in non-stop mode.  When a step finishes,
handle_inferior_event calls stop_waiting, which itself calls
stop_all_threads to stop everything.  I.e., after the first step
completes, all threads are stopped, before handle_inferior_event
returns.  And after that, now in fetch_inferior_event, we consult the
thread's thread_fsm::should_stop, which as we've seen, for the first
step returns false -- i.e., we need to keep_going for another step.
However, since the target is in non-stop mode, keep_going resumes
_only_ the current thread.  All the other threads remain stopped,
inadvertently.

If the target is in non-stop mode, we don't actually need to stop all
threads right after each step finishes, and then re-resume them again.
We can instead defer stopping all threads until all the steps are
completed.

So fix this by delaying the stopping of all threads until after we
called the FSM's "should_stop" method.  I.e., move it from
stop_waiting, to handle_inferior_events's callers,
fetch_inferior_event and wait_for_inferior.

New test included.  Tested on x86-64 GNU/Linux native and gdbserver.

Change-Id: Iaad50dcfea4464c84bdbac853a89df92ade6ae01

Re: opcodes/arc: Implement style support in the disassembler

* arc-dis.c (print_insn_arc): Fix thinko.

gas/symbols: introduce md_resolve_symbol

Assuming GMSD is a special operand, marked as O_md1, the code:

    .set VREG, GMSD
    .set REG, VREG
    extsw REG, 2

...fails upon attempts to resolve the value of the symbol. This happens
since machine-dependent values are not handled in the giant op switch.
We introduce a custom md_resolve_symbol macro; the ports can use this
macro to customize the behavior when resolve_symbol_value hits O_md
operand.

Automatic date update in version.in

x86: Disallow invalid relocations against protected symbols

Since glibc 2.36 will issue warnings for copy relocation against
protected symbols and non-canonical reference to canonical protected
functions, change the linker to always disallow such relocations.

bfd/

* elf32-i386.c (elf_i386_scan_relocs): Remove check for
elf_has_indirect_extern_access.
* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
(elf_x86_64_relocate_section): Remove check for
elf_has_no_copy_on_protected.
* elfxx-x86.c (elf_x86_allocate_dynrelocs): Check for building
executable instead of elf_has_no_copy_on_protected.
(_bfd_x86_elf_adjust_dynamic_symbol): Disallow copy relocation
against non-copyable protected symbol.
* elfxx-x86.h (SYMBOL_NO_COPYRELOC): Remove check for
elf_has_no_copy_on_protected.

ld/

* testsuite/ld-i386/i386.exp: Expect linker error for PR ld/17709
test.
* testsuite/ld-i386/pr17709.rd: Removed.
* testsuite/ld-i386/pr17709.err: New file.
* testsuite/ld-x86-64/pr17709.rd: Removed.
* testsuite/ld-x86-64/pr17709.err: New file.
* testsuite/ld-x86-64/pr28875-func.err: Updated.
* testsuite/ld-x86-64/x86-64.exp: Expect linker error for PR
ld/17709 test.  Add tests for function pointer against protected
function.

x86: Make protected symbols local for -shared

Call _bfd_elf_symbol_refs_local_p with local_protected==true.  This has
2 noticeable effects for -shared:

* GOT-generating relocations referencing a protected data symbol no
  longer lead to a GLOB_DAT (similar to a hidden symbol).
* Direct access relocations (e.g. R_X86_64_PC32) no longer has the
  confusing diagnostic below.

    __attribute__((visibility("protected"))) void *foo() {
      return (void *)foo;
    }

    // gcc -fpic -shared -fuse-ld=bfd
    relocation R_X86_64_PC32 against protected symbol `foo' can not be used when making a shared object

The new behavior matches arm, aarch64 (commit
83c325007c5599fa9b60b8d5f7b84842160e1d1b), and powerpc ports, and other
linkers: gold and ld.lld.

Note: if some code tries to use direct access relocations to take the
address of foo, the pointer equality will break, but the error should be
reported on the executable link, not on the innocent shared object link.
glibc 2.36 will give a warning at relocation resolving time.

With this change, `#define elf_backend_extern_protected_data 1` is no
longer effective.  Just remove it.

Remove the test "Run protected-func-1 without PIE" since -fno-pic
address taken operation in the executable doesn't work with protected
symbol in a shared object by default.  Similarly, remove
protected-data-1a and protected-data-1b.  protected-data-1b can be made
working by removing HAVE_LD_PIE_COPYRELOC from GCC
(https://sourceware.org/pipermail/gcc-patches/2022-June/596678.html).

Reformat gdbarch-components.py to fix deviations

Reformat to make sure we have a clean file with no deviations
from the expected python code format.

[AArch64] MTE corefile support

Teach GDB how to dump memory tags for AArch64 when using the gcore command
and how to read memory tag data back from a core file generated by GDB
(via gcore) or by the Linux kernel.

The format is documented in the Linux Kernel documentation [1].

Each tagged memory range (listed in /proc/<pid>/smaps) gets dumped to its
own PT_AARCH64_MEMTAG_MTE segment. A section named ".memtag" is created for each
of those segments when reading the core file back.

To save a little bit of space, given MTE tags only take 4 bits, the memory tags
are stored packed as 2 tags per byte.

When reading the data back, the tags are unpacked.

I've added a new testcase to exercise the feature.

Build-tested with --enable-targets=all and regression tested on aarch64-linux
Ubuntu 20.04.

[1] Documentation/arm64/memory-tagging-extension.rst (Core Dump Support)

[AArch64] Support AArch64 MTE memory tag dumps in core files

The Linux kernel can dump memory tag segments to a core file, one segment
per mapped range. The format and documentation can be found in the Linux
kernel tree [1].

The following patch adjusts bfd and binutils so they can handle this new
segment type and display it accordingly. It also adds code required so GDB
can properly read/dump core file data containing memory tags.

Upon reading, each segment that contains memory tags gets mapped to a
section named "memtag". These sections will be used by GDB to lookup the tag
data. There can be multiple such sections with the same name, and they are not
numbered to simplify GDB's handling and lookup.

There is another patch for GDB that enables both reading
and dumping of memory tag segments.

Tested on aarch64-linux Ubuntu 20.04.

[1] Documentation/arm64/memory-tagging-extension.rst (Core Dump Support)

[AArch64] Fix testcase compilation failure

Newer distros carry newer headers that contains MTE definitions.  Account
for that fact in the MTE testcases (gdb.arch/aarch64-mte.exp) and define
constants conditionally to prevent compilation failures.