Bump GDB's version number to 15.1.90.DATE-git.

This commit changes gdb/version.in to 15.1.90.DATE-git.

This commit also makes the following changes in gdb/testsuite:

* gdb.base/default.exp: Change $_gdb_minor to 2.

Set GDB version number to 15.1.

This commit changes gdb/version.in to 15.1.

Automatic date update in version.in

Automatic date update in version.in

Fix cast types for opencl

The bitshift tests for opencl have these failures:

print /x (signed char) 0x0f << 8
No type named signed char.
(gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print /x (signed char) 0x0f << 8
print (signed char) 0x0f << 8
No type named signed char.
(gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print (signed char) 0x0f << 8

Apparently opencl doesn't have the 'signed' modifier for types, only
the 'unsigned' modifier.
Even 'char' is guaranteed to be signed if no modifier is used, so
this changes the casts to match this logic.

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

Fix 64-bit shifts where long only has 32-bit size

On systems where long has 32-bit size you get these failures:

print 1 << (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 << (unsigned long long) 0xffffffffffffffff
print 1 >> (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 >> (unsigned long long) 0xffffffffffffffff
print -1 << (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 << (unsigned long long) 0xffffffffffffffff
print -1 >> (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 >> (unsigned long long) 0xffffffffffffffff

Fixed by changing the number-of-bits variable to ULONGEST.

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

Fix too-large or negative right shift of negative numbers

As seen in these test failures:

print -1 >> -1
warning: right shift count is negative
$N = 0
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -1 >> -1
print -4 >> -2
warning: right shift count is negative
$N = 0
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -4 >> -2

Fixed by restoring the logic from before the switch to gmp.

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

Fix right shift of negative numbers

PR31590 shows that right shift of negative numbers doesn't work
correctly since GDB 14:

(gdb) p (-3) >> 1
$1 = -1

GDB 13 and earlier returned the correct value -2.
And there actually is one test that shows the failure:

print -1 >> 1
$84 = 0
(gdb) FAIL: gdb.base/bitshift.exp: lang=asm: rsh neg lhs: print -1 >> 1

The problem was introduced with the change to gmp functions in
commit 303a881f87.
It's wrong because gdb_mpz::operator>> uses mpz_tdif_q_2exp, which
always rounds toward zero, and the gmp docu says this:

For positive n both mpz_fdiv_q_2exp and mpz_tdiv_q_2exp are simple
bitwise right shifts.
For negative n, mpz_fdiv_q_2exp is effectively an arithmetic right shift
treating n as two's complement the same as the bitwise logical functions
do, whereas mpz_tdiv_q_2exp effectively treats n as sign and magnitude.

So this changes mpz_tdiv_q_2exp to mpz_fdiv_q_2exp, since it
does right shifts for both positive and negative numbers.

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

Restore bitshift.exp tests

Commit cdd4206647 unintentionally disabled all tests of bitshift.exp,
so it actually just does this:

Running /c/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/bitshift.exp ...
PASS: gdb.base/bitshift.exp: complete set language

=== gdb Summary ===

 # of expected passes 1

It changed the 'continue' of unsupported languages to 'return', and
since ada is the first language and is unsupported, no tests were run.

This changes it back to 'continue', and the following patches fix
the regressions that were introduced since then unnoticed.

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

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Fix gdb.lookup_type for function-local types

Looking for a type defined locally in a function doesn't work
any more since the introduction of TYPE_DOMAIN:
```
(gdb) python print (gdb.lookup_type ('main()::Local'))
Python Exception <class 'gdb.error'>: No type named main()::Local.
Error occurred in Python: No type named main()::Local.
```

cp_search_static_and_baseclasses was simply missing a check for
SEARCH_TYPE_DOMAIN, now it works again:
```
(gdb) python print (gdb.lookup_type ('main()::Local'))
Local
```

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

Include needed unordered_map header

Compiling on FreeBSD 13.2 with the default clang version 14.0.5 and top level
configure options --with-python=/usr/local/bin/python3.9 gives this error:

  CXX    ada-exp.o
./../binutils-gdb/gdb/ada-exp.y:100:8: error: no template named 'unordered_map' in namespace 'std'
  std::unordered_map<std::string, std::vector<ada_index_var_operation *>>
  ~~~~~^
1 error generated.

This change fixes it.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31918
Approved-By: Tom Tromey <tom@tromey.com>
(cherry picked from commit c702f1ad8a6a51b9c74445c77e1f6e822ba9293b)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[gdb/tdep] Fix gdb.base/watchpoint-running.exp on {arm,ppc64le}-linux

When running test-case gdb.base/watchpoint-running on ppc64le-linux (and
similar on arm-linux), we get:
...
(gdb) watch global_var^M
warning: Error when detecting the debug register interface. \
  Debug registers will be unavailable.^M
Watchpoint 2: global_var^M
(gdb) FAIL: $exp: all-stop: hardware: watch global_var
FAIL: $exp: all-stop: hardware: watchpoint hit (timeout)
...

The problem is that ppc_linux_dreg_interface::detect fails to detect the
hardware watchpoint interface, because the calls to ptrace return with errno
set to ESRCH.

This is a feature of ptrace: if a call is done while the tracee is not
ptrace-stopped, it returns ESRCH.

Indeed, in the test-case "watch global_var" is executed while the inferior is
running, and that triggers the first call to ppc_linux_dreg_interface::detect.

And because the detection failure is cached, subsequent attempts at setting
hardware watchpoints will also fail, even if the tracee is ptrace-stopped.

The way to fix this is to make sure that ppc_linux_dreg_interface::detect is
called when we know that the thread is ptrace-stopped, which in the current
setup is best addressed by using target-specific post_attach and
post_startup_inferior overrides.  However, as we can see in
aarch64_linux_nat_target, that causes code duplication.

Fix this by:
- defining a new target hook low_init_process, called from
  linux_init_ptrace_procfs, which is called from both
  linux_nat_target::post_attach and linux_nat_target::post_startup_inferior,
- adding implementations for ppc_linux_nat_target and arm_linux_nat_target
  that detect the hardware watchpoint interface,
- replacing the aarch64_linux_nat_target implementations of post_attach and
  post_startup_inferior with a low_init_process implementation.

Tested on ppc64le-linux, arm-linux, aarch64-linux and x86_64-linux.

Co-Authored-By: Tom de Vries <tdevries@suse.de>
Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/31834
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31834
PR tdep/31705
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31705

(cherry picked from commit 50de502a4f843310e231b3174804e95a9e7de4fc)

Automatic date update in version.in

[gdb/python] Fix gdb.python/py-disasm.exp on arm-linux

After fixing test-case gdb.python/py-disasm.exp to recognize the arm nop:
...
nop {0}
...
we run into:
...
disassemble test^M
Dump of assembler code for function test:^M
   0x004004d8 <+0>:     push    {r11}           @ (str r11, [sp, #-4]!)^M
   0x004004dc <+4>:     add     r11, sp, #0^M
   0x004004e0 <+8>:     nop     {0}^M
=> 0x004004e4 <+12>:    Python Exception <class 'ValueError'>: Buffer \
  returned from read_memory is sized 0 instead of the expected 4^M
^M
unknown disassembler error (error = -1)^M
(gdb) FAIL: $exp: global_disassembler=ShowInfoRepr: disassemble test
...

This is caused by this code in gdbpy_disassembler::read_memory_func:
...
  gdbpy_ref<> result_obj (PyObject_CallMethod ((PyObject *) obj,
                                              "read_memory",
                                              "KL", len, offset));
...
where len has type "unsigned int", while "K" means "unsigned long long" [1].

Fix this by using "I" instead, meaning "unsigned int".

Also, offset has type LONGEST, which is typedef'ed to int64_t, while "L" means
"long long".

Fix this by using type gdb_py_longest for offset, in combination with format
character "GDB_PY_LL_ARG".  Likewise in disasmpy_info_read_memory.

Tested on arm-linux.

Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR python/31845
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845

[1] https://docs.python.org/3/c-api/arg.html

(cherry picked from commit 4cd214dce4579f86a85a96c882e0fc8c4d94601c)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

fix division by zero in target_read_string()

Under certain circumstances, a floating point exception in
target_read_string() can happen when the type has been obtained
by a call to stpy_lazy_string_elt_type(). In the latter function,
a call to check_typedef() has been forgotten. This makes
type->length = 0 in this case.

(cherry picked from commit 8130c1a430c952f65b621aee2c801316a61fab14)

Fix printing strings on macOS Sonoma

On macOS sonoma, printing a string would only print the first
character. For instance, if there was a 'const char *s = "foobar"',
then the 'print s' command would print '$1 = "f"' rather than the
expected '$1 = "foobar"'.

It seems that this is due to Apple silently replacing the version
of libiconv they ship with the OS to one which silently fails to
handle the 'outbytesleft' parameter correctly when using 'wchar_t'
as a target encoding.

This specifically causes issues when using iterating through a
string as wchar_iterator does.

This bug is visible even if you build for an old version of macOS,
but then run on Sonoma. Therefore this fix in the code applies
generally to macOS, and not specific to building on Sonoma. Building
for an older version and expecting forwards compatibility is a
common situation on macOS.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31853
Approved-By: Tom Tromey <tom@tromey.com>
(cherry picked from commit bb2981798f54e6eb30e46fb11cda2ca49561ffd3)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb: Avoid compilation warning in gcore.c.

See https://sourceware.org/pipermail/gdb-patches/2024-June/209726.html
for the details.

Approved-By: Tom Tromey <tom@tromey.com>
(cherry picked from commit e222ed2ce5b5359bfc6d8fd125534ccb507d7fb0)

Automatic date update in version.in

gdb/testsuite: Add gdb.arch/aarch64-mops-watchpoint.exp

Test behaviour of watchpoints triggered by MOPS instructions.  This test
is similar to gdb.base/memops-watchpoint.exp, but specifically for MOPS
instructions rather than whatever instructions are used in the libc's
implementation of memset/memcpy/memmove.

There's a separate watched variable for each set of instructions so that
the testcase can test whether GDB correctly identified the watchpoint
that triggered in each case.

Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
(cherry picked from commit 55e3fcf5e523007bd97868214e00324db42c11f6)

gdb/aarch64: Add record support for MOPS instructions.

There are two kinds of MOPS instructions: set instructions and copy
instructions.  Within each group there are variants with minor
differences in how they read or write to memory — e.g., non-temporal
read and/or write, unprivileged read and/or write and permutations of
those — but they work in the same way in terms of the registers and
regions of memory that they modify.

The new gdb.reverse/aarch64-mops.exp testcase verifies that MOPS
instructions are recorded and correctly reversed.  Not all variants of the
copy and set instructions are tested, since there are many and the record
and replay target processes them in the same way.

PR tdep/31666
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
(cherry picked from commit ebd06ca6b9bb2327e1269b52eb99b2f012faabf9)

gdb/aarch64: Disable displaced single-step for MOPS instructions

The AArch64 MOPS (Memory Operation) instructions provide a standardised
instruction sequence to perform a memset, memcpy or memmove.  A sequence is
always composed of three instructions: a prologue instruction, a main
instruction and an epilogue instruction.  As an illustration, here are the
implementations of these memory operations in glibc 2.39:

  (gdb) disassemble/r
  Dump of assembler code for function __memset_mops:
  => 0x0000fffff7e8d780 <+0>:     d503201f        nop
     0x0000fffff7e8d784 <+4>:     aa0003e3        mov     x3, x0
     0x0000fffff7e8d788 <+8>:     19c10443        setp    [x3]!, x2!, x1
     0x0000fffff7e8d78c <+12>:    19c14443        setm    [x3]!, x2!, x1
     0x0000fffff7e8d790 <+16>:    19c18443        sete    [x3]!, x2!, x1
     0x0000fffff7e8d794 <+20>:    d65f03c0        ret
  End of assembler dump.

  (gdb) disassemble/r
  Dump of assembler code for function __memcpy_mops:
  => 0x0000fffff7e8c580 <+0>:     d503201f        nop
     0x0000fffff7e8c584 <+4>:     aa0003e3        mov     x3, x0
     0x0000fffff7e8c588 <+8>:     19010443        cpyfp   [x3]!, [x1]!, x2!
     0x0000fffff7e8c58c <+12>:    19410443        cpyfm   [x3]!, [x1]!, x2!
     0x0000fffff7e8c590 <+16>:    19810443        cpyfe   [x3]!, [x1]!, x2!
     0x0000fffff7e8c594 <+20>:    d65f03c0        ret
  End of assembler dump.

  (gdb) disassemble/r
  Dump of assembler code for function __memmove_mops:
  => 0x0000fffff7e8d180 <+0>:     d503201f        nop
     0x0000fffff7e8d184 <+4>:     aa0003e3        mov     x3, x0
     0x0000fffff7e8d188 <+8>:     1d010443        cpyp    [x3]!, [x1]!, x2!
     0x0000fffff7e8d18c <+12>:    1d410443        cpym    [x3]!, [x1]!, x2!
     0x0000fffff7e8d190 <+16>:    1d810443        cpye    [x3]!, [x1]!, x2!
     0x0000fffff7e8d194 <+20>:    d65f03c0        ret
  End of assembler dump.

The Arm Architecture Reference Manual says that "the prologue, main, and
epilogue instructions are expected to be run in succession and to appear
consecutively in memory".  Therefore this patch disables displaced stepping
on them.

The testcase verifies that MOPS sequences are correctly single-stepped.

PR tdep/31666
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
(cherry picked from commit b995344c116e04bd6bfeaf53364cd791d0dae45d)

Automatic date update in version.in

gdb/doc: use POD2MAN5 when appropriate

In commit:

  commit 824083f34c222aa7419e2ea58e82d6f230d5f531
  Date:   Fri Apr 12 17:47:20 2024 +0100

      gdb/doc: use silent-rules.mk in the Makefile

I rewrote the rules for building the man pages.  While doing this I
accidentally switched from using MAN2POD5 to MAN2POD1 for generating
the file gdbinit.5.

Restore use of MAN2POD5 where appropriate.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Bump GDB's version number to 15.0.91.DATE-git.

This commit changes gdb/version.in to 15.0.91.DATE-git.

Set GDB version number to 15.0.91.

This commit changes gdb/version.in to 15.0.91.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb/doc: don't have .pod targets separate to man page targets

While preparing the new release it was discovered that commit:

  commit 824083f34c222aa7419e2ea58e82d6f230d5f531
  Date:   Fri Apr 12 17:47:20 2024 +0100

      gdb/doc: use silent-rules.mk in the Makefile

was causing problems.  Given a release tar file, an attempt to build
and install GDB would give an error like this:

  [...]
    TEXI2POD gdb.pod
  cannot find GDBvn.texi at ../../../gdb-15.0.50.20240508/gdb/doc/../../etc/texi2pod.pl line 251, <GEN0> line 16.
  make[5]: *** [Makefile:663: gdb.pod] Error 2

The problem here is how the man pages are built, and how they are
distributed within a release.

Within the development (git) tree, the man page files are not part of
the source tree, these files are built as needed.  Within a release
tar file though, the man pages are included.  The idea being that a
user can build and install GDB, including getting the man pages,
without having to install the tools needed to generate the man pages.

The man pages are generated in a two step process.  First the .texi
file is processed with texi2pod to create a .pod file, then this .pod
file is processed to create the .1 or .5 man file.

Prior to the above commit these two steps were combined into a single
recipe, this meant that when a user performed a build/install from a
release tree all of the dependencies, as well as the final result,
were all present in the source tree, and so nothing needed to be
rebuilt.

However, the above commit split the two steps apart.  Now we had a
separate rule for building the .pod files, and the .1/.5 man page
files depended on the relevant .pod file.

As the .pod files are not shipped in a GDB release, this meant that
one of the dependencies of the man page files was now missing.  As a
result if a user tried to install from a release tree a rebuild of the
.pod files would be attempted, and if that succeeded then building the
man pages would follow that.

Unfortunately, building the .pod files would fail as the GDBvn.texi
file, though present in the source tree, was not present in the build
tree, which is where it is needed for the .pod file generation to
work.

To fix this, I propose merging the .pod creation and the .1/.5 man
page creation back into a single recipe.  Having these two steps split
is probably the "cleaner" solution, but makes it harder for us to
achieve our goal of shipping the prebuilt man page files.  I've added
a comment explaining what's going on (such a comment would have
prevented this mistake having been made in the first place).

One possibly weird thing here is that I have left both an
ECHO_TEXI2POD and a ECHO_TEXI2MAN in the rule $(MAN1S) and $(MAN5S)
recipes.  This is 100% not going to break anything, these just print
two different progress messages while executing the recipes, but I'm
not sure if this is considered poor style or not.  Maybe we're only
supposed to have a single ECHO_* per recipe?

Anyway, even if this is poor style, I figure it really is just a style
thing.  We can tweak this later as needed.  Otherwise, this commit
should fix the current issue blocking the next GDB release.

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

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Set GDB version number to 15.0.90.

This commit changes gdb/version.in to 15.0.90.

gdb/NEWS: Replace "Chagnes since GDB 14" to "Changes in GDB 15"

This commit changes the title of the section to refer to the actual
release version number, now that all changes listed are confirmed
to be part of the upcoming GDB 15 release.

Set development mode to "off" by default.

This is done by setting the "development" variable to "false"
in bfd/development.sh.

Bump version to 15.0.90.DATE-git.

Now that the GDB 15 branch has been created,
this commit bumps the version number in gdb/version.in to
15.0.90.DATE-git

For the record, the GDB 15 branch was created
from commit 3a624d9f1c5ccd8cefdd5b7ef12b41513f9006cd.

Automatic date update in version.in

ld: Document -pie -Ttext-segment=ORG generates ET_EXEC

This is the v2 patch I am checking in.

H.J.

Automatic date update in version.in

Re: LoongArch: gas: Adjust DWARF CIE alignment factors

Adjust the gas testsuite to suit commit de203ed568f6.

* testsuite/gas/loongarch/relax-cfi-fde-DW_CFA_advance_loc.d:
Expect data alignment of -8.  Tidy.

gas: extend \+ support to .irp / .irpc

PR gas/31752

These are effectively macro-like, without any separate macro definition.
They already support \@, so they would better also support \+. This
allows, where desired, to get away without maintaining an explicit count
variable in source code.

With this the recently introduced testcase doesn't need any xfails
anymore.

gas: adjust handling of quotes for .irpc

The present handling of inner double quotes can lead to very strange
diagnostics. Follow one of the two possible interpretations of the doc:
@dots{} referring to possibly multiple white space separated
@var{values}, each of which may be quoted. The original implementation,
prior to 465e5617233f ("PR gas/3856"), hints at the other possible
interpretation: When quoted there's only a single @var{values}, with
inner quotes taken as ordinary characters. That, however, seems overall
less useful to me.

While touching the documentation, mirror the (inverse) spelling
correction (@section line inconsistent with actual description) to .irp
as well.

x86: simplify VexVVVV_SRC2 handling for the XOP case

As already suggested during review, rather than having an extra
conditional in build_modrm_byte() (a code path used for quite a few
more insns, including even certain GPR ones), adjust the attribute in
the installed template to properly describe things with operands
swapped.

x86: simplify / consolidate check_{word,long,qword}_reg()

These run after template matching. Therefore operands are already known
to match the template in use. With the loop bodies skipping anything not
a GPR in the actual operands, there's therefore no need to check the
template's operand type for permitting Reg or Accum.

At the same time bring the three functions in sync for the "byte" part
of the logic, as far as checking the template for other sizes (qword
specifically) goes. Plus drop a stale comment from check_qword_reg(),
when all three are now behaving the same in this regard.

x86: correct VCVT{,U}SI2SD

Properly reject inappropriate suffixes (No_lSuf / No_qSuf mistakenly
omitted by cf665fee1d6c ["x86: re-work AVX512 embedded rounding / SAE"]),
to avoid emitting bad or arbitrarily guessed instructions. Interestingly
check_{long,qword}_suffix() don't help here, which perhaps is another
indication that the way they work right now isn't quite appropriate.

Sadly correcting just the templates breaks operand ambiguity detection,
since so far that worked from a single template permitting more than one
suffix. Here we have ambiguity though which can now be noticed only when
taking all (matching) templates together. Therefore we need to determine
further matching templates (see code comments for constraints), to then
accumulate permitted suffixes across all of them.

[gdb/testsuite] Add PR26286 kfail in gdb.threads/attach-many-short-lived-threads.exp

When running test-case gdb.threads/attach-many-short-lived-threads.exp, I run
regularly into PR26286:
...
(gdb) continue^M
Continuing.^M
[LWP ... exited]^M
  ...
[LWP ... exited]^M
^M
Program terminated with signal SIGTRAP, Trace/breakpoint trap.^M
The program no longer exists.^M
(gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \
  break at break_fn: 1
...

Add a kfail for this, such that we have:
...
(gdb) KFAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \
  break at break_fn: 1 (PRMS: threads/26286)
...

Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Tested on x86_64-linux.

Automatic date update in version.in

gdb, testsuite: Fix return value in gdb.base/foll-fork.exp

In a remote testing setup, I saw this error:

~~~
(gdb) FAIL: gdb.base/foll-fork.exp: check_fork_catchpoints: runto: run to main
ERROR: tcl error sourcing gdb/gdb/testsuite/gdb.base/foll-fork.exp.
ERROR: expected boolean value but got ""
    while executing
"if { ![check_fork_catchpoints] } {
    untested "follow-fork not supported"
    return
}"
    (file "gdb/gdb/testsuite/gdb.base/foll-fork.exp" line 434)
    invoked from within
"source gdb/gdb/testsuite/gdb.base/foll-fork.exp"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 source gdb/gdb/testsuite/gdb.base/foll-fork.exp"
    invoked from within
"catch "uplevel #0 source $test_file_name""
Remote debugging from host 172.0.1.3, port 37766
Killing process(es): 1171
Quit
~~~

The actual reason for this were some connection problems. Though the
function check_fork_catchpoints shouldn't return an empty string, especially
as it promises to always return 0 or 1. Fix that.

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

gdb/testsuite: Restore libc_has_debug_info's less strict behaviour

The code that was factored out from gdb.base/relativedebug.exp assumed that
libc has debug info and only determined that it doesn't if it saw a specific
message from GDB to that effect.  In the process of factoring it into a
require predicate, I made it stricter by trying to make a specific
determination of whether or not debug info is available.

Pedro noticed that "It'll disable the testcase on systems that link with
their libc statically (even if has debug info), or systems that name their
libc something else."  Which is something I hadn't considered.

This patch returns libc_has_debug_info to the original behaviour.

Also, remove a verbose message that is redundant with the $message
variable.

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

Automatic date update in version.in

libctf testsuite compilation failure

* testsuite/libctf-regression/open-error-free.c (main): Correct
format length modifier.

Default dwarf_synchronous to true

Unfortunately the background DWARF reading series introduced a number
of races, as repored by thread sanitizer.  This patch changes gdb to
disable this feature for the time being -- in particular for the gdb
15 release.

I've filed a bug and linked all the known races to it.  Once those are
fixed we can re-enable this feature by default.

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

restore build with --enable-maintainer-mode

A build with --enable-maintainer-mode is currently failing with:

make[4]: *** No rule to make target '<SRC>/gas/config/te-ia64aix.h',
 needed by '<SRC>/gas/po/gas.pot'.  Stop.
make[4]: Leaving directory '<$OBJ>/gas/po'
make[3]: *** [Makefile:1695: all-recursive] Error 1
...

As config/te-ia64aix.h is now removed, remove the corresponding fragment
from the makefile.

gas/
        * Makefile.am: Remove config/te-ia64aix.h.
        * Makefile.in: Regenerate.
        * po/POTFILES.in: Regenerate.

aarch64: fix incorrect encoding for system register pmsdsfr_el1

This patch fixes a mistake in the encoding of the system register
pmsdsfr_el1.

Reference:
https://developer.arm.com/documentation/ddi0601/2022-09/AArch64-Registers/PMSDSFR-EL1--Sampling-Data-Source-Filter-Register?lang=en

Support APX zero-upper

This patch is to enable ZU for IMUL (opcodes 0x69 and 0x6B) and SETcc.
Since the spec only recommends one form of setzu, I won't be adding
set<cc>reg32/reg64 support in this patch.

gas/ChangeLog:

        * config/tc-i386.c (build_apx_evex_prefix): Handle ZU.
        * testsuite/gas/i386/x86-64.exp: Added new tests for ZU.
        * testsuite/gas/i386/x86-64.exp: Added new tests for ZU.
        * testsuite/gas/i386/x86-64-apx-zu-intel.d: New test.
        * testsuite/gas/i386/x86-64-apx-zu-inval.l: Ditto.
        * testsuite/gas/i386/x86-64-apx-zu-inval.s: Ditto.
        * testsuite/gas/i386/x86-64-apx-zu.d: Ditto.
        * testsuite/gas/i386/x86-64-apx-zu.s: Ditto.

opcodes/ChangeLog:

        * i386-dis-evex-prefix.h: Handle PREFIX_EVEX_MAP4_40 ~
        PREFIX_EVEX_MAP4_4F.
        * i386-dis-evex.h: Ditto.
        * i386-dis.c (struct dis386): Add new micro 'ZU'.
        (putop): Handle %ZU.
        * i386-gen.c: Added ZU.
        * i386-opc.h: Ditto.
        * i386-opc.tbl: Added new templates to support ZU.

X86: Remove "i.rex" to eliminate extra conditional branch

Resulting code will do better without the extra conditional branch.
Remove "i.rex" to eliminate extra conditional branch.

gas/ChangeLog:

        * config/tc-i386.c (establish_rex): Remove i.rex.

gprofng: use StringBuilder to create long messages

ChangeLog
2024-05-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* src/collctrl.cc: Use StringBuilder to create messages.
Remove unused variables and arrays.
* src/collctrl.h: Remove unused variables.

gprofng: Remove hardware counter tables for unsupported hardware (Sparc)

ChangeLog
2024-05-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/31123
* common/hwctable.c: Remove hardware counter tables for Sparc machines.

gprofng: remove memset() in libcollector

ChangeLog
2024-05-20  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* libcollector/collector.c: Use static initialization instead of memset.
* libcollector/dispatcher.c: Likewise.
* libcollector/hwprofile.c: Likewise.
* libcollector/jprofile.c: Likewise.
* libcollector/profile.c: Likewise.
* libcollector/synctrace.c: Likewise.

Add check for 8-bit old registers in EVEX format

Since APX supports EVEX from legacy instructions, we need to check
the 8-bit old registers in EVEX format. And add test cases for it.

gas/ChangeLog:

        * config/tc-i386.c (md_assemble): Add invalid check for old byte
        registers in EVEX format.
        * testsuite/gas/i386/x86-64-apx-inval.l: Add new test.
        * testsuite/gas/i386/x86-64-apx-inval.s: Ditto.

x86: Split REX/REX2 old registers judgment.

Split "REX/REX2 old register checking" and "add empty rex prefix"
into two separate branches.

gas/ChangeLog:

        * config/tc-i386.c (establish_rex): Split the judgments.

Automatic date update in version.in

gas: ginsn: remove unnecessary buffer allocation and free

A previous commit 80ec235 fixed the memory leaks, but brought to light
that the code should ideally make consistent use of snprintf and not
allocate/free more buffers than necessary.

gas/
* ginsn.c (ginsn_dst_print): Use snprintf consistently.

aarch64: Fix the hyphenated disassembly comment.

This patch fixes the following comment.

-  /* The hyphenated form is preferred for disassembly if there are
-     more than two registers in the list, and the register numbers
      are monotonically increasing in increments of one.  */

+  /* The hyphenated form is preferred for disassembly if there is
+     more than one register in the list, and the register numbers
      are monotonically increasing in increments of one.  */

Clarify documentation for pretty_printer.child

An Ada pretty-printer had a bug where its 'child' method returned a
gdb.Value rather than a tuple.  Kévin suggested that the documentation
for this method could be improved to clarify this.

Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
Approved-By: Eli Zaretskii <eliz@gnu.org>

gas: drop remnants of ia64-*-aix*

With BFD not supporting that target anymore, GAS can't possibly support
it either.

ld: silence makeinfo warnings

Older tool versions (4.12 in my case) demand . or , after @xref{};
arrange for this to be the case.

include, libctf: improve documentation

Some review comments came in after I pushed the last lot of ctf-api.h
comment improvements.  They were good, so I've incorporated them.
Mostly: better _next iterator usage info, better info on ctf_*open
functions, and better info on ctf_type_aname and ctf_type_name_raw.

include/
* ctf-api.h: improve documentation.

Automatic date update in version.in