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

gdb: handle_no_resumed: only update thread list of event target

When running:

    $ make check TESTS="gdb.multi/multi-re-run.exp" RUNTESTFLAGS="--target_board=native-gdbserver"

I get:

    target remote localhost:2347^M
    Remote debugging using localhost:2347^M
    Reading symbols from /lib64/ld-linux-x86-64.so.2...^M
    Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.31.so...^M
    0x00007ffff7fd0100 in _start () from /lib64/ld-linux-x86-64.so.2^M
    (gdb) continue^M
    Continuing.^M
    Cannot execute this command while the target is running.^M
    Use the "interrupt" command to stop the target^M
    and then try again.^M
    (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=1: runto: run to all_started

The test does:

 - Connect to a remote target with inferior 2, continue and stop on the
   all_started function
 - Connect to a separate remote target / GDBserver instance with inferior 1,
   continue and (expect to) stop on the all_started function

The failure seen above happens when trying to continue inferior 1.

What happens is:

 - GDB tells inferior 1's remote target to continue
 - We go into fetch_inferior_event, try to get an event at random from
   the targets
 - do_target_wait happens to pick inferior 2's target
 - That target return TARGET_WAITKIND_NO_RESUMED, which makes sense:
   inferior 2 is stopped, that target has no resumed thread
 - handle_no_resumed tries to update the thread list of all targets:

   for (auto *target : all_non_exited_process_targets ())
     {
       switch_to_target_no_thread (target);
       update_thread_list ();
     }

 - When trying to update the thread list of inferior 1's target, it hits
   the "Cannot execute this command while the target is running" error.
   This target is working in "remote all-stop" mode, and it is currently
   waiting for a stop reply, so it can't send packets to update the
   thread list at this time.

To handle the problem described in the comment in handle_no_resumed, I
don't think it is necessary to update the thread list of all targets,
but only the event target.  That comment describes a kind of race
condition where some target reports a breakpoint hit for a thread and
then its last remaining resumed thread exits, so sends a "no resumed"
event.  If we ended up resuming the thread that hit a breakpoint, we
want to ignore the "no resumed" and carry on.

But I don't really see why we need to update the thread list on the
other targets.  I can't really articulate this, it's more a gut feeling,
maybe I just fail to imagine the situation where this is needed.  But
here is the patch anyway, so we can discuss it.  The patch changes
handle_no_resumed to only update the thread list of the event target.
This fixes the test run shown above.

The way I originally tried to fix this was to make
remote_target::update_thread_list return early if the target is
currently awaiting a stop reply, since there's no way it can update the
thread list at that time.  But that felt more like papering over the
problem.  I then thought that we probably shouldn't be asking the target
to update the thread list unnecessarily.

Change-Id: Ide3df22b4f556478e155ad1c67ad4b4fe7c26a58

gdbserver/linux: free process_info_private and arch_process_info when failing to attach

Running

  $ ../gdbserver/gdbserver --once --attach :1234 539436

with ASan while /proc/sys/kernel/yama/ptrace_scope is set to 1 (prevents
attaching) shows that we fail to free some platform-specific objects
tied to the process_info (process_info_private and arch_process_info):

    Direct leak of 32 byte(s) in 1 object(s) allocated from:
        #0 0x7f6b558b3fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
        #1 0x562eaf15d04a in xcalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:100
        #2 0x562eaf251548 in xcnew<process_info_private> /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/poison.h:122
        #3 0x562eaf22810c in linux_process_target::add_linux_process_no_mem_file(int, int) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:426
        #4 0x562eaf22d33f in linux_process_target::attach(unsigned long) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:1132
        #5 0x562eaf1a7222 in attach_inferior /home/simark/src/binutils-gdb/gdbserver/server.cc:308
        #6 0x562eaf1c1016 in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3949
        #7 0x562eaf1c1d60 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:4084
        #8 0x7f6b552f630f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

    Indirect leak of 56 byte(s) in 1 object(s) allocated from:
        #0 0x7f6b558b3fb9 in __interceptor_calloc /usr/src/debug/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
        #1 0x562eaf15d04a in xcalloc /home/simark/src/binutils-gdb/gdbserver/../gdb/alloc.c:100
        #2 0x562eaf2a0d79 in xcnew<arch_process_info> /home/simark/src/binutils-gdb/gdbserver/../gdbsupport/poison.h:122
        #3 0x562eaf295e2c in x86_target::low_new_process() /home/simark/src/binutils-gdb/gdbserver/linux-x86-low.cc:723
        #4 0x562eaf22819b in linux_process_target::add_linux_process_no_mem_file(int, int) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:428
        #5 0x562eaf22d33f in linux_process_target::attach(unsigned long) /home/simark/src/binutils-gdb/gdbserver/linux-low.cc:1132
        #6 0x562eaf1a7222 in attach_inferior /home/simark/src/binutils-gdb/gdbserver/server.cc:308
        #7 0x562eaf1c1016 in captured_main /home/simark/src/binutils-gdb/gdbserver/server.cc:3949
        #8 0x562eaf1c1d60 in main /home/simark/src/binutils-gdb/gdbserver/server.cc:4084
        #9 0x7f6b552f630f in __libc_start_call_main (/usr/lib/libc.so.6+0x2d30f)

Those objects are deleted by linux_process_target::mourn, but that is
not called if we fail to attach, we only call remove_process.  I
initially fixed this by making linux_process_target::attach call
linux_process_target::mourn on failure (before calling error).  But this
isn't done anywhere else (including in GDB) so it would just be
confusing to do things differently here.

Instead, add a linux_process_target::remove_linux_process helper method
(which calls remove_process), and call that instead of remove_process in
the Linux target.  Move the free-ing of the extra data from the mourn
method to that new method.

Change-Id: I277059a69d5f08087a7f3ef0b8f1792a1fcf7a85

gdb: handle bracketed-paste-mode and EOF correctly

This commit replaces an earlier commit that worked around the issues
reported in bug PR gdb/28833.

The previous commit just implemented a work around in order to avoid
the worst results of the bug, but was not a complete solution.  The
full solution was considered too risky to merge close to branching GDB
12.  This improved fix has been applied after GDB 12 branched.  See
this thread for more details:

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

This commit replaces this earlier commit:

  commit 74a159a420d4b466cc81061c16d444568e36740c
  Date:   Fri Mar 11 14:44:03 2022 +0000

      gdb: work around prompt corruption caused by bracketed-paste-mode

Please read that commit for a full description of the bug, and why is
occurs.

In this commit I extend GDB to use readline's rl_deprep_term_function
hook to call a new function gdb_rl_deprep_term_function.  From this
new function we can now print the 'quit' message, this replaces the
old printing of 'quit' in command_line_handler.  Of course, we only
print 'quit' in gdb_rl_deprep_term_function when we are handling EOF,
but thanks to the previous commit (to readline) we now know when this
is.

There are two aspects of this commit that are worth further
discussion, the first is in the new gdb_rl_deprep_term_function
function.  In here I have used a scoped_restore_tmpl to disable the
readline global variable rl_eof_found.

The reason for this is that, in rl_deprep_terminal, readline will
print an extra '\n' character before printing the escape sequence to
leave bracketed paste mode.  You might then think that in the
gdb_rl_deprep_term_function function, we could simply print "quit" and
rely on rl_deprep_terminal to print the trailing '\n'.  However,
rl_deprep_terminal only prints the '\n' when bracketed paste mode is
on.  If the user has turned this feature off, no '\n' is printed.
This means that in gdb_rl_deprep_term_function we need to print
"quit" when bracketed paste mode is on, and "quit\n" when bracketed
paste mode is off.

We could absolutely do that, no problem, but given we know how
rl_deprep_terminal is implemented, it's easier (I think) to just
temporarily clear rl_eof_found, this prevents the '\n' being printed
from rl_deprep_terminal, and so in gdb_rl_deprep_term_function, we can
now always print "quit\n" and this works for all cases.

The second issue that should be discussed is backwards compatibility
with older versions of readline.  GDB can be built against the system
readline, which might be older than the version contained within GDB's
tree.  If this is the case then the system readline might not contain
the fixes needed to support correctly printing the 'quit' string.

To handle this situation I have retained the existing code in
command_line_handler for printing 'quit', however, this code is only
used now if the version of readline we are using doesn't not include
the required fixes.  And so, if a user is using an older version of
readline, and they have bracketed paste mode on, then they will see
the 'quit' sting printed on the line below the prompt, like this:

  (gdb)
  quit

I think this is the best we can do when someone builds GDB against an
older version of readline.

Using a newer version of readline, or the patched version of readline
that is in-tree, will now give a result like this in all cases:

  (gdb) quit

Which is what we want.

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

readline: back-port changes needed to properly detect EOF

This commit is a partial back-port of this upstream readline commit:

  commit 002d31aa5f5929eb32d0e0e2e8b8d35d99e59961
  Author: Chet Ramey <chet.ramey@case.edu>
  Date:   Thu Mar 3 11:11:47 2022 -0500

      add rl_eof_found to public API; fix pointer aliasing problems  \
            with history-search-backward; fix a display problem with \
            runs of invisible characters at the end of a physical    \
            screen line

I have only pulled in the parts of this commit that relate to the new
rl_eof_found global, and the RL_STATE_EOF state flag.  These changes
are needed in order to fix PR cli/28833, and are discussed in this
thread to the bug-readline mailing list:

  https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00021.html

The above commit is not yet in any official readline release, but my
hope is that now it has been merged into the readline tree it should
be safe enough to back port this fix to GDB's tree.

At some point in the future we will inevitably want to roll forward
the version of readline that we maintain in the binutils-gdb
repository.  When that day comes the changes in this commit can be
replaced with the latest upstream readline code, as I have not changed
the meaning of this code at all from what is in upstream readline.

This commit alone does not fix the PR cli/28833 issue, for that see
the next commit, which changes GDB itself.

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

gdb: improved EOF handling when using readline 7

In this commit:

  commit a6b413d24ccc5d76179bab866834e11fd6fec294
  Date:   Fri Mar 11 14:44:03 2022 +0000

      gdb: work around prompt corruption caused by bracketed-paste-mode

a change was made to GDB to work around bug PR gdb/28833.  The
consequence of this work around is that, when bracketed paste mode is
enabled in readline, and GDB is quit by sending EOF, then the output
will look like this:

  (gdb)
  quit

The ideal output, which is what we get when bracketed paste mode is
off, is this:

  (gdb) quit

The reason we need to make this change is explained in the original
commit referenced above.  What isn't mentioned in the above commit, is
that the change that motivated this work around was only added in
readline 8, older versions of readline don't require the change.

In later commits in this series I will add a fix to GDB's in-tree copy
of readline (this fix is back-ported from upstream readline), and then
I will change GDB so that, when using the (patched) in-tree readline,
we can have the ideal output in all cases.

However, GDB can be built against the system readline.  When this is
done, and the system readline is version 8, then we will still have to
use the work around (two line) style output.

But, if GDB is built against the system readline, and the system
readline is an older version 7 readline, then there's no reason why we
can't have the ideal output, after all, readline 7 doesn't include the
change that we need to work around.

This commit changes GDB so that, when using readline 7 we get the
ideal output in all cases.  This change is trivial (a simple check
against the readline version number) so I think this should be fine to
include.

For testing this commit, you need to configure GDB including the
'--with-system-readline' flag, and build GDB on a system that uses
readline 7, for example 'Ubuntu 18.04'.  Then run the test
'gdb.base/eof-exit.exp', you should expect everything to PASS.

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

gdb: prune inferiors at end of fetch_inferior_event, fix intermittent failure of gdb.threads/fork-plus-threads.exp

This test sometimes fail like this:

    info threads^M
      Id   Target Id         Frame ^M
      11.12 process 2270719   Couldn't get registers: No such process.^M
    (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: no threads left
    [Inferior 11 (process 2270719) exited normally]^M
    info inferiors^M
      Num  Description       Connection           Executable        ^M
    * 1    <null>                                 /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads ^M
      11   <null>                                 /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads ^M
    (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left (the program exited)

I can get it to fail quite reliably by pinning it to a core:

  $ taskset -c 5 make check TESTS="gdb.threads/fork-plus-threads.exp"

The previous attempt at fixing this was:

  https://sourceware.org/pipermail/gdb-patches/2021-October/182846.html

What we see is part due to a possible unfortunate ordering of events
given by the kernel, and what could be considered a bug in GDB.

The test program makes a number of forks, waits them all, then exits.
Most of the time, GDB will get and process the exit event for inferior 1
after the exit events of all the children.  But this is not guaranteed.
After the last child exits and is waited by the parent, the parent can
exit quickly, such that GDB collects from the kernel the exit events for
the parent and that child at the same time.  It then chooses one event
at random, which can be the event for the parent.  This will result in
the parent appearing to exit before its child.  There's not much we can
do about it, so I think we have to adjust the test to cope.

After expect has seen the "exited normally" notification for inferior 1,
it immediately does an "info thread" that it expects to come back empty.
But at this point, GDB might not have processed inferior 11's (the last
child) exit event, so it will look like there is still a thread.  Of
course that thread is dead, we just don't know it yet.  But that makes
the "no thread" test fail.  If the test waited just a bit more for the
"exited normally" notification for inferior 11, then the list of threads
would be empty.

So, first change, make the test collect all the "exited normally"
notifications for all inferiors before proceeding, that should ensure we
see an empty thread list.  That would fix the first FAIL above.

However, we would still have the second FAIL, as we expect inferior 11
to not be there, it should have been deleted automatically.  Inferior 11
is normally deleted when prune_inferiors is called.  That is called by
normal_stop, which is only called by fetch_inferior_event only if the
event thread completed an execution command FSM (thread_fsm).  But the
FSM for the continue command completed when inferior 1 exited.  At that
point inferior 11 was not prunable, as it still had a thread.  When
inferior 11 exits, prune_inferiors is not called.

I think that can be considered a GDB bug.  From the user point of view,
there's no reason why in one case inferior 11 would be deleted and not
in the other case.

This patch makes the somewhat naive change to call prune_inferiors in
fetch_inferior_event, so that it is called in this case.  It is placed
at this particular point in the function so that it is called after the
user inferior / thread selection is restored.  If it was called before
that, inferior 11 wouldn't be pruned, because it would still be the
current inferior.

Change-Id: I48a15d118f30b1c72c528a9f805ed4974170484a
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26272

Un-break the coff-pe-read.c build

This fixes a build breakage in my recent coff-pe-read.c change.

I'm sorry about this.  I don't understand how it happened, because I
definitely built and tested the series on Windows, and I didn't change
it before pushing.  Something must have gone wrong on the Windows
build, but I don't know what.  I'll investigate and and re-test to be
sure.

More const use and alloca avoidance in coff-pe-read.c

This changes another function in coff-pe-read.c to use 'const' more,
and to avoid the use of alloca by instead using std::string.

Use std::string in coff-pe-read.c

coff-pe-read.c uses xsnprintf and alloca, but using std::string is
better, and just as easy.  In general I think alloca is something to
be avoided, and unbounded uses especially so.

Remove a const-removing cast from coff-pe-read.c

coff-pe-read.c casts away const at one spot, but this is easily
replaced by calling bfd_get_filename directly in a couple of debugging
prints.

Simplify BFD section iteration in coff-pe-read.c

coff-pe-read.c iterates over BFD sections using bfd_map_over_sections,
but it's much simpler to use a for-each loop.  This allows for the
removal of helper functions and types.

Fix method naming bug in new DWARF indexer

Pedro pointed out that gdb-add-index is much slower with the new DWARF
indexer.  He also noticed that, in some cases, the generated
.gdb_index would have the wrong fully-qualified name for a method.

I tracked this down to a bug in the indexer.  If a type could have
methods but was marked as a declaration, the indexer was ignoring it.
However, this meant that the internal map to find the qualified name
was not updated for this container.

RISC-V: Add missing DECLARE_INSNs for Zicbo{m,p,z}

The recently added support for the Zicbo{m,p,z} extensions did not
include DECLARE_INSN() declarations for the instructions.
These declarations are needed by GDB's instruction detection code.
This patch adds them.

Signed-off-by: Christoph Muellner <cmuellner@gcc.gnu.org>

Automatic date update in version.in

Fix for gdb.base/solib-search.exp test.

The variable right_lib_flags is not being set correctly to define RIGHT.
The value RIGHT is needed to force the address of the library functions
lib1_func3 and lib2_func4 to occur at different address in the wrong and
right libraries.

With RIGHT defined correctly, functions lib1_func3 and lib2_func4 occur
at different addresses the test runs correctly on Powerpc.

The test needs the lib2 addresses to be different in the right and
wrong cases.  That is the point of introducing function lib2_spacer
with the ifdef RIGHT compiler directive.

On Intel, the ARRAY_SIZE of 1 versus 8192 is sufficient to get the
dynamic linker to move the addresses of the library.  You can also get
the same effect on PowerPC but you must use a value much larger than
8192.

The key thing is that the test was not properly setting RIGHT to
defined to get the lib2_spacer function on Intel and Powerpc.

Without the patch, we have the Intel backtrace for the bad libraries:

backtrace
#0  break_here () at /home/ ... /gdb/testsuite/gdb.base/solib-search.c:30
#1  0x00007ffff7fae156 in ?? ()
#2  0x00007fffffffc150 in ?? ()
#3  0x00007ffff7fbb156 in ?? ()
#4  0x00007fffffffc160 in ?? ()
#5  0x00007ffff7fae146 in ?? ()
#6  0x00007fffffffc170 in ?? ()
#7  0x00007ffff7fbb146 in ?? ()
#8  0x00007fffffffc180 in ?? ()
#9  0x0000555555555156 in main () at /home/ ... /binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:23
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) PASS: gdb.base/solib-search.exp: backtrace (with wrong libs) (data collection)

The backtrace on Intel with the good libraries is:

backtrace
#0  break_here () at /.../binutils-gdb/gdb/testsuite/gdb.base/solib-search.c:30
#1  0x00007ffff7fae156 in lib2_func4 () at /.../binutils-gdb/gdb/testsuite/gdb.base/solib-search-lib2.c:49
#2  0x00007ffff7fbb156 in lib1_func3 () at /.../gdb.base/solib-search-lib1.c:49
#3  0x00007ffff7fae146 in lib2_func2 () at /.../testsuite/gdb.base/solib-search-lib2.c:30
#4  0x00007ffff7fbb146 in lib1_func1 () at /.../gdb.base/solib-search-lib1.c:30
#5  0x0000555555555156 in main () at /...solib-search.c:23
(gdb) PASS: gdb.base/solib-search.exp: backtrace (with right libs) (data collection)
PASS: gdb.base/solib-search.exp: backtrace (with right libs)

In one case the backtrace is correct and the other it
is wrong on Intel.  This is due to the fact that the ARRAY_SIZE caused
the dynamic linker to move the library function addresses around.  I
believe it has to do with the default size of the data and code
sections used by the dynamic linker.

So without the patch the backtrace on PowerPC looks like:

 backtrace
#0  break_here () at /.../solib-search.c:30
#1  0x00007ffff7f007f4 in lib2_func4 () at /.../solib-search-lib2.c:49
#2  0x00007ffff7f307f4 in lib1_func3 () at /.../solib-search-lib1.c:49
#3  0x00007ffff7f007ac in lib2_func2 () at /.../solib-search-lib2.c:30
#4  0x00007ffff7f307ac in lib1_func1 () at /.../solib-search-lib1.c:30
#5  0x000000001000074c in main () at /.../solib-search.c:23

for both the good and bad libraries.

The patch fixes defining RIGHT in solib-search-lib1.c and solib-search-
lib2.c.  Note, without the patch the lib1_spacer and lib2_spacer
functions do not show up in the object dump of the Intel or Powerpc
libraries as it should.  The patch fixes that by making sure RIGHT gets
defined.

Now with the patch the backtrace for the bad library on PowerPC looks
like:

backtrace
#0  break_here () at /.../solib-search.c:30
#1  0x00007ffff7f0083c in __glink_PLTresolve () from /.../solib-search-lib2.so
Backtrace stopped: frame did not save the PC

And the backtrace for the good libraries on PowerPC looks like:

backtrace
#0  break_here () at /.../solib-search.c:30
#1  0x00007ffff7f0083c in lib2_func4 () at /.../solib-search-lib2.c:49
#2  0x00007ffff7f3083c in lib1_func3 () at /.../solib-search-lib1.c:49
#3  0x00007ffff7f007cc in lib2_func2 () at /.../solib-search-lib2.c:30
#4  0x00007ffff7f307cc in lib1_func1 () at /.../solib-search-lib1.c:30
#5  0x000000001000074c in main () at /.../solib-search.c:23
(gdb) PASS: gdb.base/solib-search.exp: backtrace (with right libs) (data collection)
PASS: gdb.base/solib-search.exp: backtrace (with right libs)

The issue then is on Power where the ARRAY_SIZE of 1 versus 8192 is not
sufficient to cause the dymanic linker to allocate the libraries at
different addresses.  I don't claim to understand the specifics of how
the dynamic linker works and what the default size is for the data and
code sections are.  My guess is by default PowerPC allocates a larger
data size by default, which is large enough to hold array[8192].  The
default size of the data section allocated by the dynamic linker on
Intel is not large enough to hold array[8192] thus causing the code
section on Intel to have to move when the large array is defined.

Note on PowerPC, if you make ARRAY_SIZE big enough, then you will cause
the library addresses to occur at different addresses as the larger
data section forces the code section to a different address.  That was
actually my original fix for the program until I spoke with Doug Evans
who originally wrote the test.  Doug noticed that RIGHT was not getting
defined as he originally intended in the test.

With the patch to fix the definition of RIGHT, PowerPC has a bad and a
good backtrace because the address of lib1_func3 and lib2_func4 both
move because lib1_spacer and lib2_spacer are now defined
before lib1_func3 and lib2_func4.

Without the patch, the lib1_spacer and lib2_spacer function doesn't show
up in the binary for the correct or incorrect library on Intel or PowerPC.
With the patch, RIGHT gets defined as originally intended for the test on
both architectures and lib1_spacer and lib2_spacer function show up in the
binaries on both architectures changing the other function addresses as
intended thus causing the test work as intended on PowerPC.