gas: range-check 3rd argument of .align et al

Negative values would have been silently converted to large positive
ones, which may not be the user's intention. Similarly overly large
values would have been silently truncated. Warn them instead, and zap
such values.

ld/doc: Remove '.info' suffix in @ref, etc

Texinfo 7.2 began showing warnings like:

    ld.texi:1026: warning: do not set .info suffix in reference for manual `gcc.info'
    ld.texi:9689: warning: do not set .info suffix in reference for manual `binutils.info'

The Texinfo developers plan to stop removing the '.info' suffix
internally in a future release so without this patch the references will
break in the future.

Signed-off-by: Collin Funk <collin.funk1@gmail.com>

binutils/doc: Remove '.info' suffix in @ref, etc

Texinfo 7.2 began showing warnings like:

    binutils.texi:882: warning: do not set .info suffix in reference for manual `ld.info'
    binutils.texi:1365: warning: do not set .info suffix in reference for manual `ld.info'

The Texinfo developers plan to stop removing the '.info' suffix
internally in a future release so without this patch the references will
break in the future.

Signed-off-by: Collin Funk <collin.funk1@gmail.com>

x86: improve matching diagnostics when %st is involved

Diagnosing operand size vs operand type mismatches doesn't work very
well when GPRs and FPRs are in the same register class, distinguished
just by size. Introduce a separate RegFP class.

x86: move Anysize check in operand_size_match()

Anysize is applicable to memory operands only. Move the check to where
memory operands are handled. (The RegSIMD part there was questionable
altogether.)

x86: improve matching diagnostics when "accumulator" registers are involved

In templates, the expectation of an "accumulator" register to be used is
expressed solely by operand size; there's no "class" specifier there.
Hence operand_size_match() is too eager in invoking
match_{operand,simd}_size(), resulting in "operand size mismatch" errors
when it's the type (of register), not the size that's wrong.
Interestingly adjustments there alone lead to no error at all then: To
"compensate", operand_type_match() needs to disambiguate register types
when register instances are specified in the template (matching the
actual operand), by checking a match (overlap) in operand sizes.

x86: fold Accum checking in operand_size_match()

There's little point invoking match_{operand,simd}_size() twice per
loop; in fact the SIMD case with D set simply doesn't exist. Amend the
checks by one looking at the given operand, just like we already have
been doing for memory ones.

x86: improve matching diagnostics

Many times in the past I was puzzled by seeing "operand size mismatch"
when really "operand type mismatch" would be far more appropriate. As it
turns out, there were at least two flaws: In the single operand case we
didn't propagate i.error to match_template()'s local specific_error when
noticing a type mismatch. And then operand_size_match() was too eager in
invoking match_mem_size(): Especially the Unspecified attribute can get
in the way there when the expected operand isn't a memory one (and hence
Unspecified would not be set in the operand template, whereas it's
uniformly set for memory operands in AT&T syntax).

(In the x86-64-lkgs-inval testcase the particular error for the two
bogus Intel syntax forms doesn't really matter; all we ought to care
about there isthat there is _some_ error.)

x86: drop bogus accumulator check

Accum is an "instance", not a "class". With present enumerator values of
Reg and Accum, the 2nd check simply did the same as the first. In fact
checking for the accumulator (%rax) isn't necessary here at all, because
there's no case where an individual template would permit alternatively
a memory operand or the (qword) accumulator; only "any GPR" is ever
being paired with "memory".

RISC-V: check offsets when linker relaxation is disabled

The assembler partially relied on the linker to check whether the
offset is valid.  However, some optimization logic (added later)
removes relocations relative to local symbols without checking offsets.

For instance, it caused following code to silently emit wrong jumps
(to the jump instruction "." itself) without relocations:

> .option norelax
> j .+0x200000   # J (or JAL) instruction cannot encode this offset.
> j .+1          # Jump to odd address is not valid.

This commit adds offset checks where necessary.

gas/ChangeLog:

* config/tc-riscv.c (md_apply_fix): Check offsets when the
relocation relative to a local symbol is being optimized out.
* testsuite/gas/riscv/no-relax-branch-offset-fail.s: Failure
case where the branch offset is invalid.
* testsuite/gas/riscv/no-relax-branch-offset-fail.d: Ditto.
* testsuite/gas/riscv/no-relax-branch-offset-fail.l: Ditto.
* testsuite/gas/riscv/no-relax-branch-offset-ok.s: Border case.
* testsuite/gas/riscv/no-relax-branch-offset-ok.d: Ditto.
* testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.s: Failure
case only on RV64 where the PC-relative offset exceed limits.
* testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.d: Ditto.
* testsuite/gas/riscv/no-relax-pcrel-offset-fail-64.l: Ditto.
* testsuite/gas/riscv/no-relax-pcrel-offset-fail-not-32.d: Test
case for RV32 so that no errors occur.
* testsuite/gas/riscv/no-relax-pcrel-offset-ok.s: Border case.
* testsuite/gas/riscv/no-relax-pcrel-offset-ok.d: Ditto.

RISC-V: Add zilsd & zclsd support

Ref: https://github.com/riscv/riscv-zilsd/blob/main/zilsd.adoc

Signed-off-by: dysun <sundongya@nucleisys.com>
Co-developed-by: LIU Xu <liuxu@nucleisys.com>
Co-developed-by: ZHAO Fujin <zhaofujin@nucleisys.com>

Automatic date update in version.in

gas: sframe: avoid creating more symbols than necessary for FRE offset

Each SFrame FDE contains an offset to the start of its respective SFrame
FREs in the sfde_func_start_fre_off field.  To generate this offset,
fre_symbols[] array is being used.  The number of elements of this array
is currently set to the total number of SFrame FREs in the entire SFrame
section.  This is more than unnecessary.  We only need to track as many
points as the number of SFrame FDEs.

gas/
* gen-sframe.c (output_sframe_internal):  Size fde_fre_symbols
with the number of SFrame FDEs.

Fix regression with dynamic array bounds

Kévin discovered that commit ba005d32b0f ("Handle dynamic field
properties") regressed a test in the internal AdaCore test suite.

The problem here is that, when writing that patch, I did not consider
the case where an array type's bounds might come from a member of a
structure -- but where the array is not defined in the structure's
scope.

In this scenario the field-resolution logic would trip this condition:

  /* Defensive programming in case we see unusual DWARF.  */
  if (fi == nullptr)
    return nullptr;

This patch reworks this area, partly backing out that commit, and
fixes the problem.

In the new code, I chose to simply duplicate the field's location
information.  This isn't totally ideal, in that it might result in
multiple copies of a baton.  However, this seemed nicer than tracking
the DIE/field correspondence for every field in every CU -- my
thinking here is that this particular dynamic scenario is relatively
rare overall.  Also, if the baton cost does prove onerous, we could
intern the batons somewhere.

Regression tested on x86-64 Fedora 41.  I also tested this using the
AdaCore internal test suite.

Tested-By: Simon Marchi <simon.marchi@efficios.com>

ld: rename ldirname to stat_ldirname

It conflicts with the ldirname function that will be added in the next
libiberty sync.

ld/:
* ldlang.c (stat_ldirname): Rename from ldirname, all uses
changed.

gdb: rename ldirname to gdb_ldirname

It conflicts with the ldirname function that will be added in the next
libiberty sync.

binutils: Don't complain plugin with all LTO sections removed

When all LTO sections have been removed, the BFD lto_type is set to
lto_non_ir_object by bfd_set_lto_type.  In this case, don't complain
needing a plugin when seeing a LTO slim symbol.

bfd/

PR binutils/32967
* archive.c (_bfd_compute_and_write_armap): Call
bfd_lto_slim_symbol_p to check LTO slim symbol.
* bfd-in2.h: Generated.
* bfd.c (bfd_lto_slim_symbol_p): New.

binutils/

PR binutils/32967
* nm.c (filter_symbols): Call bfd_lto_slim_symbol_p to check
LTO slim symbol.

ld/

PR binutils/32967
* testsuite/ld-plugin/lto-binutils.exp: Run PR binutils/32967
tests.
* testsuite/ld-plugin/strip-1a-s-all.nd: New file.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

Automatic date update in version.in

gas .file 0 vs. dwarf5

Support added in commit 3417bfca676f for dwarf5 directory table 0
assumed that .file 0 was always the first debug .file directive.
That's not necessarily true.

* dwarf2dbg.c (get_directory_table_entry): Don't assume entry
        1 is available after putting DW_AT_comp_dir in entry 0.  Pass
pwd as file0_dirname to recursive call to avoid another
        getpwd in the case file0_dirname is NULL.

testsuite: fix gdb_exit for MinGW target

GDB is not properly exited via 'remote_close host' when running the
testsuite in a MinGW environment.  Use the 'quit' command to properly
exit the GDB debugging session.

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

testsuite: get windows PID on MinGW target

Also translate the MinGW PID to the Windows PID when running on a MinGW
target.

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

Fix create_breakpoint_parse_arg_string self-test

The emoji patch broke the create_breakpoint_parse_arg_string self-test
when gdb is running on a suitable terminal.  The problem is that the
test case doesn't take the error prefix string into account.

This patch fixes the test by having it compare the exception message
directly, rather than relying on the result of exception_print.  I did
try a different approach, of having the test mimic exception_print,
but this one seemed cleaner to me.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Add initializers to field_of_this_result

This adds initializers to field_of_this_result, so that certain spots
don't have to memset it.  This approach seems safer and cleaner.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Fix some pre-commit nits in gdb/__init__.py

I noticed that pre-commit has some complaints (flake8 and codespell)
about gdb/__init__.py.  This patch fixes these.

Approved-By: Tom de Vries <tdevries@suse.de>

resbin: don't pass NULL as printf %s arg

Fix three place where a NULL could be passed to "toosmall".

gas .file sanity check

Currently we allow insane file numbers that cause gas to allocate up
to 4G of memory for a file array.  Trim that a little to 1G (which
still allows insane file numbers up to 33554431), and tidy function
parameter types so that we only need one file number sanity check.

* dwarf2dbg.c (assign_file_to_slot): Take a valueT file number.
Reduce max files array size.
(allocate_filename_to_slot): Take a valueT file number.
(dwarf2_directive_filename): Don't duplicate file number
sanity check here.

Remove Marcus Shawcroft from the MAINTAINERS file

Marcus has resigned from the project.

ld/testsuite: Use $plug_opt for --plugin option

Use $plug_opt for --plugin usage, instead of running:

run_host_cmd "$CC_FOR_TARGET" "-print-prog-name=liblto_plugin.so"

PR binutils/21479
* testsuite/ld-plugin/lto-binutils.exp (lto_plugin): Removed.
Replace "--plugin $lto_plugin" with $plug_opt.
* testsuite/ld-plugin/lto.exp (lto_plugin): Removed.
Replace "--plugin $lto_plugin" with $plug_opt.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

Remove annoying spaces from objcopy.exp

Remove annoying spaces from bfd/elfxx-aarch64.c

Remove annoying space from gas/config/obj-elf.c

strip: Add GCC LTO IR support

Add GCC LTO IR support to strip by copying GCC LTO IR input as unknown
object file.  Don't enable LTO plugin in strip unless all LTO sections
should be removed, assuming all LTO sections will be removed with
-R .gnu.lto_.*.  Add linker LTO tests for strip with --strip-unneeded
and GCC LTO IR inputs.

binutils/

PR binutils/21479
* objcopy.c: Include "plugin-api.h" and "plugin.h".
(lto_sections_removed): New.
(command_line_switch): Add OPTION_PLUGIN.
(strip_options): Likewise.
(strip_usage): Display "--plugin NAME".
(copy_unknown_file): New function.
(copy_unknown_object): Call copy_unknown_file.
(copy_archive): Copy input LTO IR member as unknown object.
(copy_file): Set input target to "plugin" for strip if it is
unset unless all LTO sections should be removed.  Copy input
LTO IR file as unknown file.
(strip_main): Call bfd_plugin_set_program_name. Handle
OPTION_PLUGIN.  Set lto_sections_removed to true if all GCC
LTO sections should be removed.
* doc/binutils.texi: Document --plugin for strip.

ld/

PR binutils/21479
* testsuite/ld-plugin/lto-binutils.exp: New file.
* testsuite/ld-plugin/strip-1a-fat.c: Likewise.
* testsuite/ld-plugin/strip-1a-fat.rd: Likewise.
* testsuite/ld-plugin/strip-1b-fat.c: Likewise.
* testsuite/ld-plugin/strip-1b-fat.rd: Likewise.
* testsuite/ld-plugin/strip-1a.c: Likewise.
* testsuite/ld-plugin/strip-1b.c: Likewise.
* testsuite/lib/ld-lib.exp (run_cc_link_tests): Add optional
trailing ld options.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

ld: fix C23 issue in vers7 test

This test is UNSUPPORTED on arm64 with GCC 15 (which defaults to -std=gnu23)
because it now prototypes "no arguments".

PR ld/32546
* ld-elfvers/vers7.c: Fix function definitions for C23.

Automatic date update in version.in

aarch64: Replace incorrect comment

The comment explaining the placement of the cfinv entry before the
generic msr entry in the opcode table was incorrect.  The issue is
unrelated to the all ones bitmask for cfinv, and is actually due the
large number of architectural aliases of the msr instruction.

gdb/python: new gdb.ParameterPrefix class

This commit adds a new gdb.ParameterPrefix class to GDB's Python API.

When creating multiple gdb.Parameters, it is often desirable to group
these together under a sub-command, for example, 'set print' has lots
of parameters nested under it, like 'set print address', and 'set
print symbol'.  In the Python API the 'print' part of these commands
are called prefix commands, and are created using gdb.Command objects.

However, as parameters are set via the 'set ....' command list, and
shown through the 'show ....' command list, creating a prefix for a
parameter usually requires two prefix commands to be created, one for
the 'set' command, and one for the 'show' command.

This often leads to some duplication, or at the very least, each user
will end up creating their own helper class to simplify creation of
the two prefix commands.

This commit adds a new gdb.ParameterPrefix class.  Creating a single
instance of this class will create both the 'set' and 'show' prefix
commands, which can then be used while creating the gdb.Parameter.

Here is an example of it in use:

  gdb.ParameterPrefix('my-prefix', gdb.COMMAND_NONE)

This adds 'set my-prefix' and 'show my-prefix', both of which are
prefix commands.  The user can then add gdb.Parameter objects under
these prefixes.

The gdb.ParameterPrefix initialise method also supports documentation
strings, so we can write:

  gdb.ParameterPrefix('my-prefix', gdb.COMMAND_NONE,
      "Configuration setting relating to my special extension.")

which will set the documentation string for the prefix command.

Also, it is possible to support prefix commands that use the `invoke`
functionality to handle unknown sub-commands.  This is done by
sub-classing gdb.ParameterPrefix and overriding either 'invoke_set' or
'invoke_show' to handle the 'set' or 'show' prefix command
respectively.

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

gdb/guile: generate general description string for parameters

This commit builds on the previous one, and auto-generates a general
description string for parameters defined via the Guile API.  This
brings the Guile API closer inline with the Python API.  It is worth
reading the previous commit to see some motivating examples.

This commit updates get_doc_string in guile/scm-param.c to allow for
the generation of a general description string.  Then in
gdbscm_make_parameter, if '#:doc' was not given, get_doc_string is
used to generate a suitable default.

This does invalidate (and so the commit removes) this comment that was
in gdbscm_make_parameter:

  /* If doc is NULL, leave it NULL.  See add_setshow_cmd_full.  */

First, Python already does exactly what I'm proposing here, and has
done for a while, with no issues reported.  And second, I've gone and
read add_setshow_cmd_full, and some of the functions it calls, and can
see no reasoning behind this comment...

... well, there is one reason that I can think of, but I'll discuss
that more below.

With this commit, if I define a parameter like this:

  (use-modules (gdb))
  (register-parameter! (make-parameter
                        "print test"
                        #:command-class COMMAND_NONE
                        #:parameter-type PARAM_BOOLEAN))

Then, in GDB, I now see this behaviour:

  (gdb) help show print test
  Show the current value of 'print test'.
  This command is not documented.
  (gdb) help set print test
  Set the current value of 'print test'.
  This command is not documented.
  (gdb)

The two 'This command is not documented.' lines are new.  This output
is what we get from a similarly defined parameter using the Python
API (see the previous commit for an example).

I mentioned above that I can think of one reason for the (now deleted)
comment in gdbscm_make_parameter about leaving the doc field as NULL,
and that is this: consider the following GDB behaviour:

  (gdb) help show style filename foreground
  Show the foreground color for this property.
  (gdb)

Notice there is only a single line of output.  If I want to get the
same behaviour from a parameter defined in Guile, I might try skipping
the #:doc argument, but (after this commit), if I do that, GDB will
auto-generate some text for me, giving two lines of output (see
above).

So, next, maybe I try setting #:doc to the empty string, but if I do
that, then I get this:

  (use-modules (gdb))
  (register-parameter! (make-parameter
                        "print test"
#:doc ""
                        #:command-class COMMAND_NONE
                        #:parameter-type PARAM_BOOLEAN))

  (gdb) help show print test
  Show the current value of 'print test'.

  (gdb)

Notice the blank line, that's not what I wanted.  In fact, the only
way to get rid of the second line is to leave the 'doc' variable as
NULL in gdbscm_make_parameter, which, due to the new auto-generation,
is no longer possible.

This issue also existed in the Python API, and was addressed in
commit:

  commit 4b68d4ac98aec7cb73a4b276ac7dd38d112786b4
  Date:   Fri Apr 11 23:45:51 2025 +0100

      gdb/python: allow empty gdb.Parameter.__doc__ string

After this commit, an empty __doc__ string for a gdb.Parameter is
translated into a NULL pointer passed to the add_setshow_* command,
which means the second line of output is completely skipped.

And this commit includes the same solution for the Guile API.  Now,
with this commit, and the Guile parameter using an empty '#:doc'
string, GDB has the following behaviour:

  (gdb) help show print test
  Show the current value of 'print test'.
  (gdb)

This matches the output for a similarly defined parameter in Python.

gdb/guile: improve auto-generated strings for parameters

Consider this user defined parameter created in Python:

  class test_param(gdb.Parameter):
     def __init__(self, name):
        super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
        self.value = True

  test_param('print test')

If this is loaded into GDB, then we observe the following behaviour:

  (gdb) show print test
  The current value of 'print test' is "on".
  (gdb) help show print test
  Show the current value of 'print test'.
  This command is not documented.
  (gdb) help set print test
  Set the current value of 'print test'.
  This command is not documented.
  (gdb)

If we now define the same parameter using Guile:

  (use-modules (gdb))
  (register-parameter! (make-parameter
                        "print test"
                        #:command-class COMMAND_NONE
                        #:parameter-type PARAM_BOOLEAN))

And load this into a fresh GDB session, we see the following:

  (gdb) show print test
  Command is not documented is off.
  (gdb) help show print test
  This command is not documented.
  (gdb) help set print test
  This command is not documented.
  (gdb)

The output of 'show print test' doesn't make much sense, and is
certainly worse than the Python equivalent.  For both the 'help'
commands it appears as if the first line is missing, but what is
actually happening is that the first line has become 'This command is
not documented.', and the second line is then missing.

The problems can all be traced back to 'get_doc_string' in
guile/scm-param.c.  This is the guile version of this function.  There
is a similar function in python/py-param.c, however, the Python
version returns one of three different strings depending on the use
case.  In contrast, the Guile version just returns 'This command is
not documented.' in all cases.

The three cases that the Python code handles are, the 'set' string,
the 'show' string, and the general 'description' string.

Right now the Guile get_doc_string only returns the general
'description' string, which is funny, because, in
gdbscm_make_parameter, where get_doc_string is used, the one case that
we currently don't need is the general 'description' string.  Instead,
right now, the general 'description' string is used for both the 'set'
and 'show' cases.

In this commit I plan to bring the Guile API a little more inline with
the Python API.  I will update get_doc_string (in scm-param.c) to
return either a 'set' or 'show' string, and gdbscm_make_parameter will
make use of these strings.

The changes to the Guile get_doc_string are modelled on the Python
version of this function.  It is also worth checking out the next
commit, which is related, and helps motivate how the changes have been
implemented in this commit.

After this commit, the same Guile parameter description shown above,
now gives this behaviour:

  (gdb) show print test
  The current value of 'print test' is off.
  (gdb) help show print test
  Show the current value of 'print test'.
  (gdb) help set print test
  Set the current value of 'print test'.
  (gdb)

The 'show print test' output now matches the Python behaviour, and is
much more descriptive.  The set and show 'help' output are now missing
the second line when compared to the Python output, but the first line
is now correct, and I think this is better than the previous Guile
output.

In the next commit I'll address the problem of the missing second
line.

Existing tests have been updated to expect the new output.

gdb/python: allow empty gdb.Parameter.__doc__ string

I was recently attempting to create some parameters via the Python
API.  I wanted these parameters to appear similar to how GDB handles
the existing 'style' parameters.

Specifically, I was interested in this behaviour:

  (gdb) help show style filename foreground
  Show the foreground color for this property.
  (gdb) help set style filename foreground
  Set the foreground color for this property.
  (gdb)

Notice how each 'help' command only gets a single line of output.

I tried to reproduce this behaviour via the Python API and was unable.

The problem is that, in order to get just a single line of output like
this, the style parameters are registered with a call to
add_setshow_color_cmd with the 'help_doc' being passed as nullptr.

On the Python side, when parameters are created, the 'help_doc' is
obtained with a call to get_doc_string (python/py-param.c).  This
function either returns the __doc__ string, or a default string: "This
command is not documented.".

To avoid returning the default we could try setting __doc__ to an
empty string, but setting this field to any string means that GDB
prints a line for that string, like this:

  class test_param(gdb.Parameter):
     __doc__ = ""
     def __init__(self, name):
        super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
        self.value = True

  test_param('print test')

Then in GDB:

  (gdb) help set print test
  Set the current value of 'print test'.

  (gdb)

The blank line is the problem I'd like to solve.

This commit makes a couple of changes to how parameter doc strings are
handled.

If the doc string is set to an empty string, then GDB now converts
this to nullptr, which removes the blank line problem, the new
behaviour in GDB (for the above `test_param`) is:

  (gdb) help set print test
  Set the current value of 'print test'.
  (gdb)

Next, I noticed that if the set/show docs are set to empty strings,
then the results are less than ideal:

  class test_param(gdb.Parameter):
     set_doc = ""
     def __init__(self, name):
        super ().__init__(name, gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
        self.value = True

  test_param('print test')

And in GDB:

  (gdb) help set print test

  This command is not documented.
  (gdb)

So, if the set/show docs are the empty string, GDB now forces these to
be the default string instead, the new behaviour in GDB is:

  (gdb) help set print test
  Set the current value of 'print test'.
  This command is not documented.
  (gdb)

I've added some additional asserts; the set/show docs should always be
non-empty strings, which I believe is the case after this commit.  And
the 'doc' string returned from get_doc_string should never nullptr,
but could be empty.

There are new tests to cover all these changes.

gdb/python/guile: check for invalid prefixes in Command/Parameter creation

The manual for gdb.Parameter says:

  If NAME consists of multiple words, and no prefix parameter group
  can be found, an exception is raised.

This makes sense; we cannot create a parameter within a prefix group,
if the prefix doesn't exist.  And this almost works, so:

  (gdb) python gdb.Parameter("xxx foo", gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)
  Python Exception <class 'RuntimeError'>: Could not find command prefix xxx.
  Error occurred in Python: Could not find command prefix xxx.

The prefix 'xxx' doesn't exist, and we get an error.  But, if we try
multiple levels of prefix:

  (gdb) python gdb.Parameter("print xxx foo", gdb.COMMAND_NONE, gdb.PARAM_BOOLEAN)

This completes without error, however, we didn't get what we were
maybe expecting:

  (gdb) show print xxx foo
  Undefined show print command: "xxx foo".  Try "help show print".

But we did get:

  (gdb) show print foo
  The current value of 'print foo' is "off".

GDB stopped scanning the prefix string at the unknown 'xxx', and just
created the parameter there.  I don't think this makes sense, nor is
it inline with the manual.

An identical problem exists with gdb.Command creation; GDB stops
parsing the prefix at the first unknown prefix, and just creates the
command there.  The manual for gdb.Command says:

  NAME is the name of the command.  If NAME consists of multiple
  words, then the initial words are looked for as prefix commands.
  In this case, if one of the prefix commands does not exist, an
  exception is raised.

So again, the correct action is, I believe, to raise an exception.

The problem is in gdbpy_parse_command_name (python/py-cmd.c), GDB
calls lookup_cmd_1 to look through the prefix string and return the
last prefix group.  If the very first prefix word is invalid then
lookup_cmd_1 returns NULL, and this case is handled.  However, if
there is a valid prefix, followed by an invalid prefix, then
lookup_cmd_1 will return a pointer to the last valid prefix list, and
will update the input argument to point to the start of the invalid
prefix word.  This final case, where the input is left pointing to an
unknown prefix, was previously not handled.

I've fixed gdbpy_parse_command_name, and added tests for command and
parameter creation to cover this case.

The exact same error is present in the guile API too.  The guile
documentation for make-parameter and make-command says the same things
about unknown prefixes resulting in an exception, but the same error
is present in gdbscm_parse_command_name (guile/scm-cmd.c), so I've
fixed that too, and added some tests.

Automatic date update in version.in

gdb/dwarf: skip broken .debug_macro.dwo

Running gdb.base/errno.exp with gcc <= 13 with split DWARF results in:

    $ make check TESTS="gdb.base/errno.exp" RUNTESTFLAGS="CC_FOR_TARGET=gcc-13 --target_board=fission"
    (gdb) break -qualified main
    /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7549: internal-error: locate_dwo_sections: Assertion `!dw_sect->readin' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    ...
    FAIL: gdb.base/errno.exp: macros: gdb_breakpoint: set breakpoint at main (GDB internal error)

The assert being hit has been added in 28f15782adab ("gdb/dwarf: read
multiple .debug_info.dwo sections"), but it merely exposed an existing
problem.

gcc versions <= 13 are affected by this bug:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111409

Basically, it produces .dwo files with multiple .debug_macro.dwo
sections, with some unresolved links between them.  I think that this
macro debug info is unusable, and all we can do is ignore it.

In locate_dwo_sections, if we detect a second .debug_macro.dwo section,
forget about the previous .debug_macro.dwo and any subsequent one.  This
will effectively make it as if the macro debug info wasn't there at all.

The errno test seems happy with it:

    # of expected passes            84
    # of expected failures          8

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

gdb/dwarf: move loops into locate_dw{o,z}_sections

For a subsequent patch, it would be easier if the loop over sections
inside locate_dwo_sections (I want to maintain some state for the
duration of the loop).  Move the for loop in there.  And because
locate_dwz_sections is very similar, modify that one too, to keep both
in sync.

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

gdb/dap: fix decode_source

The documentation for the Source interface says

   * The path of the source to be shown in the UI.
   * It is only used to locate and load the content of the source if no
   * `sourceReference` is specified (or its value is 0).

but the code used `path` first. I fixed it to use `sourceReference` first.

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

[PATCH] Add syscall tests when following/detaching from fork

breakpoints/13457 discusses issues with syscall catchpoints when
following forks, lamenting that there is no coverage for the
various permutations of `follow-fork-mode' and `detach-on-fork'.

This is an attempt to try and cover some of this ground. Unfortunately
the state of syscall support when detaching after the fork is
very, very inconsistent across various architectures. [I've tested
extensively Fedora/RHEL platforms.]

Right now, the only reliable platform to run tests on is x86_64/i?86
for the specific case where we do not detach from the fork. Consequently,
this patch limits testing to those architectures.

I have updated breakpoints/13457 with my findings on failures with the
detaching case.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13457
Approved-By: Andrew Burgess <aburgess@redhat.com>

aarch64: Support for FEAT_RME_GPC3

FEAT_RME_GPC3 - RME Granule Protection Check 3 Extension - introduces
a method for defining a set of windows in the memory map for which
Granule Protection Checks are skipped, and instead applies a set of
default settings associated with the window.

This patch introduces the sysreg gpcbw_el3. Add -march=armv9.5-a to
access this sysreg since this feature is optional from armv9.5-a.

aarch64: Support for FEAT_OCCMO

FEAT_OCCMO - Outer Cacheable Cache Maintenance Operation - introduces
system instructions that provides software with a mechanism to publish
writes to the Outer cache level.

gdbsupport/event-loop: do not truncate poll timeouts to lower second

In update_wait_timeout function, microseconds were not taken into account
in poll timeout computation, resulting in 100% cpu time consumption in
the event loop while waiting for a sub-second timeout.

The bug has been introduced in commit c2c6d25.

This patch adds the microseconds converted to milliseconds in poll
timeout computation. Conversion by excess (ceil) is performed to
avoid the same problem with sub-millisecond timeouts too.

gdb: pass std::string from linux_find_memory_regions_full

Update linux_find_memory_region_ftype to take 'const std::string &'
instead of 'const char *', update the two functions which are passed
as callbacks to linux_find_memory_regions_full.

There should be no user visible changes after this commit.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb: remove unnecessary function declaration

There's no need to declare a function immediately before its
definition.  Lets not do that.

There should be no user visible changes after this commit.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb: move extra checks into dump_note_entry_p

Now that dump_note_entry_p is always called (see previous commit), we
can move some of the checks out of linux_make_mappings_callback into
dump_note_entry_p.

The checks only exist in linux_make_mappings_callback because, before
the previous commit, we couldn't be sure that dump_note_entry_p would
be called or not, so linux_make_mappings_callback had to run its own
checks.

Now that dump_note_entry_p is always called we can rely on that
function to filter out which mappings should result in an NT_FILE
entry, and linux_make_mappings_callback can just create an entry for
everything it is passed.

As a result of this change I was able to remove the inode argument
from linux_make_mappings_callback and
linux_find_memory_regions_thunk.  The inode check has now moved to
dump_note_entry_p.

There should be no user visible changes after this commit.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb: always call should_dump_mapping_p during core file creation

This commit moves the logic for whether should_dump_mapping_p is
called out of linux_find_memory_regions_full and pushes it down into
the two callback functions that are used as the should_dump_mapping_p
callback; `dump_mapping_p` and `dump_note_entry_p`.

Older Linux kernels don't make the 'Anonymous' information available
in the smaps file, and currently, GDB handles this by not calling the
should_dump_mapping_p callback in linux_find_memory_regions_full,
instead the answer is hard-coded to true.

This is (maybe) fine for dump_mapping_p, but for dump_note_entry_p,
this choice makes little sense.  The dump_note_entry_p function
doesn't even use the anonymous mapping information.

I propose that the 'has_anonymous' check should be moved out of
linux_find_memory_regions_full, and pushed into dump_mapping_p.  Then
in dump_note_entry_p there will be no has_anonymous check; it just
isn't needed.

This allows linux_find_memory_regions_full to be simplified a little,
and will allow some additional clean ups in
linux_make_mappings_callback, which is the partner function to
dump_note_entry_p (see linux_make_mappings_corefile_notes), now that
we know dump_note_entry_p is always called.  This follow on clean up
will be done in a later commit in this series.

Looking at dump_mapping_p, I do wonder if the ::has_anonymous check
could be moved later in the function.  The first few checks in
dump_mapping_p don't rely on the anonymous information, so running
them might give better results.  However, the lack of the anonymous
information is only for older kernels, so testing any changes in this
area would likely require spinning up an older kernel, and as the
years pass, we likely care about this case less.  So for now I've left
the ::has_anonymous check as the first thing in dump_mapping_p as this
keeps the existing behaviour.

There should be no user visible changes after this commit.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb: pass struct smaps_data to linux_dump_mapping_p_ftype

Simplify the argument passing in linux_find_memory_regions_full when
calling the should_dump_mapping_p callback.  Instead of pulling all
the components from the smaps_data object and passing them separately,
just pass the smaps_data object.

I think this change is justified on its own; the code seems cleaner,
and easier to read to my eye.  But additionally, in a later commit in
this series I want to pass smaps_data::has_anonymous to the
should_dump_mapping_p callback, which would mean adding yet another
argument, and I think the argument list is already long enough.
Changing the function now to pass the smaps_data object means that I
will already have the ::has_anonymous field available in the later
commit.

There should be no user visible changes after this commit.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb: use bool more in linux-tdep.c

Convert linux_dump_mapping_p_ftype to return a bool, and then update
everything that is needed to handle the fallout from this change.

There should be no user visible changes from this commit.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb: add '-stopped' and '-running' options to "info threads"

Add two options to "info threads": `-stopped` and `-running`.

The purpose of these options is to filter the output of the command.
The `-stopped` option means "print stopped threads only" and,
similarly, `-running` means "print the running threads only".  When
both options are provided by the user, the indication is that the user
wants the union.  That is, the output contains both stopped and
running threads.

Suppose we have an application with 5 threads, 2 of which have hit a
breakpoint.  The "info threads" command in the non-stop mode gives:

  (gdb) info threads
    Id   Target Id             Frame
  * 1    Thread 0x7ffff7d99740 (running)
    2    Thread 0x7ffff7d98700 something () at file.c:30
    3    Thread 0x7ffff7597700 (running)
    4    Thread 0x7ffff6d96700 something () at file.c:30
    5    Thread 0x7ffff6595700 (running)
  (gdb)

Using the "-stopped" flag, we get

  (gdb) info threads -stopped
    Id   Target Id             Frame
    2    Thread 0x7ffff7d98700 something () at file.c:30
    4    Thread 0x7ffff6d96700 something () at file.c:30
  (gdb)

Using the "-running" flag, we get

  (gdb) info threads -running
    Id   Target Id             Frame
  * 1    Thread 0x7ffff7d99740 (running)
    3    Thread 0x7ffff7597700 (running)
    5    Thread 0x7ffff6595700 (running)
  (gdb)

Using both flags prints all:

  (gdb) info threads -stopped -running
    Id   Target Id             Frame
  * 1    Thread 0x7ffff7d99740 (running)
    2    Thread 0x7ffff7d98700 something () at file.c:30
    3    Thread 0x7ffff7597700 (running)
    4    Thread 0x7ffff6d96700 something () at file.c:30
    5    Thread 0x7ffff6595700 (running)
  (gdb)

When combined with a thread ID, filtering applies to those threads that
are matched by the ID.

  (gdb) info threads 3
    Id   Target Id             Frame
    3    Thread 0x7ffff7597700 (running)
  (gdb) info threads -stopped 3
  No threads matched.
  (gdb)

Regression-tested on X86_64 Linux.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-by: Pedro Alves <pedro@palves.net

gdb: update "info threads" output when no threads match the arguments

If "info threads" is provided with the thread ID argument but no such
threads matching the thread ID(s) are found, GDB prints

  No threads match '<ID...>'.

Update this output to the more generalized

  No threads matched.

The intention is that the next patch, and potentially future ones,
will extend the command with more filter/match arguments.  We cannot
customize the output to each such argument.  Hence, be more generic.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-by: Pedro Alves <pedro@palves.net

gdb: pass info_threads_opts to print_thread_info_1

The "info threads" command tracks its options in a struct named
'info_threads_opts', which currently has only one option.  Pass the
whole options object to helper functions, instead of passing
the option value individually.  This is a refactoring to make adding
more options easier.

Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-by: Pedro Alves <pedro@palves.net

Automatic date update in version.in

ubsan: size_inc_line_addr integer overflow

Fix a fuzzer testcase where a large positive line_delta causes signed
overflow when subtracting -5.  Signed overflow is perfectly OK here.

msan: use of uninitialised data in get_cie_info

This completely bogus oss-fuzz x86 testcase results in a read from an
uninitialised (at the time check_eh_frame is called) part of an insn
frag:
 .section .debug_frame
 orl $1,x
 .long x
 .uleb128 0,x,0
x:

Fix the problem by verifying the assumption in get_cie_info that a CIE
starts at the beginning of .eh_frame or .debug_frame.  Or at least
exclude silliness involving instructions placed there.  That seems a
useful sanity check.  Also sanity check sizes of initial FDE fields.

Yes, this doesn't completely stop the problem since you could place an
insn with a relocated field later in the CIE.  If fuzzers find such a
testcase I'll ignore it.

* ehopt.c (struct cie_info): Add "f" field.
(get_cie_info): Return a bool.  Verify frag at start of chain
is one with the CIE size found by check_eh_frame.
(check_eh_frame): Save CIE start frag.  Only accept 4 or 8
byte fields in state_saw_size, state_saw_cie_offset and
state_saw_pc_begin.  Formatting.  Localise "fix" variable.

Automatic date update in version.in

gdb: LoongArch: Emulate floating-point branch instructions

Add bceqz and bcnez cases in loongarch_insn_is_cond_branch() and
loongarch_next_pc() to emulate floating-point branch instructions.

Here are the references:

https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#_bceqz_bcnez
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#table-table-of-instruction-encoding

Approved-by: Kevin Buettner <kevinb@redhat.com>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

Automatic date update in version.in

MAINTAINERS: Update my email address

Update my email address and move up Surya's name as the main PPC contact.

Signed-off-by: Peter Bergner <bergner@tenstorrent.com>

Fix two comments in cli-style.c

I noticed that a couple of new comments in cli-style.c mentioned the
wrong command name.  This patch fixes the comments.

Move "show style sources" documentation

I noticed that I had inadvertently put the "set style warning-prefix"
documentation between the paragraph for "set style sources" and the
paragraph for "show style sources".  This patch moves the latter up a
bit to clean this up.

aarch64: Mark predicate-as-counter pseudo instructions

Using explicit pseudo aliases is clearer and more consistent with other
instruction aliases.

This does not change behaviour.  For the non-alias instructions
(everything except mov) we already picked the first matching entry for
disassembly by default.  For mov we picked the last matching aliased
entry, which remained the original alias since do_misc_decoding doesn't
recognise OP_MOV_PN_PN.

aarch64: Mark clearbhb as a pseudo instruction

This was an early name for the clrbhb hint instruction.  Some software
was written with the old name before it was renamed, so we support it
for assembly but should never use it in disassembly.

This patch has no functional change, because we already pick (by
default) the last matching alias in the opcode table, and clrbhb is
listed later than clearbhb.

aarch64: Merge dgh tests into system.d

aarch64: Fix dgh disassembly

aarch64: Mark SME mova aliases

This will only change behaviour during disassembly with -M no-aliases.

aarch64: Mark rev64 as a pseudo instruction

This is more natural than raising the priority of rev with F_P1, and
is functionally equivalent.

aarch64: Add new test original-missing-misc.d

This test file includes all the remaining untested instructions that
weren't part of a larger group of new or existing tests.

aarch64: Add new test mov-wide.d

Only movn was previously untested.

aarch64: Add new test exception-generation.d

svc and dcps* were already tested, but are included here as part of the
same encoding group.

aarch64: Add new test conditional-compare.d

The register form of ccmp was already tested.

aarch64: Add new test branch-cond-pseudos.d

beq, bne, bcs and bcc were already tested, and bge and ble are also used
in scfi tests.

aarch64: Add new test ldst-unpriv.d

All instructions were previously untested.

aarch64: Add new test ldst-extend-general.d

All instructions were previously untested.

aarch64: Add new test dp-general-two-source.d

lsl was already tested but is included here as part of the same encoding
group.

aarch64: Add new test dp-general-one-source.d

rev16 and the 64-bit rev/rev64 instructions were already tested, but are
included here as part of the same encoding group.

aarch64: Add new test addsub-carry.d

All instructions were previously untested.

aarch64: Add new test advsimd-scalar-doubling-mul.d

All instructions were previously untested.

aarch64: Add new test advsimd-scalar-two-reg-misc.d

sqabs, sqneg, abs and neg were already tested, but are included here as
part of the same encoding group.

aarch64: Add new test advsimd-scalar-shift-immediate.d

All instructions were previously untested.

aarch64: Add new test advsimd-scalar-three-same.d

All instructions were previously untested.

aarch64: Add new test advsimd-copy.d

Only smov and the second dup variant were previously untested.  However,
the only test for umov was a disassembly test with -M no-aliases, and
the first dup variant was only tested in assembly in diagnostic.d with
the non-architectural syntax `dup v0.2d, v1.2d[0]`.

aarch64: Add new test advsimd-permute.d

All instructions were previously untested.

aarch64: Add new test advsimd-modified-immediate.d

All instructions (7 opcode table entries) were previously untested.

aarch64: Add new test advsimd-two-reg-misc-hilo.d

All instructions were previously untested.

aarch64: Add new test advsimd-two-reg-misc.d

sqabs, abs, not, mvn, sqneg and neg were already tested, and cmeq was
already assembled in an error test (sve-reg-diagnostic.d), but they are
all included here as part of the same encoding group.

aarch64: Add new test advsimd-mul-element.d

All instructions were previously untested.

aarch64: Add new test advsimd-widening-narrowing.d

All instructions were previously untested.

aarch64: Add new test advsimd-three-same.d

All instructions except orr/mov were previously untested.

aarch64: Add missing widening fmops test

Also remove the valid instructions from the test for invalid
instructions - this meant that the instruction was previously being
tested for assembly but not disassembly.

aarch64: Add tests for fabd, urecpe and ursqrt

Other instructions in the encoding group are tested in advsimd-fp16.d,
so add these instructions to the existing test file.

aarch64: Add tests for fcvt, fcvtzs and fcvtzu

Other instructions in the encoding group are tested in float-fp16.d, so
add these instructions to the existing test file.

aarch64: Add tests for csdb and eret to system.d

aarch64: Add test for ands and bics

The other instructions in the encoding group are tested in shifted.d, so
add these to the existing test file.

aarch64: Adjust float-fp16.d test patterns

Adjust the test to match instruction addresses of any length.