Regularize spelling of names of keys

This changes gdb to use <KEY> when referring to the name of a key that
the user should press -- basically for return and tab.

In one spot, an obsolete use of <return> is removed.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-by: Kevin Buettner <kevinb@redhat.com>

Use upper case for "metasyntactic variables"

GNU typically uses all upper-case to refer to user-supplied text, as
opposed to the other common convention of angle brackets.

This patch fixes the cases of the latter that I found in help and
error text.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-by: Kevin Buettner <kevinb@redhat.com>

Automatic date update in version.in

Convert dw2-case-insensitive.exp to DWARF assembler

I used contrib/dwarf-to-dwarf-assembler.py to convert
dw2-case-insensitive.exp to use the DWARF assembler.  The output
needed some minor changes to fully work, but not really all that much.
The .c file also needed a small change, and I went ahead and removed
other extraneous code.

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

Remove "readnow" from two tests

These tests both claim that -readnow is needed for proper operation,
but (1) this isn't true, and (2) if it were true it would be a bug in
gdb.  So, remove the use of readnow.

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

[gdb/testsuite] Use valnum_re more often (part 4)

Grepping through the testsuite I also found:
- "\\$\[0-9\]\+"
- "\\$\[0-9\]\*"
- "\\$\[0-9\]".

Also replace these with valnum_re.

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

[gdb/testsuite] Use valnum_re more often (part 3)

Also transform '\\\$\[0-9\].*' into valnum_re, assuming that '\\\$\[0-9\]+' was
meant.

Done using these commands to cover '\\\$' vs '\\$' and '\[0-9\]' vs '\[0-9]':
...
find gdb/testsuite/ -type f -name *.exp* \
    | xargs sed -i 's/\\\\\\$\\\[0-9\\\]\.\*/${::valnum_re}/g'
find gdb/testsuite/ -type f -name *.exp* \
    | xargs sed -i 's/\\\\\\$\\\[0-9\]\.\*/${::valnum_re}/g'
find gdb/testsuite/ -type f -name *.exp* \
    | xargs sed -i 's/\\\\$\\\[0-9\\\]\.\*/${::valnum_re}/g'
find gdb/testsuite/ -type f -name *.exp* \
    | xargs sed -i 's/\\\\$\\\[0-9\]\.\*/${::valnum_re}/g'
...

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

[gdb/testsuite] Use valnum_re more often (part 2)

Also transform '\\\$\[0-9\]*' into valnum_re, assuming that '\\\$\[0-9\]+' was
meant.

Done using these commands to cover '\\\$' vs '\\$' and '\[0-9\]' vs '\[0-9]':
...
$ find gdb/testsuite/ -type f -name *.exp* \
    | xargs sed -i 's/\\\\\\$\\\[0-9\\\]\*/${::valnum_re}/g'
$ find gdb/testsuite/ -type f -name *.exp* \
    | xargs sed -i 's/\\\\\\$\\\[0-9\]\*/${::valnum_re}/g'
$ find gdb/testsuite/ -type f -name *.exp* \
    | xargs sed -i 's/\\\\$\\\[0-9\\\]\*/${::valnum_re}/g'
$ find gdb/testsuite/ -type f -name *.exp* \
    | xargs sed -i 's/\\\\$\\\[0-9\]\*/${::valnum_re}/g'
...

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

[gdb/testsuite] Use valnum_re more often (part 1)

Use valnum_re more often.  Do this by replacing "\\\$\[0-9\]+" and similar.

I ran these commands handling 6 variants of $decimal:
...
$ find gdb/testsuite/ -type f -name *.exp* \
    | xargs sed -i 's/\\\\\\$\\\[0-9\\\]+/${::valnum_re}/g
$ find gdb/testsuite/ -type f -name *.exp* \
    | xargs sed -i 's/\\\\\\$\\\[0-9\]+/${::valnum_re}/g'
$ find gdb/testsuite/ -type f -name *.exp* \
    | xargs sed -i 's/\\\\\\$$decimal/${::valnum_re}/g'
$ find gdb/testsuite/ -type f -name *.exp* \
    | xargs sed -i 's/\\\\\\$$::decimal/${::valnum_re}/g'
$ find gdb/testsuite/ -type f -name *.exp* \
    | xargs sed -i 's/\\\\\\$${decimal}/${::valnum_re}/g'
$ find gdb/testsuite/ -type f -name *.exp* \
    | xargs sed -i 's/\\\\\\$${::decimal}/${::valnum_re}/g'
...
and then once more matching '\\$' instead of '\\\$'.

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

[gdb/testsuite] Remove superfluous definition of valnum_re in gdb.base/commands.exp

Regexp valnum_re is defined in lib/gdb.exp.

Remove the superfluous definition of valnum_re in gdb.base/commands.exp.

While we're at it, redefine valnum_re using subst_vars to reduce escaping.

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

gdb/testsuite: disable progress bars for new debuginfod test

The recently added gdb.debuginfod/solib-with-dwz.exp test script
wasn't disabling progress bars.  This makes the gdb.log harder to
read.  Add the line to turn progress bars like we do in all the other
debuginfod tests.

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

[gdb/testsuite] Fix pi approximation

In gdb.dap/ada-non-ascii/prog.adb, I came across the following:
...
   π : Integer := 3;            --  The Indiana Approximation.
...

This article [1] explains the background behind the comment: the Indiana pi
bill.

Given that the common interpretation seems to be that the bill implies that
π == 3.2 [2]:
...
The bill ... has been claimed to imply a number of different values for π,
although the closest it comes to explicitly asserting one is the wording "the
ratio of the diameter and circumference is as five-fourths to four", which
would make π = 16⁄5 = 3.2, ... .
...
change the type to float, and set it to 3.2.

Luckily, in this particular case, changing the approximation of π has no
effect, so the test-case still passes :) .

Tested on x86_64-linux.

Approved-by: Kevin Buettner <kevinb@redhat.com>
[1] https://en.wikipedia.org/wiki/Indiana_pi_bill
[2] https://en.wikipedia.org/wiki/Approximations_of_pi#Indiana_bill

gdb/dwarf: turn some errors into asserts

There are some nullptr checks on the return value of load_cu that I
think can't possibly ever be true.  load_cu returns nullptr only if the
CU is "dummy".  A "dummy" CU is one that has a header but no DIE.  The
body (the part after the header, included in the unit reported by the
header) is either empty or consists only of zeroes (null entries).

In the various spots I modified we are doing some work (e.g. evaluating an
expression) in the context of PER_CU, so PER_CU can't possibly be empty
/ dummy.

Change those conditions to asserts.  No behavior change expected, unless
my reasoning is incorrect.

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

gdb: tighten assertions in set_type_vptr_*

In C++, only structures and classes (represented by TYPE_CODE_STRUCT)
can participate in inheritance.  I therefore think it does not make
sense to allow for TYPE_CODE_UNION in set_type_vptr_basetype and
set_type_vptr_fieldno.  Remove the possibility for the type to be a
union in these functions.

Also, for the same reason, add an assertion that checks the type of
basetype in set_type_vptr_basetype.

I did not change the getters (internal_type_vptr_fieldno and
internal_type_vptr_basetype), because it seems like they are called by
code that handles similarly both structures and unions.  Making those
stricter would require adding conditions in those callers, which doesn't
look like an improvement.  For unions, they will correctly return an
"invalid" value.

Change allocate_cplus_struct_type to not use set_type_vptr_fieldno to
initialize the field to -1, otherwise it would trip the assertion when
initializing for a union type.

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

[gdb/doc] Use '@:' after abbreviation

In gdb/doc/gdb.texinfo, we have:
...
For every type there is also a default kind associated with it, e.g.@
@code{Integer} in @value{GDBN} will internally be an @code{Integer*4} (see the
table below for default types).
...

While the @NL command [1] does probably prevent the sentence ending at 'e.g.',
the usual way to accomplish this is to use '@:' [2], so use that instead.

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

Approved-By: Eli Zaretskii <eliz@gnu.org>
[1] https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Multiple-Spaces.html
[2] https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Not-Ending-a-Sentence.html

gdb: fix gdb.base/inline-frame-cycle-unwind.exp for s390x

With test-case gdb.base/inline-frame-cycle-unwind.exp on s390x-linux, I run
into:

  ...
  (gdb) bt
   #0  inline_func () at inline-frame-cycle-unwind.c:49
   #1  normal_func () at inline-frame-cycle-unwind.c:32
   #2  0x000000000100065c in inline_func () at inline-frame-cycle-unwind.c:45
   #3  normal_func () at inline-frame-cycle-unwind.c:32
   Backtrace stopped: previous frame identical to this frame (corrupt stack?)
  (gdb) FAIL: $exp: bt: cycle at level 5: backtrace when the unwind is broken \
    at frame 5
  ...

In contrast, on x86_64-linux, I get:

  ...
  (gdb) bt
   #0  inline_func () at inline-frame-cycle-unwind.c:49
   #1  normal_func () at inline-frame-cycle-unwind.c:32
   #2  0x0000000000401157 in inline_func () at inline-frame-cycle-unwind.c:45
   #3  normal_func () at inline-frame-cycle-unwind.c:32
   #4  0x0000000000401157 in inline_func () at inline-frame-cycle-unwind.c:45
   #5  normal_func () at inline-frame-cycle-unwind.c:32
   Backtrace stopped: previous frame identical to this frame (corrupt stack?)
  (gdb) PASS: $exp: bt: cycle at level 5: backtrace when the unwind is broken \
    at frame 5
  ...

To understand what's going wrong here, we first need to understand
what this test was trying to do.

The test tries to create a frame-cycle using a custom Python
unwinder.  A frame-cycle occurs when a frame in the backtrace has the
same frame-id as an earlier frame.  As soon as GDB finds a frame with
a frame-id that it has seen before then the backtrace will be
terminated with the message:

   Backtrace stopped: previous frame identical to this frame (corrupt stack?)

A Python frame unwinder does two jobs:

  - It provides the frame-id for a frame #n, and

  - it provides the unwound register values for the previous (#n + 1)
    frame.

For a frame not claimed by a Python frame unwinder, GDB will compute
the frame-id based off of the register values.  Particularly, the $pc
and $sp, or $fp registers (or the architecture's equivalent).

In this test then, our frame unwinder does something a little
strange.  When we want to stop at frame #5, the frame unwinder claims
frame #5.  The frame unwinder then tries to give frame #5 its "normal"
frame-id, but, instead of unwinding the register values, we provide
frame #6 with all of the register values from frame #5 unmodified.

The frame unwinder does not claim frame #6, instead GDB uses its
"normal" logic to compute the frame-id.  As the registers in frame #6
are identical to the values in frame #5, GDB computes the same
frame-id for frame #6 as we supplied for frame #5, and thus a frame
cycle is created.

Notice I said that we try to give frame #5 its "normal" frame-id.

When this test was originally written there was no easy way to access
the frame-id for a frame.  So instead, the test was written to try and
recreate the frame-id based on the frame stack pointers, and the frame
size (difference between subsequent frames).  And this worked fine for
a bunch of common architectures, like x86-64 and AArch64.

But unfortunately this frame-id computation doesn't work on s390.

For this explanation we only care about two parts of the frame-id, the
code address, and the stack address.  The code address part is usually
the start of the function for a particular frame.  Our computation of
this was fine.

The stack address in the frame-id isn't the actual $sp value.
Instead, this is usually the Call Frame Address (CFA) as defined in
the DWARF.  How this is calculated really depends on the DWARF, but is
often influenced by the architectures ABI.

On x86-64 and AArch64 the CFA is usually the $sp immediately on entry
to a frame, before any stack adjustment is performed.  Thus, if we
take the frame size (difference between $sp in two frames), and add
this to the current $sp value, we successfully calculate the CFA,
which we can use in the frame-id.

On s390 though, this is not the case, the calculation of the CFA is
more complex as the s390 ABI requires that caller frames allocate a
160 byte Register Save Area below the stack pointer.  Because of this,
when the Python unwinder ties to calculate the real frame-id for a
frame, it gets the CFA wrong, and inadvertently ends up calculating a
frame-id which matches an earlier frame-id.  In the example above,
frame #5 ends up matching frame #3.  Because frame #4 is an inline
frame GDB ends up terminating the backtrace after frame #3.

The fix for this is actually pretty simple.  Since this test was
originally written GDB has gained the 'maint print frame-id' command.
So instead of trying to calculate the frame-id we can just capture the
frame-ids that GDB generates, and then, once the Python frame unwinder
is in use, we can repeat the previously captured frame-id back to
GDB.

This fixes the issues seen on s390, and doesn't impact testing on the
other architectures.

Tested on x86_64-linux and s390x-linux.

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

Automatic date update in version.in

gdb/dwarf: make abbrev_table_cache read-through, make it mandatory

This patch implements some performance improvements initially sent as
part of this series [1], but now as a single patch.  There was some push
back from Tom regarding the increased memory usage, but I think that my
solution is still desirable: it makes the code simpler, and I think that
the memory usage it not an issue (the usage is transient and the amount
of memory used by the abbrev tables is relatively low).

As a reminder, here is the problem I'm looking to solve: when using
split DWARF (.dwo files) plus type units, all units inside a .dwo file
(generally one compile unit plus many type units) share the same abbrev
table.  So we end up re-reading that same abbrev tables many times, and
its gets very noticeable in function process_skeletonless_type_units.

cooked_index_worker_debug_info::process_type_units does some work to
avoid this problem, but it only works when everything is in the main
file (not using split DWARF).

Right now, we cache abbrev tables only in specific cases during
indexing, like when one CU imports things from another CU.  My previous
series changed cutu_reader so that it would add any abbrev table it
would read to the abbrev table cache (if it was passed one as a
parameter).  This allowed using a cache in
process_skeletonless_type_units and cut the time down significantly.

This patch goes a bit further in order to simplify cutu_reader even
further:

 - It makes the abbrev table cache read-through, meaning that when you
   request an abbrev table and it's not in the cache, it will go read
   it (and cache it).

 - It makes passing an abbrev table cache to the constructors mandatory
   (even when we wouldn't benefit from using a cache).

The result is that cutu_reader doesn't need to manage multiple cases of
how to obtain an abbrev table, and it doesn't need to manage adding
abbrev tables to the cache.  It no longer needs to manage the ownership
of the abbrev tables either: the abbrev tables are always owned by the
cache.  And the cases of abbrev table sharing are well handled
transparently.

This means that we pay a small price when we don't necessarily need to
(sometimes building and destroying an abbrev_table_cache for just one
cutu_reader), but I think that this price is not significant and the
code simplification is welcome.

In concrete terms, this patch:

 - changes abbrev_table_cache::find to become abbrev_table_cache::get,
   making it read-through
 - removes abbrev_table_cache::add
 - removes the abbrev_table parameter from the main cutu_reader
   constructor
 - makes the abbrev_table_cache parameter mandatory (a reference) in the
   main cutu_reader constructor, adds it to the alternative constructor,
   and passes it down to a few methods
 - adjusts the cutu_reader code obtaining an abbrev table to just call
   abbrev_table_cache::get
 - adjusts all the cutu_reader users to pass an abbrev_table_cache (if
   not already)
 - removes the code in
   cooked_index_worker_debug_info::process_type_units meant to
   efficiently handle TUs that share abbrev tables - the cache now does
   this

The specific split DWARF + type units performance problem at the origin
of this work gets fixed by the fact that
cooked_index_worker_debug_info::process_skeletonless_type_unit now
passes an abbrev table cache to cutu_reader, and
cutu_reader::read_cutu_die_from_dwo uses it.

As a test, I'm using a build of Blender compiled with -gsplit-dwarf and
-fdebug-types-section.  I run this:

    $ ./gdb -nx -q --data-directory=data-directory -ex 'maint set dwarf sync on' -ex 'maintenance set per-command time on' -ex "file /data1/smarchi/blender-build/relwithdebinfo-clang-debugtypes-splitdwarf/bin/blender" -batch

and look at the time taken by the "DWARF skeletonless type units"
step.  Before looks like:

    Time for "DWARF skeletonless type units": wall 11.131, user 10.699, sys 0.431, user+sys 11.130, 100.0 % CPU

and after looks like:

    Time for "DWARF skeletonless type units": wall 1.751, user 1.221, sys 0.518, user+sys 1.739, 99.3 % CPU

The total run time (wall clock time) of the command goes from about 18.5
seconds to about 9.5 seconds.

I removed this assert in cutu_reader, because it relies on abbrev_cache
as a flag for whether we're in the indexer:

      /* If an existing_cu is provided, a dwarf2_cu must not exist for
 this_cu in per_objfile yet.  Here, CACHE doubles as a flag to
 let us know that the CU is being scanned using the parallel
 indexer.  This assert is avoided in this case because (1) it
 is irrelevant, and (2) the get_cu method is not
 thread-safe.  */
      gdb_assert (abbrev_cache != nullptr
  || per_objfile.get_cu (&this_cu) == nullptr);

It's not clear to me if this assert is important or how to implement it
differently.

[1] https://inbox.sourceware.org/gdb-patches/20250326200002.136200-4-simon.marchi@efficios.com/

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

Automatic date update in version.in

Rewrite Fortran character printer

This adds a Fortran-specific subclass of wchar_printer and arranges to
use it.

Rewrite Pascal character printer

This adds a Pascal-specific subclass of wchar_printer and arranges to
use it.

Rewrite Modula-2 character printer

This adds a Modula-2-specific subclass of wchar_printer and arranges
to use it.

Rewrite Ada character printer

This adds a Ada-specific subclass of wchar_printer and arranges to
use it.

Rewrite Rust character printer

This adds a Rust-specific subclass of wchar_printer and arranges to
use it.

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

Move wchar_printer implementation to a new file

This introduces a new char-print.c file and moves the wchar_printer
implementation code there.

Introduce character-printing class

This patch introduces a new class for printing character and string
literals by rewriting some code in valprint.  The new class is
designed to be subclassed to provide language-specific character
printing.

Change generic_emit_char to print the quotes

All callers of generic_emit_char print the quotes around the
character, then pass the quote character to the function.  It seemed
better to just have generic_emit_char print the quotes itself.

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

Remove language_defn::emitchar

Nothing outside of the specific language implementations ever calls
language_defn::emitchar.  This patch removes this method and updates
the rest of the code.  In some spots, the method is entirely removed;
in others, just the 'override' is removed.

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

Add quotemeta to gdb test suite

AdaCore has an internal test suite written in Python.  One nice
facility it has is called "quotemeta", and it is an alternative to
using regular expressions to match gdb output.

This patch adds a similar library, written in Tcl, to the gdb test
suite.  The idea here is to simplify certain kinds of checks and to
avoid the painful combination of both Tcl and regexp quoting.

There is a comment in the code that explains quotemeta in detail.  If
you've used the AdaCore test suite, note that this implementation has
some extensions, namely the @{...} forms.  (I do wonder here if <...>
would be a better choice, to avoid Tcl issues with braces.)

I've converted part of a Rust test case to demonstrate the effect.
The most dramatic example is this change:

-gdb_test "print g" " = \\(\\*mut \\\[u8; 6\\\]\\) $hex b\"hi bob\""
+gdb_test "print g" [quotemeta {$@DECIMAL = (*mut [u8; 6]) @HEX b"hi bob"}]

At least for me the latter is much easier to understand; and also it
doesn't cheat on the history part of the output, because it's less
painful to do this properly now.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33551
Reviewed-By: Tom de Vries <tdevries@suse.de>

gdb/dwarf: merge dwarf2_locate_v{2,5}_dwp_sections

I found this other path where we could merge the DWP v2 and DWP v5
handling.

Change-Id: Ie7a9fd70a2490dfb43a3557d208ccf07f59eea0f

PR 33629 Fix comment typo in last commit

PR 33629 ldscripts symlink in .libs/ created too late

* Makefile.am (check-DEJAGNU): Move creation of symlink..
(ld-new$(EXEEXT)): ..to here.  New rule.
* Makefile.in: Regenerate.

Automatic date update in version.in

[gdb/testsuite] Simplify gdb.base/limited-length.exp

Simplify gdb.base/limited-length.exp in the same style as commit 8e76232294b
("[gdb/testsuite] Simplify gdb.ada/limited-length.exp").

Tested on x86_64-linux.

[gdb/testsuite] Simplify gdb.ada/limited-length.exp

Simplify gdb.ada/limited-length.exp using the usual tools:
- factoring out repetition
- {} instead of ""
- string_to_regexp

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

readelf vs. mapping symbols

This reverts commit 45cf0b829303, which isn't needed after commit
6d7e5bcca5.   Mapping symbols are like any other local symbol, and
shouldn't appear after the end of a section.

The real bug that resulted in both of these commits is that st_value
in an executable or shared library is the symbol address.  It was
wrong to compare an address against a section size (you'd need to
subtract off the section vma first).  The second commit limited the
warning to ET_REL where st_value is a section offset and thus can be
compared directly to the section size.

doc: sframe: restore DRAFT marker for all outputs

Now that the 2.46 branch is created, restore DRAFT markers for the
development master branch.

libsframe/doc/
* sframe-spec.texi: restore DRAFT marker for all outputs.

sframe: Add tests for PR ld/32769

Add simple tests that verify the behavior of garbage collection of
SFrame sections during linking.

x86_64-specific tests:
  - sframe-gc-sections-1.d checks that none of the functions get
    discarded with --gc-sections
  - sframe-gc-sections-2a.d checks the behavior of --gc-sections with two
    distinct .text.* sections (similar to -ffunction-sections compiler
    option)
  - sframe-gc-sections-2b.d checks the same behaviour as
    sframe-gc-sections-2a.d, but with a linker script that discards
    .eh_frame sections.  This testcase is keep it ensured that the two
    section's GC behaviours are not unnecessarily inter-twined.

All targets supporting sframe tests:
   - pr32769.rd simple linking test in presence of --gc-sections
     option.
   - pr32769-2.d checks the behavior of --gc-sections with two .text.*
     sections, one section is discarded
   - pr32769-2r.d Like the above, but using -r option when linking and
     checking for the relocations.
   - pr32769-3.d checks the behavior of --gc-sections with multiple
     sections, none is drop.

ld/
PR ld/32769
* testsuite/ld-sframe/pr32769.rd: New file.
* testsuite/ld-sframe/pr32769.s: Likewise.
* testsuite/ld-sframe/pr32769-2.d: Likewise.
* testsuite/ld-sframe/pr32769-2r.d: Likewise.
* testsuite/ld-sframe/pr32769-2.s: Likewise.
* testsuite/ld-sframe/pr32769-3.d: Likewise.
* testsuite/ld-sframe/pr32769-3.s: Likewise.
* testsuite/ld-sframe/sframe.exp: Add pr32769 test.
* testsuite/ld-x86-64/sframe-baz.s: New file.
* testsuite/ld-x86-64/sframe-gc-sections-1.d: Likewise.
* testsuite/ld-x86-64/sframe-gc-sections-2.s: Likewise.
* testsuite/ld-x86-64/sframe-gc-sections-2a.d: Likewise.
* testsuite/ld-x86-64/sframe-gc-sections-2b.d: Likewise.
* testsuite/ld-x86-64/sframe-gc-sections-2b.t: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Add new sframe gc tests.

Co-authored-by: Indu Bhagat <indu.bhagat@oracle.com>
Signed-off-by: Claudiu Zissulescu <claudiu.zissulescu-ianculescu@oracle.com>

ld: bfd: sframe: KEEP .sframe sections and support gc-sections

Fix PR ld/32769

Currently, specifying --gc-sections causes the linker to discard all
input .sframe sections.  Fix this behaviour by adding KEEP for .sframe
sections, like it is being done for .eh_frame sections, in the default
ELF linker script.

Additionally, add logic in the linker to gc mark .sframe sections.
_bfd_elf_gc_mark () now is aware of SFrame sections. It relies on
elf_section_sframe () to get the SFrame section associated with the
text section.

Also, the _bfd_elf_parse_sframe is changed to return TRUE when the
input sframe section is already parsed. It fixes calling
_bfd_elf_discard_section_sframe function in bfd_elf_discard_info,
enabling correct behavior for discarding unneeded sframe sections.

ld/
PR ld/32769
* scripttempl/elf.sc: KEEP .sframe sections.
bfd/
* elf-bfd.h (struct elf_obj_tdata): Add sframe section pointer.
(elf_sframe_section): New macro.
* elflink.c (_bfd_elf_gc_mark): Handle SFrame sections.
(bfd_elf_gc_sections): Likewise.
(bfd_elf_discard_info): Update for handling gc operations.
* elf-sframe.c (_bfd_elf_parse_sframe): Return TRUE for already
parsed sframe sections.

Co-authored-by: Indu Bhagat <indu.bhagat@oracle.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Claudiu Zissulescu <claudiu.zissulescu-ianculescu@oracle.com>

include: libsframe: rename SFrame V3 Flexible FDE macros to CTRLWORD

The existing SFrame V3 macros for Flexible FDEs used the term 'OFFSET'
to refer to the data word encoding control/register data word. This can
be confusing, as the control data word (register ID, dereference flags)
is distinct from a stack offset.

This patch renames these macros to use 'CTRLWORD' to better reflect
their purpose. It also updates the assembler and libsframe dumper to
use the new nomenclature.

No functional change.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>
gas/
* gen-sframe.c (sframe_get_fre_dataword_size): Use
SFRAME_V3_FLEX_FDE_CTRLWORD_ENCODE.
(output_sframe_row_entry_datawords): Likewise.
include/
* sframe.h (SFRAME_V3_FLEX_FDE_REG_ENCODE): Rename from ..
(SFRAME_V3_FLEX_FDE_CTRLWORD_ENCODE): .. to.
(SFRAME_V3_FLEX_FDE_CTRLWORD_REGNUM): Rename from
SFRAME_V3_FLEX_FDE_OFFSET_REG_NUM to this.
(SFRAME_V3_FLEX_FDE_CTRLWORD_DEREF_P): Rename from
SFRAME_V3_FLEX_FDE_OFFSET_REG_DEREF_P to this.
(SFRAME_V3_FLEX_FDE_CTRLWORD_REG_P): Rename from
SFRAME_V3_FLEX_FDE_OFFSET_REG_P to this.
(SFRAME_V3_FRE_RA_UNDEFINED_P): Add new V3 macro.
libsframe/
* sframe-dump.c (dump_sframe_func_fres_flex): Update all
callers to use the new CTRLWORD macros.
libsframe/testsuite/
* libsframe.decode/be-flipping-v3.c: Use renamed macros.

Automatic date update in version.in

update gprofng doc/version.texi

regen gprof and gprofng configure

[gdb/python] Fix whitespace in py-ref.h

Fix a whitespace problem pre-commit complains about:
...
check-whitespace........................................................Failed
- hook id: check-whitespace
- exit code: 2

gdb/python/py-ref.h:58: indent with spaces.
+         "The __dict__ for this object.", nullptr },
...

Remove alloca from lookup_cmd

lookup_cmd uses alloca to make a copy of a string, just for an error
message.  However, it's just as easy to use "%.*s" (already used once
in undef_cmd_error) and to pass in a string_view, avoiding the need
for an alloca and a copy.

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

Don't make copies when calling find_cmd

Currently both callers of find_cmd make a temporary string -- one with
std::string and one with the dreaded alloca.

However, as the previous change to find_cmd points out, these copies
are not needed.  Remove them and use a string_view instead.

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

Use string_view in cli-decode.c:find_cmd

This changes cli-decode.c:find_cmd to use std::string_view.  I've made
this a separate patch to make the next patch more obvious.

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

gdb: make remaining Python extension objects inherit from PyObject

Previous patches made some Python extension objects ipublicly inherit
directly or indirectly from PyObject.
In the interest of consistency, this patch makes all remaining Python
extension objects still not inheriting from PyObject do so.

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

gdb: cast all Python extension objects passed to gdbpy_ref_policy to PyObject*

When enabling the Python limited API, pointers to Python C extension
objects can no longer be implicitly converted to 'PyObject *' by the
compiler.

gdbpy_ref_policy is a templated class that provides a generic interface
for incrementing and decrementing the reference counter on the given
object. It is used as a specialisation of the policy parameter in
gdb::ref_ptr, together with PyObject as the parameter type. As a result,
gdbpy_ref_policy always expects an argument derived from PyObject.

This patch fixes the resulting compilation issue by adding an explicit
static_cast to 'PyObject *' before passing the value to Py_INCREF and
Py_DECREF. As a side effect, these casts enforce, at compile time, that
the template type passed to gdbpy_ref_policy is a subclass of PyObject.
To provide a clearer diagnostic when an incorrect type is used, a
static_assert is added to gdbpy_ref_policy, avoiding obscure errors
originating from the static_cast. Finally, all C Python extension types
passed to gdbpy_ref_policy are updated to inherit from PyObject.

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

gdb: new setters and getters for __dict__, and attributes

GDB is currently using the Python unlimited API. Migrating the codebase
to the Python limited API would have for benefit to make a GDB build
artifacts compatible with older and newer versions of Python that they
were built with.

This patch prepares the ground for migrating the existing C extension
types from static types to heap-allocated ones, by removing the
dependency on tp_dictoffset, which is unavailable when using the limited
API.

One of the most common incompatibilities in the current static type
declarations is the tp_dictoffset slot, which specifies the dictionary
offset within the instance structure. Historically, the unlimited
API has provided two approaches to supply a dictionary for __dict__:

 * A managed dictionary.
   Setting Py_TPFLAGS_MANAGED_DICT in tp_flags indicates that the
   instances of the type have a __dict__ attribute, and that the
   dictionary is managed by Python.
   According to the Python documentation, this is the recommended approach.
   However, this flag was introduced in 3.12, together with
   PyObject_VisitManagedDict() and PyObject_ClearManagedDict(), neither
   of which is part of the limited API (at least for now). As a result,
   this recommended approach is not viable in the context of the limited
   API.

 * An instance dictionary, for which the offset in the instance is
   provided via tp_dictoffset.
   According to the Python documentation, this "tp slot" is on the
   deprecation path, and Py_TPFLAGS_MANAGED_DICT should be used instead.
   Given the age of the GDB codebase and the requirement to support older
   Python versions (>= 3.4), no need to argue that today, the implementation
   of __dict__ relies on tp_dictoffset. However, in the context of the
   limited API, PyType_Slot does not provide a Py_tp_dictoffset member, so
   another approach is needed to provide __dict__ to instances of C extension
   types.

Given the constraints of the limited API, the proposed solution consists
in providing a dictionary through a common base class, gdbpy__dict__wrapper.
This helper class owns a dictionary member corresponding to __dict__, and
any C extension type requiring a __dict__ must inherit from it. Since
extension object must also be convertible to PyObject, this wrapper class
publicly inherits from PyObject as well.
Access to the dictionary is provided via a custom getter defined in a
PyGetSetDef, similarily to what was previously done with gdb_py_generic_dict().
Because __dict__ participates in attribute look-up, and since this dictionary
is neither managed by Python nor exposed via tp_dictoffset, custom
implementations of tp_getattro and tp_setattro are required to correctly
redirect attribute look-ups to the dictionary. These custom implementations
— equivalent to PyObject_GenericGetAttr() and PyObject_GenericSetAttr() —
must be installed via tp_getattro / tp_setattro for static types, or
Py_tp_getattro / Py_tp_setattro for heap-allocated types.

- gdbpy__dict__wrapper: a base class for C extension objects that own a
  __dict__.
- gdb_py_generic_dict_getter: a __dict__ getter for extension types
  derived from gdbpy__dict__wrapper.
- gdb_py_generic_getattro: equivalent of PyObject_GenericGetAttr, but
  fixes the look-up of __dict__.
- gdb_py_generic_setattro: equivalent of PyObject_GenericSetAttr, but
  fixes the look-up of __dict__.

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

gdbpy_registry: cast C extension type object to PyObject * before Py_XINCREF

When enabling the Python limited API, pointers to Python C extension
objects can no longer be implicitly converted to 'PyObject *' by the
compiler.

The lookup() method of gbdpy_registry returns a new reference to the
type object of the looked-up entry. It does so by calling Py_XINCREF()
to increment the reference counter of the returned type object. The
template parameter obj_type corresponds to the type of C extension
object type. With the Python limited API enabled, obj_type can no longer
be implicitly converted to 'PyObject *' when passed to Py_XINCREF().

This patch fixes the resulting compilation issue by adding an explicit
static_cast to 'PyObject *' before passing the value to Py_XINCREF().
As a side effect, this cast enforces, at compile time, that the template
type 'Storage::obj_type' passed to gdbpy_registry is a subclass of
PyObject. To provide a clearer diagnostic when an incorrect type is used,
a static_assert is added to gdbpy_registry, avoiding obscure errors
originating from the static_cast. Finally, the relevant C extension types
passed to gdbpy_registry are updated to inherit publicly from PyObject.

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

Update version now that the 2.46 branch has been created

Automatic date update in version.in

PR 33852 Different objects for same input

Testcase:
$ cat aff.s
 .quad x@ntpoff
$ gas/as-new -m64 aff.s -o t.o
with MALLOC_PERTURB_ this reliably shows uninitialised memory making
its way into the output.

R_390_TLS_LE64 howto was sized incorrectly, resulting in the
initialisation in s390_elf_cons zeroing only the first four bytes.

* elf64-s390.c (elf_howto_table <R_390_TLS_LE64>): Correct
size and bitsize.

Python limited API: migrate PyImport_ExtendInittab

This patch replaces PyImport_ExtendInittab () with its limited C
API equivalent, PyImport_AppendInittab (), a convenience wrapper
around PyImport_ExtendInittab ().

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

Python limited API: migrate Py_CompileStringExFlags and PyRun_SimpleString

This patch replaces Py_CompileStringExFlags () with its limited C API
equivalent, Py_CompileString (). The eval_python_command () helper is
now exposed through the private GDB Python API as a utility function.
PyRun_SimpleString () is replaced with eval_python_command () to avoid
code duplication.

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

gas: segmentation fault in as_report_context

After input_scrub_end when next_saved_file is NULL, it is possible
that macro_nest will be non-zero on files with errors.  If
output_file_close then has an error and reports it with as_fatal we
hit the segfault.

PR 33746
* input_scrub.c (as_report_context): Don't assume
next_saved_file is non-NULL.
(as_where): Likewise.

PR 33718 objcopy and strip of Solaris binaries

non-SHF_ALLOC SHT_SUNW_symsort and SHT_SUNW_symnsort sections aren't
removed when all symbols are removed.  Fix that.

PR 33718
PR 33684
* objcopy.c (is_strip_section_1): Handle SHT_SUNW_symsort and
SHT_SUNW_symnsort sections.

Automatic date update in version.in

regen pot files

Re: PR 33840 typo in elfnn-loongarch.c

The second string with the typo was unused (and had unescaped %).
Remove it.

PR 33840 typo in elfnn-loongarch.c

s/marching/matching/

ld: testsuite: Simplify emulation check in libgot tests

The x86 libgot-1 tests are the only ones in all testsuites that use a
new ld -V -m<emul under test> idiom to check whether to run the tests.

Rather than open-coding the check everywhere while relying on that
idiom, this patch introduces a new proc to directly check the ld -V
output for the emulation in question.

Tested on {x86_64,i686}-pc-linux-gnu and {amd64,i386}-pc-solaris2.11.

2026-01-24  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

ld:
* testsuite/lib/ld-lib.exp (ld_supports_emul): New proc.
* testsuite/ld-i386/binutils.exp: Use it.
* testsuite/ld-x86-64/binutils.exp: Likewise.

gdb/python: use gdbpy_is_value_object in more places

Make more use of gdbpy_is_value_object in python/py-value.c

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

[bfd] Fix data race in bfd_check_format_matches

At the start of bfd_check_format_matches, we have this read of_bfd_section_id:
...
  unsigned int initial_section_id = _bfd_section_id;
...

In order to access the variable, it is required to hold the global BFD lock.

The function already contains code acquiring the lock:
...
  /* Locking is required here in order to manage _bfd_section_id.  */
  if (!bfd_lock ())
    {
      bfd_cache_set_uncloseable (abfd, old_in_format_matches, NULL);
      free (matching_vector);
      return false;
    }
...
so fix this by moving the read after it.

Tested on x86_64-linux.

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

Update release readme

sanity check score reloc functions

Some of these already did some sanity checking, but
bfd_reloc_offset_in_range is better since it takes into account the
relocation field size too.

       * elf32-score.c (score_elf_hi16_reloc, score_elf_lo16_reloc),
       (score_elf_gprel15_with_gp, gprel32_with_gp),
       (score_elf_got_lo16_reloc): Use bfd_reloc_offset_in_range to
       sanity check reloc addresses.
       * elf32-score7.c (score_elf_hi16_reloc, score_elf_lo16_reloc),
       (score_elf_gprel15_with_gp, gprel32_with_gp),
       (score_elf_got_lo16_reloc): Likewise.

gdb/testsuite: remove guile "test byte at sp, before flush" test

When I run:

    $ while make check TESTS="gdb.guile/scm-ports.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"; do done

I eventually get:

    FAIL: gdb.guile/scm-ports.exp: buffered=1: test byte at sp, before flush

I don't know why I only see this (or see this more often) with the
native-extended-gdbserver board, I guess because it changes the timing
of things.  Also, this is with a debug/ASan/UBSan build of GDB, if that
matters.  This is with guile 3.0.

This is what the test attempts to do:

 1. create a rw memory port that is supposed to be buffered
 2. write the byte at $sp with a new value, expecting that byte to only
    be in the port's buffer
 3. read the memory at $sp (using parse-and-eval, bypassing the rw
    memory port), expecting to see the old byte value
 4. flush the memory port, expecting that to write to new byte value at
    $sp
 5. read the memory at $sp (using parse-and-eval again), expecting to
    see the new value

It is step 3 that fails.  My hypothesis is that even if the memory port
we write to is buffered, the write to the underlying memory can happen
before the "before flush" test happens.  The Guile Buffering doc [1]
says this:

    If you write data to a buffered port, it probably doesn’t go out to
    the mutable store directly. (This “probably” introduces some
    indeterminism in your program: what goes to the store, and when,
    depends on how full the buffer is. It is something that the user
    needs to explicitly be aware of.) The data is written to the store
    later – when the buffer fills up due to another write, or when
    force-output is called, or when close-port is called, or when the
    program exits, or even when the garbage collector runs.

Because of the mention of the garbage collector, I tried putting some
calls to gc-disable and gc-enable around that area, but it doesn't fix
it.

Given that the flushing behavior of the buffered port seems
non-deterministic, I think that the buffering behavior can't easily be
tested.  I propose to get rid of that specific aspect of the test.

As suggested by Tom de Vries, replace the "test byte at sp, before
flush" test with a "test byte at sp, before write" one.  I think this is
useful as a sanity check to help prove that the memory write did in fact
change the state of the program.

Change-Id: I2f0afd7b2ebb7738e675f58397677f2f9a4e06bb
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29825
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

Automatic date update in version.in

gdbserver: Add aarch64-windows support

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

gdbserver: Move software breakpoint recognition code into win32-i386-low.cc

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

gdbserver: Move setting of process_info::tdesc into win32-i386-low.cc

It's arch-specific, and since now win32_tdesc and wow64_win32_tdesc are
only used in this file, they are made static.

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

gdbserver: Update win32_target_ops to new stopped_data_addresses interface

It will be used by the aarch64 port.

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

Minor cleanups in expanded-symbol.[ch]

I found a typo in expanded-symbol.h, then noticed some formatting
mistakes and some other incorrect comments.  This patch fixes all
these and removes some 'struct' keywords as well.

I'm checking this in as obvious.

[gdb/testsuite] Fix gdb.dap/ada-non-ascii.exp for gcc < 10

On openSUSE Leap 15.6, test-case gdb.dap/ada-non-ascii.exp passes with
gcc 10-12.

But with gcc 7-9 I see:
...
{"request_seq": 6, "type": "response", "command": "scopes", "success": true,
"body": {"scopes": [{"variablesReference": 1, "name": "Locals",
"presentationHint": "locals", "expensive": false, "namedVariables": 1,
"line": 22, "source": {"name": "prog.adb", "path":
"/data/vries/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/ada-non-ascii/prog.adb"}},
{"variablesReference": 2, "name": "Registers", "presentationHint": "registers",
"expensive": false, "namedVariables": 61, "line": 22, "source": {"name":
"prog.adb", "path":
"/data/vries/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/ada-non-ascii/prog.adb"}}]},
"seq": 18}
PASS: gdb.dap/ada-non-ascii.exp: get scopes success
PASS: gdb.dap/ada-non-ascii.exp: local scope
PASS: gdb.dap/ada-non-ascii.exp: register scope
FAIL: gdb.dap/ada-non-ascii.exp: correct number of locals
...

This is not dap-specific, also with the CLI I see:
...
$ gdb -q -batch prog -ex "break prog.adb:22" -ex run -ex "info locals"
  ...
<W03a0> = 3
...
vs.:
...
<W03a0> = 3
<W03a6> = 7
...

This corresponds to the debug info, for gcc 9 we have:
...
 <1><1866>: Abbrev Number: 3 (DW_TAG_subprogram)
    <1867>   DW_AT_name        : prog
 <2><1888>: Abbrev Number: 4 (DW_TAG_variable)
    <1889>   DW_AT_name        : W03a0
    <1894>   DW_AT_location    : 2 byte block: 91 6c    (DW_OP_fbreg: -20)
...
and for gcc 10 we have instead:
...
 <1><187d>: Abbrev Number: 3 (DW_TAG_subprogram)
    <187e>   DW_AT_name        : prog
 <2><189f>: Abbrev Number: 4 (DW_TAG_variable)
    <18a0>   DW_AT_name        : W03a0
    <18ab>   DW_AT_location    : 2 byte block: 91 6c    (DW_OP_fbreg: -20)
 <2><18ae>: Abbrev Number: 5 (DW_TAG_constant)
    <18af>   DW_AT_name        : W03a6
    <18ba>   DW_AT_const_value : 7
...

Fix this by allowing 1 local variable for gcc < 10.

Tested on x86_64-linux.

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

gdb: add noexcept to relevant methods of class ref_ptr

This patch aims at improving code readability and maintainability
by adding the 'noexcept' attribute to some constructors and
methods of class 'ref_ptr' to make clear that no exception is
supposed to be raised from them.
As an additional benefit, the compiler doesn't need to generate
the stack unwinding code for those constructors and methods.

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

obj_attr_v2_record: simplify logic when an attribute already exists

Suggested-By: Jan Beulich <jbeulich@suse.com>
Approved-By: Jan Beulich <jbeulich@suse.com>

bfd/ELF: fix BFD library build --enable-shared

The patch series that added support for Object Attributes v2 introduced
regressions when building the BFD library as a shared object.

Incorrect usages of ATTRIBUTE_HIDDEN caused the following link-time errors:

/usr/bin/ld: config/obj-elf-attr.o: in function `obj_attr_v2_record':
obj-elf-attr.c: undefined reference to `bfd_elf_obj_attr_v2_init'
obj-elf-attr.c: undefined reference to `_bfd_obj_attr_v2_find_by_tag'
obj-elf-attr.c: undefined reference to `obj_attr_v2_t_append'
/usr/bin/ld: config/obj-elf-attr.o: in function `obj_attr_v2_subsection_record':
obj-elf-attr.c: undefined reference to `obj_attr_subsection_v2_t_append'
obj-elf-attr.c: undefined reference to `obj_attr_subsection_v2_t_remove'
obj-elf-attr.c: undefined reference to `obj_attr_subsection_v2_t_append'

This patch fixes the symbols visibility so that the BFD library links
correctly when built with --enable-shared.
The ATTRIBUTE_HIDDEN annotations were removed from bfd_elf_obj_attr_v2_init
and _bfd_obj_attr_v2_find_by_tag, and _bfd_obj_attr_v2_find_by_tag was renamed
to reflect the belonging to the public BFD API using the 'bfd_' prefix. The
doubly linked list helpers remain hidden and are instead exposed through wrapper
functions.

binutils: xfail "gnu-debuglink (objdump 1)" on Solaris/amd64 [PR33243,PR33389]

As reported in PR binutils/33243, one test FAILs on Solaris/amd64:

FAIL: gnu-debuglink (objdump 1)

30c30,32
<   400660:     ff 35 b2 15 00 00 ff 25 b4 15 00 00 0f 1f 40 00     .5.....%......@.
---
>   400660:     ff 35 b2 15 00 00       push   0x15b2(%rip)        # 401c18 <_GLOBAL_OFFSET_TABLE_+0x8>
>   400666:     ff 25 b4 15 00 00       jmp    *0x15b4(%rip)        # 401c20 <_GLOBAL_OFFSET_TABLE_+0x10>
>   40066c:     0f 1f 40 00             nopl   0x0(%rax)

This is another instance of PR binutils/33389, so this patch xfail's the
test.

Tested on {amd64,i386}-pc-solaris2.11 and {x86_64,i686}-pc-linux-gnu.

2026-01-25  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

binutils:
PR binutils/33243
PR binutils/33389
* testsuite/binutils-all/compress.exp (test_gnu_debuglink): xfail
on Solaris/amd64.

regen pot files

PR 33838 Truncated translation in objcopy.c

The only macros allowed are the ones specially handled by gettext,
such as PRId64.

* objcopy.c (copy_usage): Don't use string literal
concatenation of macros in translated strings.

Patch from Andreas Schwab <schwab@linux-m68k.org>

PR 33835 readelf incorrect handling of DWARF5 CU DIE addr_base attribute

Users of "readelf" report problems running the tool's DWARF dump flag
on binaries built with the most recent version of the Go compiler (1.25),
Go bug report here https://github.com/golang/go/issues/77246

dwarf.c (skip_attribute <DW_FORM_string>): Skip terminating NUL too.

Automatic date update in version.in

Hard-coded plural in readelf.c

PR 33837
* readelf.c (process_got_section_contents): Use ngettext.

regen gprofng config

hppa64: Skip/xfail three ld tests on hppa*64*-*-*

The ver_def test fails because of the __text_seg and __data_seg
symbols in the dynamic symbol table.

The sec64k tests creates too many sections and fails.

The linux target doesn't currently have .data.rel.ro and fails the
regexp test for pr20995.

2026-01-24  John David Anglin  <danglin@gcc.gnu.org>

ld/testsuite/ChangeLog:

* ld-elf/readelf.exp: Skip ver_def on hppa*64*-*-*.
* ld-elf/sec64k.exp: Likewise.
* ld-elf/shared.exp: xfail pr20995 on all OSes.

Regenerate autogenerated files

Add 2.46 release markers to NEWS files.  Update BRANCHES.  Update README.

ld: sframe: do not generate .sframe for PLT if no .sframe is in input BFDs

GNU ld creates SFrame stack trace info for the PLT. For x86 the linker-
created .sframe section is created in setup_gnu_properties.  For s390 it
is created in create_dynamic_sections.  For both, the section data is
itself emitted a bit later in late_size_sections.  Note that for aarch64 the
linker does not create .sframe for PLT yet.

Recall that a previous patch 832ca9ef670 uncoupled
--no-ld-generated-unwind-info from the linker-generated .sframe
sections.  This means that the linker now generates .sframe section (for
.plt*) for the first input BFD enthusiatically even when none of the
input BFDs have any .sframe section, unless --discard-sframe is also
added.  The issue is that these (unexpected) linker-generated .sframe
sections (on x86_64, and s390) may now trip the linking process, e.g.,
when using --orphan-handling=error together with a linker script that
treats .sframe differently than the default linker script.
https://sourceware.org/pipermail/binutils/2026-January/147826.html

Further, with SFrame sections to be soon marked KEEP for fixing
GC/SFrame (PR ld/32769), the presence of these linker generated SFrame
sections will also cause emission of an empty .sframe (for x86_64 and
s390x), even when all input bfd's have no .sframe section.

This patch avoids creation of .sframe for .plt* if none of the input
BFDs had any .sframe section.  This then avoids creation of empty
.sframe in linked objects on x86_64 and s390x, when none of the inputs
have SFrame sections.  This also fixes PR ld/33830.

For the code changes:
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
New testcases have (since the above Reviewed-by) been added.  Since
--no-ld-generated-unwind-info is not supported on aarch64, add
target-specific ld tests.  Additionally add a generic test (for all
targets that support SFrame) to ensure no output .sframe is generated if
users says no --gsframe or similar.

bfd/
PR ld/33830
* elf-bfd.h (_bfd_elf_sframe_present_input_bfds): New
declaration.
* elf-sframe.c (_bfd_elf_sframe_present_input_bfds): New
definition.
* elf64-s390.c (elf_s390_create_dynamic_sections): Do not
generate .sframe for .plt unconditionally.
* elfxx-x86.c (_bfd_x86_elf_link_setup_gnu_properties):
Likewise.
ld/testsuite/
PR ld/33830
* ld-s390/no-sframe.ld: Linker script with no specification for
SFrame sections.
* ld-s390/s390.exp: Add new test.
* ld-s390/sframe-command-line-2.d: New testcase that uses
--no-ld-generated-unwind-info and a linker script that has no
specific rules for .sframe.
* ld-x86-64/no-sframe.ld: Likewise for x86_64.
* ld-x86-64/sframe-command-line-2.d: Likewise for x86_64.
* ld-x86-64/x86-64.exp: Add new test.
* ld-sframe/no-ld-generated-sframe.d: Ensure no .sframe in
output if no .sframe in input.
* ld-sframe/no-sframe.ld: Linker script with no specification
for SFrame sections.
* ld-sframe/test.s: Add new test.

gas: aarch64: i386: s390: sframe: adjust sframe_ra_tracking_p

Like the previous commit b600229503 which adjusted the implementation of
flex fde hook, make a similar change for sframe_ra_tracking_p.

Simply providing the definition to use boolean value direcly is
sufficient for the purpose, and helps generate better code.

gas/
* config/tc-aarch64.c (aarch64_sframe_ra_tracking_p): Remove.
* config/tc-aarch64.h (aarch64_sframe_ra_tracking_p): Remove.
(sframe_ra_tracking_p): Set to true.
* config/tc-i386.c (x86_sframe_ra_tracking_p): Remove.
* config/tc-i386.h (x86_sframe_ra_tracking_p): Remove.
(sframe_ra_tracking_p): Set to false.
* config/tc-s390.c (s390_sframe_ra_tracking_p): Remove.
* config/tc-s390.h (s390_sframe_ra_tracking_p): Remove.
(sframe_ra_tracking_p): Set to true.

Automatic date update in version.in

hppa64: Fix Linux link

The "BFD_ASSERT (r_symndx != STN_UNDEF)" assert is incorrect and
triggers linking Linux kernel.

2026-01-24  John David Anglin  <danglin@gcc.gnu.org>

bfd/ChangeLog:

* elf64-hppa.c (elf64_hppa_relocate_section): Remove asserts.

gas/NEWS: Add AArch64 updates

aarch64: Tidy architecture extensions documentation

Document mops_go, add some missing full stops, and fix alphabetization
mistakes.

aarch64: Fix sme2p3 and f16f32dot feature dependencies

These are changed to match the dependencies we agreed with LLVM.

aarch64: Add -march=armv9.7-a option

aarch64: Fix documentation of armv9.6-a dependencies

The sve2p2 and fprcvt extensions were removed from -march=armv9.6-a, but
we forgot to update the documentation at the same time.

aarch64: Remove redundant macros

We no longer encode flags in the aarch64_hint_options value field, so
delete the HINT_VAL, HINT_FLAG and HINT_ENCODE macros.

aarch64: Add support for TLBID system registers

This patch adds support for following TLBID system registers.

* tlbididr_el1 (RO)
* vtlbid0_el2
* vtlbid1_el2
* vtlbid2_el2
* vtlbid3_el2
* vtlbidos0_el2
* vtlbidos1_el2
* vtlbidos2_el2
* vtlbidos3_el2

aarch64: TLBI Domains changes for PLBI instruction

For the PLBI instruction with optional register argument
<Rt> == 0b1111, with FEAT_TLBID enabled they are permitted to
have an Rt value which is not 0b11111 and this is allowed for
all the TLBI instructions with a <type> of ALLE1*, ALLE2* and
VMALL* and a <shareability> of IS or OS.