Decode "dynamic" interface types in Ada

In Ada, if a class implements an interface and has a dynamic
superclass, then the "offset to top" -- the offset that says how to
turn a pointer to the interface into a pointer to the whole object --
is stored in the object itself.  This patch changes GDB to understand
this.

Because this only touches Ada code, and because Joel already reviewed
it internally, I am checking it in.

Fix for MUL instruction on the v850

* sim/v850/simops.c (Multiply64): Properly test if we need to
negate either of the operands.

* sim/testsuite/v850/mul.cgs: New test.

Automatic date update in version.in

Remove two unused hooks

I noticed that a couple of deprecated hooks aren't ever called, so
they can't really be used by Insight.  This patch removes them
entirely.  I checked the Insight sources, and these aren't mentioned
there, either.

Remove unnecessary calls to wrap_here and gdb_flush

Various spots in gdb currently know about the wrap buffer, and so are
careful to call wrap_here to be certain that all output has been
flushed.

Now that the pager is just an ordinary stream, this isn't needed, and
a simple call to gdb_flush is enough.

Similarly, there are places where gdb prints to gdb_stderr, but first
flushes gdb_stdout.  stderr_file already flushes gdb_stdout, so these
aren't needed.

Minor comment updates in utils.h

This patch updates some comments in utils.h to more closely reflect
the new reality.

Remove vfprintf_styled

Nothing calls vfprintf_styled any more, so remove it.

Remove ui_out_flag::unfiltered_output

There is no longer any need for ui_out_flag::unfiltered_output --
nothing ever sets this flag.  This used to be needed to make the
_unfiltered output work, but now only printf_unfiltered can be used,
and it uses the puts_unfiltered method.  This patch removes the flag
and the dead code.

Rename fprintf_symbol_filtered

fprintf_symbol_filtered is misnamed, because whether filtering happens
is now up to the stream.  This renames it to fprintf_symbol, which
isn't a great name (the first "f" doesn't mean much and the second one
is truly meaningless here), but "print_symbol" was already taken.

Rename puts_filtered_tabular

puts_filtered_tabular is now misnamed, because whether filtering
happens is now up to the stream.  So, rename it.  (This function is
pretty weird, and should probably be rewritten to avoid using the
chars_printed global, and moved into objc-lang.c.  However, I haven't
done so.)

Rename print_spaces_filtered

print_spaces_filtered is now misnamed, because whether filtering
happens is up to the stream.  So, rename it.

Unify gdb printf functions

Now that filtered and unfiltered output can be treated identically, we
can unify the printf family of functions.  This is done under the name
"gdb_printf".  Most of this patch was written by script.

Unify gdb putc functions

Now that filtered and unfiltered output can be treated identically, we
can unify the putc family of functions.  This is done under the name
"gdb_putc".  Most of this patch was written by script.

Unify gdb puts functions

Now that filtered and unfiltered output can be treated identically, we
can unify the puts family of functions.  This is done under the name
"gdb_puts".  Most of this patch was written by script.

Unify vprintf functions

Now that filtered and unfiltered output can be treated identically, we
can unify the vprintf family of functions: vprintf_filtered,
vprintf_unfiltered, vfprintf_filtered and vfprintf_unfiltered.  (For
the gdb_stdout variants, recall that only printf_unfiltered gets truly
unfiltered output at this point.)  This removes one such function and
renames the remaining two to "gdb_vprintf".  All callers are updated.
Much of this patch was written by script.

Remove fputs_styled_unfiltered

fputs_styled_unfiltered is only called from cli_ui_out, so remove it.
This area will be further simplified in future patches.

Change the pager to a ui_file

This rewrites the output pager as a ui_file implementation.

A new header is introduced to declare the pager class.  The
implementation remains in utils.c for the time being, because there
are some static globals there that must be used by this code.  (This
could be cleaned up at some future date.)

I went through all the text output in gdb to ensure that this change
should be ok.  There are a few cases:

* Any existing call to printf_unfiltered is required to be avoid the
  pager.  This is ensured directly in the implementation.

* All remaining calls to the f*_unfiltered functions -- the ones that
  take an explicit ui_file -- either send to an unfiltered stream
  (e.g., gdb_stderr), which is obviously ok; or conditionally send to
  gdb_stdout

  I investigated all such calls by searching for:

    grep -e '\bf[a-z0-9_]*_unfiltered' *.[chyl] */*.[ch] | grep -v gdb_stdlog | grep -v gdb_stderr

  This yields a number of candidates to check.

  * The breakpoint _print_recreate family, and
    save_trace_state_variables.  These are used for "save" commands
    and so are fine.

  * Things printing to a temporary stream.  Obviously ok.

  * Disassembly selftests.

  * print_gdb_help - this is non-obvious, but ok because paging isn't
    yet enabled at this point during startup.

  * serial.c - doens't use gdb_stdout

  * The code in compile/.  This is all printing to a file.

  * DWARF DIE dumping - doesn't reference gdb_stdout.

* Calls to the _filtered form -- these are all clearly ok, because if
  they are using gdb_stdout, then filtering will still apply; and if
  not, then filtering never applied and still will not.

Therefore, at this point, there is no longer any distinction between
all the other _filtered and _unfiltered calls, and they can be
unified.

In this patch, take special note of the vfprintf_maybe_filtered and
ui_file::vprintf change.  This is one instance of the above idea,
erasing the distinction between filtered and unfiltered -- in this
part of the change, the "unfiltered_output" flag is never passe to
cli_ui_out.  Subsequent patches will go much further in this
direction.

Also note the can_emit_style_escape changes in ui-file.c.  Checking
against gdb_stdout or gdb_stderr was always a bit of a hack; and now
it is no longer needed, because this is decision can be more fully
delegated to the particular ui_file implementation.

ui_file::can_page is removed, because this patch removed the only call
to it.

I think this is the main part of fixing PR cli/7234.

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

Remove vfprintf_styled_no_gdbfmt

This removes vfprintf_styled_no_gdbfmt, inlining it at the sole point
of call.

Add style-escape methods to ui_file

This adds emit_style_escape and reset_style methods to ui_file.  These
aren't used yet, but they will be once the pager is converted to be a
ui_file subclass.

Add puts_unfiltered method to ui_file

When the pager is rewritten as a ui_file, gdb will still need a way to
bypass the filtering.  After examining a few approaches, I chose this
patch, which adds a puts_unfiltered method to ui_file.  For most
implementations of ui_file, this will just delegate to puts.  This
patch also switches printf_unfiltered to use the new method.

Only have one API for unfiltered output

At the end of this series, the use of unfiltered output will be very
restricted -- only places that definitely need it will use it.  To
this end, I thought it would be good to reduce the number of
_unfiltered APIs that are exposed.  This patch changes gdb so that
only printf_unfiltered exists.  (After this patch, the f* variants
still exist as well, but those will be removed later.)

Remove some uses of printf_unfiltered

A number of spots call printf_unfiltered only because they are in code
that should not be interrupted by the pager.  However, I believe these
cases are all handled by infrun's blanket ban on paging, and so can be
converted to the default (_filtered) API.

After this patch, I think all the remaining _unfiltered calls are ones
that really ought to be.  A few -- namely in complete_command -- could
be replaced by a scoped assignment to pagination_enabled, but for the
remainder, the code seems simple enough like this.

Use unfiltered output in annotate.c

It seems to me that annotations should not be filtered.  While it
might be weird for an annotation-based UI to use the pager, it's not,
I think, out of the question.  This patch makes this change.

gdb/remote: use current_inferior in read_ptid if multi-process not supported

When parsing the ptid out of a reply package, if the multi-process
extensions are not supported, use current_inferior's pid as the pid of
the reported thread, instead of inferior_ptid.  This is needed because
the inferior_ptid may be null_ptid although a legit context exists,
due to a prior context switch via switch_to_inferior_no_thread.

Below is a scenario that illustrates what could go wrong.  First,
setup a multi-target scenario.  This is needed, because in a
multi-target setting, the inferior_ptid is cleared out before waiting
on targets.  The second inferior below sits on top of a remote target.
Multi-process packets are disabled.

  $ # First, spawn a process with PID 26253 to attach to later.
  $ gdb-up a.out
  Reading symbols from a.out...
  (gdb) maint set target-non-stop on
  (gdb) set remote multiprocess-feature-packet off
  (gdb) start
  ...
  (gdb) add-inferior -no-connection
  [New inferior 2]
  Added inferior 2
  (gdb) inferior 2
  [Switching to inferior 2 [<null>] (<noexec>)]
  (gdb) target extended-remote | gdbserver --multi -
  Remote debugging using | gdbserver --multi -
  Remote debugging using stdio
  (gdb) attach 26253
  Attaching to Remote target
  Attached; pid = 26253
  [New Thread 26253]
  [New inferior 3]
  Reading /tmp/a.out from remote target...
  ...
  [New Thread 26253]
  ...
  Reading /usr/local/lib/debug/....debug from remote target...
  >>> GDB seems to hang here.

After attaching to a process and reading some library files, GDB
seems to hang.  One interesting thing to note is that

  [New Thread 26253]

appears twice.  We also see

  [New inferior 3]

Running the same scenario with "debug infrun on" reveals more details.

  ...
  (gdb) attach 26253
  [infrun] scoped_disable_commit_resumed: reason=attaching
  Attaching to Remote target
  Attached; pid = 26253
  [New Thread 26253]
  [infrun] infrun_async: enable=1
  [infrun] attach_command: immediately after attach:
  [infrun] attach_command:   thread 26253.26253.0, executing = 1, resumed = 0, state = RUNNING
  [infrun] clear_proceed_status_thread: 26253.26253.0
  [infrun] reset: reason=attaching
  [infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads
  [infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target extended-remote
  [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 [Thread 0], status) =
    [infrun] print_target_wait_results:   26253.26253.0 [Thread 26253],
    [infrun] print_target_wait_results:   status->kind = STOPPED, sig = GDB_SIGNAL_0
    [infrun] handle_inferior_event: status->kind = STOPPED, sig = GDB_SIGNAL_0
    [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] context_switch: Switching context from 0.0.0 to 26253.26253.0
    [infrun] handle_signal_stop: stop_pc=0x7f849d8cf151
    [infrun] stop_waiting: stop_waiting
    [infrun] stop_all_threads: starting
    [infrun] stop_all_threads: pass=0, iterations=0
  [New inferior 3]
  Reading /tmp/a.out from remote target...
  warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
  Reading /tmp/a.out from remote target...
  Reading symbols from target:/tmp/a.out...
  [New Thread 26253]
    [infrun] stop_all_threads:   4723.4723.0 not executing
    [infrun] stop_all_threads:   26253.26253.0 not executing
    [infrun] stop_all_threads:   42000.26253.0 executing, need stop
    [infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) =
    [infrun] print_target_wait_results:   -1.0.0 [Thread 0],
    [infrun] print_target_wait_results:   status->kind = IGNORE
    [infrun] print_target_wait_results: target_wait (-1.0.0 [Thread 0], status) =
    [infrun] print_target_wait_results:   -1.0.0 [Thread 0],
    [infrun] print_target_wait_results:   status->kind = IGNORE

GDB tried to stop Thread 42000.26253.0, which does not exist, and we
are waiting for a stop event that will never happen.  The PID in
'42000.26253.0', namely 42000, is the PID of magic_null_ptid.
It comes from gdb/remote.c:read_ptid:

  /* Since the stub is not sending a process id, then default to
     what's in inferior_ptid, unless it's null at this point.  If so,
     then since there's no way to know the pid of the reported
     threads, use the magic number.  */
  if (inferior_ptid == null_ptid)
    pid = magic_null_ptid.pid ();
  else
    pid = inferior_ptid.pid ();

  if (obuf)
    *obuf = pp;
  return ptid_t (pid, tid);

Because multi-process was turned off, GDB did not parse an explicitly
specified PID.  Furthermore, inferior_ptid == null_ptid, and
eventually GDB picked the PID from magic_null_ptid.

If target-non-stop is not turned on at the beginning, the same bug
reveals itself as a duplicated thread as shown below.

  # Same setup as above, without 'maint set target-non-stop on'.
  ...
  (gdb) attach 26253
  Attaching to Remote target
  Attached; pid = 26253
  [New inferior 3]
  ...
  [New Thread 26253]
  ...
  (gdb) info threads
    Id   Target Id             Frame
    1.1  process 13517 "a.out" main () at test.c:3
  * 2.1  Thread 26253 "a.out"  0x00007f12750c5151 in read () from target:/lib/x86_64-linux-gnu/libc.so.6
    3.1  Thread 26253 "a.out"  Remote 'g' packet reply is too long (expected 560 bytes, got 2496 bytes): 00feffffffffffff000a3a75127f000051510c75127f0000000400000000000060d24ef6af5500000000000000000000680d000000000000b85b31e3fc7f0000c0283a75127f000000e55b75127f000010d04ef6af550000460200000000000060c73975127f0000a0d23975127f0000000a3a75127f0000000000000000000051510c75127f000046020000330000002b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000007f03000000000000ffff0000000000000000000000000000000000000000000080143a75127f000080143a75127f000040143a75127f000040143a75127f00007d0000007e0000007f00000080000000300c3a75127f0000300c3a75127f00000e000000000000000e0000000000000000000000000000000000000000000000ffffffffffffffffffffffffffffffff0400000004000000040000000400000020143a75127f000020143a75127f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000801f0000000000000000000000e55b75127f0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
  (gdb)

Fix the problem by preferring current_inferior()'s pid instead of
magic_null_ptid.

Regression-tested on X86-64 Linux.

Co-authored-by: Aleksandar Paunovic <aleksandar.paunovic@intel.com>

gdb/testsuite: fix test failure when building against readline v7

The test added in the commit:

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

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

Was not written with readline 7 in mind, only readline 8+.  Between
readline 7 and 8 the escape sequence used to disable bracketed paste
mode changed, an additional '\r' character was added to the end.  In
fact, it was the addition of this '\r' character that triggered the
issue for which the above commit is part of the solution.

Anyway, the test tries to spot the case where the output from GDB is
not perfect, but does have the above work around applied.  However,
the pattern in the test assumes that the problematic '\r' will be
present, and this is only true for readline 8+.  With readline 7 the
test was failing.

In this commit I generalise the pattern a little so that the test will
still KFAIL with readline 7.

It's a little unfortunate that the test is KFAILing with readline 7,
as without the problematic '\r' there's actually no reason that GDB
couldn't "do the right thing" in this case, in which case, the test
would PASS, but that would require changes within GDB itself.

My preference then is that initially we patch the test to get it
KFAILing, then in a separate commit I can modify GDB so that it can
PASS with readline 7.

gdb/testsuite: fix copy & paste error in gdb.python/py-format-address.exp

The test gdb.python/py-format-address.exp, added in commit:

  commit 25209e2c6979c3838e14e099f0333609810db280
  Date:   Sat Oct 23 09:59:25 2021 +0100

      gdb/python: add gdb.format_address function

included 3 copy & paste errors where the wrong address was used in the
expected output patterns.

The test compiles two almost identical test binaries (one function
changes its name, that's the only difference), two inferiors are
created, each inferior using one of the test binaries.

We then take the address of the name changing function in both
inferiors ('foo' in inferior 1 and 'bar' in inferior 2) and the tests
are carried out using these addresses.

What we're checking for is that symbols 'foo' and 'bar' show up in the
correct inferior, and that (as this test is for a Python API feature),
the user can have one inferior selected, but ask about the other
inferior, and see the correct symbol in the result.

The hope is that the two binaries will be laid out identically by the
compiler, and that 'foo' and 'bar' will be at the same address.  This
is fine, unless the executable is compiled as PIE (position
independent executable), in which case there is a problem.

The problem is that though inferior 1 is set running, the inferior 2
never is.  If the executables are compiled as PIE, then the address in
the inferior 2 will not have been resolved, while the address in the
inferior 1 will have been, and so the two addresses we use in the
tests will be different.

This issue was reported here:

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

The first part of the fix is to use the correct address variable in
the expected output patterns, with this change the tests pass even
when the executables are compiled as PIE.

A second part of this fix is to pass the 'nopie' option when we
compile the tests, this should ensure that the address obtained in
inferior 2 is the same as the address from inferior 1, which makes the
test more useful.

gdb/mi: fix use after free of frame_info causing spurious notifications

In commit:

  commit a2757c4ed693cef4ecc4dcdcb2518353eb6b3c3f
  Date:   Wed Mar 16 15:08:22 2022 +0000

      gdb/mi: consistently notify user when GDB/MI client uses -thread-select

Changes were made to GDB to address some inconsistencies in when
notifications are sent from a MI terminal to a CLI terminal (when
multiple terminals are in use, see new-ui command).

Unfortunately, in order to track when the currently selected frame has
changed, that commit grabs a frame_info pointer before and after an MI
command has executed, and compares the pointers to see if the frame
has changed.

This is not safe.

If the frame cache is deleted for any reason then the frame_info
pointer captured before the command started, is no longer valid, and
any comparisons based on that pointer are undefined.

This was leading to random test failures for some folk, see:

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

This commit changes GDB so we no longer hold frame_info pointers, but
instead store the frame_id and frame_level, this is safe even when the
frame cache is flushed.

bfd/Dwarf2: gas doesn't mangle names

Include the language identifier emitted by gas in the set of ones where
no mangled names are expected. Even if there could be "hand-mangled"
names, gas doesn't emit DW_AT_linkage_name in the first place.

bfd/Dwarf2: make find-nearest-line returned function name consistent

Prior to entering the enclosing "else if()" the earlier associated if()
checks function->is_linkage and, if set, uses function->name. The
comment in patch context precedes (and explains) the setting
function->is_linkage. Yet with the flag set, we should then also return
the function name, just like said earlier if() would do when we came
here a 2nd time for the same "addr". And indeed passing the same address
twice on addr2line's command line would resolve the function for the 2nd
instance, but not for the 1st (if this code path is taken). (This,
obviously, is particularly relevant when there's no ELF symbol table in
the first place, like would be the case - naturally - in PE/COFF
binaries, for example.)

gas/Dwarf: special-case .linefile only for macros

Restrict the PR gas/16908 workaround to just macros, matching the
original intention as well as the comment there. For constructs like
.irp or .rept the reasoning doesn't apply, as there's no separate
"invocation" point which may be of interest to record (for, as said
there, short macros).

RISC-V: correct FCVT.Q.L[U]

While the spec isn't explicit about this, it pointing out the similarity
with the D extension ought to extend to the ignoring of a meaningless
rounding mode: "Note FCVT.D.W[U] always produces an exact result and is
unaffected by rounding mode." Hence the chosen encodings also ought to
match.

Note that to avoid breaking existing code the forms with a 3rd operand
are not removed, which means there continues to be a difference to
FCVT.D.W[U].

sim: add arch/.gdbinit stub scripts

Make it easy to load the common gdbinit script even when running in
the arch/ subdir instead of the top-level sim dir.

asan: heap buffer overflow in pa_chk_field_selector

The buffer overflow showed up running the gas "all macro" test.

PR 29005
* config/tc-hppa.c (pa_chk_field_selector): Don't read past end
of line.

Automatic date update in version.in

Add Rust parser check for end of expression

I noticed that "print 5," passed in Rust -- the parser wasn't checking
that the entire input was used.  This patch fixes the problem.  This
in turn pointed out another bug in the parser, namely that it didn't
lex the next token after handling a string token.  This is also fixed
here.

Switch gdb_stdlog to use timestamped_file

Currently, timestamps for logging are done by looking for the use of
gdb_stdlog in vfprintf_unfiltered.  This seems potentially buggy, in
that during logging or other redirects (like execute_fn_to_ui_file) we
might have gdb_stdout==gdb_stdlog and so, conceivably, wind up with
timestamps in a log when they were not desired.

It seems better, instead, for timestamps to be a property of the
ui_file itself.

This patch changes gdb to use the new timestamped_file for gdb_stdlog
where appropriate, and removes the special case from
vfprintf_unfiltered.

Note that this may somewhat change the output in some cases -- in
particular, when going through execute_fn_to_ui_file (or the _string
variant), timestamps won't be emitted.  This could be fixed in those
functions, but it wasn't clear to me whether this is really desirable.

Note also that this changes the TUI to send gdb_stdlog to gdb_stderr.
I imagine that the previous use of gdb_stdout here was inadvertent.
(And in any case it probably doesn't matter.)

Add new timestamped_file class

This adds a "timestamped_file" subclass of ui_file.  This class adds a
timestamp to its output when appropriate.  That is, it follows the
rule already used in vfprintf_unfiltered of adding a timestamp at most
once per write.

The new class is not yet used.

Use unique_ptr in CLI logging code

This changes the CLI logging code to avoid manual memory management
(to the extent possible) by using unique_ptr in a couple of spots.
This will come in handy in a later patch.

Simplify the CLI set_logging logic

The CLI's set_logging logic seemed unnecessarily complicated to me.
This patch simplifies it, with an eye toward changing it to use RAII
objects in a subsequent patch.

I did not touch the corresponding MI code.  That code seems incorrect
(nothing ever uses raw_stdlog, and nothing ever sets
saved_raw_stdlog).  I didn't attempt to fix this, because I question
whether this is even useful for MI.

Handle multiple addresses in call_site_target

A large customer program has a function that is partitioned into hot
and cold parts.  A variable in a callee of this function is described
using DW_OP_GNU_entry_value, but gdb gets confused when trying to find
the caller.  I tracked this down to dwarf2_get_pc_bounds interpreting
the function's changes so that the returned low PC is the "wrong"
function.

Intead, when processing DW_TAG_call_site, the low PC of each range in
DW_AT_ranges should be preserved in the call_site_target.  This fixes
the variable lookup in the test case I have.

I didn't write a standalone test for this as it seemed excessively
complicated.

Change call_site_target to iterate over addresses

In order to handle the case where a call site target might refer to
multiple addresses, we change the code to use a callback style.  Any
spot using call_site_target::address now passes in a callback function
that may be called multiple times.

Change call_site_find_chain_1 to work recursively

call_site_find_chain_1 has a comment claiming that recursive calls
would be too expensive.  However, I doubt this is so expensive; and
furthermore the explicit state management approach here is difficult
both to understand and to modify.  This patch changes this code to use
explicit recursion, so that a subsequent patch can generalize this
code without undue trauma.

Additionally, I think this patch detects a latent bug in the recursion
code.  (It's hard for me to be completely certain.)  The bug is that
when a new target_call_site is entered, the code does:

  if (target_call_site)
    {
      if (addr_hash.insert (target_call_site->pc ()).second)
{
  /* Successfully entered TARGET_CALL_SITE.  */

  chain.push_back (target_call_site);
  break;
}
    }

Here, if entering the target_call_site fails, then any tail_call_next
elements in this call site are not visited.  However, if this code
does happen to enter a call site, then the tail_call_next elements
will be visited during backtracking.  This applies when doing the
backtracking as well -- it will only continue through a given chain as
long as each element in the chain can successfully be visited.

I'd appreciate some review of this.  If this behavior is intentional,
it can be added to the new implementation.

Constify chain_candidate

While investigating this bug, I wasn't sure if chain_candidate might
update 'chain'.  I changed it to accept a const reference, making it
clear that it cannot.  This simplifies the code a tiny bit as well.

Make call_site_target members private

This makes the data members of call_site_target 'private'.  This lets
us remove most of its public API.  call_site_to_target_addr is changed
to be a method of this type.  This is a preparatory refactoring for
the fix at the end of this series.

Change call_site_target to use custom type and enum

call_site_target reuses field_loc_kind and field_location.  However,
it has never used the full range of the field_loc_kind enum.  In a
subsequent patch, I plan to add a new 'kind' here, so it seemed best
to avoid this reuse and instead introduce new types here.

Automatic date update in version.in

Automatic date update in version.in

Remove an unused declaration from value.h

value.h has a declaration of value_print_array_elements that is
incorrect.  In C, this would have been an error, but in C++ this is a
declaration of an overload that is neither defined nor used.  This
patch removes the declaration.

Automatic date update in version.in

libtool.m4: fix the NM="/nm/over/here -B/option/with/path" case

My previous nm patch handled all cases but one -- if the user set NM in
the environment to a path which contained an option, libtool's nm
detection tries to run nm against a copy of nm with the options in it:
e.g. if NM was set to "nm --blargle", and nm was found in /usr/bin, the
test would try to run "/usr/bin/nm --blargle /usr/bin/nm --blargle".
This is unlikely to be desirable: in this case we should run
"/usr/bin/nm --blargle /usr/bin/nm".

Furthermore, as part of this nm has to detect when the passed-in $NM
contains a path, and in that case avoid doing a path search itself.
This too was thrown off if an option contained something that looked
like a path, e.g. NM="nm -B../prev-gcc"; libtool then tries to run
"nm -B../prev-gcc nm" which rarely works well (and indeed it looks
to see whether that nm exists, finds it doesn't, and wrongly concludes
that nm -p or whatever does not work).

Fix all of these by clipping all options (defined as everything
including and after the first " -") before deciding whether nm
contains a path (but not using the clipped value for anything else),
and then removing all options from the path-modified nm before
looking to see whether that nm existed.

NM=my-nm now does a path search and runs e.g.
  /usr/bin/my-nm -B /usr/bin/my-nm

NM=/usr/bin/my-nm now avoids a path search and runs e.g.
  /usr/bin/my-nm -B /usr/bin/my-nm

NM="my-nm -p../wombat" now does a path search and runs e.g.
  /usr/bin/my-nm -p../wombat -B /usr/bin/my-nm

NM="../prev-binutils/new-nm -B../prev-gcc" now avoids a path search:
  ../prev-binutils/my-nm -B../prev-gcc -B ../prev-binutils/my-nm

This seems to be all combinations, including those used by GCC bootstrap
(which, before this commit, fails to bootstrap when configured
--with-build-config=bootstrap-lto, because the lto plugin is now using
--export-symbols-regex, which requires libtool to find a working nm,
while also using -B../prev-gcc to point at the lto plugin associated
with the GCC just built.)

Regenerate all affected configure scripts.

* libtool.m4 (LT_PATH_NM): Handle user-specified NM with
options, including options containing paths.

Re: gas/Dwarf: improve debug info generation from .irp and alike blocks

am33_2.0-linux is a mn10300 target.

* testsuite/gas/elf/dwarf-5-irp.d: xfail am33.

Automatic date update in version.in

Remove download size from debuginfod progress messages if unavailable

Currently debuginfod progress update messages include the size of
each download:

  Downloading 7.5 MB separate debug info for /lib/libxyz.so.0

This value originates from the Content-Length HTTP header of the
transfer.  However this header is not guaranteed to be present for
each download.  This can happen when debuginfod servers compress files
on-the-fly at the time of transfer.  In this case gdb wrongly prints
"-0.00 MB" as the size.

This patch removes download sizes from progress messages when they are
not available.  It also removes usage of the progress bar until
a more thorough reworking of progress updating is implemented. [1]

[1] https://sourceware.org/pipermail/gdb-patches/2022-February/185798.html

sim: fix a comment typo in sim-load.c

Fix a typo where the documentation refers to a function parameter by the
wrong name.

Change-Id: I99494efe62cd4aa76fb78a0bd5da438d35740ebe

sim: fix “alligned” typos

Change-Id: Ifd574e38524dd4f1cf0fc003e0c5c7499abc84a0

x86: mention dropped L1OM/K1OM support in ld/ as well

This amends e961c696dcb2 ("x86: drop L1OM/K1OM support from ld"). Also
remove the marker that I mistakenly added in c085ab00c7b2 ("x86: drop
L1OM/K1OM support from gas").

gdb/testsuite: remove gdb.python/pretty-print-call-by-hand.exp

This test was added without a corresponding fix, with some setup_kfails.
However, it results in UNRESOLVED results when GDB is built with ASan.

  ERROR: GDB process no longer exists
  GDB process exited with wait status 1946871 exp7 0 1
  UNRESOLVED: gdb.python/pretty-print-call-by-hand.exp: frame print: backtrace test (PRMS gdb/28856)

Remove the test from the tree, I'll attach it to the Bugzilla bug
instead [1].

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28856

Change-Id: Id95d8949fb8742874bd12aeac758aa4d7564d678

x86: drop L1OM/K1OM support from ld

This was only rudimentary support anyway; none of the sub-architecture
specific insns were ever supported.

x86: drop L1OM special case from disassembler

There wasn't any real support anyway: None of the sub-architecture
specific insns were ever supported.

MAINTAINERS: add myself

I much appreciate Nick offering this role to me. Nevertheless there's
still a lot for me to learn here.

At this occasion also update my email address in the pre-existing, much
more narrow entry.

Automatic date update in version.in

gdb/testsuite: address test failures in gdb.mi/mi-multi-commands.exp

The gdb.mi/mi-multi-commands.exp test was added in commit:

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

      gdb: unbuffer all input streams when not using readline

And then tweaked in commit:

  commit 144459531dd68a1287905079aaa131b777a8cc82
  Date:   Mon Feb 7 20:35:58 2022 +0000

      gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test

The second of these commits was intended to address periodic test
failures that I was seeing, and this change did fix some problems,
but, unfortunately, introduced other issues.

The problem is that the test relies on sending two commands to GDB in
a single write.  As the characters that make these two commands arrive
they are echoed to GDB's console.  However, there is a race between
how quickly the characters are echoed and how quickly GDB decides to
act on the incoming commands.

Usually, both commands are echoed in full before GDB acts on the first
command, but sometimes this is not the case, and GDB can execute the
first command before both commands are fully echoed to the console.
In this case, the output of the first command will be mixed in with
the echoing of the second command.

This mixing of the command echoing and the first command output is
what was causing failures in the original version of the test.

The second commit relaxed the expected output pattern a little, but
was still susceptible to failures, so this commit further relaxes the
pattern.

Now, we look for the first command output with no regard to what is
before, or after the command.  Then we look for the first mi prompt to
indicate that the first command has completed.

I believe that this change should make the test more stable than it
was before.

libctf: add LIBCTF_WRITE_FOREIGN_ENDIAN debugging option

libctf has always handled endianness differences by detecting
foreign-endian CTF dicts on the input and endian-flipping them: dicts
are always written in native endianness.  This makes endian-awareness
very low overhead, but it means that the foreign-endian code paths
almost never get routinely tested, since "make check" usually reads in
dicts ld has just written out: only a few corrupted-CTF tests are
actually in fixed endianness, and even they only test the foreign-
endian code paths when you run make check on a big-endian machine.
(And the fix is surely not to add more .s-based tests like that, because
they are a nightmare to maintain compared to the C-code-based ones.)

To improve on this, add a new environment variable,
LIBCTF_WRITE_FOREIGN_ENDIAN, which causes libctf to unconditionally
endian-flip at ctf_write time, so the output is always in the wrong
endianness.  This then tests the foreign-endian read paths properly
at open time.

Make this easier by restructuring the writeout code in ctf-serialize.c,
which duplicates the maybe-gzip-and-write-out code three times (once
for ctf_write_mem, with thresholding, and once each for
ctf_compress_write and ctf_write just so those can avoid thresholding
and/or compression).  Instead, have the latter two call the former
with thresholds of 0 or (size_t) -1, respectively.

The endian-flipping code itself gains a bit of complexity, because
one single endian-flipper (flip_types) was assuming the input to be
in foreign-endian form and assuming it could pull things out of the
input once they had been flipped and make sense of them. At the
cost of a few lines of duplicated initializations, teach it to
read before flipping if we're flipping to foreign-endianness instead
of away from it.

libctf/
* ctf-impl.h (ctf_flip_header): No longer static.
(ctf_flip): Likewise.
* ctf-open.c (flip_header): Rename to...
(ctf_flip_header): ... this, now it is not private to one file.
(flip_ctf): Rename...
(ctf_flip): ... this too.  Add FOREIGN_ENDIAN arg.
(flip_types): Likewise.  Use it.
(ctf_bufopen_internal): Adjust calls.
* ctf-serialize.c (ctf_write_mem): Add flip_endian path via
a newly-allocated bounce buffer.
(ctf_compress_write): Move below ctf_write_mem and reimplement
in terms of it.
(ctf_write): Likewise.
(ctf_gzwrite): Note that this obscure writeout function does not
support endian-flipping.

libctf, ld: diagnose corrupted CTF header cth_strlen

The last section in a CTF dict is the string table, at an offset
represented by the cth_stroff header field.  Its length is recorded in
the next field, cth_strlen, and the two added together are taken as the
size of the CTF dict.  Upon opening a dict, we check that none of the
header offsets exceed this size, and we check when uncompressing a
compressed dict that the result of the uncompression is the same length:
but CTF dicts need not be compressed, and short ones are not.
Uncompressed dicts just use the ctf_size without checking it.  This
field is thankfully almost unused: it is mostly used when reserializing
a dict, which can't be done to dicts read off disk since they're
read-only.

However, when opening an uncompressed foreign-endian dict we have to
copy it out of the mmaped region it is stored in so we can endian-
swap it, and we use ctf_size when doing that.  When the cth_strlen is
corrupt, this can overrun.

Fix this by checking the ctf_size in all uncompressed cases, just as we
already do in the compressed case.  Add a new test.

This came to light because various corrupted-CTF raw-asm tests had an
incorrect cth_strlen: fix all of them so they produce the expected
error again.

libctf/
PR libctf/28933
* ctf-open.c (ctf_bufopen_internal): Always check uncompressed
CTF dict sizes against the section size in case the cth_strlen is
corrupt.

ld/
PR libctf/28933
* testsuite/ld-ctf/diag-strlen-invalid.*: New test,
derived from diag-cttname-invalid.s.
* testsuite/ld-ctf/diag-cttname-invalid.s: Fix incorrect cth_strlen.
* testsuite/ld-ctf/diag-cttname-null.s: Likewise.
* testsuite/ld-ctf/diag-cuname.s: Likewise.
* testsuite/ld-ctf/diag-parlabel.s: Likewise.
* testsuite/ld-ctf/diag-parname.s: Likewise.

include, libctf, ld: extend variable section to contain functions too

The CTF variable section is an optional (usually-not-present) section in
the CTF dict which contains name -> type mappings corresponding to data
symbols that are present in the linker input but not in the output
symbol table: the idea is that programs that use their own symbol-
resolution mechanisms can use this section to look up the types of
symbols they have found using their own mechanism.

Because these removed symbols (mostly static variables, functions, etc)
all have names that are unlikely to appear in the ELF symtab and because
very few programs have their own symbol-resolution mechanisms, a special
linker flag (--ctf-variables) is needed to emit this section.

Historically, we emitted only removed data symbols into the variable
section.  This seemed to make sense at the time, but in hindsight it
really doesn't: functions are symbols too, and a C program can look them
up just like any other type.  So extend the variable section so that it
contains all static function symbols too (if it is emitted at all), with
types of kind CTF_K_FUNCTION.

This is a little fiddly.  We relied on compiler assistance for data
symbols: the compiler simply emits all data symbols twice, once into the
symtypetab as an indexed symbol and once into the variable section.

Rather than wait for a suitably adjusted compiler that does the same for
function symbols, we can pluck unreported function symbols out of the
symtab and add them to the variable section ourselves.  While we're at
it, we do the same with data symbols: this is redundant right now
because the compiler does it, but it costs very little time and lets the
compiler drop this kludge and save a little space in .o files.

include/
* ctf.h: Mention the new things we can see in the variable
section.

ld/
* testsuite/ld-ctf/data-func-conflicted-vars.d: New test.

libctf/
* ctf-link.c (ctf_link_deduplicating_variables): Duplicate
symbols into the variable section too.
* ctf-serialize.c (symtypetab_delete_nonstatic_vars): Rename
to...
(symtypetab_delete_nonstatics): ... this.  Check the funchash
when pruning redundant variables.
(ctf_symtypetab_sect_sizes): Adjust accordingly.
* NEWS: Describe this change.

ld, testsuite: improve CTF-availability test

The test for -gctf support in the compiler is used to determine when to
run the ld-ctf tests and most of those in libctf.  Unfortunately,
because it uses check_compiler_available and compile_one_cc, it will
fail whenever the compiler emits anything on stderr, even if it
actually does support CTF perfectly well.

So, instead, ask the compiler to emit assembler output and grep it for
references to ".ctf": this is highly unlikely to be present if the
compiler does not support CTF.  (This will need adjusting when CTF grows
support for non-ELF platforms that don't dot-prepend their section
names, but right now the linker doesn't link CTF on any such platforms
in any case.)

With this in place we can do things like run all the libctf tests under
leak sanitizers etc even if those spray warnings on simple CTF
compilations, rather than being blocked from doing so just when we would
most like to.

ld/
* testsuite/lib/ld-lib.exp (check_ctf_available): detect CTF
even if a CTF-capable compiler emits warnings.

gdb/python: remove Python 2/3 compatibility macros

New in this version:

 - Rebase on master, fix a few more issues that appeared.

python-internal.h contains a number of macros that helped make the code
work with both Python 2 and 3.  Remove them and adjust the code to use
the Python 3 functions.

Change-Id: I99a3d80067fb2d65de4f69f6473ba6ffd16efb2d

gdb/python: remove Python 2 support

New in this version:

 - Add a PY_MAJOR_VERSION check in configure.ac / AC_TRY_LIBPYTHON.  If
   the user passes --with-python=python2, this will cause a configure
   failure saying that GDB only supports Python 3.

Support for Python 2 is a maintenance burden for any patches touching
Python support.  Among others, the differences between Python 2 and 3
string and integer types are subtle.  It requires a lot of effort and
thinking to get something that behaves correctly on both.  And that's if
the author and reviewer of the patch even remember to test with Python
2.

See this thread for an example:

  https://sourceware.org/pipermail/gdb-patches/2021-December/184260.html

So, remove Python 2 support.  Update the documentation to state that GDB
can be built against Python 3 (as opposed to Python 2 or 3).

Update all the spots that use:

 - sys.version_info
 - IS_PY3K
 - PY_MAJOR_VERSION
 - gdb_py_is_py3k

... to only keep the Python 3 portions and drop the use of some
now-removed compatibility macros.

I did not update the configure script more than just removing the
explicit references to Python 2.  We could maybe do more there, like
check the Python version and reject it if that version is not
supported.  Otherwise (with this patch), things will only fail at
compile time, so it won't really be clear to the user that they are
trying to use an unsupported Python version.  But I'm a bit lost in the
configure code that checks for Python, so I kept that for later.

Change-Id: I75b0f79c148afbe3c07ac664cfa9cade052c0c62

x86: reject relocations involving registers

To prevent fatal or even internal errors, add a simple check to
i386_validate_fix(), rejecting relocations when their target symbol is
an equate of a register (or resolved to reg_section for any other
reason).

x86: improve resolution of register equates

Allow transitive (or recursive) equates to work in addition to direct
ones. The only requirements are that
- the equate being straight of a register, i.e. no expressions involved
  (albeit I'm afraid something like "%eax + 0" will be viewed as %eax),
- at the point of use there's no forward ref left which cannot be
  resolved, yet.

Revert "PR28977 tc-i386.c internal error in parse_register"

This reverts commit 5fac3f02edacfca458f7eeaaaa33a87e26e0e332,
which was superceeded / replaced by 4faaa10f3fab.

x86: don't attempt to resolve equates and alike from i386_parse_name()

PR gas/28977

Perhaps right from its introduction in 4d1bb7955a8b it was wrong for
i386_parse_name() to call parse_register(). This being a hook from the
expression parser, it shouldn't be resolving e.g. equated symbols.
That's relevant only for all other callers of parse_register().

To compensate, in Intel syntax mode check_register() needs calling;
perhaps not doing so was an oversight right when the function was
introduced. This is necessary in particular to force EVEX encoding when
VRex registers are used (but of course also to reject bad uses of
registers, i.e. fully matching what parse_register() needs it for).

Update the list of recognized m-profile TAG_CPU_ARCH_*

Check 3 additional variants previously not recognized:

- TAG_CPU_ARCH_V7E_M
- TAG_CPU_ARCH_V8M_BASE
- TAG_CPU_ARCH_V8M_MAIN

gas/Dwarf5: re-use file 0 line string table entry when faking file 0

No need to emit the same string a 2nd time for file 1 in this case.

gas/Dwarf5: adjust .debug_line file 0 checking

First of all when a table entry has a NULL filename, the two inner if()s
are better done the other way around: The 2nd doesn't depend on what the
first does. This then renders redundant half of the conditions of the
other if() and clarifies that subsequently only entry 0 is dealt with
(indicating that part of the comment was wrong). Finally for there to be
a usable name in slot 1, files_in_use needs to be larger than 1 and slot
1's (rather than slot 0's) name needs to be non-NULL.

gas/Dwarf5: drop dead code

Commit 3417bfca676f ("GAS: DWARF-5: Ensure that the 0'th entry in the
directory table contains the current... ") added a "dwarf_level < 5"
check to out_dir_and_file_list(). This rendered dead that branch of the
construct, due to the enclosing if()'s "DWARF2_LINE_VERSION >= 5".
Delete that code as well as the corresponding part of the comment.

While there also drop a redundant "dirs != NULL": "dirs" will always be
non-NULL when dirs_in_use is not zero.

gas/Dwarf: improve debug info generation from .irp and alike blocks

Tying the bumping of the logical line number to reading from the
original source file looks wrong: Upon finishing of the processing of an
sb the original values will be restored anyway. Yet without bumping the
line counter uses of .line inside e.g. an .irp construct won't have the
intended effect: Such uses may be necessary to ensure proper debug info
is emitted in particular when switching sections inside the .irp body,
as dwarf2_gen_line_info() would bail without doing anything when it
finds the line number unchanged from what it saw last.

ELF32: don't silently truncate relocation addends

At least x86-64's x32 sub-mode and RISC-V's 32-bit mode calculate
addends as 64-bit values, but store them in signed 32-bit fields when
generating the file without encountering any earlier error. When the
relocated field is a 64-bit one, the value resulting after processing
the relocation record when linking (or the latest when loading) may
thus be wrong due to the truncation.

With the code change in place, one x32 testcase actually triggers the
new diagnostic. That one case of too large a (negative) addend is being
adjusted alongside the addition of a new testcase to actually trigger
the new error. (Note that due to internal BFD behavior the relocation in
.data doesn't get processed anymore after the errors in .text.)

Note that in principle it is possible to express 64-bit relocations in
ELF32, but this would require .rel relocations, i.e. with the addend
stored in the 64-bit field being relocated. But I guess it would be a
lot of effort for little gain to actually support this.

gas: retain whitespace between strings

Macro arguments may be separated by commas or just whitespace. Macro
arguments may also be quoted (where one level of quotes is removed in
the course of determining the values for the respective formal
parameters). Furthermore this quote removal knows _two_ somewhat odd
escaping mechanisms: One, apparently in existence forever, is that a
pair of quotes counts as the escaping of a quote, with the pair being
transformed to a single quote in the course of quote removal. The other
(introduced by c06ae4f232e6) looks more usual on the surface in that it
deals with \" sequences, but it _retains_ the escaping \. Hence only the
former mechanism is suitable when the value to be used by the macro body
is to contain a quote. Yet this results in ambiguity of what "a""b" is
intended to mean; elsewhere (e.g. for .ascii) it represents two
successive string literals. However, in any event is the above different
from "a" "b": I don't think this can be viewed the same as "a""b" when
processing macro arguments.

Change the scrubber to retain such whitespace, by making the processing
of strings more similar to that of symbols. And indeed this appears to
make sense when taking into account that for quite a while gas has been
supporting quoted symbol names.

Taking a more general view, however, the change doesn't go quite far
enough. There are further cases where significant whitespace is removed
by the scrubber. The new testcase enumerates a few in its ".if 0"
section. I'm afraid the only way that I see to deal with this would be
to significantly simplify the scrubber, such that it wouldn't do much
more than collapse sequences of unquoted whitespace into a single blank.
To be honest problems in this area aren't really surprising when seeing
that there's hardly any checking of .macro use throughout the testsuite
(and in particular in the [relatively] generic tests under all/).

Only .so files are used in libcollector. Remove the other files.

* libcollector/Makefile.am (install-data-local): Remove the *.la
and *.a libraries.
* libcollector/Makefile.in: Regenerate.

gdb: testsuite: use gdb_attach to fix jit-elf.exp

If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the following
command without superuser:

  make check-gdb TESTS="gdb.base/jit-elf.exp"

we can see the following messages in gdb/testsuite/gdb.log:

  (gdb) attach 1650108
  Attaching to program: /home/yangtiezhu/build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 1650108
  ptrace: Operation not permitted.
  (gdb) FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach

use gdb_attach to fix the above issue, at the same time, the clean_reattach
proc should return a value to indicate whether it worked, and the callers
should return early as well on failure.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

gdb: testsuite: use gdb_attach to fix attach-pie-noexec.exp

If /proc/sys/kernel/yama/ptrace_scope is 1, when execute the following
command without superuser:

  make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"

we can see the following messages in gdb/testsuite/gdb.log:

  (gdb) attach 6500
  Attaching to process 6500
  ptrace: Operation not permitted.
  (gdb) PASS: gdb.base/attach-pie-noexec.exp: attach

It is obviously wrong, the expected result should be UNSUPPORTED in such
a case.

With this patch, we can see "Operation not permitted" in the log info,
and then we can do the following processes to test:
(1) set ptrace_scope as 0
    $ echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
    $ make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"
(2) use sudo
    $ sudo make check-gdb TESTS="gdb.base/attach-pie-noexec.exp"

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

gdb: testsuite: add new gdb_attach to check "attach" command

This commit adds new gdb_attach to centralize the failure checking of
"attach" command. Return 0 if attach failed, otherwise return 1.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

gdb: testsuite: remove attach test from can_spawn_for_attach

As Pedro Alves said, caching procs should not issue pass/fail [1],
this commit removes attach test from can_spawn_for_attach, at the
same time, use "verbose -log" instead of "unsupported" to get a
trace about why a test run doesn't support spawning for attach.

[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186311.html

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

Automatic date update in version.in

Add support for hardware breakpoints/watchpoints on FreeBSD/Aarch64.

This shares aarch64-nat.c and nat/aarch64-hw-point.c with the Linux
native target.  Since FreeBSD writes all of the debug registers in one
ptrace op, use an unordered_set<> to track the "dirty" state for
threads rather than bitmasks of modified registers.

fbsd-nat: Add a low_prepare_to_resume virtual method.

This method can be overridden by architecture-specific targets to
perform additional work before a thread is resumed.

fbsd-nat: Add a low_delete_thread virtual method.

This method can be overridden by architecture-specific targets to
perform additional work when a thread is deleted.

Note that this method is only invoked on systems supporting LWP
events, but the pending use case (aarch64 debug registers) is not
supported on older kernels that do not support LWP events.

fbsd-nat: Add helper routine to fetch siginfo_t for a ptid.

aarch64: Add an aarch64_nat_target mixin class.

This class includes platform-independent target methods for hardware
breakpoints and watchpoints using routines from
nat/aarch64-hw-point.c.

stopped_data_address is not platform-independent since the FAR
register holding the address for a breakpoint hit must be fetched in a
platform-specific manner.  However, aarch64_stopped_data_address is
provided as a helper routine which performs platform-independent
validation given the value of the FAR register.

For tracking the per-process debug register mirror state, use an
unordered_map indexed by pid as recently adopted in x86-nat.c rather
than a manual linked-list.

nat: Split out platform-independent aarch64 debug register support.

Move non-Linux-specific support for hardware break/watchpoints from
nat/aarch64-linux-hw-point.c to nat/aarch64-hw-point.c.  Changes
beyond a simple split of the code are:

- aarch64_linux_region_ok_for_watchpoint and
  aarch64_linux_any_set_debug_regs_state renamed to drop linux_ as
  they are not platform specific.

- Platforms must implement the aarch64_notify_debug_reg_change
  function which is invoked from the platform-independent code when a
  debug register changes for a given debug register state.  This does
  not use the indirection of a 'low' structure as is done for x86.

- The handling for kernel_supports_any_contiguous_range is not
  pristine.  For non-Linux it is simply defined to true.  Some uses of
  this could perhaps be implemented as new 'low' routines for the
  various places that check it instead?

- Pass down ptid into aarch64_handle_breakpoint and
  aarch64_handle_watchpoint rather than using current_lwp_ptid which
  is only defined on Linux.  In addition, pass the ptid on to
  aarch64_notify_debug_reg_change instead of the unused state
  argument.

x86-fbsd-nat: Copy debug register state on fork.

Use the FreeBSD native target low_new_fork hook to copy the
per-process debug state from the parent to the child on fork.

fbsd-nat: Add a low_new_fork virtual method.

This method can be overridden by architecture-specific targets to
perform additional work when a new child process is forked.

Add an x86_fbsd_nat_target mixin class for FreeBSD x86 native targets.

This class implements debug register support common between the i386
and amd64 native targets.

While here, remove #ifdef's for HAVE_PT_GETDBREGS in FreeBSD-specific
code.  The ptrace request has been present on FreeBSD x86
architectures since 4.0 (released in March 2000).  The last FreeBSD
release without this support is 3.5 released in June 2000.

x86-nat: Add x86_lookup_debug_reg_state.

This function returns nullptr if debug register state does not yet
exist for a given process rather than creating new state.

x86-nat: Use an unordered_map to store per-pid debug reg state.

This replaces a manual linked list which used O(n) lookup and removal.

Remove USE_SIGTRAP_SIGINFO condition for FreeBSD/x86 debug regs support.

For BSD x86 targets, stopped_by_hw_breakpoint doesn't check siginfo_t
but inspects the DR6 register directly via PT_GETDBREGS.

Remove two unused variables

I found a couple of spots that declare a symtab_and_line but don't
actually use it.  I think this probably isn't detected as unused
because it has a constructor.

Fix return code in _bfd_dwarf2_find_nearest_line().

* dwarf2.c (_bfd_dwarf2_find_nearest_line): if a function name is
found, but no line number info, then return a result of 2.

gdb/python: add gdb.format_address function

Add a new function, gdb.format_address, which is a wrapper around
GDB's print_address function.

This method takes an address, and returns a string with the format:

  ADDRESS <SYMBOL+OFFSET>

Where, ADDRESS is the original address, formatted as hexadecimal,
SYMBOL is a symbol with an address lower than ADDRESS, and OFFSET is
the offset from SYMBOL to ADDRESS in decimal.

If there's no SYMBOL suitably close to ADDRESS then the
<SYMBOL+OFFSET> part is not included.

This is useful if a user wants to write a Python script that
pretty-prints addresses, the user no longer needs to do manual symbol
lookup, or worry about correctly formatting addresses.

Additionally, there are some settings that effect how GDB picks
SYMBOL, and whether the file name and line number should be included
with the SYMBOL name, the gdb.format_address function ensures that the
users Python script also benefits from these settings.

The gdb.format_address by default selects SYMBOL from the current
inferiors program space, and address is formatted using the
architecture for the current inferior.  However, a user can also
explicitly pass a program space and architecture like this:

  gdb.format_address(ADDRESS, PROGRAM_SPACE, ARCHITECTURE)

In order to format an address for a different inferior.

Notes on the implementation:

In py-arch.c I extended arch_object_to_gdbarch to add an assertion for
the type of the PyObject being worked on.  Prior to this commit all
uses of arch_object_to_gdbarch were guaranteed to pass this function a
gdb.Architecture object, but, with this commit, this might not be the
case.

So, with this commit I've made it a requirement that the PyObject be a
gdb.Architecture, and this is checked with the assert.  And in order
that callers from other files can check if they have a
gdb.Architecture object, I've added the new function
gdbpy_is_architecture.

In py-progspace.c I've added two new function, the first
progspace_object_to_program_space, converts a PyObject of type
gdb.Progspace to the associated program_space pointer, and
gdbpy_is_progspace checks if a PyObject is a gdb.Progspace or not.