Fetch the NT_ARM_TLS register set for native FreeBSD/Aarch64 processes.

This permits resolving TLS variables.

Support TLS variables on FreeBSD/Aarch64.

Derive the pointer to the DTV array from the tpidr register.

Read the tpidr register from NT_ARM_TLS core dump notes on FreeBSD/Aarch64.

Add an aarch64-tls feature which includes the tpidr register.

Fetch the NT_ARM_TLS register set for native FreeBSD/arm processes.

This permits resolving TLS variables.

Support TLS variables on FreeBSD/arm.

Derive the pointer to the DTV array from the tpidruro register.

Read the tpidruro register from NT_ARM_TLS core dump notes on FreeBSD/arm.

Add an arm-tls feature which includes the tpidruro register from CP15.

fbsd-nat: Add helper routines for register sets using PT_[G]SETREGSET.

FreeBSD's kernel has recently added PT_GETREGSET and PT_SETREGSET
operations to fetch a register set named by an ELF note type.  These
helper routines provide helpers to check for a register set's
existence, fetch registers for a register set, and store registers to
a register set.

ld: Regenerate aclocal.m4 with automake 1.15.1

* aclocal.m4: Regenerate with automake 1.15.1.

gdbserver: track current process as well as current thread

The recent commit 421490af33bf ("gdbserver/linux: Access memory even
if threads are running") caused a regression in
gdb.threads/access-mem-running-thread-exit.exp with gdbserver, which I
somehow missed.  Like so:

 (gdb) print global_var
 Cannot access memory at address 0x555555558010
 (gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: access mem (print global_var after writing, inf=2, iter=1)

The problem starts with GDB telling GDBserver to select a thread, via
the Hg packet, which GDBserver complies with, then that thread exits,
and GDB, without knowing the thread is gone, tries to write to memory,
through the context of the previously selected Hg thread.

GDBserver's GDB-facing memory access routines, gdb_read_memory and
gdb_write_memory, call set_desired_thread to make GDBserver re-select
the thread that GDB has selected with the Hg packet.  Since the thread
is gone, set_desired_thread returns false, and the memory access
fails.

Now, to access memory, it doesn't really matter which thread is
selected.  All we should need is the target process.  Even if the
thread that GDB previously selected is gone, and GDB does not yet know
about that exit, it shouldn't matter, GDBserver should still know
which process that thread belonged to.

Fix this by making GDBserver track the current process separately,
like GDB also does.  Add a new set_desired_process routine that is
similar to set_desired_thread, but just sets the current process,
leaving the current thread as NULL.  Use it in the GDB-facing memory
read and write routines, to avoid failing if the selected thread is
gone, but the process is still around.

Change-Id: I4ff97cb6f42558efbed224b30d5c71f6112d44cd

Fix gdb.threads/access-mem-running-thread-exit.exp w/ native-extended-gdbserver

When testing gdb.threads/access-mem-running-thread-exit.exp with
--target_board=native-extended-gdbserver, we get:

  Running gdb.threads/access-mem-running-thread-exit.exp ...
  FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: second inferior: runto: run to main
  WARNING: Timed out waiting for EOF in server after monitor exit

  === gdb Summary ===

  # of expected passes            3
  # of unexpected failures        1
  # of unsupported tests          1

The problem is that the testcase spawns a second inferior with
-no-connection, and then runto_main does "run", which fails like so:

 (gdb) run
 Don't know how to run.  Try "help target".
 (gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: second inferior: runto: run to main

That "run" above failed because native-extended-gdbserver forces "set
auto-connect-native-target off", to prevent testcases from mistakenly
running programs with the native target, which would exactly be the
case here.

Fix this by letting the second inferior share the first inferior's
connection everywhere except on targets that do reload on run (e.g.,
--target_board=native-gdbserver).

Change-Id: Ib57105a238cbc69c57220e71261219fa55d329ed

gdb: add some additional thread status debug output

While working on this patch:

  https://sourceware.org/pipermail/gdb-patches/2022-January/185109.html

I found it really useful to print the executing/resumed status of all
threads (or all threads in a particular inferior) at various
places (e.g. when a new inferior is started, when GDB attaches, etc).

This debug was originally part of the above patch, but I wanted to
rewrite this as a separate patch and move the code into a new function
in infrun.h, which is what this patch does.

Unless 'set debug infrun on' is in effect, then there should be no
user visible changes after this commit.

Add a linker warning when creating potentially dangerous executable segments.  Add tests, options to disabke and configure switches to choose defaults.

Fix potential arithmetic overflow in the linker's plugin handling code.

PR 29101
* libdep_plugin.c (get_libdeps): Check for overflow when computing
amount of memory to allocate.

objdump: fix styled printing of addresses

Previous work to add styled disassembler output missed a case in
objdump_print_addr, which is fixed in this commit.

gdb/testsuite: small cleanup in mi-break-qualified.exp

It is not necessary to pass an empty string to mi_gdb_start, passing
the empty string is equivalent to passing no arguments, which is what
we do everywhere else (that we don't need to specify an actual
argument).

The only place we use 'mi_gdb_start ""' is in
gdb.mi/mi-break-qualified.exp, so in this commit I just replace that
with a call to 'mi_gdb_start' - just for consistency.

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

gdb/testsuite: change mi_gdb_start to take a list of flags

After this previous commit I was thinking about the API of
mi_gdb_start.  I felt that the idea of passing flags as separate
arguments and using 'args' to gather these into a list, though clever,
was not an intuitive API.

In this commit I modify mi_gdb_start so that it expects a single
argument, which should be a list of flags.  Thus, where we previously
would have said:

  mi_gdb_start separate-mi-tty separate-inferior-tty

We would now say:

  mi_gdb_start { separate-mi-tty separate-inferior-tty }

However, it turns out we never actually call mi_gdb_start passing two
arguments in this way at all.  We do in some places do this:

  mi_gdb_start separate-inferior-tty

But that's fine, a single string like this works equally well as a
single item list, so this will not need updating.

There is also one place where we do this:

  eval mi_gdb_start $start_ops

where $start_ops is a list that might contains 0, 1, or 2 items.  The
eval here is used to expand the $start_ops list so mi_gdb_start sees
the list contents as separate arguments.  In this case we just need to
drop the use of eval.

I think that the new API is more intuitive, but others might
disagree, in which case I can drop this change.

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

gdb/testsuite: fix mi-exec-run.exp with native-extended-gdbserver board

When running with the native-extended-gdbserver board, I currently see
one failure in gdb.mi/mi-exec-run.exp:

    FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout)

In this test the MI interface should be started in a separate tty,
which means we should have a CLI tty and an MI tty, however, this is
not happening.  Instead GDB is just started in MI mode and there is no
CLI tty.

The test script tries to switch between the CLI an MI terminals and
look for some expected output on each, however, as there is no CLI
terminal the expected output never arrives, and the test times out.

It turns out that this is not a GDB problem, rather, this is an issue
with argument passing within the test script.

The proc default_mi_gdb_start expects to take a set of flags (strings)
as arguments, each of flag is expected to be a separate argument.  The
default_mi_gdb_start proc collects all its arguments into a list using
the special 'args' parameter name, and then iterates over this list to
see which flags were passed.

In mi_gdb_start, which forwards to default_mi_gdb_start, the arguments
are also gathered into the 'args' parameter list, but are then
expanded back to be separate arguments using the eval trick, i.e.:

  proc mi_gdb_start { args } {
    return [eval default_mi_gdb_start $args]
  }

This ensures that when we arrive in default_mi_gdb_start each flag is
a separate argument, rather than appearing as a single list containing
all arguments.

When using the native-extended-gdbserver board however, the file
boards/native-extended-gdbserver.exp is loaded, and this file replaces
the default mi_gdb_start with its own version.

This new mi_gdb_start also gathers the arguments into an 'args' list,
but forgets to expand the arguments out using the eval trick.

As a result, when using the native-extended-gdbserver board, by the
time we get to default_mi_gdb_start, we end up with the args list
containing a single item, which is a list containing all the arguments
the user passed.

What this means is that if the user passes two arguments, then, in
default_mi_gdb_start, instead of seeing two separate arguments, we see
a single argument made by concatenating the two arguments together.

The only place this is a problem is in the test mi-exec-run.exp,
which (as far as I can see) is the only test where we might try to
pass both arguments at the same time.  Currently we think we passed
both arguments to mi_gdb_start, but mi_gdb_start behaves as if no
arguments were passed.

This commit fixes the problem by making use of the eval trick within
the native-extended-gdbserver version of mi_gdb_start.  After this,
the FAIL listed at the top of this message is resolved.

gdb: fix failures in gdb.mi/mi-exec-run.exp with native-extended-gdbserver

When running the gdb.mi/mi-exec-run.exp test using the
native-extended-gdbserver I see failures like this:

  FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=main: force-fail=1: run failure detected
  FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=separate: force-fail=1: run failure detected
  FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected

There's a race condition here, so you might see a slightly different
set of failures, but I always see some from the 'run failure detected'
test.

NOTE: I also see an additional test failure:

 FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout)

but that is a completely different issue, and is not being addressed
in this commit.

The problem for the 'run failure detected' test is that we end up
in gdb_expect looking for output from two spawn-ids, one from
gdbserver, and one from gdb.  We're looking for one output pattern
from each spawn-id, and for the test to pass we need to see both
patterns.

Now, if gdb exits then this is a test failure (this would indicate gdb
crashing, which is bad), so we have an eof pattern associated with
the gdb spawn-id.

However, in this particular test we expect gdbserver to fail to
execute the binary (the test binary is set non-executable), and so we
get an error message from gdbserver (which matches the pattern), and
then gdbserver exits, this is expected.

The problem is that after spotting the pattern from gdbserver, we
often see the eof from gdbserver before we see the pattern from gdb.
If this happens then we drop out of the gdb_expect without ever seeing
the pattern from gdb, and fail the test.

In this commit, I place the spawn-id of gdbserver into a global
variable, and then use this global variable as the -i option within
the gdb_expect.

Now, once we have seen the expected pattern on the gdbserver spawn-id,
the global variable is cleared.  After this the gdb_expect no longer
checks the gdbserver spawn-id for additional output, and so never sees
the eof event.  This leaves the gdb_expect running, which allows the
pattern from gdb to be seen, and for the test to pass.

I now see no failures relating to 'run failure detected'.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.cp/align.exp with gcc 12.1 / 11.3

Starting with gcc 12.1 / gcc 11.3, for test-case gdb.cp/align.exp we run into:
...
align.cc:29:23: error: invalid application of 'alignof' to a void type^M
   29 |     unsigned a_void = alignof (void);^M
      |                       ^~~~~~~~~~~~~~^M
...

Fix this by using __alignof__ instead.

Tested on x86_64-linux, with gcc 7.5.0, gcc 12.1 and clang 12.0.1.

gdb/debuginfod: Whitespace-only URL should disable debuginfod

Currently debuginfod is disabled when the string of server URLs
is unset or set to be the empty string (via the $DEBUGINFOD_URLS
environment variable or the 'set debuginfod urls' gdb command).

Extend this functionality so that a whitespace-only URL also disables
debuginfod.

Modify a testcase to verify that a whitespace-only URL disables
debuginfod.

gdb: remove type_wanted parameter from a few functions

The type_wanted value, passed down to the create_sals_from_location
callback, is never used.  Remove it.

Change-Id: Ic363ee13f6af593a3e875ff7fe46de130cdc190c

gnulib: update to bd11400942d6

Update the gnulib import to fixes these issues:

  - GDB build with clang + glibc < 2.33.

      https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=d6a07b4dc21b3118727743142c678858df442853
      https://lists.gnu.org/archive/html/bug-gnulib/2022-04/msg00072.html

    With glibc < 2.33, gnulib (since relatively recently) enables a
    replacement for free (see gnulib/import/m4/free.m4).  In that path,
    clang shows this error:

        make[2]: Entering directory '/home/smarchi/build/binutils-gdb-clang/gdbsupport'
          CXX      agent.o
        In file included from /home/smarchi/src/binutils-gdb/gdbsupport/agent.cc:20:
        In file included from /home/smarchi/src/binutils-gdb/gdbsupport/common-defs.h:95:
        ../gnulib/import/string.h:636:19: error: exception specification in declaration does not match previous declaration
        _GL_EXTERN_C void free (void *) throw ();
                          ^
        ../gnulib/import/stdlib.h:737:17: note: expanded from macro 'free'
        #   define free rpl_free
                        ^
        ../gnulib/import/stdlib.h:739:1: note: previous declaration is here
        _GL_FUNCDECL_RPL (free, void, (void *ptr));
        ^
        ../gnulib/import/sys/select.h:251:23: note: expanded from macro '_GL_FUNCDECL_RPL'
          _GL_FUNCDECL_RPL_1 (rpl_##func, rettype, parameters_and_attributes)
                              ^
        <scratch space>:139:1: note: expanded from here
        rpl_free
        ^

    The gnulib commit mentioned fixes the exception specification of `free`.

 - GDB build on RHEL 7:

      CC       libgnu_a-openat-proc.o
    In file included from /usr/include/string.h:633,
                     from ./string.h:41,
                     from ../../../binutils-gdb/gnulib/import/openat-proc.c:30:
    ./string.h:1105:1: error: expected identifier or '(' before '__extension__'
     1105 | _GL_FUNCDECL_SYS (strndup, char *,
          | ^~~~~~~~~~~~~~~~

     https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=84863a1c4dc8cca8fb0f6f670f67779cdd2d543b
     https://lists.gnu.org/archive/html/bug-gnulib/2022-04/msg00075.html

Change-Id: Ibd51302feece6f385d0c53e0d08921b5d95e2776

Fix Ada catchpoint regression

The breakpoint C++-ification series introduced a regression for Ada
catchpoints.  Specifically, commit 2b5ab5b8 ("Convert base breakpoints
to vtable ops") caused these to start failing.  I didn't notice this
because testing Ada using a Linux distro compiler requires installing
the GNAT debuginfo, which I hadn't done.

This patch fixes the problem.  I'm checking it in.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.multi/attach-no-multi-process.exp with check-readmore

When running test-case gdb.multi/attach-no-multi-process.exp with
check-readmore, I get:
...
(gdb) attach 13411^M
Attaching to Remote target^M
No unwaited-for children left.^M
(gdb) Reading symbols from attach-no-multi-process...^M
Reading symbols from /lib64/libm.so.6...^M
(No debugging symbols found in /lib64/libm.so.6)^M
Reading symbols from /lib64/libc.so.6...^M
(No debugging symbols found in /lib64/libc.so.6)^M
Reading symbols from /lib64/ld-linux-x86-64.so.2...^M
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)^M
0x00007f5df1fffc8a in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6^M
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=off: \
  attach to the program via remote (timeout)
...

The problem is that the attach output is matched using gdb_test, which uses
the '$gdb_prompt $' regexp, and this does not handle the case that '(gdb) ' is
not the last available output.

Fix this by using a gdb_test_multiple instead with a '$gdb_prompt ' regexp, so
without the '$' anchor.

Tested on x86_64-linux with native, check-read1 and check-readmore.

Automatic date update in version.in

opcodes: don't assume ELF in riscv, csky, rl78, mep disassemblers

Currently, the get_disassembler() implementations for riscv, csky, and
rl78--and mep_print_insn() for mep--access ELF variants of union fields
without first checking that the bfd actually represents an ELF.  This
causes undefined behavior and crashes when disassembling non-ELF files
(the "binary" BFD, for example).  Fix that.

Automatic date update in version.in

Remove create_breakpoints_sal_default

create_breakpoints_sal_default is just a simple wrapper, so remove it.

Remove allocate_bp_location

allocate_bp_location is just a small wrapper for a method call, so
inline it everywhere.

Constify breakpoint_ops

Now that all breakpoint_ops are statically initialized, they can all
be made const.

Remove breakpoint ops initialization

initialize_breakpoint_ops does not do much any more, so remove it in
favor of statically-initialize objects.

Remove vtable_breakpoint_ops

There's no need to have vtable_breakpoint_ops any more, so remove it
in favor of base_breakpoint_ops.

Remove most fields from breakpoint_ops

At this point, all implementations of breakpoints use the vtable.  So,
we can now remove most function pointers from breakpoint_ops and
switch to using methods directly in the callers.  Only the two "static
virtual" methods remain in breakpoint_ops.

Remove breakpoint_ops from init_catchpoint

init_catchpoint is only ever passed a single breakpoint_ops pointer,
so remove the parameter.

Remove breakpoint_ops from init_ada_exception_breakpoint

init_ada_exception_breakpoint is only ever passed a single
breakpoint_ops structure, so remove the parameter.

Merge probe and ordinary tracepoints

Right now, probe tracepoints are handled by a separate ops object.
However, they differ only in a small way from ordinary tracepoints,
and furthermore can be distinguished by their event location.

This patch merges the two cases, just as was done for breakpoints.

Merge probe and ordinary breakpoints

Right now, probe breakpoints are handled by a separate ops object.
However, they differ only in a small way from ordinary breakpoints,
and furthermore can be distinguished by their "probe" object.

This patch merges the two cases.  This avoids having to introduce a
new bp_ constant (which can be quite subtle to do correctly) and a new
subclass.

Remove bkpt_base_breakpoint_ops

An earlier patch removed the last use of bkpt_base_breakpoint_ops, so
remove the object entirely.

Convert static marker tracepoints to vtable ops

This converts static marker tracepoints to use vtable_breakpoint_ops.

Add bp_static_marker_tracepoint

Because the actual construction of a breakpoint is buried deep in
create_breakpoint, at present it's necessary to have a new bp_
enumerator constant any time a new subclass is needed.  Static marker
tracepoints are one such case, so this patch introduces
bp_static_marker_tracepoint and updates various spots to recognize it.

Convert ranged breakpoints to vtable ops

This converts ranged breakpoints to use vtable_breakpoint_ops.  This
requires introducing a new ranged_breakpoint type, but this is
relatively simple because ranged breakpoints can only be created by
break_range_command.

Convert dprintf to vtable ops

This converts dprintf to use vtable_breakpoint_ops.

Convert Ada catchpoints to vtable ops

This converts Ada catchpoints to use vtable_breakpoint_ops.

Convert ordinary breakpoints to vtable ops

This converts "ordinary" breakpoint to use vtable_breakpoint_ops.
Recall that an ordinary breakpoint is both the kind normally created
by users, and also a base class used by other classes.

Change inheritance of dprintf

The dprintf breakpoint ops is mostly a copy of bpkt_breakpoint_ops,
except it's written out explicitly -- and, importantly, there's
nothing that bpkt_breakpoint_ops overrides that dprintf does not.
This changes dprintf to simply inherit directly, and updates struct
dprintf_breakpoint to reflect the change as well.

Convert momentary breakpoints to vtable ops

This converts momentary breakpoints to use vtable_breakpoint_ops.

Convert internal breakpoints to vtable ops

This converts internal breakpoints to use vtable_breakpoint_ops.

Convert break-catch-throw to vtable ops

This converts break-catch-throw.c to use vtable_breakpoint_ops.

Convert base breakpoints to vtable ops

This converts base breakpoints to use vtable_breakpoint_ops.

Add some new subclasses of breakpoint

This adds a few new subclasses of breakpoint.  The inheritance
hierarchy is chosen to reflect what's already present in
initialize_breakpoint_ops -- it mirrors the way that the _ops
structures are filled in.

This patch also changes new_breakpoint_from_type to create the correct
sublcass based on bptype.  This is important due to the somewhat
inverted way in which create_breakpoint works; and in particular later
patches will change some of these entries.

Convert tracepoints to vtable ops

This converts tracepoints to use vtable_breakpoint_ops.

Convert watchpoints to vtable ops

This converts watchpoints and masked watchpoints. to use
vtable_breakpoint_ops.  For masked watchpoints, a new subclass must be
introduced, and watch_command_1 is changed to create one.

Convert break-catch-load to vtable ops

This converts break-catch-load.c to use vtable_breakpoint_ops.

Convert break-catch-fork to vtable ops

This converts break-catch-fork.c to use vtable_breakpoint_ops.

Convert break-catch-exec to vtable ops

This converts break-catch-exec.c to use vtable_breakpoint_ops.

Convert break-catch-syscall to vtable ops

This converts break-catch-syscall.c to use vtable_breakpoint_ops.

Convert break-catch-sig to use vtable ops

This converts break-catch-sig.c to use vtable_breakpoint_ops.

Add a vtable-based breakpoint ops

This adds methods to struct breakpoint.  Each method has a similar
signature to a corresponding function in breakpoint_ops, with the
exceptions of create_sals_from_location and create_breakpoints_sal,
which can't be virtual methods on breakpoint -- they are only used
during the construction of breakpoints.

Then, this adds a new vtable_breakpoint_ops structure and populates it
with functions that simply forward a call from breakpoint_ops to the
corresponding virtual method.  These are all done with lambdas,
because they are just a stepping stone -- by the end of the series,
this structure will be deleted.

Return bool from breakpoint_ops::print_one

This changes breakpoint_ops::print_one to return bool, and updates all
the implementations and the caller.  The caller is changed so that a
NULL check is no longer needed -- something that will be impossible
with a real method.

Delete some unnecessary wrapper functions

This patch deletes a few unnecessary wrapper functions from
breakpoint.c.

Add an assertion to clone_momentary_breakpoint

This adds an assertion to clone_momentary_breakpoint.  This will
eventually be removed, but in the meantime is is useful for helping
convince oneself that momentary breakpoints will always use
momentary_breakpoint_ops.  This understanding will help when cleaning
up the code later.

Boolify print_solib_event

Change print_solib_event to accept a bool parameter and update the
callers.

Move "catch load" to a new file

The "catch load" code is reasonably self-contained, and so this patch
moves it out of breakpoint.c and into a new file, break-catch-load.c.
One function from breakpoint.c, print_solib_event, now has to be
exposed, but this seems pretty reasonable.

gprofng: assertion in gprofng/src/Expression.cc:139

gprofng/ChangeLog
2022-04-28  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29102
* src/Expression.h: Remove fixupValues.
* src/Expression.cc (Expression::copy): Fix a bug.

De-duplicate .gdb_index

This de-duplicates variables and types in .gdb_index, making the new
index closer to what gdb generated before the new DWARF scanner
series.  Spot-checking the resulting index for gdb itself, it seems
that the new scanner picks up some extra symbols not detected by the
old one.  I tested both the new and old versions of gdb on both new
and old versions of the index, and startup time in all cases is
roughly the same (it's worth noting that, for gdb itself, the index no
longer provides any benefit over the DWARF scanner).  So, I think this
fixes the size issue with the new index writer.

Regression tested on x86-64 Fedora 34.

Fix .debug_names regression with new indexer

At AdaCore, we run the internal gdb test suite in several modes,
including one using the .debug_names index.  This caught a regression
caused by the new DWARF indexer.

First, the psymtabs-based .debug_names generator was completely wrong.
However, to avoid making the rewrite series even bigger (fixing the
writer will also require rewriting the .debug_names reader), it
attempted to preserve the weirdness.

However, this was not done properly.  For example the old writer did
this:

-      case STRUCT_DOMAIN:
- return DW_TAG_structure_type;

The new code, instead, simply preserves the actual DWARF tag -- but
this makes future lookups fail, because the .debug_names reader only
looks for DW_TAG_structure_type.

This patch attempts to revert to the old behavior in the writer.

gdb/infrun: make fetch_inferior_event restore thread if exited or signalled

Commit 152a1749566 ("gdb: prune inferiors at end of
fetch_inferior_event, fix intermittent failure of
gdb.threads/fork-plus-threads.exp") introduced some follow-fork-related
test failures, such as:

    info inferiors^M
      Num  Description       Connection           Executable        ^M
    * 1    process 634972    1 (native)           /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork ^M
      2    process 634975    1 (native)           /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork ^M
    (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: info inferiors
    inferior 2^M
    [Switching to inferior 2 [process 634975] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork)]^M
    [Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 634975))]^M
    #0  0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6^M
    (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: inferior 2
    continue^M
    Continuing.^M
    [Inferior 2 (process 634975) exited normally]^M
    [Switching to Thread 0x7ffff7c9a740 (LWP 634972)]^M
    (gdb) PASS: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: continue until exit at continue unfollowed inferior to end
    break callee^M
    Breakpoint 2 at 0x555555555160: file /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c, line 9.^M
    (gdb) FAIL: gdb.base/foll-fork.exp: follow-fork-mode=parent: detach-on-fork=off: cmd=next 2: test_follow_fork: break callee

What happens here is:

 - inferior 2 is selected
 - we continue, leading to inferior 2's exit
 - we set breakpoint, expect 2 locations, but only one location is
   resolved

Reading between the lines, we understand that inferior 2 got pruned,
when it shouldn't have been.

The issue can be reproduced by hand with:

    $ ./gdb -q --data-directory=data-directory testsuite/outputs/gdb.base/foll-fork/foll-fork -ex "set detach-on-fork off" -ex start -ex "next 2" -ex "inferior 2" -ex "set debug infrun"
    ...
    Temporary breakpoint 1, main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:14
    14        int  v = 5;
    [New inferior 2 (process 637627)]
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
    17        if (pid == 0) /* set breakpoint here */
    [Switching to inferior 2 [process 637627] (/home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork)]
    [Switching to thread 2.1 (Thread 0x7ffff7c9a740 (LWP 637627))]
    #0  0x00007ffff7d7abf7 in _Fork () from /usr/lib/libc.so.6
    (gdb) continue
    Continuing.
    [infrun] clear_proceed_status_thread: 637627.637627.0
    [infrun] proceed: enter
      [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT
      [infrun] scoped_disable_commit_resumed: reason=proceeding
      [infrun] start_step_over: enter
        [infrun] start_step_over: stealing global queue of threads to step, length = 0
        [infrun] operator(): step-over queue now empty
      [infrun] start_step_over: exit
      [infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop
        [infrun] proceed: resuming 637627.637627.0
        [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [637627.637627.0] at 0x7ffff7d7abf7
        [infrun] do_target_resume: resume_ptid=637627.637627.0, step=0, sig=GDB_SIGNAL_0
        [infrun] infrun_async: enable=1
        [infrun] prepare_to_wait: prepare_to_wait
      [infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop
      [infrun] reset: reason=proceeding
      [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target native
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native
      [infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target native
    [infrun] proceed: exit
    [infrun] fetch_inferior_event: enter
      [infrun] scoped_disable_commit_resumed: reason=handling event
      [infrun] do_target_wait: Found 2 inferiors, starting at #1
      [infrun] random_pending_event_thread: None found.
      [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
      [infrun] print_target_wait_results:   637627.637627.0 [process 637627],
      [infrun] print_target_wait_results:   status->kind = EXITED, exit_status = 0
      [infrun] handle_inferior_event: status->kind = EXITED, exit_status = 0
    [Inferior 2 (process 637627) exited normally]
      [infrun] stop_waiting: stop_waiting
      [infrun] stop_all_threads: start: reason=presenting stop to user in all-stop, inf=-1
        [infrun] stop_all_threads: pass=0, iterations=0
        [infrun] stop_all_threads:   637624.637624.0 not executing
        [infrun] stop_all_threads: pass=1, iterations=1
        [infrun] stop_all_threads:   637624.637624.0 not executing
        [infrun] stop_all_threads: done
      [infrun] stop_all_threads: end: reason=presenting stop to user in all-stop, inf=-1
    [Switching to Thread 0x7ffff7c9a740 (LWP 637624)]
      [infrun] infrun_async: enable=0
      [infrun] reset: reason=handling event
      [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads
    (gdb) [infrun] fetch_inferior_event: exit
    (gdb) info inferiors
      Num  Description       Connection           Executable
    * 1    process 637624    1 (native)           /home/simark/build/binutils-gdb-one-target/gdb/testsuite/outputs/gdb.base/foll-fork/foll-fork
    (gdb) i th
      Id   Target Id                                      Frame
    * 1    Thread 0x7ffff7c9a740 (LWP 637624) "foll-fork" main () at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/foll-fork.c:17

After handling the EXITED event for inferior 2, inferior 2 should have
stayed the current inferior, which should have prevented it from getting
pruned.  When debugging, we find that when getting at the
prune_inferiors call, the current inferior is inferior 1.  Further
debugging shows that prior to the call to
clean_up_just_stopped_threads_fsms, the current inferior is inferior 2,
and after, it's inferior 1.  Then, back in fetch_inferior_event, the
restore_thread object is disabled, due to:

    /* If we got a TARGET_WAITKIND_NO_RESUMED event, then the
       previously selected thread is gone.  We have two
       choices - switch to no thread selected, or restore the
       previously selected thread (now exited).  We chose the
       later, just because that's what GDB used to do.  After
       this, "info threads" says "The current thread <Thread
       ID 2> has terminated." instead of "No thread
       selected.".  */
    if (!non_stop
&& cmd_done
&& ecs->ws.kind () != TARGET_WAITKIND_NO_RESUMED)
      restore_thread.dont_restore ();

So in the end, inferior 1 stays current, and inferior 2 gets wrongfully
pruned.

I'd say clean_up_just_stopped_threads_fsms is the culprit here.  It
actually attempts to restore the event_thread to be current at the end,
after the loop (I presume the current thread on entry is always supposed
to be the event thread).  But in this case, the event is of kind EXITED,
and ecs->event_thread is not set, so the current inferior isn't
restored.

Fix that by using scoped_restore_current_thread.  If there is no current
thread, scoped_restore_current_thread will still restore the current
inferior, and that's what we want.

Random note: the thread_info object for inferior 2's thread is never
freed.  It is held (by refcount) by the restore_thread object in
fetch_inferior_event, while the inferior's thread list gets cleared, in
the exit event processing.  When the refcount reaches 0 (when the
restore_thread object is destroyed), there's nothing that actually
deletes the thread_info object.  And I think that nothing in GDB points
to it anymore, so it leaks.  I don't want to fix that in this patch, but
thought it would be good to mention it, in case somebody has an idea for
how to fix that.

Change-Id: Ibc7df543e2c46aad5f3b9250b28c3fb5912be4e8

Slightly tweak and clarify target_resume's interface

The current target_resume interface is a bit odd & non-intuitive.
I've found myself explaining it a couple times the recent past, while
reviewing patches that assumed STEP/SIGNAL always applied to the
passed in PTID.  It goes like this today:

  - if the passed in PTID is a thread, then the step/signal request is
    for that thread.

  - otherwise, if PTID is a wildcard (all threads or all threads of
    process), the step/signal request is for inferior_ptid, and PTID
    indicates which set of threads run free.

Because GDB always switches the current thread to "leader" thread
being resumed/stepped/signalled, we can simplify this a bit to:

  - step/signal are always for inferior_ptid.

  - PTID indicates the set of threads that run free.

Still not ideal, but it's a minimal change and at least there are no
special cases this way.

That's what this patch does.  It renames the PTID parameter to
SCOPE_PTID, adds some assertions to target_resume, and tweaks
target_resume's description.  In addition, it also renames PTID to
SCOPE_PTID in the remote and linux-nat targets, and simplifies their
implementation a little bit.  Other targets could do the same, but
they don't have to.

Change-Id: I02a2ec2ab3a3e9b191de1e9a84f55c17cab7daaf

Automatic date update in version.in

Fix libinproctrace.so build on PPC

The recent gnulib import caused a build failure of libinproctrace.so
on PPC:

    alloc.c:(.text+0x20): undefined reference to `rpl_malloc'
    alloc.c:(.text+0x70): undefined reference to `rpl_realloc'

This patch fixes the problem using the same workaround that was
previously used for free.

x86: Properly handle function pointer reference

Update

commit ebb191adac4ab45498dec0bfaac62f0a33537ba4
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Wed Feb 9 15:51:22 2022 -0800

    x86: Disallow invalid relocation against protected symbol

to allow function pointer reference and make sure that PLT entry isn't
used for function reference due to function pointer reference.

bfd/

PR ld/29087
* elf32-i386.c (elf_i386_scan_relocs): Don't set
pointer_equality_needed nor check non-canonical reference for
function pointer reference.
* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.

ld/

PR ld/29087
* testsuite/ld-x86-64/x86-64.exp: Run PR ld/29087 tests.
* testsuite/ld-x86-64/protected-func-3.c: New file.

Check OBJF_NOT_FILENAME in DWARF index code

The DWARF index code currently uses 'stat' to see if an objfile
represents a real file.  However, I think it's more correct to check
OBJF_NOT_FILENAME instead.

Regression tested on x86-64 Fedora 34.

Remove "typedef enum ..."

I noticed a few spots in GDB that use "typedef enum".  However, in C++
this isn't as useful, as the tag is automatically entered as a
typedef.  This patch removes most uses of "typedef enum" -- the
exceptions being in some nat-* code I can't compile, and
glibc_thread_db.h, which I think is more or less a copy of some C code
from elsewhere.

Tested by rebuilding.

gdb: fix nullptr dereference in block::ranges()

This commit:

  commit f5cb8afdd297dd68273d98a10fbfd350dff918d8
  Date:   Sun Feb 6 22:27:53 2022 -0500

      gdb: remove BLOCK_RANGES macro

introduces a potential nullptr dereference in block::ranges, this is
breaking most tests, e.g. gdb.base/break.exp is failing for me.

In the above patch BLOCK_CONTIGUOUS_P is changed from this:

  #define BLOCK_CONTIGUOUS_P(bl)  (BLOCK_RANGES (bl) == nullptr \
                                   || BLOCK_NRANGES (bl) <= 1)

to this:

  #define BLOCK_CONTIGUOUS_P(bl)  ((bl)->ranges ().size () == 0 \
                                   || (bl)->ranges ().size () == 1)

So, before the commit we checked for the block ranges being nullptr,
but afterwards we just call block::ranges() in all cases.

The problem is that block::ranges() looks like this:

  /* Return a view on this block's ranges.  */
  gdb::array_view<blockrange> ranges ()
  { return gdb::make_array_view (m_ranges->range, m_ranges->nranges); }

where m_ranges is:

  struct blockranges *m_ranges;

And so, we see that the nullptr check has been lost, and we might end
up dereferencing a nullptr.

My proposed fix is to move the nullptr check into block::ranges, and
return an explicit empty array_view if m_ranges is nullptr.

After this, everything seems fine again.

s390: Add DT_JMPREL pointing to .rela.[i]plt with static-pie

In static-pie case, there are IRELATIVE-relocs in
.rela.iplt (htab->irelplt), which will later be grouped
to .rela.plt.  On s390, the IRELATIVE relocations are
always located in .rela.iplt - even for non-static case.
Ensure that DT_JMPREL, DT_PLTRELA, DT_PLTRELASZ is added
to the dynamic section even if htab->srelplt->size == 0.
See _bfd_elf_add_dynamic_tags in bfd/elflink.c.

bfd/
elf64-s390.c (elf_s390_size_dynamic_sections):
Enforce DT_JMPREL via htab->elf.dt_jmprel_required.

s390: Avoid dynamic TLS relocs in PIE

No dynamic relocs are needed for TLS defined in an executable, the
TP relative offset is known at link time.

Fixes
FAIL: Build pr22263-1

bfd/
PR ld/22263
* elf64-s390.c (elf_s390_tls_transition): Use bfd_link_dll
instead of bfd_link_pic for TLS.
(elf_s390_check_relocs): Likewise.
(allocate_dynrelocs): Likewise.
(elf_s390_relocate_section): Likewise.

libctf: impose an ordering on conflicting types

When two types conflict and they are not types which can have forwards
(say, two arrays of different sizes with the same name in two different
TUs) the CTF deduplicator uses a popularity contest to decide what to
do: the type cited by the most other types ends up put into the shared
dict, while the others are relegated to per-CU child dicts.

This works well as long as one type *is* most popular -- but what if
there is a tie?  If several types have the same popularity count,
we end up picking the first we run across and promoting it, and
unfortunately since we are working over a dynhash in essentially
arbitrary order, this means we promote a random one.  So multiple
runs of ld with the same inputs can produce different outputs!
All the outputs are valid, but this is still undesirable.

Adjust things to use the same strategy used to sort types on the output:
when there is a tie, always put the type that appears in a CU that
appeared earlier on the link line (and if there is somehow still a tie,
which should be impossible, pick the type with the lowest type ID).

Add a testcase -- and since this emerged when trying out extern arrays,
check that those work as well (this requires a newer GCC, but since all
GCCs that can emit CTF at all are unreleased this is probably OK as
well).

Fix up one testcase that has slight type ordering changes as a result
of this change.

libctf/ChangeLog:

* ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Use
cd_output_first_gid to break ties.

ld/ChangeLog:

* testsuite/ld-ctf/array-conflicted-ordering.d: New test, using...
* testsuite/ld-ctf/array-char-conflicting-1.c: ... this...
* testsuite/ld-ctf/array-char-conflicting-2.c: ... and this.
* testsuite/ld-ctf/array-extern.d: New test, using...
* testsuite/ld-ctf/array-extern.c: ... this.
* testsuite/ld-ctf/conflicting-typedefs.d: Adjust for ordering
changes.

libctf: add a comment explaining how to use ctf_*open

Specifically, tell users what to pass to those functions that accept raw
section content, since it's fairly involved and easy to get wrong.
(.dynsym / .dynstr when CTF_F_DYNSTR is set, otherwise .symtab / .strtab).

include/ChangeLog:

* ctf-api.h (ctf_*open): Improve comment.

gprofng: test suite problems

gprofng/ChangeLog
2022-04-27  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29065
* testsuite/lib/Makefile.skel: Search parent dir for libs too.

gdb: remove BLOCKVECTOR_MAP macro

Replace with equivalent methods.

Change-Id: I4e56c76dfc363c1447686fb29c4212ea18b4dba0

gdb: constify addrmap_find

addrmap_find shouldn't need to modify the addrmap, so constify the
addrmap parameter.  This helps for the following patch, where getting
the map of a const blockvector will return a const addrmap.

Change-Id: If670e425ed013724a3a77aab7961db50366dccb2

gdb: remove BLOCKVECTOR_BLOCK and BLOCKVECTOR_NBLOCKS macros

Replace with calls to blockvector::blocks, and the appropriate method
call on the returned array_view.

Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd

gdb: remove BLOCK_ENTRY_PC macro

Replace with equivalent method.

Change-Id: I0e033095e7358799930775e61028b48246971a7d

gdb: remove BLOCK_CONTIGUOUS_P macro

Replace with an equivalent method.

Change-Id: I60fd3be7b4c2601c2a74328f635fa48ed80eb7f5

gdb: remove BLOCK_RANGE macro

Replace with access through the block::ranges method.

Change-Id: I50f3ed433b997c9f354e49bc6583f540ae4b6121

gdb: remove BLOCK_NRANGES macro

Replace with range for loops.

Change-Id: Icbe04f9b6f9e6ddae2e15b2409c61f7a336bc3e3

gdb: remove BLOCK_RANGES macro

Replace with an equivalent method on struct block.

Change-Id: I6dcf13e9464ba8a08ade85c89e7329c300fd6c2a

gdb: remove BLOCK_RANGE_{START,END} macros

Replace with equivalent methods on blockrange.

Change-Id: I20fd8f624e0129782c36768291891e7582d77c74

gdb: remove BLOCK_NAMESPACE macro

Replace with equivalent methods.

Change-Id: If86b8cbdfb0f52e22c929614cd53e73358bab76a

gdb: remove BLOCK_MULTIDICT macro

Replace with equivalent methods.

Change-Id: If9a239c511a664f2a59fecb6d1cd579881b23dc2

gdb: remove BLOCK_SUPERBLOCK macro

Replace with equivalent methods.

Change-Id: I334a319909a50b5cc5570a45c38c70e10dc00630

gdb: remove BLOCK_FUNCTION macro

Replace with equivalent methods.

Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101

gdb: remove BLOCK_{START,END} macros

Replace with equivalent methods.

Change-Id: I10a6c8a2a86462d9d4a6a6409a3f07a6bea66310

Automatic date update in version.in

x86: Disable 2 tests with large memory requirement

gas/

* testsuite/gas/i386/i386.exp: Disable rept.

ld/

* testsuite/ld-x86-64/x86-64.exp: Disable pr17618.

Make gdb.base/parse_number.exp test all architectures

There are some subtle differences between architectures, like the size
of a "long" type, and this isn't currently accounted for in
gdb.base/parse_number.exp.

For example, on aarch64 a long type is 8 bytes, whereas a long type is
4 bytes for x86_64.  This causes the following FAIL's:

 FAIL: gdb.base/parse_number.exp: lang=asm: ptype 0xffffffffffffffff
 FAIL: gdb.base/parse_number.exp: lang=auto: ptype 0xffffffffffffffff
 FAIL: gdb.base/parse_number.exp: lang=c: ptype 0xffffffffffffffff
 FAIL: gdb.base/parse_number.exp: lang=c++: ptype 0xffffffffffffffff
 FAIL: gdb.base/parse_number.exp: lang=fortran: p/x 0xffffffffffffffff
 FAIL: gdb.base/parse_number.exp: lang=fortran: ptype 0xffffffffffffffff
 FAIL: gdb.base/parse_number.exp: lang=go: ptype 0xffffffffffffffff
 FAIL: gdb.base/parse_number.exp: lang=local: ptype 0xffffffffffffffff
 FAIL: gdb.base/parse_number.exp: lang=minimal: ptype 0xffffffffffffffff
 FAIL: gdb.base/parse_number.exp: lang=objective-c: ptype 0xffffffffffffffff
 FAIL: gdb.base/parse_number.exp: lang=opencl: ptype 0xffffffffffffffff
 FAIL: gdb.base/parse_number.exp: lang=pascal: ptype 0xffffffffffffffff

There are some fortran-specific divergences as well, where 32-bit
architectures show "unsigned int" for both 32-bit and 64-bit integers
and 64-bit architectures show "unsigned int" and "unsigned long" for
32-bit and 64-bit integers.

There might be a bug that 32-bit fortran truncates 64-bit values to
32-bit, given "p/x 0xffffffffffffffff" returns "0xffffffff".

Here's what we get for aarch64:

 (gdb) ptype 0xffffffff
 type = unsigned int
 (gdb) ptype 0xffffffffffffffff
 type = unsigned long
 (gdb) p sizeof (0xffffffff)
 $1 = 4
 (gdb) p sizeof (0xffffffffffffffff)
 quit
 $2 = 8
 (gdb) ptype 0xffffffff
 type = unsigned int
 (gdb) ptype 0xffffffffffffffff
 type = unsigned long

And for arm:

 (gdb) ptype 0xffffffff
 type = unsigned int
 (gdb) ptype 0xffffffffffffffff
 quit
 type = unsigned long long
 (gdb) p sizeof (0xffffffff)
 quit
 $1 = 4
 (gdb) p sizeof (0xffffffffffffffff)
 quit
 $2 = 8
 (gdb) ptype 0xffffffff
 type = unsigned int
 (gdb) ptype 0xffffffffffffffff
 type = unsigned long

This patch...

* Makes the testcase iterate over all architectures, thus covering all
  the different combinations of types/sizes every time.

* Adjusts the expected values and types based on the sizes of long
  long, long and int.

A particularly curious architecture is s12z, which has 32-bit long
long, and thus no way to represent 64-bit integers in C-like
languages.

Co-Authored-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ifc0ccd33e7fd3c7585112ff6bebe7d266136768b