x86: shrink Masking insn attribute to a single bit (boolean)

The logic can actually be expressed with less code that way, utilizing
that there are common patterns of when which form of masking is
permitted. This then also eliminates the large set of open-codings of
BOTH_MASKING in the opcode table.

Correct ld-elf/eh5 test for hppa64

Commit 3c0afdb78988 regressed this test for hppa64, because the test
had been enabled for hppa64 in the time between the mips changes and
their reversion.  This patch isn't just a simple reapply, I recreated
the testsuite change by hand for hppa64: Two lines in eh5.d might need
further changes for mips.

Automatic date update in version.in

binutils/NEWS: Mention Sony Allegrex MIPS CPU support

Mention the addition of Sony Allegrex processor support to the MIPS port.

binutils/
* NEWS: Mention Sony Allegrex MIPS CPU support.

MIPS/GAS/testsuite: Fix `-modd-spreg'/`-mno-odd-spreg' test invocations

Reformat `-modd-spreg'/`-mno-odd-spreg' test invocations in mips.exp to
fit in 79 columns

gas/
* testsuite/gas/mips/mips.exp: Reformat
`-modd-spreg'/`-mno-odd-spreg' test invocations.

Add additional missing Allegrex CPU instructions

Allegrex supports some MIPS32 and MIPS32r2 instructions (albeit with
some encoding differences) such as bit manipulation (ins/ext) and MLA
(madd/msub).  It also features some new instructions like wsbw and
min/max or device-specific ones such as mfic.

Signed-off-by: David Guillen Fandos <david@davidgf.net>

Add rotation instructions to MIPS Allegrex CPU

The Allegrex CPU supports bit rotation instructions as described in the
MIPS32 release 2 CPU (even though it is a MIPS-2 based CPU).

Signed-off-by: David Guillen Fandos <david@davidgf.net>

Add MIPS Allegrex CPU as a MIPS2-based CPU

The Allegrex CPU was created by Sony Interactive Entertainment to power
their portable console, the PlayStation Portable.
The pspdev organization maintains all sorts of tools to create software
for said device including documentation.

Signed-off-by: David Guillen Fandos <david@davidgf.net>

GAS/doc: Correct Tag_GNU_MIPS_ABI_MSA attribute description

Rewrite the paragraph to match the style of Tag_GNU_MIPS_ABI_FP text
immediately above, correcting grammar and formatting at the same time.

gas/
* doc/as.texi (MIPS Attributes): Correct Tag_GNU_MIPS_ABI_MSA
attribute description.

Revert "MIPS: gas: alter 64 or 32 for mipsisa triples if march is implicit"

This reverts commit 094025a30bb2da19df3990e0c0ff8167af823aa1.  It was
applied unapproved.

Revert "MIPS: default r6 if vendor is img"

This reverts commit be0d391f22fe6009c3be907753975a984cbbcc23.  It was
applied unapproved.

Revert "MIPS: fix r6 testsuites"

This reverts commit ffc528aed56b9e2c171137da28690a9bb6861b0b.  It was
applied unapproved.

Revert "MIPS: fix -gnuabi64 testsuite"

This reverts commit cb81e84c72933a7fad10b75b7e270d92d8d65251.  It was
applied unapproved.

Revert "MIPS: fix some ld testcases with compiler"

This reverts commit a0631c1501c113c04891c9a24a9ff5276257f28d.  It was
applied unapproved.

Revert "MIPS: add MT ASE support for micromips32"

This reverts commit acce83dacff0ce43677410c67aaae32817afe991.  It was
applied unapproved.

Revert "MIPS: sync oprand char usage between mips and micromips"

This reverts commit 5b207b919483f67311a73dfc1de8897ecfd8e776.  It was
applied unapproved.

Re: Add some expected failures for bfin linker tests

After commit 7ade0f1582c4 I was seeing bfin-elf +XPASS: weak symbols,
and on looking into the bfin targets a little, discovered we have two
bfin-linux targets.  One, bfin-uclinux, is like bfin-elf in that
ld -m elf32bfin is the default, and the other, bfin-linux-uclibc where
ld -m elf32bfinfd is the default.  So putting bfin-*-*linux* in test
xfails or elsewhere is wrong.  We want bfin-*-linux* instead to just
select the fdpic bfin target.

This patch corrects wrong bfin target triples in the ld testsuite,
not just the recent change but others I'd added to xfails too.
It also fixes the bfin-linux-uclibc ld-elf/64ksec fail

vms write_archive memory leaks

This fixes two memory leaks in the vms archive handling.

* vms-lib.c (_bfd_vms_lib_build_map): Free input symbols.
(_bfd_vms_lib_write_archive_contents): Free archive map symbols.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.base/step-over-exit.exp with glibc debuginfo

In test-case gdb.base/step-over-exit.exp, we set a breakpoint on _exit and
continue, expecting to hit the breakpoint.

Without glibc debug info installed, we have with target board unix/-m64:
...
Thread 2.1 "step-over-exit" hit Breakpoint 2.2, 0x00007ffff7d46aee in \
  _exit () from /lib64/libc.so.6^M
(gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
...
and with target board unix/-m32:
...
Thread 2.1 "step-over-exit" hit Breakpoint 2.2, 0xf7d84c25 in _exit () from \
  /lib/libc.so.6^M
(gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
...

However after installing debug info (packages glibc-debuginfo and
glibc-32bit-debuginfo), we have for -m64 (note: __GI__exit instead of _exit):
...
Thread 2.1 "step-over-exit" hit Breakpoint 2.2, \
  __GI__exit (status=<optimized out>) at \
  ../sysdeps/unix/sysv/linux/_exit.c:27^M
27      {^M
(gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
...
and -m32 (note: _Exit instead of _exit):
...
Thread 2.1 "step-over-exit" hit Breakpoint 2.2, _Exit () at \
  ../sysdeps/unix/sysv/linux/i386/_exit.S:24^M
24      ../sysdeps/unix/sysv/linux/i386/_exit.S: No such file or directory.^M
(gdb) FAIL: gdb.base/step-over-exit.exp: continue to exit
...

The gdb_test allows for both _exit and __GI__exit, but not _Exit:
...
gdb_test "continue" \
    "Continuing\\..*Breakpoint $decimal.*_exit \\(.*\\).*" \
    "continue to exit"
...

Fix this by allowing _Exit as well.

Tested on x86_64-linux.

Add some expected failures for bfin linker tests

Add --remap-inputs option to the BFD linker.

  PR 30374
  * ldfile.c (struct input_remap): New structure. (ldfile_add_remap): New function. (ldfile_remap_input_free): New function. (ldfile_add_remap_file): New function. (ldfile_possibly_remap_input): New function. (ldfile_print_input_remaps): New function. * ldfile.h: Add prototypes for new functions.
  * ldlang.c (new_afile): Call ldfile_possibly_remap_input. (lang_finish): Call ldfile_remap_input_free. (lang_map): Call ldfile_print_input_remaps.
  * ldlex.h (OPTION_REMAP_INPUTS, OPTION_REMAP_INPUTS_FILE): Define.
  * lexsup.c (ld_options): Add --remap-inputs-file and --remap-inputs. (parse_args): Handle new options.
  * NEWS: Mention the new feature.
  * ld.texi: Document the new options.
  * testsuite/ld-misc/input-remap.exp: New test driver.
  * testsuite/ld-misc/remaps.r: New file: Expected linker output.
  * testsuite/ld-misc/remaps.txt: New file.  Input remaps file.

asprintf memory leaks

A number of backends want to return bfd_reloc_dangerous messaqes from
relocation special_function, and construct the message using asprintf.
Such messages are not freed anywhere, leading to small memory leaks
inside libbfd.  To limit the leaks, I'd implemented a static buffer in
the ppc backends that was freed before use in asprintf output.  This
patch extends that scheme to other backends using a shared static
buffer and goes further in freeing the buffer on any bfd_close.

The patch also fixes a few other cases where asprintf output was not
freed after use.

bfd/
* bfd.c (_input_error_msg): Make global and rename to..
(_bfd_error_buf): ..this.
(bfd_asprintf): New function.
(bfd_errmsg): Use bfd_asprintf.
* opncls.c (bfd_close_all_done): Free _buf_error_buf.
* elf32-arm.c (find_thumb_glue, find_arm_glue): Use bfd_asprintf.
* elf32-nios2.c (nios2_elf32_relocate_section): Likewise.
* elf32-ppc.c (ppc_elf_unhandled_reloc): Likewise.
* elf64-ppc.c (ppc64_elf_unhandled_reloc): Likewise.
* elfnn-riscv.c (riscv_resolve_pcrel_lo_relocs): Likewise.
(riscv_elf_relocate_section): Likewise.
* libbfd.h: Regenerate.
gas/
* read.c (read_end): Free current_name and current_label.
(do_s_func): Likewise on error path.  strdup label.
ld/
* pe-dll.c (make_head, make_tail, make_one),
(make_singleton_name_thunk, make_import_fixup_entry),
(make_runtime_pseudo_reloc),
(pe_create_runtime_relocator_reference: Free oname after use.

Re: bfd/elf.c strtab memory leak

There are other places that leak the strtab.

* elf.c (_bfd_elf_compute_section_file_positions): Free strtab
on error paths.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.tui/long-prompt.exp with read1

When running test-case gdb.tui/long-prompt.exp with check-read1, we get:
...
(gdb) FAIL: gdb.tui/long-prompt.exp: prompt size == width + 1: \
  end of screen: at last line
...

The problem is in these commands:
...
    Term::command "echo \\n"
    Term::command "echo \\n"
    Term::command "echo \\n"
    Term::command "echo \\n"
...

The last one makes the terminal scroll, and the scrolling makes the expected
output match on a different line.

Fix this by replacing the sequence with a single command:
...
    Term::command "echo \\n\\n\\n\\n\\n\\n"
...
which avoids scrolling.

Tested on x86_64-linux.

[gdb/testsuite] Fix and add prompt anchoring in tuiterm

There is a test-case that contains a unit test for tuiterm:
gdb.tui/tuiterm.exp.

However, this only excercises the tuiterm itself, and not the functions that
interact with it, like Term::command.

Add a new test-case gdb.tui/tuiterm-2.exp that:
- overrides proc accept_gdb_output (to be able simulate incorrect responses
  while avoiding the timeout),
- overrides proc send_gdb (to be able to call Term::command without a gdb
  instance, such that all tuiterm input is generated by the test-case).
- issues Term::command calls, and
- checks whether they behave correctly.

This exposes a problem in Term::command.  The "prompt before command" regexp
starts with a bit that is supposed to anchor the prompt to the border:
...
set str "(^|\|)$gdb_prompt $str"
...
but that doesn't work due to insufficient escaping.  Fix this by adding the
missing escape:
...
set str "(^|\\|)$gdb_prompt $str"
...

Futhermore, the "prompt after command" regexp in Term::wait_for has no
anchoring at all:
...
set prompt_wait_for "$gdb_prompt \$"
...
so add that as well.

Tested on x86_64-linux.

[gdb/testsuite] Allow procs with default value args in with_override

Currently proc with_override does not work with procs with default value args.

Fix this, and add a test-case excercising this scenario.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.dap/type_check.exp with older python

On openSUSE Leap 15.4 with system python 3.6, I run into:
...
(gdb) python check_everything()^M
(gdb) FAIL: gdb.dap/type_check.exp: type checker
...

In check_everything, the hasattr test fails silently:
...
def check_everything():
    # Older versions of Python can't really implement this.
    if hasattr(typing, "get_origin"):
...
and that makes the gdb_test in the test-case fail.

Fix this by emitting UNSUPPORTED instead in check_everything, and detecting
this in the test-case.

Tested on x86_64-linux.

gdb/testsuite: use proper int size for gdb.dwarf2/symbol_needs_eval*.exp

We recently realized that symbol_needs_eval_fail.exp and
symbol_needs_eval_timeout.exp invalidly dereference an int (4 bytes on
x86_64) by reading 8 bytes (the size of a pointer).

Here how it goes:

In gdb/testsuite/gdb.dwarf2/symbol_needs_eval.c a global variable is
defined:

    int exec_mask = 1;

and later both tests build some DWARF using the assembler doing:

    set exec_mask_var [gdb_target_symbol exec_mask]
    ...
        DW_TAG_variable {
          {DW_AT_name a}
          {DW_AT_type :$int_type_label}
          {DW_AT_location {
            DW_OP_addr $exec_mask_var
            DW_OP_deref
            ...
          }
        }

The definition of the DW_OP_deref (from Dwarf5 2.5.1.3 Stack Operations)
says that "The size of the data retrieved from the dereferenced address
is the size of an address on the target machine."

On x86_64, the size of an int is 4 while the size of an address is 8.
The result is that when evaluating this expression, the debugger reads
outside of the `a` variable.

Fix this by using `DW_OP_deref_size $int_size` instead.  To achieve
this, this patch adds the necessary steps so we can figure out what
`sizeof(int)` evaluates to for the current target.

While at it, also change the definition of the int type in the assembled
DWARF information so we use the actual target's size for an int instead
of the literal 4.

Tested on x86_64 Linux.

Approved-By: Tom Tromey <tom@tromey.com>

Automatic date update in version.in

Simplify case DW_OP_GNU_uninit in dwarf_expr_context::execute_stack_op

Tom Tromey pointed out that the test and call to error() for the
DW_OP_GNU_uninit case in dwarf_expr_context::execute_stack_op (in
gdb/dwarf2/expr.c)...

  if (op_ptr != op_end && *op_ptr != DW_OP_piece
      && *op_ptr != DW_OP_bit_piece)
    error (_("DWARF-2 expression error: DW_OP_GNU_uninit must always "
   "be the very last op in a DWARF expression or "
   "DW_OP_piece/DW_OP_bit_piece piece."));

...could be replaced by a call to dwarf_expr_require_composition which
performs a similar check and outputs a suitable error message.

Added self to W.A.A. maintainers

gdb/testsuite: Testing with the armflang compiler

Currently the Fortran test suite does not run with armflang because the
compiler detection fails. This in turn means fortran_runto_main does not
know which main method to use to start a test case.

Fortran compiler detection was added in 44d469c5f85; however, the commit
message notes that it was not tested with armflang.

This commit tests and fixes up a minor issue to get the detection
working.

The goal here is to get the tests running and preventing further
regressions during future work. This change does not do anything to fix
existing failures.

>From what I can understand, the auto detection leverages the
preprocessor to extract the Fortran compiler identity from the defines.
This preprocessor output is then evaluated by the test suite to import
these defines.

In the case of armflang, this evaluation step is disrupted by the
presence of the following warning:

    $ armflang -E -fdiagnostics-color=never testsuite/lib/compiler.F90 -o compiler.exp
    $ clang-13: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument]

The evaluation logic is already set up to filter this warning, but the
prefix differs.

This commit fixes the issue by updating the filter to exclude the
armflang flavour of warning.

gdb.fortran regression tests run with GNU, Intel and Intel LLVM. No
regressions detected.

The gdb.fortran test results with ACfL 23.04.1 are as follows.

Before:

 # of expected passes 560
 # of unexpected failures 113
 # of unresolved testcases 2
 # of untested testcases 5
 # of duplicate test names 2

After:

 # of expected passes 5388
 # of unexpected failures 628
 # of known failures 10
 # of untested testcases 8
 # of unsupported tests 5
 # of duplicate test names 5

As can be seen from the above, there are now considerably more passing
assertions.

Reviewed-By: Luis Machado <luis.machado@arm.com>
Approved-By: Tom Tromey <tom@tromey.com>

Remove f-strings from DAP

Kévin pointed out that gdb claims a minimum Python version of 3.2, but
the DAP code uses f-strings, which were added in 3.6.

This patch removes the uses of f-strings from the DAP code.  I can't
test an older version of Python, but I did confirm that this still
works with the version I have.

Implement DAP conditional breakpoints

I realized that I had only implemented DAP breakpoint conditions for
exception breakpoints, and not other kinds of breakpoints.  This patch
corrects the oversight.

Do not report totalFrames from DAP stackTrace request

Currently, gdb will unwind the entire stack in response to the
stackTrace request.  I had erroneously thought that the totalFrames
attribute was required in the response.  However, the spec says:

    If omitted or if `totalFrames` is larger than the available
    frames, a client is expected to request frames until a request
    returns less frames than requested (which indicates the end of the
    stack).

This patch removes this from the response in order to improve
performance when the stack trace is very long.

Implement DAP breakpointLocations request

This implements the DAP breakpointLocations request.

Add "stop at main" extension to DAP launch request

Co-workers who work on a program that uses DAP asked for the ability
to have gdb stop at the main subprogram when launching.  This patch
implements this extension.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Add "target" parameter to DAP attach request

This adds a new "target" to the DAP attach request.  This is passed to
"target remote".  I thought "attach" made the most sense for this,
because in some sense gdb is attaching to a running process.  It's
worth noting that all DAP "attach" parameters are defined by the
implementation.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Handle DAP supportsVariableType capability

A DAP client can report the supportsVariableType capability in the
initialize request.  In this case, gdb can include the type of a
variable or expression in various results.

Implement DAP setExpression request

This implements the DAP setExpression request.

Add gdb.Value.assign method

This adds an 'assign' method to gdb.Value.  This allows for assignment
without requiring the use of parse_and_eval.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Add type-checking to DAP requests

It occurred to me recently that gdb's DAP implementation should
probably check the types of objects coming from the client.  This
patch implements this idea by reusing Python's existing type
annotations, and supplying a decorator that verifies these at runtime.

Python doesn't make it very easy to do runtime type-checking, so the
core of the checker is written by hand.  I haven't tried to make a
fully generic runtime type checker.  Instead, this only checks the
subset that is needed by DAP.  For example, only keyword-only
functions are handled.

Furthermore, in a few spots, it wasn't convenient to spell out the
type that is accepted.  I've added a couple of comments to this effect
in breakpoint.py.

I've tried to make this code compatible with older versions of Python,
but I've only been able to try it with 3.9 and 3.10.

Use tuples for default arguments in DAP

My co-worker Kévin taught me that using a mutable object as a default
argument in Python is somewhat dangerous, because the object is
created a single time (when the function is defined), and so if it is
mutated in the body of the function, the changes will stick around.

This patch changes the cases like this in DAP to use () rather than []
as the default.  This patch is merely preventative, as no bugs like
this are in the code.

Fix a latent bug in DAP request decorator

The 'request' decorator is intended to also ensure that the request
function runs in the DAP thread.  However, the unwrapped function is
installed in the global request map, so the wrapped version is never
called.  This patch fixes the bug.

Add test for DAP pause request

I neglected to write a test for the DAP "pause" request.  This patch
adds one.

Rename one DAP function

When I first started implementing DAP, I had some vague plan of having
the implementation functions use the same name as the request.  I
abandoned this idea, but one vestige remained.  This patch renames the
one remaining function to be gdb-ish.

Add singleThread support to some DAP requests

A few DAP requests support a "singleThread" parameter, which is
somewhat similar to scheduler-locking.  This patch implements support
for this.

Implement DAP stepOut request

This implements the DAP "stepOut" request.

Implement DAP attach request

This implements the DAP "attach" request.

Note that the copyright dates on the new test source file are not
incorrect -- this was copied verbatim from another directory.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Implement DAP setExceptionBreakpoints request

This implements the DAP setExceptionBreakpoints request for Ada.  This
is a somewhat minimal implementation, in that "exceptionOptions" are
not implemented (or advertised) -- I wasn't completely sure how this
feature is supposed to work.

I haven't added C++ exception handling here, but it's easy to do if
needed.

This patch relies on the new MI command execution support to do its
work.

Don't require inferior execution for Ada catchpoints

Currently, Ada catchpoints require that the inferior be running.
However, there's no deep reason for this -- for example, C++ exception
catchpoints do not have this requirement.  Instead, those work like
ordinary breakpoints: they are pending until the needed runtime
locations are seen.

This patch changes Ada catchpoints to work the same way.

Mark members of ada_catchpoint "private"

This changes the members of ada_catchpoint to be private.

Turn should_stop_exception into a method of ada_catchpoint

This turns the should_stop_exception function in ada-lang.c into a
method of ada_catchpoint.

Combine create_excep_cond_exprs and ada_catchpoint::re_set

This patch merges create_excep_cond_exprs into ada_catchpoint::re_set.
This is less verbose and is also a step toward making ada_catchpoint
work more like the other code_breakpoint-based exception catchpoints.

Transfer ownership of exception string to ada_catchpoint

This changes the ada_catchpoint to require an rvalue ref, so that
ownership of the exception string can be transferred to the catchpoint
object.

Pass tempflag to ada_catchpoint constructor

This is a minor cleanup to pass tempflag to the ada_catchpoint
constructor.

Use gnat_runtime_has_debug_info in Ada catchpoint tests

This changes the Ada catchpoint tests to use
gnat_runtime_has_debug_info.  This simplifies the code.

Stop gdb in gnat_runtime_has_debug_info

gnat_runtime_has_debug_info starts a new gdb to do its work.  However,
it also leaves this gdb running, which can potentially confuse the
calling test -- I encountered this when writing a new DAP test.  This
patch changes the proc to shut down gdb.

[gdb/testsuite] Relax breakpoint count check in gdb.python/py-rbreak.exp

With a gdb 13.2 based package on SLE-15 aarch64,  I run into:
...
(gdb) PASS: gdb.python/py-rbreak.exp: nosharedlibrary
py sl = gdb.rbreak("^[^_]",minsyms=False)^M
Breakpoint 2 at 0x4004ac: file ../sysdeps/aarch64/crti.S, line 63.^M
  ...
(gdb) py print(len(sl))^M
12^M
(gdb) FAIL: gdb.python/py-rbreak.exp: check number of returned breakpoints is 11
...

The FAIL is due to:
- the glibc object crti.o containing debug information for function
  call_weak_fn, and
- the test-case not expecting this.

The debug information is there due to compiling glibc using a binutils which
contains commit 591cc9fbbfd ("gas/Dwarf: record functions").

I've run into a similar issue before, see commit 3fbbcf473a5 ("[gdb/testsuite]
Fix regexp in py-rbreak.exp").

The fix I applied there was to use a regexp "^[^_]" to filter out
__libc_csu_fini and __libc_csu_init, but that doesn't work for call_weak_fn.

Fix this by:
- reverting the regexp to "", and
- rewriting the check to require at least 11 functions, rather than a precise
  match.

Tested on x86_64-linux.

PR testsuite/30538
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30538

[gdb/testsuite] Fix breakpoint regexp in gdb.ada/out_of_line_in_inlined.exp

With a gdb 13.2 based package on openSUSE Tumbleweed i586, I ran into:
...
(gdb) run ^M
Starting program: out_of_line_in_inlined/foo_o224_021-all ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib/libthread_db.so.1".^M
^M
Breakpoint 1.1, foo_o224_021.child1.child2 (s=...) at foo_o224_021.adb:26^M
26                  for C of S loop^M
(gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: \
  run to foo_o224_021.child1.child2
...

I can reproduce the same issue with gdb trunk on x86_64, by using optimize=-O3
instead of optimize=-O2.

Fix this by using $bkptno_num_re.

Tested on x86_64-linux.

PR testsuite/30539
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30539

[gdb/tui] Replace macro HELP_ATTRIBUTE_MODE with std::string

Replace macro HELP_ATTRIBUTE_MODE with a std::string.

Tested on x86_64-linux.

Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Reviewed-By: Tom Tromey <tom@tromey.com>

LoongArch: gas: Relocations simplification when -mno-relax

  Gas does not emit ADD/SUB relocation pairs for label differences
  when -mno-relax.

Automatic date update in version.in

Permit DW_OP_GNU_uninit to be used with DW_OP_piece

This commit implements a fix for a bug reported against GDB on
Fedora bugzilla...

https://bugzilla.redhat.com/show_bug.cgi?id=2166796

The test case in that bug report involved running gdb against the 'jq'
program (which is a command-line JSON processor) on Fedora 37.  Since
the debug info is compiler (and compile-time option) dependent, it
won't necessarily show up in other distributions or even past or
future versions of Fedora.  (E.g. when trying the example shown below
on Fedora 38, GDB says that the value of 'value' has been optimized
out.  I.e. it does not demonstrate the same DWARF error that can be
see when using Fedora 37.)

That said, on Fedora 37, the bug could be reproduced as follows:

[kev@f37-1 ~]$ gdb jq -q -ex 'b src/util.c:415' -ex 'r </dev/null'
Reading symbols from jq...

This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.fedoraproject.org/>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Reading symbols from /home/kev/.cache/debuginfod_client/9d3c8b4197350a190a74972d481de32abf641aa4/debuginfo...
No source file named src/util.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (src/util.c:415) pending.
Starting program: /usr/bin/jq </dev/null
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, jq_util_input_next_input (state=0x55555555d7f0) at src/util.c:416
416     if (state->parser == NULL) {
(gdb) p value
DWARF-2 expression error: DW_OP_GNU_uninit must always be the very last op.

This is undesirable - rather than output an error about the DWARF
info, we'd prefer to see a value, even if it is uninitialized.

Examination of the debuginfo showed the following:

 <1><468f1>: Abbrev Number: 112 (DW_TAG_subprogram)
    <468f2>   DW_AT_external    : 1
    <468f2>   DW_AT_name        : (indirect string, offset: 0x4781): jq_util_input_next_input
    <468f6>   DW_AT_decl_file   : 10
    <468f6>   DW_AT_decl_line   : 411
    <468f8>   DW_AT_decl_column : 4
    <468f9>   DW_AT_prototyped  : 1
    <468f9>   DW_AT_type        : <0x3f2>
    <468fd>   DW_AT_sibling     : <0x4692e>
...
 <2><46921>: Abbrev Number: 102 (DW_TAG_variable)
    <46922>   DW_AT_name        : (indirect string, offset: 0x8cb): value
    <46926>   DW_AT_decl_file   : 10
    <46926>   DW_AT_decl_line   : 414
    <46928>   DW_AT_decl_column : 6
    <46929>   DW_AT_type        : <0x3f2>

Note that there's no DW_AT_location, so I looked for an abstract origin entry:

 <2><2dfa0>: Abbrev Number: 90 (DW_TAG_variable)
    <2dfa1>   DW_AT_abstract_origin: <0x46921>
    <2dfa5>   DW_AT_location    : 0x27cf1 (location list)
    <2dfa9>   DW_AT_GNU_locviews: 0x27ce1

(Note that the DW_AT_abstract_origin attribute's value is 0x46921 which
is the DIE for the local variable "value".)

Looking at the location list, I see:

    00027cf1 v000000000000000 v000000000000000 views at 00027ce1 for:
             000000000002f8fe 000000000002f92e (DW_OP_reg13 (r13); DW_OP_GNU_uninit; DW_OP_piece: 8; DW_OP_reg12 (r12); DW_OP_GNU_uninit; DW_OP_piece: 8)

While DW_OP_GNU_uninit is not the very last op, it is the last op
prior to DW_OP_piece.  The fix involved changing the DW_OP_GNU_uninit
case in dwarf_expr_context::execute_stack_op in gdb/dwarf2/expr.c so
that DW_OP_GNU_uninit may appear just before DW_OP_piece.

With the fix in place, attempting to print 'value' now looks like
this:

(gdb) p value
$1 =  [uninitialized] {kind_flags = 0 '\000', pad_ = 0 '\000', offset = 0,
  size = 0, u = {ptr = 0x0, number = 0}}

Note that "[uninitialized]" is part of the output.  (But also note
that there's an extra space character.)

I've made a new test case,
gdb.dwarf2/DW_OP_piece_with_DW_OP_GNU_uninit.exp, by adapting an
existing one, gdb.dwarf2/opt-out-not-implptr.exp.  Since it uses the
DWARF assembler, the test case does not depend on a specific compiler
version or compiler options.

Tested on Fedora 37 and Fedora 38.

Automatic date update in version.in

Automatic date update in version.in

libsframe: testsuite: add sframe_find_fre tests for pltN entries

Add a new test plt-findfre-1 to ensure lookup of SFrame stack trace
information for pltN entries is correct.

In this test, a dummy SFrame FDE of type SFRAME_FDE_TYPE_PCMASK is
created.  The size of the 'function code block' covered by the SFrame
FDE is equivalent to 5 pltN entries of 16 bytes each.

The test first looks up SFrame FREs for some addresses in the first pltN
entry, followed by lookups for some addresses in the fourth pltN entry.

libsframe/
* Makefile.in: Regenerated.
* testsuite/libsframe.find/find.exp: Add new test.
* testsuite/libsframe.find/local.mk: Likewise.
* testsuite/libsframe.find/plt-findfre-1.c: New test.

libsframe: fix sframe_find_fre for pltN entries

To find SFrame stack trace information from an FDE of type
SFRAME_FDE_TYPE_PCMASK, sframe_find_fre () was doing an operation
like,
  (start_ip_offset & 0xff) >= (pc & 0xff), etc.

This is buggy and needs correction.  The mask 0xff should be 0xf (to
work for a pltN entry of size say, 16 bytes).

At this time, the size of the pltN entry is implicitly assumed to be 16
bytes by libsframe.  In next version of the SFrame format, we can encode
this information explicitly in the SFrame FDE.

For now, we should fix the code to at least behave correctly for the
generated code and the generated SFrame stack trace information for the
pltN entries on x86_64.

libsframe/
* sframe.c (sframe_find_fre): Correct the bitmask used for
SFrame FDEs of type SFRAME_FDE_TYPE_PCMASK.

[AArch64,arm] Fix some formatting issues in the aarch64/arm codebase

As noted by Tom Tromey, there are some formatting issues with the ternary
operator in the aarch64/arm codebase.  This patch fixes those.

Reviewed-By: Tom Tromey <tom@tromey.com>

[gdb/tui] Simplify tui_puts_internal

Simplify tui_puts_internal by using continue, as per this [1] coding standard
rule, making the function more readable and easier to understand.

No functional changes.

Tested on x86_64-linux.

[1] https://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code

Reviewed-By: Tom Tromey <tom@tromey.com>

[gdb/tui] Delete line buffer when switching to singlekey

Say we're in TUI mode, and type "sun":
...
(gdb) sun
...

After switching to SingleKey mode using C-x s, we have just:
...
sun
...

After typing "d", we get:
...
sun
Undefined command: "sundown".  Try "help".
...

The SingleKey "d" is supposed run the "down" command.

Fix this by clearing the readline line buffer when switching to SingleKey
mode.

Tested on x86_64-linux.

PR tui/30522
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30522

Reviewed-By: Tom Tromey <tom@tromey.com>

[gdb/testsuite] Add test-case gdb.tui/single-key.exp

I noticed that there's no test-case excercising SingleKey mode, so add a test-case.

Tested on x86_64-linux.

Reviewed-By: Tom Tromey <tom@tromey.com>

gdb/debuginfod: cleanup debuginfod earlier

A GDB crash was discovered on Fedora GDB that was tracked back to an
issue with the way that debuginfod is cleaned up.

The bug was reported on Fedora 37, 38, and 39.  Here are the steps to
reproduce:

1. The file /etc/ssl/openssl.cnf contains the following lines:

   [provider_sect]
   default = default_sect
   ##legacy = legacy_sect
   ##
   [default_sect]
   activate = 1

   ##[legacy_sect]
   ##activate = 1

   The bug will occur when the '##' characters are removed so that the
   lines in question look like this:

   [provider_sect]
   default = default_sect
   legacy = legacy_sect

   [default_sect]
   activate = 1

   [legacy_sect]
   activate = 1

2. Clean up any existing debuginfod cache data:

   > rm -rf $HOME/.cache/debuginfod_client

3. Run GDB:

   > gdb -nx -q -iex 'set trace-commands on' \
                -iex 'set debuginfod enabled on' \
                -iex 'set confirm off' \
-ex 'start' -ex 'quit' /bin/ls
   +set debuginfod enabled on
   +set confirm off
   Reading symbols from /bin/ls...
   Downloading separate debug info for /usr/bin/ls
   ... snip ...
   Temporary breakpoint 1, main (argc=1, argv=0x7fffffffde38) at ../src/ls.c:1646
   1646    {
   +quit

   Fatal signal: Segmentation fault
   ----- Backtrace -----
   ... snip ...

So GDB ends up crashing during exit.

What's happening is that when debuginfod is initialised
debuginfod_begin is called (this is in the debuginfod library), this
in turn sets up libcurl, which makes use of openssl.  Somewhere during
this setup process an at_exit function is registered to cleanup some
state.

Back in GDB the debuginfod_client object is managed using this code:

  /* Deleter for a debuginfod_client.  */

  struct debuginfod_client_deleter
  {
    void operator() (debuginfod_client *c)
    {
      debuginfod_end (c);
    }
  };

  using debuginfod_client_up
    = std::unique_ptr<debuginfod_client, debuginfod_client_deleter>;

And then a global debuginfod_client_up is created to hold a pointer to
the debuginfod_client object.  As a global this will be cleaned up
using the standard C++ global object destructor mechanism, which is
run after the at_exit handlers.

However, it is expected that when debuginfod_end is called the
debuginfod_client object will still be in a usable state, that is, we
don't expect the at_exit handlers to have run and started cleaning up
the library state.

To fix this issue we need to ensure that debuginfod_end is called
before the at_exit handlers have a chance to run.

This commit removes the debuginfod_client_up type, and instead has GDB
hold a raw pointer to the debuginfod_client object.  We then make use
of GDB's make_final_cleanup to register a function that will call
debuginfod_end.

As GDB's final cleanups are called before exit is called, this means
that debuginfod_end will be called before the at_exit handlers are
called, and the crash identified above is resolved.

It's not obvious how this issue can easily be tested for. The bug does
not appear to manifest when using a local debuginfod server, so we'd
need to setup something more involved.  For now I'm proposing this
patch without any associated tests.

Co-Authored-By: Mark Wielaard <mark@klomp.org>
Co-Authored-By: Simon Marchi <simark@simark.ca>
Reviewed-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Aaron Merey <amerey@redhat.com>

gdb: fix ASan failure after recent string changes

After this commit:

  commit baab375361c365afee2577c94cbbd3fdd443d6da
  Date:   Tue Jul 13 14:44:27 2021 -0400

      gdb: building inferior strings from within GDB

It was pointed out that a new ASan failure had been introduced which
was triggered by gdb.base/internal-string-values.exp:

  (gdb) PASS: gdb.base/internal-string-values.exp: test_setting: all langs: lang=ada: ptype "foo"
  print $_gdb_maint_setting("test-settings string")
  =================================================================
  ==80377==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000068034 at pc 0x564785cba682 bp 0x7ffd20644620 sp 0x7ffd20644610
  READ of size 1 at 0x603000068034 thread T0
      #0 0x564785cba681 in find_command_name_length(char const*) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2129
      #1 0x564785cbacb2 in lookup_cmd_1(char const**, cmd_list_element*, cmd_list_element**, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, int, bool) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2186
      #2 0x564785cbb539 in lookup_cmd_1(char const**, cmd_list_element*, cmd_list_element**, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, int, bool) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2248
      #3 0x564785cbbcf3 in lookup_cmd(char const**, cmd_list_element*, char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >*, int, int) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2339
      #4 0x564785c82df2 in setting_cmd /tmp/src/binutils-gdb/gdb/cli/cli-cmds.c:2219
      #5 0x564785c84274 in gdb_maint_setting_internal_fn /tmp/src/binutils-gdb/gdb/cli/cli-cmds.c:2348
      #6 0x564788167b3b in call_internal_function(gdbarch*, language_defn const*, value*, int, value**) /tmp/src/binutils-gdb/gdb/value.c:2321
      #7 0x5647854b6ebd in expr::ada_funcall_operation::evaluate(type*, expression*, noside) /tmp/src/binutils-gdb/gdb/ada-lang.c:11254
      #8 0x564786658266 in expression::evaluate(type*, noside) /tmp/src/binutils-gdb/gdb/eval.c:111
      #9 0x5647871242d6 in process_print_command_args /tmp/src/binutils-gdb/gdb/printcmd.c:1322
      #10 0x5647871244b3 in print_command_1 /tmp/src/binutils-gdb/gdb/printcmd.c:1335
      #11 0x564787125384 in print_command /tmp/src/binutils-gdb/gdb/printcmd.c:1468
      #12 0x564785caac44 in do_simple_func /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:95
      #13 0x564785cc18f0 in cmd_func(cmd_list_element*, char const*, int) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2735
      #14 0x564787c70c68 in execute_command(char const*, int) /tmp/src/binutils-gdb/gdb/top.c:574
      #15 0x564786686180 in command_handler(char const*) /tmp/src/binutils-gdb/gdb/event-top.c:543
      #16 0x56478668752f in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /tmp/src/binutils-gdb/gdb/event-top.c:779
      #17 0x564787dcb29a in tui_command_line_handler /tmp/src/binutils-gdb/gdb/tui/tui-interp.c:104
      #18 0x56478668443d in gdb_rl_callback_handler /tmp/src/binutils-gdb/gdb/event-top.c:250
      #19 0x7f4efd506246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb)
      #20 0x564786683dea in gdb_rl_callback_read_char_wrapper_noexcept /tmp/src/binutils-gdb/gdb/event-top.c:192
      #21 0x564786684042 in gdb_rl_callback_read_char_wrapper /tmp/src/binutils-gdb/gdb/event-top.c:225
      #22 0x564787f1b119 in stdin_event_handler /tmp/src/binutils-gdb/gdb/ui.c:155
      #23 0x56478862438d in handle_file_event /tmp/src/binutils-gdb/gdbsupport/event-loop.cc:573
      #24 0x564788624d23 in gdb_wait_for_event /tmp/src/binutils-gdb/gdbsupport/event-loop.cc:694
      #25 0x56478862297c in gdb_do_one_event(int) /tmp/src/binutils-gdb/gdbsupport/event-loop.cc:264
      #26 0x564786df99f0 in start_event_loop /tmp/src/binutils-gdb/gdb/main.c:412
      #27 0x564786dfa069 in captured_command_loop /tmp/src/binutils-gdb/gdb/main.c:476
      #28 0x564786dff61f in captured_main /tmp/src/binutils-gdb/gdb/main.c:1320
      #29 0x564786dff75c in gdb_main(captured_main_args*) /tmp/src/binutils-gdb/gdb/main.c:1339
      #30 0x564785381b6d in main /tmp/src/binutils-gdb/gdb/gdb.c:32
      #31 0x7f4efbc3984f  (/usr/lib/libc.so.6+0x2384f) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
      #32 0x7f4efbc39909 in __libc_start_main (/usr/lib/libc.so.6+0x23909) (BuildId: 2f005a79cd1a8e385972f5a102f16adba414d75e)
      #33 0x564785381934 in _start (/tmp/build/binutils-gdb/gdb/gdb+0xabc5934) (BuildId: 90de353ac158646e7dab501b76a18a76628fca33)

  0x603000068034 is located 0 bytes after 20-byte region [0x603000068020,0x603000068034) allocated by thread T0 here:
      #0 0x7f4efcee0cd1 in __interceptor_calloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:77
      #1 0x5647856265d8 in xcalloc /tmp/src/binutils-gdb/gdb/alloc.c:97
      #2 0x564788610c6b in xzalloc(unsigned long) /tmp/src/binutils-gdb/gdbsupport/common-utils.cc:29
      #3 0x56478815721a in value::allocate_contents(bool) /tmp/src/binutils-gdb/gdb/value.c:929
      #4 0x564788157285 in value::allocate(type*, bool) /tmp/src/binutils-gdb/gdb/value.c:941
      #5 0x56478815733a in value::allocate(type*) /tmp/src/binutils-gdb/gdb/value.c:951
      #6 0x5647854ae81c in expr::ada_string_operation::evaluate(type*, expression*, noside) /tmp/src/binutils-gdb/gdb/ada-lang.c:10675
      #7 0x5647854b63b8 in expr::ada_funcall_operation::evaluate(type*, expression*, noside) /tmp/src/binutils-gdb/gdb/ada-lang.c:11184
      #8 0x564786658266 in expression::evaluate(type*, noside) /tmp/src/binutils-gdb/gdb/eval.c:111
      #9 0x5647871242d6 in process_print_command_args /tmp/src/binutils-gdb/gdb/printcmd.c:1322
      #10 0x5647871244b3 in print_command_1 /tmp/src/binutils-gdb/gdb/printcmd.c:1335
      #11 0x564787125384 in print_command /tmp/src/binutils-gdb/gdb/printcmd.c:1468
      #12 0x564785caac44 in do_simple_func /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:95
      #13 0x564785cc18f0 in cmd_func(cmd_list_element*, char const*, int) /tmp/src/binutils-gdb/gdb/cli/cli-decode.c:2735
      #14 0x564787c70c68 in execute_command(char const*, int) /tmp/src/binutils-gdb/gdb/top.c:574
      #15 0x564786686180 in command_handler(char const*) /tmp/src/binutils-gdb/gdb/event-top.c:543
      #16 0x56478668752f in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) /tmp/src/binutils-gdb/gdb/event-top.c:779
      #17 0x564787dcb29a in tui_command_line_handler /tmp/src/binutils-gdb/gdb/tui/tui-interp.c:104
      #18 0x56478668443d in gdb_rl_callback_handler /tmp/src/binutils-gdb/gdb/event-top.c:250
      #19 0x7f4efd506246 in rl_callback_read_char (/usr/lib/libreadline.so.8+0x3b246) (BuildId: 092e91fc4361b0ef94561e3ae03a75f69398acbb)

The problem is in cli/cli-cmds.c, in the function setting_cmd, where
we do this:

  const char *a0 = (const char *) argv[0]->contents ().data ();

Here argv[0] is a value* which we know is either a TYPE_CODE_ARRAY or
a TYPE_CODE_STRING.  The problem is that the above line is casting the
value contents directly to a C-string, i.e. one that is assumed to
have a null-terminator at the end.

After the above commit this can no longer be assumed to be true.  A
string value will be represented just as it would be in the current
language, so for Ada and Fortran the string will be an array of
characters with no null-terminator at the end.

My proposed solution is to copy the string contents into a std::string
object, and then use the std::string::c_str() value, this will ensure
that a null-terminator has been added.

I had a check through GDB at places TYPE_CODE_STRING was used and
couldn't see any other obvious places where this type of assumption
was being made, so hopefully this is the only offender.

Running the above test with ASan compiled in no longer gives an error.

Reviewed-By: Tom Tromey <tom@tromey.com>

Use scoped_value_mark in two more places

I found a couple of spots that could use scoped_value_mark.  One of
them is a spot that didn't consider the possibility that value_mark
can return NULL.  I tend to doubt this can be seen in this context,
but nevertheless this is safer.

Regression tested on x86-64 Fedora 36.

[gdb] Fix typos

Fix typos:
- reponse -> response
- inital -> initial
- a -> an

readelf/objdump remember_state memory leaks

* dwarf.c (display_debug_frames <DW_CFA_restore_state>): Do free
invalid remember_state.

ecoff find_nearest_line and final link leaks

Freeing ecoff_debug_info "pointers to the unswapped symbolic info"
isn't a simple matter, due to differing allocation strategies.  In
_bfd_ecoff_slurp_symbolic_info the pointers are to objalloc memory.
In the ecoff linker they are to separately malloc'd memory.  In gas we
have most (obj-elf) or all (obj-ecoff) into a single malloc'd buffer.

This patch fixes the leaks for binutils and ld, leaving the gas leaks
for another day.  The mips elf backend already had this covered, and
the ecoff backend had a pointer, raw_syments used as a flag, so most
of the patch is moving these around a little so they are accessible
for both ecoff and elf.

include/
* coff/ecoff.h (struct ecoff_debug_info): Add alloc_syments.
bfd/
* libecoff.h (struct ecoff_tdata): Delete raw_syments.
* elfxx-mips.c (free_ecoff_debug): Delete.  Replace uses with
_bfd_ecoff_free_ecoff_debug_info.
(_bfd_mips_elf_final_link): Init debug.alloc_syments.
* ecofflink.c (_bfd_ecoff_free_ecoff_debug_info): New function.
* ecoff.c (_bfd_ecoff_bfd_free_cached_info): Call
_bfd_ecoff_free_ecoff_debug_info.
(_bfd_ecoff_slurp_symbolic_info): Replace uses of raw_syments
with alloc_syments.
(ecoff_final_link_debug_accumulate): Likewise.  Use
_bfd_ecoff_free_ecoff_debug_info.
(_bfd_ecoff_bfd_copy_private_bfd_data): Set alloc_syments for
copied output.
* elf64-alpha.c (elf64_alpha_read_ecoff_info): Use
_bfd_ecoff_free_ecoff_debug_info.
* libbfd-in.h (_bfd_ecoff_free_ecoff_debug_info): Declare.
* libbfd.h: Regenerate.
gas/
* config/obj-ecoff.c (ecoff_frob_file): Set alloc_syments.
* config/obj-elf.c (elf_frob_file_after_relocs): Likewise.

Automatic date update in version.in

[gdb/testsuite] Add test-case gdb.tui/long-prompt.exp

I noticed that the test-suite doesn't excercise the case in
tui_redisplay_readline that height (initially 1) is changed by this call:
...
    tui_puts_internal (w, prompt, &height);
...

Add a test-case that excercises this.

Tested on x86_64-linux.

gdb/corelow.c: do not try to reopen a file if open failed once

In the current implementation, core_target::build_file_mappings will try
to locate and open files which were mapped in the process for which the
core dump was produced.  If the file cannot be found or cannot be
opened, GDB will re-try to open it once for each time it was mapped in
the process's address space.

This patch makes it so GDB recognizes that it has already failed to open
a given file once and does not re-try the process for each mapping.

Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb/corelow.c: avoid repeated warnings in build_file_mappings

When GDB opens a coredump it tries to locate and then open all files
which were mapped in the process.

If a file is found but cannot be opened with BFD (bfd_open /
bfd_check_format fails), then a warning is printed to the user.  If the
same file was mapped multiple times in the process's address space, the
warning is printed once for each time the file was mapped.  I find this
un-necessarily noisy.

This patch makes it so the warning message is printed only once per
file.

There was a comment in the code assuming that if the file was found on
the system, opening it (bfd_open + bfd_check_format) should always
succeed.  A recent change in BFD (014a602b86f "Don't optimise bfd_seek
to same position") showed that this assumption is not valid.  For
example, it is possible to have a core dump of a process which had
mmaped an IO page from a DRI render node (/dev/dri/runderD$NUM).  In
such case the core dump does contain the information that portions of
this special file were mapped in the host process, but trying to seek to
position 0 will fail, making bfd_check_format fail.  This patch removes
this comment.

Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb/corelow.c: fix use-after-free in build_file_mappings

In core_target::build_file_mappings, GDB tries to open files referenced
in the core dump.

The process goes like this:

    struct bfd *bfd = bfd_map[filename];
    if (bfd == nullptr)
      {
        bfd = bfd_map[filename]
          = bfd_openr (expanded_fname.get (), "binary");
        if (bfd == nullptr || !bfd_check_format (bfd, bfd_object))
          {
            if (bfd != nullptr)
              bfd_close (bfd);
            return;
          }
      }
    asection *sec = bfd_make_section_anyway (bfd, "load");
    ...

The problem is that if bfd_check_format fails, we close the bfd but keep
a reference to it in the bfd_map.

If the same filename appears another time in the NT_FILE note, we enter
this code again.  The second time, bfd_map[filename] is not nullptr and
we try to call bfd_make_section_anyway on an already closed BFD, which
is a use-after-free error.

This patch makes sure that the bfd is only saved in the bfd_map if it
got opened successfully.

This error got exposed by a recent change in BFD (014a602b86f "Don't
optimise bfd_seek to same position").  Since this change, opening a
coredump which contains mapping to some special files such as a DRI
render node (/dev/dri/renderD$NUM) exposes the issue.  This happens for
example for processes using AMDGPU devices to offload compute tasks.

Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>

Re: _bfd_free_cached_info

Oops, another leak caused by not defining the correct macro.

* elf32-mips.c: Define bfd_elf32_bfd_free_cached_info.
* elfn32-mips.c: Likewise.
* elf64-mips.c: Define bfd_elf64_bfd_free_cached_info.

Re: _bfd_free_cached_info

ELF targets with target-specific free_cache_info functions need to
call _bfd_elf_free_cached_info, not _bfd_generic_bfd_free_cached_info.

* elf64-ppc.c (ppc64_elf_free_cached_info): Call
_bfd_elf_free_cached_info.
* elfnn-aarch64.c (elfNN_aarch64_bfd_free_cached_info): Likewise.

Automatic date update in version.in

libsframe: reuse static function sframe_decoder_get_funcdesc_at_index

sframe_decoder_get_funcdesc_at_index () is the function to access SFrame
FDEs in the SFrame decoder context.  Use it consistently.

Avoid unnecessary type cast and include minor enhancements as the code
is moved around.

libsframe/
* sframe.c (sframe_decoder_get_funcdesc_at_index): Move some
checks here.  Move the static function definition before the new
use.
(sframe_decoder_get_funcdesc): Use
sframe_decoder_get_funcdesc_at_index instead.

Simplify ada_lookup_struct_elt_type

This patch simplifies ada_lookup_struct_elt_type by changing it to
call find_struct_field.  The two functions were substantially similar,
even to the point of having identical comments.

I tested this using both the gdb test suite and the internal AdaCore
test suite.  Given this and the fact that it is Ada-specific, I am
checking it in.

Add extra linker warning message about discrepancies between normal and common symbols.

  PR 30499
  bfd * elflink.c (elf_link_add_object_symbols): Add a message indicating that alignment and size discrepancies between the definition of common symbols and normal symbols are serious and should be investigated.
  ld  * testsuite/ld-elfcomm/elfcomm.exp: Update regexps to match new output from the linker.

[gdb/tui] Factor out border-mode help text

I noticed that the help texts for tui border-mode and tui active-border-mode
are similar.

Factor out the common part into macro HELP_ATTRIBUTE_MODE.

Tested on x86_64-linux.

[gdb/cli] Handle pending ^C after rl_callback_read_char for readline 7

In commit faf01aee1d0 ("[gdb] Handle pending ^C after rl_callback_read_char")
we handled a problem (described in detail in that commit) for readline >= 8
using public readline functions rl_pending_signal and rl_check_signals.

For readline 7 (note that we require at least readline 7 so there's no need to
worry about readline 6), there was no fix though, because rl_check_signals was
not available.

Fix this by instead using the private readline function _rl_signal_handler.

There is precedent for using private readline variables and functions, but
it's something we want to get rid of (PR build/10723).  Nevertheless, I think
we can allow this specific instance because it's not used when building
against readline >= 8.

[ In the meanwhile, a fix was committed in the devel branch of the readline
repo, contained in commit 8d0c439 ("rollup of changes since readline-8.2"),
first proposed here (
https://lists.gnu.org/archive/html/bug-readline/2022-10/msg00008.html ). ]

Tested on x86_64-linux, against system readline 7.0 on openSUSE Leap 15.4.

PR cli/27813
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27813

Fix PR30369 regression on aarch64/arm (PR30506)

The gdb.dwarf2/dw2-prologue-end-2.exp test was failing for both AArch64 and
Arm.

As Tom pointed out here (https://inbox.sourceware.org/gdb-patches/6663707c-4297-c2f2-a0bd-f3e84fc62aad@suse.de/),
there are issues with both the prologue skipper for AArch64 and Arm and an
incorrect assumption by the testcase.

This patch fixes both of AArch64's and Arm's prologue skippers to not skip past
the end of a function.  It also incorporates a fix to the testcase so it
doesn't assume the prologue skipper will stop at the first instruction of the
functions/labels.

Regression-tested on aarch64-linux/arm-linux Ubuntu 20.04/22.04 and
x86_64-linux Ubuntu 20.04.

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

Co-Authored-By: Tom de Vries <tdevries@suse.de>
Co-Authored-By: Luis Machado <luis.machado@arm.com>

[gdb/testsuite] Add missing wait in gdb.python/tui-window-disabled.exp

While working on PR tui/30526, I noticed a bug in test-case
gdb.python/tui-window-disabled.exp.

Here we send "tui enable" to gdb, but don't wait for it to arrive before
checking for a window box:
...
    send_gdb "tui enable\n"
    Term::check_box "check for python window" 0 0 80 16
...

Fix this by waiting for the prompt to be issued in TUI before doing the check.

Tested on x86_64-linux.

[gdb/testsuite] Fix two typos in gdb.python/tui-window-disabled.exp

Fix two typos in test-case gdb.python/tui-window-disabled.exp.

[gdb/testsuite] Handle output after prompt in gdb.threads/step-N-all-progress.exp

Using "taskset -c 0" I run into this timeout:
...
(gdb) PASS: gdb.threads/step-N-all-progress.exp: non-stop=on: \
  target-non-stop=on: continue to breakpoint: break here
next 3^M
[New Thread 0x7ffff7dbd6c0 (LWP 10202)]^M
50        return 0;^M
(gdb) [Thread 0x7ffff7dbd6c0 (LWP 10202) exited]^M
FAIL: gdb.threads/step-N-all-progress.exp: non-stop=on: target-non-stop=on: \
  next 3 (timeout)
...

The problem is that this test:
...
    gdb_test "next 3" "return 0;"
...
expects no output after the prompt.

Fix this by using -no-prompt-anchor.

Tested on x86_64-linux.

ld-elf/eh5 remove xfail hppa64

Commit cb81e84c72 resulted in an xpass for hppa64-hp-hpux11, but the
test still fails on hpp64-linux.  Let's make it pass for hppa64-linux
too, by accepting pcrel sdata8 encoding in the augmentation data.

Fix gdb.base/memtag.exp failure

While running this test on an emulator, I noticed we're failing to match the
output message when "memory-tag check" is issued with no arguments.  That's
because I coded the message using "error" and missed a period at the end.  Other
similar messages are issued with error_no_arg.

This patch changes that call to use error_no_arg.

Tested on aarch64-linux Ubuntu 20.04/22.04.

_bfd_free_cached_info

doc/bfdint.texi and comments in the aout and som code about this
function are just wrong, and its name is not very apt.  Better would
be _bfd_mostly_destroy, and we certainly should not be saying anything
about the possibility of later recreating anything lost by this
function.  What's more, if _bfd_free_cached_info is called when
creating an archive map to reduce memory usage by throwing away
symbols, the target _close_and_cleanup function won't have access to
tdata or section bfd_user_data to tidy memory.  This means most of the
target _close_and_cleanup function won't do anything, and therefore
sometimes will result in memory leaks.

This patch fixes the documentation problems and moves most of the
target _close_and_cleanup code to target _bfd_free_cached_info.
Another notable change is that bfd_generic_bfd_free_cached_info is now
defined as _bfd_free_cached_info rather than _bfd_bool_bfd_true,
ie. the default now frees objalloc memory.