Build ldint

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>

DIGEST: Makefile.*

The Makefile.in was generated using automake
after adding a few files.

When adding the ldreflect.* files, the autotools
versions were wrong.
After upgrading the host OS, autotools were upgraded to 2.71
reinstalling the desired 2.69 still generates a lot of changes.

Makefile.ini has therefore been manually edited.

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>

DIGEST: calculation

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>

DIGEST: ldlang.*: add timestamp

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>

DIGEST: ldmain.c

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>

DIGEST: ldgram.y

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>

DIGEST: ldlex.l

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>

DIGEST: testsuite

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>

DIGEST: Documentation

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>

DIGEST: NEWS

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>

DIGEST: LICENSING

Signed-off-by: Ulf Samuelsson <ulf@emagii.com>

[gdb/testsuite] Fix gdb.base/signals-state-child.exp for remote-gdbserver-on-localhost

With test-case gdb.base/signals-state-child.exp on target board
remote-gdbserver-on-localhost I run into:
...
builtin_spawn /usr/bin/ssh -t -l remote-target localhost \
  $outputs/gdb.base/signals-state-child/signals-state-child-standalone^M
bash: $outputs/gdb.base/signals-state-child/signals-state-child-standalone: \
  Permission denied^M
Connection to localhost closed.^M^M
FAIL: gdb.base/signals-state-child.exp: collect standalone signals state
...

The problem is that we're trying to run an executable on the target board using
a host path.

After fixing this by downloading the exec to the target board, we run into:
...
builtin_spawn /usr/bin/ssh -t -l remote-target localhost \
  signals-state-child-standalone^M
bash: signals-state-child-standalone: command not found^M
Connection to localhost closed.^M^M
FAIL: gdb.base/signals-state-child.exp: collect standalone signals state
...

Fix this by using an absolute path name for the exec on the target board.

The dejagnu proc standard_file does not support op == "absolute" for target
boards, so add an implementation in remote-gdbserver-on-localhost.exp.

Also:
- fix a PATH-in-test-name issue
- cleanup gdb.txt and standalone.txt on target board

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.cp/breakpoint-shlib-func.exp with remote-gdbserver-on-localhost

Test-case gdb.cp/breakpoint-shlib-func.exp fails with target board
remote-gdbserver-on-localhost.

Fix this by adding the missing gdb_load_shlib.

Tested on x86_64-linux.

Modify altivec-regs.exp testcase for AIX

On AIX, the debugger cannot access vector registers before they
are first used by the inferior.  Hence we change the test case
such that some vector registers are accessed by the variable 'x' in AIX
and other targets are not affected as a consequence of the same.

[gdb/testsuite] Fix gdb.mi/*.exp with remote-gdbserver-on-localhost

When running test-cases gdb.mi/*.exp with target board
remote-gdbserver-on-localhost, we run into a few fails.

Fix these (and make things more similar to the gdb.exp procs) by:
- factoring out mi_load_shlib out of mi_load_shlibs
- making mi_load_shlib use gdb_download_shlib, like
  gdb_load_shlib
- factoring out mi_locate_shlib out of mi_load_shlib
- making mi_locate_shlib check for mi_spawn_id, like
  gdb_locate_shlib
- using gdb_download_shlib and mi_locate_shlib in the test-cases.

Tested on x86_64-linux, with and without target board
remote-gdbserver-on-localhost.

gdb: fix -Wsingle-bit-bitfield-constant-conversion warning in z80-tdep.c

When building with clang 16, I see:

    /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:338:32: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
            info->prologue_type.load_args = 1;
                                          ^ ~
    /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:345:36: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
          info->prologue_type.critical = 1;
                                       ^ ~
    /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:351:37: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
          info->prologue_type.interrupt = 1;
                                        ^ ~
    /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:367:36: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
                  info->prologue_type.fp_sdcc = 1;
                                              ^ ~
    /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:375:35: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
          info->prologue_type.fp_sdcc = 1;
                                      ^ ~
    /home/smarchi/src/binutils-gdb/gdb/z80-tdep.c:380:35: error: implicit truncation from 'int' to a one-bit wide bit-field changes value from 1 to -1 [-Werror,-Wsingle-bit-bitfield-constant-conversion]
          info->prologue_type.fp_sdcc = 1;
                                      ^ ~

Fix that by using "unsigned int" as the bitfield's underlying type.

Change-Id: I3550a0112f993865dc70b18f02ab11bb5012693d

gdbsupport: ignore -Wenum-constexpr-conversion in enum-flags.h

When building with clang 16, we get:

      CXX    gdb.o
    In file included from /home/smarchi/src/binutils-gdb/gdb/gdb.c:19:
    In file included from /home/smarchi/src/binutils-gdb/gdb/defs.h:65:
    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/enum-flags.h:95:52: error: integer value -1 is outside the valid range of values [0, 15] for this enumeration type [-Wenum-constexpr-conversion]
        integer_for_size<sizeof (T), static_cast<bool>(T (-1) < T (0))>::type
                                                       ^

The error message does not make it clear in the context of which enum
flag this fails (i.e. what is T in this context), but it doesn't really
matter, we have similar warning/errors for many of them, if we let the
build go through.

clang is right that the value -1 is invalid for the enum type we cast -1
to.  However, we do need this expression in order to select an integer
type with the appropriate signedness.  That is, with the same signedness
as the underlying type of the enum.

I first wondered if that was really needed, if we couldn't use
std::underlying_type for that.  It turns out that the comment just above
says:

    /* Note that std::underlying_type<enum_type> is not what we want here,
       since that returns unsigned int even when the enum decays to signed
       int.  */

I was surprised, because std::is_signed<std::underlying_type<enum_type>>
returns the right thing.  So I tried replacing all this with
std::underlying_type, see if that would work.  Doing so causes some
build failures in unittests/enum-flags-selftests.c:

      CXX    unittests/enum-flags-selftests.o
    /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:254:1: error: static assertion failed due to requirement 'gdb::is_same<selftests::enum_flags_tests::check_valid_expr254::archetype<enum_flags<s
    elftests::enum_flags_tests::RE>, selftests::enum_flags_tests::RE, enum_flags<selftests::enum_flags_tests::RE2>, selftests::enum_flags_tests::RE2, enum_flags<selftests::enum_flags_tests::URE>, selftests::enum_fla
    gs_tests::URE, int>, selftests::enum_flags_tests::check_valid_expr254::archetype<enum_flags<selftests::enum_flags_tests::RE>, selftests::enum_flags_tests::RE, enum_flags<selftests::enum_flags_tests::RE2>, selfte
    sts::enum_flags_tests::RE2, enum_flags<selftests::enum_flags_tests::URE>, selftests::enum_flags_tests::URE, unsigned int>>::value == true':
    CHECK_VALID (true,  int,  true ? EF () : EF2 ())
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/smarchi/src/binutils-gdb/gdb/unittests/enum-flags-selftests.c:91:3: note: expanded from macro 'CHECK_VALID'
      CHECK_VALID_EXPR_6 (EF, RE, EF2, RE2, UEF, URE, VALID, EXPR_TYPE, EXPR)
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:105:3: note: expanded from macro 'CHECK_VALID_EXPR_6'
      CHECK_VALID_EXPR_INT (ESC_PARENS (typename T1, typename T2,           \
      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/valid-expr.h:66:3: note: expanded from macro 'CHECK_VALID_EXPR_INT'
      static_assert (gdb::is_detected_exact<archetype<TYPES, EXPR_TYPE>,    \
      ^              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is a bit hard to decode, but basically enumerations have the
following funny property that they decay into a signed int, even if
their implicit underlying type is unsigned.  This code:

    enum A {};
    enum B {};

    int main() {
      std::cout << std::is_signed<std::underlying_type<A>::type>::value
                << std::endl;
      std::cout << std::is_signed<std::underlying_type<B>::type>::value
                << std::endl;
      auto result = true ? A() : B();
      std::cout << std::is_signed<decltype(result)>::value << std::endl;
    }

produces:

    0
    0
    1

So, the "CHECK_VALID" above checks that this property works for enum flags the
same way as it would if you were using their underlying enum types.  And
somehow, changing integer_for_size to use std::underlying_type breaks that.

Since the current code does what we want, and I don't see any way of doing it
differently, ignore -Wenum-constexpr-conversion around it.

Change-Id: Ibc82ae7bbdb812102ae3f1dd099fc859dc6f3cc2

gdb.threads/next-bp-other-thread.c: Ensure child thread is started.

Use a pthread_barrier to ensure the child thread is started before
the main thread gets to the first breakpoint.

gdb.threads/execl.c: Ensure all threads are started before execl.

Use a pthread_barrier to ensure all threads are started before
proceeding to the breakpoint where info threads output is checked.

gdb.base/catch-syscall.exp: Remove some Linux-only assumptions.

- Some OS's use a different syscall for exit().  For example, the
  BSD's use SYS_exit rather than SYS_exit_group.  Update the C source
  file and the expect script to support SYS_exit as an alternative to
  SYS_exit_group.

- The cross-arch syscall number tests are all Linux-specific with
  hardcoded syscall numbers specific to Linux kernels.  Skip these
  tests on non-Linux systems.  FreeBSD kernels for example use the
  same system call numbers on all platforms, so the test is also not
  relevant on FreeBSD.

gdb.threads/multi-create: Double the existing stack size.

Setting the stack size to 2*PTHREAD_STACK_MIN actually lowered the
stack on FreeBSD rather than raising it causing non-main threads in
the test program to overflow their stack and crash.  Double the
existing stack size rather than assuming that the initial stack size
is PTHREAD_STACK_MIN.

amd64-linux-tdep: Don't treat fs_base and gs_base as system registers.

These registers can be changed directly in userspace, and similar
registers to support TLS on other architectures (tpidr* on ARM and
AArch64, tp on RISC-V) are treated as general purpose registers.

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

gdb.arch/amd64-gs_base.exp: Support non-Linux.

The orig_rax pseudo-register is Linux-specific and isn't relevant to
this test.  The fs_base and gs_base registers are also not treated as
system registers in other OS ABIs.  This allows the test to pass on
FreeBSD.

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

Automatic date update in version.in

gdb/python: Fix --disable-tui build

As of 2023-02-13 "gdb/python: deallocate tui window factories at Python
shut down" (9ae4519da90), a TUI-less build fails with:

$src/gdb/python/py-tui.c: In function ‘void gdbpy_finalize_tui()’:
$src/gdb/python/py-tui.c:621:3: error: ‘gdbpy_tui_window_maker’ has not been declared
  621 |   gdbpy_tui_window_maker::invalidate_all ();
      |   ^~~~~~~~~~~~~~~~~~~~~~

Since gdbpy_tui_window_maker is only defined under #ifdef TUI, add an
#ifdef guard in gdbpy_finalize_tui as well.

[gdb/testsuite] Move gdb.base/gdb-caching-proc.exp to gdb.testsuite

Test-case gdb.base/gdb-caching-proc.exp doesn't really test gdb, but it tests
the gdb_caching_procs in the testsuite, so it belongs in gdb.testsuite rather
than gdb.base.

Move test-case gdb.base/gdb-caching-proc.exp to gdb.testsuite, renaming it to
gdb.testsuite/gdb-caching-proc-consistency.exp to not clash with
recently added gdb.testsuite/gdb-caching-proc.exp.

Tested on x86_64-linux.

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

[gdb/testsuite] Allow args in gdb_caching_proc

Test-case gdb.base/morestack.exp contains:
...
require {have_compile_flag -fsplit-stack}
...
and I want to cache the result of have_compile_flag.

Currently gdb_caching_proc doesn't allow args, so I could add:
...
gdb_caching_proc have_compile_flag_fsplit_stack {
    return [have_compile_flag -fsplit-stack]
}
...
and then use that proc instead, but I find this cumbersome and
maintenance-unfriendly.

Instead, allow args in a gdb_caching_proc, such that I can simply do:
...
-proc have_compile_flag { flag } {
+gdb_caching_proc have_compile_flag { flag } {
...

Note that gdb_caching_procs with args do not work with the
gdb.base/gdb-caching-procs.exp test-case, so those procs are skipped.

Tested on x86_64-linux.

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

[gdb/testsuite] Use regular proc syntax for gdb_caching_proc

A regular tcl proc with no args looks like:
...
proc foo {} {
     return 1
}
...
but a gdb_caching_proc deviates from that syntax by dropping the explicit no
args bit:
...
gdb_caching_proc foo {
     return 1
}
...

Make the gdb_caching_proc use the same syntax as regular procs, such that we
have instead:
...
gdb_caching_proc foo {} {
     return 1
}
...

Tested on x86_64-linux.

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

[gdb/testsuite] Add gdb.testsuite/gdb-caching-proc.exp

Add test-case gdb.testsuite/gdb-caching-proc.exp that excercises
gdb_caching_proc.

Tested on x86_64-linux.

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

Fix DAP stackTrace through frames without debuginfo

The DAP stackTrace implementation did not fully account for frames
without debuginfo.  Attemping this would yield a result like:

{"request_seq": 5, "type": "response", "command": "stackTrace", "success": false, "message": "'NoneType' object has no attribute 'filename'", "seq": 11}

This patch fixes the problem by adding another check for None.

Remove exception_catchpoint::resources_needed

exception_catchpoint::resources_needed has a FIXME comment that I
think makes this method obsolete.  Also, I note that similar
catchpoints, for example Ada catchpoints, don't have this method.
This patch removes the method.  Regression tested on x86-64 Fedora 36.

Remove two more files in gdb "distclean"

The recent work to have gdb link via libtool means that there are a
couple more generated files in the build directory that should be
removed by "distclean".

Note that gdb can't really fully implement distclean due to the desire
to put certain generated files into the distribution.  Still, it can
get pretty close.

macho null dereference read

The main problem here was not returning -1 from canonicalize_symtab on
an error, leaving the vector of relocs only partly initialised and one
with a null sym_ptr_ptr.

* mach-o.c (bfd_mach_o_canonicalize_symtab): Return -1 on error,
not 0.
(bfd_mach_o_pre_canonicalize_one_reloc): Init sym_ptr_ptr to
undefined section sym.

PR30198, Assertion and segfault when linking x86_64 elf and coff

PR 30198
* coff-x86_64.c (coff_amd64_reloc): Set *error_message when
returning bfd_reloc_dangerous.  Also check that __ImageBase is
defined before accessing h->u.def.

More _bfd_ecoff_locate_line sanity checks

* ecofflink.c (mk_fdrtab): Discard fdr with negative cpd.
(lookup_line): Sanity check fdr cbLineOffset and cbLine.
Sanity check pdr cbLineOffset.

Correct odd loop in ecoff lookup_line

I can't see why this really odd looking loop was written the way it
was in commit a877f5917f90, but it can result in a buffer overrun.

* ecofflink.c (lookup_line): Don't swap in pdr at pdr_end.

Downgrade objdump fatal errors to non-fatal

* objdump.c (slurp_symtab): Replace bfd_fatal calls with calls
to my_bfd_nonfatal.
(slurp_dynamic_symtab, disassemble_section): Likewise.
(disassemble_data): Replace fatal call with non_fatal call, and
set exit_status.  Don't error on non-existent dynamic relocs.
Don't call bfd_fatal on bfd_canonicalize_dynamic_reloc error.
(dump_ctf, dump_section_sframe): Replace bfd_fatal calls with
calls to my_bfd_nonfatal and clean up memory.
(dump_relocs_in_section): Don't call bfd_fatal on errors.
(dump_dynamic_relocs): Likewise.
(display_any_bfd): Make archive nesting too depp non_fatal.

Downgrade addr2line fatal errors to non-fatal

* addr2line.c (slurp_symtab): Don't exit on errors.
(process_file): Likewise.

Downgrade nm fatal errors to non-fatal

Many of the fatal errors in nm ought to be recoverable.  This patch
downgrades most of them.  The ones that are left are most likely due
to memory allocation failures.

* nm.c (print_symdef_entry): Don't bomb with a fatal error
on a corrupted archive symbol table.
(filter_symbols): Silently omit symbols that return NULL
from bfd_minisymbol_to_symbol rather than giving a fatal
error.
(display_rel_file): Don't give a fatal error on
bfd_read_minisymbols returning an error, or on not being able
to read dynamic symbols for synth syms.
(display_archive): Downgrade bfd_openr_next_archived_file
error.
(display_file): Don't bomb on a bfd_close failure.

Move nm.c cached line number info to bfd usrdata

Replace the static variables used by nm to cache line number info
with a struct attached to the bfd.  Cleaner, and it avoids any concern
that lineno_cache_bfd is somehow left pointing at memory for a closed
bfd and that memory is later reused for another bfd, not that I think
this is possible.  Also don't bomb via bfd_fatal on errors getting
the line number info, just omit the line numbers.

* nm.c (struct lineno_cache): Rename from get_relocs_info.
Add symcount.
(lineno_cache_bfd, lineno_cache_rel_bfd): Delete.
(get_relocs): Adjust for struct rename.  Don't call bfd_fatal
on errors.
(free_lineno_cache): New function.
(print_symbol): Use lineno_cache in place of statics.  Don't
call bfd_fatal on errors reading symbols, just omit the line
info.
(display_archive, display_file): Call free_lineno_cache.

Correct objdump command line error handling

bfd_nonfatal is used when a bfd error is to be printed.  That's not
the case for command line errors.

* objdump.c (nonfatal): Rename to my_bfd_nonfatal.
(main): Use non_fatal and call usage on unrecognized arg errors.
Don't set exit_status when calling usage.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb/testsuite: use `kill -FOO` instead of `kill -SIGFOO`

When running gdb.base/bg-exec-sigint-bp-cond.exp when SHELL is dash,
rather than bash, I get:

    c&^M
    Continuing.^M
    (gdb) sh: 1: kill: Illegal option -S^M
    ^M
    Breakpoint 2, foo () at /home/jenkins/smarchi/binutils-gdb/build/gdb/testsuite/../../../gdb/testsuite/gdb.base/bg-exec-sigint-bp-cond.c:23^M
    23        return 0;^M
    FAIL: gdb.base/bg-exec-sigint-bp-cond.exp: no force memory write: SIGINT does not interrupt background execution (timeout)

This is because it uses the kill command built-in the dash shell, and
using the SIG prefix with kill does not work with dash's kill.  The
difference is listed in the documentation for bash's POSIX-correct mode
[1]:

    The kill builtin does not accept signal names with a ‘SIG’ prefix.

Replace SIGINT with INT in that test.

By grepping, I found two other instances (gdb.base/sigwinch-notty.exp
and gdb.threads/detach-step-over.exp).  Those were not problematic on my
system though.  Since they are done through remote_exec, they don't go
through the shell and therefore invoke /bin/kill.  On my Arch Linux,
it's:

    $ /bin/kill --version
    kill from util-linux 2.38.1 (with: sigqueue, pidfd)

and on my Ubuntu:

    $ /bin/kill --version
    kill from procps-ng 3.3.17

These two implementations accept "-SIGINT".  But according to the POSIX
spec [2], the kill utility should recognize the signal name without the
SIG prefix (if it recognizes them with the SIG prefix, it's an
extension):

    -s  signal_name
        Specify the signal to send, using one of the symbolic names defined
in the <signal.h> header. Values of signal_name shall be recognized
in a case-independent fashion, without the SIG prefix. In addition,
the symbolic name 0 shall be recognized, representing the signal
value zero. The corresponding signal shall be sent instead of SIGTERM.
    -signal_name
        [XSI] [Option Start]
        Equivalent to -s signal_name. [Option End]

So, just in case some /bin/kill implementation happens to not recognize
the SIG prefixes, change these two other calls to remove the SIG
prefix.

[1] https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html
[2] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/kill.html

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

[gdb/testsuite] Use set always-read-ctf on instead of --strip-debug

Use "set always-read-ctf on" instead of --strip-debug in the ctf test-cases.

Tested on x86_64-linux.

Update expected results in long_long.exp

Simon pointed out that the recent patch to add half-float support to
'x/f' caused a couple of regressions in long_long.exp.  This patch
fixes these by updating the expected results.

Prevent the ASCII linker script directive from generating huge amounts of padding if the size expression is not a constant.

 PR 30193 * ldgram.y (ASCII): Fail if the size is not a constant.

gdb/python: replace strlen call with std::string::size call

Small cleanup to use std::string::size instead of calling strlen on
the result of std::string::c_str.

Should be no user visible changes after this call.

x86: use swap_2_operands() in build_vex_prefix()

Open-coding part of what may eventually be needed is somewhat risky.
Let's use the function we have, taking care of all pieces of data which
may need swapping, no matter that
- right now i.flags[] and i.reloc[] aren't relevant here (yet),
- EVEX masking and embedded broadcast aren't applicable.

x86: drop redundant calculation of EVEX broadcast size

In commit a5748e0d8c50 ("x86/Intel: allow MASM representation of
embedded broadcast") I replaced the calculation of i.broadcast.bytes in
check_VecOperands() not paying attention to the immediately following
call to get_broadcast_bytes() doing exactly that (again) first thing.

gas: default .debug section compression method adjustments

While commit b0c295e1b8d0 ("add --enable-default-compressed-debug-
sections-algorithm configure option") adjusted flag_compress_debug's
initializer, it didn't alter the default used when the command line
option was specified with an (optional!) argument. This rendered help
text inconsistent with actual behavior in certain configurations.

As to help text - the default reported there clearly shouldn't be
affected by a possible earlier --compress-debug-sections= option, so
flag_compress_debug can't be used when emitting usage information.

x86: avoid .byte in testcases where possible

In the course of using the upcoming .insn directive to eliminate various
.byte uses in testcases I've come across these, which needlessly use
more .byte than necessary even without the availability of .insn.

Tidy type handling in binutils/rdcoff.c

There isn't really any good reason for code in rdcoff.c to distinguish
between "basic" types and any other type.  This patch dispenses with
the array reserved for basic types and instead handles all types using
coff_get_slot, simplifying the code.

* rdcoff.c (struct coff_types, coff_slots): Merge.  Delete
coff_slots.
(T_MAX): Delete.
(parse_coff_base_type): Use coff_get_slot to store baseic types.
(coff_get_slot, parse_coff_type, parse_coff_base_type),
(parse_coff_struct_type, parse_coff_enum_type),
(parse_coff_symbol, parse_coff): Pass types as coff_types**.

binutils coff type list

As for commit 72d225ef9cc7, handle type numbers starting anywhere.

PR 17512
* rdcoff.c (struct coff_slots): Add base_index.
(coff_get_slot): Delete pr17512 excessively large slot check.
Don't allocate entire array from 0 to type number, allocate a
sparse array.

Automatic date update in version.in

gdb: fix -Wmaybe-uninitialized warning in value.c

Since commit 11470e70ea0d ("gdb: store internalvars in an std::map"), bulding
with -O2, with g++ 11.3.0 on Ubuntu 22.04, I see:

      CXX    value.o
    In constructor ‘internalvar::internalvar(internalvar&&)’,
        inlined from ‘constexpr std::pair<_T1, _T2>::pair(_U1&&, _U2&&) [with _U1 = const char*&; _U2 = internalvar; typename std::enable_if<(std::_PCC<true, _T1, _T2>::_MoveConstructiblePair<_U1, _U2>() && std::_PCC<true, _T1, _T2>::_ImplicitlyMoveConvertiblePair<_U1, _U2>()), bool>::type <anonymous> = true; _T1 = const char*; _T2 = internalvar]’ at /usr/include/c++/11/bits/stl_pair.h:353:35,
        inlined from ‘constexpr std::pair<typename std::__strip_reference_wrapper<typename std::decay<_Tp>::type>::__type, typename std::__strip_reference_wrapper<typename std::decay<_Tp2>::type>::__type> std::make_pair(_T1&&, _T2&&) [with _T1 = const char*&; _T2 = internalvar]’ at /usr/include/c++/11/bits/stl_pair.h:572:72,
        inlined from ‘internalvar* create_internalvar(const char*)’ at /home/smarchi/src/binutils-gdb/gdb/value.c:1933:52:
    /home/smarchi/src/binutils-gdb/gdb/value.c:1831:8: warning: ‘<unnamed>.internalvar::u’ may be used uninitialized [-Wmaybe-uninitialized]
     1831 | struct internalvar
          |        ^~~~~~~~~~~
    /home/smarchi/src/binutils-gdb/gdb/value.c: In function ‘internalvar* create_internalvar(const char*)’:
    /home/smarchi/src/binutils-gdb/gdb/value.c:1933:76: note: ‘<anonymous>’ declared here
     1933 |   auto pair = internalvars.emplace (std::make_pair (name, internalvar (name)));
          |                                                                            ^

This is because the union field internalvar::u is not initialized when
constructing the temporary internalvar object above.  That object is then used
for move-construction, and the (implicit) move constructor copies the
uninitialized bytes of field u over from the temporary object to the new
internalvar object.  The compiler therefore complains that we use uninitialized
bytes.  I don't think it's really a problem, because the internalvar object is
in the `kind == INTERNALVAR_VOID` state, in which the contents of the union is
irrelevant.  Still, mute the warning by default-initializing the union.

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

Handle half-float in 'x' command

Using 'x/hf' should print bytes as float16, but instead it currently
prints as an integer.  I tracked this down to a missing case in
float_type_from_length.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30161
Approved-By: Simon Marchi <simon.marchi@efficios.com>

Fix some value comments

I noticed a very stale comment in valarith.c.  This patch fixes a few
comments in this area.

Reviewed-By: Andrew Burgess <aburgess@redhat.com>

gdb: LoongArch: Add support for static data member in struct

As described in C++ reference [1], static data members are not part
of objects of a given class type. Modified compute_struct_member ()
to ignore static data member so that we can get the expected result.

loongson@linux:~$ cat test.c
#include<stdio.h>
struct struct_01 { static unsigned a; float b;};
unsigned struct_01::a = 66;
struct struct_01 struct_01_val = { 99.00 };
int check_arg_struct(struct struct_01 arg)
  {
    printf("arg.a = %d\n", arg.a);
    printf("arg.b = %f\n", arg.b);
    return 0;
  }
int main()
  {
    check_arg_struct(struct_01_val);
    return 0;
  }
loongson@linux:~$ g++ -g test.c -o test++
loongson@linux:~$ gdb test++

Without this patch:
...
(gdb) start
...
(gdb) p check_arg_struct(struct_01_val)
arg.a = 66
arg.b = 0.000000
$1 = 0

With this patch:
...
(gdb) start
...
(gdb) p check_arg_struct(struct_01_val)
arg.a = 66
arg.b = 99.000000
$1 = 0

[1] https://learn.microsoft.com/en-us/cpp/cpp/static-members-cpp?view=msvc-170

Signed-off-by: Hui Li <lihui@loongson.cn>
Reviewed-By: Tom Tromey <tom@tromey.com>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

Don't write zeros to a gap in the output file

Writing out zeros is counterproductive if a file system supports
sparse files.  A very large gap need not take much actual disk space,
but it usually will if zeros are written.

memory_bseek also supports not writing out zeros in a gap.

* elf.c (write_zeros): Delete.
(assign_file_positions_for_load_sections): Don't call write_zeros.
Comment.

[gdb/symtab] Add set/show always-read-ctf on/off

[ This is a simplified rewrite of an earlier submission "[RFC][gdb/symtab] Add
maint set symbol-read-order", submitted here (
https://sourceware.org/pipermail/gdb-patches/2022-September/192044.html
). ]

With the test-case included in this patch, we run into:
...
(gdb) file dwarf2-and-ctf
(gdb) print var_ctf^M
'var_ctf' has unknown type; cast it to its declared type^M
...

The problem is that the executable contains both ctf and dwarf2, so the ctf
info (which contains the type information about var_ctf) is ignored.

GDB has support for handling multiple debug formats, but the common use case
for ctf is to be used when dwarf2 is not present, and gdb reflects that,
assuming that by reading ctf in addition there won't be any extra information,
so it's not worth the additional cycles and memory.

Add a new command "set/show always-read-ctf on/off", that when on forces
unconditional reading of ctf, allowing us to do:
...
(gdb) set always-read-ctf on
(gdb) file dwarf2-and-ctf
(gdb) print var_ctf^M
$2 = 2^M
...

The setting is off by default, preserving current behaviour.

A bit of background on the relevance of reading order: the formats have a
priority relationship between them, where reading earlier means lower
priority.  By reading the format with the most detail last, we ensure it has
the highest priority, which makes sure that in case there is overlapping info,
the most detailed info is found.  This explains the current reading order of
mdebug, stabs and dwarf2.

Add the unconditional reading of ctf before dwarf2, because it's less detailed
than dwarf2.  The conditional reading of ctf is still done after the attempt to
read dwarf2, necessarily so because we only know whether there's dwarf2 after
we've tried to read it.

The new command allow us to replace uses of -Wl,--strip-debug added in commit
908a926ec4e ("[gdb/testsuite] Fix ctf test-cases on openSUSE Tumbleweed") by
uses of "set always-read-ctf on", but I've left that for another commit.

Tested on x86_64-linux.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>

gdb: update some copyright years (2022 -> 2023)

The copyright years in the ROCm files (e.g. solib-rocm.c) are wrong,
they end in 2022 instead of 2023.  I suppose because I posted (or at
least prepared) the patches in 2022 but merged them in 2023, and forgot
to update the year.  I found a bunch of other files that are in the same
situation.  Fix them all up.

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

Automatic date update in version.in

Use const for dwarf2_property_baton

Once a baton is stored in a struct type, it doesn't make sense to
modify it.  This patch constifies the API.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Make gdb property batons type-safe

gdbtypes treats dynamic property batons as 'void *', but in actuality
the only users all use dwarf2_property_baton.  This patch changes this
code to be type-safe.  If a new type is needed here, it seems like
that too could be done in a type-safe way.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

More bounds checking in macro_expand

* macro.c (macro_expand): Ensure input string buffer is not
read past end.

Using .mri in assembly

Changing mri mode between macro definition and use isn't good.  This
.macro x
.endm
.mri 1
x
leads to a segfault.  Fixed with the following patch, but I suppose
what should really happen is that macros be marked as being mri mode
when defined, and that determine whether the magic NARG parameter be
supplied at expansion.  Nobody has complained about this in 30 years
so I'm not inclined to change gas behaviour to that extent.

* macro.c (macro_expand): Don't segfault in mri mode if NARG
formal isn't found.

Fix type of check_valid_shift_count parameter

check_valid_shift_count has an 'int' parameter that really should be
an enum exp_opcode.  This patch makes the change.  Tested by
rebuilding.

gdb: fix a whitespace issue in solib-rocm.c

Change-Id: I9cd236eaf161fe3a1abf0d212efca47a7149e021

Fix typo with my email address

Fix btrace regression

Tom de Vries pointed out that my earlier patch:

    commit 873a185be258ad2552b9579005852815b4da5baf
    Date:   Fri Dec 16 07:56:57 2022 -0700

Don't use struct buffer in handle_qxfer_btrace

regressed gdb.btrace/reconnect.exp.  I didn't notice this because I
did not have libipt installed.

This patch fixes the bug.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30169
Tested-By: Bruno Larsen <blarsen@redhat.com>

[gdb/testsuite] Add another xfail case in gdb.python/py-record-btrace.exp

I ran into:
...
(gdb) PASS: gdb.python/py-record-btrace.exp: function call: \
  python print(c.prev)
python print(c == c.next.prev)^M
Traceback (most recent call last):^M
  File "<string>", line 1, in <module>^M
AttributeError: 'NoneType' object has no attribute 'prev'^M
Error while executing Python code.^M
(gdb) FAIL: gdb.python/py-record-btrace.exp: function call: \
  python print(c == c.next.prev)
...
due to having only 4 insn instead of 100:
...
python print(len(insn))^M
4^M
...

This could be caused by the same hw bug as we already have an xfail for, so
expand the xfail matching.

Tested on x86_64-linux.

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

Approved-By: Markus T. Metzger <markus.t.metzger@intel.com>

Catch overflow in gas s_space

Also fix an error introduced in 1998 in reporting a zero count for
negative counts.

      * read.c (s_space): Use unsigned multiply, and catch overflow.
      Correct order of tests for invalid repeat counts.  Ensure
      ignored directives don't affect mri_pending_align.

gas s_fill caused internal error in frag_new

Fix an internal error after "non-constant fill count for absolute
section".

* read.c (s_fill): Don't create frags after errors.

Memory leak in gas do_repeat

* read.c (do_repeat): Free sb on error path.

Automatic date update in version.in

gdb: add HtabPrinter to gdb-gdb.py.in

When debugging GDB, I find it a bit tedious to inspect htab_t objects.
It is possible to find the entries by poking at the fields, but it's
annoying to do each time.  I think a pretty printer would help.  Add a
basic one to gdb-gdb.py.

The pretty printer advertises itself as "array-like", and the result
looks like:

    (top-gdb) p bfcache
    $3 = htab_t with 3 elements = {0x6210003252a0, 0x62100032caa0, 0x62100033baa0}

The htab_t itself doesn't know about the type of pointed objects.  But
it's easy enough to cast the addresses to the right type to use them:

    (top-gdb) print *((btrace_frame_cache *) 0x6210003252a0)
    $6 = {tp = 0x61700002ed80, frame = 0x6210003251e0, bfun = 0x62000000b390}

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

[gdb/testsuite] Fix gdb.python/py-breakpoint.exp timeouts

On powerpc64le-linux, I run into two timeouts:
...
FAIL: gdb.python/py-breakpoint.exp: test_watchpoints: \
  Test watchpoint write (timeout)
FAIL: gdb.python/py-breakpoint.exp: test_bkpt_internal: \
  Test watchpoint write (timeout)
...

In this case, hw watchpoints are not supported, and using sw watchpoints
is slow.

Most of the time is spent in handling a try-catch, which triggers a malloc.  I
think this bit is more relevant for the "catch throw" part of the test-case,
so fix the timeouts by setting the watchpoints after the try-catch.

Tested on x86_64-linux and powerpc64le-linux.

Remove value_in

value_in is unused.  From git log, it seems to have been part of the
Chill language, which was removed from gdb eons ago.  This patch
removes the function.  Tested by rebuilding.

[gdb/testsuite] Fix gdb.rust/watch.exp on ppc64le

On x86_64-linux, I have:
...
(gdb) watch -location y^M
Hardware watchpoint 2: -location y^M
(gdb) PASS: gdb.rust/watch.exp: watch -location y
...
but on powerpc64le-linux, I run into:
...
(gdb) watch -location y^M
Watchpoint 2: -location y^M
(gdb) FAIL: gdb.rust/watch.exp: watch -location y
...
due to the regexp matching "Hardware watchpoint" but not "Watchpoint":
...
gdb_test "watch -location y" ".*watchpoint .* -location .*"
...

Fix this by making the regexp less restrictive.

Tested on x86_64-linux and powerpc64le-linux.

gdb: fix mi breakpoint-deleted notifications for thread-specific b/p

Background
----------

When a thread-specific breakpoint is deleted as a result of the
specific thread exiting the function remove_threaded_breakpoints is
called which sets the disposition of the breakpoint to
disp_del_at_next_stop and sets the breakpoint number to 0.  Setting
the breakpoint number to zero has the effect of hiding the breakpoint
from the user.  We also print a message indicating that the breakpoint
has been deleted.

It was brought to my attention during a review of another patch[1]
that setting a breakpoints number to zero will suppress the MI
breakpoint-deleted notification for that breakpoint, and indeed, this
can be seen to be true, in delete_breakpoint, if the breakpoint number
is zero, then GDB will not notify the breakpoint_deleted observer.

It seems wrong that a user created, thread-specific breakpoint, will
have a =breakpoint-created notification, but will not have a
=breakpoint-deleted notification.  I suspect that this is a bug.

[1] https://sourceware.org/pipermail/gdb-patches/2023-February/196560.html

The First Problem
-----------------

During my initial testing I wanted to see how GDB handled the
breakpoint after it's number was set to zero.  To do this I created
the testcase gdb.threads/thread-bp-deleted.exp.  This test creates a
worker thread, which immediately exits.  After the worker thread has
exited the main thread spins in a loop.

In GDB I break once the worker thread has been created and place a
thread-specific breakpoint, then use 'continue&' to resume the
inferior in non-stop mode.  The worker thread then exits, but the main
thread never stops - instead it sits in the spin.  I then tried to use
'maint info breakpoints' to see what GDB thought of the
thread-specific breakpoint.

Unfortunately, GDB crashed like this:

  (gdb) continue&
  Continuing.
  (gdb) [Thread 0x7ffff7c5d700 (LWP 1202458) exited]
  Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.
  maint info breakpoints
  ... snip some output ...

  Fatal signal: Segmentation fault
  ----- Backtrace -----
  0x5ffb62 gdb_internal_backtrace_1
          ../../src/gdb/bt-utils.c:122
  0x5ffc05 _Z22gdb_internal_backtracev
          ../../src/gdb/bt-utils.c:168
  0x89965e handle_fatal_signal
          ../../src/gdb/event-top.c:964
  0x8997ca handle_sigsegv
          ../../src/gdb/event-top.c:1037
  0x7f96f5971b1f ???
          /usr/src/debug/glibc-2.30-2-gd74461fa34/nptl/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
  0xe602b0 _Z15print_thread_idP11thread_info
          ../../src/gdb/thread.c:1439
  0x5b3d05 print_one_breakpoint_location
          ../../src/gdb/breakpoint.c:6542
  0x5b462e print_one_breakpoint
          ../../src/gdb/breakpoint.c:6702
  0x5b5354 breakpoint_1
          ../../src/gdb/breakpoint.c:6924
  0x5b58b8 maintenance_info_breakpoints
          ../../src/gdb/breakpoint.c:7009
  ... etc ...

As the thread-specific breakpoint is set to disp_del_at_next_stop, and
GDB hasn't stopped yet, then the breakpoint still exists in the global
breakpoint list.

The breakpoint will not show in 'info breakpoints' as its number is
zero, but it will show in 'maint info breakpoints'.

As GDB prints the breakpoint, the thread-id for the breakpoint is
printed as part of the 'stop only in thread ...' line.  Printing the
thread-id involves calling find_thread_global_id to convert the global
thread-id into a thread_info*.  Then calling print_thread_id to
convert the thread_info* into a string.

The problem is that find_thread_global_id returns nullptr as the
thread for the thread-specific breakpoint has exited.  The
print_thread_id assumes it will be passed a non-nullptr.  As a result
GDB crashes.

In this commit I've added an assert to print_thread_id (gdb/thread.c)
to check that the pointed passed in is not nullptr.  This assert would
have triggered in the above case before GDB crashed.

MI Notifications: The Dangers Of Changing A Breakpoint's Number
---------------------------------------------------------------

Currently the delete_breakpoint function doesn't trigger the
breakpoint_deleted observer for any breakpoint with the number zero.

There is a comment explaining why this is the case in the code; it's
something about watchpoints.  But I did consider just removing the 'is
the number zero' guard and always triggering the breakpoint_deleted
observer, figuring that I'd then fix the watchpoint issue some other
way.

But I realised this wasn't going to be good enough.  When the MI
notification was delivered the number would be zero, so any frontend
parsing the notifications would not be able to match
=breakpoint-deleted notification to the earlier =breakpoint-created
notification.

What this means is that, at the point the breakpoint_deleted observer
is called, the breakpoint's number must be correct.

MI Notifications: The Dangers Of Delaying Deletion
--------------------------------------------------

The test I used to expose the above crash also brought another problem
to my attention.  In the above test we used 'continue&' to resume,
after which a thread exited, but the inferior didn't stop.  Recreating
the same test in the MI looks like this:

  -break-insert -p 2 main
  ^done,bkpt={number="2",type="breakpoint",disp="keep",...<snip>...}
  (gdb)
  -exec-continue
  ^running
  *running,thread-id="all"
  (gdb)
  ~"[Thread 0x7ffff7c5d700 (LWP 987038) exited]\n"
  =thread-exited,id="2",group-id="i1"
  ~"Thread-specific breakpoint 2 deleted - thread 2 no longer in the thread list.\n"

At this point the we have a single thread left, which is still
running:

  -thread-info
  ^done,threads=[{id="1",target-id="Thread 0x7ffff7c5eb80 (LWP 987035)",name="thread-bp-delet",state="running",core="4"}],current-thread-id="1"
  (gdb)

Notice that we got the =thread-exited notification from GDB as soon as
the thread exited.  We also saw the CLI line from GDB, the line
explaining that breakpoint 2 was deleted.  But, as expected, we didn't
see the =breakpoint-deleted notification.

I say "as expected" because the number was set to zero.  But, even if
the number was not set to zero we still wouldn't see the
notification.  The MI notification is driven by the breakpoint_deleted
observer, which is only called when we actually delete the breakpoint,
which is only done the next time GDB stops.

Now, maybe this is fine.  The notification is delivered a little
late.  But remember, by setting the number to zero the breakpoint will
be hidden from the user, for example, the breakpoint is removed from
the MI's -break-info command output.

This means that GDB is in a position where the breakpoint doesn't show
up in the breakpoint table, but a =breakpoint-deleted notification has
not yet been sent out.  This doesn't seem right to me.

What this means is that, when the thread exits, we should immediately
be sending out the =breakpoint-deleted notification.  We should not
wait for GDB to next stop before sending the notification.

The Solution
------------

My proposed solution is this; in remove_threaded_breakpoints, instead
of setting the disposition to disp_del_at_next_stop and setting the
number to zero, we now just call delete_breakpoint directly.

The notification will now be sent out immediately; as soon as the
thread exits.

As the number has not changed when delete_breakpoint is called, the
notification will have the correct number.

And as the breakpoint is immediately removed from the breakpoint list,
we no longer need to worry about 'maint info breakpoints' trying to
print the thread-id for an exited thread.

My only concern is that calling delete_breakpoint directly seems so
obvious that I wonder why the original patch (that added
remove_threaded_breakpoints) didn't take this approach.  This code was
added in commit 49fa26b0411d, but the commit message offers no clues
to why this approach was taken, and the original email thread offers
no insights either[2].  There are no test regressions after making
this change, so I'm hopeful that this is going to be fine.

[2] https://sourceware.org/pipermail/gdb-patches/2013-September/106493.html

The Complication
----------------

Of course, it couldn't be that simple.

The script gdb.python/py-finish-breakpoint.exp had some regressions
during testing.

The problem was with the FinishBreakpoint.out_of_scope callback
implementation.  This callback is supposed to trigger whenever the
FinishBreakpoint goes out of scope; and this includes when the thread
for the breakpoint exits.

The problem I ran into is the Python FinishBreakpoint implementation.
Specifically, after this change I was loosing some of the out_of_scope
calls.

The problem is that the out_of_scope call (of which I'm interested) is
triggered from the inferior_exit observer.  Before my change the
observers were called in this order:

  thread_exit
  inferior_exit
  breakpoint_deleted

The inferior_exit would trigger the out_of_scope call.

After my change the breakpoint_deleted notification (for
thread-specific breakpoints) occurs earlier, as soon as the
thread-exits, so now the order is:

  thread_exit
  breakpoint_deleted
  inferior_exit

Currently, after the breakpoint_deleted call the Python object
associated with the breakpoint is released, so, when we get to the
inferior_exit observer, there's no longer a Python object to call the
out_of_scope method on.

My solution is to follow the model for how bpfinishpy_pre_stop_hook
and bpfinishpy_post_stop_hook are called, this is done from
gdbpy_breakpoint_cond_says_stop in py-breakpoint.c.

I've now added a new bpfinishpy_pre_delete_hook
gdbpy_breakpoint_deleted in py-breakpoint.c, and from this new hook
function I check and where needed call the out_of_scope method.

With this fix in place I now see the
gdb.python/py-finish-breakpoint.exp test fully passing again.

Testing
-------

Tested on x86-64/Linux with unix, native-gdbserver, and
native-extended-gdbserver boards.

New tests added to covers all the cases I've discussed above.

Approved-By: Pedro Alves <pedro@palves.net>

gdb/testsuite: fix failure in gdb.mi/mi-pending.exp with extended-remote

I currently see this failure when running the gdb.mi/mi-pending.exp
test using the native-extended-remote board:

  -break-insert -f -c x==4 mi-pendshr.c:pendfunc2
  &"No source file named mi-pendshr.c.\n"
  ^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="mi-pendshr.c:pendfunc2",cond="x==4",evaluated-by="host",times="0",original-location="mi-pendshr.c:pendfunc2"}
  (gdb)
  FAIL: gdb.mi/mi-pending.exp: MI pending breakpoint on mi-pendshr.c:pendfunc2 if x==4 (unexpected output)

The failure is caused by the 'evaluated-by="host"' string, which only
appears in the output when the test is run using the
native-extended-remote board.

I could fix this by just updating the pattern in
gdb.mi/mi-pending.exp, but I have instead updated mi-pending.exp to
make more use of the support procs in mi-support.exp.  This did
require making a couple of adjustments to mi-support.exp, but I think
the result is that mi-pending.exp is now easier to read, and I see no
failures with native-extended-remote anymore.

One of the test names has changed after this work, I think the old
test name was wrong - it described a breakpoint as pending when the
breakpoint was not pending, I suspect a copy & paste error.

But there's no changes to what is actually being tested after this
patch.

Approved-By: Pedro Alves <pedro@palves.net>

gdb/testsuite: introduce is_target_non_stop helper proc

I noticed that several tests included copy & pasted code to run the
'maint show target-non-stop' command, and then switch based on the
result.

In this commit I factor this code out into a helper proc in
lib/gdb.exp, and update all the places I could find that used this
pattern to make use of the helper proc.

There should be no change in what is tested after this commit.

Reviewed-By: Pedro Alves <pedro@palves.net>

gdb/testsuite introduce foreach_mi_ui_mode helper proc

Introduce foreach_mi_ui_mode, a helper proc which can be used when
tests are going to be repeated once with the MI in the main UI, and
once with the MI on a separate UI.

The proc is used like this:

  foreach_mi_ui_mode VAR {
    # BODY
  }

The BODY will be run twice, once with VAR set to 'main' and once with
VAR set to 'separate', inside BODY we can then change the behaviour
based on the current UI mode.

The point of this proc is that we sometimes shouldn't run the separate
UI tests (when gdb_debug_enabled is true), and this proc hides all
this logic.  If the separate UI mode should not be used then BODY will
be run just once with VAR set to 'main'.

I've updated two tests that can make use of this helper proc.  I'm
going to add another similar test in a later commit.

There should be no change to what is tested with this commit.

Approved-By: Pedro Alves <pedro@palves.net>

gdb/testsuite: extend the use of mi_clean_restart

The mi_clean_restart proc calls the mi_gdb_start proc passing no
arguments.

In this commit I add an extra (optional) argument to the
mi_clean_restart proc, and pass this through to mi_gdb_start.

The benefit of this is that we can now use mi_clean_restart when we
also want to pass the 'separate-mi-tty' or 'separate-inferior-tty'
flags to mi_gdb_start, and avoids having to otherwise duplicate the
contents of mi_clean_restart in different tests.

I've updated the obvious places where this new functionality can be
used, and I'm seeing no test regressions.

Reviewed-By: Pedro Alves <pedro@palves.net>

gdb/testsuite: make more use of mi-support.exp

Building on the previous commit, now that the breakpoint related
support functions in lib/mi-support.exp can now help creating the
patterns for thread specific breakpoints, make use of this
functionality for gdb.mi/mi-nsmoribund.exp and gdb.mi/mi-pending.exp.

There should be no changes in what is tested after this commit.

Reviewed-By: Pedro Alves <pedro@palves.net>

gdb: don't duplicate 'thread' field in MI breakpoint output

When creating a thread-specific breakpoint with a single location, the
'thread' field would be repeated in the MI output.  This can be seen
in two existing tests gdb.mi/mi-nsmoribund.exp and
gdb.mi/mi-pending.exp, e.g.:

  (gdb)
  -break-insert -p 1 bar
  ^done,bkpt={number="1",type="breakpoint",disp="keep",
      enabled="y",
      addr="0x000000000040110a",func="bar",
      file="/tmp/mi-thread-specific-bp.c",
      fullname="/tmp/mi-thread-specific-bp.c",
      line="32",thread-groups=["i1"],
      thread="1",thread="1",  <================ DUPLICATION!
      times="0",original-location="bar"}

I know we need to be careful when adjusting MI output, but I'm hopeful
in this case, as the field is duplicated, and the field contents are
always identical, that we might get away with removing one of the
duplicates.

The change in GDB is a fairly trivial condition change.

We did have a couple of tests that contained the duplicate fields in
their expected output, but given there was no comment pointing out
this oddity either in the GDB code, or in the test, I suspect this was
more a case of copying whatever output GDB produced and using that as
the expected results.  I've updated these tests to remove the
duplication.

I've update lib/mi-support.exp to provide support for building
breakpoint patterns that contain the thread field, and I've made use
of this in a new test I've added that is just about creating
thread-specific breakpoints and checking the results.  The two tests I
mentioned above as being updated could also use the new
lib/mi-support.exp functionality, but I'm going to do that in a later
patch, this way it is clear what changes I'm actually proposing to
make to the expected output.

As I said, I hope that frontends will be able to handle this change,
but I still think its worth adding a NEWS entry, that way, if someone
runs into problems, there's a chance they can figure out what's going
on.

This should not impact CLI output at all.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Pedro Alves <pedro@palves.net>

gdb: remove an out of date comment about disp_del_at_next_stop

Delete an out of date comment about disp_del_at_next_stop, the comment
says:

  /* NOTE drow/2003-09-08: This state only exists for removing
     watchpoints.  It's not clear that it's necessary...  */

I'm sure this was true when the comment was added, but today the
disp_del_at_next_stop state is not just used for deleting watchpoints,
which leaves us with "It's not clear that it's necessary...", which
doesn't really help at all.

And then this comment is located on one random place where
disp_del_at_next_stop is used, rather than at its definition site.

Lets just delete the comment.

No user visible changes after this commit.

Reviewed-By: Pedro Alves <pedro@palves.net>

[Aarch64] Add Binutils support for MEC

This change supports MEC which is part of RME (Realm Management Extension).

chew.c printf of intptr_t

Seen when building binutils with gcc -m32 on x86_64-linux.
chew.c: In function ‘print’:
chew.c:1434:59: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘intptr_t’ {aka ‘int’} [-Wformat=]
 1434 |     fprintf (stderr, "print: illegal print destination `%ld'\n", *isp);
      |                                                         ~~^      ~~~~
      |                                                           |      |
      |                                                           |      intptr_t {aka int}
      |                                                           long int
      |                                                         %d

* chew.c: Include inttypes.h.
(print): Use PRIdPTR for *isp.

ld: Sort section contributions in PDB files

Microsoft's DIA library, and thus also MSVC and WinDbg, expects section
contributions to be ordered by section number and offset, otherwise it's
unable to resolve line numbers.

Free ecoff debug info

This frees memory associated with the mips ecoff find_nearest_line.

* elfxx-mips.x (free_ecoff_debug): New function, extracted from..
(_bfd_mips_elf_read_ecoff_info): ..here.  Free ext_hdr earlier.
Don't clear already NULL fdr.
(struct mips_elf_find_line): Move earlier.
(_bfd_mips_elf_close_and_cleanup): Call free_ecoff_debug.
(_bfd_mips_elf_find_nearest_line): Likewise on error paths,
and to clean up input_debug when done.

Add some sanity checking in ECOFF lookup_line

More anti-fuzzer bounds checking for the ECOFF support.  A lot of this
is in ancient code using "long" for counts and sizes, which is why the
patch uses "(long) ((unsigned long) x + 1) > 0" in a few places.  The
unsigned long cast is so that "x + 1" doesn't trigger ubsan warnings
about signed integer overflow.  It would be a good idea to replace
most of the longs used in binutils with size_t, but that's more than I
care to do for COFF/ECOFF.

* ecofflink.c (mk_fdrtab): Sanity check string offsets.
(lookup_line): Likewise, and symbol indices.

Another PE SEC_HAS_CONTENTS test

I'd skipped this one before, thinking "obfd, that's the linker output
bfd so no need to test".  Wrong, this is objcopy output.

* peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Test
SEC_HAS_CONTENTS before reading section.

Automatic date update in version.in

Forced quit cases handled by resetting sync_quit_force_run

During my audit of the use of gdb_exception with regard to QUIT
processing, I found a try/catch in the scoped_switch_fork_info
destructor.

Static analysis found this call path from the destructor to
maybe_quit():

  scoped_switch_fork_info::~scoped_switch_fork_info()
    -> remove_breakpoints()
    -> remove_breakpoint(bp_location*)
    -> remove_breakpoint_1(bp_location*, remove_bp_reason)
    -> memory_validate_breakpoint(gdbarch*, bp_target_info*)
    -> target_read_memory(unsigned long, unsigned char*, long)
    -> target_read(target_ops*, target_object, char const*, unsigned char*, unsigned long, long)
    -> maybe_quit()

Since it's not safe to do a 'throw' from a destructor, we simply
call set_quit_flag and, for gdb_exception_forced_quit, also
set sync_quit_force_run.  This will cause the appropriate
exception to be rethrown at the next QUIT check.

Another case is the try / catch in tui_getc() in tui-io.c.  The
existing catch swallows the exception.  I've added a catch for
'gdb_exception_forced_quit', which also swallows the exception,
but also sets sync_quit_force_run and calls set_quit_flag in
order to restart forced quit processing at the next QUIT check.
This is required because it isn't safe to throw into/through
readline.

Thanks to Pedro Alves for suggesting this idea.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
Tested-by: Tom de Vries <tdevries@suse.de>
Approved-By: Pedro Alves <pedro@palves.net>

Introduce set_force_quit_flag and change type of sync_quit_force_run

At the moment, handle_sigterm() in event-top.c does the following:

  sync_quit_force_run = 1;
  set_quit_flag ();

This was used several more times in a later patch in this series, so
I'm introducing (at Pedro's suggestion) a new function named
'set_force_quit_flag'.  It simply sets sync_quit_force_run and also
calls set_quit_flag().  I've revised the later patch to call
set_force_quit_flag instead.

I noticed that sync_quit_force_run is declared as an int but is being
used as a bool, so I also changed its type to bool in this commit.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
Approved-By: Pedro Alves <pedro@palves.net>

QUIT processing w/ explicit throw for gdb_exception_forced_quit

This commit contains changes which have an explicit throw for
gdb_exception_forced_quit, or, in a couple of cases for gdb_exception,
but with a throw following a check to see if 'reason' is
RETURN_FORCED_QUIT.

Most of these are straightforward - it made sense to continue to allow
an existing catch of gdb_exception to also catch gdb_exception_quit;
in these cases, a catch/throw for gdb_exception_forced_quit was added.

There are two cases, however, which deserve a more detailed
explanation.

1) remote_fileio_request in gdb/remote-fileio.c:

The try block calls do_remote_fileio_request which can (in turn)
call one of the functions in remote_fio_func_map[].  Taking the
first one, remote_fileio_func_open(), we have the following call
path to maybe_quit():

  remote_fileio_func_open(remote_target*, char*)
    -> target_read_memory(unsigned long, unsigned char*, long)
    -> target_read(target_ops*, target_object, char const*, unsigned char*, unsigned long, long)
    -> maybe_quit()

Since there is a path to maybe_quit(), we must ensure that the
catch block is not permitted to swallow a QUIT representing a
SIGTERM.

However, for this case, we must take care not to change the way that
Ctrl-C / SIGINT is handled; we want to send a suitable EINTR reply to
the remote target should that happen.  That being the case, I added a
catch/throw for gdb_exception_forced_quit.  I also did a bit of
rewriting here, adding a catch for gdb_exception_quit in favor of
checking the 'reason' code in the catch block for gdb_exception.

2) mi_execute_command in gdb/mi/mi-main.c:

The try block calls captured_mi_execute_command(); there exists
a call path to maybe_quit():

  captured_mi_execute_command(ui_out*, mi_parse*)
    -> mi_cmd_execute(mi_parse*)
    -> get_current_frame()
    -> get_prev_frame_always_1(frame_info*)
    -> frame_register_unwind_location(frame_info*, int, int*, lval_type*, unsigned long*, int*)
    -> frame_register_unwind(frame_info*, int, int*, int*, lval_type*, unsigned long*, int*, unsigned char*)
    -> value_entirely_available(value*)
    -> value_fetch_lazy(value*)
    -> value_fetch_lazy_memory(value*)
    -> read_value_memory(value*, long, int, unsigned long, unsigned char*, unsigned long)
    -> maybe_quit()

That being the case, we can't allow the exception handler (catch block)
to swallow a gdb_exception_quit for SIGTERM.  However, it does seem
reasonable to output the exception via the mi interface so that some
suitable message regarding SIGTERM might be printed; therefore, I
check the exception's 'reason' field for RETURN_FORCED_QUIT and
do a throw for this case.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
Tested-by: Tom de Vries <tdevries@suse.de>
Approved-By: Pedro Alves <pedro@palves.net>

Guile QUIT processing updates

This commit contains QUIT processing updates for GDB's Guile support.
As with the Python updates, we don't want to permit this code to
swallow the exception, gdb_exception_forced_quit, which is associated
with GDB receiving a SIGTERM.

I've adopted the same solution that I used for Python; whereever
a gdb_exception is caught in try/catch code in the Guile extension
language support, a catch for gdb_exception_forced_quit has been
added; this catch block will simply call quit_force(), which will
cause the necessary cleanups to occur followed by GDB exiting.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
Tested-by: Tom de Vries <tdevries@suse.de>
Approved-By: Pedro Alves <pedro@palves.net>