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

Fix gdbserver build for x86-64 Windows

I broke the gdbserver build on x86-64 Windows a little while back.
Previously, I could not build this configuration, but today I found
out that if I configure with:

    --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32

using the Fedora 34 tools, it will in fact build.  I'm not certain,
but maybe the gnulib update helped with this.

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

Create pseudo sections for NT_ARM_TLS notes on FreeBSD.

bfd/ChangeLog:

* elf.c (elfcore_grok_freebsd_note): Handle NT_ARM_TLS notes.

gdb/arm: Extend arm_m_addr_is_magic to support FNC_RETURN, add unwind-secure-frames command

This patch makes use of the support for several stack pointers
introduced by the previous patch to switch between them as needed
during unwinding.

It introduces a new 'unwind-secure-frames' arm command to enable/disable
mode switching during unwinding. It is enabled by default.

It has been tested using an STM32L5 board (with cortex-m33) and the
sample applications shipped with the STM32Cube development
environment: GTZC_TZSC_MPCBB_TrustZone in
STM32CubeL5/Projects/NUCLEO-L552ZE-Q/Examples/GTZC.

The test consisted in setting breakpoints in various places and check
that the backtrace is correct: SecureFault_Callback (Non-secure mode),
__gnu_cmse_nonsecure_call (before and after the vpush instruction),
SecureFault_Handler (Secure mode).

This implies that we tested only some parts of this patch (only MSP*
were used), but remaining parts seem reasonable.

Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>

gdb/arm: Add support for multiple stack pointers on Cortex-M

Armv8-M architecture with Security extension features four stack pointers
to handle Secure and Non-secure modes.

This patch adds support to switch between them as needed during
unwinding, and replaces all updates of cache->prev_sp with calls to
arm_cache_set_prev_sp.

Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>

gdb/arm: Introduce arm_cache_init

This patch is a preparation for the rest of the series and adds two
arm_cache_init helper functions. It updates every place that updates
cache->saved_regs to call the helper instead.

Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>

gdb/arm: Define MSP and PSP registers for M-Profile

This patch removes the hardcoded access to PSP in
arm_m_exception_cache() and relies on the definition with the XML
descriptions.

Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>

gdb/arm: Fix prologue analysis to support vpush

While working on adding support for Non-secure/Secure modes unwinding,
I noticed that the prologue analysis lacked support for vpush, which
is used for instance in the CMSE stub routine.

This patch updates thumb_analyze_prologue accordingly, adding support
for vpush of D-registers.

Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>

gdb/testsuite: fix FAIL in gdb.base/clear_non_user_bp.exp

Tom and Simon feedback that there is a test failing in this commit:

  commit a5c69b1e49bae4d0dcb20f324cebb310c63495c6
  Date:   Sun Apr 17 15:09:46 2022 +0800

    gdb: fix using clear command to delete non-user breakpoints(PR cli/7161)

Then, I reproduced the same fail with Ubuntu 20.04 as Simon said, and I
fixed the nit in this patch.  The root of the problem is not correctly
matching the presentation of internal breakpoints.

In addition, as Pedro pointed out, the original testcase is not portable
in some methods, so this patch fixes this issue and some other
improvements.

Tested on x86_64 ubuntu 20.04.4 and openSUSE Tumbleweed(VERSION_ID="20220425").

x86: VFPCLASSSH is Evex.LLIG

This also was mistakenly flagged as Evex.128.

Fix potential buffer overruns when creating DLLs.

PR 29006
* pe-dll.c (make_head): Use asprintf to allocate and populate a
buffer containing the temporary name.
(make_tail, make_one, make_singleton_name_thunk): Likewise.
(make_import_fixup_mark, make_import_fixup_entry): Likewise.
(make_runtime_pseudo_reloc): Likewise.
(pe_create_runtime_relocator_reference): Likewise.

Revert pr29072 lto test changes

Revert commit 65daf5bed6 testsuite changes in ld-plugin/.  -z isn't
supported for non-ELF targets, and isn't needed since we now prune the
exec stack warning (commit 333cd559ba).

PR 29072

gdb/testsuite: use with_cwd where possible

I learned about with_cwd today.  I spotted a few spots that could use
it, to make the code more robust.

Change-Id: Ia23664cb827f25e79d31948e0c006a8dc61c33e1

Automatic date update in version.in

GDB PowerPC record test cases for ISA 2.06 and ISA 3.1

This patch adds PowerPC specific tests to verify recording of various
instructions.  The first test case checks the ISA 2.06 lxvd2x instruction.
The second test case tests several of the ISA 3.01 instructions.  Specifically,
it checks the word and prefixed instructions and some of the Matrix
Multiply Assist (MMA) instructions.

The patch has been run on both Power 10 and Power 9 to verify the ISA
2.06 test case runs on both platforms without errors.  The ISA 3.1 test
runs without errors on Power 10 and is skipped as expected on Power 9.

Add recording support for the ISA 3.1 PowerPC instructions.

This patch adds support for the PowerPC ISA 3.1 instructions to the PowerPC
gdb instruction recording routines.  Case statement entries are added to a
number of the existing routines for recording the 32-bit word instructions.
A few new functions were added to handle the new word instructions.  The 64-bit
prefix instructions are all handled by a set of new routines.  The function
ppc_process_prefix_instruction() is the primary function to handle the
prefixed instructions. It calls additional functions to handle specific
sets of prefixed instructions.  These new functions are:
  ppc_process_record_prefix_vsx_d_form(),
  ppc_process_record_prefix_store_vsx_ds_form(),
  ppc_process_record_prefix_op34(),
  ppc_process_record_prefix_op33(),
  ppc_process_record_prefix_op32(),
  ppc_process_record_prefix_store(),
  ppc_process_record_prefix_op59_XX3(),
  ppc_process_record_prefix_op42().

Handle encoding failures in Windows thread names

Internally at AdaCore, we noticed that the new Windows thread name
code could fail.  First, it might return a zero-length string, but in
gdb conventions it should return nullptr instead.  Second, an encoding
failure could wind up showing replacement characters to the user; this
is confusing and not useful; it's better to recognize such errors and
simply discard the name.  This patch makes both of these changes.

i386: Pass -z noexecstack to linker tests

PR ld/29072
* testsuite/ld-i386/i386.exp: Pass -z noexecstack to gotpc1
and property-6.

bsd-kvm: Fix build after recent changes to path handling functions.

Convert bsd_kvm_corefile and the local filename in bsd_kvm_open to
std::string rather than simple char * pointers freed by xfree.

gdb: make some random Python files Python 3-compatible

I noticed that these files failed to format with Black, because they use
print without parenthesis (which isn't Python 3 compatible).

I don't know if these files are still relevant, but the change is
trivial, so here it is.

Change-Id: I116445c2b463486016f824d32effffc915b60766

PowerPC: Update expected floating point output for gdb.arch/altivec-regs.exp and gdb.arch/vsx-regs.exp

The format for printing the floating point values was changed by commit:

   commit 56262a931b7ca8ee3ec9104bc7e9e0b40cf3d64e
   Author: Tom Tromey <tromey@adacore.com>
   Date:   Thu Feb 17 13:43:59 2022 -0700

       Change how "print/x" displays floating-point value

       Currently, "print/x" will display a floating-point value by first
       casting it to an integer type.  This yields weird results like:

           (gdb) print/x 1.5
           $1 = 0x1
        ...
        Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16242

The above change results in 417 regression test failures since the expected
Power vector register output no longer match.

This patch updates the expected Altivec floating point register prints to
the hexadecimal format for both big endian and little endian systems.  The
patch also fixes a formatting isue with the decimal_vector expected value
assign statements.

The expected VSX vector_register1, vector_register1_vr, vector_register2,
vector_register2_vr variables are updated to include the new float128 entry.
Additionally, the comment in the vsx expect file about the initialization
of the vs registers is updated.

The patch has been tested on Power 10, Power 8 LE and Power 8 BE.

gdbsupport/pathstuff.h: #include <array> explicitly for std::array<>

This fixes build breakage using clang with libc++ on FreeBSD where
std::array<> is not yet declared when used by the path_join variadic
function template.

Automatic date update in version.in

Do not put linkage names into .gdb_index

This changes the .gdb_index writer to skip linkage names.  This was
always done historically (though somewhat implicitly).

Emit a note warning the user that creating an executable stack because of a missing .note.GNU-stack section is deprecated.

PR 29072
bfd * elflink.c (bfd_elf_size_dynamic_sections): Display a note to the
user that the current ehaviour of creating an executable stack
because of a missing .note.GNU-stack section is deprecated and
will be changed in a future release.

binutils* testsuite/lib/binutils-common.exp (prune_warnings_extra): Filter
out notes about the executable stacjk behaviour beign deprecated.

ld * testsuite/ld-elf/pr29072.b.warn: Update to include the note
about the linker's behaviour being depreccated.

gdb/fortran: Support for assumed rank zero

If a variable is passed to function in FORTRAN as an argument the
variable is treated as an array with rank zero.  GDB currently does
not support the case for assumed rank 0.  This patch provides support
for assumed rank 0 and updates the testcase as well.

Without patch:
Breakpoint 1, arank::sub1 (a=<error reading variable:
  failed to resolve dynamic array rank>) at assumedrank.f90:11
11       PRINT *, RANK(a)
(gdb) p a
failed to resolve dynamic array rank
(gdb) p rank(a)
failed to resolve dynamic array rank

With patch:
Breakpoint 1, arank::sub1 (a=0) at assumedrank.f90:11
11       PRINT *, RANK(a)
(gdb) p a
$1 = 0
(gdb) p rank(a)
$2 = 0

gdb/infrun: assert !step_over_info_valid_p in restart_threads

While working in gdb/infrun.c:restart_threads, I was wondering what are
the preconditions to call the function.  It seems to me that
!step_over_info_valid_p should be a precondition (i.e. if we are doing
an inline step over breakpoint, we do not want to resume non stepping
threads as one of them might miss the breakpoint which is temporally
disabled).

To convince myself that this is true, I have added an assertion to
enforce this, and got one regression in the testsuite:

    FAIL: gdb.base/step-over-syscall.exp: vfork: displaced=off: single step over vfork (GDB internal error)

This call to restart_threads originates from handle_vfork_done which
does not check if a step over is active when restarting other threads:

    if (target_is_non_stop_p ())
      {
        scoped_restore_current_thread restore_thread;

        insert_breakpoints ();
        restart_threads (event_thread, event_thread->inf);
        start_step_over ();
      }

In this patch, I propose to:
- Call start_step_over before restart_threads.  If a step over is already
  in progress (as it is the case in the failing testcase),
  start_step_over return immediately, and there is no point in restarting
  all threads just to stop them right away for a step over breakpoint.
- Only call restart_threads if no step over is in progress at this
  point.

In this patch, I also propose to keep the assertion in restart_threads
to help enforce this precondition, and state it explicitly.

I have also checked all other places which call restart_threads, and
they all seem to check that there is no step over currently active
before doing the call.

As for infrun-related things, I am never completely sure I did not miss
something.  So as usual, all feedback and thoughts are very welcome.

Tested on x86_64-linux-gnu.

Change-Id: If5f5f98ec4cf9aaeaabb5e3aa88ae6ffd70d4f37

Automatic date update in version.in

gdb: move setbuf calls out of gdb_readline_no_editing_callback

After this commit:

  commit d08cbc5d3203118da5583296e49273cf82378042
  Date:   Wed Dec 22 12:57:44 2021 +0000

      gdb: unbuffer all input streams when not using readline

Issues were reported with some MS-Windows hosts, see the thread
starting here:

  https://sourceware.org/pipermail/gdb-patches/2022-March/187004.html

Filed in bugzilla as: PR mi/29002

The problem seems to be that calling setbuf on terminal file handles
is not always acceptable, see this mail for more details:

  https://sourceware.org/pipermail/gdb-patches/2022-April/187310.html

This commit does two things, first moving the setbuf calls out of
gdb_readline_no_editing_callback so that we don't end up calling
setbuf so often.

Then, for MS-Windows hosts, we don't call setbuf for terminals, this
appears to resolve the issues that have been reported.

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

Automatic date update in version.in

Automatic date update in version.in