Automatic date update in version.in

gas: sframe: reset fp_reg to SFRAME_FRE_REG_INVALID

It makes sense to keep all internal state related to registers
(cfa_base_reg, fp_reg) reset to SFRAME_FRE_REG_INVALID.

While at it, also make sure fp_reg state is copied over when intializing
an SFrame FRE.

gas/
* gen-sframe.c (sframe_row_entry_new): Reset to
SFRAME_FRE_REG_INVALID.
(sframe_row_entry_initialize): Copy over fp_reg too.
(sframe_xlate_do_offset): Adjust accordingly.

gas: sframe: rename "bp" to "fp"

Reviewed-by: Jens Remus <jremus@linux.ibm.com>

libsframe: refactor out sframe_fre_grow_tbl

Usage of a global int number_of_entries is likely unnecessary.  The same
global is used for growing the FDE tbl too, when adding FDEs.  At the
moment, however, carve out a new function to grow the FRE table, and
use a macro instead of 'number_of_entries'.

This refactoring helps provide basis for a later patch where we add
SFrame FREs in bulk instead of one at a time to the SFrame encoder
object.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>
libsframe/
* sframe.c (SFRAME_FRE_ALLOC_LEN): New definition.
(sframe_grow_fre_tbl): New definition.
(sframe_encoder_add_fre): Use the new function.

libsframe: use tmp variable for realloc pattern

If realloc fails, the original buffer isnt free'd otherwise.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>
libsframe/
* sframe.c (sframe_encoder_add_fre): Use tmp variable.
(sframe_encoder_add_funcdesc_internal): Likewise.

libsframe: refactor sframe_decoder_add_funcdesc for internal use

sframe_encoder_add_funcdesc () was added for SFRAME_VERSION_1.  This has
since been obsoleted by introduction of SFRAME_VERSION_2 and its
corresponding sframe_decoder_add_funcdesc_v2 API.

Refactor the functionality into an internal-only API:
sframe_encoder_add_funcdesc_internal (). Ensure it returns the error
code for the caller to take necessary action or pass to user.

Keep only two args for sframe_encoder_add_funcdesc: function size and
function start addr.  This simple barebone API will be used in a
subsequent commit to adjust the link-time behaviour of SFrame sections.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>
include/
* sframe-api.h (sframe_encoder_add_funcdesc): Remove args to
create the barebone API.
libsframe/
* sframe.c (sframe_encoder_add_funcdesc): Refactor out into
sframe_encoder_add_funcdesc_internal.  Change args.
(sframe_encoder_add_funcdesc_v2): Use the new internal API.
* libsframe.ver: Move sframe_encoder_add_funcdesc to 2.1 node.

gas: sframe: refactor out the offsets emission code

Minor refactoring.  Carve out the SFrame FRE offsets emission code into
a new output_sframe_row_entry_offsets ().  This change helps prepare for
later supporting a new FDE type in SFrame V3.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>
gas/
* gen-sframe.c (output_sframe_row_entry_offsets): New
definition.
(output_sframe_row_entry): Use the new definition.

gas: sframe: pass SFrame FDE as argument to output_sframe_row_entry

Minor refactoring.  Will be needed later for supporting flexible topmost
frames in SFrame V3.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>
gas/
* gen-sframe.c (output_sframe_row_entry): Use new argument.
(output_sframe_internal): Likewise.

gas: sframe: add new sframe_xlate_ctx_get_cur_cfa_reg

Purely cosmetic change.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>
gas/
* gen-sframe.c (sframe_xlate_ctx_get_cur_cfa_reg): New
definition.
(sframe_xlate_do_def_cfa_offset): Use it.
(sframe_xlate_do_escape_expr): Likewise.
(sframe_xlate_do_escape_gnu_args_size): Likewise.

gas: libsframe: use SFRAME_V2_* macro where available

No functional change.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>
gas/
* sframe-opt.c (sframe_convert_frag): Use SFRAME_V2_
prefixed macro instead.
libsframe/
* sframe-dump.c (dump_sframe_func_with_fres): Likewise.
* sframe.c (sframe_get_fre_type): Likewise.
(sframe_get_fde_type): Likewise.
(sframe_fre_check_range_p): Likewise.
(sframe_fde_create_func_info): Likewise.

include: sframe: add SFRAME_V2_ prefixed macro names for FDE

Such a change for readability only.  SFrame V1 is now obsolete, and with
newer versions like V3 or later, its likely better to have macro names
reflect the applicable version.

Add new macro names for FDE information related macros.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>
include/
* sframe.h (SFRAME_V2_FUNC_INFO): New definition.
(SFRAME_V2_FUNC_FRE_TYPE): Likewise.
(SFRAME_V2_FUNC_PC_TYPE): Likewise.
(SFRAME_V2_FUNC_PAUTH_KEY): Likewise.
(SFRAME_V2_FUNC_INFO_UPDATE_PAUTH_KEY): Likewise.

libsframe: implement an internal-only SFrame FDE representation

Up until now, libsframe has used the same SFrame FDE representation as
the on-disk representation (sframe_func_desc_entry).  The choice made by
the author of the library, back when it was first contributed, perhaps
sufficed the needs then.  But looking forward, we need to be able to
allow reading and dumping out of not just sections with version
SFRAME_VERSION_2 but also future supported versions.

Note that libsframe did not (and still does not) expose the SFrame FDE
representation in any public APIs;  doing so is not recommended.

For the path forward, create an internal-only SFrame FDE representation
(sframe_func_desc_entry_int).  libsframe now keeps all in-memory FDEs of
type sframe_func_desc_entry_int.  Doing so means instead of memcpy, we
need to resort to member-by-member mapping.  This can be seen in
sframe_fde_tbl_init (read time) and the new function
sframe_encoder_write_fde (write time).

Other than that, replace out the previous direct interaction with
on-disk format when:
  - flipping SFrame contents before decoding them in sframe_decode.
  - flipping SFrame contents before writing them out in sframe_encode.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>

Automatic date update in version.in

include: gas: bfd: sframe: clean the abstraction

... between specification and implmentation.

Move to definition in the implementation (gas/ld/libsframe) and not the
specification (include/sframe.h).  At this time the implementation in
gas and ld generate the sections in the latest SFrame version only.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>
bfd/
* elf-sframe.c: Add definition here.
gas/
* gen-sframe.c: Likewise.
libsframe/
* sframe.c: Likewise.
include/
* sframe.h: Remove the definition.

gas: sframe: ignore .cfi_offset for RA selectively

For ABIs not tracking RA (e.g., AMD64), the return address is expected
to be in a specific location (usually a fixed offset from CFA on stack).
Explicit manourvering to a different offset may be non-representable in
SFrame, and should not be simply ignored.

Although such patterns are not usually seen in the wild, it is more
correct to catch them if at all they manifest.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>
gas/
* gen-sframe.c (sframe_xlate_do_offset): Do not ignore
.cfi_offset for RA all the time.

Revert "gas: Don't skip SFrame FDE if .cfi_register specifies RA w/o tracking"

This reverts commit df174a6b760.

    commit df174a6b760ac5c66ee62ecb872c760ae21fd4cd
    Date:   Thu Jul 4 10:34:12 2024 +0200

    gas: Don't skip SFrame FDE if .cfi_register specifies RA w/o tracking

    Do not skip SFrame FDE if .cfi_register specifies RA register without
    RA tracking being actually used. Without RA tracking the register
    contents can always be restored from the stack using the fixed
    RA offset from CFA.

Even for ABI/arch without RA tracking, there may be instances where user
may specify '.cfi_register RA, reg'.  This needs to be caught, skipping
this from SFrame generation may not be correct.  This may be done in
certain hand-written asm sequences where the user needs to manipulate
the return to a certain function.

No testcase is being added ATM because in SFrame V3, a new FDE type can
be used to represent such cases (A new test case will be added then).

Reviewed-by: Jens Remus <jremus@linux.ibm.com>

gas: add as_info() for informational diagnostics

This patch adds as_info(), a shortened version of as_info_where(),
for emitting informational diagnostics from Gas.
This new helper provides the same formatting and source location
handling as as_info_where(), while offering a simpler interface
for the common case. It respects the --no-info flag, and supports
indentation in the same way as its sibling.

gdb: allow 'set args' and run commands to contain newlines

When starting GDB it is possible to set an inferior argument that
contains a newline, for example:

  shell> gdb --args my.app "abc
  > def"
  ...
  (gdb) show args
  Argument list to give program being debugged when it is started is "abc'
  'def".

However, once GDB is started, the only way to install an argument
containing a newline is to use the Python API.

This commit changes that.

After this commit 'set args' as well as 'run', 'start', and 'starti',
will now accept multi-line inferior arguments, e.g.:

  (gdb) set args "abc
  > def"
  (gdb) show args
  Argument list to give program being debugged when it is started is ""abc
  def"".

And also:

  (gdb) run "abc
  > def"
  ... etc ...

Once GDB has presented the secondary prompt to gather the remaining
inferior arguments then it is possible for the user to quit argument
entry by sending SIGINT (usually, Ctrl-c), or sending EOF (usually,
Ctrl-d).  For the 'set args' case this will abort the argument change,
leaving the arguments as they were previously.  For the run style
commands, this aborts the run command completely, the inferior is not
changed, and the partially collected arguments are not installed.

On Unix hosts, arguments can be wrapped with either single or double
quotes, while on MS-Windows hosts, arguments can only be wrapped with
double quotes.  This gives the expected behaviour when native
debugging, but isn't entirely accurate.  If a user is cross debugging
between Unix and MS-Windows then the host machine will determine which
set of quotes is valid, which will then be incorrect for the actual
target machine.  This should probably be fixed in the future, but
isn't something I plan to fix immediately.  If this patch is accepted,
then I can create a bug to track this issue.

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

loongarch: add back support for object attributes v1

A previous commit [1] mistakenly removed support for Object Attributes
for LoongArch targets.

This patch adds back the OA feature into Gas for the LoongArch targets
following the new approach which consists in:
- defining TC_OBJ_ATTR to 1 in tc-loongarch.h
- enabling the compilation of obj-elf-attr.c in gas/configure.ac

[1]: 28a51085ae59fdb530fbdce1e2a7d160667e3007

Automatic date update in version.in

Use gdb_bfd_sections in more places

I found a few spots still iterating over sections using "->next", and
thought it would be a little cleaner to use gdb_bfd_sections instead.
In one spot the loop indentation turned out to be wrong as well.

Remove rust_parser::get_string

Now that struct stoken has been replaced with string_view,
rust_parser::get_string doesn't provide much value.  In some places it
can even be replaced with a direct use of the string_view.

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

Don't use stoken in rust-parse.c

I wanted to change rust-parse.c to use string_view and not stoken.
This was simple enough, but it seemed good to also change
parser_state::push_dollar to use string_view; and as it turned out,
this simplified the code a little.

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

Use string_view in user_reg_map_name_to_regnum

This changes user_reg_map_name_to_regnum to use std::string_view.
This pointed out some dead code in that function: the "len < 0" test
in the loop can never be true, because earlier code changes 'len' in
this case.

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

Fix --help output

In commit 9e69a2e127940cc5, which introduced "command" styling, I
accidentally made gdb's --help output mention the "stream" command,
rather than the "help" command.

While doing this I also found a spot where --help output was
incorrectly formatted.  This patch fixes this as well.

I'm going to backport this to the gdb-17 branch as well.

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

gdb/reverse: force direction to forward when stopping record

If a user had set the execution direction to reverse, and then they use
the command "record stop", the execution direction will be cached as
reversed, which will affect some warning messages, and can confuse
users.

This commit fixes this by forcing the execution direction to "forward"
when the command "record stop" is executed.

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

Fix crash when breakpoint condition causes inferior exit

When using a breakpoint condition that causes an inferior exit, gdb
crashes with a null pointer access:

(gdb) b main if callexit()
Breakpoint 1 at 0x114b: file callexit.c, line 32.
(gdb) r
Starting program: /home/src/lappy/binutils-gdb.git/gdb/testsuite/gdb.base/callexit
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
[Inferior 1 (process 218586) exited normally]
../../gdb/infcall.c:895:50: runtime error: member call on null pointer of type 'struct thread_fsm'
../../gdb/infcall.c:895:50: runtime error: member access within null pointer of type 'struct thread_fsm'

Fix this by checking the thread_fsm pointer beforehand, now the result
looks like this:

(gdb) b main if callexit()
Breakpoint 1 at 0x114b: file callexit.c, line 32.
(gdb) r
Starting program: /home/src/lappy/binutils-gdb.git/gdb/testsuite/gdb.base/callexit
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
[Inferior 1 (process 220707) exited normally]
❌ Error in testing condition for breakpoint 1:
The program being debugged exited while in a function called from GDB.
Evaluation of the expression containing the function
(callexit) will be abandoned.
❌ No registers.
(gdb)

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

Fix crash if breakpoint commands contain detach or kill

If breakpoint commands contain detach or kill, then gdb tries to access
freed memory:

(gdb) b main
Breakpoint 1 at 0x111d: file main.c, line 21.
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>detach
>end
(gdb) run
Starting program: /home/src/lappy/binutils-gdb.git/gdb/testsuite/gdb.base/main
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".

main () at main.c:21
21        return 0;
[Inferior 1 (process 241852) detached]
=================================================================
==241817==ERROR: AddressSanitizer: heap-use-after-free on address 0x7b7a3de0b760 at pc 0x55fcb92613fe bp 0x7ffec2d524f0 sp 0x7ffec2d524e0
READ of size 8 at 0x7b7a3de0b760 thread T0
    #0 0x55fcb92613fd in bpstat_do_actions_1 ../../gdb/breakpoint.c:4898
    #1 0x55fcb92617da in bpstat_do_actions() ../../gdb/breakpoint.c:5012
    #2 0x55fcba3180e7 in inferior_event_handler(inferior_event_type) ../../gdb/inf-loop.c:71
    #3 0x55fcba3ba1e1 in fetch_inferior_event() ../../gdb/infrun.c:4769

0x7b7a3de0b760 is located 0 bytes inside of 56-byte region [0x7b7a3de0b760,0x7b7a3de0b798)
freed by thread T0 here:
    #0 0x7f1a43522a2d in operator delete(void*, unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:155
    #1 0x55fcb925d5cd in bpstat_clear(bpstat**) ../../gdb/breakpoint.c:4646
    #2 0x55fcbb69ea6a in clear_thread_inferior_resources ../../gdb/thread.c:185
    #3 0x55fcbb69f4cb in set_thread_exited(thread_info*, std::optional<unsigned long>, bool) ../../gdb/thread.c:244
    #4 0x55fcba368d64 in operator() ../../gdb/inferior.c:269
    #5 0x55fcba375e2b in clear_and_dispose<inferior::clear_thread_list()::<lambda(thread_info*)> > ../../gdb/../gdbsupport/intrusive_list.h:529
    #6 0x55fcba368f19 in inferior::clear_thread_list() ../../gdb/inferior.c:265
    #7 0x55fcba3694ba in exit_inferior(inferior*) ../../gdb/inferior.c:322
    #8 0x55fcba369e35 in detach_inferior(inferior*) ../../gdb/inferior.c:358
    #9 0x55fcba319d9f in inf_ptrace_target::detach_success(inferior*) ../../gdb/inf-ptrace.c:214
    #10 0x55fcba56a2f6 in linux_nat_target::detach(inferior*, int) ../../gdb/linux-nat.c:1582
    #11 0x55fcba62121c in thread_db_target::detach(inferior*, int) ../../gdb/linux-thread-db.c:1381
    #12 0x55fcbb5ca49e in target_detach(inferior*, int) ../../gdb/target.c:2557
    #13 0x55fcba356ba4 in detach_command(char const*, int) ../../gdb/infcmd.c:2894
    #14 0x55fcb9597eea in do_simple_func ../../gdb/cli/cli-decode.c:94
    #15 0x55fcb95b10b5 in cmd_func(cmd_list_element*, char const*, int) ../../gdb/cli/cli-decode.c:2831
    #16 0x55fcbb6f5282 in execute_command(char const*, int) ../../gdb/top.c:563
    #17 0x55fcb95eedb9 in execute_control_command_1 ../../gdb/cli/cli-script.c:526
    #18 0x55fcb95f04dd in execute_control_command(command_line*, int) ../../gdb/cli/cli-script.c:702
    #19 0x55fcb9261175 in bpstat_do_actions_1 ../../gdb/breakpoint.c:4940
    #20 0x55fcb92617da in bpstat_do_actions() ../../gdb/breakpoint.c:5012
    #21 0x55fcba3180e7 in inferior_event_handler(inferior_event_type) ../../gdb/inf-loop.c:71
    #22 0x55fcba3ba1e1 in fetch_inferior_event() ../../gdb/infrun.c:4769

previously allocated by thread T0 here:
    #0 0x7f1a435218cd in operator new(unsigned long) /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:86
    #1 0x55fcb927061f in build_bpstat_chain(address_space const*, unsigned long, target_waitstatus const&) ../../gdb/breakpoint.c:5880
    #2 0x55fcba3d63b6 in handle_signal_stop ../../gdb/infrun.c:7083
    #3 0x55fcba3d01c7 in handle_inferior_event ../../gdb/infrun.c:6574
    #4 0x55fcba3b9918 in fetch_inferior_event() ../../gdb/infrun.c:4713

This checks after executing commands of each breakpoint if the bpstat
was deleted already, and stops any further processing immediately.
Now the result looks like this:

(gdb) b main
Breakpoint 1 at 0x111d: file main.c, line 21.
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>detach
>end
(gdb) run
Starting program: /home/src/lappy/binutils-gdb.git/gdb/testsuite/gdb.base/main
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".

main () at main.c:21
21        return 0;
[Inferior 1 (process 242940) detached]
(gdb)

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

gas: stub out sframe-opt.c functions when SFrame is not supported

Much like everything in gen-sframe.c, these functions are supposed to
never be reached when SFrame isn't supported by a target. Adding
respective assertions reduces code size for such targets, while at the
same time adding consistency checking for targets which optionally
support the feature.

gas/x86: reduce / correct target checks for --64 command line option

First, pei-x86-64 is meaningless for gas; it's a linker output target, not
one object files would use. Next, coff-x86-64 is meaningless for TE_PE
(and really coff-x86-64 isn't currently provided by any libbfd
configuration anyway). Then, of the three ones left exactly one is a
possible candidate for a given gas configuration. Checking others as well
would only lead to (possibly cryptic) errors later. And finally, even for
ELF we want to check for the one target which i386_target_format() would
also use. This last aspect then applies to --x32 handling as well (just
that there it's benign right now, as only one target exists starting
"elf32-x86-64".

gas/CFI: fix .cfi_escape parsing when equates are in use

The restoring of the line pointer needs to happen in more cases.

While there also adjust a slightly misleading comment.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>

Automatic date update in version.in

Automatic date update in version.in

Add back non-solaris ELF targets to solaris config

This reverses some of the changes made in config.bfd for PR 27666.
Removing targets for that PR was really just a workaround, and since
the underlying bug is now fixed they can be added back.

I chose to add the non-solaris ELF targets to the linker config using
targ_extra_emuls rather than targ_extra_libpath because someone using
the elf32_sparc emulation probably doesn't want to pick up solaris
libraries by accident.

PR 33374
bfd/
* config.bfd: Remove pr27666 comments.  Add back non-solaris
ELF targets to selvecs for solaris targets.
ld/
* configure.tgt: Adjust solaris targets to suit config.bfd
change.

libsframe: testsuite: fix build failure

Previous commit 4651bea1193 to fix PR ld/32789 missed making the
necessary changes to the libsframe testsuite.

libsframe/testsuite/
PR ld/32789
PR libsframe/33731
* libsframe.encode/encode-1.c: Add additional arg for sorting
FDEs.  Set to true.
* libsframe.find/findfre-1.c: Likewise.
* libsframe.find/findfunc-1.c: Likewise.
* libsframe.find/plt-findfre-1.c: Likewise.
* libsframe.find/plt-findfre-2.c: Likewise.

bfd: include: sframe: fix PR ld/32789

Currently, when SFrame sections are emitted after linking the input
SFrame sections, the SFrame FDEs are sorted on start PC.  Doing so for
relocatable links has no effect (SFrame FDEs remain in place), because
the start PC is unrelocated data.  For relocatable links, then, the
emitted SFrame FDEs in the output section remain in the same order as
that in the respective input BFD.

The assembler does not guarantee the emission of SFrame FDEs in the same
order as the placement of the associated .text* sections,
(SFRAME_F_FDE_SORTED is not set in the ET_REL objs generated by GAS).
This means setting SFRAME_F_FDE_SORTED by the linker was wrong when:
  - doing relocatable link, and
  - the input bfds contain multiple .text sections, say .text.hot,
    .text.init, .text.unlikely etc.

For relocatable links, skip sorting the SFrame FDEs.  Do not set
SFRAME_F_FDE_SORTED for relocatable links.

This is achieved by adding an explicit argument (bool sort_fde_p) to the
sframe_encoder_write API.  Move the API from 2.0 to the 2.1 node as this
is an ABI-incompatible change.  Skip bumping the "current" in
libsframe/libtool-version ATM, we will do so closer to release.

When writing of SFrame data for PLT entries, indicate sort_fde_p to
false: these sections are like the other SFrame sections for any other
ET_REL binary.

Add a test in ld/testsuite/ld-sframe/sframe.exp, these tests are run for
all ABIs supported for SFrame.  In this test, for object file generated
for pr32789-1a.c:
  - the emitted SFrame FDEs by GAS are in the order of the .text* in the
    input assembly (i.e., .text.init, .text, .text.exit)
  - the emitted .text* sections by GAS are placed in the following order
    .text, .text.init, .text.exit.
  - GAS does not set SFRAME_F_FDE_SORTED, as expected.

Reviewed-by: Jens Remus <jremus@linux.ibm.com>
bfd/
PR ld/32789
* elf-sframe.c (_bfd_elf_write_section_sframe): Skip sorting the
SFrame FDEs for relocatable links.
* elf64-s390.c (_bfd_s390_elf_write_sframe_plt): Additional
argument to sframe_encoder_write.
* elfxx-x86.c (_bfd_x86_elf_write_sframe_plt): Likewise.
libsframe/
* libsframe.ver: Move from 2.0 node to 2.1.
* sframe.c (sframe_encoder_write_sframe): Conditionalize based
on argument sort_fde_p.
(sframe_encoder_write): New argument to indicate whether SFrame
FDEs are to be sorted in output.
include/
* sframe-api.h (sframe_encoder_write): New argument.
ld/testsuite/
PR ld/32789
* ld/testsuite/ld-sframe/sframe.exp: New test.
* ld/testsuite/ld-sframe/pr32789-1.rd: New test.
* ld/testsuite/ld-sframe/pr32789-1.sd: New test.
* ld/testsuite/ld-sframe/pr32789-1a.c: New test.
* ld/testsuite/ld-sframe/pr32789-1b.c: New test.
* ld/testsuite/ld-x86-64/sframe-reloc-1.d: Remove
SFRAME_F_FDE_SORTED.

ld targ_extra_emuls and targ_extra_libpath

targ_extra_libpath are for those targets other than the default target
that might have libraries available in the default library search
paths.  targ_extra_emuls are for those targets that likely don't.

Sort them so those on the libpath come first.  This currently does not
have any effect except for order of compilation of e*.c and the order
printed in ld help messages, but I thought it worth doing anyway.

* configure.ac (all_emuls): Sort targ_extra_libpath before
targ_extra_emuls.
* configure: Regenerate.

more solaris config tidies

This patch is primarily about making ld and bfd config match for
solaris targets.  In commit 3677b7296185 I made the bfd config match
the ld config, which resulted in PR 27666.  This goes the other way,
changing the ld config to match bfd.  The current mismatch results in
failures like:
..ld-new: target elf32-i386 not found
FAIL: Build libgot-1-i386.so
The problem is that even though the elf32-i386 target is compiled in
to bfd, it is excluded from the list of targets supported by bfd.
ld -V says it is there, but can't use it..

Secondarily, remove "want64" from the 32-bit x86 and sparc solaris
targets in config.bfd, and arrange for ld/configure.tgt to match that
by using targ64_extra_emuls.  This means that on a 32-bit host you
won't get the 64-bit solaris target support by default.  Setting
"want64" forces use of 64-bit bfd_vma on such hosts, which usually
isn't needed for a 32-bit target, and when "want64" is true it is a
little odd to see targ64_selvecs used.  Also, some nonsense has crept
in to ld/configure.tgt regarding targ_extra_libpath.  Any target
mentioned in targ_extra_libpath does not need to be mentioned in
targ_extra_emuls.  So tidy that for solaris.

Finally, matching of solaris targets has been simplified.  This does
not change target triple matching, except with --enable-obsolete.
Without --enable-obsolete, you will still need to specify solaris2.10
or solaris2.11 as the operating system part of the target triple, and
this is expected to become permanent after the next binutils release.

PR 27666
bfd/
* config.bfd: Simplify solaris target matching.  Remove
"want64" from x86 and 32-bit sparc solaris targets.
ld/
* configure.tgt: Remove non-solaris targets from the x86 and
32-bit sparc solaris targets, and use targ64 variables to add
conditional 64-bit targets.  Don't unnecessarily add targets
to targ_extra_emuls that appear in targ_extra_libpatch.
Simplify solaris target matching.

bfd ASSOCIATED_VECS

Tidy code setting ASSOCIATED_VECS, which could be fooled by unusual
configure options such as --enable-targets="srec,all".

* targets.c (_bfd_associated_vector): Remove comma after
ASSOCIATED_VECS.
* configure.ac: Set assocvecs from targ_defvec and
targ_selvecs when handling the target, rather than assuming
those variables are still set for the target when handling
--enable-targets=all.  Move code making assocvecs unique
later.  Do so in a way that need not run sed afterwards, and
leave a trailing comma.
* configure: Regenerate.

PR 27666, bfd_check_format_matches

bfd_check_format_matches should not change what matches depending on
its "matching" arg.  Fix that.  This bug in bfd_check_format_matches
is the underlying cause of pr27666.

PR 27666
* format.c (bfd_check_format_matches): Always allocate
matching_vector.

LoongArch: Add disassembly support for ud ui5

ud ui5, also known as amswap.w rd,$r1,rj(rd==rj), is displayed as
"ud ui5" by default during disassembly. Alternatively, the original
instruction can be printed using the objdump -M no-aliases.

To implement this support, a format specifier "ru0:5,ru5:5" for ud is
applied exclusively during disassembly. This specifier indicates that
registers should be printed using their corresponding numeric values,
and when the instruction is identified as ud, only a single parameter
is displayed.

binutils/

        * testsuite/binutils-all/loongarch64/dis-amswap-ud-noaliases.d:
  New test.
        * testsuite/binutils-all/loongarch64/dis-amswap-ud.d: New test.
        * testsuite/binutils-all/loongarch64/dis-amswap-ud.s: New test.

gas/

        * testsuite/gas/loongarch/macro_ud.d: Update test.

include/

        * opcode/loongarch.h: New macro.

opcodes/

        * loongarch-dis.c (get_loongarch_opcode_by_binfmt): Correct match `ud`.
        (dis_one_arg): Disassemble the `ud` parameter.
        * loongarch-opc.c: Add opcode for "ud" alias.

Automatic date update in version.in

Re: asan: alpha-vms: mmember access within null pointer

Fix commit c01de193638c error.  This in combination with the
vms_lib_bstat error led to an uninitialised stat buf st_size and
intermittent test failures.

* bfdio.c (bfd_get_file_size): Correct brace placement.
* vms-lib.c (vms_lib_bflush): Return -1.

bfin: avoid gcc extension using __VA_ARGS__

We shouldn't be using extensions when we don't have a suitable fallback in
place. For cases where there's no argument wanted, OUTS() already exists.

Add windres to TOOL_PROGS

I sent a patch to GCC adding support for passing .rc and .res files to the
driver directly, allowing support for doing things like:

gcc file.c file.rc -o file.exe

However, binutils doesn't install windres into the tooldir, so by default, gcc
will be unable to find windres. This patch adds windres to TOOL_PROGS so this
can work.

binutils/ChangeLog:

* Makefile.am (TOOL_PROGS): Add windres.
* Makefile.in: Regenerate.

Signed-off-by: Peter Damianov <peter0x44@disroot.org>

bfd: correct dir separator conversion for Win32

Iterating a wchar_t array holding the conversion of multi-byte (likely
UTF-8) input using array indexes from the corresponding char array isn't
going to work as soon as any characters wider than a single char are
present. Simply walk the wchar_t array all by itself.

While looking at that code I also noticed a wrong argument being passed to
a later MultiByteToWideChar() invocation: This needs to be number of
characters, which isn't sizeof() when the array is of wchar_t elements.

MAINTAINERS: move three people to "Past Maintainers"

... for the respective emails bouncing. Thanks to them for their past
work. Sadly this renders KVX and XCOFF unmaintained.

While there also restore alphabetic sorting of the list.

Automatic date update in version.in

Don't use "module" name

In C++20, "module" is an "identifier with special meaning".  While it
can be used as a variable name, it highlights as a keyword in Emacs,
and I think it's nicer to just avoid it.

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

gdb/testsuite: fix tclint errors

After commit:

  commit b5160e2ee6a0192389caf7acee1fc32961ed29f4 (upstream/master, upstream/HEAD, gdb-tmp-g)
  Date:   Fri Jul 26 16:32:33 2024 +0100

      gdb: improve line number lookup around inline functions

the following tclint errors were reported:

  gdb/testsuite/gdb.dwarf2/dw2-inline-bt.exp:211:26: expression with substitutions should be enclosed by braces [unbraced-expr]
  gdb/testsuite/gdb.dwarf2/dw2-inline-bt.exp:212:26: expression with substitutions should be enclosed by braces [unbraced-expr]

Fixed by this commit.

Add Do_Nothing to two more Ada tests

A couple of Ada tests were failing with gnat-llvm, because LLVM is a
bit more aggressive about eliminating unused local variables.  This
patch arranges for some variables to be kept alive a little longer,
using the usual Do_Nothing technique.

binutils-gdb/git: Handle *.ac and *.m4 files in .gitattributes

Since commit 52ca3d3fe61 ("toplevel: unify the GCC and GDB/binutils .editorconfig
files"), .editorconfig has settings for .ac and .m4 files:
...
[*.{ac,m4}]
indent_style = tab
indent_size = 2
trim_trailing_whitespace = true
...

There are no setting for those files in .gitattributes, so the whitespace
attribute defaults to trailing-space (shorthand for blank-at-eol,
blank-at-eof) and space-before-tab.

Since according to .editorconfig the indentation style is tab, add
indent-with-non-tab as well.

Since aclocal.m4 is generated, unset the whitespace attribute.  Likewise for
configure.

gdb, btrace: fix assert with gcc-15

This fixes

/usr/include/c++/15/optional:1186: constexpr _Tp& std::optional<_Tp>::operator*() & [with _Tp = std::__cxx11::basic_string<char>]: Assertion 'this->_M_is_engaged()' failed.

encountered in gdb.btrace/ptwrite.exp.

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

Automatic date update in version.in

gdb: replace msym_bunch with deque

This patch replaces the msym_bunch implementation with an std::deque.

I initially tried to replace it with a vector.  However, that doesn't
work, because minimal_symbol references need to stay valid across calls
to minimal_symbol_reader::record_full in at least one spot.
elf_symtab_read calls minimal_symbol_reader::record_full (through
function record_minimal_symbol) to record a minimal symbol for a PLT
entry and then uses a previously added minimal symbol to set the size of
the PLT minimal symbol.  If we used a vector, a re-allocation could
happen which would invalidate the reference to the previous minimal
symbol (luckily this was caught by ASan).

An std::deque implementation typically uses a sequence of fixed-sized
arrays, much like our current msym_bunch implementation.  So adding an
item at the end will not invalidate existing references.  But unlike our
msym_bunch, we don't have to worry about memory management.

I was a bit puzzled about this code in
minimal_symbol_reader::record_full:

  /* If we already read minimal symbols for this objfile, then don't
     ever allocate a new one.  */
  if (!m_objfile->per_bfd->minsyms_read)
    {
      m_msym_bunch_index++;
      m_objfile->per_bfd->n_minsyms++;
    }

From what I understand, this "feature" gets used when you have
ECOFF debug info in an ELF executable.  We first parse the ELF minimal
symbols in elf_symfile_read, then go into elfmdebug_build_psymtabs.
elfmdebug_build_psymtabs has the capability to generate minimal symbols
(useful when you use ECOFF debug info in an ECOFF executable I guess),
but in this case we already have the ELF ones, so we don't want to
record the ECOFF minimal symbols.  Hence this mechanism to suppress new
minimal symbols.

The consequence of this patch, I believe, is that
minimal_symbol_reader::record_full will unnecessarily allocate minimal
symbols in this case.  These minimal symbols won't be installed, because
of the check in minimal_symbol_reader::install.  The minimal symbols
will be freed when the minimal_symbol_reader gets destroyed.  That means
a higher temporary memory usage when reading an ECOFF-in-ELF file, but
no change in behavior.  See discussion at [1].

[1] https://inbox.sourceware.org/gdb-patches/85958fad-17e1-4593-b842-d60a6610f149@polymtl.ca/T/#meaf9b53da296e7f6872b441ec97038d172ca907f

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

[gdb/contrib] Add tcllint->tclint in codespell-dictionary.txt

Confusingly, the Tcl linter we're using is called tclint instead of tcllint.

Add a corresponding entry in gdb/contrib/codespell-dictionary.txt.

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

gdb: improve line number lookup around inline functions

This commit aims to fix an issue where GDB would report the wrong line
for frames other than #0 if a previous frame had just left an inline
function.

Consider this example which is compiled at -Og:

  volatile int global = 0;

  static inline int bar (void) { asm (""); return 1; }

  static void foo (int count)
  { global += count; }

  int main (void)
  {
    foo (bar ());
    return 0;
  }

Used in this GDB session:

  (gdb) break foo
  Breakpoint 1 at 0x401106: file test.c, line 6.
  (gdb) run
  Starting program: /tmp/inline-bt/test.x

  Breakpoint 1, foo (count=count@entry=1) at test.c:6
  6 { global += count; }
  (gdb) frame 1
  #1  0x0000000000401121 in main () at test.c:3
  3 static inline int bar (void) { asm (""); return 1; }

Notice that GDB incorrectly reports frame #1 as being at line 3 when
it should really be reporting this line:

  foo (bar ());

The cause of this problem is in find_pc_sect_line (symtab.c).  This
function is passed a PC for which GDB must find the symtab_and_line
information.  The function can be called in two modes based on the
NOTCURRENT argument.

When NOTCURRENT is false then we are looking for information about the
current PC, i.e. the PC at which the inferior is currently stopped
at.

When NOTCURRENT is true we are looking for information about a PC that
it not the current PC, but is instead the PC for a previous frame.
The interesting thing in this case is that the PC passed in will be
the address after the address we actually want to lookup information
for, this is because as we unwind the program counter from frame #0
what we get is the return address in frame #1.  The return address is
often (or sometimes) on the line after the calling line, and so in
find_pc_sect_line, when NOTCURRENT is true, we subtract 1 from PC and
then proceed as normal looking for information about this new PC
value.

Now lets look at the x86-64 disassembly for 'main' from the above
example.  The location marker (=>) represents the return address in
'main' after calling 'foo':

  (gdb) run
  Starting program: /tmp/inline-bt/test.x

  Breakpoint 1, foo (count=count@entry=1) at test.c:6
  6 { global += count; }
  #0  foo (count=count@entry=1) at test.c:6
  #1  0x000000000040111f in main () at test.c:3
  (gdb) up
  #1  0x000000000040111f in main () at test.c:3
  3 static inline int bar (void) { asm (""); return 1; }
  (gdb) disassemble
  Dump of assembler code for function main:
     0x0000000000401115 <+0>: mov    $0x1,%edi
     0x000000000040111a <+5>: call   0x401106 <foo>
  => 0x000000000040111f <+10>: mov    $0x0,%eax
     0x0000000000401124 <+15>: ret
  End of assembler dump.

And the corresponding line table:

  (gdb) maintenance info line-table
  objfile: /tmp/inline-bt/test.x ((struct objfile *) 0x59405a0)
  compunit_symtab: test.c ((struct compunit_symtab *) 0x53ad320)
  symtab: /tmp/inline-bt/test.c ((struct symtab *) 0x53ad3a0)
  linetable: ((struct linetable *) 0x53adc90):
  INDEX  LINE   REL-ADDRESS        UNREL-ADDRESS      IS-STMT PROLOGUE-END EPILOGUE-BEGIN
  0      6      0x0000000000401106 0x0000000000401106 Y
  1      6      0x0000000000401106 0x0000000000401106 Y
  2      6      0x0000000000401106 0x0000000000401106
  3      6      0x0000000000401114 0x0000000000401114
  4      9      0x0000000000401115 0x0000000000401115 Y
  5      10     0x0000000000401115 0x0000000000401115 Y
  6      3      0x0000000000401115 0x0000000000401115 Y
  7      3      0x0000000000401115 0x0000000000401115 Y
  8      3      0x0000000000401115 0x0000000000401115 Y
  9      10     0x0000000000401115 0x0000000000401115
  10     11     0x000000000040111f 0x000000000040111f Y
  11     12     0x000000000040111f 0x000000000040111f
  12     END    0x0000000000401125 0x0000000000401125 Y

When looking for the line information of frame #1 we start with the
return address 0x40111f, however, as this is not the current program
counter value we subtract one and look for line information for
0x40111e.

We will find the entry at index 9, this is the last entry with an
address less than the address we're looking for, the next entry has an
address greater than the one we're looking for.  The entry at index 9
is for line 10 which is the correct line, but GDB reports line 3, so
what's going on?

Having found a matching entry GDB checks to see if the entry is marked
as is-stmt (is statement).  In our case index 9 (line 10) is not a
statement, and so GDB looks backwards for entries at the same address,
if any of these are marked is-stmt then GDB will use the last of these
instead.  In our case the previous entry at index 8 is marked is-stmt,
and so GDB uses that.  The entry at index 8 is for line 3, and that is
why GDB reports the wrong line.  So why perform the backward is-stmt
check?

When NOTCURRENT is false (not our case) the backward scan makes
sense.  If the inferior has just stopped at some new location, and we
want to report that location to the user, then it is better (I think)
to select an is-stmt entry.  In this way we will report a line number
for a line which the inferior is just about to start executing, and
non of the side effects of that line have yet taken place.  The line
GDB prints will correspond with the reported line, and if the user
queries the inferior state, the inferior should (assuming the compiler
emitted correct is-stmt markers) correspond to the line in question
having not yet been started.

However, in our case NOTCURRENT is true.  We're looking back to
previous frames that are currently in-progress.  If upon return to the
previous frame we are about to execute the next line then (it seems to
me) that this indicates we must be performing the very last action
from the previous line.  As such, looking back through the line table
in order to report a line that has not yet started is the wrong thing
to do.  We really want to report the very last line table entry for
the previous address as this is (I think) most likely to represent the
previous line that is just about to complete.

Further, in the NOTCURRENT case, we should care less about reporting
an is-stmt line.  When a user looks back to a previous frame I don't
think they expect the line being reported to have not yet started.  In
fact I think the expectation is the reverse ... after all, the
previous line must have executed enough to call the current frame.

So my proposal is that the backward scan of the line table looking for
an is-stmt entry should not be performed when NOTCURRENT is true.  In
the case above this means we will report the entry at index 9, which
is for line 10, which is correct.

For testing this commit I have:

 1. Extended the existing gdb.opt/inline-bt.exp test.  I've extended
 the source code to include a test similar to the example above.  I
 have also extended the script so that the test is compiled at a
 variety of optimisation levels (O0, Og, O1, O2).

 2. Added a new DWARF assembler test which hard codes a line table
 similar to the example given above.  My hope is that even if test
 case (1) changes (due to compiler changes) this test will continue to
 test the specific case I'm interested in.

I have tested the gdb.opt/inline-bt.exp test with gcc versions 8.4.0,
9.3.1, 10.5.0, 11.5.0, 12.2.0, and 14.2.0, in each case the test will
fail (with the expected error) without this patch applied, and will
pass with this patch applied.

I was inspired to write this patch while reviewing these patches:

  https://inbox.sourceware.org/gdb-patches/AS8P193MB1285C58F6F09502252CEC16FE4DF2@AS8P193MB1285.EURP193.PROD.OUTLOOK.COM
  https://inbox.sourceware.org/gdb-patches/AS8P193MB12855708DFF59A5309F5B19EE4DF2@AS8P193MB1285.EURP193.PROD.OUTLOOK.COM

though this patch only covers one of the issues addressed by these
patches, and the approach taken is quite different.  Still, those
patches are worth reading for the history of this fix.

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

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

Minor test fix for gnat-llvm

This patch fixes a spot in the gdb test suite where gnat-llvm seems to
emit slightly better DWARF than GNAT.

bfd/ELF: Handle prstatus of 156 bytes in elf32_arm_nabi_grok_prstatus

For a corefile generated on openSUSE Leap 15.2 armv7l with linux version
5.3.18, we get:
...
$ gdb -q --core core
  ...
Core was generated by `/usr/bin/rs_scope -d'.

⚠️ warning: Couldn't find general-purpose registers in core file.
(gdb)
...

The warning is emitted because the pseudo-section .reg is missing, because
elf32_arm_nabi_grok_prstatus expects the PRSTATUS note to have size 148, but
instead we have:
...
$ eu-readelf -n core | grep -i prstatus
  CORE                 156  PRSTATUS
  CORE                 156  PRSTATUS
  CORE                 156  PRSTATUS
  CORE                 156  PRSTATUS
...

This is a bug for CONFIG_BINFMT_ELF_FDPIC=y configurations, fixed
by v5.9 linux kernel commit 16aead81018c ("take fdpic-related parts of
elf_prstatus out").

The bug causes the FDPIC-specific unsigned long fields pr_exec_fdpic_loadmap
and pr_interp_fdpic_loadmap to be added to struct elf_prstatus in case the
FDPIC ABI is not used.

Work around this bug in elf32_arm_nabi_grok_prstatus, by ignoring the extra
fields, which gets us instead:
...
Core was generated by `/usr/bin/rs_scope -d'.
Program terminated with signal SIGSEGV, Segmentation fault.
[Current thread is 1 (LWP 30047)]
(gdb)
...

Tested gdb, gas, binutils and ld on x86_64-linux and arm-linux with
--enable-targets=all.

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

[gdb] Fix style.indent in tclint.toml

The style.indent setting in gdb/tclint.toml is set to 4 spaces, which is an
approximation.

Starting with v0.6.2, tclfmt supports setting style.indent to mixed,<s>,<t>,
which allows us to specify the actual indentation scheme.

Set style.indent to mixed,4,8.

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

gdb: remove unused includes from valops.c

clangd says they are unused.

Change-Id: I17362d38eabf7b93a311265ba7497560592faa94

gdb: remove unused include from gdbtypes.c

clangd says it's not used.

Change-Id: I49ae57264599b490c3fe4c61c05a11e7c0891056

Automatic date update in version.in

PR 33721 load/store of misaligned address

This fixes PR33721 by a common technique of declaring a packed struct
to access unaligned integer fields.  (See eg. linux kernel
include/vdso/unaligned.h)  I've tidied the PR29856 fix for a similar
bug too (not that there was anything wrong with that fix).

PR 33721
PR 29856
* sframe.c (flip_fre_start_address): Use a packed struct to
access 2-byte and 4-byte unaligned fields.  Make addr a void*.
(sframe_decode_fre_start_address): Similarly, and remove
unnecessary casts.  Always set *fre_start_addr.

more solaris tidies

Don't overspecify the obsolete solaris targets: match solaris* rather
than solaris2.[0-9]*.  Move the sparc-*-solaris2.[0-6]* match later,
and make it sparc*-*-solaris* so that it catches sparcv9 and sparc64.
This change is necessary for internal binutils consistency so that
selecting --target=sparc-sun-solaris2 gets an error that the target is
obsolete, and furthermore that the same target with --enable-obsolete
does not result in runtime errors.

bfd/
* config.bfd: Don't overspecify obsolete solaris targets.
ld/
* configure.tgt: Don't overspecify obsolete solaris targets.
* po/BLD-POTFILES.in: Regenerate.

[gdb/testsuite] Fix gdb.cp/typeid.exp with m32 PIE

On x86_64-linux, if I run test-case gdb.cp/typeid.exp with target boards:
- unix/-m64
- unix/-m32
- unix/-fPIE/-pie/-m64
- unix/-fPIE/-pie/-m32
for only target board unix/-fPIE/-pie/-m32 I get:
...
(gdb) print &typeid(i)^M
could not find typeinfo symbol for 'int'^M
(gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(i)
print &typeid(i) == &typeid(typeof(i))^M
could not find typeinfo symbol for 'int'^M
(gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(i) == &typeid(typeof(i))
print &typeid(cp)^M
could not find typeinfo symbol for 'char*'^M
(gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(cp)
print &typeid(cp) == &typeid(typeof(cp))^M
could not find typeinfo symbol for 'char*'^M
(gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(cp) == &typeid(typeof(cp))
print &typeid(ccp)^M
could not find typeinfo symbol for 'char const*'^M
(gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(ccp)
print &typeid(ccp) == &typeid(typeof(ccp))^M
could not find typeinfo symbol for 'char const*'^M
(gdb) FAIL: gdb.cp/typeid.exp: before starting: print &typeid(ccp) == &typeid(typeof(ccp))
...

This is yet another configuration for which these tests don't work.

We're already allowing this for clang and istarget "powerpc*-*-*".

I don't think there is value in trying to detect yet another configuration.

Instead, just allow it in general.

Tested on x86_64-linux.

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

gas: sframe: fix memory leak of remember_fre

While at it, use the same pattern for cleaning up memory in
sframe_xlate_ctx_cleanup.

gas/
* gen-sframe.c (sframe_xlate_ctx_cleanup): Use the same pattern
for free'ing memory consistently.
(sframe_xlate_ctx_finalize): Free up remember_fre.

gdb: trivial cleanups in minimal_symbol_is_less_than

Remove unnecessary braces.

Replace `&` + `->` with `.`.

Remove the trivial comments that just explain how the comparison
operators work in C.

Change-Id: Id77ae534c90219e2c02332ff5606c54d00286eca

Untabify gdb 'help' output

This changes the gdb 'help' command to untabify its output.  This lets
us fix the last couple of warnings from the whitespace checker.

Regression tested on x86-64 Fedora 41.

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

gdb: shortcut 'list LINENO'

While working on a test for a weird interaction between the DWARF
parser, debuginfod, and the 'list' command, I noticed that performing
'list LINENO' can incur a significant amount of work trying to figure
out which symtab the source should be listed from.  This seems a
little weird as a plain 'list' just uses the default symtab with no
searching through all of the symtabs.

The symtab lookup is all hidden behind the decode_line_1 call, which
is made from list_command (cli/cli-cmds.c).

The thing is, in list_command we already have code which (basically)
checks if the argument to 'list' is a line number, here's the code:

  for (p = arg; p != arg1 && *p >= '0' && *p <= '9'; p++);
  linenum_beg = (p == arg1);

And we already have code within list_command which depends on the
default symtab, look at how 'list .', 'list +', and 'list -' are
handled.

I think that 'list LINENO' is such a common use case that is makes
sense to optimise this case in order to avoid the need to perform
symtab lookup.  I think this can be achieved without any significant
changes to the list_command function; we'll just move the existing
line number check (see above code) a little earlier in the function
and change it to a strtol call so that the actual line number is
recorded.  Then there's a little error checking, before finally we can
skip straight to listing the source code using the default symtab.

For anything other than 'list LINENO' we will handle the command just
as we've always done.

I think there's actually scope for list_command to handle more cases
internally, without calling out to decode_line_1, but I thought I'd
see how happy people were with this smaller change first before I
tried anything larger.

There should be no user visible changes after this commit, other than
'list LINENO' might be a little faster.

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

gdb: minor code cleanups in list_command

There should be no functional change after this commit, this is mostly
just a code cleanup in the list_command function.

I have inlined local variables into the function body, changing 'int'
to 'bool' where appropriate, and updating 'if' conditions to avoid
treating non-bools as a bool.

I also make more use of list_around_line towards the end of the
list_command function, which avoids some code duplication, but
shouldn't be a functional change.

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

[gdb] Fix "the the"

Replace "the the" with "the".

Result of running:
...
$ find gdb* -type f | egrep -v ChangeLog | xargs sed -i 's/the the /the /'
$ find gdb* -type f | egrep -v ChangeLog | xargs sed -i 's/the the$/the/'
...

The only change I have doubts about, is this comment in queue_comp_unit in
gdb/dwarf2/read.c:
...
    ... .  If the CU gets enqueued by this function but its DIEs
-   are not yet loaded, the the caller must load the CU's DIEs to ensure the
+   are not yet loaded, the caller must load the CU's DIEs to ensure the
    invariant is respected.
...
where I think "the the" -> "then the" also make sense.  But for now, I'm going
with "the the" -> "the".

Tested by building gdb on x86_64-linux.

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

gdb: fix crash from 'shell' when GDB has no terminal

Bug PR gdb/33716 identifies a problem where GDB will crash when using
the 'shell' command if GDB is not attached to a terminal.  E.g.:

  $ gdb -nw -nh -q -batch -ex 'shell echo hello' </dev/null
  hello

  Fatal signal: Segmentation fault
  ----- Backtrace -----
  ... etc ...

This problem was introduced with commit:

  commit 3a7f7d0be3a2953fd110f084b34586ce9c649d66
  Date:   Fri Jul 25 19:07:59 2025 +0200

      [gdb/tui] Fix shell command terminal settings

This commit introduces 'class scoped_gdb_ttystate', a RAII class which
backs up and restores the current terminal state.  Unfortunately, the
implementation tries to backup and restore the state even when GDB is
not attached to a terminal.

If GDB is not attached to a terminal then serial_get_tty_state
will (on a Unix like system) return a NULL pointer.  Calling
serial_set_tty_state with a NULL state object will trigger the crash
seen above.

Elsewhere in GDB, calling serial_set_tty_state is guarded by calling
gdb_has_a_terminal().  I propose that we only try to backup the
terminal state if GDB is actually connected to a terminal.  The call
to serial_set_tty_state will only be made if the backed up tty state
is not NULL.

With this change in place the crash is resolved.  There's a new test
to cover this case.

While I'm here I added a gdb_assert in ser-unix.c which would have
triggered in this case before we saw the crash.  And I've extended the
comment in serial.h to document that serial_get_tty_state can return
NULL.

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

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

gdb: rename scoped_gdb_tty_state, and make it non-copyable

The scoped_gdb_tty_state class seems misnamed.  For save/restore type
classes the pattern in GDB is usually scoped_restore_<whatever>, so
lets rename this to scoped_restore_tty_state.  I dropped the 'gdb' part
of the name as the underlying functions being called are
serial_get_tty_state and serial_set_tty_state, so the new name
matches (I think) what's actually being called.

I've also made the class non-copyable like other scoped_restore_
classes.

There should be no user visible changes after this commit.

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

gdb/doc: fix incorrect use of @value

In commit:

  commit 255a9c42709958d0925d1d0d1d39d262972fd2a6
  Date:   Fri Dec 5 11:33:29 2025 +0000

      gdb: new setting to disable progress bars

I incorrectly used @value{on} and @value{off} to reference the on/off
settings of a new flag.  This caused the following warnings when
building the docs:

  gdb.texinfo:51356: warning: undefined flag: off
  gdb.texinfo:51357: warning: undefined flag: on

Looking through the docs there seems to be a split, in some cases we
use @code and in others we use @samp.  I'm not sure @code is correct,
so I've switched to use @samp.  The warnings are gone after this
patch.

Re: LoongArch: Add linker relaxation support for R_LARCH_CALL30

clang catches this error and another like it on line 6320.
elfnn-loongarch.c:6357:35: error: overlapping comparisons always evaluate to true [-Werror,-Wtautological-overlap-compare]
 6357 |                    && (r_type != R_LARCH_CALL36 || r_type != R_LARCH_CALL30))
      |                        ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~

* elfnn-loongarch.c (loongarch_elf_relax_section): Correct tests
for R_LARCH_CALL36 and_LARCH_CALL30.

Automatic date update in version.in

gdb/testsuite: fix tcllint errors in gdb.base/startup-hints.exp

Fix:

    gdb/testsuite/gdb.base/startup-hints.exp:61:44: expression with substitutions should be enclosed by braces [unbraced-expr]
    gdb/testsuite/gdb.base/startup-hints.exp:64:28: expression with substitutions should be enclosed by braces [unbraced-expr]

Change-Id: Id21ff11ced82b11c11d0eb0d186fe6fc5c4c06c5

LD/testsuite: Expand archive verification to group feature

Expand archive verification to cover the group feature.  Linker error
messages for unsatisfied symbol references vary between targets a bit,
in particular `arc-*-*' produce duplicate messages and `alpha*-*-osf*'
and `alpha*-*-linux*ecoff*' add a "final link failed" message.  Factor
this in with the error pattern list to match.  Usual XFAIL annotations
apply.

CRIS/LD/testsuite: Add tests for emulation switching

Add tests matching generic ones from ld-archive/archive.exp for explicit
link emulation switching, verifying that correct output is produced from
a link including an archive the format of which is not the default one.

This covers generic BFD code using `cris-aout' and `cris-elf' targets as
ones that permit switching between dissimilar emulations from assembly
through the link.

Only tests for link emulation explicitly specified are included at this
stage, as bugs in BFD currently prevent links from successful completion
that use the default emulation while involving archives in a non-default
format.  Additional tests will be included with a subsequent change that
addresses said bugs.

LD/testsuite: Expand archive verification to `--whole-archive' feature

Expand archive verification to cover the `--whole-archive' feature,
adding link map and verbose output matching to verify the correct
archive members are added and the unwanted ones omitted.

Adjust the linker flags accordingly for XCOFF targets, by switching from
the `-bexpall' option to `-unix' (`-bexpfull' would do too, but has some
test coverage already, unlike `-unix', which is a superset of the former
option), so that additional symbols pulled with `--whole-archive' aren't
discarded by linker garbage collection.

This test expansion has revealed the lack of thin archive support in AR
for Alpha/VMS and XCOFF targets, despite apparent presence of relevant
code in the respective BFD backends.  With `ar rcT' invocation a regular
archive is silently produced instead.

Rather than making the relevant tests overly permissive, XFAIL them for
the affected targets, referring PR binutils/33600.

VMS/BFD: Fix a sign extension issue with archive symbol lookup

Symbol binary search code for VMS archive files uses plain `char' data
type to cast a difference between characters to data of the `int' type.
Consequently the difference is consider unsigned in the range between 0
and 255 on hosts where plain `char' data type is unsigned, resulting in
symbol lookup failures, such as with the test expansion included with
this change causing regressions as follows:

FAIL: Regular archive link
FAIL: Thin archive link
FAIL: Regular archive plus regular link
FAIL: Regular archive plus thin link
FAIL: Thin archive plus regular link
FAIL: Thin archive plus thin link

owing to link failures such as:

.../ld/ld-new: tmpdir/abc.o:($DATA$+0x0): undefined reference to `aa'
.../ld/ld-new: tmpdir/ab.a(b.obj):($DATA$+0x10): undefined reference to `aa'
.../ld/ld-new: tmpdir/abc.o:($DATA$+0x0): undefined reference to `aa'
.../ld/ld-new: tmpdir/ab.a(b.obj):($DATA$+0x10): undefined reference to `aa'

with the `alpha-dec-vms' target on the `powerpc64le-linux-gnu' host.

Use explicit `signed char' data type for the cast then, removing the
failures.

LD/testsuite: Fix archive verification for Alpha/VMS

As from commit a2298f23f2e2 ("PR 33385 vms archives") the handling of
Alpha/VMS archives has been recently unbroken, after 7 years, revealing
issues with archive tests added with commit 435223a9ae70 ("LD/testsuite:
Add tests for archive handling"), the change of the failure mode of
which went unnoticed.

In particular there is no NM support for executables and archives always
have an index by the nature of the format; cf. `_bfd_vms_lib_archive_p':
"The map is always present."

Address these peculiarities by excluding NM tests for the executables
produced and by omitting mapless archive rejection tests just as with
XCOFF targets, removing all the test failures:

alpha-dec-vms  -FAIL: Regular archive link
alpha-dec-vms  -FAIL: Thin archive link
alpha-dec-vms  -FAIL: Regular archive plus regular link
alpha-dec-vms  -FAIL: Regular archive plus thin link
alpha-dec-vms  -FAIL: Thin archive plus regular link
alpha-dec-vms  -FAIL: Thin archive plus thin link
alpha-dec-vms  -FAIL: Regular archive w/o index link
alpha-dec-vms  -FAIL: Thin archive w/o index link

Factor out code to filter out unwanted tests to a procedure for a better
structure of the code.

PR binutils/33485: LD/testsuite: Also XFAIL `ns32k-*-*' targets

NS32k targets also use the a.out archive format, which suffers from PR
binutils/33485 where symbol indexes in a.out thin archives are missing
symbols for subsequent members.  This affects `ns32k-pc532-lites*',
`ns32k-pc532-mach*', and `ns32k-pc532-ux*' targets in particular; other
NS32k targets appear defunct.  Add suitable XFAIL annotation, removing
failures such as:

ns32k-pc532-lites  -FAIL: Thin archive link
ns32k-pc532-lites  -FAIL: Regular archive plus thin link
ns32k-pc532-lites  -FAIL: Thin archive plus regular link
ns32k-pc532-lites  -FAIL: Thin archive plus thin link

[pre-commit] Move codespell-log to post-commit

The current pre-commit hook codespell-log works with script
gdb/contrib/codespell-log.sh.

During the commit-msg phase of a commit, the following happens:
- git calls pre-commit
- pre-commit calls gdb/contrib/codespell-log.sh,
- gdb/contrib/codespell-log.sh calls pre-commit, and
- precommit calls codespell.

This purpose of this indirection is to:
- ignore the exit status of codespell (to make sure that the commit is not
  aborted), and
- control the version of codespell.

However, if the check fails, the output is a bit messy due to the indirection:
...
$ touch gdb/bla.c
$ git add gdb/bla.c
$ git commit -m "Usuable"
  ...
codespell-log............................................................Passed
- hook id: codespell-log
- duration: 0.43s

codespell-log-internal...................................................Failed
- hook id: codespell
- exit code: 65

.git/COMMIT_EDITMSG:1: Usuable ==> Usable

[detached HEAD 18ec133830f] Usuable
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 gdb/bla.c
...

And if the check passes, the output is still verbose due to the verbose=true
setting.

I found a simpler way to implement this.

Given that we don't want to abort the commit, the post-commit stage is a more
natural place for this check.  Moving it there solves two problems:
- we no longer need to ignore the exit status of codespell
- we no longer need the verbose=true setting

The only issue is that we need to generate the file containing the commit
message ourselves, something that is provided by git in the commit-msg stage.
So we still need a wrapper script.

However, it seems that specifying a shell script as entry point of a codespell
hook is fine, so we no longer need to call pre-commit from codespell-log.sh.

Having simplified codespell-log.sh, we can downgrade it to a /bin/sh script,
instead of requiring bash.

Checked with shellcheck.

gdb: new setting to disable progress bars

Two commits ago, in the commit titled:

    gdb: make get_chars_per_line return an unsigned value

A bodge was added in cli-out.c so that progress bars (as seen when
debuginfod downloads a file) would be disabled when the output
terminal had unlimited width.

The hack was added because this previous commit fixed a bug such that
progress bars could now be displayed in very wide, or even on
unlimited width output terminals.  By fixing this bug, progress bars
were now being displayed when running the testsuite, as the testsuite
sets the output terminal to unlimited width.

To avoid breaking the tests, this previous commit added a bodge such
that on unlimited width output terminals, progress bars would always
be disabled.  This got the tests passing again, but isn't an ideal
solution.

This commit cleans things up.  We now have a new setting:

  set progress-bars enabled on|off
  show progress-bars enabled

This setting allows progress bars to be turned off.  The tests are
then updated to explicitly turn off progress bars.  The bodge from the
earlier commit is then removed.

Now, progress bars should display correctly on any width of output
terminal over 50 characters, the minimum required.  And the debuginfod
tests should all pass as they turn off progress bars.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb: fix crashes and weird output from new boxed hint text

After the commit:

  commit f6df8aa48f120b78f0670b429f8a3363020a47dc
  Date:   Mon Sep 15 11:56:17 2025 -0300

      gdb: Make startup message more user friendly

I noticed, that when I start GDB with a file on the command line, I
was seeing some stray '..'.  Like this:

  $ gdb -nw -nh /tmp/hello.x
  GNU gdb (GDB) 18.0.50.20251202-git
  Copyright (C) 2025 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "x86_64-pc-linux-gnu".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  <https://www.gnu.org/software/gdb/bugs/>.

  ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
  ┃ Find the GDB manual online at:                                               ┃
  ┃ http://www.gnu.org/software/gdb/documentation/.                              ┃
  ┃ For help, type "help".                                                       ┃
  ┃ Type "apropos <word>" to search for commands related to <word>               ┃
  ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
  ..
  Reading symbols from /tmp/hello.x...

Notice the '..' after the boxed hint text, that's what I'm complaining
about.  Also, notice that the last line within the box is missing its
period.

Before the above commit the last line would appear like this when no
file was loaded:

  Type "apropos <word>" to search for commands related to <word>.

And like this when a file was being loaded:

  Type "apropos <word>" to search for commands related to <word>...

The extra '..' are added to show that a file is being loaded, and that
this might take some time.  But we have the 'Reading symbols from ...'
text to indicate this now, so I think the extra '..' are redundant.
Lets just drop them.  This will leave just a single period at the end
of the sentence.

The above commit unfortunately, didn't include any tests, so I thought
I'd write some to cover this fix.... and that uncovered a bug where
the box around the startup hints could be corrupted:

  $ gdb -eiex 'set width 50' -nw -nh
  GNU gdb (GDB) 18.0.50.20251202-git
  Copyright (C) 2025 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "x86_64-pc-linux-gnu".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  <https://www.gnu.org/software/gdb/bugs/>.

  ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
  ┃ Find the GDB manual online at:                 ┃
  ┃ http://www.gnu.org/software/gdb/documentation/. ┃
  ┃ For help, type "help".                         ┃
  ┃ Type "apropos <word>" to                       ┃
  ┃  search for commands related to <word>         ┃
  ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

  (gdb)

This was caused by a mistake on the line where we choose whether to
box or not.  The line is currently:

  if (width - 3 <= docs_url.length ())

There are two problems here, the '3' should be '4'.  The box adds 4
characters '| ' and ' |'.  But also, the WIDTH can be very small, less
than 4 even, which means that the subtraction can underflow, wrapping
around and giving a very large value.  I plan to rewrite the line to:

  if (width < docs_url.length () + 1 + 4)

The '+ 1' accounts for the period at the end of the URL line (which
was previously handled by the '<=', and the '+ 4' accounts for the box
borders.  By making it a '+ 4' on the URL, rather than '- 4' from the
width, we avoid underflow.  This is fine so long as the URL to our
documentation doesn't approach UINT_MAX in length.  Which I hope it
never does.

I've added a couple of asserts to print_gdb_hints to reflect things
that must be true.  The first is that get_chars_per_line never returns
0.  And later on, I assert that 'width > 4' in a place where we are
about to do 'width - 4'.  If the assert triggers then underflow would
have occurred.

Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>

gdb: make get_chars_per_line return an unsigned value

I noticed that get_chars_per_line currently returns an 'int', but the
value it is returning, from utils.c, is an 'unsigned int'.  In some
cases this can cause weird behaviour as an unlimited width terminal
will have UINT_MAX characters per line, which will appear as negative
when returned from get_chars_per_line.

This has been the case since get_chars_per_line was added in commit:

  commit 2f2287318b33ddf855a692fcc191f6b25caf4644
  Date:   Wed Dec 16 18:18:40 2020 +0100

      [gdb/cli] Add a progress meter

Lets make get_chars_per_line return an unsigned value, and update all
the uses of this function to hold the result in an unsigned variable.

I ran into this issue when looking at print_gdb_hints (from top.c)
where a very large get_chars_per_line() value would appear negative,
and so the startup hints would be printed without a box when really
they should have been boxed.  Someone else noticed this problem while
I was building this patch, and pushed commit:

  commit 06e470d8fc0ae0e83fe0977fdf8c011998980891
  Date:   Sat Nov 29 15:48:55 2025 +0100

      gdb: handle unlimited screen width case in print_gdb_hints

This commit works around the signed / unsigned confusion entirely
within print_gdb_hints by adding a case to 'int' in one place.  The
change I present here reverts parts of 06e470d8fc0a in favour of
fixing the type of WIDTH within print_gdb_hints.

It is worth nothing that there are other bugs in print_gdb_hints
relating to how WIDTH is handled, but these are fixed in the next
commit.

By updating the return type of get_chars_per_line, I ran into some
issues in cli-out.c relating to how progress bars are handled.  The
existing code includes code like:

   if (!stream->isatty ()
       || !current_ui->input_interactive_p ()
       || chars_per_line < MIN_CHARS_PER_LINE)
     return;

The early return here triggers when progress bars should not be
printed.  Notice that when the terminal width is unlimited,
CHARS_PER_LINE will appear negative, and so the early return will
trigger.

It turns out that our testsuite depends on this; the debuginfod tests
don't expect to see a progress bar, and they don't because within the
tests we set the width to unlimited.

By "fixing" the type of CHARS_PER_LINE to 'unsigned int', an unlimited
width terminal no longer triggers the early return, and GDB starts
trying to print a progress bar in our debuginfod tests, which cause
the tests to fail.

I think the real fix is to add a new flag to allow progress bars to be
disabled, the tests can then use this.  I will add just such a flag at
the end of this series.

For now though, I propose adding a bodge.  If CHARS_PER_LINE is
UINT_MAX, then we should act as if progress bars are disabled.  The
above code now becomes:

   if (!stream->isatty ()
       || !current_ui->input_interactive_p ()
       || chars_per_line < MIN_CHARS_PER_LINE
       || chars_per_line == UINT_MAX)
     return;

This change is in cli_ui_out::clear_progress_notify.  There is a
similar change in cli_ui_out::do_progress_notify.  With these two
changes, the debuginfod tests are working again.  This bodge will be
removed by the last patch in this series.

There's no tests with this commit yet as print_gdb_hints has other
bugs which will be fixed in the next commit.  At this point I'll add
some tests.

Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>

Minor DAP test cleanups

This patch removes the "-1" from returns in the DAP tests, and also
reindents one of those lines at the same time.

DAP: accept requests with '"arguments": null'

Some Debug Adapter Protocol clients like Helix set the optional
"arguments" field of the ConfigurationDone request to null, which is a
bit odd but seems to be allowed by the protocol specification. Before
this patch, Python exceptions would be raised on such requests. This
patch makes it so these requests are treated as if the "arguments"
field was absent.

Use skip_spaces in more places

I looked through gdb for instance of:

      while (*p == ' ' || *p == '\t')
p++;

... and replaced these with a call to skip_spaces.

In some cases this might slightly change the semantics, as now other
whitespace (like \r or \f) will be considered.  However I don't think
this matters.

Regression tested on x86-64 Fedora 41.

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

aarch64: Add support for new BTI <target> "r"

This patch adds support for new BTI <target> "r" (instruction: bti r),
which is an alias to "bti" (with no target), for both "bti" and "bti r"
the preferred disassembly is "bti r". This "bti r" instruction is by
default available from Armv8-A architecture.

The HINT_OPD_F_NOPRINT macro has become redundant with these changes
and has been removed.

bfd/s12z: put relocations next to each other

It's not helpful to have two separate "sections", each with a single
relocation.

bfd/ELF: fold BFD_RELOC_<arch>_RELATIVE

There's no need to have a separate reloc per arch; just like for other
more or less generic ones a single one will (mostly) do. Arm64, C-Sky,
and KVX - sadly - are exceptions.

bfd/ELF: fold BFD_RELOC_<arch>_J{,U}MP_SLOT

There's no need to have a separate reloc per arch; just like for other
more or less generic ones a single one will (mostly) do. Arm64, C-Sky,
and KVX - sadly - are exceptions.

bfd/ELF: fold BFD_RELOC_<arch>_GLOB_DAT

There's no need to have a separate reloc per arch; just like for other
more or less generic ones a single one will (mostly) do. Arm64, C-Sky,
and KVX - sadly - are exceptions.

bfd/ELF: fold BFD_RELOC_<arch>_COPY

There's no need to have a separate reloc per arch; just like for other
more or less generic ones a single one will (mostly) do. Arm64, C-Sky,
and KVX - sadly - are exceptions.

bfd/ELF: fold BFD_RELOC_<arch>_IRELATIVE

There's no need to have a separate reloc per arch; just like for other
more or less generic ones a single one will (mostly) do. Arm64, C-Sky, and
KVX - sadly - are exceptions.

S/390: use BFD_RELOC_<n>_PLT_PCREL in favor of custom types

No reason to have separate types when the generic ones have no (other)
meaning for this target.

Sparc: use BFD_RELOC_<n>_PLT_PCREL in favor of custom types

No reason to have separate types when the generic ones have no (other)
meaning for this target.