Automatic date update in version.in

[gdb/testsuite] Fix gdb.base/style.exp on freebsd

On x86_64-freebsd, with test-case gdb.base/style.exp I run into:
...
(gdb) print $_colorsupport
\e[36;49;22;27m$1\e[m = "monochrome"
(gdb) FAIL: $exp: colorsupport_8color: color support is 8 color
...

Fix this by applying the same fix as for tuiterm: use TERM=ansiw instead of
TERM=ansi for bsd, getting us instead:
...
(gdb) print $_colorsupport
\e[36;49;22;27m$1\e[m = "monochrome,ansi_8color"
(gdb) PASS: $exp: colorsupport_8color: color support is 8 color
...

Tested on x86_64-freebsd.

Disabling hardware single step in gdbserver

This patch gives gdbserver the ability to omit the 's' reply to
'vCont?'.  This tells gdb that hardware single-step is definitely not
supported, causing it to fall back to using software single-step.
This is useful for testing the earlier change to
maybe_software_singlestep.

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

Call target_can_do_single_step from maybe_software_singlestep

When the PikeOS osabi sniffer was added, Pedro suggested that a target
could omit stepping from its vCont? reply packet to tell gdb that
software single-step must be used:

https://sourceware.org/legacy-ml/gdb-patches/2018-09/msg00312.html

This patch implements this idea by moving the call to
target_can_do_single_step into maybe_software_singlestep.

I've also removed some FIXME comments from gdbarch_components.py, and
slightly updated the documentation for gdbarch_software_single_step.
I think these comments are somewhat obsolete now that
target_can_do_single_step exists -- the current approach isn't exactly
what the comments intended, but on the other hand, it exists and
works.

Following review comments from Andrew, this version changes
record-full to use maybe_software_singlestep, and then combines
maybe_software_singlestep with insert_single_step_breakpoint.

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

gdb: Add myself to gdb/MAINTAINERS

windres PR 33244 testcase

Make the windres testing both parse .rc files to binary and back
again.  It's not possible to compare against the original .rc file
unfortunately, but at least this checks for the segfault fixed by
commit 891d1654d731.

PR 33244
* testsuite/binutils-all/windres/psql.rc: New file.
* testsuite/binutils-all/windres/windres.exp: Do a -J res
-O rc conversion too.  Correct verbose message.

Automatic date update in version.in

Automatic date update in version.in

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

Commit c6c8d0b82175 went completely the wrong way.  "key" needs to be
NULL as that reads a different type of data.

PR 33244
* resbin.c (get_version_header): Don't pass a NULL key on to
toosmall.
(bin_to_res_version): Restore NULL key cases.

Automatic date update in version.in

gdb/MAINTAINERS: Update my email address

gprof: Run tst-gmon-gprof-l.sh after tst-gmon-gprof.sh

Both tst-gmon-gprof.sh and tst-gmon-gprof-l.sh generate gmon.out and
process it.  Run tst-gmon-gprof-l.sh after tst-gmon-gprof.sh to avoid
the race condition.

* testsuite/Makefile.am (tst-gmon-gprof-l.out): Depend on
tst-gmon-gprof.out.
* testsuite/Makefile.in: Regenerated.

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

gdbserver: switch to using getopt_long for argument processing

Update gdbserver to use getopt_long for argument processing.  This
turned out to be easier than I expected.

Interesting parts of this patch are:

I pass '+' as the OPTSTRING to getopt_long, this prevents getopt_long
from reordering the contents of ARGV.  This is needed so that things
like this will work:

  gdbserver :54321 program --arg1 --arg2

Without the '+', getopt_long will reorder ARGV, moving '--arg1' and
'--arg2' forward and handling them as arguments to gdbserver.

Because of this (not reordering) and to maintain backward
compatibility, we retain a special case to deal with '--attach' which
can appear after the PORT, like this:

  gdbserver :54321 --attach PID

I did consider adding a warning to this special case, informing the
user that placing --attach after the PORT was deprecated, but in the
end I didn't want to really change the behaviour as part of this
commit, so I've left that as an optional change for the future.

The getopt_long function supports two value passing forms, there is
'--option=value', and also '--option value'.  Traditionally, gdbserver
only supports the first of these.  To maintain this behaviour, after
the call to getopt_long, I spot if '--option value' was used, and if
so, modify the state so that it seems that no value was passed, and
that 'value' is the next ARGV entry to be parsed.  We could, possibly,
remove this code in the future, but that would be a functional change,
which is not something I want in this commit.

Handling of "-" for stdio connection has now moved out of the argument
processing loop as '-' isn't considered a valid option by getopt_long,
this is an improvement as all PORT handling is now in one place.

I've tried as much as possible to leave user visible functionality
unchanged after this commit, and as far as I can tell from testing,
nothing has changed.

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

gdbserver: exit with code 1 after missing packet name

When using the command:

  $ gdbserver --disable-packet

gdbserver lists all the packets that can be disabled, and then exits.
I think that this output is a helpful error message that is printed
when the user has forgotten to entry a packet name.  We get similar
output if we run the command:

  $ gdbserver --disable-packet=foo

where gdbserver tells us that 'foo' is invalid, and then lists the
packets that we can use.

The difference is that, in the first case, gdbserver exits with a code
of 0, and in the second, gdbserver exits with a code of 1.

I think both these cases should exit with a code of 1.

With the exception of '--help' and '--version', where we are asking
gdbserver to print some message then exit (which are, and should exit
with a code of 0), in all other cases where we do an early exit, I
think this is an indication that the user has done something
wrong (entered and invalid argument, or missed an argument value), and
gdbserver should exit with a non-zero exit code to indicate this.

This commit updates the exit code in the above case from 0 to 1.

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

gdbserver: convert locals to `bool` in captured_main

Within gdbserver/server.cc, in captured_main, convert some locals to
bool.  Move the declaration of some locals into the body of the
function.

There should be no user visible changes after this commit.

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

opcodes/x86: make i386_mnem[] static

With the tables no longer being part of libopcodes (but rather being
compiled directly into gas), this table doesn't need exposing anymore.
The declaration cannot be avoided, though, as the first use of the
array sits ahead of its definition (in i386-tbl.h).

opcodes/riscv: make riscv_options[] const

There's no reason to allow the array to be modifiable. In fact the
compiler is able to infer this, placing the array in .data.rel.ro, but
let's make it explicit.

opcodes/ppc: make ppc_opts[] static const

There's no reason to allow the array to be modifiable, nor for it to be
globally visible.

opcodes/aarch64: convert print_sme_za_list()'s zan[] / zan_v[]

Merge them into a single array of struct type. There's further no reason
to have the compiler materialize such objects on the stack. And there's
also no reason to allow the array(s) to be modifiable. Finally, given
how short the strings are, there's little point using more space to
store pointers to them (on 64-bit hosts; the situation is a little
better on 32-bit ones).

While there also correct indentation in adjacent code, and avoid open-
coding ARRAY_SIZE().

opcodes/aarch64: make aarch64_opnd_qualifiers[] static const

There's no reason to allow the array to be modifiable, nor for it to be
globally visible.

opcodes/aarch64: make aarch64_ext_ldst_reglist()'s data[] static const

There's no reason to have the compiler materialize such an object onto the
stack. And there's also no reason to allow the array to be modifiable.

gas: check section size against entry size

If a section has a non-zero entry size, its total size would generally
better be a multiple of the entry size. Warn if that's not the case.

Update my e-mail

Update some entries in the gdb/MAINTAINERS file.

gdb/dwarf: sort dwarf2_per_bfd::all_units by (section, offset)

This patch started as a fix for PR 29518 ("GDB doesn't handle
DW_FORM_ref_addr DIE references correctly with .debug_types sections")
[1], but the scope has expanded a bit to fix the problem more generally,
after I spotted a few issues related to the order of all_units.  The
first version of this patch is here [2].

PR 29518 shows that dwarf2_find_containing_comp_unit can erroneously
find a type unit.  The obvious problem is that the
dwarf2_find_containing_comp_unit function searches the whole all_units
vector (containing both comp and type units), when really it should just
search the compilation units.  A simple solution would be to make it
search the all_comp_units view (which is removed in a patch earlier in
this series).

I then realized that in DWARF 5, since type units are in .debug_info
(versus .debug_types in DWARF 4), type units can be interleaved with
comp type in the all_units vector.  That would make the all_comp_units
and all_type_units views erroneous, and dwarf2_find_containing_comp_unit
could still return something wrong.  In v1, I added a sort in
finalize_all_units to make sure all_units is in the order that
dwarf2_find_containing_comp_unit expects:

 - comp units from the main file
 - type units from the main file
 - comp units from the dwz file
 - type units from the dwz file (not actually supported, see PR 30838)

Another problem I spotted is that the .gdb_index reader creates units in
this order:

 - comp units from .gdb_index from main file
 - comp units from .gdb_index from dwz file
 - type units from .gdb_index from main file

This isn't the same order as above, so it would need the same sort step.

Finally, I'm not exactly sure if and when it happens, but it looks like
lookup_signatured_type can be called at a later time (after the initial
scan and creation of dwarf2_per_cu object creation), when expanding a
symtab.  And that could lead to the creation of a new type unit (see
function add_type_unit), which would place the new type unit at the end
of the all_units vector, possibly screwing up the previous order.

To handle all this in a nice and generic way, Tom Tromey proposed to
change the all_units order, so that units are sorted by section, then
section offset.  This is what this patch implements.  The sorting is
done in finalize_all_units.

This works well, because when looking up a unit by section offset, the
caller knows which section the unit is in.  Passing down a (section,
section offset) tuple makes it clear and unambiguous what unit the
caller is referring to.  It should help eliminate some bugs where the
callee used the section offset in the wrong section.  Passing down the
section along with the section offset replaces the "is_dwz" flag passed
to dwarf2_find_containing_comp_unit and a bunch of other functions in a
more general way.

dwarf2_find_containing_comp_unit can now legitimately find and return
type units even though it should be needed (type units are typically
referred to by signature).  But I don't think there is harm for this
function to be more generic than needed.  I therefore I renamed it to
dwarf2_find_containing_unit.

The sort criterion for "section" can be anything, as long as we use the
same for sorting and searching.  In this patch, I use the pointer to
dwarf2_section_info, because it's easy.  The downside is that the actual
order depends on what the memory allocator decided to return, so could
change from run to run, or machine to machine.  Later, I might change it
so that sections are ordered based on their properties, making the order
stable across the board.  This logic is encapsulated in the
all_units_less_than function, so it's easy to change.

The .debug_names reader can no longer rely on the order of the all_units
vector for its checks, since all_units won't be the same order as found
in the .debug_names lists.  In fact, even before, it wasn't: this check
assumed that .debug_info had all CUs before TUs, and that the index
listed them in the exact same order.  When I build a file with gcc and
"-gdwarf-5 -fdebug-types-section", type units appear first in
.debug_info.  This caused GDB to reject a .debug_names index that is had
produced:

    $ GDB="./gdb -nx -q --data-directory=data-directory" /home/smarchi/src/binutils-gdb/gdb/contrib/gdb-add-index.sh -dwarf-5 hello.so
    $ ./gdb -nx -q --data-directory=data-directory hello.so
    Reading symbols from hello.so...

    ⚠️  warning: Section .debug_names has incorrect entry in CU table, ignoring .debug_names.

To make it work, add a new dwarf2_find_unit function that allows looking
up a unit by start address (unlike dwarf2_find_containing_unit, which
can find by any containing address), and make the .debug_names reader
use it.  It might make the load time of .debug_names a bit longer (the
build and check step is now going to be O(n*log(n)) instead of O(n)
where n is the number of units, or something like that), but I think
it's important to be correct here.

This patch adds a test
(gdb.dwarf2/dw-form-ref-addr-with-type-units.exp), which tries to
replicate the problem as shown by PR 29518.

gdb.base/varval.exp needs a small change, because an error message
changes (for the better, I think)

gdb.dwarf2/debug-names-non-ascending-cu.exp now fails, because GDB no
longer rejects a .debug_names index which lists CUs in a different order
than .debug_info.  Given the change I did to the .debug_names reader,
explained above, I don't think this is a problem anymore (GDB can accept
an index like that).  I also don't think that DWARF 5 mandates that CUs
are in ascending order.  Delete this test.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=29518
[2] https://inbox.sourceware.org/gdb-patches/20250218193443.118139-1-simon.marchi@efficios.com/

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

gdb/dwarf: sort units when writing index

The order of all_units can't be relied on when writing the CU and TU
lists to .gdb_index or .debug_names.

Both the .gdb_index and .debug_names writers expect that all_units
contains comp units followed by type units.  As of this commit, when
reading a DWARF 5 .debug_info, the all_units vector is ordered based on
the order the units appear in .debug_info, where type units can be
interleaved with comp units.

It probably worked fine with DWARF 4, where type units were in a section
of their own (.debug_types).  They were read after comp units, and
therefore after them in the all_units vector.

Change the writers to use a common function that splits the units in two
lists (comp units and type units).  Sort both lists by section offset.
This is more than required, but it should help produce a stable and
predictable output.

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

gdb/dwarf: make .gdb_index reader use its own list of units

The .gdb_index reader currently uses per_bfd::all_units when translating
a numerical index (as found in an index entry) to a dwarf2_per_cu.  The
order of per_bfd::all_units is going to change in a subsequent patch, so
the indices as found in the index won't map to the right unit in
all_units.  Change the .gdb_index reader to maintain its own vector,
with the units in the same order as found in the .gdb_index header.

This is similar to what the .debug_names reader does.  But unlike
.debug_names, .gdb_index treats the CUs and TUs as a single list, as far
as the numerical indices are concerned, so we only need a single list
here (versus two for .debug_names).

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

gdb/dwarf: move index unit vectors to .debug_names reader and use them

The all_comp_units_index_cus and all_comp_units_index_tus vectors
contain the CU and TU lists as found in the .debug_names list.  It seems
like they are meant to be used by the .debug_names reader when handling
a DW_IDX_compile_unit or DW_IDX_type_unit attribute.  The value of the
attribute would translate directly into an index into one of these
vectors.

However, it looks like these vectors aren't actually used in practice.
They are used in the dwarf2_per_bfd::get_index_{c,t}u methods, which in
turn aren't used anywhere.

The handlers of DW_IDX_compile_unit and DW_IDX_type_unit use the
dwarf2_per_bfd::get_unit method, with the assumption that
dwarf2_per_bfd::all_units has comp units before type units.  This is not
the case: the .debug_names reader creates the units in
dwarf2_per_bfd::all_units using the create_all_units function, which
creates the units in the order found in .debug_info, where type units
can be interleaved with comp units.

Since those vectors are specific to the .debug_names reader, move them
to the mapped_debug_names_reader struct.  Then, update the handlers of
DW_IDX_compile_unit and DW_IDX_type_unit to actually use them.

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

gdb/dwarf: remove all_{comp,type}_units views

In DWARF 5, type units appear in the .debug_info section, interleaved
with comp units, and the order in all_units reflects that.  The
all_comp_units and all_type_units views are wrong in that case
(all_comp_units contains some type units, and vice-versa).

It would be possible to manually sort all_units to ensure that type
units follow comp units, but this series takes the approach of sorting
the units by section and section offset.

Remove those views, and replace their uses with num_comp_units and
num_type_units.  It appears that the views were only used to know the
number of each kind.

The finalize_all_units function is now empty, but I am keeping it
because a subsequent patch adds a call to std::sort in there to sort the
all_units vector.

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

gdb/dwarf: track compilation and type unit count

A subsequent commit will remove the all_comp_units and all_type_units
array views, since it's not possible to assume that that all_units
vector is segmented between comp and type units.  Some callers still
need to know the number of each kind, so track that separately.

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

ia64 assembler warning breaks ld tests

The "Warning: Explicit stops are ignored in auto mode" results in
failures of a number of run_ld_link_tests because the compiler is run
using -S and then the resulting .s file assembled without suppplying
-x to gas.  Fix that problem by adding -x to ASFLAGS for ia64, and
tweak the binutils link-order test since the source is used in a ld
test too.

ld/
* testsuite/config/default.exp: Set ASFLAGS to "-x" for ia64.
Remove unnecessary "global".
binutils/
* testsuite/binutils-all/link-order.s: Provide explicit stop.
* testsuite/binutils-all/objcopy.exp: Pass "-x" when building
link-order test for ia64.

ld-elf/shared libpr23161c and pr23161c tests

If I understand these tests correctly it is to ensure that _end,
_edata and __bss_start are not made dynamic.  The dynamic reloc tests
are not really necessary.  (We dropped them from pr23161a and pr23161b
tests a while ago without removing the -r from readelf invocation.)
Dropping the reloc tests allows them to run for more targets.

* testsuite/ld-elf/pr23161c.rd: Rewrite.
* testsuite/ld-elf/pr23161d.rd: Delete.
* testsuite/ld-elf/shared.exp (pr23161a, pr23161b): Remove -r
from readelf check.
(libpr23161c.so, pr23161c): Likewise, and check expected readelf
output using the new pr23161c.rd.

Automatic date update in version.in

Don't nest double quotes in tuiterm.exp

I found a line in tuiterm.exp that causes Emacs paren-matching to go
awry.  This patch fixes the problem by changing some apparent nested
double quotes (which I think isn't really possible in Tcl but this
seems to be the intent) to be more correct; which fixes the Emacs
issue as well.

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

zlib: import zlib-1.3.1 [PR32933]

As done just now on the GCC side in r16-2677-g7a79219383c83c,
import zlib-1.3.1.

strip: Treat "default" output_target as unspecified

Treat output target as unspecified if it is set to "default".

binutils/

PR binutils/33230
* objcopy.c (copy_file): Treat "default" output_target as
unspecified.

binutils/testsuite/

PR binutils/33230
* binutils-all/x86-64/x86-64.exp (run_pr33230_test): New.
Run binutils/33230 tests with readelf if supported.

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

[gdb/testsuite] Fix gdb.gdb/python-helper.exp with gdb built with -flto

With a gdb build with gcc 7.5.0 and "-O2 -flto=auto -g", I run into:
...
(outer-gdb) PASS: gdb.gdb/python-helper.exp: print varobj_table
print inferior_list
$5 = {m_front = 0x212e830, m_back = 0x2e39aa0}
(outer-gdb) FAIL: gdb.gdb/python-helper.exp: print inferior_list
...

The problem is that the type of inferior_list:
...
(outer-gdb) what inferior_list^M
type = intrusive_list^M
(outer-gdb)
...
is not descriptive enough to trigger the pretty pretter.

Note that with a gdb build with -O0, we'd get instead:
...
(outer-gdb) what inferior_list^M
type = intrusive_list<inferior, intrusive_base_node<inferior> >
(outer-gdb)
...

Fix this by detecting this situation, and declaring the test unsupported.

Tested on x86_64-linux.

strip: Don't check target_defaulted in input BFD

The target_defaulted field in BFD is set to true if the target isn't
specified.  After

commit 717a38e9a02109fcbcb18bb2ec3aa251e2ad0a0d
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Sun May 4 05:12:46 2025 +0800

    strip: Add GCC LTO IR support

the target is set to "plugin" if BFD supports plugin when the target
isn't specified nor default.  Update strip to check the input target,
instead of the target_defaulted field in input BFD.

PR binutils/33230
* objcopy.c (copy_object): Add a bool argument, target_defaulted,
to indicate if the input target isn't specified nor default.
Check it instead of ibfd->target_defaulted.
(copy_archive): Add a bool argument, target_defaulted, and pass
it to copy_object.
(copy_file): Set target_defaulted to true if the input target
isn't specified and pass it to copy_archive and copy_object.
* testsuite/binutils-all/x86-64/pr33230.obj.bz2: New file.
* testsuite/binutils-all/x86-64/x86-64.exp: Run PR binutils/33230
tests.

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

Automatic date update in version.in

PR 33229 nds32 gas segfaults on gcc output

Commit 1ac26e9f7ac2 replaced ISSPACE with is_whitespace, but the
former returns true on EOL while the latter does not.  Sprinkle
is_end_of_stmt tests to fix this bug.

The same segfault can be triggered by a ".relax_hint" with no
following instructions.  Fix that too.

* config/tc-nds32.c (nds32_lookup_pseudo_opcode): Use
is_end_of_stmt along with is_whitespace.
(nds32_relax_relocs, nds32_relax_hint, nds32_flag),
(ict_model: Likewise.
(nds32_elf_append_relax_relocs): Return on no opcode.
* testsuite/gas/nds32/nds32.exp: Find .d files automatically.
* testsuite/gas/nds32/pr33229.d,
* testsuite/gas/nds32/pr33229.s: New test.

Automatic date update in version.in

ppc _bfd_clear_contents

ppc32 isn't susceptible to the PR33223 segfault, but could hit a
_bfd_clear_contents segfault with a carefully crafted invalid object.

* elf32-ppc.c (ARRAY_SIZE): Define.
(ppc_elf_howto_init): Use ARRAY_SIZE.
(ppc_elf_reloc_name_lookup): Likewise.
(ppc_elf_info_to_howto): Likewise, and consolidate error
handling.
(ppc_elf_check_relocs): Guard against segfaults caused by a NULL
howto passed to _bfd_clear_contents.  Use ARRAY_SIZE.

PR 33223 ppc64: segfault on unknown relocation

Bounds check accesses to ppc64_elf_howto_table and don't dereference a
NULL howto.  I think this catches all cases where that might happen.

PR 33223
bfd/
* elf64-ppc.c (ppc64_elf_info_to_howto): Consolidate error handling.
(ppc64_elf_check_relocs): Tidy error messages.
(ppc64_elf_relocate_section): Don't segfault when attempting to
report an unsupported relocation.  Don't pass a NULL howto to
_bfd_clear_contents.
ld/
* testsuite/ld-powerpc/elfv2-2so.d: Adjust to suit error message
change.

ld: testsuite: Enable ld-elfweak tests on Solaris/x86

The ld-elfweak tests are currently only enabled on Solaris/SPARC for no
apparent reason.  Enabling them on Solaris in general lets them all PASS
on both amd64-pc-solaris2.11 and i386-pc-solaris2.11.

2025-07-25  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

ld:
* testsuite/ld-elfweak/elfweak.exp: Enable on *-*-solaris2* rather
than sparc*-*-solaris2* only.

Automatic date update in version.in

ld: testsuite: Fix "PR ld/28138 (build only)" on Solaris

The

FAIL: PR ld/28138 (build only)

test FAILs on Solaris:

ld/tmpdir/ld/collect-ld: plugin framework: out of file descriptors. Try using fewer objects/archives

ld/tmpdir/ld/collect-ld: cannot find -lgcc: Too many open files
[...]

I found that the test PASSes when using ulimit -n 21 instead of the
current 20.  Looking with strace/truss, on Linux/i686 the following
files are opened:

301543 openat(AT_FDCWD, "tmpdir/pr28138", O_RDWR|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
301543 openat(AT_FDCWD, "/lib/../lib32/crt1.o", O_RDONLY|O_LARGEFILE) = 4
301543 openat(AT_FDCWD, "/lib/../lib32/crt1.o", O_RDONLY|O_LARGEFILE) = 5
301543 openat(AT_FDCWD, "/lib/../lib32/crti.o", O_RDONLY|O_LARGEFILE) = 5
301543 openat(AT_FDCWD, "/lib/../lib32/crti.o", O_RDONLY|O_LARGEFILE) = 6
301543 openat(AT_FDCWD, "lib/gcc/i686-pc-linux-gnu/12.1.0/crtbegin.o", O_RDONLY|O_LARGEFILE) = 6
301543 openat(AT_FDCWD, "lib/gcc/i686-pc-linux-gnu/12.1.0/crtbegin.o", O_RDONLY|O_LARGEFILE) = 7
301543 openat(AT_FDCWD, "tmpdir/pr28138.o", O_RDONLY|O_LARGEFILE) = 7
301543 openat(AT_FDCWD, "tmpdir/pr28138.o", O_RDONLY|O_LARGEFILE) = 8
301543 openat(AT_FDCWD, "tmpdir/pr28138.a", O_RDONLY|O_LARGEFILE) = 8
301543 openat(AT_FDCWD, "tmpdir/pr28138.a", O_RDONLY|O_LARGEFILE) = 9
301543 openat(AT_FDCWD, "tmpdir/pr28138-7.o", O_RDONLY|O_LARGEFILE) = 9
301543 openat(AT_FDCWD, "tmpdir/pr28138-7.o", O_RDONLY|O_LARGEFILE) = 10
301543 openat(AT_FDCWD, "tmpdir/pr28138-6.o", O_RDONLY|O_LARGEFILE) = 10
301543 openat(AT_FDCWD, "tmpdir/pr28138-6.o", O_RDONLY|O_LARGEFILE) = 11
301543 openat(AT_FDCWD, "tmpdir/pr28138-5.o", O_RDONLY|O_LARGEFILE) = 11
301543 openat(AT_FDCWD, "tmpdir/pr28138-5.o", O_RDONLY|O_LARGEFILE) = 12
301543 openat(AT_FDCWD, "tmpdir/pr28138-4.o", O_RDONLY|O_LARGEFILE) = 12
301543 openat(AT_FDCWD, "tmpdir/pr28138-4.o", O_RDONLY|O_LARGEFILE) = 13
301543 openat(AT_FDCWD, "tmpdir/pr28138-3.o", O_RDONLY|O_LARGEFILE) = 13
301543 openat(AT_FDCWD, "tmpdir/pr28138-3.o", O_RDONLY|O_LARGEFILE) = 3
301543 openat(AT_FDCWD, "tmpdir/pr28138-2.o", O_RDONLY|O_LARGEFILE) = 3
301543 openat(AT_FDCWD, "tmpdir/pr28138-2.o", O_RDONLY|O_LARGEFILE) = 4
301543 openat(AT_FDCWD, "tmpdir/pr28138-1.o", O_RDONLY|O_LARGEFILE) = 4
301543 openat(AT_FDCWD, "tmpdir/pr28138-1.o", O_RDONLY|O_LARGEFILE) = 5

while on Solaris/i386 there are a couple more:

27726: openat64(AT_FDCWD, "tmpdir/pr28138", O_RDWR|O_CREAT|O_TRUNC, 0666) = 4
27726: openat64(AT_FDCWD, "/usr/lib/crt1.o", O_RDONLY) = 5
27726: openat64(AT_FDCWD, "/usr/lib/crt1.o", O_RDONLY) = 6
27726: openat64(AT_FDCWD, "lib/gcc/i386-pc-solaris2.11/14.2.0/crtp.o", O_RDONLY) = 6
27726: openat64(AT_FDCWD, "lib/gcc/i386-pc-solaris2.11/14.2.0/crtp.o", O_RDONLY) = 7
27726: openat64(AT_FDCWD, "/usr/lib/crti.o", O_RDONLY) = 7
27726: openat64(AT_FDCWD, "/usr/lib/crti.o", O_RDONLY) = 8
27726: openat64(AT_FDCWD, "/usr/lib/values-Xa.o", O_RDONLY) = 8
27726: openat64(AT_FDCWD, "/usr/lib/values-Xa.o", O_RDONLY) = 9
27726: openat64(AT_FDCWD, "/usr/lib/values-xpg6.o", O_RDONLY) = 9
27726: openat64(AT_FDCWD, "/usr/lib/values-xpg6.o", O_RDONLY) = 10
27726: openat64(AT_FDCWD, "lib/gcc/i386-pc-solaris2.11/14.2.0/crtbegin.o", O_RDONLY) = 10
27726: openat64(AT_FDCWD, "lib/gcc/i386-pc-solaris2.11/14.2.0/crtbegin.o", O_RDONLY) = 11
27726: openat64(AT_FDCWD, "tmpdir/pr28138.o", O_RDONLY) = 11
27726: openat64(AT_FDCWD, "tmpdir/pr28138.o", O_RDONLY) = 12
27726: openat64(AT_FDCWD, "tmpdir/pr28138.a", O_RDONLY) = 12
27726: openat64(AT_FDCWD, "tmpdir/pr28138.a", O_RDONLY) = 13
27726: openat64(AT_FDCWD, "tmpdir/pr28138-7.o", O_RDONLY) = 13
27726: openat64(AT_FDCWD, "tmpdir/pr28138-7.o", O_RDONLY) = 14
27726: openat64(AT_FDCWD, "tmpdir/pr28138-6.o", O_RDONLY) = 14
27726: openat64(AT_FDCWD, "tmpdir/pr28138-6.o", O_RDONLY) = 15
27726: openat64(AT_FDCWD, "tmpdir/pr28138-5.o", O_RDONLY) = 15
27726: openat64(AT_FDCWD, "tmpdir/pr28138-5.o", O_RDONLY) = 16
27726: openat64(AT_FDCWD, "tmpdir/pr28138-4.o", O_RDONLY) = 16
27726: openat64(AT_FDCWD, "tmpdir/pr28138-4.o", O_RDONLY) = 17
27726: openat64(AT_FDCWD, "tmpdir/pr28138-3.o", O_RDONLY) = 17
27726: openat64(AT_FDCWD, "tmpdir/pr28138-3.o", O_RDONLY) = 18
27726: openat64(AT_FDCWD, "tmpdir/pr28138-2.o", O_RDONLY) = 18
27726: openat64(AT_FDCWD, "tmpdir/pr28138-2.o", O_RDONLY) = 19
27726: openat64(AT_FDCWD, "tmpdir/pr28138-1.o", O_RDONLY) = 19
27726: openat64(AT_FDCWD, "tmpdir/pr28138-1.o", O_RDONLY) Err#24 EMFILE

While it seems weird that the same files are opened twice for reading,
it's no wonder that 20 fds aren't enough on Solaris.

To avoid this, I've raised the limit to 25, hoping that this will be
enough on more targets.

Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu.

2025-07-25  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

ld:
* testsuite/ld-plugin/lto.exp (PR ld/28138 test): Raise fd limit
to 25.

Add forgotten ChangeLog entry for commit 7c1c13e896c76879bcf3fb29332e0a59918bc9e0.

ld: testsuite: Skip "Run with libpr19553c.so" test on Solaris

The

FAIL: Run with libpr19553c.so

test FAILs on Solaris (32 and 64-bit, sparc and x86):

Running: tmpdir/pr19553c > tmpdir/pr19553c.out
diff tmpdir/pr19553c.out /vol/src/gnu/binutils/hg/master/local/ld/testsuite/ld-elf/pr19553c.out
1c1
< pr19553b
---
> pr19553c
child process exited abnormally

The test uses .symver, resulting in versioned symbols which the Solaris
ld.so.1 doesn't support and never will.  Running it with LD_DEBUG=all
shows

26493: 1: symbol=foo;  lookup in file=tmpdir/pr19553c  [ ELF ]
26493: 1: symbol=foo;  lookup in file=tmpdir/libpr19553c.so  [ ELF ]
26493: 1: symbol=foo;  skipping entry in file=tmpdir/libpr19553c.so, index[7], version=FOO, due to GNU version hidden bit
26493: 1: symbol=foo;  continuing lookup in file=tmpdir/libpr19553c.so  [ ELF ]
26493: 1: symbol=foo;  lookup in file=tmpdir/libpr19553b.so  [ ELF ]
26493: 1: binding file=tmpdir/pr19553c to file=tmpdir/libpr19553b.so: symbol 'foo'

so this patch skips the test.

2025-07-25  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

ld:
* testsuite/ld-elf/indirect.exp (Run with libpr19553c.so):
Skip on *-*-solaris2*.

Avoid timeouts with gnat-llvm in gdb.ada/operator_call.exp

While working on gnat-llvm, gdb.ada/operator_call.exp has many
timeouts.  This happens because gnat-llvm's DWARF output is still
incomplete, and so gdb emits an unexpected error in this test.

This patch improves the test by having it recognize this output and
issue a failure rather than a timeout.  This greatly speeds up
testing.

libctf: link: rejig lazy opening to not need weak symbols

The ctf_link_add_ctf API function has a 'lazy opening' feature whereby,
if you pass in the file but not a CTF archive, the archive is opened
as late as possible during links.  This is valuable mostly in
cu-mapped links (a feature not accessible via GNU ld), where it
ensures that, rather than eventually needing memory for the original
link inputs, the smushed-together cu-mapped intermediate outputs,
*and* the final output, we only need enough memory for the smushed-
together outputs, the final output, and one input, since the inputs
can be closed immediately after they are smushed together.

(In GNU ld, the feature is useless because it loads all sections into
memory anyway.)

The lazy-opening feature uses libctf's ctf_open function, which uses
BFD: so it is not available in libctf-nobfd -- except that I thought I
had a cunning trick, and used a weak symbol so that if you linked
libctf-nobfd into your program and then also linked in bfd, the feature
stayed enabled.

This is silly -- if your program is licensed such that you can link in
BFD, you can just link in libctf.so and not bother with libctf-nobfd.so
in the first place.  Worse, the weak symbol usage broke MacOS builds,
since MacOS's system compiler uses a different means of introducing weak
symbols.  We could test for and use it, but this is the only place in
libctf to use weak symbols at all, and the feature of lazy-opening with
libctf-nobfd is so marginal we might as well drop it: it's almost
certain there are zero users, certainly fewer users than users of MacOS
with the system compiler.

While we're at it, simplify things by deleting the never-implemented
feature (not exposed in the API) to allow linking together raw buffers
of CTF data.  If we need it we can bring it back, but all it's doing
right now is complicating the code to no end at all.

libctf/
PR libctf/33194
* ctf-link.c (ctf_open): Delete weak pragma.
(ctf_link_add): Fuse with...
(ctf_link_add_ctf): ... this function.  Drop BUF, N args
and corresponding unimplemented feature warnings.  Only check
NOBFD to see whether lazy loading is available, not PIC as
well.
(ctf_link_lazy_open): Likewise.

gas: add missing header guard in tc-<arch>.h files

This patch adds missing header guards in some of the tc-<arch>.h,
and merely comments on the corresponding #endif for others. The
patch does not aim at being exhaustive, it only touched the files
relevant for [1].

[1]: https://inbox.sourceware.org/binutils/20250711112913.2453285-1-matthieu.longo@arm.com/

Automatic date update in version.in

Update release documentation following 2.45 release

Automatic date update in version.in

doc: sframe: mention errata 1 of SFrame version 2

With the changes of an added flag SFRAME_F_FDE_FUNC_START_PCREL, s390x
support and new section type SHT_GNU_SFRAME, indicate that this document
specifies the errata 1 of SFrame version 2.  This will help distinguish
the document / specification better from previous releases.

libsframe/doc/
* sframe-spec.texi: Mention errata 1 of SFrame version 2.

Automatic date update in version.in

PR 33214 sparc LDM/STM/LDMA/STMA etc. FAIL on Solaris/SPARC

Delete code in compare_opcodes preferencing 1+i over i+1 and 1,i over
i,1.  Instead simply make the sort stable, by keeping the original
table order.

[gdb/tui] Fix shell command terminal settings

In bash I have the following terminal settings:
...
$ stty
speed 38400 baud; line = 0;
-brkint -imaxbel iutf8
...
and then in gdb using the shell command likewise:
...
(gdb) shell stty
speed 38400 baud; line = 0;
-brkint -imaxbel iutf8
(gdb)
...
and likewise using a shell session:
...
(gdb) shell
$ stty
speed 38400 baud; line = 0;
-brkint -imaxbel iutf8
$
...

But in TUI, we get different settings (removed runaway indentation for
readability):
...
(gdb) shell sttyspeed 38400 baud; line = 0;
min = 1; time = 0;
-brkint -icrnl -imaxbel iutf8
-onlcr
-icanon -echo

(gdb)
...
and consequently the shell is not really usable.  This is PR tui/18215.

The easiest way to fix this is to just temporarily leave TUI while in the shell,
leaving the output of the commands in CLI mode, but that's a bit confusing.

Fix this (as suggested in the PR) by restoring the initial terminal settings
while in the shell command, such that also in TUI we have:
...
(gdb) shell sttyspeed 38400 baud; line = 0;
-brkint -imaxbel iutf8

(gdb)
...

Tested on x86_64-linux.

Reported-By: Doug Evans <dje@google.com>
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18215

gdb: Convert gdb/mingw-hdep.c to INIT_GDB_FILE

I noticed that my MinGW GDB did not have the "maint set
console-translation-mode" command, even though the code to register it
is in gdb/mingw-hdep.c.

The problem is that gdb/mingw-hdep.c is not using INIT_GDB_FILE.  This
fixes it.

Change-Id: I3aa305c517e100d4733b391a110a1b20b89fdb7f

gdb: use the location_completer for the list command

The "location_completer" function has been available for a long time,
but it was seemingly never used as the completer for the list function.
A quick check through git history shows that a similar completer was
available for the "edit" command but wasn't added to "list" with no
reasoning for it.

I think "list" should use the location_completer, as it is more aware of
the locspec grammar.

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

gdb: fix copyright year in svr4-tls-tdep.c

Change-Id: Ia03b286d9544a209197e58e59e752dc3d2715359

gdb: fix copyright year in solib-frv.h

My mistake, I forgot to update this when merging my patch series.

Change-Id: I67691c962d91221bd9a684febd7296b4b9b5999f

gdb/dwarf: apply DW_AT_bit_offset when DW_AT_data_member_location is constant block

Since commit 420d030e88 ("Handle field with dynamic bit offset"), I see:

    $ make check TESTS="gdb.trace/unavailable-dwarf-piece.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
    FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d x
    FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d y
    FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d z

The first FAIL is:

    p/d x
    $4 = {a = 0, b = <unavailable>, c = <unavailable>, d = <unavailable>, e = <unavailable>, f = <unavailable>, g = <unavailable>, h = <unavailable>, i = <unavailable>, j = 0}
    (gdb) FAIL: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d x

When we should see:

    p/d x
    $4 = {a = 0, b = <unavailable>, c = 0, d = 0, e = 0, f = 0, g = 0, h = 0, i = 0, j = 0}
    (gdb) PASS: gdb.trace/unavailable-dwarf-piece.exp: tracing bar: p/d x

The structure we print is:

    0x0000004f:   DW_TAG_structure_type
                    DW_AT_name [DW_FORM_string]     ("t")
                    DW_AT_byte_size [DW_FORM_sdata] (3)
                    DW_AT_decl_file [DW_FORM_udata] (0)
                    DW_AT_decl_line [DW_FORM_udata] (1)

    0x00000055:     DW_TAG_member
                      DW_AT_name [DW_FORM_string]   ("a")
                      DW_AT_type [DW_FORM_ref4]     (0x00000019 "unsigned char")
                      DW_AT_data_member_location [DW_FORM_exprloc]  (DW_OP_plus_uconst 0x0)

    0x0000005f:     DW_TAG_member
                      DW_AT_name [DW_FORM_string]   ("b")
                      DW_AT_type [DW_FORM_ref4]     (0x00000019 "unsigned char")
                      DW_AT_byte_size [DW_FORM_sdata]       (1)
                      DW_AT_bit_size [DW_FORM_sdata]        (1)
                      DW_AT_bit_offset [DW_FORM_sdata]      (7)
                      DW_AT_data_member_location [DW_FORM_exprloc]  (DW_OP_plus_uconst 0x1)

    ...

The particularity of field "b" (and the following ones, not shown here)
is that they have:

 - a DW_AT_data_member_location of expression form, but that GDB reduces
   to a constant
 - a DW_AT_bit_offset

What I think happens is that the code path taken in this particular
scenario never ends up using the DW_AT_bit_offset value.  Fix it by
calling apply_bit_offset_to_field, like what is done when
data_member_location_attr is using a constant form.

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

gdb/dwarf: rename some variables in handle_member_location

For legibility, use more specific names for attribute variables and
don't reuse them for different attributes.

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

gas/NEWS: Add AArch64 updates

gas/doc: Update AArch64 Architecture Extensions

Add faminmax, move a couple of misplaced entries, and improve a few
other entries.

The documentation now lists every recognised extension name, with the
exception of a couple of aliases that are deliberately undocumented.

aarch64: Fix sve2p2/sme2p2 dependencies

Change dependency on sve2/sme2 to sve2p1/sme2p1.

gas: sframe: command line option takes precedence

over gas directive to emit .sframe section.

Fix PR gas/33175 sframe: --gsframe=no does not disable when
.cfi_sections directive with .sframe

--gsframe=no should also disable generation of SFrame section when
explicit CFI directive:
  .cfi_sections .sframe
is specified in the input.  This means we need to track whether SFrame
generation was explicitly disabled by the user.  Introduce a new enum to
facilitate disambiguation between GEN_SFRAME_DEFAULT_NONE and
GEN_SFRAME_DISABLED.

While fixing the bug by adding the enum, keep the upcoming requirement
in mind: we will also need to disambiguate between
--enable-default-sframe and user-specified --gsframe/--gsframe=yes.  The
intent is to not display SFrame related warnings or errors like:

  as_bad (_(".sframe not supported for target"));

for unsupported targets if --enable-default-sframe is in effect.

This implies we need to have a four state enum (
GEN_SFRAME_DEFAULT_NONE, GEN_SFRAME_CONFIG_ENABLED,
GEN_SFRAME_DISABLED, GEN_SFRAME_ENABLED)

gas/
PR gas/33175
* dw2gencfi.c (cfi_finish): Check state of flag_gen_sframe to
determine whether any SFrame section is generated.
* as.h (enum gen_sframe_option): New definition.
* as.c (parse_args): Keep track of whether the flag is
explicitly enabled or disabled

gas/testsuite/
PR gas/33175
* gas/cfi-sframe/cfi-sframe-common-1.d: Remove redundant
--gsframe.
* gas/cfi-sframe/cfi-sframe.exp:  Add new test.
* gas/cfi-sframe/cfi-sframe-common-1c.d: New test.  No SFrame
section if explicit --gsframe=no.
* gas/cfi-sframe/cfi-sframe-common-1c.s: New test.

readelf: objdump: sframe: fix dumping with section name

Fix PR binutils/33186 - No SFrame dump if section name is not .sframe

When the section name is not ".sframe", ensure that readelf and objdump
are able to dump a section of type SHT_GNU_SFRAME and not fail if the
user specifies the new section name.

For objdump, in dump_dwarf_section (), use the match string of ".sframe"
to find the corresponding debug_displays[] item for SFrame section.
Doing this ensures that any call to dump_dwarf_section () with the
section pointing to the SFrame section (with name possibly different
from ".sframe") will successfully dump the SFrame section.

If the SFrame section is named anything but ".sframe", and user does not
specify the name of the SFrame section either, the documented behaviour
is that the default section name is assumed to be ".sframe".  So the
following (albeit counter intuitive) is expected at this time:

$ readelf -S sort | grep sframe
  [NN] .sframe2          GNU_SFRAME       0000000000NNNNNN  0000NNNN

(Note section name .sframe2).

$ objdump --sframe sort

sort:     file format elf64-x86-64

No .sframe section present

(Similarly for readelf as well).

For objdump, set dump_sframe_section_name to ".sframe" if user specifies
no section name.  In the error checking done in dump_sframe_section, add
the case when user specifies a valid section name but one that does not
contain SFrame section data.  For sections generated with Binutils >=
2.45, this can be checked with section type of SHT_GNU_SFRAME.
Previously these sections were SHT_PROGBITS with name ".sframe".

Similar changes in readelf.

Add a test each for objdump and readelf to dump a renamed section.  Use
gas_sframe_check to limit the execution of these tests only when a gas
supporting SFrame format is present.

binutils/
PR binutils/33186
* objdump.c (dump_dwarf_section): Set match to ".sframe" which
corresponds to the name in the debug_displays[] entry for
SFrame section.
(dump_sframe_section): Check if the user specified section name
contains SFrame data.
(main): Set default section name to ".sframe".
* readelf.c (display_debug_section): Adjust checks to find the
debug_diplays[] item for the input arg SFrame section.
Use id instead of i, as it is more readable.

binutils/testsuite/
PR binutils/33186
* binutils-all/x86-64/objdump-sframe-01.d: New test.
* binutils-all/x86-64/readelf-sframe-01.d: New test.
* binutils-all/x86-64/sframe-func.s: New test.

ld: Force SHELL=/bin/bash in ld for Solaris [PR32580]

As described in PR ld/32580, when using SHELL=/bin/sh or /bin/ksh on
Solaris, the generated linker scripts get corrupted.  So far, the only
workaround is to enforce /bin/bash instead.

This is a major nuisance for developers and users alike, so this patch
automates this by overriding SHELL in ld/configure.ac.

Tested on amd64-pc-solaris2.11 in three configurations:

* CONFIG_SHELL unset

* CONFIG_SHELL=/bin/ksh

* CONFIG_SHELL='/bin/bash --norc'

In the first two cases, SHELL was set to /bin/bash as desired, while in
the third it was left unchanged.

2025-07-24  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

ld:
PR ld/32580
* configure.ac <*-*-solaris2*>: Enforce SHELL=/bin/bash.
* configure: Regenerate.

PR 33210 NULL pointer arithmetic in coffcode.h

Fix ubsan "runtime error: applying zero offset to null pointer".

Automatic date update in version.in

strip: Properly handle LLVM IR bitcode

commit 717a38e9a02109fcbcb18bb2ec3aa251e2ad0a0d
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Sun May 4 05:12:46 2025 +0800

    strip: Add GCC LTO IR support

added "-R .gnu.lto_.*" to strip to remove all GCC LTO sections.  When
"-R .gnu.lto_.*" is used, the plugin target is ignored so that all LTO
sections are stripped as the regular sections.  It works for the slim
GCC LTO IR since the GCC LTO IR is stored in the regular sections.  When
the plugin target is ignored, the GCC LTO IR can be recognized as the
normal object files.  But it doesn't work for the slim LLVM IR which
is stored in a standalone file.

1. Add bfd_check_format_matches_lto and bfd_check_format_lto to take an
argument, lto_sections_removed, to indicate if all LTO sections should
be removed.
2. Update strip to always enable the plugin target so that the plugin
target is enabled when checking for bfd_archive.
3. Update strip to ignore the plugin target for bfd_object when all LTO
sections should be removed.  If the object is unknown, copy it as an
unknown file without any messages.
4. Treat the "-R .llvm.lto" strip option as removing all LTO sections.

bfd/

PR binutils/33198
* format.c (bfd_check_format_lto): New function.
(bfd_check_format): Call bfd_check_format_matches_lto.
(bfd_check_format_matches): Renamed to ...
(bfd_check_format_matches_lto): This.  Add an argument,
lto_sections_removed, to indicate if all LTO sections should be
removed and don't match the plugin target if lto_sections_removed
is true.
(bfd_check_format_matches): Call bfd_check_format_matches_lto.
* bfd-in2.h: Regenerated.

binutils/

PR binutils/33198
* objcopy.c (copy_archive): Call bfd_check_format_lto, instead
of bfd_check_format, and pass lto_sections_removed.  Remove the
non-fatal message on unknown element since it will be copied as
an unknown file.
(copy_file): Don't check lto_sections_removed when enabling LTO
plugin in strip.
(copy_file): Ignore the plugin target first if all LTO sections
should be removed.  Try with the plugin target next if ignoring
the plugin target failed to match the format.
(strip_main): Also set lto_sections_removed for -R .llvm.lto.
* testsuite/binutils-all/x86-64/pr33198.c: New file.
* testsuite/binutils-all/x86-64/x86-64.exp (run_pr33198_test):
New.
Run binutils/33198 tests.
* testsuite/lib/binutils-common.exp (llvm_plug_opt): New.
(CLANG_FOR_TARGET): New.  Set to "clang" for native build if
"clang -v" reports "clang version".

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

[gdb/testsuite] Add Term::get_string_with_attrs in tuiterm

While reading a gdb.log for test-case gdb.tui/main-2.exp, I noticed that this
line was somewhat hard to read:
...
screen line 6: '<fg:cyan><intensity:bold>|<fg:default><intensity:normal>B+>    21 <reverse:1>  return 0;<reverse:0>                                                         <fg:cyan><intensity:bold>|<fg:default><intensity:normal>'
...
because of the border attributes.

Then I realized that the test-case is only interested in the text between the
borders, so I added a proc Term::get_string_with_attrs that allows me to drop
the borders, getting us instead:
...
screen line 6: 'B+>    21 <reverse:1>  return 0;<reverse:0>                                                         '
...

Tested on aarch64-linux.

[gdb/testsuite] Use TERM=ansiw in tuiterm for bsd

TERM=ansi is different on freebsd and linux.  Consequently, many TUI
test-cases (gdb.tui/*.exp and gdb.python/tui*.exp) fail on freebsd.

One of the problems is that send_gdb "<cmd>\r\n" is needed instead of
send_gdb "<cmd>\n".

This is because gdb_send "layout regs\n" translates to
"layout regs<KEY_DOWN>", which evidently missing the carriage return part.

While we can work around this, there are other problems.  There is no color
support, and the cursor keys fail to scroll the source window.

So I went looking for an alternative to TERM=ansi on freebsd, and came across
TERM=ansiw.  Using this didn't work out of the box, but with the fixes in
this series it now does.

I also briefly looked at TERM=ansis, which is interesting because it's
available on both linux and freebsd, but ansiw is a better choice for now.
I've filed PR33179 to document what I learned, with the aim to eventually
follow up and address two test-case failures with TERM=ansis on linux.

Tested on x86_64-freebsd.

[gdb/testsuite] Log on return in Term::_log_cur

Proc Term::_log_cur logs the cursor update of code in its body argument:
...
    proc _ctl_0x08 {} {
        _log_cur "Backspace" {
            variable _cur_col

            if {$_cur_col > 0} {
                incr _cur_col -1
            }
        }
    }
...
giving us for instance:
...
+++ Backspace, cursor: (2, 0) -> (2, 0)
...

But if we rewrite the code to use a return:
...
    if { $_cur_col == 0 } {
return
    }
    incr _cur_col -1
...
and the return is triggered, the log message disappears.

Fix this by wrapping the "uplevel $body" in a catch:
...
- uplevel $body
+ set code [catch {uplevel $body} result]
...

Tested on aarch64-linux.

Automatic date update in version.in

gold: configury: fix obsolete macros

Running `autoreconf -vf -Wall' in the gold directory shows errors about the use
of obsolete macros.  This patch fix the issues with macros used directly by
configure.ac. However, it doesn't fix all warnings.  There are autoconf warnings
about macros from files in config and one automake warning about a target being
shadowed.  It cuts a lot of the noise down and makes an upgrade to autoconf
2.71+ easier.

https://www.gnu.org/software/automake/manual/1.12.2/html_node/Obsolete-Macros.html#index-AM_005fCONFIG_005fHEADER
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Obsolete-Macros.html#index-AC_005fOUTPUT-2133

gold/ChangeLog:

* aclocal.m4: Regenerate.
* configure: Regenerate.
* configure.ac: Replace AM_CONFIG_HEADER by AC_CONFIG_HEADERS. Replace
        AC_OUTPUT(file list) by AC_CONFIG_FILES([file list])\nAC_OUTPUT.

Approved-by: Alan Modra <amodra@gmail.com>

[gdb/testsuite] Fix Term::_csi_m with no args

When calling Term::_csi_m with no args, default behaviour needs to be applied,
which is equivalent to "Term::_csi_m 0" [1].

However, while "Term::_csi_m 0" works, as well as 'Term::_csi_m ""', calling
Term::_csi_m with no args has no effect.

Fix this by implementing the default behaviour in Term::_csi_m.

Tested on aarch64-linux.

Approved-By: Tom Tromey <tom@tromey.com>
[1] https://vt100.net/docs/vt510-rm/SGR.html

[gdb/testsuite] Handle auto_left_margin in tuiterm

The terminal capability bw (aka as auto_left_margin) controls whether a
backspace at the start of a line wraps to the last column of the previous
line.

For tuiterm, we use TERM=ansi, and on linux at least that capability is off.

Consequently the current implementation of Term::_ctl_0x08 doesn't wrap.

Add this capability in Term::_ctl_0x08, and add a unit test.

Tested on aarch64-linux.

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

gdbserver: use reference in range for loop

The armhf buildbot fails to build GDB, with:

    ../../binutils-gdb/gdbserver/server.cc: In function ‘void handle_general_set(char*)’:
    ../../binutils-gdb/gdbserver/server.cc:1021:23: error: loop variable ‘<structured bindings>’ creates a copy from type ‘const std::pair<thread_info*, enum_flags<gdb_thread_option> >’ [-Werror=range-loop-construct]
     1021 |       for (const auto [thread, options] : set_options)
          |                       ^~~~~~~~~~~~~~~~~
    ../../binutils-gdb/gdbserver/server.cc:1021:23: note: use reference type to prevent copying
     1021 |       for (const auto [thread, options] : set_options)
          |                       ^~~~~~~~~~~~~~~~~
          |                       &

I did not use a reference on purpose, because the pair is very small.  I
don't see the problem when building on amd64, I presume it is because
the pair is considered too big to copy on a 32-bit architecture, but not
on a 64-bit architecture.

In any case, fix it by adding a reference.

Change-Id: I8e95235d6e53f032361950cf6e0c7d46b082f951

[gdb/testsuite] Handle Horizontal Position Absolute in tuiterm

I ran the tui testsuite on freebsd with TERM=ansiw, and investigated the first
failure, in test-case gdb.tui/tui-init-source.exp.

The problem turned out to be the lack of handling a Horizontal Position
Absolute [1] sequence "^[[80`" in tuiterm.

Add Term::_csi_`, forwarding to Term::_csi_G which handles Cursor Horizontal
Absolute [2].

Tested on x86_64-linux.

Approved-By: Tom Tromey <tom@tromey.com>
[1] https://vt100.net/docs/vt510-rm/HPA.html
[2] https://vt100.net/docs/vt510-rm/CHA.html

[gdb/testsuite] Fix Cursor Horizontal Absolute clipping

I looked at the tuiterm implementation of Cursor Horizontal Absolute:
...
    proc _csi_G {args} {
set arg [_default [lindex $args 0] 1]

_log_cur "Cursor Horizontal Absolute ($arg)" {
    variable _cur_col
    variable _cols

    set _cur_col [expr {min ($arg - 1, $_cols)}]
}
    }
...
and noticed a problem with the clipping behavior.

If we have say $_cols == 80, and we do _csi_G 81 we get $_cur_col == 80, while
$_cur_col is zero-based and should be in the 0..79 range.

Fix this by using:
...
    set _cur_col [expr {min ($arg, $_cols)} - 1]
...
which gets us $_cur_col == 79.

Add two boundary tests to gdb.tui/tuiterm.exp.

Tested on x86_64-linux.

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

gdb, gdbserver: use structured bindings in a few places

I wanted to change one of these, so I searched for more similar
instances, while at it.  I think this looks a bit tidier, over unpacking
the pairs by hand.

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

PR 33197 [AVR] Incorrect syntax in generated ldscript

Rearrange scripttempl/avr.sc to avoid oddities of shells expanding
${RELOCATING+stuff} in here documents where "stuff" contains quoted
strings.  Also I think it is better to avoid multi-line "stuff" as it
can be tricky to spot the ending brace.

libctf: don't run tests requiring deduplicating linker unless one is in use

Before now, we were relying on gcc -B to repoint GCC at our freshly-built
linker, and assuming we could use this to run tests that do linker dedup.

This is, alas, not reliable (building --with-ld=/an/absolute/path bypasses
-B searches for the linker), and we would like the libctf tests in
particular to not fail if the compiler uses a linker that cannot deduplicate
(simply skipping such tests).

Add a new testsuite function that tries to link one of the lookup tests'
testcases (which is known to produce conflicting types, i.e. a dict with
per-translation-unit children) and then does an objdump and greps it for
signs of the per-translation-unit children.  If there are none, the linker
probably just concatenated the sections: i.e., it is not a linker that
can deduplicate CTF.

libctf/
PR libctf/33162
* testsuite/config/default.exp (objdump): Introduce.
(OBJDUMPFLAGS): Likewise.
* testsuite/lib/ctf-lib.exp (check_ctf_linker_dedup): New.
* testsuite/libctf-lookup/lookup.exp: Use it.
* testsuite/libctf-regression/libctf-repeat-cu.exp: Likewise.
* testsuite/libctf-regression/regression.exp: Likewise.

libctf: exclude always-emitted Solaris symbols from the symtypetab

If we're skipping _BEGIN_ and _END_ we should certainly skip all the other
ABI-required always-emitted symbols given in ld/emultempl/solaris2*em as
well.  (This fixes a couple of diagnostics tests, but that's just because
the tests are quite sensitive to CTF section sizes, and introducing any
symtypetab entries for those tests perturbs those.)

Some of these are usually STT_NOTYPE, but not always: if programs already
emitted the symbol they might end up with any type, in particular
STT_OBJECT, and appear in the symtypetabs.

[nca: added commit log, added more symbols]

libctf/
PR libctf/33162
* ctf-serialize.c (ctf_symtab_skippable): Skip
more always-emitted Solaris symbols.

libctf: get libctf-nobfd.ver from the right place with Solaris ld

We generate de-commented version scripts for Solaris ld (whose
-z gnu-version-script linker option does not support comments),
but after we switched to generating libctf-nobfd.ver itself, we
failed to adjust this code to pick it up from the new location.

libctf/
PR libctf/33161
* configure.ac: Fix libctf-nobfd.ver path on Solaris.
* configure: Regenerated.

libctf: do not use mmap on Solaris 11

Writable mmaps and read are inconsistent with each other on Solaris 11.4,
which breaks archive writing.  Simply assert that Solaris 2.11 doesn't have
mmap, falling back to read(): the archive format is being bumped shortly, to
one with completely different writeout code, so this workaround need not
stay for long.

[nca: added commit log]

libctf/
PR libctf/29292
* configure.ac: Turn off mmap on Solaris 2.11.
* configure: Regenerated.

gas: sframe: fix PR gas/33170

SFrame generation code assumes that since DW_CFA_restore means
restoration of the state of the register to the one at the beginning of
the function, there must be a state to restore to (hence the gas_assert
(cie_fre)).

This assumption needs adjustment.  DW_CFA_restore may be present in the
very beginning of a (e.g., cold) function, with no initialized state for
SFrame functions to restore to.

gas/
PR gas/33170
* gas/gen-sframe.c (sframe_xlate_do_restore): Use current FRE if
CIE FRE is not yet setup.
gas/testsuite/
PR gas/33170
* gas/cfi-sframe/cfi-sframe.exp: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-pr33170.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-pr33170.s: New test.

Automatic date update in version.in

[gdb/testsuite] Modernize gdb.base/command-line-input.exp

Modernize test-case gdb.base/command-line-input.exp using clean_restart,
multi_line and string_to_regexp.

Tested on x86_64-linux.

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

[gdb/cli] Clear line buffer on ^C

Gdb has the ability to gather input over several lines [1], for instance this:
...
(gdb) print 1
$1 = 1
(gdb)
...
can also be typed as:
...
(gdb) print\
 1
$2 = 1
(gdb)
...

Furthermore, if we type a command but change our mind, we can abort using ^C
and start over using a fresh gdb prompt [2]:
...
(gdb) print 1❌️ Quit
(gdb) echo 1\n
1
(gdb)
...

Now say we type a multi-line command but abort it, we get:
...
(gdb) print\
 1❌️ Quit
(gdb) echo 1\n
❌️ Undefined command: "printecho".  Try "help".
(gdb)
...

Using "set trace-commands on", we can see what happened:
...
+printecho 1\n
..

Gdb has prepended the first line of the cancelled multi-line command to the
following command.

Fix this by clearing current_ui->line_buffer on catching a gdb_exception in
start_event_loop.

Tested on x86_64-linux.

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

[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Output.html
[2] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Quitting-GDB.html

gdb: Remove redundant parameter for filename completion

As I was working on an unrelated patch, I noticed that all calls to
make_source_files_completion_list had both parameters of the function
call being the same pointer.  I think we can remove that redundancy and
make that call with just one parameter.

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

gdb/solib-svr4: fix indent

Change-Id: I63f78f359f55ec15fb3296a1a9ce28c9d01d663b

gdb: use skip_spaces in info_linker_namespace_command

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

gdb: fix formatting in solib.c

I found these two small nits while working in this file.

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

Updated translations for various sub-directories

Remove steps for adding .dirstamp when creating pre-release tarball

ld: Rename a file on Windows fails if target already exists

To rename a file on Windows, the target name cannot exist. Removing file
prior to renaming ensures this is handled.
To remove a file on Windows, the file cannot be open. Closing the bfd
handle ensures this is handled.
Moved call to free on isympp / osympp to after bfd is closed to align
with comment earlier in the cmdline_add_object_only_section function.

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

Fix failing test: i386-avx-reverse

Running the standalone test `gdb.reverse` with the target board configuration `unix/-fPIE/-pie` leads to the following failure:
'''
FAIL: gdb.reverse/i386-avx-reverse.exp: verify ymm15 before vbroadcastsd
'''

This happens because the test expects values stored in `dyn_buf0`, but instead (in the test source) the address of the buffer itself
got broadcast to xmm15 (and thus to ymm15).
This happened because the pointer to the start of `dyn_buf0` wasn't dereferenced (see 'vpbroadcast_test' in 'i386-avx-reverse.c'):
'''
asm volatile ("vbroadcastss %0, %%xmm15": : "m" (dyn_buf0));
 ^
'''
and this consequently lead to the test failing for the next instruction (`vbroadcastsd`), which depended on the correct value being broadcast to the register.

Also, updated the corresponding expected output (gdb.reverse/i386-avx-reverse.exp) to match.

Tested on x86-64 Linux.

Signed-off-by: Shiven Kashyap <shivenkashyap24@gmail.com>
Approved-By: Guinevere Larsen <guinevere@redhat.com>