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.

Fix some stale header names from dwarf files

Some of these references were not updated when they were moved to a separate
directory.

Install gprofng libraries under $(pkglibdir)

gprofng/ChangeLog
2022-03-21  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

        PR gprofng/28972
* gprofng/libcollector/Makefile.am: Rename lib_LTLIBRARIES to
pkglib_LTLIBRARIES. Add install-data-local.
* gprofng/src/Makefile.am: Likewise.
* gprofng/src/envsets.cc (putenv_libcollector_ld_misc): New location of
the gprofng libraries.
* gprofng/configure.ac: Removed an unused GPROFNG_LIBDIR.
* gprofng/Makefile.am: Removed an unused GPROFNG_LIBDIR.  Add
install-data-local.
* gprofng/configure: Regenerate.
* gprofng/Makefile.in: Likewise.
* gprofng/doc/Makefile.in: Likewise.
* gprofng/gp-display-htmllibcollector/Makefile.in: Likewise.
* gprofng/libcollector/Makefile.in: Likewise.
* gprofng/src/Makefile.in: Likewise.

Automatic date update in version.in

gdb: Add missing #include in solib.h

The gdb_bfd_ref_ptr type is used in solib.h declarations.

PR gdb/27570: missing support for debuginfod in core_target::build_file_mappings

Add debuginfod support to core_target::build_file_mappings and
locate_exec_from_corefile_build_id to enable the downloading of
missing executables and shared libraries referenced in core files.

Also add debuginfod support to solib_map_sections so that previously
downloaded shared libraries can be retrieved from the local debuginfod
cache.

When core file shared libraries are found locally, verify that their
build-ids match the corresponding build-ids found in the core file.
If there is a mismatch, attempt to query debuginfod for the correct
build and print a warning if unsuccessful:

  warning: Build-id of /lib64/libc.so.6 does not match core file.

Also disable debuginfod when gcore invokes gdb.  Debuginfo is not
needed for core file generation so debuginfod queries will slow down
gcore unnecessarily.

gdb: Add soname to build-id mapping for core files

Since commit aa2d5a422 gdb has been able to read executable and shared
library build-ids within core files.

Expand this functionality so that each core file bfd maintains a map of
soname to build-id for each shared library referenced in the core file.

This feature may be used to verify that gdb has found the correct shared
libraries for core files and to facilitate downloading shared libaries via
debuginfod.

Watchpoint followed by catchpoint misreports watchpoint (PR gdb/28621)

If GDB reports a watchpoint hit, and then the next event is not
TARGET_WAITKIND_STOPPED, but instead some event for which there's a
catchpoint, such that GDB calls bpstat_stop_status, GDB mistakenly
thinks the watchpoint triggered.  Vis, using foll-fork.c:

  (gdb) awatch v
  Hardware access (read/write) watchpoint 2: v
  (gdb) catch fork
  Catchpoint 3 (fork)
  (gdb) c
  Continuing.

  Hardware access (read/write) watchpoint 2: v

  Old value = 0
  New value = 5
  main () at gdb.base/foll-fork.c:16
  16        pid = fork ();
  (gdb)
  Continuing.

  Hardware access (read/write) watchpoint 2: v      <<<<
                                                    <<<< these lines are spurious
  Value = 5                                         <<<<

  Catchpoint 3 (forked process 1712369), arch_fork (ctid=0x7ffff7fa4810) at arch-fork.h:49
  49      arch-fork.h: No such file or directory.
  (gdb)

The problem is that when we handle the fork event, nothing called
watchpoints_triggered before calling bpstat_stop_status.  Thus, each
watchpoint's watchpoint_triggered field was still set to
watch_triggered_yes from the previous (real) watchpoint stop.
watchpoint_triggered is only current called in the handle_signal_stop
path, when handling TARGET_WAITKIND_STOPPED.

This fixes it by adding watchpoint_triggered calls in the other events
paths that call bpstat_stop_status.  But instead of adding them
explicitly, it adds a new function bpstat_stop_status_nowatch that
wraps bpstat_stop_status and calls watchpoint_triggered, and then
replaces most calls to bpstat_stop_status with calls to
bpstat_stop_status_nowatch.

This required constifying watchpoints_triggered.

New test included, which fails without the fix.

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

Change-Id: I282b38c2eee428d25319af3bc842f9feafed461c

gdbserver: Fixup previous patch

The previous prepare_resume_reply change missed updating the 'buf'
reference that overwrites the 'T', so if 'buf' was advanced, we'd
still overwrite the wrong character.  This fixes it.

Change-Id: Ia8ce433366b85af4e268c1c49e7b447da3130a4d

gdbserver: Fix incorrect assertion

While playing with adding a new event kind, I noticed that
prepare_resume_reply TARGET_WAITKIND_FORKED, etc. advance 'buf', so if
we force-disable the T packet, we'd fail the *buf == 'T' assertion.

Fix it by tweaking the assertion to always look at the beginning of
the buffer.

Change-Id: I8c38e32353db115edcde418b3b1e8ba12343c22b

gdb: re-generate config.in

I'm getting this diff when running `autoreconf -vf`.

Change-Id: Id5f009d0f0481935c1ee9df5332cb4bf45fbd32d

gdb/x86: handle stap probe arguments in xmm registers

On x86 machines with xmm register, and with recent versions of
systemtap (and gcc?), it can occur that stap probe arguments will be
placed into xmm registers.

I notice this happening on a current Fedora Rawhide install with the
following package versions installed:

  $ rpm -q glibc systemtap gcc
  glibc-2.35.9000-10.fc37.x86_64
  systemtap-4.7~pre16468670g9f253544-1.fc37.x86_64
  gcc-12.0.1-0.12.fc37.x86_64

If I check the probe data in libc, I see this:

  $ readelf -n /lib64/libc.so.6
  ...
  stapsdt              0x0000004d       NT_STAPSDT (SystemTap probe descriptors)
    Provider: libc
    Name: pthread_start
    Location: 0x0000000000090ac3, Base: 0x00000000001c65c4, Semaphore: 0x0000000000000000
    Arguments: 8@%xmm1 8@1600(%rbx) 8@1608(%rbx)
  stapsdt              0x00000050       NT_STAPSDT (SystemTap probe descriptors)
    Provider: libc
    Name: pthread_create
    Location: 0x00000000000912f1, Base: 0x00000000001c65c4, Semaphore: 0x0000000000000000
    Arguments: 8@%xmm1 8@%r13 8@8(%rsp) 8@16(%rsp)
  ...

Notice that for both of these probes, the first argument is a uint64_t
stored in the xmm1 register.

Unfortunately, if I try to use this probe within GDB, then I can't
view the first argument.  Here's an example session:

  $ gdb $(which gdb)
  (gdb) start
  ...
  (gdb) info probes stap  libc pthread_create
  ...
  (gdb) break *0x00007ffff729e2f1       # Use address of probe.
  (gdb) continue
  ...
  (gdb) p $_probe_arg0
  Invalid cast.

What's going wrong?  If I re-run my session, but this time use 'set
debug stap-expression 1', this is what I see:

  (gdb) set debug stap-expression 1
  (gdb) p $_probe_arg0
  Operation: UNOP_CAST
   Operation: OP_REGISTER
    String: xmm1
   Type: uint64_t
  Operation: UNOP_CAST
   Operation: OP_REGISTER
    String: r13
   Type: uint64_t
  Operation: UNOP_CAST
   Operation: UNOP_IND
    Operation: UNOP_CAST
     Operation: BINOP_ADD
      Operation: OP_LONG
       Type: long
       Constant: 0x0000000000000008
      Operation: OP_REGISTER
       String: rsp
     Type: uint64_t *
   Type: uint64_t
  Operation: UNOP_CAST
   Operation: UNOP_IND
    Operation: UNOP_CAST
     Operation: BINOP_ADD
      Operation: OP_LONG
       Type: long
       Constant: 0x0000000000000010
      Operation: OP_REGISTER
       String: rsp
     Type: uint64_t *
   Type: uint64_t
  Invalid cast.
  (gdb)

The important bit is this:

  Operation: UNOP_CAST
   Operation: OP_REGISTER
    String: xmm1
   Type: uint64_t

Which is where we cast the xmm1 register to uint64_t.  And the final
piece of the puzzle is:

  (gdb) ptype $xmm1
  type = union vec128 {
      v8bf16 v8_bfloat16;
      v4f v4_float;
      v2d v2_double;
      v16i8 v16_int8;
      v8i16 v8_int16;
      v4i32 v4_int32;
      v2i64 v2_int64;
      uint128_t uint128;
  }

So, we are attempting to cast a union type to a scalar type, which is
not supporting in C/C++, and as a consequence GDB's expression
evaluator throws an error when we attempt to do this.

The first approach I considered for solving this problem was to try
and make use of gdbarch_stap_adjust_register.  We already have a
gdbarch method (gdbarch_stap_adjust_register) that allows us to tweak
the name of the register that we access.  Currently only x86
architectures use this to transform things like ax to eax in some
cases.

I wondered, what if we change gdbarch_stap_adjust_register to do more
than just change the register names?  What if this method instead
became gdbarch_stap_read_register.  This new method would return a
operation_up, and would take the register name, and the type we are
trying to read from the register, and return the operation that
actually reads the register.

The default implementation of this method would just use
user_reg_map_name_to_regnum, and then create a register_operation,
like we already do in stap_parse_register_operand.  But, for x86
architectures this method would fist possibly adjust the register
name, then do the default action to read the register.  Finally, for
x86 this method would spot when we were accessing an xmm register,
and, based on the type being pulled from the register, would extract
the correct field from the union.

The benefit of this approach is that it would work with the expression
types that GDB currently supports.  The draw back would be that this
approach would not be very generic.  We'd need code to handle each
sub-field size with an xmm register.  If other architectures started
using vector registers for probe arguments, those architectures would
have to create their own gdbarch_stap_read_register method.  And
finally, the type of the xmm registers comes from the type defined in
the target description, there's a risk that GDB might end up
hard-coding the names of type sub-fields, then if a target uses a
different target description, with different field names for xmm
registers, the stap probes would stop working.

And so, based on all the above draw backs, I rejected this first
approach.

My second plan involves adding a new expression type to GDB called
unop_extract_operation.  This new expression takes a value and a type,
during evaluation the value contents are fetched, and then a new value
is extracted from the value contents (based on type).  This is similar
to the following C expression:

  result_value = *((output_type *) &input_value);

Obviously we can't actually build this expression in this case, as the
input_value is in a register, but hopefully the above makes it clearer
what I'm trying to do.

The benefit of the new expression approach is that this code can be
shared across all architectures, and it doesn't care about sub-field
names within the union type.

The draw-backs that I see are potential future problems if arguments
are not stored within the least significant bytes of the register.
However if/when that becomes an issue we can adapt the
gdbarch_stap_read_register approach to allow architectures to control
how a value is extracted.

For testing, I've extended the existing gdb.base/stap-probe.exp test
to include a function that tries to force an argument into an xmm
register.  Obviously, that will only work on a x86 target, so I've
guarded the new function with an appropriate GCC define.  In the exp
script we use readelf to check if the probe exists, and is using the
xmm register.

If the probe doesn't exist then the associated tests are skipped.

If the probe exists, put isn't using the xmm register (which will
depend on systemtap/gcc versions), then again, the tests are skipped.

Otherwise, we can run the test.  I think the cost of running readelf
is pretty low, so I don't feel too bad making all the non-xmm targets
running this step.

I found that on a Fedora 35 install, with these packages installed, I
was able to run this test and have the probe argument be placed in an
xmm register:

  $ rpm -q systemtap gcc glibc
  systemtap-4.6-4.fc35.x86_64
  gcc-11.2.1-9.fc35.x86_64
  glibc-2.34-7.fc35.x86_64

Finally, as this patch adds a new operation type, then I need to
consider how to generate an agent expression for the new operation
type.

I have kicked the can down the road a bit on this.  In the function
stap_parse_register_operand, I only create a unop_extract_operation in
the case where the register type is non-scalar, this means that in
most cases I don't need to worry about generating an agent expression
at all.

In the xmm register case, when an unop_extract_operation will be
created, I have sketched out how the agent expression could be
handled, however, this code is currently not reached.  When we try to
generate the agent expression to place the xmm register on the stack,
GDB hits this error:

  (gdb) trace -probe-stap test:xmmreg
  Tracepoint 1 at 0x401166
  (gdb) actions
  Enter actions for tracepoint 1, one per line.
  End with a line saying just "end".
  >collect $_probe_arg0
  Value not scalar: cannot be an rvalue.

This is because GDB doesn't currently support placing non-scalar types
on the agent expression evaluation stack.  Solving this is clearly
related to the original problem, but feels a bit like a second
problem.  I'd like to get feedback on whether my approach to solving
the original problem is acceptable or not before I start looking at
how to handle xmm registers within agent expressions.

Reduce O(n2) performance overhead when parsing DWARF unit information.

PR 28978
* dwarf2.c (scan_unit_for_symbols): When performing second pass,
check to see if the function or variable being processed is the
same as the previous one.

x86: don't suppress overflow diagnostics in x32 mode

Unlike in 64-bit mode, where values wrap at the 64-bit boundary anyway,
there's no wrapping at the 32-bit boundary here, and hence overflow
detection shouldn't be suppressed just because rela relocations are
going to be used.

The extra check against NO_RELOC is actually a result of an ilp32 test
otherwise failing. But thinking about it, reporting overflows for
not-really-relocations (typically because of earlier errors) makes
little sense in general. Perhaps this should even be extended to non-
64-bit modes.

gdb/testsuite: reformat gdb.python/pretty-print-call-by-hand.py

Run black on the file.

Change-Id: Ifb576137fb7158a0227173f61c1202f0695b3685

[gdb/testsuite] test a function call by hand from pretty printer

The test case added here is testing the bug gdb/28856, where calling a
function by hand from a pretty printer makes GDB crash. There are 6
mechanisms to trigger this crash in the current test, using the commands
backtrace, up, down, finish, step and continue. Since the failure happens
because of use-after-free (more details below) the tests will always
have a chance of passing through sheer luck, but anecdotally they seem
to fail all of the time.

The reason GDB is crashing is a use-after-free problem. The above
mentioned functions save a pointer to the current frame's information,
then calls the pretty printer, and uses the saved pointer for different
reasons, depending on the function. The issue happens because
call_function_by_hand needs to reset the obstack to get the current
frame, invalidating the saved pointer.

gdb/testsuite: Installed-GDB testing & data-directory

In testsuite/README, we suggest that you can run the testsuite against
some other GDB binary by using:

    make check RUNTESTFLAGS=GDB=/usr/bin/gdb

However, that example isn't fully correct, because with that command
line, the testsuite will still pass

  -data-directory=[pwd]/../data-directory

to /usr/bin/gdb, like e.g.:

  ...
  builtin_spawn /usr/bin/gdb -nw -nx -data-directory /home/pedro/gdb/build/gdb/testsuite/../data-directory -iex set height 0 -iex set width 0
  ...

while if you're testing an installed GDB (the system GDB being the
most usual scenario), then you should normally let it use its own
configured directory, not the just-built GDB's data directory.

This commit improves the status quo with the following two changes:

 - if the user specifies GDB on the command line, then by default,
   don't start GDB with the -data-directory command line option.
   I.e., let the tested GDB use its own configured data directory.

 - let the user override the data directory, via a new
   GDB_DATA_DIRECTORY global.  This replaces the existing
   BUILD_DATA_DIRECTORY variable in testsuite/lib/gdb.exp, which
   wasn't overridable, and was a bit misnamed for the new purpose.

So after this, the following commands I believe behave intuitively:

 # Test the non-installed GDB in some build dir:

    make check \
      RUNTESTFLAGS="GDB=/path/to/other/build/gdb \
                    GDB_DATA_DIRECTORY=/path/to/other/build/gdb/data-directory"

 # Test the GDB installed in some prefix:

    make check \
      RUNTESTFLAGS="GDB=/opt/gdb/bin/gdb"

 # Test the built GDB with some alternative data directory, e.g., the
   system GDB's data directory:

    make check \
      RUNTESTFLAGS="GDB_DATA_DIRECTORY=/usr/share/gdb"

Change-Id: Icdc21c85219155d9564a9900961997e6624b78fb

z80 assembler: Fix new unexpected overflow warning in v2.37

PR 28791
* config/tc-z80.c (emit_data_val): Do not warn about overlarge
constants generated by bit manipulation operators.
* testsuite/gas/z80/pr28791.s: New test source file.
* testsuite/gas/z80/pr28791.d: New test driver file.

Add support for readline 8.2

In readline 8.2 the type of rl_completer_word_break_characters changed to
include const.

Automatic date update in version.in

RISC-V: Fix misplaced @end table

Move the csr-check and arch items inside the table for the .option directive.

PR28979, internal error in demand_empty_rest_of_line

The change in read_a_source_file prevents the particular testcase in
the PR from triggering the assertion in demand_empty_rest_of_line.
I've also removed the assertion.  Nothing much goes wrong with gas if
something else triggers it, so it's not worthy of an abort.

I've also changed my previous patch to ignore_rest_of_line to allow
that function to increment input_line_pointer past buffer_limit, like
demand_empty_rest_of_line:  The two functions ought to behave the
same in that respect.  Finally, demand_empty_rest_of_line gets a
little hardening to prevent accesses past buffer_limit plus one.

PR 28979
* read.c (read_a_source_file): Calculate known size for sbuf
rather than calling strlen.
(demand_empty_rest_of_line): Remove "know" check.  Expand comment.
Don't dereference input_line_pointer when past buffer_limit.
(ignore_rest_of_line): Allow input_line_pointer to increment to
buffer_limit plus one.  Expand comment.

Update gdb/NEWS after GDB 12 branch creation.

This commit a new section for the next release branch, and renames
the section of the current branch, now that it has been cut.

Bump version to 13.0.50.DATE-git.

Now that the GDB 12 branch has been created,
this commit bumps the version number in gdb/version.in to
13.0.50.DATE-git

For the record, the GDB 12 branch was created
from commit 2be64de603f8b3ae359d2d3fbf5db0e79869f32b.

Also, as a result of the version bump, the following changes
have been made in gdb/testsuite:

* gdb.base/default.exp: Change $_gdb_major to 13.

ld:LoongArch: Add test cases to adapt to LoongArch32 and LoongArch64

  ld/testsuite/ld-loongarch-elf

  *  ld-loongarch-elf.exp:  Test LoongArch32 and LoongArch64 testcases respectively.
  *  jmp_op.d: Fix bug in test LoongArch32.
  *  disas-jirl-32.d: New test case for LoongArch32.
  *  disas-jirl-32.s: New test case for LoongArch32.
  *  disas-jirl.d: Skip test case LoongArch32.
  *  macro_op_32.d: New test case for LoongArch32.
  *  macro_op_32.s: New test case for LoongArch32.
  *  macro_op.d: Skip test case LoongArch32.

gas:LoongArch: Fix "make check" pr21884 fail in LoongArch32.

  gas/config/
    * tc-loongarch.c: Add function to select target mach.
    * tc-loongarch.h: Define macro TARGET_MACH.

ld: loongarch: Skip unsupport test cases.

  ld/testsuite/ld-elf/
    * eh5.d Skip loongarch64 target.
    * pr21884.d Skip loongarch* targets.
    * pr26936.d Skip loongarch* targets.

LoongArch: Fix LD check fails.

  Some test cases about ifunc.

  bfd/
    * elfnn-loongarch.c
    * elfxx-loongarch.h

   === ld Summary ===
  of expected passes             1430
  of expected failures           11
  of untested testcases          1
  of unsupported tests           154

LoongArch: Update ABI eflag in elf header.

  Update LoongArch ABI eflag in elf header.
    ilp32s  0x5
    ilp32f  0x6
    ilp32d  0x7
    lp64s   0x1
    lp64f   0x2
    lp64d   0x3

  bfd/
    * elfnn-loongarch.c Check object flags while ld.

  gas/
    * tc-loongarch.c Write eflag to elf header.

  include/elf
        * loongarch.h Define ABI number.

gas:LoongArch: Fix wrong line number in .debug_line

  The dwarf2_emit_insn() can create debuginfo of line. But it is called
  too late in append_fixp_and_insn. It causes extra offs when debuginfo
  of line sets address.

  gas/config/
    * tc-loongarch.c

gas:LoongArch: Fix segment error in compilation due to too long symbol name.

  Change "char buffer[8192];" into "char *buffer =
  (char *) malloc(1000 +  6 * len_str);" in function
  loongarch_expand_macro_with_format_map.

  gas/
    * config/tc-loongarch.c

  include/
    * opcode/loongarch.h

  opcodes/
    * loongarch-coder.c

LoongArch: Use functions instead of magic numbers.

  Replace the magic numbers in gas(tc-loongarch.c) and
  bfd(elfnn-loongarch.c) with the functions defined in
  the howto table(elfxx-loongarch.c).

  gas/
    * config/tc-loongarch.c: use functions.

  bfd/
    * elfnn-loongarch.c: use functions.
    * elfxx-loongarch.c: define functions.
    * elfxx-loongarch.h

ubsan: loongarch : signed integer shift overflow.

   opcodes/
* loongarch-coder.c :
  int32_t ret = 0;
  ret <<= sizeof (ret) * 8 - len;
  ret >>= sizeof (ret) * 8 - len;
  ...
  Avoid ubsan warning.

Automatic date update in version.in

gdb/python: remove gdb._mi_commands dict

The motivation for this patch is the fact that py-micmd.c doesn't build
with Python 2, due to PyDict_GetItemWithError being a Python 3-only
function:

      CXX    python/py-micmd.o
    /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c: In function â€˜int micmdpy_uninstall_command(micmdpy_object*)’:
    /home/smarchi/src/binutils-gdb/gdb/python/py-micmd.c:430:20: error: â€˜PyDict_GetItemWithError’ was not declared in this scope; did you mean â€˜PyDict_GetItemString’?
      430 |   PyObject *curr = PyDict_GetItemWithError (mi_cmd_dict.get (),
          |                    ^~~~~~~~~~~~~~~~~~~~~~~
          |                    PyDict_GetItemString

A first solution to fix this would be to try to replace
PyDict_GetItemWithError equivalent Python 2 code.  But I looked at why
we are doing this in the first place: it is to maintain the
`gdb._mi_commands` Python dictionary that we use as a `name ->
gdb.MICommand object` map.  Since the `gdb._mi_commands` dictionary is
never actually used in Python, it seems like a lot of trouble to use a
Python object for this.

My first idea was to replace it with a C++ map
(std::unordered_map<std::string, gdbpy_ref<micmdpy_object>>).  While
implementing this, I realized we don't really need this map at all.  The
mi_command_py objects registered in the main MI command table can own
their backing micmdpy_object (that's a gdb.MICommand, but seen from the
C++ code).  To know whether an mi_command is an mi_command_py, we can
use a dynamic cast.  Since there's one less data structure to maintain,
there are less chances of messing things up.

 - Change mi_command_py::m_pyobj to a gdbpy_ref, the mi_command_py is
   now what keeps the MICommand alive.
 - Set micmdpy_object::mi_command in the constructor of mi_command_py.
   If mi_command_py manages setting/clearing that field in
   swap_python_object, I think it makes sense that it also takes care of
   setting it initially.
 - Move a bunch of checks from micmdpy_install_command to
   swap_python_object, and make them gdb_asserts.
 - In micmdpy_install_command, start by doing an mi_cmd_lookup.  This is
   needed to know whether there's a Python MI command already registered
   with that name.  But we can already tell if there's a non-Python
   command registered with that name.  Return an error if that happens,
   rather than waiting for insert_mi_cmd_entry to fail.  Change the
   error message to "name is already in use" rather than "may already be
   in use", since it's more precise.

I asked Andrew about the original intent of using a Python dictionary
object to hold the command objects.  The reason was to make sure the
objects get destroyed when the Python runtime gets finalized, not later.
Holding the objects in global C++ data structures and not doing anything
more means that the held Python objects will be decref'd after the
Python interpreter has been finalized.  That's not desirable.  I tried
it and it indeed segfaults.

Handle this by adding a gdbpy_finalize_micommands function called in
finalize_python.  This is the mirror of gdbpy_initialize_micommands
called in do_start_initialization.  In there, delete all Python MI
commands.  I think it makes sense to do it this way: if it was somehow
possible to unload Python support from GDB in the middle of a session
we'd want to unregister any Python MI command.  Otherwise, these MI
commands would be backed with a stale PyObject or simply nothing.

Delete tests that were related to `gdb._mi_commands`.

Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I060d5ebc7a096c67487998a8a4ca1e8e56f12cd3

Automatic date update in version.in

Fix crash with stepi, no debug info, and "set debug infrun 1"

A stepi in a function without debug info with "set debug infrun 1"
crashes GDB since commit c8353d682f69 (gdb/infrun: some extra infrun
debug print statements), due to a reference to
"tp->current_symtab->filename" when tp->current_symtab is null.

This commit adds the missing null check.  The output in this case
becomes:

  [infrun] set_step_info: symtab = <null>, line = 0, step_frame_id = {stack=0x7fffffffd980,code=0x0000000000456c30,!special}, step_stack_frame_id = {stack=0x7fffffffd980,code=0x0000000000456c30,!special}

Change-Id: I5171a9d222bc7e15b9dba2feaba7d55c7acd99f8

Implement gdbarch_stack_frame_destroyed_p for aarch64

The internal AdaCore testsuite has a test that checks that an
out-of-scope watchpoint is deleted.  This fails on some aarch64
configurations, reporting an extra stop:

    (gdb) continue
    Continuing.

    Thread 3 hit Watchpoint 2: result

    Old value = 64
    New value = 0
    0x0000000040021648 in pck.get_val (seed=0, off_by_one=false) at [...]/pck.adb:13
    13    end Get_Val;

I believe what is happening here is that the variable is stored at:

    <efa>   DW_AT_location    : 2 byte block: 91 7c  (DW_OP_fbreg: -4)

and the extra stop is reported just before a return, when the ldp
instruction is executed:

   0x0000000040021644 <+204>: ldp x29, x30, [sp], #48
   0x0000000040021648 <+208>: ret

This instruction modifies the frame base calculation, and so the test
picks up whatever memory is pointed to in the callee frame.

Implementing the gdbarch hook gdbarch_stack_frame_destroyed_p fixes
this problem.

As usual with this sort of patch, it has passed internal testing, but
I don't have a good way to try it with dejagnu.  So, I don't know
whether some existing test covers this.  I suspect there must be one,
but it's also worth noting that this test passes for aarch64 in some
configurations -- I don't know what causes one to fail and another to
succeed.

Fix Build issues due to patch "gprofng: a new GNU profiler"

  Find and fix more places where clock_gettime() and CLOCK_MONOTONIC_RAW are used.

gdb: run black to format some Python files

Seems like some leftovers from previous commits.

Change-Id: I7155ccdf7a4fef83bcb3d60320252c3628efdb83

Fix ld-arm bug in encoding of blx calls jumping from thumb to arm instructions

PR 28924
* elf32-arm.c (THM_MAX_FWD_BRANCH_OFFSET): Fix definition.
(THM2_MAX_FWD_BRANCH_OFFSET): Likewise.

x86: also fold remaining multi-vector-size shift insns

By slightly relaxing the checking in operand_type_register_match() we
can fold the vector shift insns with an XMM source as well. While
strictly speaking an overlap in just one size (see the code comment) is
not enough (both operands could have multiple sizes with just a single
common one), this is good enough for all templates we have, or which
could sensibly / usefully appear (within the scope of the present
operand matching model).

Tightening this a little would be possible, but would require broadcast
related information to be passed into the function.

x86: drop stray CheckRegSize from VEXTRACT{F,I}32X4

They have only a single operand allowing multiple sizes, hence there are
no pairs of operands to check for consistent size.

x86: fold certain AVX2 templates into their AVX counterparts

Like for AVX512VL we can make the handling of operand sizes a little
more flexible to allow reducing the number of templates we have.

RISC-V: Cache management instructions

This commit adds 'Zicbom' / 'Zicboz' instructions.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Add handling for
new instruction classes.

include/ChangeLog:

* opcode/riscv-opc.h (MATCH_CBO_CLEAN, MASK_CBO_CLEAN,
MATCH_CBO_FLUSH, MASK_CBO_FLUSH, MATCH_CBO_INVAL,
MASK_CBO_INVAL, MATCH_CBO_ZERO, MASK_CBO_ZERO): New macros.
* opcode/riscv.h (enum riscv_insn_class): Add new instruction
classes INSN_CLASS_ZICBOM and INSN_CLASS_ZICBOZ.

opcodes/ChangeLog:

* riscv-opc.c (riscv_opcodes): Add cache-block management
instructions.

RISC-V: Prefetch hint instructions and operand set

This commit adds 'Zicbop' hint instructions.

bfd/ChangeLog:

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

gas/ChangeLog:

* config/tc-riscv.c (riscv_ip): Add handling for new operand
type 'f' (32-byte aligned pseudo S-type immediate for prefetch
hints).
(validate_riscv_insn): Likewise.

include/ChangeLog:

* opcode/riscv-opc.h (MATCH_PREFETCH_I, MASK_PREFETCH_I,
MATCH_PREFETCH_R, MASK_PREFETCH_R, MATCH_PREFETCH_W,
MASK_PREFETCH_W): New macros.
* opcode/riscv.h (enum riscv_insn_class): Add new instruction
class INSN_CLASS_ZICBOP.

opcodes/ChangeLog:

* riscv-dis.c (print_insn_args): Add handling for new operand
type.
* riscv-opc.c (riscv_opcodes): Add prefetch hint instructions.

PR28977 tc-i386.c internal error in parse_register

PR 28977
* config/tc-i386.c (parse_register): Handle X_op not O_register
as for a non-reg_section symbol.  Simplify array bounds check.

Tidy gas current_frame before exit

Releases some obstack memory on an error path.

* cond.c (cond_finish_check): Call cond_exit_macro.

ubsan: logical_input_line signed integer overflow

To avoid a completely useless fuzzing ubsan "bug" report, I decided to
make logical_input_line unsigned.

* input-scrub.c (logical_input_line): Make unsigned.
(struct input_save): Here too.
(input_scrub_reinit, input_scrub_close, bump_line_counters),
(as_where): Adjust to suit.

Automatic date update in version.in

gprofng: Skip jsynprog with a broken javac

On CET enabled Linux/x86-64 machines, one can get

$ javac simple.java
Error: dl failure on line 894
Error: failed /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-6.fc35.x86_64/jre/lib/amd64/server/libjvm.so, because /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-6.fc35.x86_64/jre/lib/amd64/server/libjvm.so: rebuild shared object with SHSTK support enabled

Set GPROFNG_BROKEN_JAVAC to "yes" only with a broken javac and skip the
jsynprog test with a broken javac.

PR gprofng/28965
* Makefile.am (GPROFNG_BROKEN_JAVAC): New.
(check-DEJAGNU): Pass GPROFNG_BROKEN_JAVAC to runtest.
* configure.ac (GPROFNG_BROKEN_JAVAC): New AC_SUBST.  Set to yes
with a broken javac.
* Makefile.in: Regenerate.
* configure: Likewise.
* testsuite/gprofng.display/display.exp: Skip jsynprog with a
broken javac.

Remove fall throughs in core_target::xfer_partial.

The cases for TARGET_OBJECT_LIBRARIES and TARGET_OBJECT_LIBRARIES_AIX
can try to fetch different data objects (such as
TARGET_OBJECT_SIGNAL_INFO) if gdbarch methods for the requested data
aren't present.  Return with TARGET_XFER_E_IO if the gdbarch method
isn't present instead.

gdb: Remove support for S+core

GCC removed support for score back in 2014 already.  Back then, we
basically agreed about removing it from GDB too, but it ended up being
forgotten.  See:

 https://sourceware.org/pipermail/gdb/2014-October/044643.html

Following through this time around.

Change-Id: I5b25a1ff7bce7b150d6f90f4c34047fae4b1f8b4