gdb: fix vfork regressions when target-non-stop is off

It was pointed out on the mailing list[1] that after this commit:

  commit b1e0126ec56e099d753c20e91a9f8623aabd6b46
  Date:   Wed Jun 21 14:18:54 2023 +0100

      gdb: don't resume vfork parent while child is still running

the test gdb.base/vfork-follow-parent.exp now has some failures when
run with the native-gdbserver or native-extended-gdbserver boards:

  FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to end of inferior 2 (timeout)
  FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: inferior 1 (timeout)
  FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: print unblock_parent = 1 (timeout)
  FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to break_parent (timeout)

The reason that these failures don't show up when run on the standard
unix board is that the test is only run in the default operating mode,
so for Linux this will be all-stop on top of non-stop.

If we adjust the test script so that it runs in the default mode and
with target-non-stop turned off, then we see the same failures on the
unix board.  This commit includes this change.

The way that the test is written means that it is not (currently)
possible to turn on non-stop mode and have the test still work, so
this commit does not do that.

I have also updated the test script so that the vfork child performs
an exec as well as the current exit.  Exec and exit are the two ways
in which a vfork child can release the vfork parent, so testing both
of these cases is useful I think.

In this test the inferior performs a vfork and the vfork-child
immediately exits.  The vfork-parent will wait for the vfork-child and
then blocks waiting for gdb.  Once gdb has released the vfork-parent,
the vfork-parent also exits.

In the test that fails, GDB sets 'detach-on-fork off' and then runs to
the vfork.  At this point the test tries to just "continue", but this
fails as the vfork-parent is still selected, and the parent can't
continue until the vfork-child completes.  As the vfork-child is
stopped by GDB the parent will never stop once resumed, so GDB refuses
to resume it.

The test script then sets 'schedule-multiple on' and once again
continues.  This time GDB, in theory, resumes both the parent and the
child, the parent will be held blocked by the kernel, but the child
will run until it exits, and which point GDB stops again, this time
with inferior 2, the newly exited vfork-child, selected.

What happens after this in the test script is irrelevant as far as
this failure is concerned.

To understand why the test started failing we should consider the
behaviour of four different cases:

  1. All-stop-on-non-stop before commit b1e0126ec56e,

  2. All-stop-on-non-stop after commit b1e0126ec56e,

  3. All-stop-on-all-stop before commit b1e0126ec56e, and

  4. All-stop-on-all-stop after commit b1e0126ec56e.

Only case #4 is failing after commit b1e0126ec56e, but I think the
other cases are interesting because, (a) they inform how we might fix
the regression, and (b) it turns out the behaviour of #2 changed too
with the commit, but the change was harmless.

For #1 All-stop-on-non-stop before commit b1e0126ec56e, what happens
is:

  1. GDB calls proceed with the vfork-parent selected, as schedule
     multiple is on user_visible_resume_ptid returns -1 (everything)
     as the resume_ptid (see proceed function),

  2. As this is all-stop-on-non-stop, every thread is resumed
    individually, so GDB tries to resume both the vfork-parent and the
    vfork-child, both of which succeed,

  3. The vfork-parent is held stopped by the kernel,

  4. The vfork-child completes (exits) at which point the GDB sees the
     EXITED event for the vfork-child and the VFORK_DONE event for the
     vfork-parent,

  5. At this point we might take two paths depending on which event
     GDB handles first, if GDB handles the VFORK_DONE first then:

     (a) As GDB is controlling both parent and child the VFORK_DONE is
         ignored (see handle_vfork_done), the vfork-parent will be
 resumed,

     (b) GDB processes the EXITED event, selects the (now defunct)
         vfork-child, and stops, returning control to the user.

     Alternatively, if GDB selects the EXITED event first then:

     (c) GDB processes the EXITED event, selects the (now defunct)
         vfork-child, and stops, returning control to the user.

     (d) At some future time the user resumes the vfork-parent, at
         which point the VFORK_DONE is reported to GDB, however, GDB
 is ignoring the VFORK_DONE (see handle_vfork_done), so the
 parent is resumed.

For case #2, all-stop-on-non-stop after commit b1e0126ec56e, the
important difference is in step (2) above, now, instead of resuming
both the vfork-parent and the vfork-child, only the vfork-child is
resumed.  As such, when we get to step (5), only a single event, the
EXITED event is reported.

GDB handles the EXITED just as in (5)(c), then, later, when the user
resumes the vfork-parent, the VFORKED_DONE is immediately delivered
from the kernel, but this is ignored just as in (5)(d), and so,
though the pattern of when the vfork-parent is resumed changes, the
overall pattern of which events are reported and when, doesn't
actually change.  In fact, by not resuming the vfork-parent, the order
of events (in this test) is now deterministic, which (maybe?) is a
good thing.

If we now consider case #3, all-stop-on-all-stop before commit
b1e0126ec56e, then what happens is:

  1. GDB calls proceed with the vfork-parent selected, as schedule
     multiple is on user_visible_resume_ptid returns -1 (everything)
     as the resume_ptid (see proceed function),

  2. As this is all-stop-on-all-stop, the resume is passed down to the
     linux-nat target, the vfork-parent is the event thread, while the
     vfork-child is a sibling of the event thread,

  3. In linux_nat_target::resume, GDB calls linux_nat_resume_callback
     for all threads, this causes the vfork-child to be resumed.  Then
     in linux_nat_target::resume, the event thread, the vfork-parent,
     is also resumed.

  4. The vfork-parent is held stopped by the kernel,

  5. The vfork-child completes (exits) at which point the GDB sees the
     EXITED event for the vfork-child and the VFORK_DONE event for the
     vfork-parent,

  6. We are now in a situation identical to step (5) as for
     all-stop-on-non-stop above, GDB selects one of the events to
     handle, and whichever we select the user sees the correct
     behaviour.

And so, finally, we can consider #4, all-stop-on-all-stop after commit
b1e0126ec56e, this is the case that started failing.

We start out just like above, in proceed, the resume_ptid is
-1 (resume everything), due to schedule multiple being on.  And just
like above, due to the target being all-stop, we call
proceed_resume_thread_checked just once, for the current thread,
which, remember, is the vfork-parent thread.

The change in commit b1e0126ec56e was to avoid resuming a vfork-parent
thread, read the commit message for the justification for this change.

However, this means that GDB now rejects resuming the vfork-parent in
this case, which means that nothing gets resumed!  Obviously, if
nothing resumes, then nothing will ever stop, and so GDB appears to
hang.

I considered a couple of solutions which, in the end, I didn't go
with, these were:

  1. Move the vfork-parent check out of proceed_resume_thread_checked,
     and place it in proceed, but only on the all-stop-on-non-stop
     path, this should still address the issue seen in b1e0126ec56e,
     but would avoid the issue seen here.  I rejected this just
     because it didn't feel great to split the checks that exist in
     proceed_resume_thread_checked like this,

  2. Extend the condition in proceed_resume_thread_checked by adding a
     target_is_non_stop_p check.  This would have the same effect as
     idea 1, but leaves all the checks in the same place, which I
     think would be better, but this still just didn't feel right to
     me, and so,

What I noticed was that for the all-stop-on-non-stop, after commit
b1e0126ec56e, we only resumed the vfork-child, and this seems fine.
The vfork-parent isn't going to run anyway (the kernel will hold it
back), so if feels like we there's no harm in just waiting for the
child to complete, and then resuming the parent.

So then I started looking at follow_fork, which is called from the top
of proceed.  This function already has the task of switching between
the parent and child based on which the user wishes to follow.  So, I
wondered, could we use this to switch to the vfork-child in the case
that we are attached to both?

Turns out this is pretty simple to do.

Having done that, now the process is for all-stop-on-all-stop after
commit b1e0126ec56e, and with this new fix is:

  1. GDB calls proceed with the vfork-parent selected, but,

  2. In follow_fork, and follow_fork_inferior, GDB switches the
     selected thread to be that of the vfork-child,

  3. Back in proceed user_visible_resume_ptid returns -1 (everything)
     as the resume_ptid still, but now,

  4. When GDB calls proceed_resume_thread_checked, the vfork-child is
     the current selected thread, this is not a vfork-parent, and so
     GDB allows the proceed to continue to the linux-nat target,

  5. In linux_nat_target::resume, GDB calls linux_nat_resume_callback
     for all threads, this does not resume the vfork-parent (because
     it is a vfork-parent), and then the vfork-child is resumed as
     this is the event thread,

At this point we are back in the same situation as for
all-stop-on-non-stop after commit b1e0126ec56e, that is, the
vfork-child is resumed, while the vfork-parent is held stopped by
GDB.

Eventually the vfork-child will exit or exec, at which point the
vfork-parent will be resumed.

[1] https://inbox.sourceware.org/gdb-patches/3e1e1db0-13d9-dd32-b4bb-051149ae6e76@simark.ca/

kvx: New port.

aarch64: Enable Cortex-A720 CPU

This patch adds support for the Cortex-A720 CPU to binutils.

bfd/ChangeLog:

* cpu-aarch64.c: Add Cortex-A720.

gas/ChangeLog:

* NEWS: Update docs.
* config/tc-aarch64.c: Add Cortex-A720.
* doc/c-aarch64.texi: Update docs.
* testsuite/gas/aarch64/cpu-cortex-a720.d: New test.

gdb, infcmd: support jump command in multi-inferior case

Fixes the issue where jump failed if multiple inferiors run the same
source.

See the below example

    $ gdb -q ./simple
    Reading symbols from ./simple...
    (gdb) break 2
    Breakpoint 1 at 0x114e: file simple.c, line 2.
    (gdb) run
    Starting program: /temp/simple

    Breakpoint 1, main () at simple.c:2
    2         int a = 42;
    (gdb) add-inferior
    [New inferior 2]
    Added inferior 2 on connection 1 (native)
    (gdb) inferior 2
    [Switching to inferior 2 [<null>] (<noexec>)]
    (gdb) info inferiors
      Num  Description       Connection           Executable
      1    process 6250      1 (native)           /temp/simple
    * 2    <null>            1 (native)
    (gdb) file ./simple
    Reading symbols from ./simple...
    (gdb) run
    Starting program: /temp/simple

    Thread 2.1 "simple" hit Breakpoint 1, main () at simple.c:2
    2         int a = 42;
    (gdb) info inferiors
      Num  Description       Connection           Executable
      1    process 6250      1 (native)           /temp/simple
    * 2    process 6705      1 (native)           /temp/simple
    (gdb) jump 3
    Unreasonable jump request
    (gdb)

In this example, jump fails because the debugger finds two different
locations, one for each inferior.

Solution is to limit the search to the current program space.

This is done by having the jump_command function use
decode_line_with_current_source rather than
decode_line_with_last_displayed, which makes sense,
the *_current_source function always looks up a location based on the
current thread's location -- if a user is asking the current thread to
jump, then surely their destination should be relative to where the
current thread is located.

Then, inside decode_line_with_current_source, the call to
decode_line_1 is updated to pass through the current program_space,
which will limit the returned locations to those in the current
program space.

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

Automatic date update in version.in

Mention process_stratum in inferior::priv comment

From what I can tell, inferior::priv is reserved for the
process_stratum target.  It seems to me that it has to be, because
currenlty only such targets use it, and if a target at another stratum
started using this field, then conflicts could occur.  This patch
documents this.

Reviewed-by: John Baldwin <jhb@FreeBSD.org>

Updated Russian translation for the bfd directory

RISC-V: Make T-Head testing pattern more generic

On some T-Head vendor extensions, we test against the constant
18446744073709551615 (2**64-1) to detect invalid immediate errors on -1.
However, it heavily depends on the fact that the value used to print
immediate value is a 64-bit unsigned type and this constant is not (and
should not be) important (we just want to know that -1 is not valid).

This commit replaces all such occurrences of 18446744073709551615 with
a more generic regular expression.

gas/ChangeLog:

* testsuite/gas/riscv/x-thead-ba-fail.l: Replace
18446744073709551615 with generic regular expression.
* testsuite/gas/riscv/x-thead-bb-fail.l: Likewise.
* testsuite/gas/riscv/x-thead-bs-fail.l: Likewise.
* testsuite/gas/riscv/x-thead-fmemidx-fail.l: Likewise.
* testsuite/gas/riscv/x-thead-memidx-fail.l: Likewise.
* testsuite/gas/riscv/x-thead-mempair-fail.l: Likewise.

RISC-V: Make "fli.h" available to 'Zvfh' + 'Zfa'

The documentation of the 'Zfa' extension states that "fli.h" is available
"if the Zfh or Zvfh extension is implemented" (both the latest and the
oldest editions are checked).

This fact was not reflected in Binutils ('Zvfh' implies 'Zfhmin', not full
'Zfh' extension and "fli.h" required 'Zfh' and 'Zfa' extensions).
This commit makes "fli.h" also available when both 'Zfa' and 'Zvfh'
extensions are implemented.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Add new
instruction class handling.
(riscv_multi_subset_supports_ext): Likewise.

gas/ChangeLog:

* testsuite/gas/riscv/zfa-zvfh.s: New test.
* testsuite/gas/riscv/zfa-zvfh.d: Ditto.

include/ChangeLog:

* opcode/riscv.h (enum riscv_insn_class): Add new instruction
class.

opcodes/ChangeLog:

* riscv-opc.c (riscv_opcodes): Change instruction class of "fli.h"
from INSN_CLASS_ZFH_AND_ZFA to new INSN_CLASS_ZFH_OR_ZVFH_AND_ZFA.

RISC-V: Add support for the 'Zihintntl' extension

This commit adds 'Zihintntl' extension and its hint instructions.

This is based on:
<https://github.com/riscv/riscv-isa-manual/commit/0dc91f505e6da7791d5a733c553e6e2506ddcab5>,
the first ISA Manual noting that the 'Zihintntl' extension is ratified.

Note that compressed 'Zihintntl' hints require either 'C' or
'Zca' extension.

Co-authored-by: Nelson Chu <nelson@rivosinc.com>
bfd/ChangeLog:

* elfxx-riscv.c (riscv_supported_std_z_ext): Add 'Zihintntl'
standard hint 'Z' extension.
(riscv_multi_subset_supports): Support new instruction classes.
(riscv_multi_subset_supports_ext): Likewise.

gas/ChangeLog:

* testsuite/gas/riscv/zihintntl.s: New test for 'Zihintntl'
including auto-compression without C prefix and explicit C prefix.
* testsuite/gas/riscv/zihintntl.d: Likewise.
* testsuite/gas/riscv/zihintntl-na.d: Likewise.
* testsuite/gas/riscv/zihintntl-base.s: New test for correspondence
between 'Zihintntl' and base 'I' or 'C' instructions.
* testsuite/gas/riscv/zihintntl-base.d: Likewise.

include/ChangeLog:

* opcode/riscv.h (enum riscv_insn_class): Add new instruction
classes: INSN_CLASS_ZIHINTNTL and INSN_CLASS_ZIHINTNTL_AND_C.
(MASK_NTL_P1, MATCH_NTL_P1, MASK_NTL_PALL,
MATCH_NTL_PALL, MASK_NTL_S1, MATCH_NTL_S1, MASK_NTL_ALL,
MATCH_NTL_ALL, MASK_C_NTL_P1, MATCH_C_NTL_P1, MASK_C_NTL_PALL,
MATCH_C_NTL_PALL, MASK_C_NTL_S1, MATCH_C_NTL_S1, MASK_C_NTL_ALL,
MATCH_C_NTL_ALL): New.

opcodes/ChangeLog:

* riscv-opc.c (riscv_opcodes): Add instructions from the
'Zihintntl' extension.

RISC-V: remove indirection from register tables

The longest register name is 4 characters (plus a nul one), so using a
4- or 8-byte pointer to get at it is neither space nor time efficient.
Embed the names right into the array. For PIE this also reduces the
number of base relocations in the final image.

To avoid old gcc, when generating 32-bit code, bogusly warning about
bounds being exceeded in the code processing Cs/Cw, Ct/Cx, and CD,
an adjustment to EXTRACT_BITS() is needed: This macro shouldn't supply
a 64-bit value, and it also doesn't need to - all operand fields to
date are far more narrow than 32 bits. This in turn allows dropping a
number of casts elsewhere.

PPC: remove indirection from struct pd_reg

The longest register name is 5 characters (plus a nul one), so using a
4- or 8-byte pointer to get at it is neither space nor time efficient.
Embed the names right into the array. For PIE this also reduces the
number of base relocations in the final image.

Automatic date update in version.in

[gdb/build] Fix YYSTYPE and yyalloc odr violation

When building gdb with -O2 -flto I run into:
...
ada-exp.c.tmp:576:7: error: type ‘union YYSTYPE’ violates the C++ One \
  Definition Rule [-Werror=odr]
...

Fix this by renaming to ada_exp_YYSTYPE and likewise for other .y files.

Likewise for yyalloc.

Tested on x86_64-linux.  Also tested with byacc rather than bison on
suggestion of Tom Tromey.

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

fbsd-nat: Stop a process if it is running before killing it.

In addition, detach from any child processes implicitly attached to by
the kernel due to fork following that have not yet been processed by
GDB's core.

fbsd-nat: Fix thread_alive against a running thread.

FreeBSD's ptrace fails requests with EBUSY against a running process.
Report that the thread is alive instead of dead if ptrace fails with
EBUSY.

This fixes an internal error in the gdb.threads/detach-step-over.exp
test where one process was detached while a thread in a second process
was being stepped.  The core incorrectly assumed the stepping thread
had vanished and discarded the pending stepping state.  When the
thread later reported a SIGTRAP from completing the step, this
triggered an assertion.

fbsd-nat: Fix several issues with detaching.

- Detach from any child processes implicitly attached to by the kernel
  due to fork following that have not yet been processed by GDB's
  core.

- Delete breakpoints before detaching.

  inf-ptrace::detach does not do this (somewhat surprisingly), so add
  an override to remove breakpoints from a process before detaching
  from it.

  This also requires explicitly draining any pending SIGTRAP events
  for software breakpoints before detaching.  In particular, threads
  may need their PC adjusted due to the software breakpoint before
  being resumed after detach.  On more modern systems using the si_code
  from SIGTRAP to identify software breakpoint traps, the PC is adjusted
  in ::wait_1 as a side effect of parsing the event.  To support older
  kernels, ::detach fixes up the PC for any SIGTRAP stop whose potential
  new PC matches an existing software breakpoint.

fbsd-nat: Fix resuming and waiting with multiple processes.

I did not fully understand the requirements of multiple process
support when I enabled it previously and several parts were broken.
In particular, the resume method was only resuming a single process,
and wait was not stopping other processes when reporting an event.

To support multiple running inferiors, add a new per-inferior
structure which trackes the number of existing and running LWPs for
each process.  The structure also stores a ptid_t describing the
set of LWPs currently resumed for each process.

For the resume method, iterate over all non-exited inferiors resuming
each process matching the passed in ptid rather than only resuming the
current inferior's process for a wildcard ptid.  If a resumed process
has a pending event, don't actually resume the process, but other
matching processes without a pending event are still resumed in case
the later call to the wait method requests an event from one of the
processes without a pending event.

For the wait method, stop other running processes before returning an
event to the core.  When stopping a process, first check to see if an
event is already pending.  If it is, queue the event to be reported
later.  If not, send a SIGSTOP to the process and wait for it to stop.
If the event reported by the wait is not for the SIGSTOP, queue the
event and remember to ignore a future SIGSTOP event for the process.

Note that, unlike the Linux native target, entire processes are
stopped rather than individual LWPs.  In FreeBSD one can only wait on
processes (via pid), not for an event from a specific thread.

Other changes in this commit handle bookkeeping for the per-inferior
data such as migrating the data to the new inferior in the follow_exec
method.  The per-inferior data is created in the attach,
create_inferior, and follow_fork methods.

fbsd-nat: Defer any ineligible events reported by wait.

If wait_1 finds an event for a thread or process that does not match
the set of threads and processes previously resumed, defer the event.
If the event is for a specific thread, suspend the thread and continue
the associated process before waiting for another event.

One specific example of such an event is if a thread is created while
another thread in the same process hits a breakpoint.  If the second
thread's event is reported first, the target resume method does not
yet "know" about the new thread and will not suspend it via
PT_SUSPEND.  When wait is called, it will probably return the event
from the first thread before the result of the step from second
thread.  This is the case reported in PR 21497.

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

fbsd-nat: Add a list of pending events.

The m_pending_events list stores a queue of deferred events that might
be reported by the next call to the target's wait method.  The set of
events that are eligible is filtered by the ptid passed to resume.

For now this just replaces the list of vfork_done events.  A
subsequent commit will reuse this to store other events.

Remove alloca from osabi.c

I noticed that the call to alloca in osabi.c can be replaced with a
statically-sized buffer, because some code just before the declaration
ensures that the length is bounded.

Reviewed-by: John Baldwin <jhb@FreeBSD.org>

[gdb/build] Fix struct token odr violation

When building gdb with -O2 -flto I run into:
...
/data/vries/gdb/src/gdb/c-exp.y:2450:8: warning: type 'struct token' \
  violates the C++ One Definition Rule [-Wodr]
 struct token
        ^
/data/vries/gdb/src/gdb/d-exp.y:939:8: note: a different type is defined in \
  another translation unit
 struct token
        ^
...

Fix this by renaming to c_token and d_token.

Likewise in:
- fortran-exp.y, renaming to f_token,
- go-exp.y, renaming to go_token, and
- p-exp.y, renaming to p_token.

Tested on x86_64-linux.

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

[gdb/build] Fix struct token_and_value odr violation

When build gdb with -O2 -flto I run into:
...
gdb/c-exp.y:3003:8: warning: type 'struct token_and_value' violates the C++ \
  One Definition Rule [-Wodr]
 struct token_and_value
        ^
gdb/d-exp.y:1310:8: note: a different type is defined in another translation \
  unit
 struct token_and_value
        ^
...

Fix this by renaming to c_token_and_value and d_token_and_value.

Likewise in gdb/go-exp.y, renaming to go_token_and_value.

Tested on x86_64-linux.

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

[gdb/build] Fix enum param_types odr violation

When building gdb with -O2 -flto, I run into:
...
gdb/guile/scm-param.c:121:6: warning: type 'param_types' violates the C++ \
  One Definition Rule [-Wodr]
 enum param_types
      ^
gdb/python/py-param.c:33:6: note: an enum with different value name is \
  defined in another translation unit
 enum param_types
      ^
...

Fix this by renaming to enum scm_param_types and py_param_types.

Tested on x86_64-linux.

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

[gdb/build] Remove superfluous variable param_types in gdb/python/py-param.c

In gdb/python/py-param.c we have:
...
enum param_types
{
  ...
}
param_types;
...
which declares both an enum param_types, and an unused variable param_types.

Fix this by removing the variable.

Tested on x86_64-linux.

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

[gdb] Fix maint print symbols/psymbols help text

Consider the help text of "maint print symbols":
...
(gdb) help maint print symbols
Print dump of current symbol definitions.
Usage: mt print symbols [-pc ADDRESS] [--] [OUTFILE]
       mt print symbols [-objfile OBJFILE] [-source SOURCE] [--] [OUTFILE]
Entries in the full symbol table are dumped to file OUTFILE,
or the terminal if OUTFILE is unspecified.
If ADDRESS is provided, dump only the file for that address.
If SOURCE is provided, dump only that file's symbols.
If OBJFILE is provided, dump only that file's minimal symbols.
...
and "maint print psymbols":
...
(gdb) help maint print psymbols
Print dump of current partial symbol definitions.
Usage: mt print psymbols [-objfile OBJFILE] [-pc ADDRESS] [--] [OUTFILE]
       mt print psymbols [-objfile OBJFILE] [-source SOURCE] [--] [OUTFILE]
Entries in the partial symbol table are dumped to file OUTFILE,
or the terminal if OUTFILE is unspecified.
If ADDRESS is provided, dump only the file for that address.
If SOURCE is provided, dump only that file's symbols.
If OBJFILE is provided, dump only that file's minimal symbols.
...

The OBJFILE lines mistakingly mention minimal symbols.

Fix this by reformulating as "dump only that object file's symbols".

Also make the ADDRESS lines more clear by using the formulation: "dump only
the symbols for the file with code at that address".

Tested on x86_64-linux.

Co-Authored-By: Eli Zaretskii <eliz@gnu.org>
PR gdb/30742
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30742

ld: Build libpr23169a.so with -z lazy

pr23169b test only works with lazy binding.  To work with linker which
disables lazy binding by default, build pr23169b binaries with -z lazy.

PR ld/30698
* ld-ifunc/ifunc.exp: Build pr23169b binaries with -z lazy.

Remove fall-back prune_warnings

No one should be using versions of dejagnu without prune_warnings,
which was available in 1996 (dejagnu-1.3).

binutils/
* testsuite/lib/binutils-common.exp: Remove fallback prune_warnings.
gas/
* testsuite/lib/gas-defs.exp: Remove fallback prune_warnings.

Re: PR30715, VAX: md_create_long_jump

Tidy comment formatting.

ld: fix relocatable, retain7a target pattens for HPPA

Fix issue reported by Dave and Alan.

Put back the old pattern for hppa-*-linux* and add hppa[12]*-*-linux* to cover
Gentoo's hppa1.1 and hppa2.0 without including hppa64 inadvertently like I did
before.

ld/
PR 30733
PR 30734
* ld/testsuite/ld-elf/relocatable.d: Use better pattern to exclude hppa64
          but include hppa1.1, hppa2.0.
* ld/testsuite/ld-elf/retain7a.d: Ditto.

Fixes: 0e339f6b4f2df25ed351cb94dc7fe16868626f49
Fixes: e3b66187192ce6840df283c00f6395bb0ff15cf5
Signed-off-by: Sam James <sam@gentoo.org>

Automatic date update in version.in

[gdb/symtab] Don't deduplicate variables in gdb-index

When running test-case gdb.python/py-symbol.exp with target board
cc-with-gdb-index, we run into:
...
(gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M
1^M
(gdb) FAIL: gdb.python/py-symbol.exp: print (len (gdb.lookup_static_symbols ('rr')))
...

[ Note that the test-case contains rr in both py-symtab.c:
...
static int __attribute__ ((used)) rr = 42; /* line of rr */
...
and py-symtab-2.c:
...
static int __attribute__ ((used)) rr = 99; /* line of other rr */
... ]

This passes with gdb-12-branch, and fails with gdb-13-branch.

AFAIU the current code in symtab_index_entry::minimize makes the assumption
that it's fine to store only one copy of rr in the gdb-index, because
"print rr" will only ever print one, and always the same.

But that fails to recognize that gdb supports gdb.lookup_static_symbols, which
returns a list of variables rather than the first one.

In other words, the current approach breaks feature parity between cooked
index and gdb-index.

Note btw that also debug-names has both instances:
...
[  5] #00597969 rr:
        <4> DW_TAG_variable DW_IDX_compile_unit=3 DW_IDX_GNU_internal=1
        <4> DW_TAG_variable DW_IDX_compile_unit=4 DW_IDX_GNU_internal=1
...

Fix this in symtab_index_entry::minimize, by not deduplicating variables.

Tested on x86_64-linux, with target boards unix and cc-with-gdb-index.

Reviewed-by: Kevin Buettner <kevinb@redhat.com>
PR symtab/30720
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30720

gprofng: pass gprofng location to gp-display-gui

gprofng GUI can be installed to the other directory.
In this case, $PATH is used to find gp-display-gui from gprofng
and option --gprofngdir is passed to gp-display-gui.

gprofng/ChangeLog
2023-08-09  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* src/gprofng.cc (Gprofng::exec_cmd): Add option --gprofngdir.

gprofng: fix typos in get_realpath() and check_executable()

gprofng/ChangeLog
2023-08-09  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* src/Application.cc (Application::get_realpath): Fix typo.
* src/checks.cc (collect::check_executable): Likewise.

Automatic date update in version.in

Re: gdb: warn unused result for bfd IO functions

Add a missing return statement.

PR30715, VAX: md_create_long_jump

PR 30715
* config/tc-vax.c (md_create_long_jump): Use pc-relative addressing.
* testsuite/gas/vax/broken_word.d,
* testsuite/gas/vax/broken_word.s: New test.
* testsuite/gas/vax/vax.exp: Run it.

gdbserver: Reinstall software single-step breakpoints in resume_stopped_resumed_lwps

At the moment, while performing a software single-step, gdbserver fails
to reinsert software single-step breakpoints for a LWP when
interrupted by a signal in another thread.  This commit fixes this
problem by reinstalling software single-step breakpoints in
linux_process_target::resume_stopped_resumed_lwps in
gdbserver/linux-low.cc.

This bug was discovered due to a failing assert in maybe_hw_step()
in gdbserver/linux-low.cc.  Looking at the backtrace revealed
that the caller was linux_process_target::resume_stopped_resumed_lwps.
I was uncertain whether the assert should still be valid when called
from that method, so I tried hoisting the assert from maybe_hw_step
to all callers except resume_stopped_resumed_lwps.  But running the
new test case, described below, showed that merely eliminating the
assert for this case was NOT a good fix - a study of the log file for
the test showed that the single-step operation failed to occur.
Instead GDB (via gdbserver) stopped at the next breakpoint that was
hit.

Zhiyong Yan had proposed a fix which resinserted software single-step
breakpoints, albeit at a different location in linux-low.cc.  Testing
revealed that, while running gdb.threads/pending-fork-event-detach,
the executable associated with that test would die due to a SIGTRAP
after the test program was detached.  Examination of the core file(s)
showed that a breakpoint instruction had been left in program memory.
Test results were otherwise very good, so Zhiyong was definitely on
the right track!

This commit causes software single-step breakpoint(s) to be inserted
before the call to maybe_hw_step in resume_stopped_resumed_lwps.  This
will cause 'has_single_step_breakpoints (thread)' to be true, so that
the assert in maybe_hw_step...

      /* GDBserver must insert single-step breakpoint for software
 single step.  */
      gdb_assert (has_single_step_breakpoints (thread));

...will no longer fail.  And better still, the single-step breakpoints
are reinstalled, so that stepping will actually work, even when
interrupted.

The C code for the test case was loosely adapted from the reproducer
provided in Zhiyong's bug report for this problem.  The .exp file was
copied from next-fork-other-thread.exp and then tweaked slightly.  As
noted in a comment in next-fork-exec-other-thread.exp, I had to remove
"on" from the loop for non-stop as it was failing on all architectures
(including x86-64) that I tested.  I have a feeling that it ought to
work, but this can be investigated separately and (re)enabled once it
works.  I also increased the number of iterations for the loop running
the "next" commands.  I've had some test runs which don't show the bug
until the loop counter exceeded 100 iterations.  The C file for the
new test uses shorter delays than next-fork-other-thread.c though, so
it doesn't take overly long (IMO) to run this new test.

Running the new test on a Raspberry Pi w/ a 32-bit (Arm) kernel and
userland using a gdbserver build without the fix in this commit shows
the following results:

FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=12: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=on: i=9: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=off: i=18: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=3: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=11: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=1: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=1: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=on: i=3: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=off: i=1: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=47: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=on: i=57: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=1: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=10: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=1: next to break here

=== gdb Summary ===

 # of unexpected core files 12
 # of expected passes 3011
 # of unexpected failures 14

Each of the 12 core files were caused by the failed assertion in
maybe_hw_step in linux-low.c.  These correspond to 12 of the
unexpected failures.

When the tests are run using a gdbserver build which includes the fix
in this commit, the results are significantly better, but not perfect:

FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=143: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=on: i=25: next to other line

=== gdb Summary ===

 # of expected passes 10178
 # of unexpected failures 2

I think that the two remaining failures are due to some different
problem.  They are also racy - I've seen runs with no failures or only
one failure, but never more than two.  Also, those runs were conducted
with the loop count in next-fork-exec-other-thread.exp set to 200.
During his testing of this fix and the new test case, Luis Machado
found that this test was taking a long time and asked about ways to
speed it up.  I then conducted additional tests in which I gradually
reduced the loop count, timing each one, also noting the number of
failures.  With the loop count set to 30, I found that I could still
reliably reproduce the failures that Zhiyong reported (in which, with
the proper settings, core files are created).  But, with the loop
count set to 30, the other failures noted above were much less likely
to show up.  Anyone wishing to investigate those other failures should
set the loop count back up to 200.

Running the new test on x86-64 and aarch64, both native and
native-gdbserver shows no failures.

Also, I see no regressions when running the entire test suite for
armv7l-unknown-linux-gnueabihf (i.e.  the Raspberry Pi w/ 32-bit
kernel+userland) with --target_board=native-gdbserver.  Additionally,
using --target_board=native-gdbserver, I also see no regressions for
the entire test suite for x86-64 and aarch64 running Fedora 38.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30387
Co-Authored-By: Zhiyong Yan <zhiyong.yan@windriver.com>
Tested-By: Zhiyong Yan <zhiyong.yan@windriver.com>
Tested-By: Luis Machado <luis.machado@arm.com>

regen config

This regenerates config files changed by the previous 44 commits.
Note that subject lines in these commits mostly match the gcc git
originating commit.

toplevel: Substitute GDCFLAGS instead of using CFLAGS

r14-2875-g1ed21e23d6d4da ("Use substituted GDCFLAGS") already
implemented this change, but only on the generated file rather than in
the template it is generated from.

* Makefile.tpl: Substitute @GDCFLAGS@ instead of using
$(CFLAGS).

Use substituted GDCFLAGS

Use the substituted value for GCDFLAGS instead of hardcoding $(CFLAGS) so
that the subdir configure scripts use the configured value.

* configure.ac (GDCFLAGS): Set default from ${CFLAGS}.

gccrs: Add gcc-check-target check-rust

This allows us to invoke the rust testsuite.

* Makefile.def: Add Rust language.

PR bootstrap/106472: Add libgo depends on libbacktrace to Makefile.def

This patch fixes PR bootstrap/106472 by adding a missing dependency
to Makefile.def to allow make bootstrap when configured using
"--enable-languages=go" (and not using make with multiple threads).

2022-07-31  Roger Sayle  <roger@nextmovesoftware.com>

PR bootstrap/106472
* Makefile.def (dependencies): Make configure-target-libgo depend
upon all-target-libbacktrace.

Revert "Fix PR 67102: Add libstdc++ dependancy to libffi" [PR67102]

Disable warnings as errors for STAGEautofeedback.

Compilation during STAGEautofeedback produces additional warnings
since inlining decisions with -fauto-profile are different from
other builds.

This patches disables warnings as errors for STAGEautofeedback.

Tested on x86_64-pc-linux-gnu.

* Makefile.tpl: Disable warnings as errors for STAGEautofeedback

Fix autoprofiledbootstrap build

* Makefile.tpl: Define PROFILE_MERGER

Fix collection and processing of autoprofile data for target libs

cc1, cc1plus, and lto  built during STAGEautoprofile need to be built with
debug info since they are used to build target libs. -gtoggle was
turning off debug info for this stage.

create_gcov should be passed prev-gcc/cc1, prev-gcc/cc1plus, and prev-gcc/lto
instead of stage1-gcc/cc1, stage1-gcc/cc1plus, and stage1-gcc/lto when
processing profile data collected while building target libraries.

Tested on x86_64-pc-linux-gnu.

* Makefile.tpl: Remove -gtoggle for STAGEautoprofile

Collect both user and kernel events for autofdo tests and autoprofiledbootstrap

When we collect just user events for autofdo with lbr we get some events where branch
sources are kernel addresses and branch targets are user addresses. Without kernel MMAP
events create_gcov can't make sense of kernel addresses. Currently create_gcov fails if
it can't map at least 95% of events. We sometimes get below this threshold with just
user events. The change is to collect both user events and kernel events.

Tested on x86_64-pc-linux-gnu.

* Makefile.tpl: Collect both kernel and user events for autofdo

d: Import dmd b8384668f, druntime e6caaab9, phobos 5ab9ad256 (v2.098.0-beta.1)

The D front-end is now itself written in D, in order to build GDC, you
will need a working GDC compiler (GCC version 9.1 or later).

GCC changes:

    - Add support for bootstrapping the D front-end.

These add the required components in order to have a D front-end written
in D itself.  Because the compiler front-end only depends on the core
runtime modules, only libdruntime is built for the bootstrap stages.

D front-end changes:

    - Import dmd v2.098.0-beta.1.

Druntime changes:

    - Import druntime v2.098.0-beta.1.

Phobos changes:

    - Import phobos v2.098.0-beta.1.

The jump from v2.076.1 to v2.098.0 covers nearly 4 years worth of
development on the D programming language and run-time libraries.

* Makefile.def: Add bootstrap to libbacktrace, libphobos, zlib, and
libatomic.
* Makefile.tpl (POSTSTAGE1_HOST_EXPORTS): Fix command for GDC.
(STAGE1_CONFIGURE_FLAGS): Add --with-libphobos-druntime-only if
target-libphobos-bootstrap.
(STAGE2_CONFIGURE_FLAGS): Likewise.

Makefile.def: drop remnants of unused libelf

Use of libelf was removed from gcc in r0-104274-g48215350c24d52 ("re PR
lto/46273 (Failed to bootstrap)") around 2010, before gcc-4.6.0.

This change removes unused references to libelf from top-level configure
and Makefile.

* Makefile.def: Drop libelf module and gcc-configure dependency
on it.
* Makefile.tpl (HOST_EXPORTS): Drop unused LIBELFLIBS and
LIBELFINC.

Do not use HAVE_DOS_BASED_FILE_SYSTEM for Cygwin.

PR gcov-profile/94570
* ltmain.sh: Do not define HAVE_DOS_BASED_FILE_SYSTEM
for CYGWIN.

Co-Authored-By: Jonathan Yong <10walls@gmail.com>

FDPIC: Handle arm*-*-uclinuxfdpiceabi in configure scripts

In libtool.m4, we use uclinuxfdpiceabi in cases where ELF shared
libraries support is required, as uclinux does not guarantee that.

* libtool.m4: Handle uclinuxfdpiceabi.

libtool.m4: Sort output of 'find' to enable deterministic builds.

        * libtool.m4: Sort output of 'find' to enable deterministic builds.
* ltmain.sh: Likewise.

Fix hppa64-hpux11 build to remove source paths from embedded path.

This change adds the +nodefaultrpath ld option to remove all library
paths that were specified with the -L option from the embedded path.

* libtool.m4 (archive_cmds): Add +nodefaultrpath ld option on
hppa64-*-hpux11*.

Generic configury support for shared libs on VxWorks

This change adds the configury bits to activate the build of
shared libs on VxWorks ports configured with --enable-shared,
for libraries variants where this is generally supported (rtp,
code model !large - currently not compatible with -fPIC).

Set lt_cv_deplibs_check_method in libtool.m4, so the build of
libraries know how to establish dependencies.  This is useful in
configurations such as aarch64 where proper support of LSE relies
on accurate dependency information between libstdc++ and libgcc_s
to begin with.

* libtool.m4 (*vxworks*): When enable_shared, set dynamic_linker
and friends for rtp !large. Assume the linker has the required
abilities and set lt_cv_deplibs_check_method.

toplevel: reconcile few divergences with GCC

* configure.ac: Reorder include.
<is_elf calculation>: Re-add haiku to ELF target list.

gcc: xtensa: add data alignment properties to dynconfig

include/
* xtensa-dynconfig.h (xtensa_config_v4): New struct.
(XCHAL_DATA_WIDTH, XCHAL_UNALIGNED_LOAD_EXCEPTION)
(XCHAL_UNALIGNED_STORE_EXCEPTION, XCHAL_UNALIGNED_LOAD_HW)
(XCHAL_UNALIGNED_STORE_HW, XTENSA_CONFIG_V4_ENTRY_LIST): New
definitions.
(XTENSA_CONFIG_INSTANCE_LIST): Add xtensa_config_v4 instance.
(XTENSA_CONFIG_ENTRY_LIST): Add XTENSA_CONFIG_V4_ENTRY_LIST.

gcc: xtensa: add XCHAL_HAVE_{CLAMPS, DEPBITS, EXCLUSIVE, XEA3} to dynconfig

include/
* xtensa-dynconfig.h (xtensa_config_v3): New struct.
(xtensa_get_config_v3): New declaration.
(XCHAL_HAVE_CLAMPS, XCHAL_HAVE_DEPBITS, XCHAL_HAVE_EXCLUSIVE)
(XCHAL_HAVE_XEA3, XTENSA_CONFIG_V3_ENTRY_LIST): New definitions.
(XTENSA_CONFIG_INSTANCE_LIST): Add xtensa_config_v3 instance.
(XTENSA_CONFIG_ENTRY_LIST): Add XTENSA_CONFIG_V3_ENTRY_LIST.

MSP430: Add -fno-exceptions multilib

* config-ml.in (msp430-*-*): Support --disable-no-exceptions configure
flag.

Add D front-end, libphobos library, and D2 testsuite.

* config-ml.in: Treat GDC and GDCFLAGS like other compiler/flag
environment variables.

Cherry picked from GCC commit b4c522fabd0df7be08882d2207df8b2765026110

config-ml.in: Suppress output from multi-do recipes

The FIXME comments saying "Leave out until this is tested a bit more"
are from 1997. I think they've been sufficiently tested.

* config-ml.in (multi-do, multi-clean): Add @ to silence recipes.
Remove FIXME comments.

mh-mingw: drop unused BOOT_CXXFLAGS variable

gcc's build system has BOOT_CFLAGS and various STAGE<N>_C{,XX}FLAGS
variables. BOOT_CXXFLAGS is not handled anywhere.

config/
* mh-mingw: Drop assignment of unused BOOT_CXXFLAGS variable.

mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags variables

This is similar to what was done in
eea4e2ff0a3f5e7f37df204c070cc5d9ef339e6e (where it was added to
STAGE*_CXXFLAGS), but this adds the flag to the CXXFLAGS and
BOOT_CXXFLAGS variables too (as it's already added to CFLAGS and
BOOT_CFLAGS).

2021-04-09  Martin Storsjö  <martin@martin.st>

config/
* mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags
variables

configure: Allow host fragments to react to --enable-host-shared.

This makes the host_shared value available to host makefile
fragments.

It uses this to adjust Darwin's mdynamic-no-pic in the case that
shared host resources are required.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
config/
* mh-darwin: Require a non-shared host configuration to
enable  mdynamic-no-pic where that is supported.

Darwin, config: Revise host config fragment.

There were two uses for the Darwin host config fragment:

The first is to arrange for targets that support mdynamic-no-pic
to be built with that enabled (since it makes a significant
difference to the compiler performance).  We can be more specific
in the application of this, since it only applies to 32b hosts
plus powerpc64-darwin9.

The second was to work around a tool bug where -fno-PIE was not
propagated to the link stage.  This second use is redundant,
since the buggy toolchain cannot bootstrap current GCC sources
anyway.

This makes the host fragment more specific and reduces the number
of toolchains for which it is included which reduces clutter in
configure lines.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
config/
* mh-darwin: Make this specific to handling the
mdynamic-no-pic case.

gcc: Add 'mcf' thread model support from mcfgthread

This patch adds the new thread model `mcf`, which implements mutexes
and condition variables with the mcfgthread library.

Source code for mcfgthread is available at <https://github.com/lhmouse/mcfgthread>.

config/
* gthr.m4 (GCC_AC_THREAD_HEADER): Add new case for `mcf` thread
model

Fix PR bootstrap/102389: --with-build-config=bootstrap-lto is broken

So the problem here is that now the lto-plugin requires NM that works
with LTO to work so we need to pass down NM just like we do for ranlib
and ar.

config/
* bootstrap-lto-lean.mk: Handle NM like RANLIB AND AR.
* bootstrap-lto.mk: Likewise.

32-bit PA-RISC with HP-UX: remove deprecated ports

* configure.ac: Drop GCC configury for hpux10
* configure: Likewise.
config/
* mh-pa-hpux10: Drop.

Merge modula-2 front end onto gcc.

This commit merges the devel/modula2 into master.
The libraries reside in libgm2, the compiler in gcc/m2
and the testsuite in gcc/testsuite/gm2.

* configure.ac (target_libraries): Add target-libgm2.
Add NCN_STRICT_CHECK_TARGET_TOOLS entry for gm2.
Add GCC_TARGET_TOOL entry for gm2.  (compare_exclusions)
add gcc/m2/gm2-compiler/M2Version,
gcc/m2/gm2-compiler-boot/SYSTEM and gcc/m2/gm2version.
* Makefile.def (target_modules): Add libgm2.  (flags_to_pass)
Add GM2_FOR_TARGET, GM2FLAGS_FOR_TARGET.  (dependencies) Add
all-target-libgm2 and on=all-target-libatomic.  (languages)
Add entry for language=m2 with gcc-check-target=check-m2
and lib-check-target=check-target-libgm2.
* Makefile.tpl (BUILD_EXPORTS): Add definition for GM2
and GM2FLAGS.  (HOST_EXPORTS) Add definition for GM2.
(BASE_TARGET_EXPORTS) Add definition for GM2.
(GM2_FOR_BUILD) Defined.  (GM2FLAGS) Defined.
(GM2_FOR_TARGET) Defined.  (GM2FLAGS_FOR_TARGET) Defined.
(EXTRA_HOST_FLAGS) Defined.  (POSTSTAGE1_FLAGS_TO_PASS)
Add GM2 and GM2_FOR_BUILD.  (EXTRA_TARGET_FLAGS) Add
GM2 and GM2FLAGS.  (EXTRA_GCC_FLAGS) Add GM2_FOR_TARGET.

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

Add TFLAGS to gcc's GCC_FOR_TARGET

When the GCC build runs GCC_FOR_TARGET, e.g. for selftests or for
dumping specs, it doesn't use TFLAGS in non-bootstrap scenarios.  This
patch arranges for TFLAGS to be passed from the top level down to gcc
in GCC_FOR_TARGET in this case.

* Makefile.tpl (HOST_EXPORTS): Add TFLAGS to GCC_FOR_TARGET.
(EXTRA_GCC_FLAGS): Likewise.

configure: Account CXXFLAGS in gcc-plugin.m4.

We now use a C++ compiler so that we need to process
CXXFLAGS as well as CFLAGS in the gcc-plugin config
fragment.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
config/
* gcc-plugin.m4: Save and process CXXFLAGS.

configure: use OBJDUMP determined by libtool [PR95648]

$ac_cv_prog_OBJDUMP contains the --host OBJDUMP that
libtool has inferred. Current config/gcc-plugin.m4 does
not respect the user's choice for OBJDUMP.

config/
* gcc-plugin.m4: Use libtool's $ac_cv_prog_OBJDUMP.

Remove support for Intel MIC offloading

... after its deprecation in GCC 12.

* Makefile.def: Remove module 'liboffloadmic'.
* configure.ac: Remove 'liboffloadmic' handling.

configure, Darwin: Ensure overrides to host-pie are passed to gcc configure.

The latest versions of Darwin on the Aarch64 platform mandate PIE executables.
On x86_64 it remains optional, but produces tool warnings after Darwin20, so
we default to PIE executables there too.

All (non-PowerPC) 64b Darwin platforms mandate PIC code and therefore force
host_shared on (we issue a diagnostic if the user tries to configure them
non-shared).

However, this also means we cannot test the host_shared setting independently
of the host_pie setting so that the logic for setting PICFLAG must be amended
for Darwin.

For Darwin versions required to have PIE executables, in the event that the
user tries to configure these as --disable-host-pie, we issue a warning and
override the setting.  These versions must also switch host_pie on even if it
is not given in the configure line.  To cater for this we pass the current
value of host_pie, as determined by top-level configure, to the GCC configure.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
* Makefile.def: Pass the enable-host-pie value to GCC configure.
* configure.ac: Adjust the logic for shared and PIE host flags to
ensure that PIE is passed for hosts that require it.

configure: Only create serdep.tmp if needed

There's no reason to create this file if none of the serial configure
options are passed.

* configure.ac: Only create serdep.tmp if needed

configure: Implement --enable-host-pie

This patch implements the --enable-host-pie configure option which
makes the compiler executables PIE.  This can be used to enhance
protection against ROP attacks, and can be viewed as part of a wider
trend to harden binaries.

Co-Authored by: Iain Sandoe  <iain@sandoe.co.uk>

* configure.ac (--enable-host-pie): New check.  Set PICFLAG after this
check.

intl/
* configure.ac (--enable-host-shared): Don't set PICFLAG here.
(--enable-host-pie): New check.  Set PICFLAG after this check.

libdecnumber/
* configure.ac (--enable-host-shared): Don't set PICFLAG here.
(--enable-host-pie): New check.  Set PICFLAG after this check.

zlib/
* configure.ac (--enable-host-shared): Don't set PICFLAG here.
(--enable-host-pie): New check.  Set PICFLAG after this check.

configure: When host-shared, pass --with-pic to in-tree lib configs.

If we are building PIC/PIE host executables, and we are building dependent
libs (e.g. GMP) in-tree those libs need to be configured to generate PIC code.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
* Makefile.def: Pass host_libs_picflag to host dependent library
configures.
* configure.ac (host_libs_picflag): New configure variable set to
'--with-pic' when building 'host_shared'.

configure: Do not build the ununsed libffi shared library.

We do not use the shared libffi libraray, nor do we install it.
However, on at least Darwin, the shared version will be picked
up for testing, so it is preferrable not to build it.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
* Makefile.def: Do not build shared libffi.

Darwin : Update libtool and dependencies for Darwin20 [PR97865]

The change in major version (and the increment from Darwin19 to 20)
caused libtool tests to fail which resulted in incorrect build settings
for shared libraries.

PR target/97865
* libtool.m4: Update handling of Darwin platform link flags
for Darwin20.

LoongArch: implement count_{leading,trailing}_zeros

LoongArch always support clz and ctz instructions, so we can always use
__builtin_{clz,ctz} for count_{leading,trailing}_zeros.  This improves
the code of libgcc, and also benefits Glibc once we merge longlong.h
there.

Bootstrapped and regtested on loongarch64-linux-gnu.

include/
* longlong.h [__loongarch__] (count_leading_zeros): Define.
[__loongarch__] (count_trailing_zeros): Likewise.
[__loongarch__] (COUNT_LEADING_ZEROS_0): Likewise.

Updated constants from <https://dwarfstd.org/Languages.php>

include/
* dwarf2.h: Update with additional languages from dwarf
standard.

c++: source position of lambda captures [PR84471]

include/
* ansidecl.h (ATTRIBUTE_WARN_UNUSED_RESULT): Add __.

Libvtv: Add loongarch support.

The loongarch64 specification permits page sizes of 4KiB, 16KiB and 64KiB,
but only 16KiB pages are supported for now.

Co-Authored-By: qijingwen <qijingwen@loongson.cn>
include/
* vtv-change-permission.h (defined): Determines whether the macro
__loongarch_lp64 is defined
(VTV_PAGE_SIZE): Set VTV_PAGE_SIZE to 16KiB for loongarch64.

Automatic date update in version.in

gdb.ada/mi_var_access.exp

The NUMCHILD value for the "A_String_Access" test differs for X86 and
PowerPC.  The patch substitutes $decimal instead of "1" to match the value
of NUMCHILD.

The test "-var-update A_String_Access" generates different output depending
on the value of VAROBJ_UPDATE_RESULT.TYPE_CHANGED.  If the value is true,
the strings "new_type" and "new_num_children" are printed along with their
values.

The VAROBJ_UPDATE_RESULT.TYPE_CHANGED value is true on PowerPC which
produces the output:

  Expecting: ^(-var-update A_String_Access[
  ]+)?(\^done,changelist=\[\{name="A_String_Access",in_scope="true",type_changed="false",has_more="0"\}\][
  ]+[(]gdb[)]
  [ ]*)
  -var-update A_String_Access
  ^done,changelist=[{name="A_String_Access",in_scope="true",type_changed="true",new_type="pck.string_access",new_num_children="1",has_more="0"}]
  (gdb)
  FAIL: gdb.ada/mi_var_access.exp: update at stop 2 (unexpected output)

The patch adds a second possible result string for the test
$re_varobj_update_result_type to match the case when type_changed is true.

Currently for the mi_var_access.exp test VAROBJ_UPDATE_RESULT.TYPE_CHANGED
is true on PowerPC and false on X86-64.

Fixes 2 failures on PowerPC.

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

Fix Python documentation for range type fields

GDB's Python documentation claims that range types have two fields,
but this is not true, and attempts to access them hit this error:

      "Type is not a structure, union, enum, or function type."

This patch fixes the documentation.

Test GNAT encodings in arr_acc_idx_w_gap.exp

While working on a GNAT bug, I wanted to also test
arr_acc_idx_w_gap.exp using GNAT encodings.  When the GNAT change is
ready, I plan to add a new case here.

Tested on x86-64 Fedora 36.  I am checking this in.

RISC-V: Reflect actual range of vlen for hashing

Before actual vlen handling, fix the riscv_gdbarch_features hashing
function based on the actual valid range of vlen.  In bytes, vlen is 0,
or 4 <= xlen <= 8192.

RISC-V: Add reference to Zve32*

Before actual vlen handling, this commit fixes its description to allow vlen
less than 16 (but 4 or greater), to support vector subset extensions for
embedded environment ('Zve32*').

gdb: warn unused result for bfd IO functions

This fixes the compilation warnings introduced by my bfdio.c patch.

The removed bfd_seeks in coff_symfile_read date back to 1994, commit
7f4c859520, prior to which the file used stdio rather than bfd to read
symbols.  Since it now uses bfd to read the file there should be no
need to synchronise to bfd's idea of the file position.  I also fixed
a potential uninitialised memory access.

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

Fix AIX build break.

In a recent commit the signature of the scoped_restore_current_inferior_for_memory function was changed and in AIX we did not update the same.

This patch updates it in aix-thread.c file fixed the break and the thread debugging works alright as a result.

gas: purge md_elf_section_word()

It's not documented anyway, and having it makes no sense anymore with
obj_elf_section_word() now being TC_SPARC-only. In any event the x86
backing function was dead code.

x86: pack CPU flags in opcode table

The table constantly growing in two dimensions (number of table entries
times number of ISA extension flags) doesn't scale very well. Use a more
compact representation: Only identifiers which need to combine with
other identifiers retain individual flag bits. All others are combined
into an enum, with a new helper added to transform the table entries
into the original i386_cpu_flags layout. This way the table in the final
binary shrinks by almost a third (the generated source code shrinks by
about half), and isn't likely to grow again in that dimension any time
soon.

While moving the 3DNow! fields, drop the stray inner 'a' from their
names.

warn unused result for bfd IO functions

This patch fixes all the warnings I found in bfd, binutils and ld,
plus some bitrotted COFF_GO32 code that tried to allocate -168ul
bytes.  When the malloc fail was reported these testsuite fails
resulted:

i386-go32  +FAIL: go32 stub
i386-go32  +ERROR: tcl error sourcing /home/alan/src/binutils-gdb/ld/testsuite/ld-i386/i386.exp.
i386-go32  +ERROR: couldn't open "tmpdir/go32stub": no such file or directory
i386-go32  +FAIL: ld-scripts/sane1
i386-go32  +FAIL: ld-scripts/assign-loc
i386-go32  +FAIL: ld-scripts/pr18963

This does result in some warnings in gdb which are fixed in a followup
patch.

bfd/
* bfdio.c (bfd_read, bfd_write): Add ATTRIBUTE_WARN_UNUSED_RESULT.
(bfd_tell, bfd_stat, bfd_seek, bfd_mmap): Likewise.
* bfd-in2.h: Regenerate.
* coff-rs6000.c (xcoff_write_armap_big) Don't ignore bfd_write
return value.
(xcoff_generate_rtinit): Likewise.  Also free data_buffer and
string_table before returning.
* coff64-rs6000.c (xcoff64_generate_rtinit): Likewise.
* coff-stgo32.c (go32exe_check_format): Don't ignore bfd_seek
return value.
* coffcode.h (coff_apply_checksum): Don't ignore bfd_write return.
(coff_write_object_contents <COFF_GO32>): Likewise, and bfd_malloc.
Fix bitrotted code to look for first section with non-zero filepos.
* elf64-ia64-vms.c (elf64_vms_write_shdrs_and_ehdr): Don't ignore
bfd_seek or bfd_write return values.
* pef.c (bfd_pef_scan_section): Likewise.
(bfd_pef_read_header, bfd_pef_xlib_read_header): Likewise.
* vms-misc.c (_bfd_vms_output_end): Likewise.  Return status.
* vms.h (_bfd_vms_output_end): Update prototype.
* vms-alpha.c: Pass _bfd_vms_output_end status up call chains.
* wasm-module.c (wasm_compute_custom_section_file_position): Don't
ignore bfd_seek or bfd_write return values.
(wasm_compute_section_file_positions): Likewise.
* xsym.c (bfd_sym_scan): Don't ignore bfd_seek return value.
(bfd_sym_read_name_table): Likewise.
binutils/
* ar.c (print_contents, extract_file): Don't ignore bfd_seek
return value.
ld/
* pdb.c (create_section_contrib_substream): Don't ignore bfd_seek
return value.
(create_section_header_stream): Likewise.
* pe-dll.c (pe_get16, pe_get32): Add fail param to return results
from bfd_seek and bfd_read.
(pe_implied_import_dll): Handle these fails, and other bfd_seek
and bfd_read return values.

RISC-V: Fix opcode entries of "vmsge{,u}.vx"

Their check_func should be "match_never", not "match_opcode".  The reasons
this error did not cause any disassembler errors are:

1.  The problem will not reproduce if "no-aliases" is specified
    (because macro instructions are handled as aliases).
2.  If not, all affected compressed instructions or their aliases
    precede before "vmsge{,u}.vx" macro instructions.

However, it'll easily break if we reorder opcode entries.  This commit
fixes this issue before the *accident* occurs.

opcodes/ChangeLog:

* riscv-opc.c (riscv_opcodes): Make sure that we never match to
vmsge{,u}.vx instructions unless specified in the assembler.

RISC-V: Remove support for non-existing 'Zve32d'

Since this "extension" does not exist (on the other hand, 'Zve64d' exists)
and it's not useful if we keep it (as other code portions just ignore
"zve32d"), this commit just removes it.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_supported_std_z_ext): Remove 'Zve32d'
extension from the list.

Automatic date update in version.in

[gdb/symtab] Fix off-by-one error in cooked_indexer::recurse

Test-case gdb.dwarf2/pr13961.exp contains:
...
 <1><25>: Abbrev Number: 8 (DW_TAG_class_type)
    <26>   DW_AT_specification: <0x2a>
 <1><2a>: Abbrev Number: 2 (DW_TAG_class_type)
    <2b>   DW_AT_name        : foo
    <2f>   DW_AT_byte_size   : 4
    <30>   DW_AT_decl_file   : 1
    <31>   DW_AT_decl_line   : 1
    <32>   DW_AT_sibling     : <0x44>
...

The DIE at 0x25 contains an intra-CU forward reference, and is deferred during
DIE indexing in the cooked_index, by adding it to m_deferred_entries.

The resulting cooked index entries are:
...
        [25] ((cooked_index_entry *) 0x333b5d0)
        name:       foo
        canonical:  foo
        qualified:  foo
        DWARF tag:  DW_TAG_class_type
        flags:      0x0 []
        DIE offset: 0x2a
        parent:     ((cooked_index_entry *) 0)

        [26] ((cooked_index_entry *) 0x333b630)
        name:       foo
        canonical:  foo
        qualified:  foo::foo
        DWARF tag:  DW_TAG_class_type
        flags:      0x0 []
        DIE offset: 0x25
        parent:     ((cooked_index_entry *) 0x333b5d0) [foo]
...

Notice that 0x2a is the parent of 0x25, and that this is why the qualified
name of 0x25 is "foo::foo", which is incorrect, it's supposed to be "foo".

The parent is set here in cooked_indexer::make_index:
...
  for (const auto &entry : m_deferred_entries)
    {
      void *obj = m_die_range_map.find (entry.spec_offset);
      cooked_index_entry *parent = static_cast<cooked_index_entry *> (obj);
      m_index_storage->add (entry.die_offset, entry.tag, entry.flags,
    entry.name, parent, m_per_cu);
    }
...
and AFAICT, we store in m_die_range_map the parent of the respective
spec_offset DIE (though that's not clear from the comment describing it).

So, the root cause of this is that when we lookup the parent for DIE 0x25, we get
m_die_range_map.find (0x2a) == 0x2a.

This is an off-by-one error, fixed in cooked_indexer::recurse by:
...
-      CORE_ADDR start = form_addr (parent_entry->die_offset,
+      CORE_ADDR start = form_addr (parent_entry->die_offset + 1,
...
which gives us:
...
    [12] ((cooked_index_entry *) 0x41e21f0)
    name:       foo
    canonical:  foo
    qualified:  foo
    DWARF tag:  DW_TAG_class_type
    flags:      0x0 []
    DIE offset: 0x25
    parent:     ((cooked_index_entry *) 0)

    [13] ((cooked_index_entry *) 0x41e2190)
    name:       foo
    canonical:  foo
    qualified:  foo
    DWARF tag:  DW_TAG_class_type
    flags:      0x0 []
    DIE offset: 0x2a
    parent:     ((cooked_index_entry *) 0)
...

Tested on x86_64-linux.

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

[gdb/symtab] Dump qualified name of cooked_index_entry

When doing "maint print objfiles" for the exec of test-case
gdb.dwarf2/pr13961.exp, we get:
...
    [25] ((cooked_index_entry *) 0x37b25d0)
    name:       foo
    canonical:  foo
    DWARF tag:  DW_TAG_class_type
    flags:      0x0 []
    DIE offset: 0x2a
    parent:     ((cooked_index_entry *) 0)

    [26] ((cooked_index_entry *) 0x37b2630)
    name:       foo
    canonical:  foo
    DWARF tag:  DW_TAG_class_type
    flags:      0x0 []
    DIE offset: 0x25
    parent:     ((cooked_index_entry *) 0x37b25d0) [foo]
...

By following the parent links in the text, we can conclude that the qualified
name of DIE 0x25 is foo::foo (which is incorrect, that's PR symtab/30739).

But it's not evident, and also hard to verify in a test-case.

Add dumping of the qualified name, such that we have:
...
    [25] ((cooked_index_entry *) 0x333b5d0)
    name:       foo
    canonical:  foo
    qualified:  foo
    DWARF tag:  DW_TAG_class_type
    flags:      0x0 []
    DIE offset: 0x2a
    parent:     ((cooked_index_entry *) 0)

    [26] ((cooked_index_entry *) 0x333b630)
    name:       foo
    canonical:  foo
    qualified:  foo::foo
    DWARF tag:  DW_TAG_class_type
    flags:      0x0 []
    DIE offset: 0x25
    parent:     ((cooked_index_entry *) 0x333b5d0) [foo]
...

Tested on x86_64-linux.

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

Fix gdb.ada/O2_float_param.exp for PowerPC

The frame command on Power pc prints the address in hex between the
#0 and in calle.increment.  For example

(gdb) frame
#0  0x0000000010010a88 in callee.increment (val=val@entry=99.0, msg=...)
    at /home/.../gdb/testsuite/gdb.ada/O2_float_param/callee.adb:19
19    procedure Increment (Val : in out Float; Msg: String) is

The printing of the address for the frame is done by function
print_frame in gdb/stack.c.  If SAL.IS_stmt is false for the frame,
function frame_show_address returns true and print_frame prints the
address.  Currently, SAL.IS is false on PowerPC and true on X86-64.

Update the set re string to accept the hex address if it exits.

Fixes two failures on PowerPC.

Patch tested on Power10 with no new regressions.

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