tests: use canonical option name

ld/ChangeLog:

* testsuite/ld-size/size.exp: Use canonical option name.

re: Support Intel AMX-FP16

Fix these fails due to the target padding out sections with nops.
x86_64-w64-mingw32  +FAIL: x86_64 AMX-FP16 insns
x86_64-w64-mingw32  +FAIL: x86_64 AMX-FP16 insns (Intel disassembly)

* testsuite/gas/i386/x86-64-amx-fp16-intel.d: Accept trailing nops.
* testsuite/gas/i386/x86-64-amx-fp16.d: Likewise.

Re: ld/testsuite: adjust ld-arm to run shared tests only when supported

commit 67527cffcd enabled previously disabled tests unresolved-1-dyn,
thumb-plt and thumb-plt-got for nacl.  The first fails due to trying
to link against mixed-lib.so which isn't compiled for nacl.  The last
two fail with
objdump: tmpdir/dump(.rel.plt): relocation 0 has invalid symbol index 14885104
and
readelf: Error:  bad symbol index: 00e320f0 in reloc

Relocation section '.rel.plt' at offset 0x128 contains 1 entry:
 Offset     Info    Type                Sym. Value  Symbol's Name
e320f000  e320f000 R_ARM_NONE

* testsuite/ld-arm/arm-elf.exp: Disable unresolved-1-dyn,
thumb-plt and thumb-plt-got for nacl.

Automatic date update in version.in

gdb/testsuite: fix gdb.guile/scm-parameter.exp "wrong type argument" test pattern for Guile >= 2.2

Since commit 90319cefe3 ("GDB/Guile: Don't assert that an integer value
is boolean"), I see:

    FAIL: gdb.guile/scm-parameter.exp: kind=PARAM_ZINTEGER: test-PARAM_ZINTEGER-param: guile (set-parameter-value! test-PARAM_ZINTEGER-param #:unlimited)
    FAIL: gdb.guile/scm-parameter.exp: kind=PARAM_ZUINTEGER: test-PARAM_ZUINTEGER-param: guile (set-parameter-value! test-PARAM_ZUINTEGER-param #:unlimited)

This comes from the fact that GDB outputs this:

    ERROR: In procedure set-parameter-value!:
    In procedure gdbscm_set_parameter_value_x: Wrong type argument in position 2 (expecting integer): #:unlimited
    Error while executing Scheme code.

while the test expects an additional "ERROR:" on the second line,
something like this:

    ERROR: In procedure set-parameter-value!:
    ERROR: In procedure gdbscm_set_parameter_value_x: Wrong type argument in position 2 (expecting integer): #:unlimited
    Error while executing Scheme code.

Guile 2.0 outputs the `ERROR:` on the second line, while later versions
do not.  Change the pattern to accept both outputs.  This is similar to
commit 6bbe1a929c6 ("[gdb/testsuite] Fix gdb.guile/scm-breakpoint.exp
with guile 3.0").

Change-Id: I9dc45e7492a4f08340cad974610242ed689de959

gdb/arm: Fix M-profile EXC_RETURN

Arm v8-M Architecture Reference Manual,
D1.2.95 EXC_RETURN, Exception Return Payload
describes ES bit:

"ES, bit [0]
     Exception Secure. The security domain the exception was taken to.
     The possible values of this bit are:
       0 Non-secure.
       1 Secure"

arm-tdep.c:3443, arm_m_exception_cache () function tests this bit:

  exception_domain_is_secure = (bit (lr, 0) == 0);

The test is negated!

Later on line 3553, the condition evaluates if an additional state
context is stacked:

  /* With the Security extension, the hardware saves R4..R11 too.  */
  if (tdep->have_sec_ext && secure_stack_used
      && (!default_callee_register_stacking || exception_domain_is_secure))

RM, B3.19 Exception entry, context stacking
reads:
RPLHM "In a PE with the Security Extension, on taking an exception,
the PE hardware:
  ...
  2. If exception entry requires a transition from Secure state to
     Non-secure state, the PE hardware extends the stack frame and also
     saves additional state context."

So we should test for !exception_domain_is_secure instead of non-negated
value!
These two bugs compensate each other so unstacking works correctly.

But another test of exception_domain_is_secure (negated due to the
first bug) prevents arm_unwind_secure_frames to work as expected:

  /* Unwinding from non-secure to secure can trip security
     measures.  In order to avoid the debugger being
     intrusive, rely on the user to configure the requested
     mode.  */
  if (secure_stack_used && !exception_domain_is_secure
      && !arm_unwind_secure_frames)

Test with GNU gdb (GDB) 13.0.50.20221016-git.
Stopped in a non-secure handler:

 (gdb) set arm unwind-secure-frames 0
 (gdb) bt
 #0  HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:490
 #1  0x0804081c in SysTick_Handler ()
     at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsstm32l5xx_it.c:134
 #2  <signal handler called>
 #3  HAL_GPIO_ReadPin (GPIOx=0x52020800, GPIO_Pin=8192)
     at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Drivers/STM32L5xx_HAL_Driver/Src/stm32l5xx_hal_gpio.c:386
 #4  0x0c000338 in SECURE_Mode () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:86
 #5  0x080403f2 in main () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:278
 Backtrace stopped: previous frame inner to this frame (corrupt stack?)

The frames #3 and #4 are secure. backtrace should stop before #3.

Stopped in a secure handler:

 (gdb) bt
 #0  HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:425
 #1  0x0c000b6a in SysTick_Handler ()
     at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:234
 warning: Non-secure to secure stack unwinding disabled.
 #2  <signal handler called>

The exception from secure to secure erroneously stops unwinding. It should
continue as far as the security unlimited backtrace:

 (gdb) set arm unwind-secure-frames 1
 (gdb) si <-- used to rebuild frame cache after change of unwind-secure-frames
 0x0c0008e6      425       if (SecureTimingDelay != 0U)
 (gdb) bt
 #0  0x0c0008e6 in HAL_SYSTICK_Callback () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:425
 #1  0x0c000b6a in SysTick_Handler ()
     at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:234
 #2  <signal handler called>
 #3  0x0c000328 in SECURE_Mode () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/main.c:88
 #4  0x080403f2 in main () at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/NonSecure/Src/nsmain.c:278

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

Set exception_domain_is_secure to the value expected by its name.
Fix exception_domain_is_secure usage in the additional state context
stacking condition.

Signed-off-by: Tomas Vanek <vanekt@fbl.cz>

gdb/arm: fix IPSR field test in arm_m_exception_cache ()

Arm v8-M Architecture Reference Manual,
D1.2.141 IPSR, Interrupt Program Status Register reads
"Exception, bits [8:0]"

9 bits, not 8! It is uncommon but true!

Signed-off-by: Tomas Vanek <vanekt@fbl.cz>

gdb/arm: Terminate frame unwinding in M-profile lockup

In the lockup state the PC value of the the outer frame is irreversibly
lost. The other registers are intact so LR likely contains
PC of some frame next to the outer one, but we cannot analyze
the nearest outer frame without knowing its PC
therefore we do not know SP fixup for this frame.

The frame unwinder possibly gets mad due to the wrong SP value.
To prevent problems terminate unwinding if PC contains the magic
value of the lockup state.

Example session wihtout this change,
Cortex-M33 CPU in lockup, gdb 13.0.50.20221016-git:
----------------
  (gdb) c
  Continuing.

  Program received signal SIGINT, Interrupt.
  0xeffffffe in ?? ()
  (gdb) bt
  #0  0xeffffffe in ?? ()
  #1  0x0c000a9c in HardFault_Handler ()
      at C:/dvl/stm32l5trustzone/GPIO_IOToggle_TrustZone/Secure/Src/stm32l5xx_it.c:99
  #2  0x2002ffd8 in ?? ()
  Backtrace stopped: previous frame identical to this frame (corrupt stack?)
  (gdb)
----------------
The frame #1 is at correct PC taken from LR, #2 is a total nonsense.

With the change:
----------------
  (gdb) c
  Continuing.

  Program received signal SIGINT, Interrupt.
  warning: ARM M in lockup state, stack unwinding terminated.
  <signal handler called>
  (gdb) bt
  #0  <signal handler called>
  (gdb)
----------------

There is a visible drawback of emitting a warning in a cache buildnig routine
as introduced in Torbjörn SVENSSON's
[PATCH v4] gdb/arm: Stop unwinding on error, but do not assert
The warning is printed just once and not repeated on each backtrace command.

Signed-off-by: Tomas Vanek <vanekt@fbl.cz>

gdb: copyright: make file header scan a bit more pythonic

Should be functionally the same, but uses more pythonic idioms to get
fewer lines of code, and to make sure to not leak open file handles.

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

gdb: make copyright.py interface a bit nicer

This way people can run `./copyright.py --help` and get some info as
to what this does without it going and modifying the tree.

sim: testsuite: improve parallel test processing

The current logic limits itself to a maxdepth of 4 when looking for
results.  This wouldn't be a problem if cris didn't have a testsuite
at a depth of 5 which we end up ignoring when summarizing.  Rather
than bump the number from 4 to 5, rework the code so that we gather
the exact set of tests that we tried to run.

buffer overflow in _bfd_XX_print_ce_compressed_pdata

More fuzzed fun.

* peXXigen.c (_bfd_XX_print_ce_compressed_pdata): Use smaller of
virt_size and bfd section size as limit of function table.

Correct ELF reloc size sanity check

The external reloc size check was wrong.  Here asect is the code/data
section, not the reloc section.  So using this_hdr gave the size of
the code/data section.

* elf.c (_bfd_elf_get_reloc_upper_bound): Properly get
external size from reloc headers.

segfault in objdump.c reloc_at

bfd_canonicalize_reloc returns -1L on errors.

* objdump.c (load_specific_debug_section): Properly handle
error return from bfd_canonicalize_reloc.

som.c reloc sanity checking

This patch checks that relocations emitted in som_write_fixups have
offsets that are monotonic and within a section.  To do that properly
using bfd_reloc_offset_in_range it is necessary to set the reloc howto
size field, which isn't used otherwise by the som backend.  Note that
the sizes used are not exactly those in the old sizing switch
statement deleted from som_write_fixups, but all relocs handled by the
main switch statement there get the same size.  Most unhandled relocs
get a zero size (exceptions being R_RELOCATION, R_SPACE_REF,
R_MILLI_REL, R_BREAKPOINT which all involve writing one word according
to my SOM reference).  I figure it doesn't matter since any unhandled
reloc is converted to 0xff R_RESERVED, and a default of zero is better
for a "don't know" reloc.

Besides tidying the code, stringizing name from type in SOM_HOWTO
fixes R_REPEATED_INIT name.

* som.c (SOM_HOWTO): Add SIZE arg, delete NAME.  Stringize type
to name.
(som_hppa_howto_table): Update with sizes.
(som_write_fixups): Delete sizing switch statement.  Sanity check
bfd_reloc address against subsection size.

som.c buffer overflow

Fuzzed object files can put random values in bfd_reloc->address,
leading to large som_reloc_skip output.

* som.c (som_write_fixups): Allow for maximal som_reloc_skip.

PR29720, objdump -S crashes if build-id is missing

PR 29720
* objdump.c (slurp_file): Don't call debuginfod_find_source
when build_id is NULL.

Automatic date update in version.in

gdb: remove spurious spaces after frame_info_ptr

Fix some whitespace issues introduced with the frame_info_ptr patch.

Change-Id: I158d30d8108c97564276c647fc98283ff7b12163

x86-64: Use only one default max-page-size

On x86-64 the default ELF_MAXPAGESIZE depends on a configure
option (--disable-separate-code).  Since 9833b775
("PR28824, relro security issues") we use max-page-size for relro
alignment (with a short interval, from 31b4d3a ("PR28824, relro
security issues, x86 keep COMMONPAGESIZE relro") to its revert
a1faa5ea, where x86-64 only used COMMONPAGESIZE as relro alignment
target).

But that means that a linker configured with --disable-separate-code
behaves different from one configured with --enable-separate-code
(the default), _even if using "-z {no,}separate-code" option to use
the non-configured behaviour_ .  In particular it means that when
configuring with --disable-separate-code the linker will produce
binaries aligned to 2MB pages on disk, and hence generate 2MB
executables for a hello world (and even 6MB when linked with
"-z separate-code").

Generally we can't have constants that ultimately land in static
variables be depending on configure options if those only influence
behaviour that is overridable by command line options.

So, do away with that, make the default MAXPAGESIZE be 4k (as is default
for most x86-64 configs anyway, as most people won't configure with
--disable-separate-code).  If people need more they can use the
"-z max-page-size" (with would have been required right now for a
default configure binutils).

bfd/
* elf64-x86-64.c (ELF_MAXPAGESIZE): Don't depend on
DEFAULT_LD_Z_SEPARATE_CODE.

gdb/testsuite: make sure to consume the prompt in gdb.base/unwind-on-each-insn.exp

This test fails quite reliably for me when ran as:

    $ taskset -c 1 make check TESTS="gdb.base/unwind-on-each-insn.exp" RUNTESTFLAGS="--target_board=native-gdbserver"

or more simply:

    $ make check-read1 TESTS="gdb.base/unwind-on-each-insn.exp"

The problem is that the gdb_test_multiple call that grabs the frame id
from "maint print frame-id" does not consume the prompt.  Well, it does
sometimes due to the trailing .*, but not always.  If the prompt is not
consumed, the tests that follow get confused:

    FAIL: gdb.base/unwind-on-each-insn.exp: gdb_breakpoint: set breakpoint at *foo
    FAIL: gdb.base/unwind-on-each-insn.exp: disassemble foo
    FAIL: gdb.base/unwind-on-each-insn.exp: get $sp and frame base in foo: get hexadecimal valueof "$sp"
    ... many more ...

Use -wrap to make gdb_test_multiple consume the prompt.

While at it, remove the bit that consumes the command name and do
exp_continue, it's not really necessary.  And for consistency, do the
same changes to the gdb_test_multiple that consumes the stack address,
although that one was fine, it did consume the prompt explicitly.

Change-Id: I2b7328c8844c7e98921ea494c4c05107162619fc
Reviewed-By: Bruno Larsen <blarsen@redhat.com>

[gdb/testsuite] Handle missing .note.GNU-stack

On openSUSE Tumbleweed I run into this for the dwarf assembly test-cases, and
some hardcoded assembly test-cases:
...
 Running gdb.dwarf2/fission-absolute-dwo.exp ...
 gdb compile failed, ld: warning: fission-absolute-dwo.o: \
   missing .note.GNU-stack section implies executable stack
 ld: NOTE: This behaviour is deprecated and will be removed in a future \
   version of the linker

                 === gdb Summary ===

 # of untested testcases         1
...

Fix the dwarf assembly test-cases by adding the missing .note.GNU-stack in
proc Dwarf::assemble.

Fix the hard-coded test-cases using this command:
...
$ for f in $(find gdb/testsuite/gdb.* -name *.S); do
    if ! grep -q note.GNU-stack $f; then
      echo -e "\t.section\t.note.GNU-stack,\"\",@progbits" >> $f;
    fi;
  done
...

Likewise for .s files, and gdb/testsuite/lib/my-syscalls.S.

The idiom for arm seems to be to use %progbits instead, see commit 9a5911c08be
("gdb/testsuite/gdb.dwarf2: Replace @ with % for ARM compatability"), so
hand-edit gdb/testsuite/gdb.arch/arm-disp-step.S to use %progbits instead.

Note that dwarf assembly testcases use %progbits as decided by proc _section.

Tested on x86_64-linux.

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

[gdb/testsuite] Add missing skip_gdbserver_tests in gdb.multi/attach-no-multi-process.exp

I build gdb without gdbserver, and ran into:
...
(gdb) PASS: gdb.multi/attach-no-multi-process.exp: target_non_stop=off: \
  switch to inferior 2
spawn of  --once --multi localhost:2346 failed
ERROR: tcl error sourcing attach-no-multi-process.exp.
ERROR: tcl error code NONE
ERROR: Timeout waiting for gdbserver response.
...

Add the missing skip_gdbserver_tests.

Tested on x86_64-linux.

[gdb] Rewrite RETHROW_ON_TARGET_CLOSE_ERROR into function

Recent commit b2829fcf9b5 ("[gdb] Fix rethrow exception slicing in
insert_bp_location") introduced macro RETHROW_ON_TARGET_CLOSE_ERROR.

I wrote this as a macro in order to have the rethrowing throw be part of the
same function as the catch, but as it turns out that's not necessary.

Rewrite into a function.

Tested on x86_64-linux.

gdb: internal_error -> internal_error_loc in gdb-gdb.gdb.in

Commit f34652de0b ("internal_error: remove need to pass
__FILE__/__LINE__") renamed the internal_error function to
internal_error_loc.  Change gdb-gdb.gdb.in accordingly.

Change-Id: I876e1623607b6becf74ade53d102ead53a74ed86

RISC-V: Should reset `again' flag for _bfd_riscv_relax_pc.

The R_RISCV_DELETE relocations are no longer deleted at another relax pass,
so we should reset 'again' flag to true for _bfd_riscv_relax_pc, while the
deleted bytes are marked as R_RISCV_DELETE.

bfd/
    * elfnn-riscv.c (_bfd_riscv_relax_pc): Set `again' to true while the
    deleted bytes are marked as R_RISCV_DELETE.

RISC-V: Improve link time complexity.

The riscv port does deletion and symbol table update for each relocation
while relaxing, so we are moving section bytes and scanning symbol table once
for each relocation.  Compared to microblaze port, they record the relaxation
changes into a table, then do the deletion and symbol table update once per
section, rather than per relocation.  Therefore, they should have better link
time complexity than us.

To improve the link time complexity, this patch try to make the deletion in
linear time.  Compared to record the relaxation changes into a table, we
replace the unused relocation with R_RISCV_DELETE for the deleted bytes, and
then resolve them at the end of the section.  Assuming the number of
R_RISCV_DELETE is m, and the number of symbols is n, the total link complexity
should be O(m) for moving section bytes, and O(m*n^2) for symbol table update.
If we record the relaxation changes into the table, and then sort the symbol
table by values, then probably can reduce the time complexity to O(m*n*log(n))
for updating symbol table, but it doesn't seem worth it for now.

bfd/
    * elfnn-riscv.c (_riscv_relax_delete_bytes): Renamed from
    riscv_relax_delete_bytes, updated to reduce the tiem complexity to O(m)
    for memmove.
    (typedef relax_delete_t): Function pointer declaration of delete functions.
    (riscv_relax_delete_bytes): Can choose to use _riscv_relax_delete_piecewise
    or _riscv_relax_delete_immediate for deletion.
    (_riscv_relax_delete_piecewise): Just mark the deleted bytes as R_RISCV_DELETE.
    (_riscv_relax_delete_immediate): Delete some bytes from a section while
    relaxing.
    (riscv_relax_resolve_delete_relocs): Delete the bytes for R_RISCV_DELETE
    relocations from a section, at the end of _bfd_riscv_relax_section.
    (_bfd_riscv_relax_call): Mark deleted bytes as R_RISCV_DELETE by reusing
    R_RISCV_RELAX.
    (_bfd_riscv_relax_lui): Likewise, but reuse R_RISCV_HI20 for lui, and reuse
    R_RISCV_RELAX for c.lui.
    (_bfd_riscv_relax_tls_le): Likewise, but resue R_RISCV_TPREL_HI20 and
    R_RISCV_TPREL_ADD.
    (_bfd_riscv_relax_pc): Likewise, but resue R_RISCV_PCREL_HI20 for auipc.
    (_bfd_riscv_relax_align): Updated, don't need to resue relocation since
    calling _riscv_relax_delete_immediate.
    (_bfd_riscv_relax_delete): Removed.
    (_bfd_riscv_relax_section): Set riscv_relax_delete_bytes for each relax_func,
    to delete bytes immediately or later.  Call riscv_relax_resolve_delete_relocs
    to delete bytes for DELETE relocations from a section.

Automatic date update in version.in

gdb/doc: reword description of DisassembleInfo.read_memory

While reading the documentation of DisassembleInfo.read_memory I
spotted the word 'available' in one sentence where it didn't make
sense.

sim/lm32: fix some missing function declaration warnings

In the lm32 simulator, I was seeing some warnings about missing
function declarations.

The lm32 simulator has a weird header structure, in order to pull in
the full cpu.h header we need to define WANT_CPU_LM32BF.  This is done
in some files, but not in others.  Critically, it's not done in some
files that then use functions declared in cpu.h

In this commit I added the missing #define so that the full cpu.h can
be included.

After doing this there are still a few functions that are used
undeclared, these functions appear to be missing any declarations at
all, so I've added some to cpu.h.

With this done all the warnings when compiling lm32 are resolved for
both gcc and clang, so I've removed the SIM_WERROR_CFLAGS line from
Makefile.in, this allows lm32 to build with -Werror.

sim/h8300: avoid self assignment

There are two places in the h8300 simulator where we assign a variable
to itself.  Clang gives a warning for this, which is converted into an
error by -Werror.

Silence the warning by removing the self assignments.  As these
assignments were in a complex if/then/else tree, rather than try to
adjust all the conditions, I've just replaced the self assignments
with a comment and an empty statement.

sim/aarch64: remove two unused functions

These functions are not used.  Clang warns about the unused functions,
which is then converted into an error by -Werror.

Delete the unused functions.

sim/ppc: fix for operator precedence warning from clang

In the ppc simulator, clang was warning about some code like this:

  busy_ptr->nr_writebacks = 1 + (PPC_ONE_BIT_SET_P(out_vmask)) ? 1 : 2;

The warning was:

  operator '?:' has lower precedence than '+'; '+' will be evaluated first

I suspect that this is not the original authors intention.
PPC_ONE_BIT_SET_P is going to be 0 or 1, so if we evaluate the '+'
first, the condition will always be non-zero, so true.  The whole
expression could then be simplified to just '1', which doesn't make
much sense.

I suspect the answer the author was expecting was either 2 or 3.  Why
they didn't just write:

  busy_ptr->nr_writebacks = (PPC_ONE_BIT_SET_P(out_vmask)) ? 2 : 3;

I have no clue, however, to keep the structure of the code unchanged,
I've updated things to:

  busy_ptr->nr_writebacks = 1 + (PPC_ONE_BIT_SET_P (out_vmask) ? 1 : 2);

which silences the warning from clang, and is, I am guessing, what the
original author intended.

sim/ppc: initialize a memory buffer in all cases

In the ppc simulator's do_fstat function, which provides the fstat
call for the simulator, if the fstat is going to fail then we
currently write an uninitialized buffer into the simulated target.

In theory, I think this is fine, we also write the error status into
the simulated target, so, given that the fstat has failed, the target
shouldn't be relying on the buffer contents.

However, writing an uninitialized buffer means we might leak simulator
private data into the simulated target, which is probably a bad thing.
Plus it probably makes life easier if something consistent, like all
zeros, is written rather than random junk, which might look like a
successful call (except for the error code).

So, in this commit, I initialize the stat buffer to zero before
it is potentially used.  If the stat call is not made then the buffer
will be left initialized as all zeros.

sim/ppc: don't try to print an uninitialized variable

The ppc simulator, in sim_create_inferior, tries to print the function
local entry_point variable before the variable is initialized.

In this commit, I defer the debug print line until the variable has
been initialized.

sim/sh: use fabs instead of abs

The sh simulator incorrectly uses integer abs instead of the floating
point fabs on some floating point values, fixed in this commit.

[gdb] Fix rethrow exception slicing in insert_bp_location

The preferred way of rethrowing an exception is by using throw without
expression, because it avoids object slicing of the exception [1].

Fix this in insert_bp_location.

Tested on x86_64-linux.

[1] https://en.cppreference.com/w/cpp/language/throw

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

[gdb] Fix rethrow exception slicing in pretty_print_insn

The preferred way of rethrowing an exception is by using throw without
expression, because it avoids object slicing of the exception [1].

Fix this in gdb_pretty_print_disassembler::pretty_print_insn.

Tested on x86_64-linux.

[1] https://en.cppreference.com/w/cpp/language/throw

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

ld/testsuite: adjust ld-arm to run shared tests only when supported

If a custom arm-elf target is disabling the shared support, a lot of
failures are reported by the testsuite.
Moreover, some tests try to access libraries which have been explicitly
skipped earlier (eg mixed-lib.so).

ld/ChangeLog:

* testsuite/ld-arm/arm-elf.exp: Separate tests needing shared
lib support.

ld/testsuite: skip ld-elf/exclude when -shared is not supported

ld/ChangeLog:

* testsuite/ld-elf/exclude.exp: Call check_shared_lib_support.
to skip for all targets without shared lib support.

x86: consolidate VPCLMUL tests

There's little point in having Intel syntax disassembler tests when the
purpose of a test is assembler functionality: Drop all
*avx512*_vpclmulqdq-wig1-intel.

For *avx512*_vpclmulqdq-wig1 share source with *avx512*_vpclmulqdq.

Finally put in place similar tests for -mvexwig=1.

x86: consolidate VAES tests

There's little point in having Intel syntax disassembler tests when the
purpose of a test is assembler functionality: Drop all
*avx512*_vaes-wig1-intel.

For *avx512*_vaes-wig1 share source with *avx512*_vaes. This in
particular makes sure that the 32-bit VL test actually tests any EVEX
encodings in the first place.

Finally put in place similar tests for -mvexwig=1.

x86: emit {evex} prefix when disassembling ambiguous AVX512VL insns

When no AVX512-specific functionality is in use, the disassembly of
AVX512VL insns is indistinguishable from their AVX counterparts (if such
exist). Emit the {evex} pseudo-prefix in such cases.

Where applicable drop stray uses of PREFIX_OPCODE from table entries.

[gdb/testsuite] Add skip_python_tests in gdb.python/tui-window-names.exp

I did a gdb build without python support, and during testing ran into FAILs in
test-case gdb.python/tui-window-names.exp.

Fix this by adding the missing skip_python_test.

Tested on x86_64-linux.

Automatic date update in version.in

sim: testsuite: update ignored .exp files [PR sim/29596]

Now that we run `check/foo.exp` instead of `check/./foo.exp`,
update the config/ & lib/ exceptions to cover both paths.

Bug: https://sourceware.org/PR29596

sim: testsuite: tweak parallel find invocation [PR sim/29596]

Make sure we invoke runtest with the same exp filenames when running in
parallel as it will find when run single threaded.  When `runtest` finds
files itself, it will use paths like "aarch64/allinsn.exp".  When we run
`find .` with the %p option, it produces "./aarch64/allinsn.exp".  Switch
to %P to get "aarch64/allinsn.exp".

Bug: https://sourceware.org/PR29596

sim: mips/ppc/riscv: re-add AC_CANONICAL_SYSTEM [PR sim/29439]

These configure scripts check $target and change behavior.  They
shouldn't be doing that, but until we can rework the sim to change
behavior based on the input ELF, restore AC_CANONICAL_SYSTEM to
these so that $target is correctly populated.

This was lost in the d3562f83a7b8a1ae6e333cd5561419d3da18fcb4
("sim: unify toolchain probing logic") refactor as the logic was
hoisted up to the common code.  But the fact the vars weren't
passed down to the sub-configure scripts was missed.

Bug: https://sourceware.org/PR29439

Automatic date update in version.in

gdb/testsuite: add max number of instructions check in gdb.base/unwind-on-each-insn.exp

This test sends my CI in an infinite loop of failures.   We expect to
have a handful of iterations (5 on my development machine, where the
test passes fine)but the log shows that it went up to 104340 iterations:

    FAIL: gdb.base/unwind-on-each-insn.exp - instruction 104340: maint print frame-id
    DUPLICATE: gdb.base/unwind-on-each-insn.exp - instruction 104340: maint print frame-id
    FAIL: gdb.base/unwind-on-each-insn.exp - instruction 104340: [string equal $fid $main_fid]
    FAIL: gdb.base/unwind-on-each-insn.exp - instruction 104340: get hexadecimal valueof "$pc"

Add a max instruction check, exit the loop if we reach 100 iterations.
This should allow the test to fail fast if there's a problem, but 100
iterations should be more than enough for when things are working.

Change-Id: I77978d593aca046068f9209272d82e1675ba17c2

Automatic date update in version.in

Improve Python Unwinders documentation

- avoid "GDB proper" to refer to global locus, as object files and
  program spaces are also GDB proper.

- gdb.register_unwinder does not accept locus=gdb.

- "a unwinder" -> "an unwinder"

Approved-by: Eli Zaretskii <eliz@gnu.org>
Change-Id: I98c1b1000e1063815238e945ca71ec6f37b5702e

gdb: make inherit_abstract_dies use vector iterators

Small cleanup to use std::vector iterators rather than raw pointers.

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

gdb: check for empty offsets vector in inherit_abstract_dies

When building GDB with clang and --enable-ubsan, I get:

  UNRESOLVED: gdb.dwarf2/frame-inlined-in-outer-frame.exp: starti prompt

The cause being:

    $ ./gdb --data-directory=data-directory -nx -q -readnow testsuite/outputs/gdb.dwarf2/frame-inlined-in-outer-frame/frame-inlined-in-outer-frame
    Reading symbols from testsuite/outputs/gdb.dwarf2/frame-inlined-in-outer-frame/frame-inlined-in-outer-frame...
    Expanding full symbols from testsuite/outputs/gdb.dwarf2/frame-inlined-in-outer-frame/frame-inlined-in-outer-frame...
    /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:11954:47: runtime error: applying non-zero offset 8 to null pointer

I found this to happen with ld-linux on at least Arch Linux and Ubuntu
22.04:

    $ ./gdb --data-directory=data-directory -nx -q -readnow -iex "set debuginfod enabled on" /lib64/ld-linux-x86-64.so.2
    Reading symbols from /lib64/ld-linux-x86-64.so.2...
    Reading symbols from /home/simark/.cache/debuginfod_client/22bd7a2c03d8cfc05ef7092bfae5932223189bc1/debuginfo...
    Expanding full symbols from /home/simark/.cache/debuginfod_client/22bd7a2c03d8cfc05ef7092bfae5932223189bc1/debuginfo...
    /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:11954:47: runtime error: applying non-zero offset 8 to null pointer

The problem happens when doing this:

    sect_offset *offsetp = offsets.data () + 1

When `offsets` is an empty vector, `offsets.data ()` returns nullptr.
Fix it by wrapping that in a `!offsets.empty ()` check.

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

readelf: support zstd compressed debug sections [PR 29640]

Fix incorrect .gdb_index with new DWARF scanner

PR symtab/29694 points out a regression caused by the new DWARF
scanner when the cc-with-gdb-index target board is used.

What happens here is that an older version of gdb will make an index
describing the "A" type as:

[737] A: 1 [global, type]

whereas the new gdb says:

[1008] A: 0 [global, type]

Here the old one is correct because the A in CU 0 is just a
declaration without a size:

 <1><45>: Abbrev Number: 10 (DW_TAG_structure_type)
    <46>   DW_AT_name        : A
    <48>   DW_AT_declaration : 1
    <48>   DW_AT_sibling     : <0x6d>

This patch fixes the problem by introducing the idea of a "type
declaration".  I think gdb still needs to recurse into these types,
searching for methods, but by marking the type itself as a
declaration, gdb can skip this type during lookups and when writing
the index.

Regression tested on x86-64 using the cc-with-gdb-index board.

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

Fix crash in value_print_array_elements

A user noticed that gdb would crash when printing a packed array after
doing "set lang c".  Packed arrays don't exist in C, but it's
occasionally useful to print things in C mode when working in a non-C
language -- this lets you see under the hood a little bit.

The bug here is that generic value printing does not handle packed
arrays at all.  This patch fixes the bug by introducing a new function
to extract a value from a bit offset and width.

The new function includes a hack to avoid problems with some existing
test cases when using -fgnat-encodings=all.  Cleaning up this code
looked difficult, and since "all" is effectively deprecated, I thought
it made sense to simply work around the problems.

Fix bug in Ada packed array handling

A user found a bug where an array of packed arrays was printed
incorrectly.  The bug here is that the packed array has a bit stride,
but the outer array does not -- and should not.  However,
update_static_array_size does not distinguish between an array of
packed arrays and a multi-dimensional packed array, and for the
latter, only the innermost array will end up with a stride.

This patch fixes the problem by adding a flag to indicate whether a
given array type is a constituent of a multi-dimensional array.

gdb: declare variables on first use in inherit_abstract_dies

Move variable declarations to where they are first use, plus some random
style fixes.

Change-Id: Idf40d60f9034996fa6a234165cd989a721eb4148

Add a -w option to the linker to suppress warning and error messages.

PR 29654
* ld.h (struct ld_config_type): Add no_warnings field.
* ldlex.h (enum option_values): Add OPTION_NO_WARNINGS.
* lexsup.c (ld_options): Add --no-warnings.
(parse_args): Add support for -w and --no-warnings.
* ldmisc.c (vfinfo): Return early if the message is a warning and
-w has been enabled.
* ld.texi (options): Document new command line option.
* NEWS: Mention the new feature.

Add a note to the binutils/NEWS file about DCO signed contributions.

gdb/reverse: Fix stepping over recursive functions

Currently, when using GDB to do reverse debugging, if we try to use the
command "reverse next" to skip a recursive function, instead of skipping
all of the recursive calls and stopping in the previous line, we stop at
the second to last recursive call, and need to manually step backwards
until we leave the first call.  This is well documented in PR gdb/16678.

This bug happens because when GDB notices that a reverse step has
entered into a function, GDB will add a step_resume_breakpoint at the
start of the function, then single step out of the prologue once that
breakpoint is hit.  The problem was happening because GDB wouldn't give
that step_resume_breakpoint a frame-id, so the first time the breakpoint
was hit, the inferior would be stopped.  This is fixed by giving the
current frame-id to the breakpoint.

This commit also changes gdb.reverse/step-reverse.c to contain a
recursive function and attempt to both, skip it altogether, and to skip
the second call from inside the first call, as this setup broke a
previous version of the patch.

Change calculation of frame_id by amd64 epilogue unwinder

When GDB is stopped at a ret instruction and no debug information is
available for unwinding, GDB defaults to the amd64 epilogue unwinder, to
be able to generate a decent backtrace. However, when calculating the
frame id, the epilogue unwinder generates information as if the return
instruction was the whole frame.

This was an issue especially when attempting to reverse debug, as GDB
would place a step_resume_breakpoint from the epilogue of a function if
we were to attempt to skip that function, and this breakpoint should
ideally have the current function's frame_id to avoid other problems
such as PR record/16678.

This commit changes the frame_id calculation for the amd64 epilogue,
so that it is always the same as the dwarf2 unwinder's frame_id.

It also adds a test to confirm that the frame_id will be the same,
regardless of using the epilogue unwinder or not, thanks to Andrew
Burgess.

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

Updated Hungarian translation for the gprof sub-directory.

* po/hu.po: Updated Hungarian translation.

GDB/Python: Make `None' stand for `unlimited' in setting integer parameters

Similarly to booleans and following the fix for PR python/29217 make
`gdb.parameter' accept `None' for `unlimited' with parameters of the
PARAM_UINTEGER, PARAM_INTEGER, and PARAM_ZUINTEGER_UNLIMITED types, as
`None' is already returned by parameters of the two former types, so
one might expect to be able to feed it back.  It also makes it possible
to avoid the need to know what the internal integer representation is
for the special setting of `unlimited'.

Expand the testsuite accordingly.

Approved-By: Simon Marchi <simon.marchi@polymtl.ca>

GDB/testsuite: Expand Python integer parameter coverage across all types

Also verify PARAM_UINTEGER, PARAM_INTEGER, and PARAM_ZINTEGER parameter
types, in addition to PARAM_ZUINTEGER and PARAM_ZUINTEGER_UNLIMITED
already covered, and verify a choice of existing GDB parameters.  Add
verification for reading parameters via `<parameter>.value' in addition
to `gdb.parameter('<parameter>')' as this covers different code paths.

Approved-By: Simon Marchi <simon.marchi@polymtl.ca>

GDB/Guile: Don't assert that an integer value is boolean

Do not assert that a value intended for an integer parameter, of either
the PARAM_UINTEGER or the PARAM_ZUINTEGER_UNLIMITED type, is boolean,
causing error messages such as:

ERROR: In procedure make-parameter:
ERROR: In procedure gdbscm_make_parameter: Wrong type argument in position 15 (expecting integer or #:unlimited): 3
Error while executing Scheme code.

when initialization with a number is attempted.  Instead assert that it
is integer.  Keep matching `#:unlimited' keyword as an alternative.  Add
suitable test cases.

Approved-By: Simon Marchi <simon.marchi@polymtl.ca>

[gdb/testsuite] Silence compilation fail in gdb.base/rtld-step.exp

With gcc 7.5.0 and test-case gdb.base/rtld-step.exp, I run into:
...
gdb compile failed, gcc: error: unrecognized command line option \
  '-static-pie'; did you mean '-static'?
...

Silence this by checking in the test-case that -static-pie is supported, and
emitting instead:
...
UNTESTED: gdb.base/rtld-step.exp: \
  failed to compile (-static-pie not supported or static libc missing)
...

Tested on x86_64-linux, with:
- gcc 7.5.0: UNTESTED
- gcc 12.2.1 with static glibc not installed: UNTESTED
- gcc 12.2.1 with static glibc installed: PASS

Support Intel AMX-FP16

gas/

* NEWS: Add support for Intel AMX-FP16 instruction.
* config/tc-i386.c: Add amx_fp16.
* doc/c-i386.texi: Document .amx_fp16.
* testsuite/gas/i386/i386.exp: Add AMX-FP16 tests.
* testsuite/gas/i386/x86-64-amx-fp16-intel.d: New test.
* testsuite/gas/i386/x86-64-amx-fp16.d: Likewise.
* testsuite/gas/i386/x86-64-amx-fp16.s: Likewise.
* testsuite/gas/i386/x86-64-amx-fp16-bad.d: Likewise.
* testsuite/gas/i386/x86-64-amx-fp16-bad.s: Likewise.

opcodes/

* i386-dis.c (MOD_VEX_0F385C_X86_64_P_3_W_0): New.
(VEX_LEN_0F385C_X86_64_P_3_W_0_M_0): Likewise.
(VEX_W_0F385C_X86_64_P_3): Likewise.
(prefix_table): Add VEX_W_0F385C_X86_64_P_3.
(vex_len_table): Add VEX_LEN_0F385C_X86_64_P_3_W_0_M_0.
(vex_w_table): Add VEX_W_0F385C_X86_64_P_3.
(mod_table): Add MOD_VEX_0F385C_X86_64_P_3_W_0.
* i386-gen.c (cpu_flag_init): Add AMX-FP16_FLAGS.
(CPU_ANY_AMX_TILE_FLAGS): Add CpuAMX_FP16.
(cpu_flags): Add CpuAMX-FP16.
* i386-opc.h (enum): Add CpuAMX-FP16.
(i386_cpu_flags): Add cpuamx_fp16.
* i386-opc.tbl: Add Intel AMX-FP16 instruction.
* i386-init.h: Regenerate.
* i386-tbl.h: Likewise.

sim: Remove unused CXXFLAGS substitution

Not only that sim/configure.ac does not AC_SUBST CXXFLAGS,
unless we need C++ compiler like CXX, substitution @CXXFLAGS@ is useless.
Because of this, this commit removes this substitution.

Automatic date update in version.in

x86: Check VEX/EVEX encoding before checking vector operands

Since

commit 837e225ba1992f9745e5bbbd5e8443243a7f475f
Author: Jan Beulich <jbeulich@suse.com>
Date:   Thu Oct 20 10:01:12 2022 +0200

    x86: re-work AVX-VNNI support

moved AVX-VNNI after AVX512-VNNI, vector Disp8 is applied even when VEX
encoding is selected.  Check VEX/EVEX encoding before checking vector
operands to avoid vector Disp8 with VEX encoding.

PR gas/29708
* config/tc-i386.c (match_template): Check VEX/EVEX encoding
before checking vector operands.
* testsuite/gas/i386/avx-vnni.d: Updated.
* testsuite/gas/i386/x86-64-avx-vnni.d: Likewise.
* testsuite/gas/i386/avx-vnni.s: Add a Disp32 test.
* testsuite/gas/i386/x86-64-avx-vnni.s: Likewise.

gdb/python: break more dependencies between gdbpy_initialize_* functions

In a later commit in this series I will propose removing all of the
explicit gdbpy_initialize_* calls from python.c and replace these
calls with a more generic mechanism.

One of the side effects of this generic mechanism is that the order in
which the various Python sub-systems within GDB are initialized is no
longer guaranteed.

On the whole I don't think this matters, most of the sub-systems are
independent of each other, though testing did reveal a few places
where we did have dependencies, though I don't think those
dependencies were explicitly documented in comment anywhere.

This commit is similar to the previous one, and fixes the second
dependency issue that I found.

In this case the finish_breakpoint_object_type uses the
breakpoint_object_type as its tp_base, this means that
breakpoint_object_type must have been initialized with a call to
PyType_Ready before finish_breakpoint_object_type can be initialized.

Previously we depended on the ordering of calls to
gdbpy_initialize_breakpoints and gdbpy_initialize_finishbreakpoints in
python.c.

After this commit a new function gdbpy_breakpoint_init_breakpoint_type
exists, this function ensures that breakpoint_object_type has been
initialized, and can be called from any gdbpy_initialize_* function.

I feel that this change makes the dependency explicit, which I think
is a good thing.

There should be no user visible changes after this commit.

gdb/python: break dependencies between gdbpy_initialize_* functions

In a later commit in this series I will propose removing all of the
explicit gdbpy_initialize_* calls from python.c and replace these
calls with a more generic mechanism.

One of the side effects of this generic mechanism is that the order in
which the various Python sub-systems within GDB are initialized is no
longer guaranteed.

On the whole I don't think this matters, most of the sub-systems are
independent of each other, though testing did reveal a few places
where we did have dependencies, though I don't think those
dependencies were explicitly documented in a comment anywhere.

This commit removes the first dependency issue, with this and the next
commit, all of the implicit inter-sub-system dependencies will be
replaced by explicit dependencies, which will allow me to, I think,
clean up how the sub-systems are initialized.

The dependency is around the py_insn_type.  This type is setup in
gdbpy_initialize_instruction and used in gdbpy_initialize_record.
Rather than depend on the calls to these two functions being in a
particular order, in this commit I propose adding a new function
py_insn_get_insn_type.  This function will take care of setting up the
py_insn_type type and calling PyType_Ready.  This helper function can
be called from gdbpy_initialize_record and
gdbpy_initialize_instruction, and the py_insn_type will be initialized
just once.

To me this is better, the dependency is now really obvious, but also,
we no longer care in which order gdbpy_initialize_record and
gdbpy_initialize_instruction are called.

There should be no user visible changes after this commit.

gdb: some int to bool conversion in breakpoint.c

Some int to bool conversion in breakpoint.c.  I've only updated the
function signatures of static functions, but I've updated some
function local variables throughout the file.

There should be no user visible changes after this commit.

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

gdb: make use of scoped_restore in unduplicated_should_be_inserted

I noticed that we could make use of a scoped_restore in the function
unduplicated_should_be_inserted.  I've also converted the function
return type from int to bool.

This change shouldn't make any difference, as I don't think anything
within should_be_inserted could throw an exception, but the change
doesn't hurt, and will help keep us safe if anything ever changes in
the future.

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

gdb: used scoped_restore_frame in update_watchpoint

I was doing some int to bool cleanup in update_watchpoint, and I
noticed a manual version of scoped_restore_selected_frame.  As always
when these things are done manually, there is the chance that, in an
error case, we might leave the wrong frame selected.

This commit updates things to use scoped_restore_selected_frame, and
also converts a local variable from int to bool.

The only user visible change after this commit is in the case where
update_watchpoint throws an error - we should now correctly restore
the previously selected frame.  Otherwise, this commit should be
invisible to the user.

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

gdb: make some bp_location arguments const in breakpoint.c

I spotted a few places where I could make some 'bp_location *'
arguments constant in breakpoint.c.

There should be no user visible changes after this commit.

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

Reapply "Don't build readline/libreadline.a, when --with-system-readline is supplied"

Commit 228cf97dd3c8 ("Merge configure.ac from gcc project") undid the
change originally done in commit 69961a84c9b ("Don't build
readline/libreadline.a, when --with-system-readline is supplied").
Re-apply it.

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

x86: re-work AVX-VNNI support

By putting the templates after their AVX512 counterparts, the AVX512
flavors will be picked by default. That way the need to always use {vex}
ceases to exist once respective CPU features (AVX512-VNNI or AVX512VL as
a whole) have been disabled. This way the need for the PseudoVexPrefix
attribute also disappears.

[gdb/testsuite] Fix gdb.debuginfod/fetch_src_and_symbols.exp with check-read1

With test-case gdb.debuginfod/fetch_src_and_symbols.exp and check-read1, I run
into:
...
(gdb) FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: local_url: \
  file fetch_src_and_symbols (got interactive prompt)
...

The problem is that this output:
...
Enable debuginfod for this session? (y or [n]) y^M
...
is matched using regexp "Enable debuginfod?.*" with matches only the first two
words of the output, after which an implicit clause in gdb_test_multiple triggers
on the second part containing the interactive prompt.

Fix this by included the interactive prompt in the regexp.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.mi/mi-disassemble.exp with check-read1

With test-case gdb.mi/mi-disassemble.exp and check-read1 I run into:
...
FAIL: gdb.mi/mi-disassemble.exp: disassemble /b main
FAIL: gdb.mi/mi-disassemble.exp: get valueof "*((unsigned char *) 0x400549)"
...

The problem for both FAILs is that the output is parsed using
gdb_test_multiple, which has implicit clauses using $gdb_prompt, which can
match before the explicit clauses using $mi_gdb_prompt.

Fix this by passing -prompt "$mi_gdb_prompt$" to gdb_test_multiple.

Tested on x86-64-linux.

Re: aarch64-pe support for LD, GAS and BFD

Fix dependencies for eaarch64pe.c.  Generated files aren't handled
fully automatically.

ld: Add minimal pdb generation

ld: Add --pdb option

Second patch incorporates fixes for endian and UB issues in calc_hash, as per
https://sourceware.org/pipermail/binutils/2022-October/123514.html.

Test stepping within a runtime loader / dynamic linker

See the remarks in rtld-step.exp for a description of what this
test is about.

This test case has been tested using gcc on the following x86-64 Linux
distributions/releases:

    Fedora 28
    Fedora 32
    Fedora 33
    Fedora 34
    Fedora 35
    Fedora 36
    Fedora 37
    rawhide (f38)
    RHEL 9.1
    Ubuntu 22.04.1 LTS

It's also been tested (and found to be working) with
RUNTESTFLAGS="CC_FOR_TARGET=clang" on all of the above expect for
Fedora 28.  The (old) version of clang available on F28 did not
accept the -static-pie option.

I also tried to make this test work on FreeBSD 13.1.  While I think I
made significant progress, I was ultimately stymied by this message
which occurs when attempting to run the main program which has been
set to use the fake/pretend RTLD as the ELF interpreter:

ELF interpreter /path/to/rtld-step-rtld not found, error 22

I have left one of the flags (-static) in place which I believe
to be needed for FreeBSD (though since I never got it to work, I
don't know for sure.)  I've also left some declarations needed
for FreeBSD in rtld-step-rtld.c.  They're currently disabled via
a #if 0; you'll need to enable them if you want to try to make
it work on FreeBSD.

Allow debugging of runtime loader / dynamic linker

At present, GDB does not allow for the debugging of the runtime loader
and/or dynamic linker.  Much of the time, this makes sense.  An
application programmer doesn't normally want to see symbol resolution
code when stepping into a function that hasn't been resolved yet.

But someone who wishes to debug the runtime loader / dynamic linker
might place a breakpoint in that code and then wish to debug it
as normal.  At the moment, this is not possible.  Attempting to step
will cause GDB to internally step (and not stop) until code
unrelated to the dynamic linker is reached.

This commit makes a minor change to infrun.c which allows the dynamic
loader / linker to be debugged in the case where a step, next, etc.
is initiated from within that code.

While developing this fix, I tried some approaches which weren't quite
right.  The GDB testusite definitely contains tests which FAIL when
it's done incorrectly.  (At one point, I saw 17 regressions!) This
commit has been tested on x86-64 linux with no regressions.

binutils: Remove unused substitution PROGRAM

Unlike other substitution, this substitution of @PROGRAM@ was done in
binutils/Makefile and it was intended for binutils/cxxfilt.man.  @PROGRAM@
in binutils/cxxfilt.man is removed in the commit 0285c67df190 ("Automate
generate on man pages") in 2001 and @PROGRAM@ is ineffective since then.

Because PROGRAM substitution does nothing, removing this manual
substitution should be completely safe.

binutils/ChangeLog:

* doc/local.mk: Remove unused substitution PROGRAM.
* Makefile.in: Regenerate.

Automatic date update in version.in

Obsolete beos

* config.bfd: Obsolete *-*-beos*.  Simplify x86 beos match.

Regen ld/po/BLD-POTFILES.in

[gdb] Fix assert in handle_jit_event

With the cc-with-tweaks.sh patch submitted here (
https://sourceware.org/pipermail/gdb-patches/2022-October/192586.html ) we run
with:
...
$ export STRIP_ARGS_STRIP_DEBUG=--strip-all
$ make check RUNTESTFLAGS="gdb.base/jit-reader.exp \
    --target_board cc-with-gnu-debuglink"
...
into the following assert:
...
(gdb) run ^M
Starting program: jit-reader ^M
gdb/jit.c:1247: internal-error: jit_event_handler: \
  Assertion `jiter->jiter_data != nullptr' failed.^M
...

Fix this by handling the
jit_bp_sym.objfile->separate_debug_objfile_backlink != nullptr case in
handle_jit_event.

Tested on x86_64-linux.

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

internal_error: remove need to pass __FILE__/__LINE__

Currently, every internal_error call must be passed __FILE__/__LINE__
explicitly, like:

  internal_error (__FILE__, __LINE__, "foo %d", var);

The need to pass in explicit __FILE__/__LINE__ is there probably
because the function predates widespread and portable variadic macros
availability.  We can use variadic macros nowadays, and in fact, we
already use them in several places, including the related
gdb_assert_not_reached.

So this patch renames the internal_error function to something else,
and then reimplements internal_error as a variadic macro that expands
__FILE__/__LINE__ itself.

The result is that we now should call internal_error like so:

  internal_error ("foo %d", var);

Likewise for internal_warning.

The patch adjusts all calls sites.  99% of the adjustments were done
with a perl/sed script.

The non-mechanical changes are in gdbsupport/errors.h,
gdbsupport/gdb_assert.h, and gdb/gdbarch.py.

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

Fix an illegal memory access when parsing an ELF file containing corrupt symbol version information.

PR 29699
* elf.c (_bfd_elf_slurp_version_tables): Fail if the sh_info field
of the section header is zero.

sim/iq2000: silence pointer-sign warnings

When building the iq2000 simulator I see a few warnings like this:

  /tmp/build/sim/../../src/sim/iq2000/iq2000.c: In function ‘fetch_str’:
  /tmp/build/sim/../../src/sim/iq2000/iq2000.c:50:54: error: pointer targets in passing argument 3 of ‘sim_read’ differ in signedness [-Werror=pointer-sign]
     50 |   sim_read (CPU_STATE (current_cpu), CPU2DATA(addr), buf, nr);
        |                                                      ^~~
        |                                                      |
        |                                                      char *

I've silenced these warnings by casting buf to 'unsigned char *'.
With this change I now see no warnings when compiling iq2000.c, so
I've removed the line from Makefile.in that disables -Werror.

Makefile.in was also disabling -Werror when compiling mloop.c,
however, I'm not seeing any warnings when compiling that file, so I've
removed the -Werror disable in that case too.

sim/erc32: avoid dereferencing type-punned pointer warnings

When building the erc32 simulator I get a few warnings like this:

  /tmp/build/sim/../../src/sim/erc32/exec.c:1377:21: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   1377 |   sregs->fs[rd] = *((float32 *) & ddata[0]);
        |                    ~^~~~~~~~~~~~~~~~~~~~~~~

The type of '& ddata[0]' will be 'uint32_t *', which is what triggers
the warning.

This commit makes use of memcpy when performing the type-punning,
which resolves the above warnings.

With this change, I now see no warnings when compiling exec.c, which
means that the line in Makefile.in that disables -Werror can be
removed.

There should be no change in behaviour after this commit.

sim/ppc: mark device_error function as ATTRIBUTE_NORETURN

The device_error function always ends up calling the error function,
which is itself marked as ATTRIBUTE_NORETURN, so it makes sense that
device_error should also be marked ATTRIBUTE_NORETURN.

Doing this resolves a few warnings from hw_ide.c about possibly
uninitialized variables - the variables are only uninitialized after
passing through a call to device_error, which obviously means the
variables are never really used uninitialized, the simulation will
terminate with the device_error call.

sim/ppc: fix warnings related to printf format strings

This commit is a follow on to:

  commit 182421c9d2eea8c4877d983a2124e591f0aca710
  Date:   Tue Oct 11 15:02:08 2022 +0100

      sim/ppc: fixes for arguments to printf style functions

where commit 182421c9d2ee addressed issues with printf format
arguments that were causing the compiler to give an error, this commit
addresses issues that caused the compiler to emit a warning.

This commit is mostly either changing the format string to match the
argument, or in some cases, excess, unused arguments are removed.

sim/cgen: mask uninitialized variable warning in cgen-run.c

I see an uninitialized variable warning (with gcc 9.3.1) from
cgen-run.c, like this:

  /tmp/build/sim/../../src/sim/cris/../common/cgen-run.c: In function ‘sim_resume’:
  /tmp/build/sim/../../src/sim/cris/../common/cgen-run.c:259:5: warning: ‘engine_fns$’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    259 |    (* engine_fns[next_cpu_nr]) (cpu);
        |    ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /tmp/build/sim/../../src/sim/cris/../common/cgen-run.c:232:14: note: ‘engine_fns$’ was declared here
    232 |   ENGINE_FN *engine_fns[MAX_NR_PROCESSORS];
        |              ^~~~~~~~~~

This is a false positive - we over allocate engine_fn, and then only
initialize the nr_cpus entries which we will later go on to use.

However, we can easily silence this warning by initializing the unused
entries in engine_fns to NULL, this might also help if anyone ever
looks at engine_fns in a debugger, it should now be obvious which
entries are in use, and which are not.

With this change the warning is gone.

There should be no change in behaviour with this commit.

Fix addr2line test for ppc64 elfv1 and mingw

* testsuite/binutils-all/addr2line.exp: Tidy.  For powerpc64
arrange to pass --synthetic to nm, and extract .main and .fn
symbol address for addr2line test.  Handle default executable
extension on cygwin/mingw compilers.