opcodes: Remove i386-init.h and i386-tbl.h from HFILES

i386-init.h and i386-tbl.h are generated files.  There is nothing to
translate.  Remove them from HFILES (POTFILES).

* Makefile.am (HFILES): Remove i386-init.h and i386-tbl.h.
* Makefile.in: Regenerated.
* po/POTFILES.in: Likewise.

Avoid timeouts in gdb.compile

PR compile/29541 points out that some of the C++ tests in gdb.compile
will time out when the glibc debuginfo is installed.  This was
interfering with my hacking on gdb by making test runs extremely long,
so I looked into it.

Internally the bug seems to be that gdb tries to convert multiple
symbols named "var" via the compiler interface; one such symbol (I
didn't track it down too far) causes the C++ compiler plugin to crash.

Unfortunately, the crash is reported as a timeout, as the gdb side of
the plugin simply hangs.  This seems like a bug in the plugin RPC
mechanism and, worse, apparently when I wrote this stuff I didn't
really consider error reporting very much at all, so gdb can't really
detect failures in the first place.

Anyway... this patch works around the timeout by compiling a simple
test that should provoke this bug, and then using "untested" if it
notices a GCC crash.

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

Remove obsolete check from skip_compile_feature_tests

skip_compile_feature_tests checks for "Command not supported on this
host", but this error was removed by commit e8d8cce6 ("Import mkdtemp
gnulib module, fix mingw build").  This patch removes the obsolete
test.

Remove one copy of skip_compile_feature_tests

I noticed that there are two identical copies of
skip_compile_feature_tests in the test suite.  This removes one from
gdb.exp, in favor of the one in compile-support.exp.

binutils: improve holes detection in .debug_loclists.

The previous warnings about holes in .debug_loclists sections don't
take into account the headers of each CU and could include the locviews
if they precede the loclist.

The following warning can be triggered between two CU.
    ... <previous CU views> ...
    0000001d <End of list>

    0000002a v000000000000000 v000000000000000 location view pair
    0000002c v000000000000000 v000000000000000 location view pair

readelf: Warning: There is a hole [0x1e - 0x2e] in .debug_loclists section.
    0000002e v000000000000000 v000000000000000 views at 0000002a for:
    ...

But [0x1e - 0x2a] corresponds to the CU header and  [0x2a - 0x2e] are
the locviews.  Thus there is no hole here.

binutils/ChangeLog:

* dwarf.c (display_debug_loc): Adjust holes detections for
headers and locviews.

Fix verilog output when the width is > 1.

PR 25202
bfd * bfd.c (VerilogDataEndianness): New variable.
(verilog_write_record): Use VerilogDataEndianness, if set, to
choose the endianness of the output.
(verilog_write_section): Adjust the address by the data width.

binutils* objcopy.c (copy_object): Set VerilogDataEndianness to the
endianness of the input file.
(copy_main): Verifiy the value set by the --verilog-data-width
option.
* testsuite/binutils-all/objcopy.exp: Add tests of the new behaviour.
* testsuite/binutils-all/verilog-I4.hex: New file.

x86: rework of match_template()'s suffix checking

(Ab)using i386_opcode_modifier for this has been overkill, as the logic
doesn't really require the full structure. With the removal of
LONG_DOUBLE_MNEM_SUFFIX and No_ldSuf there's no good reason at all
anymore to pull out such a loop invariant: We're dealing a check of a
bit in the loop for a simple comparison. Do the original compares inside
the loop, thus also making it easier to understand what is actually
being checked.

x86: drop No_ldSuf

With LONG_DOUBLE_MNEM_SUFFIX gone there'salso no use for No_ldSuf
anymore.

x86/Intel: drop LONG_DOUBLE_MNEM_SUFFIX

With the removal of its use for FPU insns the suffix is now finally
properly misnamed. Drop its use altogether, replacing it by a separate
boolean instead.

x86/Intel: restrict use of LONG_DOUBLE_MNEM_SUFFIX

As a comment near the top of match_template() already says: We really
only need this pseudo-suffix for far branch handling. Stop "deriving" it
for floating point insns. (Don't bother renaming the now properly
misnamed LONG_DOUBLE_MNEM_SUFFIX, to e.g. FAR_BRANCH_SUFFIX - it's going
to disappear anyway.)

[gdb/testsuite] Wait longer for core generation

When I run the gdb testsuite on a powerpc64le-linux system with (slow) nfs
file system, I run into timeouts due to core generation, like for instance:
...
(gdb) gcore $outputs/gdb.ada/task_switch_in_core/crash.gcore^M
FAIL: gdb.ada/task_switch_in_core.exp: save a corefile (timeout)
...

Fix this by using with_timeout_factor 3 in gdb_gcore_cmd.

Tested on powerpc64le-linux.
Approved-By: Tom Tromey <tom@tromey.com>

[gdb/testsuite] Fix gdb.ada/float-bits.exp for powerpc64le

On powerpc64le-linux, I run into:
...
(gdb) print 16llf#4000921fb54442d18469898cc51701b8#^M
$9 = <invalid float value>^M
(gdb) FAIL: gdb.ada/float-bits.exp: print \
  16llf#4000921fb54442d18469898cc51701b8#
...

The problem is that we're using a hex string for the 128-bit IEEE quad long
double format, but the actual long double float format is:
...
gdbarch_dump: long_double_format = floatformat_ibm_long_double_little^M
...

Fix this by using the hex string obtained by compiling test.c:
...
long double a = 5.0e+25L;
...
like so:
...
$ gcc -mlittle test.c -c -g
...
and running gdb:
...
$ gdb -q -batch test.o -ex "p /x a"
$1 = 0xc1e1c000000000004544adf4b7320335
...
and likewise for -mbig:
...
$ gdb -q -batch test.o -ex "p /x a"
$1 = 0x4544adf4b7320335c1e1c00000000000
...

Tested on powerpc64le-linux.

I excercised the case of floatformat_ibm_long_double_big by
using "set endian big" in the test-case.

Note that for this patch to work correctly, recent commit aaa79cd62b8 ("[gdb]
Improve printing of float formats") is required.

PR testsuite/29816
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29816
Approved-By: Tom Tromey <tom@tromey.com>

Automatic date update in version.in

[gdb/testsuite] Fix DUPLICATEs in s390-multiarch.exp

On s390x-linux, I run into:
...
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
DUPLICATE: gdb.arch/s390-multiarch.exp: Linux v2
...

Fix this by using with_test_prefix.

Tested on s390x-linux.

[gdb/testsuite] Enable gdb.arch/s390-disassembler-options.exp for --enable-targets=all

On s390x-linux, I run into:
...
DUPLICATE: gdb.arch/s390-disassembler-options.exp: \
  show disassembler-options esa
...

First, reproduce this on x86_64-linux with --enable-targets=all, by replacing
the test for 'istarget "s390*-*-*"' with a test for 'get_set_option_choices
"set architecture" "s390"'.

Fix the DUPLICATE by using with_test_prefix.

Also modernize the test-case by using clean_restart instead of gdb_exit/gdb_start.

Tested on x86_64-linux.

section-select: Fix exclude-file-3

this testcase wasn't correctly testing everything, it passed, even
though sections from an excluded file were included.  Fixing this
reveals a problem in the new section selector.  This fixes that as
well.

section-select: Remove unused code

walk_wild_file, hence walk_wild_section and walk_wild_section_handler
aren't called with the prefix tree.  Hence initialization of the latter
and all potential special cases for it aren't used anymore.  That also
removes the need to handler_data[] and some associated helper functions.
So, remove all of that.

section-select: Implement a prefix-tree

Now that we have a list of potentially matching sections per wild
statement we can actually pre-fill that one by going once over all input
sections and match their names against a prefix-tree that points to the
potentially matching wild statements.

So instead of looking at all sections names for each glob for each wild
statement we now look at the sections only once and then only check
against those globs that have a possibility of a match at all (usually
only one or two).

This pushes the whole section selection off the profiles.

section-select: Completely rebuild matches

The check_relocs callback (and others) might have created new
section behind our back and some of them (e.g. on powerpc the
"linker stubs" .got) need to come in front of all others, despite
being created late (a symptom would be "TOC opt*" failing on powerpc).

This resets all section matches before updating for newly created
sections (i.e. completely rebuilds the matches).

section-select: Lazily resolve section matches

and remember the results.  Before this the order of section matching
is basically:

  foreach script-wild-stmt S
    foreach pattern P of S
      foreach inputfile I
        foreach section S of I
  match S against P
    if match: do action for S

And this process is done three or four times: for each top-level call to
walk_wild() or wild(), that is: check_input_sections, lang_gc_sections,
lang_find_relro_sections and of course map_input_to_output_sections.

So we iterate over all sections of all files many many times (for each
glob).  Reality is a bit more complicated (some special glob types don't
need the full iteration over all sections, only over all files), but
that's the gist of it.

For future work this shuffles the whole ordering a bit by lazily doing
the matching process and memoizing results, trading a little memory for
a 75% speedup of the overall section selection process.

This lazy resolution introduces a problem with sections added late
that's corrected in the next patch.

Bounds check access to Ada task state names

While looking into Ada tasking a little, I noticed that no bounds
checking is done on accesses to the Ada task state names arrays.  This
isn't a problem currently, but if the runtime ever added numbers -- or
if there was some kind of runtime corruption -- it could cause a gdb
crash.

This patch adds range checking.  It also adds a missing _() call when
printing from the 'task_states' array.

Use ui_file_up in mi_interp

This changes mi_interp to use ui_file_up rather than explicit
management.

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

Rename fields of cli_interp_base::saved_output_files

This renames the fields of cli_interp_base::saved_output_files, as
requested by Simon.  I tried to choose names that more obviously
reflect what the field is used for.  I also added a couple of
comments.

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

[gdb] Improve printing of float formats

Currently, on x86_64, a little endian target, I get:
...
$ gdb -q -batch -ex "maint print architecture" | grep " = floatformat"
gdbarch_dump: bfloat16_format = floatformat_bfloat16_big
gdbarch_dump: double_format = floatformat_ieee_double_big
gdbarch_dump: float_format = floatformat_ieee_single_big
gdbarch_dump: half_format = floatformat_ieee_half_big
gdbarch_dump: long_double_format = floatformat_i387_ext
...
which suggests big endian.

This is due to this bit of code in pformat:
...
    /* Just print out one of them - this is only for diagnostics.  */
    return format[0]->name;
...

Fix this by using gdbarch_byte_order to pick the appropriate index, such that
we have the more accurate:
...
gdbarch_dump: bfloat16_format = floatformat_bfloat16_little
gdbarch_dump: half_format = floatformat_ieee_half_little
gdbarch_dump: float_format = floatformat_ieee_single_little
gdbarch_dump: double_format = floatformat_ieee_double_little
gdbarch_dump: long_double_format = floatformat_i387_ext
...

Tested on x86_64-linux.

Correct ordering problem in comm-data.exp

* testsuite/ld-elf/comm-data.exp: Build libcomm-data.so before
attempting to read it to set ELF64.

regen SRC-POTFILES.in

x86/Intel: adjustment to restricted suffix derivation

In "x86/Intel: restrict suffix derivation" I think I screwed up
slightly, bringing a piece of code out of sync with its comment, and
resulting in a suffix potentially being derived when one isn't needed.

x86: clean up after removal of support for gcc <= 2.8.1

At the very least a comment in process_operands() is stale. Beyond that
there are effectively two options:
1) It is possible that FADDP and FMULP were mistakenly not marked as
   being in need of dealing with the compiler anomaly, and hence the
   respective templates weren't removed at the time when they should
   have been.
2) It is also possible that there are indeed uses known beyond compiler
   generated output for these two commutative opcodes, and hence the
   templates need to stay.
To be on the safe side assume 2: Update the comment and fold the
templates into their "normal" ones (utilizing D), adjusting consuming
code accordingly.

For FMULP also add a comment paralleling a similar one FADDP has.

x86: drop FloatR

There are just 4 templates using it, which can be easily identified by
other means, as D is set only on a very limited number of FPU templates.
Also move the respective conditional out of the code path taken by all
"reverse match" insns (it probably should have been this way already
before, to avoid the one conditional in the common case).

With this the templates which had FloatR dropped no longer differ from
their AT&T syntax + mnemonic counterparts - the only difference is now
which of the two would be recognized. For this, however, we don't need
two templates - we can simply arrange the condition for setting
Opcode_FloatR accordingly.

x86: extend FPU test coverage for AT&T / Intel mnemonic differences

Before touching the templates, let's ensure we actually cover things:
For one FSUB{,R} and FDIV{,R} would better be tested with operands in
both possible orders. And then -mmnemonic=intel wasn't tested at all.

src-release.sh: Fix gdb source tarball build failure due to libsframe

This script was recently changed as follow:

    | commit e619dddb3a45780ae66d762756882a3b896b617d
    | Date:   Tue Nov 15 15:07:13 2022 -0800
    | Subject: src-release.sh: Add libsframe
    |
    | Add libsframe to the list of top level directories that will be included
    | in a release.

Since then, the gdb source tarball has been failing with the error
below during the "make configure-host configure-target" phase:

    | make[3]: *** No rule to make target '../libsframe/libsframe.la',
    |     needed by 'libbfd.la'.  Stop.
    | make[3]: Leaving directory '/tmp/gdb-public/bfd'

This patch fixes the issue by adding libsframe to the list of
GDB_SUPPORT_DIRS, similar to what was done for BINUTILS.

ChangeLog:

        * src-release.sh (GDB_SUPPORT_DIRS): Add libsframe.

Automatic date update in version.in

[gdb/testsuite] Fix gdb.base/vla-optimized-out.exp for ppc64le

On powerpc64le-linux, I run into:
...
(gdb) PASS: gdb.base/vla-optimized-out.exp: o1: printed optimized out vla
p sizeof (a)^M
$2 = <optimized out>^M
(gdb) FAIL: gdb.base/vla-optimized-out.exp: o1: \
  printed size of optimized out vla
...

The problem happens as follows.

In order to find the size of the optimized out vla, gdb needs to evaluate:
...
<155> DW_AT_upper_bound : 13 byte block: f3 1 53 23 1 8 20 24 8 20 26 31 1c \
  (DW_OP_GNU_entry_value: (DW_OP_reg3 (r3)); DW_OP_plus_uconst: 1;
   DW_OP_const1u: 32; DW_OP_shl; DW_OP_const1u: 32; DW_OP_shra; DW_OP_lit1;
   DW_OP_minus)
...

When trying to evaluate DW_OP_GNU_entry_value, it looks for a call site
matching the pc, but doesn't find it:
...
$ gdb -q -batch outputs/gdb.base/vla-optimized-out/vla-optimized-out-o1 \
  -ex "break f1" -ex run -ex "set debug entry-values 1" -ex "print sizeof (a)"
Breakpoint 1 at 0x1000067c: file vla-optimized-out.c, line 34.

Breakpoint 1, f1 (i=5) at vla-optimized-out.c:34
34      }
DW_OP_entry_value resolving cannot find DW_TAG_call_site 0x100006b0 in main
$1 = <optimized out>
....

The call site lookup fails because the call site label .LVL4:
...
        bl f1    # 11   *call_value_nonlocal_aixdi      [length = 8]
        nop
.LVL4:
...
is not placed directly after the bl insn.  This is gcc PR target/107909.

However, after manually fixing the .s file we have instead:
...
Cannot find matching parameter at DW_TAG_call_site 0x10000690 at main
$1 = <optimized out>
...
due to the fact that the call site has no call site parameters.

The call site does have a reference to the corresponding function f1, with
parameter i, for which we find location list entries:
...
  0037 1000067c 10000680 (DW_OP_reg3 (r3))
  004a 10000680 10000690 (DW_OP_GNU_entry_value: (DW_OP_reg3 (r3));
                          DW_OP_stack_value)
...
and we could use the fact that the current pc is in the 1000067c-10000680
range, and that that the range starts at the start of the function, to deduce
that DW_OP_GNU_entry_value: (DW_OP_reg3 (r3)) == DW_OP_reg3 (r3).
But that's a non-trivial enhancement, filed as enhancement PR symtab/29836.

Fix this by allowing <optimized out> for target powerpc and the gcc compiler.

Reviewed-By: Carl Love <cel@us.ibm.com>
Tested-By: Carl Love <cel@us.ibm.com>
PR testsuite/29813
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29813

gdb/testsuite: make gdb_unload use gdb_test_multiple

In the failure seen by Philippe here:

  https://inbox.sourceware.org/gdb-patches/20221120173024.3647464-1-philippe.waroquiers@skynet.be/

gdb_unload crashed GDB, leaving no trace in the test results.  Change it
to use gdb_test_multiple, so that it leaves an UNRESOLVED result.  I
think it is good practice anyway.

Make it return the result of gdb_test_multiple directly, change
gdb.python/py-objfile.exp accordingly.

Change gdb.base/endian.exp as well to avoid duplicate test names.

Change gdb.base/gnu-debugdata.exp to avoid recording a test result,
since gdb_unload does it already now.

Change-Id: I59a1e4947691330797e6ce23277942547c437a48
Approved-By: Tom de Vries <tdevries@suse.de>

gdb/testsuite: make gdb_test_multiple return immediately if send_gdb fails

In the failure seen by Philippe here:

  https://inbox.sourceware.org/gdb-patches/20221120173024.3647464-1-philippe.waroquiers@skynet.be/

... the testsuite only outputs PASSes, and an ERROR, resulting from an
uncaught exception.  This is a bit sneaky, because ERRORs are not
reported in the test summary.  In certain circumstances, it can be easy
to miss.

Normally, gdb_test_multiple outputs an UNRESOLVED when GDB crashes.  But
this is only if it manages to send the command, and it's that command
that crashes GDB.  Here, the ERROR is due to the fact that GDB had
already crashed by the time we entered gdb_test_multiple and tried to
send a command.  GDB was crashed by the previous "file" command, sent by
gdb_unload.  Because gdb_unload uses bare expect, it didn't record a
test failure when crashing GDB (this will be addressed separately).

In this patch, I propose to make gdb_test_multiple call unresolved
directly and return -1 send_gdb fails.  This way, if GDB is already
crashed by the time we enter gdb_test_multiple, it will leave a trace in
the test results in the form of an UNRESOLVED.  It will also spare us
the not-so-useful-in-my-opinion TCL backtrace.

Before, it looks like:

    ERROR: Couldn't send python print(objfile.filename) to GDB.
    ERROR: : spawn id exp9 not open
        while executing
    "expect {
    -i exp9 -timeout 10
            -re ".*A problem internal to GDB has been detected" {
                fail "$message (GDB internal error)"
                gdb_internal_error..."
        ("uplevel" body line 1)
        invoked from within
    "uplevel $body" NONE : spawn id exp9 not open

And after:

    Couldn't send python print(objfile.filename) to GDB.
    UNRESOLVED: gdb.python/py-objfile.exp: objfile.filename after objfile is unloaded

Change-Id: I72af8dc0d687826fc3f76911c27a9e5f91b677ba
Approved-By: Tom de Vries <tdevries@suse.de>

gprofng: remove unused gprofng/src/DbeSession.cc.1

xtensa: allow dynamic configuration

Import include/xtensa-dynconfig.h that defines XCHAL_* macros as fields
of a structure returned from the xtensa_get_config_v<x> function call.
Define that structure and fill it with default parameter values
specified in the include/xtensa-config.h.
Define reusable function xtensa_load_config that tries to load
configuration and return an address of an exported object from it.
Define functions xtensa_get_config_v{1,2} that use xtensa_load_config
to get structures xtensa_config_v{1,2}, either dynamically configured
or the default.

bfd/
* Makefile.am (BFD32_BACKENDS, BFD32_BACKENDS_CFILES): Append
xtensa-dynconfig.c.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac (xtensa_elf32_be_vec, xtensa_elf32_le_vec): Add
xtensa-dynconfig.lo to the tb.
* elf32-xtensa.c (xtensa-config.h): Replace #include with
xtensa-dynconfig.h.
(XSHAL_ABI, XTHAL_ABI_WINDOWED, XTHAL_ABI_CALL0): Remove
definitions.
* xtensa-dynconfig.c: New file.
* xtensa-isa.c (xtensa-dynconfig.h): New #include.
(xtensa_get_modules): New function.
(xtensa_isa_init): Call xtensa_get_modules instead of taking
address of global xtensa_modules.

gas/
* config/tc-xtensa.c (xtensa-config.h): Replace #include with
xtensa-dynconfig.h.
(XTHAL_ABI_WINDOWED, XTHAL_ABI_CALL0, XTENSA_MARCH_EARLIEST):
Remove definitions.
* config/tc-xtensa.h (xtensa-config.h): Replace #include with
xtensa-dynconfig.h.
* config/xtensa-relax.c (xtensa-config.h): Replace #include with
xtensa-dynconfig.h.
(XCHAL_HAVE_WIDE_BRANCHES): Remove definition.

include/
* xtensa-dynconfig.h: New file.

ld/
* emultempl/xtensaelf.em (xtensa-config.h): Replace #include
with xtensa-dynconfig.h.
(XTHAL_ABI_WINDOWED, XTHAL_ABI_CALL0): Remove definitions.

Automatic date update in version.in

gdb/testsuite: remove use of then keyword from library files

The canonical form of 'if' in modern TCL is 'if {} {}'.  But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.

This commit removes all use of the 'then' keyword from the testsuite
library files (in boards/, config/, and lib/).  Previous commits have
removed all uses of the 'then' keyword from the test script files,
this commit just cleans up the library files.

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

gdb/testsuite: remove use of then keyword from gdb.*/*.exp scripts

The canonical form of 'if' in modern TCL is 'if {} {}'.  But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.

This commit removes all use of the 'then' keyword from the remaining
gdb.*/*.exp scripts.  Previous commits have done the bulk of this
removal, this commit just handles the remaining directories that each
contain a low number of instances.

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

gdb/testsuite: remove use of then keyword from gdb.multi/*.exp

The canonical form of 'if' in modern TCL is 'if {} {}'.  But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.

This commit removes all use of the 'then' keyword from the gdb.multi/
test script directory.

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

gdb/testsuite: remove use of then keyword from gdb.fortran/*.exp

The canonical form of 'if' in modern TCL is 'if {} {}'.  But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.

This commit removes all use of the 'then' keyword from the gdb.fortran/
test script directory.

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

gdb/testsuite: remove use of then keyword from gdb.disasm/*.exp

The canonical form of 'if' in modern TCL is 'if {} {}'.  But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.

This commit removes all use of the 'then' keyword from the gdb.disasm/
test script directory.

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

gdb/testsuite: remove use of then keyword from gdb.reverse/*.exp

The canonical form of 'if' in modern TCL is 'if {} {}'.  But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.

This commit removes all use of the 'then' keyword from the gdb.reverse/
test script directory.

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

gdb/testsuite: remove use of then keyword from gdb.trace/*.exp

The canonical form of 'if' in modern TCL is 'if {} {}'.  But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.

This commit removes all use of the 'then' keyword from the gdb.trace/
test script directory.

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

gdb/testsuite: remove use of then keyword from gdb.threads/*.exp

The canonical form of 'if' in modern TCL is 'if {} {}'.  But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.

This commit removes all use of the 'then' keyword from the gdb.threads/
test script directory.

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

gdb/testsuite: remove use of then keyword from gdb.python/*.exp

The canonical form of 'if' in modern TCL is 'if {} {}'.  But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.

This commit removes all use of the 'then' keyword from the gdb.python/
test script directory.

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

gdb/testsuite: remove use of then keyword from gdb.cp/*.exp

The canonical form of 'if' in modern TCL is 'if {} {}'.  But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.

This commit removes all use of the 'then' keyword from the gdb.cp/
test script directory.

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

gdb/testsuite: remove use of then keyword from gdb.arch/*.exp

The canonical form of 'if' in modern TCL is 'if {} {}'.  But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.

This commit removes all use of the 'then' keyword from the gdb.arch/
test script directory.

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

gdb/testsuite: remove use of then keyword from gdb.base/*.exp

The canonical form of 'if' in modern TCL is 'if {} {}'.  But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.

This commit removes all use of the 'then' keyword from the gdb.base/
test script directory.

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

gdb/testsuite: remove use of then keyword from gdb.ada/*.exp

The canonical form of 'if' in modern TCL is 'if {} {}'.  But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.

This commit removes all use of the 'then' keyword from the gdb.ada/
test script directory.

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

gdb/testsuite: remove DOS line endings from a test script

The gdb.fortran/nested-funcs.exp test script has DOS line endings.  I
can see no reason why this script needs DOS line endings.

Convert to UNIX line endings.

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

Don't let gdb_stdlog use pager

When using the "set logging" commands, cli_interp_base::set_logging
will send gdb_stdlog output (among others) to the tee it makes for
gdb_stdout.  However, this has the side effect of also causing logging
to use the pager.  This is PR gdb/29787.

This patch fixes the problem by keeping stderr and stdlog separate
from stdout, preserving the rule that only gdb_stdout should page.

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

Don't let tee_file own a stream

Right now, tee_file owns the second stream it writes to.  This is done
for the convenience of the users.  In a subsequent patch, this will no
longer be convenient, so this patch moves the responsibility for
ownership to the users of tee_file.

Remove 'saved_output' global

CLI redirect uses a global variable, 'saved_output'.  However, globals
are generally bad, and there is no need for this one -- it can be a
member of cli_interp_base.  This patch makes this change.

Remove no longer used jump label

The out label is unused since wait_for_debug_event is in a different thread.

Actually set m_is_async to current async mode

Looks like this was missed in the async mode implementation.

Don't use auto for lambda parameter

Older gcc versions (here 4.9.2) can't handle auto for a lambda parameter:

../../gdb/windows-nat.c: In member function 'void windows_nat_target::delete_thread(ptid_t, DWORD, bool)':
../../gdb/windows-nat.c:629:12: error: use of 'auto' in lambda parameter declaration only available with -std=c++1y or -std=gnu++1y [-Werror]
        [=] (auto &th)
            ^

Fix calling convention of thread entry point

For i686 the CreateThread entry point function needs the WINAPI (stdcall)
calling convention:

../../gdb/windows-nat.c: In constructor 'windows_nat_target::windows_nat_target()':
../../gdb/windows-nat.c:450:56: error: invalid user-defined conversion from 'windows_nat_target::windows_nat_target()::<lambda(LPVOID)>' to 'LPTHREAD_START_ROUTINE' {aka 'long unsigned int (__attribute__((stdcall)) *)(void*)'} [-fpermissive]
  450 |   HANDLE bg_thread = CreateThread (nullptr, 64 * 1024, fn, this, 0, nullptr);
      |                                                        ^~
../../gdb/windows-nat.c:444:13: note: candidate is: 'constexpr windows_nat_target::windows_nat_target()::<lambda(LPVOID)>::operator DWORD (*)(LPVOID)() const' (near match)
  444 |   auto fn = [] (LPVOID self) -> DWORD
      |             ^
../../gdb/windows-nat.c:444:13: note:   no known conversion from 'DWORD (*)(LPVOID)' {aka 'long unsigned int (*)(void*)'} to 'LPTHREAD_START_ROUTINE' {aka 'long unsigned int (__attribute__((stdcall)) *)(void*)'}

Since it's not possible to change the calling convention of a lambda, I've
moved it to a separate function.

gdb: mark disassembler function callback types as noexcept

In disasm.h we define a set of types that are used by the various
disassembler classes to hold callback functions before passing the
callbacks into libopcodes.

Because libopcodes is C code, and on some (many?) targets, C code is
compiled without exception support, it is important that GDB not try
to throw an exception over libopcode code.

In the previous commit all the existing callbacks were marked as
noexcept, however, this doesn't protect us from a future change to GDB
either adding a new callback that is not noexcept, or removing the
noexcept keyword from an existing callback.

In this commit I mark all the callback types as noexcept.  This means
that GDB's disassembler classes will no longer compile if we try to
pass a callback that is not marked as noexcept.

At least, that's the idea.  Unfortunately, it's not that easy.

Before C++17, the noexcept keyword on a function typedef would be
ignored, thus:

  using func_type = void (*) (void) noexcept;

  void
  a_func ()
  {
    throw 123;
  }

  void
  some_func (func_type f)
  {
    f ();
  }

  int
  main ()
  {
    some_func (a_func);
    return 0;
  }

Will compile just fine for C++11 and C++14 with GCC.  Clang on the
other hand complains that 'noexcept' should not appear on function
types, but then does appear to correctly complain that passing a_func
is a mismatch in the set of exceptions that could be thrown.

Switching to C++17 and both GCC and Clang correctly point out that
passing a_func is an invalid conversion relating to the noexcept
keyword.  Changing a_func to:

  void
  a_func () noexcept
  { /* Nothing.  */ }

And for C++17 both GCC and Clang compile this just fine.

My conclusion then is that adding the noexcept keyword to the function
types is pointless while GDB is not compiled as C++17, and silencing
the warnings would require us to jump through a bunch of hoops.

And so, in this commit, I define a macro LIBOPCODE_CALLBACK_NOEXCEPT,
this macro expands to noexcept when compiling for C++17, but otherwise
expands to nothing.  I then add this macro to the function types.

I've compiled GDB as the default C++11 and also forced the compile to
C++17.  When compiling as C++17 I spotted a few additional places
where callbacks needed to be marked noexcept (these fixes were merged
into the previous commit, but this confirmed to be that the macro is
working as expected).

gdb/disasm: mark functions passed to the disassembler noexcept

While working on another patch, Simon pointed out that GDB could be
improved by marking the functions passed to the disassembler as
noexcept.

  https://sourceware.org/pipermail/gdb-patches/2022-October/193084.html

The reason this is important is the on some hosts, libopcodes, being C
code, will not be compiled with support for handling exceptions.  As
such, an attempt to throw an exception over libopcodes code will cause
GDB to terminate.

See bug gdb/29712 for an example of when this happened.

In this commit all the functions that are passed to the disassembler,
and which might be used as callbacks by libopcodes are marked
noexcept.

Ideally, I would have liked to change these typedefs:

  using read_memory_ftype = decltype (disassemble_info::read_memory_func);
  using memory_error_ftype = decltype (disassemble_info::memory_error_func);
  using print_address_ftype = decltype (disassemble_info::print_address_func);
  using fprintf_ftype = decltype (disassemble_info::fprintf_func);
  using fprintf_styled_ftype = decltype (disassemble_info::fprintf_styled_func);

which are declared in disasm.h, as including the noexcept keyword.
However, when I tried this, I ran into this warning/error:

  In file included from ../../src/gdb/disasm.c:25:
  ../../src/gdb/disasm.h: In constructor ‘gdb_printing_disassembler::gdb_printing_disassembler(gdbarch*, ui_file*, gdb_disassemble_info::read_memory_ftype, gdb_disassemble_info::memory_error_ftype, gdb_disassemble_info::print_address_ftype)’:
  ../../src/gdb/disasm.h:116:3: error: mangled name for ‘gdb_printing_disassembler::gdb_printing_disassembler(gdbarch*, ui_file*, gdb_disassemble_info::read_memory_ftype, gdb_disassemble_info::memory_error_ftype, gdb_disassemble_info::print_address_ftype)’ will change in C++17 because the exception specification is part of a function type [-Werror=noexcept-type]
    116 |   gdb_printing_disassembler (struct gdbarch *gdbarch,
        |   ^~~~~~~~~~~~~~~~~~~~~~~~~

So I've left that change out.  This does mean that if somebody adds a
new use of the disassembler classes in the future, and forgets to mark
the callbacks as noexcept, this will compile fine.  We'll just have to
manually check for that during review.

gdb/python: avoid throwing an exception over libopcodes code

Bug gdb/29712 identifies a problem with the Python disassembler API.
In some cases GDB will try to throw an exception through the
libopcodes disassembler code, however, not all targets include
exception unwind information when compiling C code, for targets that
don't include this information GDB will terminate when trying to pass
the exception through libopcodes.

To explain what GDB is trying to do, consider the following trivial
use of the Python disassembler API:

  class ExampleDisassembler(gdb.disassembler.Disassembler):

      class MyInfo(gdb.disassembler.DisassembleInfo):
          def __init__(self, info):
              super().__init__(info)

          def read_memory(self, length, offset):
              return super().read_memory(length, offset)

      def __init__(self):
          super().__init__("ExampleDisassembler")

      def __call__(self, info):
          info = self.MyInfo(info)
          return gdb.disassembler.builtin_disassemble(info)

This disassembler doesn't add any value, it defers back to GDB to do
all the actual work, but it serves to allow us to discuss the problem.

The problem occurs when a Python exception is raised by the
MyInfo.read_memory method.  The MyInfo.read_memory method is called
from the C++ function gdbpy_disassembler::read_memory_func.  The C++
stack at the point this function is called looks like this:

  #0  gdbpy_disassembler::read_memory_func (memaddr=4198805, buff=0x7fff9ab9d2a8 "\220ӹ\232\377\177", len=1, info=0x7fff9ab9d558) at ../../src/gdb/python/py-disasm.c:510
  #1  0x000000000104ba06 in fetch_data (info=0x7fff9ab9d558, addr=0x7fff9ab9d2a9 "ӹ\232\377\177") at ../../src/opcodes/i386-dis.c:305
  #2  0x000000000104badb in ckprefix (ins=0x7fff9ab9d100) at ../../src/opcodes/i386-dis.c:8571
  #3  0x000000000104e28e in print_insn (pc=4198805, info=0x7fff9ab9d558, intel_syntax=-1) at ../../src/opcodes/i386-dis.c:9548
  #4  0x000000000104f4d4 in print_insn_i386 (pc=4198805, info=0x7fff9ab9d558) at ../../src/opcodes/i386-dis.c:9949
  #5  0x00000000004fa7ea in default_print_insn (memaddr=4198805, info=0x7fff9ab9d558) at ../../src/gdb/arch-utils.c:1033
  #6  0x000000000094fe5e in i386_print_insn (pc=4198805, info=0x7fff9ab9d558) at ../../src/gdb/i386-tdep.c:4072
  #7  0x0000000000503d49 in gdbarch_print_insn (gdbarch=0x5335560, vma=4198805, info=0x7fff9ab9d558) at ../../src/gdb/gdbarch.c:3351
  #8  0x0000000000bcc8c6 in disasmpy_builtin_disassemble (self=0x7f2ab07f54d0, args=0x7f2ab0789790, kw=0x0) at ../../src/gdb/python/py-disasm.c:324

  ### ... snip lots of frames as we pass through Python itself ...

  #22 0x0000000000bcd860 in gdbpy_print_insn (gdbarch=0x5335560, memaddr=0x401195, info=0x7fff9ab9e3c8) at ../../src/gdb/python/py-disasm.c:783
  #23 0x00000000008995a5 in ext_lang_print_insn (gdbarch=0x5335560, address=0x401195, info=0x7fff9ab9e3c8) at ../../src/gdb/extension.c:939
  #24 0x0000000000741aaa in gdb_print_insn_1 (gdbarch=0x5335560, vma=0x401195, info=0x7fff9ab9e3c8) at ../../src/gdb/disasm.c:1078
  #25 0x0000000000741bab in gdb_disassembler::print_insn (this=0x7fff9ab9e3c0, memaddr=0x401195, branch_delay_insns=0x0) at ../../src/gdb/disasm.c:1101

So gdbpy_disassembler::read_memory_func is called from the libopcodes
disassembler to read memory, this C++ function then calls into user
supplied Python code to do the work.

If the user supplied Python code raises an gdb.MemoryError exception
indicating the memory read failed, this is fine.  The C++ code
converts this exception back into a return value that libopcodes can
understand, and returns to libopcodes.

However, if the user supplied Python code raises some other exception,
what we want is for this exception to propagate through GDB and appear
as if raised by the call to gdb.disassembler.builtin_disassemble.  To
achieve this, when gdbpy_disassembler::read_memory_func spots an
unknown Python exception, we must pass the information about this
exception from frame #0 to frame #8 in the above backtrace.  Frame #8
is the C++ implementation of gdb.disassembler.builtin_disassemble, and
so it is this function that we want to re-raise the unknown Python
exception, so the user can, if they want, catch the exception in their
code.

The previous mechanism by which the exception was passed was to pack
the details of the Python exception into a C++ exception, then throw
the exception from frame #0, and catch the exception in frame #8,
unpack the details of the Python exception, and re-raise it.

However, this relies on the exception passing through frames #1 to #7,
some of which are in libopcodes, which is C code, and so, might not be
compiled with exception support.

This commit proposes an alternative solution that does not rely on
throwing a C++ exception.

When we spot an unhandled Python exception in frame #0, we will store
the details of this exception within the gdbpy_disassembler object
currently in use.  Then we return to libopcodes a value indicating
that the memory_read failed.

libopcodes will now continue to disassemble as though that memory read
failed (with one special case described below), then, when we
eventually return to disasmpy_builtin_disassemble we check to see if
there is an exception stored in the gdbpy_disassembler object.  If
there is then this exception can immediately be installed, and then we
return back to Python, when the user will be able to catch the
exception.

There is one extra change in gdbpy_disassembler::read_memory_func.
After the first call that results in an exception being stored on the
gdbpy_disassembler object, any future calls to the ::read_memory_func
function will immediately return as if the read failed.  This avoids
any additional calls into user supplied Python code.

My thinking here is that should the first call fail with some unknown
error, GDB should not keep trying with any additional calls.  This
maintains the illusion that the exception raised from
MyInfo.read_memory is immediately raised by
gdb.disassembler.builtin_disassemble.  I have no tests for this change
though - to trigger this issue would rely on a libopcodes disassembler
that will try to read further memory even after the first failed
read.  I'm not aware of any such disassembler that currently does
this, but that doesn't mean such a disassembler couldn't exist in the
future.

With this change in place the gdb.python/py-disasm.exp test should now
pass on AArch64.

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

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

Remove reset_ecs and execution_control_state::reset

I noticed that execution_control_state has a 'reset' method, and
there's also a 'reset_ecs' function that calls it.  This patch cleans
this area up a little by adding a parameter to the constructor and (a
change Simon suggested) removing the reset method.  Some extraneous
variables are also removed, like:

-      struct execution_control_state ecss;
-      struct execution_control_state *ecs = &ecss;

Here 'ecs' is never changed, so this patch removes it entirely in
favor of just using the object everywhere.

Regression tested on x86-64 Fedora 34.

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

gdb: relax requirement for the map_failed stap probe to be present

From glibc 2.35 and later, the "map_failed" stap probe is no longer
included in glibc.  The removal of the probe looks like an accident,
but it was caused by a glibc commit which meant that the "map_failed"
probe could no longer be reached; the compiler then helpfully
optimised out the probe.

In GDB, in solib-svr4.c, we have a list of probes that we look for
related to the shared library loading detection.  If any of these
probes are missing then GDB will fall back to the non-probe based
mechanism for detecting shared library loading.  The "map_failed"
probe is include in the list of required probes.

This means that on glibc 2.35 (or later) systems, GDB is going to
always fall back to the non-probes based mechanism for detecting
shared library loading.

I raised a glibc bug to discuss this issue:

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

But, whatever the ultimate decision from the glibc team, given there
are version of glibc in the wild without the "map_failed" probe, we
probably should update GDB to handle this situation.

The "map_failed" probe is already a little strange, very early
versions of glibc didn't include this probe, so, in some cases, if
this probe is missing GDB is happy to ignore it.  This is fine, the
action associated with this probe inside GDB is DO_NOTHING, this means
the probe isn't actually required in order for GDB to correctly detect
the loading of shared libraries.

In this commit I propose changing the rules so that any probe whose
action is DO_NOTHING, is optional.

There is one possible downside to this change, and that concerns 'set
stop-on-solib-events on'.  If a probe is removed from glibc, but the
old style breakpoint based mechanism is still in place within glibc
for that same event, then GDB will stop when using the old style
non-probe based mechanism, but not when using the probes based
mechanism.

For the map_failed case this is not a problem, both the map_failed
probe, and the call to the old style breakpoint location were
optimised out, and so neither event (probes based, or breakpoint
based) will trigger.  This would only become an issue if glibc removed
a probe, but left the breakpoint in place (this would almost certainly
be a bug in glibc).

For now, I'm proposing that we just don't worry about this.  Because
some probes have actions that are not DO_NOTHING, then we know the
user will always seem _some_ stops when a shared library is
loaded/unloaded, and (I'm guessing), in most cases, that's all they
care about.  I figure when someone complains then we can figure out
what the right solution is then.

With this commit in place, then, when using a glibc 2.35 or later
system, GDB will once again use the stap probes for shared library
detection.

Reviewed-By: Lancelot SIX <lancelot.six@amd.com>

[gdb/testsuite] Require hw watchpoint in gdb.ada/task_watch.exp

On powerpc64le-linux I run into:
...
(gdb) PASS: gdb.ada/task_watch.exp: info tasks before inserting breakpoint
watch -location value task 3^M
Watchpoint 2: -location value^M
(gdb) PASS: gdb.ada/task_watch.exp: watch -location value task 3
continue^M
Continuing.^M
[Thread 0x7ffff7ccf170 (LWP 65550) exited]^M
[Thread 0x7ffff7abf170 (LWP 65551) exited]^M
FAIL: gdb.ada/task_watch.exp: continue to watchpoint (timeout)
...

On x86_64-linux (where the test-case passes), a hardware watchpoint is used:
...
(gdb) PASS: gdb.ada/task_watch.exp: info tasks before inserting breakpoint
watch -location value task 3^M
Hardware watchpoint 2: -location value^M
...
and after forcing "set can-use-hw-watchpoints 0" we can intermittently
reproduce the same failure.

In the gdb documentation related to watchpoints in multi-threaded programs, we
read:
...
Warning: In multi-threaded programs, software watchpoints have only limited
usefulness.  If GDB creates a software watchpoint, it can only watch the value
of an expression in a single thread.  If you are confident that the expression
can only change due to the current thread’s activity (and if you are also
confident that no other thread can become current), then you can use software
watchpoints as usual.  However, GDB may not notice when a non-current thread’s
activity changes the expression.  (Hardware watchpoints, in contrast, watch an
expression in all threads.)
...

Since the ada task construct is mapped onto threads, it seems that the
same limitation holds for tasks.

Fix this by using skip_hw_watchpoint_tests.

Tested on powerpc64-linux.
Tested-By: Carl Love <cel@us.ibm.com>

[gdb/testsuite] Fix gdb.ada/out_of_line_in_inlined.exp for ppc64le

On powerpc64le-linux, with test-case gdb.ada/out_of_line_in_inlined.exp I run
into:
...
(gdb) run ^M
Starting program: foo_o224_021-all ^M
^M
Breakpoint 1, 0x0000000010002f48 in foo_o224_021.child1.child2 (s=...) at \
  foo_o224_021.adb:24^M
24              function Child2 (S : String) return Boolean is -- STOP^M
(gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: \
  run to foo_o224_021.child1.child2
...

The breakpoint is correctly set at the local entry point, and given that the
local entry point doesn't correspond to a line number entry, the instruction
address of the breakpoint is shown.

The problem is that test-case doesn't expect the breakpoint address.

Fix this by allowing the breakpoint address to occur.

Tested on powerpc64le-linux.

Only use wild_sort_fast

there's no reason why the tree-based variant can't always be used
when sorting is required, it merely needs to also support filename
sorting and have a fast path for insertion at end (aka rightmost tree
leaf).

The filename sorting isn't tested anywhere and the only scripttempl
that uses it is avr (for 'SORT(*)(.ctors)'), and I believe even there it
was a mistake.  Either way, this adds a testcase for filename sorting as
well.

Then the non-BST based sorting can be simplified to only support
the fast case of no sorting required at all (at the same time renaming
the two variants to _sort and _nosort).

Special case more simple patterns

fnmatch is slow, so avoiding it in more cases is good.  This implements
a more generic version of match_simple_wild which needs some
pre-processing of patterns.  In particular it supports patterns of the
form PREFIX*SUFFIX (where all parts are optional), i.e. a super set of
what's handled now.  Most section matchers of this form and hence don't
need any calls to fnmatch anymore.

We retain the implementation of match_simple_wild for the filename
matchers (they aren't called often enough to matter).

gdb/testsuite: fail if gdb_start_cmd fails

I broke gdb.ada/start.exp, and did not notice it, because it outputs an
UNTESTED if gdb_start_cmd fails.  I don't really see when start would
fail and it's not a problem that should be looked at.  Change all spots
that call untested after a gdb_start_cmd failure, use fail instead.

Doing so caused some failures with the native-gdbserver board.  Some
tests that use "start" were relying on the fact that start would fail
with that board to just return with "untested".  Change them to add an
early return if use_gdb_stub returns true.

Some gdb.pascal tests also failed with native-gdbserver, because they
did use gdb_start_cmd to start the inferior, for no good reason.
Convert them to use runto_main instead, which does the right thing if
the target is a stub.

A further refactoring could be to make gdb_start_cmd match the expected
breakpoint hit and the prompt, which it doesn't do currently (it leaves
that to the callers, but not all of them do).

Change-Id: I097370851213e798ff29fb6cf8ba25ef7d2be007
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>

Fix range type signed-ness heuristic

The code to create a range type has a heuristic to decide whether the
range is unsigned.  However, this heuristic can fail if the upper
bound of the range has its high bit set, because the test is done
using LONGEST.

With this patch, if the underlying type of a range is unsigned, then
the range will always be unsigned.  A new test is included.

Regression tested on x86-64 Fedora 34.  We've also been using this
internally at AdaCore for a while.

gdb: disable commit resumed in target_kill

New in this version:

 - Better comment in target_kill
 - Uncomment line in test to avoid hanging when exiting, when testing on
   native-extended-gdbserver

PR 28275 shows that doing a sequence of:

 - Run inferior in background (run &)
 - kill that inferior
 - Run again

We get into this assertion:

    /home/smarchi/src/binutils-gdb/gdb/target.c:2590: internal-error: target_wait: Assertion `!proc_target->commit_resumed_state' failed.

    #0  internal_error_loc (file=0x5606b344e740 "/home/smarchi/src/binutils-gdb/gdb/target.c", line=2590, fmt=0x5606b344d6a0 "%s: Assertion `%s' failed.") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:54
    #1  0x00005606b6296475 in target_wait (ptid=..., status=0x7fffb9390630, options=...) at /home/smarchi/src/binutils-gdb/gdb/target.c:2590
    #2  0x00005606b5767a98 in startup_inferior (proc_target=0x5606bfccb2a0 <the_amd64_linux_nat_target>, pid=3884857, ntraps=1, last_waitstatus=0x0, last_ptid=0x0) at /home/smarchi/src/binutils-gdb/gdb/nat/fork-inferior.c:482
    #3  0x00005606b4e6c9c5 in gdb_startup_inferior (pid=3884857, num_traps=1) at /home/smarchi/src/binutils-gdb/gdb/fork-child.c:132
    #4  0x00005606b50f14a5 in inf_ptrace_target::create_inferior (this=0x5606bfccb2a0 <the_amd64_linux_nat_target>, exec_file=0x604000039f50 "/home/smarchi/build/binutils-gdb/gdb/test", allargs="", env=0x61500000a580, from_tty=1)
        at /home/smarchi/src/binutils-gdb/gdb/inf-ptrace.c:105
    #5  0x00005606b53b6d23 in linux_nat_target::create_inferior (this=0x5606bfccb2a0 <the_amd64_linux_nat_target>, exec_file=0x604000039f50 "/home/smarchi/build/binutils-gdb/gdb/test", allargs="", env=0x61500000a580, from_tty=1)
        at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:978
    #6  0x00005606b512b79b in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at /home/smarchi/src/binutils-gdb/gdb/infcmd.c:468
    #7  0x00005606b512c236 in run_command (args=0x0, from_tty=1) at /home/smarchi/src/binutils-gdb/gdb/infcmd.c:526

When running the kill command, commit_resumed_state for the
process_stratum_target (linux-nat, here) is true.  After the kill, when
there are no more threads, commit_resumed_state is still true, as
nothing touches this flag during the kill operation.  During the
subsequent run command, run_command_1 does:

    scoped_disable_commit_resumed disable_commit_resumed ("running");

We would think that this would clear the commit_resumed_state flag of
our native target, but that's not the case, because
scoped_disable_commit_resumed iterates on non-exited inferiors in order
to find active process targets.  And after the kill, the inferior is
exited, and the native target was unpushed from it anyway.  So
scoped_disable_commit_resumed doesn't touch the commit_resumed_state
flag of the native target, it stays true.  When reaching target_wait, in
startup_inferior (to consume the initial expect stop events while the
inferior is starting up and working its way through the shell),
commit_resumed_state is true, breaking the contract saying that
commit_resumed_state is always false when calling the targets' wait
method.

(note: to be correct, I think that startup_inferior should toggle
commit_resumed between the target_wait and target_resume calls, but I'll
ignore that for now)

I can see multiple ways to fix this.  In the end, we need
commit_resumed_state to be cleared by the time we get to that
target_wait.  It could be done at the end of the kill command, or at the
beginning of the run command.

To keep things in a coherent state, I'd like to make it so that after
the kill command, when the target is left with no threads, its
commit_resumed_state flag is left to false.  This way, we can keep
working with the assumption that a target with no threads (and therefore
no running threads) has commit_resumed_state == false.

Do this by adding a scoped_disable_commit_resumed in target_kill.  It
clears the target's commit_resumed_state on entry, and leaves it false
if the target does not have any resumed thread on exit.  That means,
even if the target has another inferior with stopped threads,
commit_resumed_state will be left to false, which makes sense.

Add a test that tries to cover various combinations of actions done
while an inferior is running (and therefore while commit_resumed_state
is true on the process target).

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28275
Change-Id: I8e6fe6dc1f475055921520e58cab68024039a1e9
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdbserver: switch to right process in find_one_thread

New in this version: add a dedicated test.

When I do this:

    $ ./gdb -nx --data-directory=data-directory -q \
        /bin/sleep \
-ex "maint set target-non-stop on" \
-ex "tar ext :1234" \
-ex "set remote exec-file /bin/sleep" \
-ex "run 1231 &" \
-ex add-inferior \
-ex "inferior 2"
    Reading symbols from /bin/sleep...
    (No debugging symbols found in /bin/sleep)
    Remote debugging using :1234
    Starting program: /bin/sleep 1231
    Reading /lib64/ld-linux-x86-64.so.2 from remote target...
    warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
    Reading /lib64/ld-linux-x86-64.so.2 from remote target...
    Reading /usr/lib/debug/.build-id/a6/7a1408f18db3576757eea210d07ba3fc560dff.debug from remote target...
    [New inferior 2]
    Added inferior 2 on connection 1 (extended-remote :1234)
    [Switching to inferior 2 [<null>] (<noexec>)]
    (gdb) Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target...
    attach 3659848
    Attaching to process 3659848
    /home/smarchi/src/binutils-gdb/gdb/thread.c:85: internal-error: inferior_thread: Assertion `current_thread_ != nullptr' failed.

Note the "attach" command just above.  When doing it on the command-line
with a -ex switch, the bug doesn't trigger.

The internal error of GDB is actually caused by GDBserver crashing, and
the error recovery of GDB is not on point.  This patch aims to fix just
the GDBserver crash, not the GDB problem.

GDBserver crashes with a segfault here:

    (gdb) bt
    #0  0x00005555557fb3f4 in find_one_thread (ptid=...) at /home/smarchi/src/binutils-gdb/gdbserver/thread-db.cc:177
    #1  0x00005555557fd5cf in thread_db_thread_handle (ptid=<error reading variable: Cannot access memory at address 0xffffffffffffffa0>, handle=0x7fffffffc400, handle_len=0x7fffffffc3f0)
        at /home/smarchi/src/binutils-gdb/gdbserver/thread-db.cc:461
    #2  0x000055555578a0b6 in linux_process_target::thread_handle (this=0x5555558a64c0 <the_x86_target>, ptid=<error reading variable: Cannot access memory at address 0xffffffffffffffa0>, handle=0x7fffffffc400,
        handle_len=0x7fffffffc3f0) at /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:6905
    #3  0x00005555556dfcc6 in handle_qxfer_threads_worker (thread=0x60b000000510, buffer=0x7fffffffc8a0) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:1645
    #4  0x00005555556e00e6 in operator() (__closure=0x7fffffffc5e0, thread=0x60b000000510) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:1696
    #5  0x00005555556f54be in for_each_thread<handle_qxfer_threads_proper(buffer*)::<lambda(thread_info*)> >(struct {...}) (func=...) at /home/smarchi/src/binutils-gdb/gdbserver/gdbthread.h:159
    #6  0x00005555556e0242 in handle_qxfer_threads_proper (buffer=0x7fffffffc8a0) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:1694
    #7  0x00005555556e04ba in handle_qxfer_threads (annex=0x629000000213 "", readbuf=0x621000019100 '\276' <repeats 200 times>..., writebuf=0x0, offset=0, len=4097)
        at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:1732
    #8  0x00005555556e1989 in handle_qxfer (own_buf=0x629000000200 "qXfer:threads", packet_len=26, new_packet_len_p=0x7fffffffd630) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:2045
    #9  0x00005555556e720a in handle_query (own_buf=0x629000000200 "qXfer:threads", packet_len=26, new_packet_len_p=0x7fffffffd630) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:2685
    #10 0x00005555556f1a01 in process_serial_event () at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4176
    #11 0x00005555556f4457 in handle_serial_event (err=0, client_data=0x0) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4514
    #12 0x0000555555820f56 in handle_file_event (file_ptr=0x607000000250, ready_mask=1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:573
    #13 0x0000555555821895 in gdb_wait_for_event (block=1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:694
    #14 0x000055555581f533 in gdb_do_one_event (mstimeout=-1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:264
    #15 0x00005555556ec9fb in start_event_loop () at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3512
    #16 0x00005555556f0769 in captured_main (argc=4, argv=0x7fffffffe0d8) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3992
    #17 0x00005555556f0e3f in main (argc=4, argv=0x7fffffffe0d8) at /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4078

The reason is a wrong current process when find_one_thread is called.
The current process is the 2nd one, which was just attached.  It does
not yet have thread_db data (proc->priv->thread_db is nullptr).  As we
iterate on all threads of all process to fulfull the qxfer:threads:read
request, we get to a thread of process 1 for which we haven't read
thread_db information yet (lwp_info::thread_known is false), so we get
into find_one_thread.  find_one_thread uses
`current_process ()->priv->thread_db`, assuming the current process
matches the ptid passed as a parameter, which is wrong.  A segfault
happens when trying to dereference that thread_db pointer.

Fix this by making find_one_thread not assume what the current process /
current thread is.  If it needs to call into libthread_db, which we know
will try to read memory from the current process, then temporarily set
the current process.

In the case where the thread is already know and we return early, we
don't need to switch process.

Add a test to reproduce this specific situation.

Change-Id: I09b00883e8b73b7e5f89d0f47cb4e9c0f3d6caaa
Approved-By: Andrew Burgess <aburgess@redhat.com>

Fix crash in "document" command

PR cli/29800 points out that "document" will now crash when the
argument is an undefined command.  This is a regression due to the
"document user-defined aliases" patch.

Approved-By: Joel Brobecker <brobecker@adacore.com>
Reviewed-By: Philippe Waroquiers <philippe.waroquiers@skynet.be>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29800

[gdb/testsuite] Fix gdb.opt/solib-intra-step.exp for powerpc64le

On powerpc64le-linux, I run into:
...
(gdb) PASS: gdb.opt/solib-intra-step.exp: first-hit
step^M
28      { /* first-retry */^M
(gdb) FAIL: gdb.opt/solib-intra-step.exp: second-hit
...

It's a bit easier to understand what happens if we do a full stepping session:
...
Temporary breakpoint 1, main ()
    at solib-intra-step-main.c:23
23        shlib_first ();
(gdb) step
shlib_first () at solib-intra-step-lib.c:29
29        shlib_second (0); /* first-hit */
(gdb) step
28      { /* first-retry */
(gdb) step
29        shlib_second (0); /* first-hit */
(gdb) step
shlib_second (dummy=0)
    at solib-intra-step-lib.c:23
23        abort (); /* second-hit */
...
and compare that to the line info:
...
CU: solib-intra-step-lib.c:
File name                    Line number    Starting address    View    Stmt
solib-intra-step-lib.c                22               0x710               x
solib-intra-step-lib.c                23               0x724               x
solib-intra-step-lib.c                28               0x740               x
solib-intra-step-lib.c                29               0x74c               x
solib-intra-step-lib.c                28               0x750               x
solib-intra-step-lib.c                29               0x758               x
solib-intra-step-lib.c                30               0x760               x
solib-intra-step-lib.c                 -               0x77c
...

So we step from line 29 to line 28, and back to line 29, which is behaviour
that matches the line table.  The peculiar order is due to using optimization.
The problem is that the test-case doesn't expect this order.

Fix this by allowing this order in the test-case.

Tested on powerpc64le-linux.

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

gdb: fix assert when quitting GDB while a thread is stepping

This commit addresses one of the issues identified in PR gdb/28275.

Bug gdb/28275 identifies a number of situations in which this assert:

  Assertion `!proc_target->commit_resumed_state' failed.

could be triggered.  There's actually a number of similar places where
this assert is found in GDB, the two of interest in gdb/28275 are in
target_wait and target_stop.

In one of the comments:

  https://sourceware.org/bugzilla/show_bug.cgi?id=28275#c1

steps to trigger the assertion within target_stop were identified when
using a modified version of the gdb.threads/detach-step-over.exp test
script.

In the gdb.threads/detach-step-over.exp test, we attach to a
multi-threaded inferior, and continue the inferior in asynchronous
(background) mode.  Each thread is continuously hitting a conditional
breakpoint where the condition is always false.  While the inferior is
running we detach.  The goal is that we detach while GDB is performing a
step-over for the conditional breakpoint in at least one thread.

While detaching, if a step-over is in progress, then GDB has to
complete the step over before we can detach.  This involves calling
target_stop and target_wait (see prepare_for_detach).

As far as gdb/28275 is concerned, the interesting part here, is the
the process_stratum_target::commit_resumed_state variable must be
false when target_stop and target_wait are called.

This is currently ensured because, in detach_command (infrun.c), we
create an instance of scoped_disable_commit_resumed, this ensures that
when target_detach is called, ::commit_resumed_state will be false.

The modification to the test that I propose here, and which exposed
the bug, is that, instead of using "detach" to detach from the
inferior, we instead use "quit".  Quitting GDB after attaching to an
inferior will cause GDB to first detach, and then exit.

When we quit GDB we end up calling target_detach via a different code
path, the stack looks like:

  #0 target_detach
  #1 kill_or_detach
  #2 quit_force
  #3 quit_command

Along this path there is no scoped_disable_commit_resumed created.
::commit_resumed_state can be true when we reach prepare_for_detach,
which calls target_wait and target_stop, so the assertion will trigger.

In this commit, I propose fixing this by adding the creation of a
scoped_disable_commit_resumed into target_detach.  This will ensure
that ::commit_resumed_state is false when calling prepare_for_detach
from within target_detach.

I did consider placing the scoped_disable_commit_resumed in
prepare_for_detach, however, placing it in target_detach ensures that
the target's commit_resumed_state flag is left to false if the detached
inferior was the last one for that target.  It's the same rationale as
for patch "gdb: disable commit resumed in target_kill" that comes later
in this series, but for detach instead of kill.

detach_command still includes a scoped_disable_commit_resumed too, but I
think it is still relevant to cover the resumption at the end of the
function.

Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28275
Change-Id: Ie128f7aba6ef0e018859275eca372e6ea738e96f

gdb/testsuite: refactor gdb.threads/detach-step-over.exp

Factor out some bits of gdb.threads/detach-step-over.exp to procs in
preparation to adding some new variations of the test.  Rename the
existing "test" proc and make it use proc_with_prefix.

Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ib4412545c81c8556029e0f7bfa9dd48d7a9f3189

gdb/testsuite: remove global declarations in gdb.threads/detach-step-over.exp

Before doing further changes to this file, change to use the :: notation
instead of declaring global variables with the `global` keyword.

Change-Id: I72301fd8f4693fea61aac054ba17245a1f4442fb
Approved-By: Andrew Burgess <aburgess@redhat.com>

[gdb/testsuite] Fix gdb.arch/altivec-regs.exp with gcc 4.8.5

On powerpc64le-linux, using gcc 4.8.5, I run into:
...
(gdb) PASS: gdb.arch/altivec-regs.exp: next (1)
next^M
11        c = vec_add (a, b);^M
(gdb) PASS: gdb.arch/altivec-regs.exp: next (2)
print/x a^M
$67 = {0xfefefefe, 0xfefefefe, 0xfefefefe, 0xfefefefe}^M
(gdb) FAIL: gdb.arch/altivec-regs.exp: print vector parameter a
...

Looking at the disassembly and the debug info, it's clear why there's
a FAIL.

The debug info says that the variable can be found at some stack location, but
the instructions don't seem to be writing there.

We can work around this by marking variable a volatile.  Likewise for b.

Note that marking the variables as volatile doesn't change the location
information.

Tested on power64le-linux.

[gdb/tdep] Fix gdb.base/msym-bp-shl.exp for ppc64le

With test-case gdb.base/msym-bp-shl.exp on powerpc64le-linux, I run into:
...
(gdb) PASS: gdb.base/msym-bp-shl.exp: debug=0: before run: break foo
info breakpoint^M
Num     Type           Disp Enb Address            What^M
1       breakpoint     keep y   <MULTIPLE>         ^M
1.1                         y   0x00000000000008d4 <foo+12>^M
1.2                         y   0x0000000000000a34 crti.S:88^M
(gdb) FAIL: gdb.base/msym-bp-shl.exp: debug=0: before run: info breakpoint
...

The problem is that the prologue skipper walks from foo@plt at 0xa28 to 0xa34:
...
0000000000000a28 <foo@plt>:
 a28:   c0 ff ff 4b     b       9e8 <__glink_PLTresolve>

Disassembly of section .fini:

0000000000000a2c <_fini>:
 a2c:   02 00 4c 3c     addis   r2,r12,2
 a30:   d4 74 42 38     addi    r2,r2,29908
 a34:   a6 02 08 7c     mflr    r0
...

This is caused by ppc_elfv2_elf_make_msymbol_special which marks foo@plt as
having a local entry point, due to incorrectly accessing an asymbol struct
using a (larger) elf_symbol_type.

Fix this by simply ignoring artificial symbols in
ppc_elfv2_elf_make_msymbol_special.

Tested on powerpc64le.

Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
Reviewed-By: Carl Love <cel@us.ibm.com>
Tested-By: Carl Love <cel@us.ibm.com>
PR tdep/29814
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29814

PR10368, ISO 8859 mentioned as 7bit encoding in strings documentation

PR 10368
* doc/binutils.texi (strings): Delete example of 7-bit encoding.

Use bfd_rename_section in msp430.em

* emultempl/msp430.em (add_region_prefix <REGION_EITHER>): Use
bfd_rename_section.
* testsuite/ld-msp430-elf/msp430-tiny-rom.ld: Handle varian data
and bss input sections.

asan: pef: buffer overflow

* pef.c (bfd_pef_parse_traceback_table): Correct size moved when
stripping leading dot.

regen gas/Makefile.in

RISC-V: Allow merging 'H' extension

Because riscv_merge_std_ext function did not merge the 'H' extension, linked
executables lacked 'H' extension when multiple objects are merged.

This issue is found while building OpenSBI with 'H' extension (resulting
ELF files did not contain "h1p0" in "Tag_RISCV_arch" even if *all* linked
object files contained it).

This commit adds 'h' to standard_exts variable to merge 'H' extension.

bfd/ChangeLog:

* elfnn-riscv.c (riscv_merge_std_ext): Add 'H' extension merging.

RISC-V: Better support for long instructions (tests)

This commit tests both (assembler and disassembler) fixes of "Better support
for long instructions".

gas/ChangeLog:

* testsuite/gas/riscv/insn.s: Add testcases such that big number
handling is required and should be disassembled as long ".byte"
sequence with correct instruction bits.
* testsuite/gas/riscv/insn.d: Likewise.
* testsuite/gas/riscv/insn-na.d: Likewise.
* testsuite/gas/riscv/insn-dwarf.d: Likewise.

RISC-V: Better support for long instructions (assembler)

Commit bb996692bd96 ("RISC-V/gas: allow generating up to 176-bit
instructions with .insn") tried to start supporting long instructions but
it was insufficient.

1.  It heavily depended on the bignum internals (radix of 2^16),
2.  It generates "value conflicts with instruction length" even if a big
    number instruction encoding does not exceed its expected length and
3.  Because long opcode was handled separately (from struct riscv_cl_insn),
    some information like DWARF line number correspondence was missing.

To resolve these problems, this commit:

1.  Handles bignum (and its encodings) precisely and
2.  Incorporates long opcode handling into regular instruction handling.

This commit will be tested on the separate commit.

gas/ChangeLog:

* config/tc-riscv.c (struct riscv_cl_insn): Add long opcode field.
(create_insn) Clear long opcode marker.
(install_insn) Install longer opcode as well.
(s_riscv_insn) Likewise.
(riscv_ip_hardcode): Make big number handling stricter. Length and
the value conflicts only if the bignum size exceeds the expected
maximum length.

RISC-V: Better support for long instructions (disassembler)

Commit bb996692bd96 ("RISC-V/gas: allow generating up to 176-bit
instructions with .insn") tried to start supporting long instructions but
it was insufficient.

On the disassembler, correct ".byte" output was limited to the first 64-bits
of an instruction.  After that, zeroes are incorrectly printed.

Note that, it only happens on ".byte" output (instruction part) and not on
hexdump (data) part.  For example, before this commit, hexdump and ".byte"
produces different values:

Assembly:
  .insn 22, 0xfedcba98765432100123456789abcdef55aa33cc607f
objdump output example (before the fix):
  10:   607f 33cc 55aa cdef     .byte   0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
  18:   89ab 4567 0123 3210
  20:   7654 ba98 fedc

Note that, after 0xcd (after first 64-bits of the target instruction), all
".byte" values are incorrectly printed as zero while hexdump prints correct
instruction bits.

To resolve this, this commit adds "packet" argument to support dumping
instructions longer than 64-bits (to print correct instruction bits on
".byte").  This commit will be tested on the separate commit.

Assembly:
  .insn 22, 0xfedcba98765432100123456789abcdef55aa33cc607f
objdump output example (after the fix):
  10:   607f 33cc 55aa cdef     .byte   0x7f, 0x60, 0xcc, 0x33, 0xaa, 0x55, 0xef, 0xcd, 0xab, 0x89, 0x67, 0x45, 0x23, 0x01, 0x10, 0x32, 0x54, 0x76, 0x98, 0xba, 0xdc, 0xfe
  18:   89ab 4567 0123 3210
  20:   7654 ba98 fedc

opcodes/ChangeLog:

* riscv-dis.c (riscv_disassemble_insn): Print unknown instruction
using the new argument packet.
(riscv_disassemble_data): Add unused argument packet.
(print_insn_riscv): Pass packet to the disassemble function.

Automatic date update in version.in

Fix leak in the dwarf reader

Valgrind reports a leak in the dwarf reader (see details below).
The function dw2_get_file_names_reader is interning in the per_objfile
all the file names it finds, except the name of 'fnd file name and directory'.
Instead, it was xstrdup-ing the name.
Fix the leaks by also interning the name.

This was validated running the tests natively, and under valgrind.
Leaks have decreased as mentionned below.
Valgrind detected no error such as double free or use after free.

Stack trace of the leak:
==4113266== 490,735 bytes in 17,500 blocks are definitely lost in loss record 7,061 of 7,074
==4113266==    at 0x483979B: malloc (vg_replace_malloc.c:393)
==4113266==    by 0x25A454: xmalloc (alloc.c:57)
==4113266==    by 0x7D1E1E: xstrdup (xstrdup.c:34)
==4113266==    by 0x39D141: dw2_get_file_names_reader (read.c:2825)
==4113266==    by 0x39D141: dw2_get_file_names(dwarf2_per_cu_data*, dwarf2_per_objfile*) (read.c:2851)
==4113266==    by 0x39DD6C: dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>) (read.c:4149)
==4113266==    by 0x3BC8B5: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18688)
==4113266==    by 0x5DD1EA: objfile::map_symtabs_matching_filename(char const*, char const*, gdb::function_view<bool (symtab*)>) (symfile-debug.c:207)
==4113266==    by 0x5F04CC: iterate_over_symtabs(char const*, gdb::function_view<bool (symtab*)>) (symtab.c:633)
==4113266==    by 0x477EE3: collect_symtabs_from_filename(char const*, program_space*) (linespec.c:3712)
==4113266==    by 0x477FC1: symtabs_from_filename(char const*, program_space*) (linespec.c:3726)
==4113266==    by 0x47A9B8: convert_explicit_location_spec_to_linespec(linespec_state*, linespec*, char const*, char const*, symbol_name_match_type, char const*, line_offset) (linespec.c:2329)
==4113266==    by 0x47E86E: convert_explicit_location_spec_to_sals (linespec.c:2388)
==4113266==    by 0x47E86E: location_spec_to_sals(linespec_parser*, location_spec const*) (linespec.c:3104)
==4113266==    by 0x47EDAC: decode_line_full(location_spec*, int, program_space*, symtab*, int, linespec_result*, char const*, char const*) (linespec.c:3149)
...

Without the fix, the top 10 leaks are:
./gdb/testsuite/outputs/gdb.base/condbreak-bad/gdb.log:345:==3213924==    definitely lost: 130,937 bytes in 5,409 blocks
./gdb/testsuite/outputs/gdb.base/hbreak2/gdb.log:619:==3758919==    definitely lost: 173,323 bytes in 7,204 blocks
./gdb/testsuite/outputs/gdb.mi/mi-var-cp/gdb.log:1320:==4152873==    definitely lost: 172,826 bytes in 7,207 blocks
./gdb/testsuite/outputs/gdb.base/advance-until-multiple-locations/gdb.log:398:==2992643==    definitely lost: 172,965 bytes in 7,211 blocks
./gdb/testsuite/outputs/gdb.mi/mi-var-cmd/gdb.log:2302:==4159476==    definitely lost: 173,129 bytes in 7,211 blocks
./gdb/testsuite/outputs/gdb.cp/gdb2384/gdb.log:222:==3811851==    definitely lost: 218,106 bytes in 7,761 blocks
./gdb/testsuite/outputs/gdb.cp/mb-templates/gdb.log:310:==3787344==    definitely lost: 290,311 bytes in 10,340 blocks
./gdb/testsuite/outputs/gdb.mi/mi-var-rtti/gdb.log:2568:==4158350==    definitely lost: 435,427 bytes in 15,507 blocks
./gdb/testsuite/outputs/gdb.mi/mi-catch-cpp-exceptions/gdb.log:1704:==4119722==    definitely lost: 435,405 bytes in 15,510 blocks
./gdb/testsuite/outputs/gdb.mi/mi-vla-fortran/gdb.log:768:==4113266==    definitely lost: 508,585 bytes in 18,109 blocks

With the fix:
./gdb/testsuite/outputs/gdb.base/fork-running-state/gdb.log:1536:==2924193==    indirectly lost: 13,848 bytes in 98 blocks
./gdb/testsuite/outputs/gdb.base/fork-running-state/gdb.log:1675:==2928777==    indirectly lost: 13,848 bytes in 98 blocks
./gdb/testsuite/outputs/gdb.python/py-inferior-leak/gdb.log:4729:==3353335==    definitely lost: 3,360 bytes in 140 blocks
./gdb/testsuite/outputs/gdb.base/kill-detach-inferiors-cmd/gdb.log:210:==2746927==    indirectly lost: 13,246 bytes in 154 blocks
./gdb/testsuite/outputs/gdb.base/inferior-clone/gdb.log:179:==3034984==    indirectly lost: 12,921 bytes in 161 blocks
./gdb/testsuite/outputs/gdb.base/interrupt-daemon/gdb.log:209:==3006248==    indirectly lost: 20,683 bytes in 174 blocks
./gdb/testsuite/outputs/gdb.threads/watchpoint-fork/gdb.log:714:==3512403==    indirectly lost: 20,707 bytes in 175 blocks
./gdb/testsuite/outputs/gdb.threads/watchpoint-fork/gdb.log:962:==3514498==    indirectly lost: 20,851 bytes in 178 blocks
./gdb/testsuite/outputs/gdb.base/multi-forks/gdb.log:336:==2585839==    indirectly lost: 53,630 bytes in 386 blocks
./gdb/testsuite/outputs/gdb.base/multi-forks/gdb.log:1338:==2592417==    indirectly lost: 100,008 bytes in 1,154 blocks

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

fix leak in gdb_environ

valgrind reports a leak when assigning a gdb_environ to another gdb_environ.
The memory allocated for the target gdb_environ env variables is not released.
The gdb_environ selftest reproduces the leak (see below).
Fix the leak by clearing the target gdb_environ before std::move-ing the
members.

Tested natively and re-running all tests under valgrind.

==3261873== 4,842 bytes in 69 blocks are definitely lost in loss record 6,772 of 6,839
==3261873==    at 0x483979B: malloc (vg_replace_malloc.c:393)
==3261873==    by 0x25A454: xmalloc (alloc.c:57)
==3261873==    by 0x7D1E4E: xstrdup (xstrdup.c:34)
==3261873==    by 0x7E2A51: gdb_environ::from_host_environ() (environ.cc:56)
==3261873==    by 0x66F1C8: test_reinit_from_host_environ (environ-selftests.c:78)
==3261873==    by 0x66F1C8: selftests::gdb_environ_tests::run_tests() (environ-selftests.c:285)
==3261873==    by 0x7EFC43: operator() (std_function.h:622)
=

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

Use false/true for some inferior class members instead of 0/1

Some class members were changed to bool, but there was
still some assignments or comparisons using 0/1.

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

[gdb/server] Emit warning for SIGINT failure

Consider the executable from test-case gdb.base/interrupt-daemon.exp.

When starting it using gdbserver:
...
$ ./build/gdbserver/gdbserver localhost:2345 \
  ./outputs/gdb.base/interrupt-daemon/interrupt-daemon
...
and connecting to it using gdb:
...
$ gdb -q -ex "target remote localhost:2345" \
    -ex "set follow-fork-mode child" \
    -ex "break daemon_main" -ex cont
...
we are setup to do the same as in the test-case: interrupt a running inferior
using ^C.

So let's try:
...
(gdb) continue
Continuing.
^C
...
After pressing ^C, nothing happens.  This a known problem, filed as
PR remote/18772.

The problem is that in linux_process_target::request_interrupt, a kill is used
to send a SIGINT, but it fails.  And it fails silently.

Make the failure verbose by adding a warning, such that the gdbserver output
becomes more helpful:
...
Process interrupt-daemon created; pid = 15068
Listening on port 2345
Remote debugging from host ::1, port 35148
Detaching from process 15068
Detaching from process 15085
gdbserver: Sending SIGINT to process group of pid 15068 failed: \
  No such process
...

Note that the failure can easily be reproduced using the test-case and target
board native-gdbserver:
...
(gdb) continue^M
Continuing.^M
PASS: gdb.base/interrupt-daemon.exp: fg: continue
^CFAIL: gdb.base/interrupt-daemon.exp: fg: ctrl-c stops process (timeout)
...
as reported in PR server/23382.

Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>

Automatic date update in version.in

[gdb/testsuite] Don't generate core in gdb.base/bt-on-fatal-signal.exp

When running test-case gdb.base/bt-on-fatal-signal.exp on powerpc64le-linux I
noticed:
...
FAIL: gdb.base/bt-on-fatal-signal.exp: SEGV: scan for backtrace (timeout)
...

The timeout is 10 seconds, but generating the core file takes more than a
minute, probably due to slow NFS.

I managed to reproduce this behaviour independently of gdb, by compiling
"int main (void) { __builtin_abort (); }" and running it, which took 1.5
seconds for a core file 50 times smaller than the one for gdb.

Fix this by preventing the core file from being generated, using a wrapper
around gdb that does "ulimit -c 0".

Tested on x86_64-linux.

[gdb/symtab] Handle failure to open .gnu_debugaltlink file

If we instrument cc-with-tweaks.sh to remove the .gnu_debugaltlink file after
dwz has created it, with test-case
gdb.threads/access-mem-running-thread-exit.exp and target board cc-with-dwz-m
we run into:
...
(gdb) file access-mem-running-thread-exit^M
Reading symbols from access-mem-running-thread-exit...^M
could not find '.gnu_debugaltlink' file for access-mem-running-thread-exit^M
...
followed a bit later by:
...
(gdb) file access-mem-running-thread-exit^M
Reading symbols from access-mem-running-thread-exit...^M
gdb/dwarf2/read.c:7284: internal-error: create_all_units: \
  Assertion `per_objfile->per_bfd->all_units.empty ()' failed.^M
...

The problem is that create_units does not catch the error thrown by
dwarf2_get_dwz_file.

Fix this by catching the error and performing the necessary cleanup, getting
the same result for the first and second file command.

PR symtab/29805
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29805

Fix jump on uninit producer_is_clang bit of cu.h dwarf2_cu struct.

Valgrind reports a "jump on unitialised bit error" when running
    e.g. gdb.base/macro-source-path.exp (see details below).

    Fix this by initializing producer_is_clang member variable of dwarf2_cu.

    Tested on amd64/debian11 and re-running gdb.base/macro-source-path.exp
    under valgrind.

    ==2140965== Conditional jump or move depends on uninitialised value(s)
    ==2140965==    at 0x5211F7: dwarf_decode_macro_bytes(dwarf2_per_objfile*, buildsym_compunit*, bfd*, unsigned char const*, unsigned char const*, macro_source_file*, line_header const*, dwarf2_section_info const*, int, int, unsigned int, dwarf2_section_info*, dwarf2_section_info*, gdb::optional<unsigned long>, htab*, dwarf2_cu*) (macro.c:676)
    ==2140965==    by 0x52158A: dwarf_decode_macros(dwarf2_per_objfile*, buildsym_compunit*, dwarf2_section_info const*, line_header const*, unsigned int, unsigned int, dwarf2_section_info*, dwarf2_section_info*, gdb::optional<unsigned long>, int, dwarf2_cu*) (macro.c:967)
    ==2140965==    by 0x523BC4: dwarf_decode_macros(dwarf2_cu*, unsigned int, int) (read.c:23379)
    ==2140965==    by 0x552AB5: read_file_scope(die_info*, dwarf2_cu*) (read.c:9687)
    ==2140965==    by 0x54F7B2: process_die(die_info*, dwarf2_cu*) (read.c:8660)
    ==2140965==    by 0x5569C7: process_full_comp_unit (read.c:8429)
    ==2140965==    by 0x5569C7: process_queue (read.c:7675)
    ==2140965==    by 0x5569C7: dw2_do_instantiate_symtab (read.c:2063)
    ==2140965==    by 0x5569C7: dw2_instantiate_symtab(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2085)
    ==2140965==    by 0x55700B: dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) (read.c:3984)
    ==2140965==    by 0x557EA3: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18781)
    ==2140965==    by 0x778977: objfile::lookup_symbol(block_enum, char const*, domain_enum) (symfile-debug.c:276)
    ....
    ==2140965==  Uninitialised value was created by a heap allocation
    ==2140965==    at 0x4839F01: operator new(unsigned long) (vg_replace_malloc.c:434)
    ==2140965==    by 0x533A64: cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) (read.c:6264)
    ==2140965==    by 0x5340C2: load_full_comp_unit(dwarf2_per_cu_data*, dwarf2_per_objfile*, dwarf2_cu*, bool, language) (read.c:7729)
    ==2140965==    by 0x548338: load_cu(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2021)
    ==2140965==    by 0x55634C: dw2_do_instantiate_symtab (read.c:2048)
    ==2140965==    by 0x55634C: dw2_instantiate_symtab(dwarf2_per_cu_data*, dwarf2_per_objfile*, bool) (read.c:2085)
    ==2140965==    by 0x55700B: dw2_expand_symtabs_matching_one(dwarf2_per_cu_data*, dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>, gdb::function_view<bool (compunit_symtab*)>) (read.c:3984)
    ==2140965==    by 0x557EA3: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18781)
    ==2140965==    by 0x778977: objfile::lookup_symbol(block_enum, char const*, domain_enum) (symfile-debug.c:276)
    ....

remove the declared but undefined/unused method find_partial_die

The method
       struct partial_die_info *find_partial_die (sect_offset sect_off);
in cu.h is defined, but is used nowhere and not implemented.

Automatic date update in version.in

Revert "readelf: Do not require EI_OSABI for IFUNC."

This reverts commit ffbbab0b3a1000f862b6d4ce3d9a76ed14f08801.

riscv: Add AIA extension support (Smaia, Ssaia)

This commit adds the AIA extensions (Smaia and Ssaia) CSRs.

bfd/ChangeLog:

* elfxx-riscv.c: Add 'smaia' and 'ssaia' to the list
of known standard extensions.

gas/ChangeLog:

* config/tc-riscv.c (enum riscv_csr_class):
(riscv_csr_address): Add CSR classes for Smaia/Ssaia.
* testsuite/gas/riscv/csr-dw-regnums.d: Add new CSRs.
* testsuite/gas/riscv/csr-dw-regnums.s: Likewise.
* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.d: Likewise.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/csr.s: Likewise.

include/ChangeLog:

* opcode/riscv-opc.h (CSR_MISELECT): New CSR macro.
(CSR_MIREG): Likewise.
(CSR_MTOPEI): Likewise.
(CSR_MTOPI): Likewise.
(CSR_MVIEN): Likewise.
(CSR_MVIP): Likewise.
(CSR_MIDELEGH): Likewise.
(CSR_MIEH): Likewise.
(CSR_MVIENH): Likewise.
(CSR_MVIPH): Likewise.
(CSR_MIPH): Likewise.
(CSR_SISELECT): Likewise.
(CSR_SIREG): Likewise.
(CSR_STOPEI): Likewise.
(CSR_STOPI): Likewise.
(CSR_SIEH): Likewise.
(CSR_SIPH): Likewise.
(CSR_HVIEN): Likewise.
(CSR_HVICTL): Likewise.
(CSR_HVIPRIO1): Likewise.
(CSR_HVIPRIO2): Likewise.
(CSR_VSISELECT): Likewise.
(CSR_VSIREG): Likewise.
(CSR_VSTOPEI): Likewise.
(CSR_VSTOPI): Likewise.
(CSR_HIDELEGH): Likewise.
(CSR_HVIENH): Likewise.
(CSR_HVIPH): Likewise.
(CSR_HVIPRIO1H): Likewise.
(CSR_HVIPRIO2H): Likewise.
(CSR_VSIEH): Likewise.
(CSR_VSIPH): Likewise.
(DECLARE_CSR): Add CSRs for Smaia and Ssaia.

Changes for v3:
- Imply ssaia for smaia
- Imply zicsr for ssaia (and transitively smaia)
- Move hypervisor CSRs to Ssaia+H
- Rebase on upstream/master

Changes for v2:
- Add hypervisor and VS CSRs
- Fix whitespace issue

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>