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.

aarch64: Adjust advsimd-fp16.d test patterns

Adjust the test to match instruction addresses of any length, and escape
literal '.' characters for a stricter match.

aarch64: Adjust shifted.d test patterns

Adjust the test to match any instruction addresses, so that the test can
be extended more easily.

aarch64: Eliminate AARCH64_OPND_SVE_ADDR_R

Adjust parsing for AARCH64_OPND_SVE_ADDR_RR{_LSL*} operands to accept
implicit XZR offsets.  Add new AARCH64_OPND_SVE_ADDR_RM{_LSL*} operands
to support instructions where an XZR offset is allowed but must be
specified explicitly.  This allows the removal of the duplicate opcode
table entries using AARCH64_OPND_SVE_ADDR_R.

aarch64: Disallow invalid SVE addressing modes

The fix for PR22988 in 2018 added a new operand AARCH64_OPND_SVE_ADDR_R
to support implicit XZR offsets, but this fix had several flaws that
meant it accepted several invalid addressing modes:

1. The base register type wasn't properly checked when the optional
register offset was omitted.  This meant that
  ldff1b {z1.s}, p1/z,[z1.d]
was parsed as if it were
  ldff1b z1.d, p1/z, [x1.d, xzr].

2. The explicit offset parsing didn't include a shift type, so the new
operand would incorrectly parse
  ldff1h{z0.s}, p0/z, [x0, x0]
as if it were
  ldff1h{z0.s}, p0/z, [x0, x0, lsl #1].

3. Regardless of the above correctness issues, support for implicit
offsets should have been added by amending the operands in the existing
opcode table entries, instead of adding new duplicate table entires.

Issue 1 can be fixed by using an "if" instead of an "else if" in
parse_operands, while issue 2 can be fixed by failing when the first
condition is false.  This patch applies just these two fixes, leaving
issue 3 to be addressed in a subsequent more invasive patch.

The instructions removed from the test sme-5.d are architecturally
invalid. The new tests cover all of the affected ldff1 variants; the
issue also affected SME ZA ld1*/st1* instructions using the same operand
type.

RISC-V: Support Zce 1.0

Zce is the extension defined in code-size-reduction

Ref: https://github.com/riscvarchive/riscv-code-size-reduction

Co-authored-by: Kito Cheng <kito.cheng@sifive.com>

RISC-V: Base for complex extension implications

Thanks to the commit 48558a5e5471 ("RISC-V: Allow nested implications for
extensions"), we can write complex extension implications in theory.
However, to actually do that, we need to pass more information to
check_func.

For example, we want to imply 'Zcf' from 'F' if and only if the 'Zce'
extension is also enabled and XLEN is 32.  Passing rps is a way to
enable this.

This commit prepares for such complex extension implications.

RISC-V: Add augmented hypervisor extension 'sha' support.

The augmented hypervisor extension 'sha'[1] is a new profile-defined extension
that captures the full set of features that are mandated to be supported along
with the H extension.

https://github.com/riscv/riscv-profiles/blob/main/src/rva23-profile.adoc#rva23s64-profile

bfd/ChangeLog:

* elfxx-riscv.c: New extension and implies.

gas/ChangeLog:

* NEWS: New extension.
* testsuite/gas/riscv/imply.d: New test for sha.
* testsuite/gas/riscv/imply.s: Ditto.
* testsuite/gas/riscv/march-help.l: New extension.

RISC-V: Add Privileged Architecture 1.13 CSRs.

This patch support RISC-V Privileged Architecture 1.13 CSRs 'medelegh' and
'hedelegh'. More details between 1.12 and 1.13 see [1].

[1] https://github.com/riscv/riscv-isa-manual/blob/main/src/priv-preface.adoc

Version log: Remove gas/po changes.

bfd/ChangeLog:

        * cpu-riscv.c: New option.
        * cpu-riscv.h (enum riscv_spec_class): Ditto.

binutils/ChangeLog:

        * doc/binutils.texi: New option.

gas/ChangeLog:

        * NEWS: Add priv-1.13 support.
        * config/tc-riscv.c: New option.
        * configure: Ditto.
        * configure.ac: Ditto.
        * testsuite/gas/riscv/csr-version-1p10.d: New CSR.
        * testsuite/gas/riscv/csr-version-1p10.l: New warning.
        * testsuite/gas/riscv/csr-version-1p11.d: New CSR.
        * testsuite/gas/riscv/csr-version-1p11.l: New warning.
        * testsuite/gas/riscv/csr-version-1p12.d: New CSR.
        * testsuite/gas/riscv/csr-version-1p12.l: New warning.
        * testsuite/gas/riscv/csr.s: New CSR.
        * testsuite/gas/riscv/attribute-15.d: New test.
        * testsuite/gas/riscv/attribute-16.d: New test.
        * testsuite/gas/riscv/csr-version-1p13.d: New test.
        * testsuite/gas/riscv/csr-version-1p13.l: New test.

include/ChangeLog:

        * opcode/riscv-opc.h (CSR_MEDELEGH): New CSR.
        (CSR_HEDELEGH): Ditto.
        (DECLARE_CSR): Ditto.

RISC-V: Added vendor extensions, xmipscbop, xmipscmov, xmipsexectl and xmipslsp

Spec:
https://mips.com/wp-content/uploads/2025/03/P8700-F_Programmers_Reference_Manual_Rev1.82_3-19-2025.pdf

Added MIPS vendor extensions, xmipscbop, xmipscmov, xmipsexectl and xmipslsp
with verison 1.0.

Passed binutils testsuites of targets elf32/elf64/linux32/linux64.

Signed-off-by: Jovan Dmitrović <jovan.dmitrovic@htecgroup.com>
Signed-off-by: Chao-ying Fu <cfu@wavecomp.com>

Automatic date update in version.in

Change substitute_path_component to use std::string

This changes substitute_path_component to use std::string and
std::string_view, simplifying it greatly and removing some manual
memory management.

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

Move substitute_path_component

This moves substitute_path_component out of utils.c.  I considered
making a new file for this (still could if someone wants that), but
since the only caller is in auto-load.c, I moved it there instead.

I've also moved the tests into auto-load.c as well.  This way
substitute_path_component can be static.

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

Automatic date update in version.in

windres: buffer overflow

bin_to_res_menuexitems can be called with random data offsets (and thus
remaining lengths), confusing code that expects 4-byte aligned data.
Prevent an item length adjustment for alignment exceeding the
remaining length and then overflowing.

Remove unnecessary use of pragma once in pr25618 test

s390: Fix format specifier for VR in disassembler

Vector register (VR) numbers are unsigned.  Use format specifier %u
instead of %i.

Reported-by: Florian Krohm <flo2030@eich-krohm.de>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>

Automatic date update in version.in

Do not set yydebug in cp-name-parser.y

This reverts the change to cp-name-parser.y, avoiding a TSan report.

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

Remove kfail from templates.exp

templates.exp has one remaining kfail.  However, the output in
question has been stabilized ever since the cp-name-parser.y work --
the test just wasn't updated.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8617
Reviewed-By: Keith Seitz <keiths@redhat.com>

Rewrite bug references in templates.exp

templates.exp has many kfails that refer to old GNATS bug numbers.
This patch updates them to refer to Bugzilla instead.

Reviewed-By: Keith Seitz <keiths@redhat.com>

Revert "gdb: support zero inode in generate-core-file command"

This reverts commit 1e21c846c275fc6e387ca903a129096be2a53d0b.

This change was causing unexpected mappings to be included in the core
files generated by GDB, which was triggering warnings when GDB opened
a core file, like this:

  warning: Can't open file [stack] during file-backed mapping note processing

  warning: Can't open file [vvar] during file-backed mapping note processing

For now I'm reverting the above commit and will come to the list again
when I have a solution that addresses the original issue without also
including the unexpected mappings.

Handle field with dynamic bit offset

I discovered that GCC emitted incorrect DWARF for the test case
included in this patch.  Eric wrote a fix for GCC, but then he found
that gdb crashed on the resulting file.

This test has a field that is at a non-constant bit offset from the
start of the type.  DWARF 5 does not allow for this situation (I've
sent a report to the DWARF list), but DWARF 3 did allow for this via a
combination of an expression for the byte offset and then the use of
DW_AT_bit_offset.  This looks like:

 <5><117a>: Abbrev Number: 17 (DW_TAG_member)
    <117b>   DW_AT_name        : (indirect string, offset: 0x1959): another_field
...
    <1188>   DW_AT_bit_offset  : 6
    <1189>   DW_AT_data_member_location: 6 byte block: 99 3d 1 0 0 22  (DW_OP_call4: <0x1193>; DW_OP_plus)
...
 <3><1193>: Abbrev Number: 2 (DW_TAG_dwarf_procedure)
    <1194>   DW_AT_location    : 15 byte block: 97 94 1 37 1a 32 1e 23 7 38 1b 31 1c 23 3  (DW_OP_push_object_address; DW_OP_deref_size: 1; DW_OP_lit7; DW_OP_and; DW_OP_lit2; DW_OP_mul; DW_OP_plus_uconst: 7; DW_OP_lit8; DW_OP_div; DW_OP_lit1; DW_OP_minus; DW_OP_plus_uconst: 3)

Now, that combination is not fully general, in that the bit offset
must be a constant -- only the byte offset may really vary.  However,
I couldn't come up with a situation where full generality is needed,
mainly because GNAT won't seem to pack fields into the padding of a
variable-length array.

Meanwhile, the reason for the gdb crash is that the code handling
DW_AT_bit_offset assumes that the byte offset is a constant.  This
causes an assertion failure.

This patch arranges for DW_AT_bit_offset to be applied during field
resolution, when needed.

Introduce apply_bit_offset_to_field helper function

This patch makes a new function, apply_bit_offset_to_field, that is
used to handle the logic of DW_AT_bit_offset.  Currently there is just
a single caller, but the next patch will change this.

Use OBSTACK_ZALLOC when allocating batons

I found some places in dwarf2/read.c that allocate a location baton,
but fail to initialize one of the fields.  It seems safer to me to use
OBSTACK_ZALLOC here, so this patch makes this change.  This will be
useful in a subsequent patch as well, where a new field is added to
one of the batons.

Clean up handle_member_location

This removes a redundant check from handle_member_location, and also
changes the complaint -- currently it will issue the "complex
location" complaint, but really what is happening here is an
unrecognized form.

Handle dynamic field properties

I found a situation where gdb could not properly decode an Ada type.
In this first scenario, the discriminant of a type is a bit-field.
PROP_ADDR_OFFSET does not handle this situation, because it only
allows an offset -- not a bit-size.

My original approach to this just added a bit size as well, but after
some discussion with Eric Botcazou, we found another failing case: a
tagged type can have a second discriminant that appears at a variable
offset.

So, this patch changes this code to accept a general 'struct field'
instead of trying to replicate the field-finding machinery by itself.

This is handled at property-evaluation time by simply using a 'field'
and resolving its dynamic properties.  Then the usual field-extraction
function is called to get the value.

Because the baton now just holds a field, I renamed PROP_ADDR_OFFSET
to PROP_FIELD.

The DWARF reader now defers filling in the property baton until the
fields have been attached to the type.

Finally, I noticed that if the discriminant field has a biased
representation, then unpack_field_as_long would not handle this
either.  This bug is also fixed here, and the test case checks this.

Regression tested on x86-64 Fedora 41.

Add new unpack_field_as_long overload

This introduces a new unpack_field_as_long that takes the field object
directly, rather than a type and an index.  This will be used in the
next patch.

Add resolve_dynamic_field

The final patch in this series will change one dynamic property
approach to use a struct field rather than an offset and a field type.
This is convenient because the reference in DWARF is indeed to a field
-- and this approach lets us reuse the field-extraction logic that
already exists in gdb.

However, the field in question may have dynamic properties which must
be resolved before it can be used.  This patch prepares for this by
introducing a separate resolve_dynamic_field function.

This patch should cause no visible changes to behavior.

Constify property_addr_info

This changes most places to use a const property_addr_info.  This
seems more correct to me because normally the user of a
property_addr_info should not modify it.  Furthermore, some functions
already take a const object, and for a subsequent patch it is
convenient if other functions do as well.

gdb/testsuite: Add require allow_hipcc_tests in gdb.rocm/mi-attach.exp

The gdb.rocm/mi-attach.exp test is missing a proper `require` check to
ensure that the current configuration can run ROCm tests.  This issue
has been reported by Baris.

This patch adds the missing `allow_hipcc_tests` requirement, and also
adds `load_lib rocm.exp` to enable this test.

Change-Id: Ie136adfc2d0854268b92af5c4df2dd0334dce259
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Approved-By: Tom Tromey <tom@tromey.com>

gdb: support zero inode in generate-core-file command

It is possible, when creating a shared memory segment (i.e. with
shmget), that the id of the segment will be zero.

When looking at the segment in /proc/PID/smaps, the inode field of the
entry holds the shared memory segment id.

And so, it can be the case that an entry (in the smaps file) will have
an inode of zero.

When GDB generates a core file, with the generate-core-file (or its
gcore alias) command, the shared memory segment should be written into
the core file.

Fedora GDB has, since 2008, carried a patch that tests this case.
There is no fix for GDB associated with the test, and unfortunately,
the motivation for the test has been lost to the mists of time.  This
likely means that a fix was merged upstream without a suitable test,
but I've not been able to find and relevant commit.  The test seems to
be checking that the shared memory segment with id zero, is being
written to the core file.

While looking at this test and trying to work out if it should be
posted upstream, I saw that GDB does appear to write the shared memory
segment into the core file (as expected), which is good.  However, GDB
still isn't getting this case exactly right.

In gcore_memory_sections (gcore.c) we call back into linux-tdep.c (via
the gdbarch_find_memory_regions call) to correctly write the shared
memory segment into the core file, however, in
linux_make_mappings_corefile_notes, when we use
linux_find_memory_regions_full to create the NT_FILE note, we call
back into linux_make_mappings_callback for each mapping, and in here
we reject any mapping with a zero inode.

The result of this, is that, for a shared memory segment with a
non-zero id, after loading the core file, the shared memory segment
will appear in the 'proc info mappings' output.  But, for a shared
memory segment with a zero id, the segment will not appear in the
'proc info mappings' output.

I propose fixing this by not checking the inode in
linux_make_mappings_callback.  The inode check was in place since the
code was originally added in commit 451b7c33cb3c9ec6272c36870 (in
2012).

The test for this bug, based on the original Fedora patch, can be
found on the mailing list here:

  https://inbox.sourceware.org/gdb-patches/0d389b435cbb0924335adbc9eba6cf30b4a2c4ee.1741776651.git.aburgess@redhat.com

I have not committed this test into the tree though because the test
was just too unreliable.  User space doesn't have any control over the
shared memory id, so all we can do is spam out requests for new shared
memory segments and hope that we eventually get the zero id.

Obviously, this can fail; the zero id might already be in use by some
long running process, or the kernel, for whatever reason, might choose
to never allocate the zero id.  The test I posted (see above thread)
did work more than 50% of the time, but it was far closer to a 50%
success rate than 100%, and I really don't like introducing unreliable
tests.

gdb/testsuite: add gcore_cmd_available predicate proc

Add a new gcore_cmd_available predicate proc that can be used in a
'requires' line, and make use of it in a few tests.

All of the tests I have modified call gdb_gcore_cmd as one of their
first actions and exit if the gcore command is not available, so it
makes sense (I think) to move the gcore command check into a requires
call.

There should be no change in what is actually run after this commit.

gdb/python/guile: check if styling is disabled in Color.escape_sequence

I noticed that the gdb.Color.escape_sequence() method would produce an
escape sequence even when styling is disabled.

I think this is the wrong choice.  Ideally, when styling is
disabled (e.g. with 'set style enabled off'), GDB should not be
producing styled output.

If a GDB extension is using gdb.Color to apply styling to the output,
then currently, the extension should be checking 'show style enabled'
any time Color.escape_sequence() is used.  This means lots of code
duplication, and the possibility that some locations will be missed,
which means disabling styling no longer does what it says.

I propose that Color.escape_sequence() should return the empty string
if styling is disabled.  A Python extension can then do:

  python
  c_none = gdb.Color('none')
  c_red = gdb.Color('red')
  print(c_red.escape_sequence(True)
        + "Text in red."
        + c_none.escape_sequence(True))
  end

If styling is enable this will print some red text.  And if styling is
disabled, then it will print text in the terminal's default color.

I have applied the same fix to the guile API.

I have extended the tests to cover this case.

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

gas: input_scrub buffers

This tidies freeing of input_scrub buffers on failure paths, making
input_scrub_end iterate over any input_scrub_push'd files or string
buffers to clean up memory.

* input-scrub.c (input_scrub_free): New function.
(input_scrub_pop): Call it rather than input_scrub_end.
(input_scrub_end): Iterate over next_saved_file freeing
buffers.
(input_scrub_next_buffer): Move sb_kill to input_scrub_free.

windres_get_* functions

windres_get_32 and similar have a length parameter that in most cases
is just the required length, so it is redundant.  The few cases where
a variable length is passed are all in resrc.c.  So, get rid of the
length parameter and introduce wrappers in resrc.c to check the
length.

Automatic date update in version.in

Fix sign of Ada rational constants

My earlier patch commit 0c03db90 ("Use correct sign in get_mpz") was
(very) incorrect.  It changed get_mpz to check for a strict sign when
examining part of an Ada rational constant.  However, in Ada the
"delta" for a fixed-point type must be positive, and so the components
of the rational representation will be positive.

This patch corrects the error.  It also renames the get_mpz function,
in case anyone is tempted to reuse this code for another purpose.

Finally, this pulls over the test from the internal AdaCore test suite
that found this issue.

gprofng: remove unused functions, duplicate macros

class Reloc is not used after commit
13f614be23a gprofng: Refactor readSymSec for using BFD's asymbol struct

Many common macros were defined in different sources.
Sometimes a macro was used, sometimes a macros value was used.
Removed unused macros and include files.

gprofng/ChangeLog
2025-05-03  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* common/gp-experiment.h: Define variables that are passed to
libcollector. Remove unused macros.
* libcollector/collector.c: Cleanup macros.
* libcollector/descendants.h: Likewise.
* libcollector/envmgmt.c: Likewise.
* libcollector/linetrace.c: Likewise.
* src/collect.h: Likewise.
* src/envsets.cc: Likewise.
* src/gp-collect-app.cc: Likewise.
* src/Stabs.cc: Remove class Reloc.
* src/Stabs.h: Likewise.
* src/ipcio.cc: Remove unused include files.

gprofng: fix 32892 source line level information not available with "-g -O2"

gprofng ignored DW_AT_specification.
As a result, gprofng skiped Dwarf for all functions declared as:
  < 2>:<0x0000f725> DW_TAG_subprogram(46)
      DW_AT_linkage_name(110)     "func_name"
      DW_AT_declaration*(60)      0x1 (1)
  < 1>:<0x00015acc> DW_TAG_subprogram(46)
       DW_AT_specification(71)    0xf725 (63269)

Another problem was that gprofng ignored DW_AT_ranges.
As a result, many functions are mapped to the <Unknown> module.

gprofng/ChangeLog
2025-05-01  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR 32892
* src/Dwarf.cc: Handle DW_AT_specification and DW_AT_ranges.
* src/DwarfLib.cc: Likewise.
* src/DwarfLib.h: Likewise.
* src/Dwarf.h (get_ranges): New function.
* src/Stabs.h (get_symbols): New function.
* src/Stabs.cc: Move Symbol class to src/Symbol.cc.
* src/Symbol.cc: New file.
* src/Symbol.h: New file.
* src/Makefile.am: Add Symbol.cc in build.
* src/Makefile.in: Rebuild.
* src/LoadObject.cc (dump_functions): Improve output for -dfunc option.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[gdb/testsuite] Simplify gdb.tui/tui-layout-asm.exp

On x86_64-cygwin, with test-case gdb.tui/tui-layout-asm.exp I run into:
...
WARNING: The following failure is probably due to the TUI window
         width.  See the comments in the test script for more
         details.
FAIL: $exp: scroll to end of assembler (scroll failed)
...

The problem is as follows.

On the TUI screen, we have:
1 | 0x1004010ff <__gdb_set_unbuffered_output+95> nop                         |
2 | 0x100401100 <__cxa_atexit>                   jmp *0x6fc2(%rip) # 0x10040 |
...

We send the down key, which should have the effect of scrolling up.  So, we
expect that the second line moves to the first line.

That seems to be the case indeed:
...
1 | 0x100401100 <__cxa_atexit> jmp *0x6fc2(%rip) # 0x1004080c8 <__imp___cxa_ |
...
but the line has changed somewhat, so the matching fails.

We could increase the width of the screen, as suggested in the test-case, but
I think that approach is fragile.

Instead, fix this by relaxing the matching: just check that the line before
scrolling is fully contained in the line after scrolling, or the other way
around.

Doing so gets us the next failure:
...
FAIL: $exp: scroll to end of assembler (too much assembler)
...

The test-case states:
...
    if { $down_count > 250 } {
# Maybe we should accept this as a pass in case a target
# really does have loads of assembler to scroll through.
fail "$testname (too much assembler)"
...
and I agree, so fix this by issuing a pass.

This results in the test-case taking ~20 seconds, so reduce the maximum number
of scrolls from 250 to 25, bringing that down to ~10 seconds.

Tested on x86_64-cygwin and x86_64-linux.

PR testsuite/32898
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32898

[gdb/symtab] Throw DWARF error on out-of-bounds DW_FORM_strx

With the test-case contained in the patch, and gdb build with
-fsanitize=address we get:
...
==23678==ERROR: AddressSanitizer: heap-buffer-overflow ...^M
READ of size 1 at 0x6020000c30dc thread T3^[[1m^[[0m^M
ptype global_var^M
    #0 0x2c6a40b in bfd_getl32 bfd/libbfd.c:846^M
    #1 0x168f96c in read_str_index gdb/dwarf2/read.c:15349^M
...

The executable contains an out-of-bounds DW_FORM_strx attribute:
...
$ readelf -wi $exec
<2eb>   DW_AT_name        :readelf: Warning: string index of 1 converts to \
  an offset of 0xc which is too big for section .debug_str
 (indexed string: 0x1): <string index too big>
...
and read_str_index doesn't check for this:
...
  info_ptr = (str_offsets_section->buffer
      + str_offsets_base
      + str_index * offset_size);
   if (offset_size == 4)
     str_offset = bfd_get_32 (abfd, info_ptr);
...
and consequently reads out-of-bounds.

Fix this in read_str_index by checking for the out-of-bounds condition and
throwing a DWARF error:
...
(gdb) ptype global_var
DWARF Error: Offset from DW_FORM_GNU_str_index or DW_FORM_strx pointing \
  outside of .debug_str_offsets section in CU at offset 0x2d7 \
  [in module dw-form-strx-out-of-bounds]
No symbol "global_var" in current context.
(gdb)
...

Tested on x86_64-linux.

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

[gdb/testsuite] Add gdb.dwarf2/dw-form-strx.exp

Add a test-case using DW_FORM_strx.

Tested on x86_64-linux.

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

[gdbsupport] Reimplement phex and phex_nz as templates

Gdbsupport functions phex and phex_nz have a parameter sizeof_l:
...
extern const char *phex (ULONGEST l, int sizeof_l);
extern const char *phex_nz (ULONGEST l, int sizeof_l);
...
and a lot of calls use:
...
  phex (l, sizeof (l))
...

Make this easier by reimplementing the functions as a template, allowing us to
simply write:
...
  phex (l)
...

Simplify existing code using:
...
$ find gdb* -type f \
    | xargs sed -i 's/phex (\([^,]*\), sizeof (\1))/phex (\1)/'
$ find gdb* -type f \
    | xargs sed -i 's/phex_nz (\([^,]*\), sizeof (\1))/phex_nz (\1)/'
...
and manually review:
...
$ find gdb* -type f | xargs grep "phex (.*, sizeof.*)"
$ find gdb* -type f | xargs grep "phex_nz (.*, sizeof.*)"
...

Tested on x86_64-linux.

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

Use emoji to indicate errors and warnings

This patch adds, at long last, some emoji output to gdb.  In
particular, warnings are indicated with the U+26A0 (WARNING SIGN), and
errors with U+274C (CROSS MARK).

There is a new setting to control whether emoji output can be used.
It defaults to "auto", which means emoji will be used if the host
charset is UTF-8.  Note that disabling styling will also disable
emoji, handy for traditionalists.

I've refactored mingw console output a little, so that emoji will not
be printed to the console.  Note the previous code here was a bit
strange in that it assumed that the first use of gdb_console_fputs
would be to stdout.

This version lets the user control the prefixes directly, so different
emoji can be chosen if desired.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Keith Seitz <keiths@redhat.com>
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

readline/tcap.h: Update definitions for C23

C23 changes how function definitions like int `int tputs ()` are
interpreted. In older standards this meant that the function arguments
are unknown. In C23 this is interpreted as `int tputs (void)` so now
when we compile with GCC15 (which defaults to -std=gnu23) we get an
error such as

  readline/display.c:2839:17: error: too many arguments to function 'tputs'; expected 0, have 3

Add the function arguments for tgetent(), tgetflag(), tgetnum(),
tgetstr(), tputs() and tgoto().

Signed-off-by: Chris Packham <judge.packham@gmail.com>
Approved-By: Tom Tromey <tom@tromey.com>

[gdb/testsuite] Fix gdb.reverse/time-reverse.exp timeout

After building gdb with "-O0 -g -fsanitize=thread" on aarch64-linux, with
test-case gdb.reverse/time-reverse.exp I run into:
...
(gdb) continue^M
Continuing.^M
FAIL: $exp: mode=c: continue to breakpoint: marker2 (timeout)
...

The problem is that instruction stepping gets stuck in a loop with this call
stack: time -> __GI___clock_gettime -> __kernel_clock_gettime ->
__cvdso_clock_gettime.

This is not specific to fsanitize=thread, it just makes gdb slow, which makes
instruction stepping slow, which results in the application getting stuck.

I ran into this as well with a regular gdb build on a 32-bit i686 laptop with
1GB of memory, an inherently slow setup.  In that instance, I was able to
observe that the loop we're stuck in is the outer loop in do_coarse in linux
kernel source lib/vdso/gettimeofday.c.

Fix this by setting "record full insn-number-max" to 2000, and handling
running into the limit.

Initially I tried the approach of using "stepi 2000" instead of continue, but
that made the issue more likely to show up (for instance, I observed it after
building gdb with -O0 on aarch64-linux).

Tested on aarch64-linux.

Approved-By: Guinevere Larsen <guinevere@redhat.com>
PR testsuite/32678
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32678

[gdb/testsuite] Make gdb.reverse/time-reverse.exp more robust

I noticed that test-case gdb.reverse/time-reverse.exp contains:
...
    if [supports_process_record] {
        # Activate process record/replay
        gdb_test_no_output "record" "turn on process record"
...

So I tried out forcing supports_process_record to 0, and got:
...
FAIL: gdb.reverse/time-reverse.exp: mode=syscall: info record
FAIL: gdb.reverse/time-reverse.exp: mode=syscall: reverse to marker1
FAIL: gdb.reverse/time-reverse.exp: mode=syscall: check time record
FAIL: gdb.reverse/time-reverse.exp: mode=c: info record
FAIL: gdb.reverse/time-reverse.exp: mode=c: reverse to marker1
FAIL: gdb.reverse/time-reverse.exp: mode=c: check time record
...

Fix this by requiring supports_process_record alongside supports_reverse.

I also noticed when running make-check-all.sh that there were a lot of failures
with target board dwarf5-fission-debug-types.

Fix this by not ignoring the result of "runto marker1".

Then I noticed that $srcfile is used as a regexp.  Fix this by applying
string_to_regexp.

Tested on x86_64-linux.

Approved-By: Guinevere Larsen <guinevere@redhat.com>

Minor changes to Ada tests for gnat-llvm

I found a few more spots where a minor modification to a test lets it
pass with gnat-llvm:

* For array_subcript_addr, gnat-llvm was not putting the array into
  memory.  Making the array larger works around this.

* For bp_inlined_func, it is normal for gnat-llvm to sometimes emit a
  call to an out-of-line copy of the function, so accept this.

* For null_overload and type-tick-size, I've applied the usual fix for
  keeping an unused local variable alive.

[gdb/testsuite] Make gdb.threads/inf-thr-count.exp more readable

While investigating a timeout in gdb.threads/inf-thr-count.exp I noticed that
it uses quite some escaping, resulting in hard-to-parse regexps like
"\\\$$::decimal".

Fix this by reducing the escaping using:
- quoting strings using {} instead of "", and
- string_to_regexp.

Also use multi_line to split up long multi-line regexps.

Tested on x86_64-linux.

[gdb/testsuite] Fix timeout in gdb.threads/inf-thr-count.exp

With test-case gdb.threads/inf-thr-count.exp, check-readmore and
READMORE_SLEEP=1000 I run into:
...
(gdb) set variable spin = 0^M
(gdb) ^M
Thread 1 "inf-thr-count" hit Breakpoint 2, breakpt () at /data/vries/gdb/src/gdb/testsuite/gdb.threads/inf-thr-count.c:49^M
49      }^M
FAIL: gdb.threads/inf-thr-count.exp: set 'spin' flag to allow main thread to exit (timeout)
PASS: gdb.threads/inf-thr-count.exp: wait for main thread to stop
...

Fix this by using -no-prompt-anchor.

Tested on x86_64-linux.

aarch64: drop stray newlines

as_bad() already emits a newline; having extra ones leads to somewhat
distorted diagnostics.

arm: drop stray newlines

Both as_bad() and as_warn() already emit a newline; having extra ones
leads to somewhat distorted diagnostics.

COFF: correct function auxiliary symbol data clearing

It's unclear why the array part of the union was used there, when we're
dealing with a function. Originally, when 32-bit hosts and targets were
prevailing, the memset() in question ended up clearing the entire x_fcn,
while for 64-bit hosts/targets only x_lnnoptr would have been cleared.
Then a2c7ca15a560 ("Use stdint types in coff internal_auxent") made
things consistent, but imo in the wrong direction (and likely
unintentionally). Go back to what apparently was meant originally, using
the correct part of the union now.

COFF: function auxiliary symbols

For one at least x86 gcc emits .def/.endef for functions, but no 2nd
pair to designate their ends (sizes). While we can't recover the sizes,
we can at least properly establish the chain of function symbols, which
of course requires to emit auxiliary symbols for every function symbol
even when there's no C_EFCN: We simply shouldn't be making their
insertion conditional upon there not being a function processing of
which is "in progress".

In fact it was wrong to assign dual purpose to {,next_}set_end:
Functions don't have "ends" set, but links to the next one. The same
symbol table entry can serve both as an end marker and be a part of the
chain of (defined) functions; this can't be expressed by a single static
variable. Use what (again) becomes last_functionP for this purpose,
along with tracking what symbol C_EFCN should apply to.

This then allows to undo exposing of the respective (supposedly static)
tracking variable, which PPC's XCOFF handling had introduced. Also
rename it back to what it was before its exposure.

For now the new testcases are XFAIL for Arm64 since there, unlike for
Arm32, mapping symbols are emitted for COFF, too.

gas: add new COFF-specific subdir in testsuite

... and move the cofftag testcase there (from all/). Just like we have
one for ELF.

Arm/COFF: accept .def outside of CCS mode

There's no reason to reject this common COFF directive when it doesn't
have any other meaning.

Automatic date update in version.in

asan: null pointer as arg 2 of memcpy

Replace xmalloc+memcpy+free with xrealloc, avoiding the asan warning
on the initial allocation where we had memcpy(p,0,0).

* cg_arcs.c (arc_add): Use xrealloc.

dwarf: Properly check holes in .debug_ranges/debug_rnglists

Don't warn if the offset of the first entry in .debug_rnglists starts
right after the header.  Warn holes in .debug_ranges and debug_rnglists
sections only if the last end pointer isn't the same as the current
start pointer.

PR binutils/32927
* dwarf.c (display_debug_ranges_list): Return the pointer to the
end.
(display_debug_ranges): Don't warn if the offset of the first
entry in .debug_rnglists starts right after the header.  Warn a
hole only if the last end pointer is the same as the next pointer.
* testsuite/binutils-all/x86-64/dwarf4.s: New file.
* testsuite/binutils-all/x86-64/dwarf5.s: Likewise.
* testsuite/binutils-all/x86-64/pr32927-1.d: Likewise.
* testsuite/binutils-all/x86-64/pr32927-2.d: Likewise.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Co-Authored-By: Alan Modra <amodra@gmail.com>

Automatic date update in version.in

gdb/progspace: fix formatting issue

The previous commit had a small styling issue that I forgot to fix
before pushing. This commit fixes the styling issue.