Automatic date update in version.in

[gdb/symtab] Fix unhandled dwarf expression opcode with gcc-11 -gdwarf-5

[ I've confused things by forgetting to add -gdwarf-4 in $subject of
commit 0057a7ee0d9 "[gdb/testsuite] Add KFAILs for gdb.ada FAILs with
gcc-11".  So I'm adding here -gdwarf-5 in $subject, even though -gdwarf-5 is
the default for gcc-11.  I keep getting confused because of working with a
system gcc-11 compiler that was patched to switch the default back to
-gdwarf-4. ]

When running test-case gdb.ada/arrayptr.exp with gcc-11 (and default
-gdwarf-5), I run into:
...
(gdb) print pa_ptr.all^M
Unhandled dwarf expression opcode 0xff^M
(gdb) FAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all
...

What happens is that pa_ptr:
...
 <2><1523>: Abbrev Number: 3 (DW_TAG_variable)
    <1524>   DW_AT_name        : pa_ptr
    <1529>   DW_AT_type        : <0x14fa>
...
has type:
...
 <2><14fa>: Abbrev Number: 2 (DW_TAG_typedef)
    <14fb>   DW_AT_name        : foo__packed_array_ptr
    <1500>   DW_AT_type        : <0x1504>
 <2><1504>: Abbrev Number: 4 (DW_TAG_pointer_type)
    <1505>   DW_AT_byte_size   : 8
    <1505>   DW_AT_type        : <0x1509>
...
which is a pointer to a subrange:
...
 <2><1509>: Abbrev Number: 12 (DW_TAG_subrange_type)
    <150a>   DW_AT_lower_bound : 0
    <150b>   DW_AT_upper_bound : 0x3fffffffffffffffff
    <151b>   DW_AT_name        : foo__packed_array
    <151f>   DW_AT_type        : <0x15cc>
    <1523>   DW_AT_artificial  : 1
 <1><15cc>: Abbrev Number: 5 (DW_TAG_base_type)
    <15cd>   DW_AT_byte_size   : 16
    <15ce>   DW_AT_encoding    : 7      (unsigned)
    <15cf>   DW_AT_name        : long_long_long_unsigned
    <15d3>   DW_AT_artificial  : 1
...
with upper bound of form DW_FORM_data16.

In gdb/dwarf/attribute.h we have:
...
  /* Return non-zero if ATTR's value falls in the 'constant' class, or
     zero otherwise.  When this function returns true, you can apply
     the constant_value method to it.
     ...
     DW_FORM_data16 is not considered as constant_value cannot handle
     that.  */
  bool form_is_constant () const;
...
so instead we have attribute::form_is_block (DW_FORM_data16) == true.

Then in attr_to_dynamic_prop for the upper bound, we get a PROC_LOCEXPR
instead of a PROP_CONST and end up trying to evaluate the constant
0x3fffffffffffffffff as if it were a locexpr, which causes the
"Unhandled dwarf expression opcode 0xff".

In contrast, with -gdwarf-4 we have:
...
    <164c>   DW_AT_upper_bound : 18 byte block: \
      9e 10 ff ff ff ff ff ff ff ff 3f 0 0 0 0 0 0 0 \
      (DW_OP_implicit_value 16 byte block: \
        ff ff ff ff ff ff ff ff 3f 0 0 0 0 0 0 0 )
...

Fix the dwarf error by translating the DW_FORM_data16 constant into a
PROC_LOCEXPR, effectively by prepending 0x9e 0x10, such that we have same
result as with -gdwarf-4:
...
(gdb) print pa_ptr.all^M
That operation is not available on integers of more than 8 bytes.^M
(gdb) KFAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all \
  (PRMS: gdb/20991)
...

Tested on x86_64-linux, with gcc-11 and target board
unix/gdb:debug_flags=-gdwarf-5.

gdb/ChangeLog:

2021-07-28  Tom de Vries  <tdevries@suse.de>

* dwarf2/read.c (attr_to_dynamic_prop): Handle DW_FORM_data16.

Automatic date update in version.in

[gdb/testsuite] Add xfail for PR gcc/101643

With gcc 8.5.0 I run into:
...
(gdb) print bad^M
$2 = (0 => 0 <repeats 25 times>)^M
(gdb) FAIL: gdb.ada/big_packed_array.exp: scenario=minimal: print bad
...
while with gcc 9.3.1 we have instead:
...
(gdb) print bad^M
$2 = (false <repeats 196 times>)^M
(gdb) PASS: gdb.ada/big_packed_array.exp: scenario=minimal: print bad
...

This is caused by gcc PR, which I've filed at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101643 "[debug, ada] packed array
not described as packed".

Fix by marking this as XFAIL.

Tested on x86_64-linux.

gdb/ChangeLog:

2021-07-27  Tom de Vries  <tdevries@suse.de>

PR testsuite/26904
* gdb/testsuite/gdb.ada/big_packed_array.exp: Add xfail.

[gdb/testsuite] Add xfail for PR gcc/101633

With gcc 7.5.0, I run into:
...
(gdb) print objects^M
$1 = ((tag => object, values => ()), (tag => unused))^M
(gdb) FAIL: gdb.ada/array_of_variant.exp: scenario=minimal: print entire array
...
while with gcc 8.5.0 we have:
...
(gdb) print objects^M
$1 = ((tag => object, values => (2, 2, 2, 2, 2)), (tag => unused))^M
(gdb) PASS: gdb.ada/array_of_variant.exp: scenario=minimal: print entire array
...

This is due to a gcc PR, which I've filed at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101633 "Bug 101633 - [debug]
DW_TAG_subrange_type missing DW_AT_upper_bound".

Fix by marking this and related FAILs as XFAIL.

Tested on x86_64-linux.

gdb/ChangeLog:

2021-07-27  Tom de Vries  <tdevries@suse.de>

PR testsuite/26903
* gdb/testsuite/gdb.ada/array_of_variant.exp: Add xfails.

Automatic date update in version.in

Update the NetBSD system call table to match NetBSD-current.

Generated from sys/sys/syscall.h revision 1.319.

We can safely remove the _lwp_gettid syscall, which was never exposed
in libc and never made it into a release.

gdb/ChangeLog:

2021-07-26  Frederic Cambus  <fred@statdns.com>

* syscalls/netbsd.xml: Regenerate.

gdb: Fix numerical field extraction for target description "flags"

The "val_print_type_code_flags ()" function is responsible for
extraction of fields for "flags" data type.  These data types are
used when describing a custom register type in a target description
XML.  The logic used for the extraction though is not sound:

    unsigned field_len = TYPE_FIELD_BITSIZE (type, field);
    ULONGEST field_val
      = val >> (TYPE_FIELD_BITPOS (type, field) - field_len + 1);

TYPE_FIELD_BITSIZE: The bit length of the field to be extracted.
TYPE_FIELD_BITPOS:  The starting position of the field; 0 is LSB.
val:                The register value.

Imagine you have a field that starts at position 1 and its length
is 4 bits.  According to the third line of the code snippet the
shifting right would become "val >> -2", or "val >> 0xfff...fe"
to be precise.  That will result in a "field_val" of 0.

The correct extraction should be:

    ULONGEST field_val = val >> TYPE_FIELD_BITPOS (type, field);

The rest of the algorithm that masks out the higher bits is OK.

gdb/ChangeLog:
2021-07-26  Shahab Vahedi  <shahab@synopsys.com>
            Simon Marchi  <simon.marchi@efficios.com>

PR gdb/28103
* valprint.c (val_print_type_code_flags): Merely shift the VAL
to the right to get rid of the lower bits.
(test_print_flags): New.
(_initialize_valprint): Invoke the "test_print_flags" as a unit-test.

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

gdb/mi: handle no condition argument case for -break-condition

As reported in PR gdb/28076 [1], passing no condition argument to the
-break-condition command (e.g.: "-break-condition 2") should clear the
condition for breakpoint 2, just like CLI's "condition 2", but instead
an error message is returned:

  ^error,msg="-break-condition: Missing the <number> and/or <expr> argument"

The current implementation of the -break-condition command's argument
handling (79aabb7308c "gdb/mi: add a '--force' flag to the
'-break-condition' command") was done according to the documentation,
where the condition argument seemed mandatory.  However, the
-break-condition command originally (i.e. before the 79aabb7308c
patch) used the CLI's "cond" command, and back then not passing a
condition argument was clearing out the condition.  So, this is a
regression in terms of the behavior.

Fix the argument handling of the -break-condition command to allow not
having a condition argument, and also update the document to make the
behavior clear.  Also add test cases to test the scenarios which were
previously not covered.

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

gdb/ChangeLog:
2021-07-26  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

PR gdb/28076
* mi/mi-cmd-break.c (mi_cmd_break_condition): Handle the case
of having no condition argument.

gdb/doc/ChangeLog:
2021-07-26  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

PR gdb/28076
* gdb.texinfo (GDB/MI Breakpoint Commands): Mention clearing
the condition in the -break-condition command.

gdb/testsuite/ChangeLog:
2021-07-26  Tankut Baris Aktemur  <tankut.baris.aktemur@intel.com>

PR gdb/28076
* gdb.mi/mi-break.exp: Add more tests to check clearing the
breakpoint condition.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[gdb/testsuite] Fix FAILs due to PR gcc/101575

When running test-case gdb.ada/formatted_ref.exp with gcc-11 and target board
unix/gdb:debug_flags=-gdwarf-4 we run into:
...
(gdb) print/x s^M
No definition of "s" in current context.^M
(gdb) FAIL: gdb.ada/formatted_ref.exp: print/x s
...
which is caused by "runto defs.adb:20" taking us to defs__struct1IP:
...
(gdb) break defs.adb:20^M
Breakpoint 1 at 0x402cfd: defs.adb:20. (2 locations)^M
(gdb) run ^M
Starting program: formatted_ref ^M
^M
Breakpoint 1, defs__struct1IP () at defs.adb:20^M
20            return s.x;                   -- Set breakpoint marker here.^M
(gdb) print s1'access^M
...
instead of the expected defs.f1:
...
(gdb) break defs.adb:20^M
Breakpoint 1 at 0x402d0e: file defs.adb, line 20.^M
(gdb) run ^M
Starting program: formatted_ref ^M
^M
Breakpoint 1, defs.f1 (s=...) at defs.adb:20^M
20            return s.x;                   -- Set breakpoint marker here.^M
...

This is caused by incorrect line info due to gcc PR 101575 - "[gcc-11,
-gdwarf-4] Missing .file <n> directive causes invalid line info".

Fix this by when landing in defs__struct1IP:
- xfailing the runto, and
- issuing a continue to land in defs.f1.

Likewise in a few other test-cases.

Tested on x86_64-linux, with:
- system gcc.
- gcc-11 and target boards unix/gdb:debug_flags=-gdwarf-4 and
  unix/gdb:debug_flags=-gdwarf-5.

gdb/testsuite/ChangeLog:

2021-07-22  Tom de Vries  <tdevries@suse.de>

* gdb.ada/formatted_ref.exp: Add xfail for PR gcc/101575.
* gdb.ada/iwide.exp: Same.
* gdb.ada/pkd_arr_elem.exp: Same.

[gdb/testsuite] Fix gdb.cp/step-and-next-inline.exp with gcc-11

When running test-case gdb.cp/step-and-next-inline.exp with gcc-11, I run
into:
...
KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 1 \
  (PRMS symtab/25507)
FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 2
KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 3 \
  (PRMS symtab/25507)
...

[ Note that I get the same result with gcc-11 and target board
unix/gdb:debug_flags=-gdwarf-4, so this is not a dwarf 4 vs 5 issue. ]

With gcc-10, I have this trace:
...
64        get_alias_set (&xx);
get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51
51        if (t != NULL
40        if (t->x != i)
52            && TREE_TYPE (t).z != 1
43        return x;
53            && TREE_TYPE (t).z != 2
43        return x;
54            && TREE_TYPE (t).z != 3)
43        return x;
main () at step-and-next-inline.cc:65
65        return 0;
...
and with gcc-11, I have instead:
...
64        get_alias_set (&xx);
get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51
51        if (t != NULL
52            && TREE_TYPE (t).z != 1
43        return x;
53            && TREE_TYPE (t).z != 2
43        return x;
54            && TREE_TYPE (t).z != 3)
43        return x;
main () at step-and-next-inline.cc:65
65        return 0;
...
and with clang-10, I have instead:
...
64        get_alias_set (&xx);
get_alias_set (t=0x601034 <xx>) at step-and-next-inline.cc:51
51        if (t != NULL
52            && TREE_TYPE (t).z != 1
53            && TREE_TYPE (t).z != 2
54            && TREE_TYPE (t).z != 3)
51        if (t != NULL
57      }
main () at step-and-next-inline.cc:65
65        return 0;
...

The test-case tries to verify that we don't step into inlined function
tree_check (lines 40-43) (so, with the clang trace we get that right).

The test-case then tries to kfail the problems when using gcc, but this is
done in such a way that the testing still gets out of sync after a failure.
That is: the "next step 2" check that is supposed to match
"TREE_TYPE (t).z != 2" is actually matching "TREE_TYPE (t).z != 1":
...
(gdb) next^M
52            && TREE_TYPE (t).z != 1^M
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: next step 2
...

Fix this by issuing extra nexts to arrive at the required lines.

Tested on x86_64-linux, with gcc-8, gcc-9, gcc-10, gcc-11, clang-8, clang-10
and clang-12.

gdb/testsuite/ChangeLog:

2021-07-22  Tom de Vries  <tdevries@suse.de>

* gdb.cp/step-and-next-inline.cc (tree_check, get_alias_set, main):
Tag closing brace with comment.
* gdb.cp/step-and-next-inline.h: Update to keep identical with
step-and-next-inline.cc.
* gdb.cp/step-and-next-inline.exp: Issue extra next when required.

Automatic date update in version.in

[gdb/testsuite] Fix FAILs due to PR gcc/101452

When running test-case gdb.base/ptype-offsets.exp with gcc-11 (with -gdwarf-5
default) or gcc-10 with target board unix/gdb:debug_flags=-gdwarf-5 we run
into this regression:
...
 (gdb) ptype/o static_member^M
 /* offset      |    size */  type = struct static_member {^M
-                               static static_member Empty;^M
 /*      0      |       4 */    int abc;^M
 ^M
                                /* total size (bytes):    4 */^M
                              }^M
-(gdb) PASS: gdb.base/ptype-offsets.exp: ptype/o static_member
+(gdb) FAIL: gdb.base/ptype-offsets.exp: ptype/o static_member
...

This is caused by missing debug info, which I filed as gcc PR101452 - "[debug,
dwarf-5] undefined static member removed by
-feliminate-unused-debug-symbols".

It's not clear yet whether this is a bug or a feature, but work around this in
the test-cases by:
- defining the static member
- adding additional_flags=-fno-eliminate-unused-debug-types.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-07-21  Tom de Vries  <tdevries@suse.de>

* lib/gdb.exp (gcc_major_version): New proc.
* gdb.base/ptype-offsets.cc: Define static member static_member::Empty.
* gdb.cp/templates.exp: Define static member using -DGCC_BUG.
* gdb.cp/m-static.exp: Add
additional_flags=-fno-eliminate-unused-debug-types.
* gdb.cp/pr-574.exp: Same.
* gdb.cp/pr9167.exp: Same.

[gdb/testsuite] Add KFAILs for gdb.ada FAILs with gcc-11

With gcc-11 we run into:
...
(gdb) print pa_ptr.all^M
That operation is not available on integers of more than 8 bytes.^M
(gdb) KFAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all (PRMS: gdb/20991)
...

This is due to PR exp/20991 - "__int128 type support".  Mark this and similar
FAILs as KFAIL.

Also mark this FAIL:
....
(gdb) print pa_ptr(3)^M
cannot subscript or call something of type `foo__packed_array_ptr'^M
(gdb) FAIL: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr(3)
...
as a KFAIL for PR ada/28115 - "Support packed array encoded as
DW_TAG_subrange_type".

Tested on x86_64-linux, with gcc-10 and gcc-11.

gdb/testsuite/ChangeLog:

2021-07-21  Tom de Vries  <tdevries@suse.de>

* gdb.ada/arrayptr.exp: Add KFAILs for PR20991 and PR28115.
* gdb.ada/exprs.exp: Add KFAILs for PR20991.
* gdb.ada/packed_array_assign.exp: Same.

Automatic date update in version.in

Fix printing of non-address types when memory tagging is enabled

When the architecture supports memory tagging, we handle
pointer/reference types in a special way, so we can validate tags and
show mismatches.

Unfortunately, the currently implementation errors out when the user
prints non-address values: composite types, floats, references, member
functions and other things.

Vector registers:

 (gdb) p $v0
 Value can't be converted to integer.

Non-existent internal variables:

 (gdb) p $foo
 Value can't be converted to integer.

The same happens for complex types and printing struct/union types.

There are a few problems here.

The first one is that after print_command_1 evaluates the expression
to print, the tag validation code call value_as_address
unconditionally, without making sure we have have a suitable type
where it makes to sense to call it.  That results in value_as_address
(if it isn't given a pointer-like type) trying to treat the value as
an integer and convert it to an address, which #1 - doesn't make sense
(i.e., no sense in validating tags after "print 1"), and throws for
non-integer-convertible types.  We fix this by making sure we have a
pointer or reference type first, and only if so then proceed to check
if the address-like value has tags.

The second is that we're calling value_as_address even if we have an
optimized out or unavailable value, which throws, because the value's
contents aren't fully accessible/readable.  This error currently
escapes out and aborts the print.  This case is fixed by checking for
optimized out / unavailable explicitly.

Third, the tag checking process does not gracefully handle exceptions.
If any exception is thrown from the tag validation code, we abort the
print.  E.g., the target may fail to access tags via a running thread.
Or the needed /proc files aren't available.  Or some other untold
reason.  This is a bit too rigid.  This commit changes print_command_1
to catch errors, print them, and still continue with the normal
expression printing path instead of erroring out and printing nothing
useful.

With this patch, printing works correctly again:

 (gdb) p $v0
 $1 = {d = {f = {2.0546950501119882e-81, 2.0546950501119882e-81}, u = {3399988123389603631, 3399988123389603631}, s = {
       3399988123389603631, 3399988123389603631}}, s = {f = {1.59329203e-10, 1.59329203e-10, 1.59329203e-10, 1.59329203e-10}, u = {
       791621423, 791621423, 791621423, 791621423}, s = {791621423, 791621423, 791621423, 791621423}}, h = {bf = {1.592e-10,
       1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10}, f = {0.11224, 0.11224, 0.11224, 0.11224, 0.11224,
       0.11224, 0.11224, 0.11224}, u = {12079, 12079, 12079, 12079, 12079, 12079, 12079, 12079}, s = {12079, 12079, 12079, 12079,
       12079, 12079, 12079, 12079}}, b = {u = {47 <repeats 16 times>}, s = {47 <repeats 16 times>}}, q = {u = {
       62718710765820030520700417840365121327}, s = {62718710765820030520700417840365121327}}}
 (gdb) p $foo
 $2 = void
 (gdb) p 2 + 2i
 $3 = 2 + 2i

gdb/ChangeLog

2021-07-20  Luis Machado  <luis.machado@linaro.org>
    Pedro Alves  <pedro@palves.net>

PR gdb/28110
* gdbarch.sh: Updated documentation for gdbarch_tagged_address_p.
* gdbarch.h: Regenerate.
* printcmd.c (should_validate_memtags): Reorder comparisons and only
validate tags for pointer and reference types.  Skip validation of
optimized out or unavailable values.
(print_command_1): Guard call memory tagging validation code with
a try/catch block.

Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: I82bf00ac88d23553b3f7563c9872dfa6ca1f2207

Automatic date update in version.in

Avoid expression parsing crash with unknown language

PR gdb/28093 points out that gdb crashes when language is set to
"unknown" and expression parsing is attempted.  At first I thought
this was a regression due to the expression rewrite, but it turns out
that older versions crash as well.

This patch avoids the crash by changing the default expression parser
to throw an exception.  I think this is preferable -- the current
behavior of silently doing nothing does not really make sense.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28093
(cherry picked from commit dcd482c1b756d9da2130552a6eb58b852d6efb97)

gdb/ChangeLog
2021-07-19  Tom Tromey  <tromey@adacore.com>

PR gdb/28093
* language.c (auto_or_unknown_language::parser): Call error.

gdb/testsuite/ChangeLog
2021-07-19  Tom Tromey  <tromey@adacore.com>

PR gdb/28093
* gdb.base/langs.exp: Add tests.

Automatic date update in version.in

Automatic date update in version.in

Add basic Z80 CPU support

Supported ISAs:
- Z80 (all undocumented instructions)
- Z180
- eZ80 (Z80 mode only)

Datasheets:
Z80: https://www.zilog.com/manage_directlink.php?filepath=docs/z80/um0080&extn=.pdf
Z180: https://www.zilog.com/manage_directlink.php?filepath=docs/z180/ps0140&extn=.pdf
eZ80: http://www.zilog.com/force_download.php?filepath=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTlWVFRBd056Y3VjR1Jt

To debug Z80 programs using GDB you must configure and embed
z80-stub.c to your program (SDCC compiler is required). Or
you may use some simulator with GDB support.

gdb/ChangeLog:

* Makefile.in (ALL_TARGET_OBS): Add z80-tdep.c.
* NEWS: Mention z80 support.
* configure.tgt: Handle z80*.
* features/Makefile (XMLTOC): Add z80.xml.
* features/z80-cpu.xml: New.
* features/z80.c: Generate.
* features/z80.xml: New.
* z80-tdep.c: New file.
* z80-tdep.h: New file.

gdb/stubs/ChangeLog:

* z80-stub.c: New file.

Change-Id: Id0b7a6e210c3f93c6853c5e3031b7bcee47d0db9

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[gdb/testsuite] Fix gdb.base/gold-gdb-index.exp

When running test-case gdb.base/gold-gdb-index.exp on openSUSE Tumbleweed,
I run into:
...
FAIL: gdb.base/gold-gdb-index.exp: maint info symtabs
...

This is due to a dummy .gdb_index:
...
Contents of the .gdb_index section:

Version 7

CU table:

TU table:

Address table:

Symbol table:
...

The dummy .gdb_index is ignored when loading the symbols, and instead partial
symbols are used.  Consequently, we get the same result as if we'd removed
-Wl,--gdb-index from the compilation.

Presumably, gold fails to generate a proper .gdb_index because it lacks
DWARF5 support.

Anyway, without a proper .gdb_index we can't test the gdb behaviour we're
trying to excercise.  Fix this by detecting whether we actually used a
.gdb_index for symbol loading.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2021-07-14  Tom de Vries  <tdevries@suse.de>

* lib/gdb.exp (have_index): New proc.
* gdb.base/gold-gdb-index.exp: Use have_index.

Automatic date update in version.in

Use /bin/sh as shebang in gdb/make-init-c

While testing the NixOS[1] packaging for gdb-11.0.90.tar.xz, I got the
following error:

  [...]
  CXX    aarch32-tdep.o
  CXX    gdb.o
  GEN    init.c
  /nix/store/26a78ync552m8j4sbjavhvkmnqir8c9y-bash-4.4-p23/bin/bash: ./make-init-c: /usr/bin/env: bad interpreter: No such file or directory
  make[2]: *** [Makefile:1866: stamp-init] Error 126
  make[2]: *** Waiting for unfinished jobs....
  make[2]: Leaving directory '/build/gdb-11.0.90/gdb'
  make[1]: *** [Makefile:9814: all-gdb] Error 2
  make[1]: Leaving directory '/build/gdb-11.0.90'
  make: *** [Makefile:903: all] Error 2
  builder for '/nix/store/xs8my3rrc3l4kdlbpx0azh6q0v0jxphr-gdb-gdb-11.0.90.drv' failed with exit code 2
  error: build of '/nix/store/xs8my3rrc3l4kdlbpx0azh6q0v0jxphr-gdb-gdb-11.0.90.drv' failed

In the nix build environment, /usr/bin/env is not present, only /bin/sh
is.  This patch makes sure that gdb/make-init-c uses '/bin/sh' as
interpreter as this is the only one available on this platform.

I do not think this change will cause regressions on any other
configuration.

[1] https://nixos.org/

gdb/Changelog

* make-init-c: Use /bin/sh as shebang.

Avoid letting exceptions escape gdb_bfd_iovec_fileio_close (PR gdb/28080)

Before PR gdb/28080 was fixed by the previous patch, GDB was crashing
like this:

 (gdb) detach
 Detaching from program: target:/any/program, process 3671843
 Detaching from process 3671843
 Ending remote debugging.
 [Inferior 1 (process 3671843) detached]
 In main
 terminate called after throwing an instance of 'gdb_exception_error'
 Aborted (core dumped)

Here's the exception above being thrown:

 (top-gdb) bt
 #0  throw_error (error=TARGET_CLOSE_ERROR, fmt=0x555556035588 "Remote connection closed") at src/gdbsupport/common-exceptions.cc:222
 #1  0x0000555555bbaa46 in remote_target::readchar (this=0x555556a11040, timeout=10000) at src/gdb/remote.c:9440
 #2  0x0000555555bbb9e5 in remote_target::getpkt_or_notif_sane_1 (this=0x555556a11040, buf=0x555556a11058, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9928
 #3  0x0000555555bbbda9 in remote_target::getpkt_sane (this=0x555556a11040, buf=0x555556a11058, forever=0) at src/gdb/remote.c:10030
 #4  0x0000555555bc0e75 in remote_target::remote_hostio_send_command (this=0x555556a11040, command_bytes=13, which_packet=14, remote_errno=0x7fffffffcfd0, attachment=0x0, attachment_len=0x0) at src/gdb/remote.c:12137
 #5  0x0000555555bc1b6c in remote_target::remote_hostio_close (this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12455
 #6  0x0000555555bc1bb4 in remote_target::fileio_close (During symbol reading: .debug_line address at offset 0x64f417 is 0 [in module build/gdb/gdb]
 this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12462
 #7  0x0000555555c9274c in target_fileio_close (fd=3, target_errno=0x7fffffffcfd0) at src/gdb/target.c:3365
 #8  0x000055555595a19d in gdb_bfd_iovec_fileio_close (abfd=0x555556b9f8a0, stream=0x555556b11530) at src/gdb/gdb_bfd.c:439
 #9  0x0000555555e09e3f in opncls_bclose (abfd=0x555556b9f8a0) at src/bfd/opncls.c:599
 #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556b9f8a0) at src/bfd/opncls.c:847
 #11 0x0000555555e0a27a in bfd_close (abfd=0x555556b9f8a0) at src/bfd/opncls.c:814
 #12 0x000055555595a9d3 in gdb_bfd_close_or_warn (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:626
 #13 0x000055555595ad29 in gdb_bfd_unref (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:715
 #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573
 #15 0x0000555555ae955a in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:377
 #16 0x000055555572b7c8 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
 #17 0x00005555557263c3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x555556bf0588, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:730
 #18 0x0000555555ae745e in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
 #19 0x0000555555ae747e in std::shared_ptr<objfile>::~shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr.h:103
 #20 0x0000555555b1c1dc in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x5555564cdd60, __p=0x555556bf0580) at /usr/include/c++/9/ext/new_allocator.h:153
 #21 0x0000555555b1bb1d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556bf0580) at /usr/include/c++/9/bits/alloc_traits.h:497
 #22 0x0000555555b1b73e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/stl_list.h:1921
 #23 0x0000555555b1afeb in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/list.tcc:158
 #24 0x0000555555b19576 in program_space::remove_objfile (this=0x5555564cdd20, objfile=0x555556515540) at src/gdb/progspace.c:210
 #25 0x0000555555ae4502 in objfile::unlink (this=0x555556515540) at src/gdb/objfiles.c:487
 #26 0x0000555555ae5a12 in objfile_purge_solibs () at src/gdb/objfiles.c:875
 #27 0x0000555555c09686 in no_shared_libraries (ignored=0x0, from_tty=1) at src/gdb/solib.c:1236
 #28 0x00005555559e3f5f in detach_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:2769

Note frame #14:

 #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573

That's a dtor, thus noexcept.  That's the reason for the
std::terminate.

The previous patch fixed things such that the exception above isn't
thrown anymore.  However, it's possible that e.g., the remote
connection drops just while a user types "nosharedlibrary", or some
other reason that leads to objfile::~objfile, and then we end up the
same std::terminate problem.

Also notice that frames #9-#11 are BFD frames:

 #9  0x0000555555e09e3f in opncls_bclose (abfd=0x555556bc27e0) at src/bfd/opncls.c:599
 #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556bc27e0) at src/bfd/opncls.c:847
 #11 0x0000555555e0a27a in bfd_close (abfd=0x555556bc27e0) at src/bfd/opncls.c:814

BFD is written in C and thus throwing exceptions over such frames may
either not clean up properly, or, may abort if bfd is not compiled
with -fasynchronous-unwind-tables (x86-64 defaults that on, but not
all GCC ports do).

Thus frame #8 seems like a good place to swallow exceptions.  More so
since in this spot we already ignore target_fileio_close return
errors.  That's what this commit does.  Without the previous fix, we'd
see:

 (gdb) detach
 Detaching from program: target:/any/program, process 2197701
 Ending remote debugging.
 [Inferior 1 (process 2197701) detached]
 warning: cannot close "target:/lib64/ld-linux-x86-64.so.2": Remote connection closed

Note it prints a warning, which would still be a regression compared
to GDB 10, if it weren't for the previous fix.

gdb/ChangeLog:
yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

PR gdb/28080
* gdb_bfd.c (gdb_bfd_close_warning): New.
(gdb_bfd_iovec_fileio_close): Wrap target_fileio_close in
try/catch and print warning on exception.
(gdb_bfd_close_or_warn): Use gdb_bfd_close_warning.

Change-Id: Ic7a26ddba0a4444e3377b0e7c1c89934a84545d7

Fix detach with target remote (PR gdb/28080)

Commit 408f66864a1a823591b26420410c982174c239a2 ("detach in all-stop
with threads running") regressed "detach" with "target remote":

 (gdb) detach
 Detaching from program: target:/any/program, process 3671843
 Detaching from process 3671843
 Ending remote debugging.
 [Inferior 1 (process 3671843) detached]
 In main
 terminate called after throwing an instance of 'gdb_exception_error'
 Aborted (core dumped)

Here's the exception above being thrown:

 (top-gdb) bt
 #0  throw_error (error=TARGET_CLOSE_ERROR, fmt=0x555556035588 "Remote connection closed") at src/gdbsupport/common-exceptions.cc:222
 #1  0x0000555555bbaa46 in remote_target::readchar (this=0x555556a11040, timeout=10000) at src/gdb/remote.c:9440
 #2  0x0000555555bbb9e5 in remote_target::getpkt_or_notif_sane_1 (this=0x555556a11040, buf=0x555556a11058, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9928
 #3  0x0000555555bbbda9 in remote_target::getpkt_sane (this=0x555556a11040, buf=0x555556a11058, forever=0) at src/gdb/remote.c:10030
 #4  0x0000555555bc0e75 in remote_target::remote_hostio_send_command (this=0x555556a11040, command_bytes=13, which_packet=14, remote_errno=0x7fffffffcfd0, attachment=0x0, attachment_len=0x0) at src/gdb/remote.c:12137
 #5  0x0000555555bc1b6c in remote_target::remote_hostio_close (this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12455
 #6  0x0000555555bc1bb4 in remote_target::fileio_close (During symbol reading: .debug_line address at offset 0x64f417 is 0 [in module build/gdb/gdb]
 this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12462
 #7  0x0000555555c9274c in target_fileio_close (fd=3, target_errno=0x7fffffffcfd0) at src/gdb/target.c:3365
 #8  0x000055555595a19d in gdb_bfd_iovec_fileio_close (abfd=0x555556b9f8a0, stream=0x555556b11530) at src/gdb/gdb_bfd.c:439
 #9  0x0000555555e09e3f in opncls_bclose (abfd=0x555556b9f8a0) at src/bfd/opncls.c:599
 #10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556b9f8a0) at src/bfd/opncls.c:847
 #11 0x0000555555e0a27a in bfd_close (abfd=0x555556b9f8a0) at src/bfd/opncls.c:814
 #12 0x000055555595a9d3 in gdb_bfd_close_or_warn (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:626
 #13 0x000055555595ad29 in gdb_bfd_unref (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:715
 #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573
 #15 0x0000555555ae955a in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:377
 #16 0x000055555572b7c8 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
 #17 0x00005555557263c3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x555556bf0588, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:730
 #18 0x0000555555ae745e in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
 #19 0x0000555555ae747e in std::shared_ptr<objfile>::~shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr.h:103
 #20 0x0000555555b1c1dc in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x5555564cdd60, __p=0x555556bf0580) at /usr/include/c++/9/ext/new_allocator.h:153
 #21 0x0000555555b1bb1d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556bf0580) at /usr/include/c++/9/bits/alloc_traits.h:497
 #22 0x0000555555b1b73e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/stl_list.h:1921
 #23 0x0000555555b1afeb in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/list.tcc:158
 #24 0x0000555555b19576 in program_space::remove_objfile (this=0x5555564cdd20, objfile=0x555556515540) at src/gdb/progspace.c:210
 #25 0x0000555555ae4502 in objfile::unlink (this=0x555556515540) at src/gdb/objfiles.c:487
 #26 0x0000555555ae5a12 in objfile_purge_solibs () at src/gdb/objfiles.c:875
 #27 0x0000555555c09686 in no_shared_libraries (ignored=0x0, from_tty=1) at src/gdb/solib.c:1236
 #28 0x00005555559e3f5f in detach_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:2769

So frame #28 already detached the remote process, and then we're
purging the shared libraries.  GDB had opened remote shared libraries
via the target: sysroot, so it tries closing them.  GDBserver is
tearing down already, so remote communication breaks down and we close
the remote target and throw TARGET_CLOSE_ERROR.

Note frame #14:

 #14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573

That's a dtor, thus noexcept.  That's the reason for the
std::terminate.

Stepping back a bit, why do we still have open remote files if we've
managed to detach already, and, we're debugging with "target remote"?
The reason is that commit 408f66864a1a823591b26420410c982174c239a2
makes detach_command hold a reference to the target, so the remote
target won't be finally closed until frame #28 returns.  It's closing
the target that invalidates target file I/O handles.

This commit fixes the issue by not relying on target_close to
invalidate the target file I/O handles, instead invalidate them
immediately in remote_unpush_target.  So when GDB purges the solibs,
and we end up in target_fileio_close (frame #7 above), there's nothing
to do, and we don't try to talk with the remote target anymore.

The regression isn't seen when testing with
--target_board=native-gdbserver, because that does "set sysroot" to
disable the "target:" sysroot, for test run speed reasons.  So this
commit adds a testcase that explicitly tests detach with "set sysroot
target:".

gdb/ChangeLog:
yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

PR gdb/28080
* remote.c (remote_unpush_target): Invalidate file I/O target
handles.
* target.c (fileio_handles_invalidate_target): Make extern.
* target.h (fileio_handles_invalidate_target): Declare.

gdb/testsuite/ChangeLog:
yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

PR gdb/28080
* gdb.base/detach-sysroot-target.exp: New.
* gdb.base/detach-sysroot-target.c: New.

Reported-By: Jonah Graham <jonah@kichwacoders.com>
Change-Id: I851234910172f42a1b30e731161376c344d2727d

[gdb/testsuite] Fix check-libthread-db.exp FAILs with glibc 2.33

When running test-case gdb.threads/check-libthread-db.exp on openSUSE
Tumbleweed with glibc 2.33, I get:
...
(gdb) maint check libthread-db^M
Running libthread_db integrity checks:^M
  Got thread 0x7ffff7c79b80 => 9354 => 0x7ffff7c79b80; errno = 0 ... OK^M
libthread_db integrity checks passed.^M
(gdb) FAIL: gdb.threads/check-libthread-db.exp: user-initiated check: \
  libpthread.so not initialized (pattern 2)
...

The test-case expects instead:
...
  Got thread 0x0 => 9354 => 0x0 ... OK^M
...
which is what I get on openSUSE Leap 15.2 with glibc 2.26, and what is
described in the test-case like this:
...
    # libthread_db should fake a single thread with th_unique == NULL.
...

Using a breakpoint on check_thread_db_callback we can compare the two
scenarios, and find that in the latter case we hit this code in glibc function
iterate_thread_list in nptl_db/td_ta_thr_iter.c:
...
  if (next == 0 && fake_empty)
    {
      /* __pthread_initialize_minimal has not run.  There is just the main
         thread to return.  We cannot rely on its thread register.  They
         sometimes contain garbage that would confuse us, left by the
         kernel at exec.  So if it looks like initialization is incomplete,
         we only fake a special descriptor for the initial thread.  */
      td_thrhandle_t th = { ta, 0 };
      return callback (&th, cbdata_p) != 0 ? TD_DBERR : TD_OK;
    }
...
while in the former case we don't because this preceding statement doesn't
result in next == 0:
...
  err = DB_GET_FIELD (next, ta, head, list_t, next, 0);
...

Note that the comment mentions __pthread_initialize_minimal, but in both cases
it has already run before we hit the callback, so it's possible the comment is
no longer accurate.

The change in behaviour bisect to glibc commit 1daccf403b "nptl: Move stack
list variables into _rtld_global", which moves the initialization of stack
list variables such as __stack_user to an earlier moment, which explains well
enough the observed difference.

Fix this by updating the regexp patterns to agree with what libthread-db is
telling us.

Tested on x86_64-linux, both with glibc 2.33 and 2.26.

gdb/testsuite/ChangeLog:

2021-07-13  Tom de Vries  <tdevries@suse.de>

PR testsuite/27690
* gdb.threads/check-libthread-db.exp: Update patterns for glibc 2.33.

gdb: disable commit-resumed on -exec-interrupt --thread-group

As reported in PR gdb/28077, we hit an internal error when using
-exec-interrupt with --thread-group:

    info threads
    &"info threads\n"
    ~"  Id   Target Id             Frame \n"
    ~"* 1    process 403312 \"loop\" (running)\n"
    ^done
    (gdb)
    -exec-interrupt --thread-group i1
    ~"/home/simark/src/binutils-gdb/gdb/target.c:3768: internal-error: void target_stop(ptid_t): Assertion `!proc_target->commit_resumed_state' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? (y or n) "

This is because this code path never disables commit-resumed (a
requirement for calling target_stop, as documented in
process_stratum_target::»commit_resumed_state) before calling
target_stop.

The other 3 code paths in mi_cmd_exec_interrupt use interrupt_target_1,
which does it.  But the --thread-group code path uses its own thing
which doesn't do it.  Fix this by adding a scoped_disable_commit_resumed
in this code path.

Calling -exec-interrupt with --thread-group is apparently not tested at
the moment (which is why this bug could creep in).  Add a new test for
that.  The test runs two inferiors and tries to interrupt them with
"-exec-interrupt --thread-group X".

This will need to be merged in the gdb-11-branch, so here are ChangeLog
entries:

gdb/ChangeLog:

* mi/mi-main.c (mi_cmd_exec_interrupt): Use
scoped_disable_commit_resumed in the --thread-group case.

gdb/testsuite/ChangeLog:

* gdb.mi/interrupt-thread-group.c: New.
* gdb.mi/interrupt-thread-group.exp: New.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28077
Change-Id: I615efefcbcaf2c15d47caf5e4b9d82854b2a2fcb

Fix some dangling references to `netbsd-tdep`

These files were renamed in 1b71cfcfdc3e13a655fefa6566b5564cec044c10,
but evidentially a few dangling references were left behind. This causes
builds to fail:

    $ ./configure --target i686-netbsdelf
    $ make
    make: *** No rule to make target 'nbsd-tdep.c', needed by 'nbsd-tdep.o'.  Stop.

gdb/ChangeLog:

* sparc-tdep.h: Fix comment.
* netbsd-tdep.c (nbsd_info_proc_mappings_header): Fix comment.
(nbsd_init_abi): Fix comment.
* configure.tgt (*-*-netbsd* | *-*-knetbsd*-gnu): Fix netbsd
file name.
(alpha*-*-openbsd*): Likewise.
(sparc-*-openbsd*): Likewise.
(sparc64-*-openbsd*): Likewise.

Change-Id: I18a0873902dccadd238615577aac4e08772fa2c8

Automatic date update in version.in

[gdb/testsuite] Fix gdb.btrace/tsx.exp on system with tsx disabled in microcode

Recently I started to see this fail with trunk:
...
(gdb) record instruction-history^M
1          0x00000000004004ab <main+4>: call   0x4004b7 <test>^M
2          0x00000000004004c6 <test+15>:        mov    $0x1,%eax^M
3          0x00000000004004cb <test+20>:        ret    ^M
(gdb) FAIL: gdb.btrace/tsx.exp: speculation indication
...

This is due to an intel microcode update (1) that disables Intel TSX by default.

Fix this by updating the pattern.

Tested on x86_64-linux, with both gcc 7.5.0 and clang 12.0.1.

[1] https://www.intel.com/content/www/us/en/support/articles/000059422/processors.html

gdb/testsuite/ChangeLog:

2021-07-12  Tom de Vries  <tdevries@suse.de>

PR testsuite/28057
* gdb.btrace/tsx.exp: Add pattern for system with tsx disabled in
microcode.

[gdb/testsuite] Fix gdb.mi/mi-info-sources.exp for extra debug info

When running test-case gdb.mi/mi-info-sources.exp, I run into:
...
Running src/gdb/testsuite/gdb.mi/mi-info-sources.exp ...
ERROR: internal buffer is full.
...
due to extra debug info from the shared libraries.

Fix this by using "nosharedlibrary".

Then I run into these FAILs:
...
FAIL: gdb.mi/mi-info-sources.exp: debug_read=false: \
  -file-list-exec-source-files (unexpected output)
FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \
  -file-list-exec-source-files (unexpected output)
FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \
  -file-list-exec-source-files --group-by-objfile, look for \
  mi-info-sources.c (unexpected output)
FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \
  -file-list-exec-source-files --group-by-objfile, look for \
  mi-info-sources-base.c (unexpected output)
...
due to openSUSE executables which have debug info for objects from sources
like sysdeps/x86_64/crtn.S.

Fix these by updating the patterns, and adding "maint expand-symtabs" to
reliably get fully-read objfiles.

Then I run into FAILs when using the readnow target board.  Fix these by
skipping the relevant tests.

Then I run into FAILs when using the cc-with-gnu-debuglink board.  Fix these
by updating the patterns.

Tested on x86_64-linux, with native, check-read1, readnow, cc-with-gdb-index,
cc-with-debug-names, cc-with-gnu-debuglink, cc-with-dwz, cc-with-dwz-m.

gdb/testsuite/ChangeLog:

2021-07-12  Tom de Vries  <tdevries@suse.de>

* lib/mi-support.exp (mi_readnow): New proc.
* gdb.mi/mi-info-sources.exp: Use nosharedlibrary.  Update patterns.
Skip tests for readnow.  Use "maint expand-symtabs".

Automatic date update in version.in

Fix warning in symtab.c

The compiler gives this warning when building symtab.c:

../../binutils-gdb/gdb/symtab.c:4247:28: warning: 'to_match' may be used uninitialized in this function [-Wmaybe-uninitialized]

This patch fixes the warning by adding a gdb_assert_not_reached.

gdb/ChangeLog:

        * gdb/symtab.c (info_sources_filter::matches): Add default
        case hander in switch statement.

(cherry picked from commit b6aeb717a8bdaa9cc348ec88a5fdf059e1337580)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb: don't set Linux-specific displaced stepping methods in s390_gdbarch_init

According to bug 28056, running an s390x binary gives:

    (gdb) run
    Starting program: /usr/bin/ls
    /home/ubuntu/tmp/gdb-11.0.90.20210705/gdb/linux-tdep.c:2550: internal-error: displaced_step_prepare_status linux_displaced_step_prepare(gdbarch*, thread_info*, CORE_ADDR&): Assertion `gdbarch_data->num_disp_step_buffers > 0' failed.

This is because the s390 architecture registers some Linux-specific
displaced stepping callbacks in the OS-agnostic s390_gdbarch_init:

    set_gdbarch_displaced_step_prepare (gdbarch, linux_displaced_step_prepare);
    set_gdbarch_displaced_step_finish (gdbarch, linux_displaced_step_finish);
    set_gdbarch_displaced_step_restore_all_in_ptid
      (gdbarch, linux_displaced_step_restore_all_in_ptid);

But then the Linux-specific s390_linux_init_abi_any passes
num_disp_step_buffers=0 to linux_init_abi:

    linux_init_abi (info, gdbarch, 0);

The problem happens when linux_displaced_step_prepare is called for the
first time.  It tries to allocate the displaced stepping buffers, but
sees that the number of displaced stepping buffers for that architecture
is 0, which is unexpected / invalid.

s390_gdbarch_init should not register the linux_* callbacks, that is
expected to be done by linux_init_abi.  If debugging a bare-metal s390
program, or an s390 program on another OS GDB doesn't know about, we
wouldn't want to use them.  We would either register no callbacks, if
displaced stepping isn't supported, or register a different set of
callbacks if we wanted to support displaced stepping in those cases.

The commit that refactored the displaced stepping machinery and
introduced these set_gdbarch_displaced_step_* calls is 187b041e2514
("gdb: move displaced stepping logic to gdbarch, allow starting
concurrent displaced steps").  However, even before that,
s390_gdbarch_init did:

  set_gdbarch_displaced_step_location (gdbarch, linux_displaced_step_location);

... which already seemed wrong.  The Linux-specific callback was used
even for non-Linux system.  Maybe that was on purpose, because it would
also happen to work in some other non-Linux case, or maybe it was simply
a mistake.  I'll assume that this was a small mistake when
s390-tdep.{h,c} where factored out of s390-linux-tdep.c, in d6e589456475
("s390: Split up s390-linux-tdep.c into two files").

Fix this by removing the setting of these displaced step callbacks from
s390_gdbarch_init.  Instead, pass num_disp_step_buffers=1 to
linux_init_abi, in s390_linux_init_abi_any.  Doing so will cause
linux_init_abi to register these same callbacks.  It will also mean that
when debugging a bare-metal s390 executable or an executable on another
OS that GDB doesn't know about, gdbarch_displaced_step_prepare won't be
set, so displaced stepping won't be used.

This patch will need to be merged in the gdb-11-branch, since this is a
GDB 11 regression, so here's the ChangeLog entry:

gdb/ChangeLog:

* s390-linux-tdep.c (s390_linux_init_abi_any): Pass 1 (number
of displaced stepping buffers to linux_init_abi.
* s390-tdep.c (s390_gdbarch_init): Don't set the Linux-specific
displaced-stepping gdbarch callbacks.

Change-Id: Ieab2f8990c78fde845ce7378d6fd4ee2833800d5
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28056

gdb/Makefile.in: remove testsuite from SUBDIRS

When distclean-ing a configured / built gdb directory, like so:

    $ ./configure && make all-gdb && make distclean

The distclean operation fails with:

    Missing testsuite/Makefile

If we look at the SUBDIRS variable in the generated gdb/Makefile,
testsuite is there twice:

    SUBDIRS = doc  testsuite data-directory testsuite

So we try distclean-ing the testsuite directory twice.  The second time,
gdb/testsuite/Makefile doesn't exist, so it fails.

The first "testsuite" comes from the @subdirs@ replacement, because of
the `AC_CONFIG_SUBDIRS` macro in gdb/configure.ac.  The second one is
hard-coded in gdb/Makefile.in:

    SUBDIRS = doc @subdirs@ data-directory testsuite

The hard-coded was added by:

    bdbbcd577460 ("Always build 'all' in gdb/testsuite")

which came after `testsuite` was removed from @subdirs@ by:

    f99d1d37496f ("Remove gdb/testsuite/configure")

My commit a100a94530eb ("gdb/testsuite: restore configure script")
should have removed the hard-coded `testsuite`, since it added it back
as a "subdir", but I missed it because I only looked f99d1d37496f to
write my patch.

Fix this by removing the hard-coded one.

This patch should be pushed to both master and gdb-11-branch, hence the
ChangeLog entry:

gdb/ChangeLog:

* Makefile.in (SUBDIRS): Remove testsuite.

Change-Id: I63e5590b1a08673c646510b3ecc74600eae9f92d

[gdb/testsuite] Fix gdb.guile/scm-breakpoint.exp with guile 3.0

When running test-case gdb.guile/scm-breakpoint.exp on openSUSE Tumbleweed
with guile 3.0, I run into:
...
(gdb) guile (define cp (make-breakpoint "syscall" #:type BP_CATCHPOINT))^M
ERROR: In procedure make-breakpoint:^M
In procedure gdbscm_make_breakpoint: unsupported breakpoint type in \
  position 3: "BP_CATCHPOINT"^M
Error while executing Scheme code.^M
(gdb) FAIL: gdb.guile/scm-breakpoint.exp: test_catchpoints: \
  create a catchpoint via the api
...

The same test passes on openSUSE Leap 15.2 with guile 2.0, where the second
line of the error message starts with the same prefix as the first:
...
ERROR: In procedure gdbscm_make_breakpoint: unsupported breakpoint type in \
  position 3: "BP_CATCHPOINT"^M
...

I observe the same difference in many other tests, f.i.:
...
(gdb) gu (print (value-add i '()))^M
ERROR: In procedure value-add:^M
In procedure gdbscm_value_add: Wrong type argument in position 2: ()^M
Error while executing Scheme code.^M
(gdb) PASS: gdb.guile/scm-math.exp: catch error in guile type conversion
...
but it doesn't cause FAILs anywhere else.

Fix this by updating the regexp to make the "ERROR: " prefix optional.

Tested on x86_64-linux, with both guile 2.0 and 3.0.

gdb/testsuite/ChangeLog:

2021-07-08  Tom de Vries  <tdevries@suse.de>

* gdb.guile/scm-breakpoint.exp: Make additional "ERROR: " prefix in
exception printing optional.

Automatic date update in version.in

Automatic date update in version.in

gdb/testsuite: restore configure script

Commit f99d1d37496f ("Remove gdb/testsuite/configure") removed
gdb/testsuite/configure, as anything gdb/testsuite/configure did could
be done by gdb/configure.

There is however one use case that popped up when this changed
propagated to downstream consumers, to run the testsuite on an already
built GDB.  In the workflow of ROCm-GDB at AMD, a GDB package is built
in a CI job.  This GDB package is then tested on different machines /
hardware configurations as part of other CI jobs.  To achieve this,
those CI jobs only configure the testsuite directory and run "make
check" with an appropriate board file.

In light of this use case, the way I see it is that gdb/testsuite could
be considered its own project.  It could be stored in a completely
different repo if we want to, it just happens to be stored inside gdb/.

Since the only downside of having gdb/testsuite/configure is that it
takes a few more seconds to run, but on the other hand it's quite useful
for some people, I propose re-adding it.

In a sense, this is revert of f99d1d37496f, but it's not a direct
git-revert, as some things have changed since.

gdb/ChangeLog:

* configure.ac: Remove things that were moved from
testsuite/configure.ac.
* configure: Re-generate.

gdb/testsuite/ChangeLog:

* configure.ac: Restore.
* configure: Re-generate.
* aclocal.m4: Re-generate.
* Makefile.in (distclean): Add config.status.
(Makefile): Adjust paths.
(lib/pdtrace): Adjust paths.
(config.status): Add.

Change-Id: Ic38c79485e1835712d9c99649c9dfb59667254f1

[gdb/testsuite] Fix fail in gdb.fortran/ptype-on-functions.exp with gcc-7

Since commit 05b85772061 "gdb/fortran: Add type info of formal parameter for
clang" I see:
...
(gdb) ptype say_string^M
type = void (character*(*), integer(kind=4))^M
(gdb) FAIL: gdb.fortran/ptype-on-functions.exp: ptype say_string
...

The part of the commit causing the fail is:
...
 gdb_test "ptype say_string" \
-    "type = void \\(character\\*\\(\\*\\), integer\\(kind=\\d+\\)\\)"
+    "type = void \\(character\[^,\]+, $integer8\\)"
...
which fails to take into account that for gcc-7 and before, the type for
string length of a string argument is int, not size_t.

Fix this by allowing both $integer8 and $integer4.

Tested on x86_64-linux, with gcc-7 and gcc-10.

gdb/testsuite/ChangeLog:

2021-07-06  Tom de Vries  <tdevries@suse.de>

* gdb.fortran/ptype-on-functions.exp: Allow both $integer8 and
$integer4 for size of string length.

Automatic date update in version.in

gdb: fall back on sigpending + sigwait if sigtimedwait is not available

The macOS platform does not provide sigtimedwait, so we get:

      CXX    compile/compile.o
    In file included from /Users/smarchi/src/binutils-gdb/gdb/compile/compile.c:46:
    /Users/smarchi/src/binutils-gdb/gdb/../gdbsupport/scoped_ignore_signal.h:69:4: error: use of undeclared identifier 'sigtimedwait'
              sigtimedwait (&set, nullptr, &zero_timeout);
              ^

An alternative to sigtimedwait with a timeout of 0 is to use sigpending,
to first check which signals are pending, and then sigwait, to consume
them.  Since that's slightly more expensive (2 syscalls instead of 1),
keep using sigtimedwait for the platforms that provide it, and fall back
to sigpending + sigwait for the others.

gdbsupport/ChangeLog:

* scoped_ignore_signal.h (struct scoped_ignore_signal)
<~scoped_ignore_signal>: Use sigtimedwait if HAVE_SIGTIMEDWAIT
is defined, else use sigpending + sigwait.

Change-Id: I2a72798337e81dd1bbd21214736a139dd350af87
Co-Authored-By: John Baldwin <jhb@FreeBSD.org>

gdbsupport/common.m4: check for sigtimedwait

The next patch will make the use of sigtimedwait conditional to whether
the platform provides it.  Start by adding a configure check for it.

gdbsupport/ChangeLog:

* common.m4 (GDB_AC_COMMON): Check for sigtimedwait.
* config.in, configure: Re-generate.

gdb/ChangeLog:

* config.in, configure: Re-generate.

gdbserver/ChangeLog:

* config.in, configure: Re-generate.

Change-Id: Ic7613fe14521b966b4d991bbcd0933ab14629c05

Automatic date update in version.in

gdb: return early if no execution in darwin_solib_create_inferior_hook

When loading a file using the file command on macOS, we get:

    $ ./gdb -nx --data-directory=data-directory -q -ex "file ./test"
    Reading symbols from ./test...
    Reading symbols from /Users/smarchi/build/binutils-gdb/gdb/test.dSYM/Contents/Resources/DWARF/test...
    /Users/smarchi/src/binutils-gdb/gdb/thread.c:72: internal-error: struct thread_info *inferior_thread(): Assertion `current_thread_ != nullptr' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    Quit this debugging session? (y or n)

The backtrace is:

    * frame #0: 0x0000000101fcb826 gdb`internal_error(file="/Users/smarchi/src/binutils-gdb/gdb/thread.c", line=72, fmt="%s: Assertion `%s' failed.") at errors.cc:52:3
      frame #1: 0x00000001018a2584 gdb`inferior_thread() at thread.c:72:3
      frame #2: 0x0000000101469c09 gdb`get_current_regcache() at regcache.c:421:31
      frame #3: 0x00000001015f9812 gdb`darwin_solib_get_all_image_info_addr_at_init(info=0x0000603000006d00) at solib-darwin.c:464:34
      frame #4: 0x00000001015f7a04 gdb`darwin_solib_create_inferior_hook(from_tty=1) at solib-darwin.c:515:5
      frame #5: 0x000000010161205e gdb`solib_create_inferior_hook(from_tty=1) at solib.c:1200:3
      frame #6: 0x00000001016d8f76 gdb`symbol_file_command(args="./test", from_tty=1) at symfile.c:1650:7
      frame #7: 0x0000000100abab17 gdb`file_command(arg="./test", from_tty=1) at exec.c:555:3
      frame #8: 0x00000001004dc799 gdb`do_const_cfunc(c=0x000061100000c340, args="./test", from_tty=1) at cli-decode.c:102:3
      frame #9: 0x00000001004ea042 gdb`cmd_func(cmd=0x000061100000c340, args="./test", from_tty=1) at cli-decode.c:2160:7
      frame #10: 0x00000001018d4f59 gdb`execute_command(p="t", from_tty=1) at top.c:674:2
      frame #11: 0x0000000100eee430 gdb`catch_command_errors(command=(gdb`execute_command(char const*, int) at top.c:561), arg="file ./test", from_tty=1, do_bp_actions=true)(char const*, int), char const*, int, bool) at main.c:523:7
      frame #12: 0x0000000100eee902 gdb`execute_cmdargs(cmdarg_vec=0x00007ffeefbfeba0 size=1, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x00007ffeefbfec20) at main.c:618:9
      frame #13: 0x0000000100eed3a4 gdb`captured_main_1(context=0x00007ffeefbff780) at main.c:1322:3
      frame #14: 0x0000000100ee810d gdb`captured_main(data=0x00007ffeefbff780) at main.c:1343:3
      frame #15: 0x0000000100ee8025 gdb`gdb_main(args=0x00007ffeefbff780) at main.c:1368:7
      frame #16: 0x00000001000044f1 gdb`main(argc=6, argv=0x00007ffeefbff8a0) at gdb.c:32:10
      frame #17: 0x00007fff20558f5d libdyld.dylib`start + 1

The solib_create_inferior_hook call in symbol_file_command was added by
commit ea142fbfc9c1 ("Fix breakpoints on file reloads for PIE
binaries").  It causes solib_create_inferior_hook to be called while
the inferior is not running, which darwin_solib_create_inferior_hook
does not expect.  darwin_solib_get_all_image_info_addr_at_init, in
particular, assumes that there is a current thread, as it tries to get
the current thread's regcache.

Fix it by adding a target_has_execution check and returning early.  Note
that there is a similar check in svr4_solib_create_inferior_hook.

gdb/ChangeLog:

* solib-darwin.c (darwin_solib_create_inferior_hook): Return
early if no execution.

Change-Id: Ia11dd983a1e29786e5ce663d0fcaa6846dc611bb

Automatic date update in version.in

Bump GDB version number to 11.0.90.DATE-git.

gdb/ChangeLog:

* version.in: Set GDB version number to 11.0.90.DATE-git.

Document the GDB 11.0.90 release in gdb/ChangeLog

gdb/ChangeLog:

GDB 11.0.90 released.

Set GDB version number to 11.0.90.

gdb/ChangeLog:

* version.in: Set GDB version number to 11.0.90.

gdb/NEWS: Replace "Changes since GDB 10" by "Changes in GDB 11".

gdb/ChangeLog:

        * NEWS: Replace "Changes since GDB 10" by "Changes in GDB 11".

Set development mode to "off" by default.

bfd/ChangeLog:

* development.sh (development): Set to false.

Bump version to 11.0.90.DATE-git.

Now that the GDB 11 branch has been created, we can
bump the version number.

gdb/ChangeLog:

GDB 11 branch created (4b51505e33441c6165e7789fa2b6d21930242927):
* version.in: Bump version to 11.0.90.DATE-git.

More minor updates to the how-to-make-a-release documentation

Update version number and regenerate files

Add markers for 2.37 branch

Synchronize libiberty sources (and include/demangle.h) with GCC master version

Automatic date update in version.in

Use 'const' in ada-exp.y

I found a few spots in ada-exp.y that could use 'const'.
Tested by rebuilding.

2021-07-02  Tom Tromey  <tromey@adacore.com>

* ada-exp.y (chop_selector, chop_separator, write_selectors)
(write_ambiguous_var, get_symbol_field_type): Use const.

Document TUI improvements in the manual & NEWS

gdb/ChangeLog:
yyyy-mm-dd  Pedro Alves  <pedro@palves.net>
    Hannes Domani  <ssbssa@yahoo.de>

* NEWS: Add new "TUI Improvements" section and mention mouse
support and that unrecognized special keys are now passed to
GDB.  Mention Python Window.click in the Python improvements
section.

gdb/doc/ChangeLog:
yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

* gdb.texinfo (TUI): <TUI Mouse Support>: New node/section.

Co-Authored-By: Hannes Domani <ssbssa@yahoo.de>
Change-Id: I0d79a795d8ac561fd28cdc5184bff029ba28bc64

Fix an illegal memory access triggered by an attempt to parse a corrupt input file.

PR 28046
* dwarf2.c (read_ranges): Check that range_ptr does not exceed
range_end.

PR28048, heap-buffer-overflow on readelf -Ww

PR 28048
* dwarf.c (get_type_signedness): Don't run off end of buffer
printing DW_FORM_string attribute.

Re: Fix minor NDS32 renaming snafu

Some extern declarations differ in constnes to their definitions too.
Let's make sure this sort of thing doesn't happen again, but putting
the externs in a header where they belong.

gas/
* config/tc-nds32.c (nds32_keyword_gpr): Don't declare.
(md_begin): Constify k.
opcodes/
* nds32-dis.c (nds32_find_reg_keyword): Constify arg and return.
(nds32_parse_audio_ext, nds32_parse_opcode): Constify psys_reg.
(nds32_field_table, nds32_opcode_table, nds32_keyword_table),
(nds32_opcodes, nds32_operand_fields, nds32_keywords),
(nds32_keyword_gpr): Move declarations to..
* nds32-asm.h: ..here, constifying to match definitions.

Fix minor NDS32 renaming snafu.

* config/tc-nds32.c: Change all references of keyword_gpr to
nds32_keyword_gpr.

sim: unify reserved instruction bits settings

Move these options up to the common dir so we only test & export
them once across all ports.

The setting only affects igen based ports, and they were turning
this on by default, so keep the default in place.

sim: m32r: merge with common configure script

Now that the traps code has been unified, the configure script has no
unique logic in it, so it can be merged into the single common one.

sim: m32r: reformat linux traps code

Do this as a sep commit to try and make the history easier to review.

sim: m32r: unify ELF & Linux traps logic

This makes the simulator work the same regardless of the target (bare
metal m32r-elf or Linux m32r-linux-gnu) by unifying the traps code.
It was mostly already the same with the only difference being support
for trap #2 reserved for Linux syscalls.  We can move that logic to
runtime by checking the current environment operating mode instead.

sim: m32r: replace custom endian helpers with sim-endian

This improves the logic a bit by making the host<->target translations
a bit more clear.  The structs still bleed way too much between the two
worlds, but let's fix one thing at a time.

sim: m32r: fix virtual environment with Linux targets

We don't want to handle Linux syscalls when in the virtual environment,
just the user environment, so adjust the Linux traps logic to check for
that specifically (instead of just skipping the operating environment).

Also tweak some testcases to explicitly specify the environment they run
under rather than relying on the default matching their needs.  This gets
the tests passing for all m32r targets.

sim: m32r: namespace Linux syscall table

The use of __NR_ defines in here conflicts a lot with the standard
host syscalls, sometimes leading to build errors (when the numbers
happen to be the same we get duplicate case handlers), and other
times leading to misbehavior (where the m32r syscall # is not what
is actually checked).

Namespace these using the standard that we already use: change the
__NR_ to TARGET_LINUX_SYS_ with a simple `sed`.

Also add a few missing includes so the code at least compiles.

Automatic date update in version.in

cgen: split GUILE setting out

This makes it easier to override to point to an older version of guile.
The current cgen code doesn't work with guile-2, so need to point to an
older guile-1.8.

opcodes: constify & local meps macros

Avoid exporting this common variable name into writable data.

opcodes: cleanup nds32 variables

For the variables that don't need to be exported, mark them static.
For the ones shared between modules, add a "nds32_" prefix to avoid
collisions with these common variable names.

opcodes: constify & localize z80 opcodes

These aren't used outside of this module, and are never modified.
Mark it static to avoid bad exported variable name issues.

opcodes: constify & scope microblaze opcodes

This is exporting the variable "opcodes" as a large writable blob.
This is not a namespace friendly name, so add a "microblaze" prefix,
and then sprinkle const over its definition & use.

opcodes: constify aarch64_opcode_tables

This table is huge (~350k), so stop putting it into writable .data
since it's only const data.

Partially fix debuginfod tests in binutils testsuite.

PR 28029
* testsuite/binutils-all/debuginfod.exp: Replace -wK with -wk.

Linux: Access memory even if threads are running

Currently, on GNU/Linux, if you try to access memory and you have a
running thread selected, GDB fails the memory accesses, like:

 (gdb) c&
 Continuing.
 (gdb) p global_var
 Cannot access memory at address 0x555555558010

Or:

 (gdb) b main
 Breakpoint 2 at 0x55555555524d: file access-mem-running.c, line 59.
 Warning:
 Cannot insert breakpoint 2.
 Cannot access memory at address 0x55555555524d

This patch removes this limitation.  It teaches the native Linux
target to read/write memory even if the target is running.  And it
does this without temporarily stopping threads.  We now get:

 (gdb) c&
 Continuing.
 (gdb) p global_var
 $1 = 123
 (gdb) b main
 Breakpoint 2 at 0x555555555259: file access-mem-running.c, line 62.

(The scenarios above work correctly with current GDBserver, because
GDBserver temporarily stops all threads in the process whenever GDB
wants to access memory (see prepare_to_access_memory /
done_accessing_memory).  Freezing the whole process makes sense when
we need to be sure that we have a consistent view of memory and don't
race with the inferior changing it at the same time as GDB is
accessing it.  But I think that's a too-heavy hammer for the default
behavior.  I think that ideally, whether to stop all threads or not
should be policy decided by gdb core, probably best implemented by
exposing something like gdbserver's prepare_to_access_memory /
done_accessing_memory to gdb core.)

Currently, if we're accessing (reading/writing) just a few bytes, then
the Linux native backend does not try accessing memory via
/proc/<pid>/mem and goes straight to ptrace
PTRACE_PEEKTEXT/PTRACE_POKETEXT.  However, ptrace always fails when
the ptracee is running.  So the first step is to prefer
/proc/<pid>/mem even for small accesses.  Without further changes
however, that may cause a performance regression, due to constantly
opening and closing /proc/<pid>/mem for each memory access.  So the
next step is to keep the /proc/<pid>/mem file open across memory
accesses.  If we have this, then it doesn't make sense anymore to even
have the ptrace fallback, so the patch disables it.

I've made it such that GDB only ever has one /proc/<pid>/mem file open
at any time.  As long as a memory access hits the same inferior
process as the previous access, then we reuse the previously open
file.  If however, we access memory of a different process, then we
close the previous file and open a new one for the new process.

If we wanted, we could keep one /proc/<pid>/mem file open per
inferior, and never close them (unless the inferior exits or execs).
However, having seen bfd patches recently about hitting too many open
file descriptors, I kept the logic to have only one file open tops.
Also, we need to handle memory accesses for processes for which we
don't have an inferior object, for when we need to detach a
fork-child, and we'd probaly want to handle caching the open file for
that scenario (no inferior for process) too, which would probably end
up meaning caching for last non-inferior process, which is very much
what I'm proposing anyhow.  So always having one file open likely ends
up a smaller patch.

The next step is handling the case of GDB reading/writing memory
through a thread that is running and exits.  The access should not
result in a user-visible failure if the inferior/process is still
alive.

Once we manage to open a /proc/<lwpid>/mem file, then that file is
usable for memory accesses even if the corresponding lwp exits and is
reaped.  I double checked that trying to open the same
/proc/<lwpid>/mem path again fails because the lwp is really gone so
there's no /proc/<lwpid>/ entry on the filesystem anymore, but the
previously open file remains usable.  It's only when the whole process
execs that we need to reopen a new file.

When the kernel destroys the whole address space, i.e., when the
process exits or execs, the reads/writes fail with 0 aka EOF, in which
case there's nothing else to do than returning a memory access
failure.  Note this means that when we get an exec event, we need to
reopen the file, to access the process's new address space.

If we need to open (or reopen) the /proc/<pid>/mem file, and the LWP
we're opening it for exits before we open it and before we reap the
LWP (i.e., the LWP is zombie), the open fails with EACCES.  The patch
handles this by just looking for another thread until it finds one
that we can open a /proc/<pid>/mem successfully for.

If we need to open (or reopen) the /proc/<pid>/mem file, and the LWP
we're opening has exited and we already reaped it, which is the case
if the selected thread is in THREAD_EXIT state, the open fails with
ENOENT.  The patch handles this the same way as a zombie race
(EACCES), instead of checking upfront whether we're accessing a
known-exited thread, because that would result in more complicated
code, because we also need to handle accessing lwps that are not
listed in the core thread list, and it's the core thread list that
records the THREAD_EXIT state.

The patch includes two testcases:

#1 - gdb.base/access-mem-running.exp

  This is the conceptually simplest - it is single-threaded, and has
  GDB read and write memory while the program is running.  It also
  tests setting a breakpoint while the program is running, and checks
  that the breakpoint is hit immediately.

#2 - gdb.threads/access-mem-running-thread-exit.exp

  This one is more elaborate, as it continuously spawns short-lived
  threads in order to exercise accessing memory just while threads are
  exiting.  It also spawns two different processes and alternates
  accessing memory between the two processes to exercise the reopening
  the /proc file frequently.  This also ends up exercising GDB reading
  from an exited thread frequently.  I confirmed by putting abort()
  calls in the EACCES/ENOENT paths added by the patch that we do hit
  all of them frequently with the testcase.  It also exits the
  process's main thread (i.e., the main thread becomes zombie), to
  make sure accessing memory in such a corner-case scenario works now
  and in the future.

The tests fail on GNU/Linux native before the code changes, and pass
after.  They pass against current GDBserver, again because GDBserver
supports memory access even if all threads are running, by
transparently pausing the whole process.

gdb/ChangeLog:
yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

PR mi/15729
PR gdb/13463
* linux-nat.c (linux_nat_target::detach): Close the
/proc/<pid>/mem file if it was open for this process.
(linux_handle_extended_wait) <PTRACE_EVENT_EXEC>: Close the
/proc/<pid>/mem file if it was open for this process.
(linux_nat_target::mourn_inferior): Close the /proc/<pid>/mem file
if it was open for this process.
(linux_nat_target::xfer_partial): Adjust.  Do not fall back to
inf_ptrace_target::xfer_partial for memory accesses.
(last_proc_mem_file): New.
(maybe_close_proc_mem_file): New.
(linux_proc_xfer_memory_partial_pid): New, with bits factored out
from linux_proc_xfer_partial.
(linux_proc_xfer_partial): Delete.
(linux_proc_xfer_memory_partial): New.

gdb/testsuite/ChangeLog
yyyy-mm-dd  Pedro Alves  <pedro@palves.net>

PR mi/15729
PR gdb/13463
* gdb.base/access-mem-running.c: New.
* gdb.base/access-mem-running.exp: New.
* gdb.threads/access-mem-running-thread-exit.c: New.
* gdb.threads/access-mem-running-thread-exit.exp: New.

Change-Id: Ib3c082528872662a3fc0ca9b31c34d4876c874c9

readelf: Reset file position to beginning for thin archive members

* readelf.c (process_archive): Reset file position to the
beginning when calling process_object for thin archive members.
* testsuite/binutils-all/readelf.exp: Add test.
* testsuite/binutils-all/readelf.h.thin: New file.

arm: don't treat XScale features as part of the FPU [PR 28031]

Although the XScale and its iwMMX extensions are implemented in the
Arm co-processor space, they are not considered to be part of the FPU
specification.  In particular, they cannot be enabled or disabled via
a .fpu directive.  It's therefore incorrect to strip these properties
when a new .fpu directive is encountered.

Note that the legacy Maverick co-processor is considered to be a FPU
and it is possible to control this via the .fpu directive.

include:

PR gas/28031
* opcode/arm.h (FPU_ANY): Exclude XScale-related features.

Automatic date update in version.in

sim: ppc: unify (most) compiler warnings with common code

Copy most of the common build warning logic over from the common
code to help keep code behavior a bit consistent, and turn them
on by default.  We disable a few flags for now until we can clean
the code up.

sim: cris/frv/iq2000/lm32: merge with common configure script

Now that the scache logic has been migrated into the common code,
there's nothing specific in these configure scripts, so merge them
into the common one.

The frv unique logic can be moved to a dedicated include and merged
in the common configure since the flag has been scoped to the arch.

sim: unify scache settings

The cgen scache module is enabled by every cgen port, and with the
same default value of 16k (which matches the common default value).
Let's pull this option out of the individual ports (via CPPFLAGS)
and into the common code (via config.h).

The object itself is compiled only for cgen ports atm, so that part
doesn't change.  The scache code is initialized dynamically via the
modules.c logic.  That's why the profile code needs an additional
CGEN_ARCH check.

This will allow us to collapse arch configure files more.  Merging
the source files will require more future work, but integrating the
cgen & non-cgen worlds itself will take a lot.

sim: frv: scope the unique configure flag

This will make it possible to merge into the common configure by
making sure we never collide with other arches.

sim: move scache init to dynamic modules.c

Use the new modules.c framework to find & initialize this module.

sim: move profile init to dynamic modules.c

Use the new modules.c framework to find & initialize this module.

sim: move trace init to dynamic modules.c

Use the new modules.c framework to find & initialize this module.