x86: express unduly set rounding control bits in disassembly

While EVEX.L'L are indeed ignored when EVEX.b stands for just SAE,
EVEX.b itself is not ignored when an insn permits neither rounding
control nor SAE.

While changing this aspect of EVEX.b handling, also alter unduly set
embedded broadcast: Don't call BadOp(), screwing up subsequent
disassembly, but emit "{bad}" instead.

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.

x86: drop dq{b,d}_mode

Their sole use is for {,V}EXTRACTPS / {,V}P{EXT,INS}RB respectively; for
consistency also limit use of dqw_mode to Jdqw. 64-bit disassembly
reflecting REX.W / VEX.W is not in line with the assembler's opcode
table having NoRex64 / VexWIG in all respective templates, i.e. assembly
input isn't being honored there either. Obviously the 0FC5 encodings of
{,V}PEXTRW then also need adjustment for consistency reasons.

x86: drop vex_scalar_w_dq_mode

It has only a single use and can easily be represented by dq_mode
instead. Plus its handling in intel_operand_size() was duplicating
that of vex_vsib_{d,q}_w_dq_mode anyway.

x86: drop xmm_m{b,w,d,q}_mode

They're effectively redundant with {b,w,d,q}_mode.

x86: fold duplicate vector register printing code

The bulk of OP_XMM() can be easily reused also for OP_EX(). Break the
shared logic out of the function, and invoke the new helper from both
places.

x86: drop vex_mode and vex_scalar_mode

These are fully redundant with, respectively, x_mode and scalar_mode.

x86: correct EVEX.V' handling outside of 64-bit mode

Unlike the high bit of VEX.vvvv / EVEX.vvvv, EVEX.V' is not ignored
outside of 64-bit mode. Oddly enough there already are tests for these
cases, but their expectations were wrong. (This may have been based on
an old SDM version, where the restriction wasn't properly spelled out.)

x86: fold duplicate code in MOVSXD_Fixup()

There's no need to have two paths printing the "xd" mnemonic suffix.

x86: fold duplicate register printing code

What so far was OP_E_register() can be easily reused also for OP_G().
Add suitable parameters to the function and move the invocation of
swap_operand() to OP_E(). Adjust MOVSXD's first operand: There never was
a need to use movsxd_mode there, and its use gets in the way of the code
folding.

x86-64: properly bounds-check %bnd<N> in OP_G()

The restriction to %bnd0-%bnd3 requires to also check REX.R is clear,
just like OP_E_Register() also includes REX.B in its check.

x86-64: generalize OP_G()'s EVEX.R' handling

EVEX.R' is invalid to be clear not only for mask registers, but also for
GPRs - IOW everything handled in this function.

x86: correct VCVT{,U}SI2SD rounding mode handling

With EVEX.W clear the instruction doesn't ignore the rounding mode, but
(like for other insns without rounding semantics) EVEX.b set causes #UD.
Hence the handling of EVEX.W needs to be done when processing
evex_rounding_64_mode, not at the decode stages.

Derive a new 64-bit testcase from the 32-bit one to cover the different
EVEX.W treatment in both cases.

x86: drop OP_Mask()

By moving its vex.r check there it becomes fully redundant with OP_G().

Automatic date update in version.in

[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-20  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.

Updated Russian translation for the bfd library

Allows linker scripts to set the SEC_READONLY flag.

* ld.texi: Document new output section type.
* ldgram.y: Add new token.
* ldlang.c: Handle the new flag.
* ldlang.h: Add readonly_section to list of section types.
* ldlex.l: Add a new identifier.
* testsuite/ld-scripts/output-section-types.t: New example linker script.
* testsuite/ld-scripts/output-section-types.d: Test driver.
* testsyute/ld-scripts/script.exp: Run the new test.

[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-20  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.

as_bad_subtract

Many places report errors of the nature "can't resolve a - b".
This provides a utility function to report such errors consistently.
I removed the section reporting and quotes around symbol names while I
was at it.  Compare
ifunc-2.s:4: Error: can't resolve `bar1' {.text.1 section} - `foo1' {.text.1 section}
with
ifunc-2.s:4: Error: can't resolve bar1 - foo1

In many cases the section names don't help the user very much in
figuring out what went wrong, and the quotes if present arguably ought
to be placed around the entire expression:
can't resolve `bar1 - foo1'

The patch also tidies some tc_get_reloc functions that leak memory on
error paths.

* write.h (as_bad_subtract): Declare.
* write.c (as_bad_subtract): New function.
(fixup_segment): Use as_bad_subtract.
* config/tc-arc.c (md_apply_fix): Likewise.
* config/tc-avr.c (md_apply_fix, tc_gen_reloc): Likewise.
* config/tc-cris.c (md_apply_fix): Likewise.
* config/tc-d10v.c (md_apply_fix): Likewise.
* config/tc-d30v.c (md_apply_fix): Likewise.
* config/tc-ft32.c (md_apply_fix): Likewise.
* config/tc-h8300.c (tc_gen_reloc): Likewise.
* config/tc-m68hc11.c (md_apply_fix): Likewise.
* config/tc-mmix.c (mmix_frob_file): Likewise.
* config/tc-mn10200.c (tc_gen_reloc): Likewise.
* config/tc-nds32.c (nds32_apply_fix): Likewise.
* config/tc-pru.c (md_apply_fix): Likewise.
* config/tc-riscv.c (md_apply_fix): Likewise.
* config/tc-s12z.c (md_apply_fix): Likewise.
* config/tc-s390.c (md_apply_fix): Likewise.
* config/tc-tilegx.c (md_apply_fix): Likewise.
* config/tc-tilepro.c (md_apply_fix): Likewise.
* config/tc-v850.c (md_apply_fix): Likewise.
* config/tc-vax.c (md_apply_fix): Likewise.
* config/tc-xc16x.c (tc_gen_reloc): Likewise.
* config/tc-xgate.c (md_apply_fix): Likewise.
* config/tc-xstormy16.c (xstormy16_md_apply_fix): Likewise.
* config/tc-xtensa.c (md_apply_fix): Likewise.
* config/tc-z80.c (tc_gen_reloc): Likewise.
* config/tc-spu.c (md_apply_fix): Likewise.
(tc_gen_reloc): Delete dead code.  Free memory on error.
* config/tc-cr16.c (tc_gen_reloc): Use as_bad_subtract.  Free
on error.
* config/tc-crx.c (tc_gen_reloc): Likewise.
* config/tc-ppc.c (tc_gen_reloc): Likewise.
* testsuite/gas/i386/ifunc-2.l: Adjust to suit changed error message.
* testsuite/gas/mips/lui-2.l: Likewise.
* testsuite/gas/tic6x/reloc-bad-1.l: Likewise.

Remove `netbsdpe` support

netbsdpe was deprecated in c2ce831330e10dab4703094491f80b6b9a5c2289.
Since then, a release has passed (2.37), and it was marked obselete in
5c9cbf07f3f972ecffe13d858010b3179df17b32. Unless I am mistaken, that
means we can now remove support altogether.

All branches in the "active" code are remove, and the target is
additionally marked as obsolete next to the other removed ones for
libbfd and gdb.

Per [1] from the NetBSD toolchain list, PE/COFF support was removed a
decade ago. Furthermore, the sole mention of this target in the binutils
commit history was in 2002. Together, I'm led to believe this target
hasn't seen much attention in quite a while.

[1]: https://mail-index.netbsd.org/tech-toolchain/2021/06/16/msg003996.html

bfd/
* config.bfd: Remove netbsdpe entry.
binutils/
* configure.ac: Remove netbsdpe entry.
* testsuite/lib/binutils-common.exp (is_pecoff_format): Likewise.
* configure: Regenerate.
gas/
* configure.tgt: Remove netbsdpe entry.
gdb/
* configure.tgt: Add netbsdpe to removed targets.
ld/
* configure.tgt: Remove netbsdpe entry.
* testsuite/ld-bootstrap/bootstrap.exp: Likewise.

Automatic date update in version.in

PR28106, build of 2.37 fails on FreeBSD and Clang

https://en.cppreference.com/w/cpp/types/NULL says NULL might be
defined as nullptr.
https://en.cppreference.com/w/cpp/language/reinterpret_cast says
reinterpret_cast can't be used on nullptr.

PR gold/28106
PR gold/27815
* gc.h (gc_process_relocs): Use static_cast in Section_id constructor.

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

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

RISC-V: Minor updates for architecture parser.

* Two add subset functions is redundant.  Keep the riscv_add_implicit_subset,
and renamed it to riscv_add_subset.  Besides, if the subset is added in order,
then we just add it at the tail of the subset list.

* Removed the "-march:" prefix from the error messages.  Since not only the
-march= option will use the parser, but also the architecture elf attributes,
the default architecture setting and linker will use the same parser.

* Use a function, riscv_parse_check_conflicts, to check the conflicts
of extensions, including the rv64e and rv32q.

The rv32emc-elf/rv32i-elf/rv32gc-linux/rv64gc-elf/rv64gc-linux regressions
are tested and passed.

bfd/
* elfxx-riscv.c (riscv_lookup_subset): Check the subset tail list
first.  If the subset is added in order, then we can just add it to
the tail without searching the whole list.
(riscv_add_subset): Replaced by riscv_add_implicit_subset.
(riscv_add_implicit_subset): Renamed to riscv_add_subset.
(riscv_parse_add_subset): Updated.
(riscv_parsing_subset_version): Removed the "-march:" prefix from
the error message.
(riscv_parse_prefixed_ext): Likewise.
(riscv_parse_std_ext): Likewise.  And move the rv<xlen>e check
to riscv_parse_check_conflicts.
(riscv_parse_check_conflicts): New function used to check conflicts.
(riscv_parse_subset): Updated.
gas/
* testsuite/gas/riscv/march-fail-base-02.l: Updated.
* testsuite/gas/riscv/march-fail-unknown-std.l: Likewise.

Automatic date update in version.in

gdb: set current thread in btrace_compute_ftrace_{bts,pt}

As documented in bug 28086, test gdb.btrace/enable-new-thread.exp
started failing with commit 0618ae414979 ("gdb: optimize
all_matching_threads_iterator"):

    (gdb) record btrace^M
    (gdb) PASS: gdb.btrace/enable-new-thread.exp: record btrace
    break 24^M
    Breakpoint 2 at 0x555555555175: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.btrace/enable-new-thread.c, line 24.^M
    (gdb) continue^M
    Continuing.^M
    /home/smarchi/src/binutils-gdb/gdb/inferior.c:303: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.^M
    A problem internal to GDB has been detected,^M
    further debugging may prove unreliable.^M
    Quit this debugging session? (y or n) FAIL: gdb.btrace/enable-new-thread.exp: continue to breakpoint: cont to bp.1 (GDB internal error)

Note that I only see the failure if GDB is compiled without libipt
support.  This is because GDB then makes use BTS instead of PT, so
exercises different code paths.

I think that the commit above just exposed an existing problem.  The
stack trace of the internal error is:

    #8  0x0000561cb81e404e in internal_error (file=0x561cb83aa2f8 "/home/smarchi/src/binutils-gdb/gdb/inferior.c", line=303, fmt=0x561cb83aa099 "%s: Assertion `%s' failed.") at /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:55
    #9  0x0000561cb7b5c031 in find_inferior_pid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, pid=0) at /home/smarchi/src/binutils-gdb/gdb/inferior.c:303
    #10 0x0000561cb7b5c102 in find_inferior_ptid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/inferior.c:317
    #11 0x0000561cb7f1d1c3 in find_thread_ptid (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread.c:487
    #12 0x0000561cb7f1b921 in all_matching_threads_iterator::all_matching_threads_iterator (this=0x7ffc4ee34678, filter_target=0x561cb8aafb60 <the_amd64_linux_nat_target>, filter_ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread-iter.c:125
    #13 0x0000561cb77bc462 in filtered_iterator<all_matching_threads_iterator, non_exited_thread_filter>::filtered_iterator<process_stratum_target* const&, ptid_t const&> (this=0x7ffc4ee34670) at /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/filtered-iterator.h:42
    #14 0x0000561cb77b97cb in all_non_exited_threads_range::begin (this=0x7ffc4ee34650) at /home/smarchi/src/binutils-gdb/gdb/thread-iter.h:243
    #15 0x0000561cb7d8ba30 in record_btrace_target::record_is_replaying (this=0x561cb8aa6250 <record_btrace_ops>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:1411
    #16 0x0000561cb7d8bb83 in record_btrace_target::xfer_partial (this=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_MEMORY, annex=0x0, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, offset=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:1437
    #17 0x0000561cb7ef73a9 in raw_memory_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1504
    #18 0x0000561cb7ef77da in memory_xfer_partial_1 (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1635
    #19 0x0000561cb7ef78b5 in memory_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, memaddr=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1664
    #20 0x0000561cb7ef7ba4 in target_xfer_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, readbuf=0x7ffc4ee34c58 "\260g\343N\374\177", writebuf=0x0, offset=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1721
    #21 0x0000561cb7ef8503 in target_read_partial (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, buf=0x7ffc4ee34c58 "\260g\343N\374\177", offset=140737352774277, len=1, xfered_len=0x7ffc4ee34ad8) at /home/smarchi/src/binutils-gdb/gdb/target.c:1974
    #22 0x0000561cb7ef861f in target_read (ops=0x561cb8aa6250 <record_btrace_ops>, object=TARGET_OBJECT_CODE_MEMORY, annex=0x0, buf=0x7ffc4ee34c58 "\260g\343N\374\177", offset=140737352774277, len=1) at /home/smarchi/src/binutils-gdb/gdb/target.c:2014
    #23 0x0000561cb7ef809f in target_read_code (memaddr=140737352774277, myaddr=0x7ffc4ee34c58 "\260g\343N\374\177", len=1) at /home/smarchi/src/binutils-gdb/gdb/target.c:1869
    #24 0x0000561cb7937f4d in gdb_disassembler::dis_asm_read_memory (memaddr=140737352774277, myaddr=0x7ffc4ee34c58 "\260g\343N\374\177", len=1, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:139
    #25 0x0000561cb80ab66d in fetch_data (info=0x7ffc4ee34e88, addr=0x7ffc4ee34c59 "g\343N\374\177") at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:194
    #26 0x0000561cb80ab7e2 in ckprefix () at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:8628
    #27 0x0000561cb80adbd8 in print_insn (pc=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:9587
    #28 0x0000561cb80abe4f in print_insn_i386 (pc=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/opcodes/i386-dis.c:8894
    #29 0x0000561cb7744a19 in default_print_insn (memaddr=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/arch-utils.c:1029
    #30 0x0000561cb7b33067 in i386_print_insn (pc=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/i386-tdep.c:4013
    #31 0x0000561cb7acd8f4 in gdbarch_print_insn (gdbarch=0x561cbae2fb60, vma=140737352774277, info=0x7ffc4ee34e88) at /home/smarchi/src/binutils-gdb/gdb/gdbarch.c:3478
    #32 0x0000561cb793a32d in gdb_disassembler::print_insn (this=0x7ffc4ee34e80, memaddr=140737352774277, branch_delay_insns=0x0) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:795
    #33 0x0000561cb793a5b0 in gdb_print_insn (gdbarch=0x561cbae2fb60, memaddr=140737352774277, stream=0x561cb8ac99f8 <null_stream>, branch_delay_insns=0x0) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:850
    #34 0x0000561cb793a631 in gdb_insn_length (gdbarch=0x561cbae2fb60, addr=140737352774277) at /home/smarchi/src/binutils-gdb/gdb/disasm.c:859
    #35 0x0000561cb77f53f4 in btrace_compute_ftrace_bts (tp=0x561cbba11210, btrace=0x7ffc4ee35188, gaps=...) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1107
    #36 0x0000561cb77f55f5 in btrace_compute_ftrace_1 (tp=0x561cbba11210, btrace=0x7ffc4ee35180, cpu=0x0, gaps=...) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1527
    #37 0x0000561cb77f5705 in btrace_compute_ftrace (tp=0x561cbba11210, btrace=0x7ffc4ee35180, cpu=0x0) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1560
    #38 0x0000561cb77f583b in btrace_add_pc (tp=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1589
    #39 0x0000561cb77f5a86 in btrace_enable (tp=0x561cbba11210, conf=0x561cb8ac6878 <record_btrace_conf>) at /home/smarchi/src/binutils-gdb/gdb/btrace.c:1629
    #40 0x0000561cb7d88d26 in record_btrace_enable_warn (tp=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:294
    #41 0x0000561cb7c603dc in std::__invoke_impl<void, void (*&)(thread_info*), thread_info*> (__f=@0x561cbb6c4878: 0x561cb7d88cdc <record_btrace_enable_warn(thread_info*)>) at /usr/include/c++/10/bits/invoke.h:60
    #42 0x0000561cb7c5e5a6 in std::__invoke_r<void, void (*&)(thread_info*), thread_info*> (__fn=@0x561cbb6c4878: 0x561cb7d88cdc <record_btrace_enable_warn(thread_info*)>) at /usr/include/c++/10/bits/invoke.h:153
    #43 0x0000561cb7c5dc92 in std::_Function_handler<void (thread_info*), void (*)(thread_info*)>::_M_invoke(std::_Any_data const&, thread_info*&&) (__functor=..., __args#0=@0x7ffc4ee35310: 0x561cbba11210) at /usr/include/c++/10/bits/std_function.h:291
    #44 0x0000561cb7f2600f in std::function<void (thread_info*)>::operator()(thread_info*) const (this=0x561cbb6c4878, __args#0=0x561cbba11210) at /usr/include/c++/10/bits/std_function.h:622
    #45 0x0000561cb7f23dc8 in gdb::observers::observable<thread_info*>::notify (this=0x561cb8ac5aa0 <gdb::observers::new_thread>, args#0=0x561cbba11210) at /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/observable.h:150
    #46 0x0000561cb7f1c436 in add_thread_silent (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/thread.c:263
    #47 0x0000561cb7f1c479 in add_thread_with_info (targ=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=..., priv=0x561cbb3f7ab0) at /home/smarchi/src/binutils-gdb/gdb/thread.c:272
    #48 0x0000561cb7bfa1d0 in record_thread (info=0x561cbb0413a0, tp=0x0, ptid=..., th_p=0x7ffc4ee35610, ti_p=0x7ffc4ee35620) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:1380
    #49 0x0000561cb7bf7a2a in thread_from_lwp (stopped=0x561cba81db20, ptid=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:429
    #50 0x0000561cb7bf7ac5 in thread_db_notice_clone (parent=..., child=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:447
    #51 0x0000561cb7bdc9a2 in linux_handle_extended_wait (lp=0x561cbae25720, status=4991) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:1981
    #52 0x0000561cb7bdf0f3 in linux_nat_filter_event (lwpid=435403, status=198015) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:2920
    #53 0x0000561cb7bdfed6 in linux_nat_wait_1 (ptid=..., ourstatus=0x7ffc4ee36398, target_options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:3202
    #54 0x0000561cb7be0b68 in linux_nat_target::wait (this=0x561cb8aafb60 <the_amd64_linux_nat_target>, ptid=..., ourstatus=0x7ffc4ee36398, target_options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:3440
    #55 0x0000561cb7bfa2fc in thread_db_target::wait (this=0x561cb8a9acd0 <the_thread_db_target>, ptid=..., ourstatus=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/linux-thread-db.c:1412
    #56 0x0000561cb7d8e356 in record_btrace_target::wait (this=0x561cb8aa6250 <record_btrace_ops>, ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/record-btrace.c:2547
    #57 0x0000561cb7ef996d in target_wait (ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/target.c:2608
    #58 0x0000561cb7b6d297 in do_target_wait_1 (inf=0x561cba6d8780, ptid=..., status=0x7ffc4ee36398, options=...) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3640
    #59 0x0000561cb7b6d43e in operator() (__closure=0x7ffc4ee36190, inf=0x561cba6d8780) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3701
    #60 0x0000561cb7b6d7b2 in do_target_wait (ecs=0x7ffc4ee36370, options=...) at /home/smarchi/src/binutils-gdb/gdb/infrun.c:3720
    #61 0x0000561cb7b6e67d in fetch_inferior_event () at /home/smarchi/src/binutils-gdb/gdb/infrun.c:4069
    #62 0x0000561cb7b4659b in inferior_event_handler (event_type=INF_REG_EVENT) at /home/smarchi/src/binutils-gdb/gdb/inf-loop.c:41
    #63 0x0000561cb7be25f7 in handle_target_event (error=0, client_data=0x0) at /home/smarchi/src/binutils-gdb/gdb/linux-nat.c:4227
    #64 0x0000561cb81e4ee2 in handle_file_event (file_ptr=0x561cbae24e10, ready_mask=1) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:575
    #65 0x0000561cb81e5490 in gdb_wait_for_event (block=0) at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:701
    #66 0x0000561cb81e41be in gdb_do_one_event () at /home/smarchi/src/binutils-gdb/gdbsupport/event-loop.cc:212
    #67 0x0000561cb7c18096 in start_event_loop () at /home/smarchi/src/binutils-gdb/gdb/main.c:421
    #68 0x0000561cb7c181e0 in captured_command_loop () at /home/smarchi/src/binutils-gdb/gdb/main.c:481
    #69 0x0000561cb7c19d7e in captured_main (data=0x7ffc4ee366a0) at /home/smarchi/src/binutils-gdb/gdb/main.c:1353
    #70 0x0000561cb7c19df0 in gdb_main (args=0x7ffc4ee366a0) at /home/smarchi/src/binutils-gdb/gdb/main.c:1368
    #71 0x0000561cb7693186 in main (argc=11, argv=0x7ffc4ee367b8) at /home/smarchi/src/binutils-gdb/gdb/gdb.c:32

At frame 45, the new_thread observable is fired.  At this moment, the
new thread isn't the current thread, inferior_ptid is null_ptid.  I
think this is ok: the new_thread observable doesn't give any guarantee
on the global context when observers are invoked.  Frame 35,
btrace_compute_ftrace_bts, calls gdb_insn_length.  gdb_insn_length
doesn't have a thread_info or other parameter what could indicate where
to read memory from, it implicitly uses the global context
(inferior_ptid).

So we reach the all_non_exited_threads_range in
record_btrace_target::record_is_replaying with a null inferior_ptid.
The previous implemention of all_non_exited_threads_range didn't care,
but the new one does.  The problem of calling gdb_insn_length and
ultimately trying to read memory with a null inferior_ptid already
existed, but the commit mentioned above made it visible.

Something between frames 40 (record_btrace_enable_warn) and 35
(btrace_compute_ftrace_bts) needs to be switching the global context to
make TP the current thread.  Since btrace_compute_ftrace_bts takes the
thread_info to work with as a parameter, that typically means that it
doesn't require its caller to also set the global current context
(current thread) when calling.  If it needs to call other functions
that do require the global current thread to be set, then it needs to
temporarily change the current thread while calling these other
functions.  Therefore, switch and restore the current thread in
btrace_compute_ftrace_bts.

By inspection, it looks like btrace_compute_ftrace_pt may also call
functions sensitive to the global context: it installs the
btrace_pt_readmem_callback callback in the PT instruction decoder.  When
this function gets called, inferior_ptid must be set appropriately.  Add
a switch and restore in there too.

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

Automatic date update in version.in

Move pending-obsolesence targets onto the obsolete list.

* config.bfd: Move pending obsoletion targets to obsolete list.

Update how-to-make-a-release checklist with latest changes from 2.37 release

PR28098 Skip R_*_NONE relocation entries with zero r_sym without counting

PR gold/28098
* reloc.cc (Track_relocs::advance): Skip R_*_NONE relocation entries
with r_sym of zero without counting in advance method.

gdb: convert nat/x86-dregs.c macros to functions

I'm debugging why GDB crashes on OpenBSD/amd64, turns out it's because
x86_dr_low.get_status is nullptr.  It would have been useful to be able
to break on x86_dr_low_get_status, so I thought it would be a good
reason to convert these function-like macros into functions.

Change-Id: Ic200b50ef8455b4697bc518da0fa2bb704cf4721

Automatic date update in version.in

Fix file-name handling regression with DWARF index

When run with the gdb-index or debug-names target boards, dup-psym.exp
fails.  This came up for me because my new DWARF scanner reuses this
part of the existing index code, and so it registers as a regression.
This is PR symtab/25834.

Looking into this, I found that the DWARF index code here is fairly
different from the psymtab code.  I don't think there's a deep reason
for this, and in fact, it seemed to me that the index code could
simply mimic what the psymtab code already does.

That is what this patch implements.  The DW_AT_name and DW_AT_comp_dir
are now stored in the quick file names table.  This may require
allocating a quick file names table even when DW_AT_stmt_list does not
exist.  Then, the functions that work with this data are changed to
use find_source_or_rewrite, just as the psymbol code does.  Finally,
line_header::file_full_name is removed, as it is no longer needed.

Currently, the index maintains a hash table of "quick file names".
The hash table uses a deletion function to free the "real name"
components when necessary.  There's also a second such function to
implement the forget_cached_source_info method.

This bug fix patch will create a quick file name object even when
there is no DW_AT_stmt_list, meaning that the object won't be entered
in the hash table.  So, this patch changes the memory management
approach so that the entries are cleared when the per-BFD object is
destroyed.  (A dwarf2_per_cu_data destructor is not introduced,
because we have been avoiding adding a vtable to that class.)

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

Check for debug-types in map_symbol_filenames

map_symbol_filenames can skip type units -- in fact I think it has to,
due to the assertion at the top of dw2_get_file_names.  This may be a
regression due to the TU/CU unification patch, I did not check.

Simplify DWARF file name caching

The DWARF index file name caching code only records when a line table
has been read and the reading failed.  However, the code would be
simpler if it recorded any attempt, which is what this patch
implements.

Introduce find_source_or_rewrite

The final bug fix in this series would duplicate the logic in
psymtab_to_fullname, so this patch extracts the body of this function
into a new function.

Simplify file_and_directory storage management

file_and_directory carries a std::string in case the compilation
directory is computed, but a subsequent patch wants to preserve this
string without also having to maintain the storage for it.  So, this
patch arranges for the compilation directory string to be stored in
the per-BFD string bcache instead.

Pass file_and_directory through DWARF line-decoding code

This patch removes the redundant "comp_unit" parameter from
compute_include_file_name, and arranges to pass a file_and_directory
object from the readers down to this function.  It also changes the
partial symtab reader to use find_file_and_directory, rather than
reimplement this functionality by hand.

Rename and refactor psymtab_include_file_name

In order to fix an index-related regression, I want to use
psymtab_include_file_name in the DWARF index file-handling code.  This
patch renames this function and changes it to no longer require a
partial symtab to be passed in.  A subsequent patch will further
refactor this code to remove the redundant parameter (which was always
there but is now more obvious).

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

gdb: make all_inferiors_safe actually work

The test gdb.threads/fork-plus-threads.exp fails since 08bdefb58b78
("gdb: make inferior_list use intrusive_list"):

    FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left

Looking at the log, we see that we are left with a bunch of inferiors in
the detach-on-fork=off case:

    info inferiors^M
      Num  Description       Connection           Executable        ^M
    * 1    <null>                                 <snip>/fork-plus-threads ^M
      2    <null>                                 <snip>/fork-plus-threads ^M
      3    <null>                                 <snip>/fork-plus-threads ^M
      4    <null>                                 <snip>/fork-plus-threads ^M
      5    <null>                                 <snip>/fork-plus-threads ^M
      6    <null>                                 <snip>/fork-plus-threads ^M
      7    <null>                                 <snip>/fork-plus-threads ^M
      8    <null>                                 <snip>/fork-plus-threads ^M
      9    <null>                                 <snip>/fork-plus-threads ^M
      10   <null>                                 <snip>/fork-plus-threads ^M
      11   <null>                                 <snip>/fork-plus-threads ^M
    (gdb) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: only inferior 1 left

when we expect to have just one.  The problem is prune_inferiors not
pruning inferiors.  And this is caused by all_inferiors_safe not
actually iterating on inferiors.  The current implementation:

  inline all_inferiors_safe_range
  all_inferiors_safe ()
  {
    return {};
  }

default-constructs an all_inferiors_safe_range, which default-constructs
an all_inferiors_safe_iterator as its m_begin field, which
default-constructs a all_inferiors_iterator.  A default-constructed
all_inferiors_iterator is an end iterator, which means we have
constructed an (end,end) all_inferiors_safe_range.

We actually need to pass down the list on which we want to iterator
(that is the inferior_list global), so that all_inferiors_iterator's
first constructor is chosen.  We also pass nullptr as the proc_target
filter.  In this case, we don't do any filtering, but if in the future
all_inferiors_safe needed to allow filtering on process target (like
all_inferiors does), we could pass down a process target pointer.

basic_safe_iterator's constructor needs to be changed to allow
constructing the wrapped iterator with multiple arguments, not just one.

With this, gdb.threads/fork-plus-threads.exp is passing once again for
me.

Change-Id: I650552ede596e3590c4b7606ce403690a0278a01

Automatic date update in version.in

gdb: Support stepping out from signal handler on riscv*-linux

Currently, gdb cannot step outside of a signal handler on RISC-V
platforms.  This causes multiple failures in gdb.base/sigstep.exp:

FAIL: gdb.base/sigstep.exp: continue to handler, nothing in handler, step from handler: leave handler (timeout)
FAIL: gdb.base/sigstep.exp: continue to handler, si+advance in handler, step from handler: leave handler (timeout)
FAIL: gdb.base/sigstep.exp: continue to handler, nothing in handler, next from handler: leave handler (timeout)
FAIL: gdb.base/sigstep.exp: continue to handler, si+advance in handler, next from handler: leave handler (timeout)
FAIL: gdb.base/sigstep.exp: stepi from handleri: leave signal trampoline
FAIL: gdb.base/sigstep.exp: nexti from handleri: leave signal trampoline

                === gdb Summary ===

# of expected passes            587
# of unexpected failures        6

This patch adds support for stepping outside of a signal handler on
riscv*-*-linux*.

Implementation is heavily inspired from mips_linux_syscall_next_pc and
surroundings as advised by Pedro Alves.

After this patch, all tests in gdb.base/sigstep.exp pass.

Build and tested on riscv64-linux-gnu.

gdb/testsuite: Declare that riscv*-*-linux* cannot hardware_single_step

Many tests fail in gdb/testsuite/gdb.base/sigstep.exp on
riscv64-linux-gnu.  Those tests check that when stepping, if the
debuggee received a signal it should step inside the signal handler.

This feature requires hardware support for single stepping (or at least
kernel support), but none are available on riscv*-linux-gnu hosts, at
the moment at least.

This patch adds RISC-V to the list of configurations that does not
have hardware single step capability, disabling tests relying on such
feature.

Tested on riscv64-linux-gnu.

Document quick_symbol_functions::expand_symtabs_matching invariant

While working on my series to replace the DWARF psymbol reader, I
noticed that the expand_symtabs_matching has an undocumented
invariant.  I think that, if this invariant is not followed, then GDB
will crash.  So, this patch documents this in the relevant spots and
introduces some asserts to make it clear.

Regression tested on x86-64 Fedora 32.

Fix array stride bug

Investigation of using the Python API with an Ada program showed that
an array of dynamic types was not being handled properly.  I tracked
this down to an oddity of how array strides are handled.

In gdb, an array stride can be attached to the range type, via the
range_bounds object.  However, the stride can also be put into the
array's first field.  From create_range_type_with_stride:

  else if (bit_stride > 0)
    TYPE_FIELD_BITSIZE (result_type, 0) = bit_stride;

It's hard to be sure why this is done, but I would guess a combination
of historical reasons plus a desire (mentioned in a comment somewhere)
to avoid modifying the range type.

This patch fixes the problem by changing type::bit_stride to
understand this convention.  It also fixes one spot that reproduces
this logic.

Regression tested on x86-64 Fedora 32.

or1k: fix pc-relative relocation against dynamic on PC relative 26 bit relocation.

bfd * elf32-or1k.c (or1k_elf_relocate_section): Use a separate entry
in switch case R_OR1K_INSN_REL_26 where we need to check for
!SYMBOL_CALLS_LOCAL() instead of !SYMBOL_REFERENCES_LOCAL().

Updated Swedish translation for the binutils sub-directory

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

gdb: pass child_ptid and fork kind to target_ops::follow_fork

This is a small cleanup I think would be nice, that I spotted while
doing the following patch.

gdb/ChangeLog:

* target.h (struct target_ops) <follow_fork>: Add ptid and
target_waitkind parameters.
(target_follow_fork): Likewise.
* target.c (default_follow_fork): Likewise.
(target_follow_fork): Likewise.
* fbsd-nat.h (class fbsd_nat_target) <follow_fork>: Likewise.
* fbsd-nat.c (fbsd_nat_target::follow_fork): Likewise.
* linux-nat.h (class linux_nat_target) <follow_fork>: Likewise.
* linux-nat.c (linux_nat_target::follow_fork): Likewise.
* obsd-nat.h (class obsd_nat_target) <follow_fork>: Likewise.
* obsd-nat.c (obsd_nat_target::follow_fork): Likewise.
* remote.c (class remote_target) <follow_fork>: Likewise.
* target-debug.h (target_debug_print_target_waitkind): New.
* target-delegates.c: Re-generate.

Change-Id: I5421a542f2e19100a22b74cc333d2b235d0de3c8

gdb: call post_create_inferior at end of follow_fork_inferior

GDB doesn't handle well the case of an inferior using the JIT interface
to register JIT-ed objfiles and forking.  If an inferior registers a
code object using the JIT interface and then forks, the child process
conceptually has the same code object loaded, so GDB should look it up
and learn about it (it currently doesn't).

To achieve this, I think it would make sense to have the
inferior_created observable called when an inferior is created due to a
fork in follow_fork_inferior.  The inferior_created observable is
currently called both after starting a new inferior and after attaching
to an inferior, allowing various sub-components to learn about that new
executing inferior.  We can see handling a fork child just like
attaching to it, so any work done when attaching should also be done in
the case of a fork child.

Instead of just calling the inferior_created observable, this patch
makes follow_fork_inferior call the whole post_create_inferior function.
This way, the attach and follow-fork code code paths are more alike.

Given that post_create_inferior calls solib_create_inferior_hook,
follow_fork_inferior doesn't need to do it itself, so those calls to
solib_create_inferior_hook are removed.

One question you may have: why not just call post_create_inferior at the
places where solib_create_inferior_hook is currently called, instead of
after target_follow_fork?

 - there's something fishy for the second solib_create_inferior_hook
   call site: at this point we have switched the current program space
   to the child's, but not the current inferior nor the current thread.
   So solib_create_inferior_hook (and everything under, including
   check_for_thread_db, for example) is called with inferior 1 as the
   current inferior and inferior 2's program space as the current
   program space.  I think that's wrong, because at this point we are
   setting up inferior 2, and all that code relies on the current
   inferior.  We could just add a switch_to_thread call before it to
   make inferior 2 the current one, but there are other problems (see
   below).

 - solib_create_inferior_hook is currently not called on the
   `follow_child && detach_fork` path.  I think we need to call it,
   because we still get a new inferior in that case (even though we
   detach the parent).  If we only call post_create_inferior where
   solib_create_inferior_hook used to be called, then the JIT
   subcomponent doesn't get informed about the new inferior, and that
   introduces a failure in the new gdb.base/jit-elf-fork.exp test.

 - if we try to put the post_create_inferior just after the
   switch_to_thread that was originally at line 662, or just before the
   call to target_follow_fork, we introduce a subtle failure in
   gdb.threads/fork-thread-pending.exp.  What happens then is that
   libthread_db gets loaded (somewhere under post_create_inferior)
   before the linux-nat target learns about the LWPs (which happens in
   linux_nat_target::follow_fork).  As a result, the ALL_LWPS loop in
   try_thread_db_load_1 doesn't see the child LWP, and the thread-db
   target doesn't have the chance to fill in thread_info::priv.  A bit
   later, when the test does "info threads", and
   thread_db_target::pid_to_str is called, the thread-db target doesn't
   recognize the thread as one of its own, and delegates the request to
   the target below.  Because the pid_to_str output is not the expected
   one, the test fails.

   This tells me that we need to call the process target's follow_fork
   first, to make the process target create the necessary LWP and thread
   structures.  Then, we can call post_create_inferior to let the other
   components of GDB do their thing.

   But then you may ask: check_for_thread_db is already called today,
   somewhere under solib_create_inferior_hook, and that is before
   target_follow_fork, why don't we see this ordering problem!?  Well,
   because of the first bullet point: when check_for_thread_db /
   thread_db_load are called, the current inferior is (erroneously)
   inferior 1, the parent.  Because libthread_db is already loaded for
   the parent, thread_db_load early returns.  check_for_thread_db later
   gets called by linux_nat_target::follow_fork.  At this point, the
   current inferior is the correct one and the child's LWP exists, so
   all is well.

Since we now call post_create_inferior after target_follow_fork, which
calls the inferior_created observable, which calls check_for_thread_db,
I don't think linux_nat_target needs to explicitly call
check_for_thread_db itself, so that is removed.

In terms of testing, this patch adds a new gdb.base/jit-elf-fork.exp
test.  It makes an inferior register a JIT code object and then fork.
It then verifies that whatever the detach-on-fork and follow-fork-child
parameters are, GDB knows about the JIT code object in all the inferiors
that survive the fork.  It verifies that the inferiors can unload that
code object.

There isn't currently a way to get visibility into GDB's idea of the JIT
code objects for each inferior.  For the purpose of this test, add the
"maintenance info jit" command.  There isn't much we can print about the
JIT code objects except their load address.  So the output looks a bit
bare, but it's good enough for the test.

gdb/ChangeLog:

* NEWS: Mention "maint info jit" command.
* infrun.c (follow_fork_inferior): Don't call
solib_create_inferior_hook, call post_create_inferior if a new
inferior was created.
* jit.c (maint_info_jit_cmd): New.
(_initialize_jit): Register new command.
* linux-nat.c (linux_nat_target::follow_fork): Don't call
check_for_thread_db.
* linux-nat.h (check_for_thread_db): Remove declaration.
* linux-thread-db.c (check_thread_signals): Make static.

gdb/doc/ChangeLog:

* gdb.texinfo (Maintenance Commands): Mention "maint info jit".

gdb/testsuite/ChangeLog:

* gdb.base/jit-elf-fork-main.c: New test.
* gdb.base/jit-elf-fork-solib.c: New test.
* gdb.base/jit-elf-fork.exp: New test.

Change-Id: I9a192e55b8a451c00e88100669283fc9ca60de5c

[gdb/procfs.c] Fix build failure in find_stop_signal

It fixes a regression caused by commit
1edb66d856c82c389edfd7610143236a68c76846 where thread_info::suspend was
made private.

The public thread_info API has to be used to get stop signal and avoid
build failures.

gdb/ChangeLog:

2021-07-14  Libor Bukata <libor.bukata@oracle.com>

  * gdb/procfs.c (find_stop_signal): Use thread_info API.

Change-Id: I53bc57a05cd0eca5f28ef0726d6faeeb306e7904

Automatic date update in version.in

x86: Add int1 as one byte opcode 0xf1

Also change the x86 disassembler to disassemble 0xf1 as int1, instead of
icebp.

gas/

PR gas/28088
* testsuite/gas/i386/opcode.s: Add int1.
* testsuite/gas/i386/x86-64-opcode.s: Add int1, int3 and int.
* testsuite/gas/i386/opcode-intel.d: Updated.
* testsuite/gas/i386/opcode-suffix.d: Likewise.
* testsuite/gas/i386/opcode.d: Likewise.
* testsuite/gas/i386/x86-64-opcode.d: Likewise.

opcodes/

PR gas/28088
* i386-dis.c (dis386): Replace icebp with int1.
* i386-opc.tbl: Add int1.
* i386-tbl.h: Regenerate.

gas: default TC_VALIDATE_FIX_SUB to 0

gas/write.c provides a fallback TC_VALIDATE_FIX_SUB define that can be
a problem for some targets, the problem being that a non-zero
definition of TC_VALIDATE_FIX_SUB says that some uses of fx_subsy are
OK, in effect that the target will handle fx_subsy in md_apply_fix
and/or tc_gen_reloc.  A lot of targets don't have the necessary
md_apply_fix and tc_gen_reloc support.  So a safer default is to
disallow fx_subsy by default.

I've had a good look over target usage of fx_subsy, and think I've
caught all the cases where targets need TC_VALIDATE_FIX_SUB.  Possible
failures would be limited to alpha, microblaze, ppc and s390 (the
targets that define UNDEFINED_DIFFERENCE_OK), or targets that generate
fixups with BFD_RELOC_GPREL32/16 and use a syntax explicitly showing
a difference expression.

* write.c (TC_VALIDATE_FIX_SUB): Default to 0.
* config/tc-hppa.h (TC_VALIDATE_FIX_SUB): Define.
* config/tc-microblaze.h (TC_VALIDATE_FIX_SUB): Define.
* config/tc-alpha.h (TC_VALIDATE_FIX_SUB): Define for ECOFF.
* config/tc-ppc.h (TC_VALIDATE_FIX_SUB): Don't define for ELF.
Do define for XCOFF.

objdump: add DWARF support for AIX

DWARF sections have special names on AIX which need be handled
by objdump in order to correctly print them.
This patch also adds the correlation in bfd for future uses.

bfd/
* libxcoff.h (struct xcoff_dwsect_name): Add DWARF name.
* coff-rs6000.c (xcoff_dwsect_names): Update.
* coffcode.h (sec_to_styp_flags): Likewise.
(coff_new_section_hook): Likewise.
binutils/
* dwarf.h (struct dwarf_section): Add XCOFF name.
* dwarf.c (struct dwarf_section_display): Update.
* objdump.c (load_debug_section): Add XCOFF name handler.
(dump_dwarf_section): Likewise.
gas/
* config/tc-ppc.c (ppc_change_debug_section): Update to
match new name's field.

[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.

[gdb/testsuite] Add missing skip_tui_tests

When building gdb with --disable-tui, we run into:
...
(gdb) frame apply all -- -^M
Undefined command: "-".  Try "help".^M
(gdb) ERROR: Undefined command "frame apply all -- -".
UNRESOLVED: gdb.base/options.exp: test-frame-apply: frame apply all -- -
...

Fix this by detecting whether tui is supported, and skipping the tui-related
tests otherwise.  Same in some gdb.tui test-cases.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.base/options.exp: Skip tui-related tests when tui is not
supported.
* gdb.python/tui-window-disabled.exp: Same.
* gdb.python/tui-window.exp: Same.

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.

arm-fbsd-nat: Use fetch_register_set and store_register_set.

aarch64-fbsd-nat: Use fetch_register_set and store_register_set.

riscv-fbsd-nat: Use fetch_register_set and store_register_set.

fbsd-nat: Add helper functions to fetch and store register sets.

In particular, this supports register sets described by a regcache_map
which are fetched and stored with dedicated ptrace operations.  These
functions are intended to be used in architecture-specific
fetch_registers and store_registers target methods.

Add regcache_map_supplies helper routine.

This helper can be used in the fetch_registers and store_registers
target methods to determine if a register set includes a specific
register.

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-07  Tom de Vries  <tdevries@suse.de>

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

gdb, dwarf: Don't follow the parent of a subprogram to get a prefix.

During prefix resolution, if the parent is a subprogram, there is no need
to go to the parent of the subprogram.  The DIE will be local.

For a program like:
~~~
  class F1
  {
  public:
    int a;
    int
    vvv ()
    {
      class F2
      {
int f;
      };
      F2 abcd;
      return 1;
    }
  };
~~~

The class F2 should not be seen as a member of F1.

Before:
~~~
(gdb) ptype abcd
type = class F1::F2 {
  private:
    int f;
}
~~~

After:
~~~
(gdb) ptype abcd
type = class F2 {
  private:
    int f;
}
~~~

gdb/ChangeLog:
2021-06-23  Felix Willgerodt  <felix.willgerodt@intel.com>

* dwarf2/read.c (determine_prefix): Return an empty prefix if the
parent is a subprogram.

gdb/testsuite/ChangeLog:
2021-06-23  Felix Willgerodt  <felix.willgerodt@intel.com>

* gdb.cp/nested-class-func-class.cc: New file.
* gdb.cp/nested-class-func-class.exp: New file.

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

RISC-V: Enable elf attributes when default configure option isn't set.

Since gcc commit, 3c70b3ca1ef58f302bf8c16d9e7c7bb8626408bf, we now enable
elf attributes for all riscv targets by default in gcc.  Therefore, I
think binutils should have the same behavior, in case users are writing
assembly files.  If --enable-default-riscv-attribute isn't set, then we
enable the elf attributes for all riscv targets by default.

ChangLog:

binutils/

* testsuite/binutils-all/readelf.s: Add comments for riscv.
* testsuite/binutils-all/readelf.s-64: Likewise.
* testsuite/binutils-all/readelf.s-64-unused: Likewise.
* testsuite/binutils-all/readelf.ss: Likewise.
* testsuite/binutils-all/readelf.ss-64: Likewise.
* testsuite/binutils-all/readelf.ss-64-unused: Likewise.

gas/

* configure.ac: If --enable-default-riscv-attribute isn't set,
then we enable the elf attributes for all riscv targets by
default.
* configure: Regenerated.

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: optimize all_matching_threads_iterator

all_matching_threads_iterator is used extensively in some pretty fast
paths, often under the all_non_exited_threads function.

If a filter target and thread-specific ptid are given, it iterates on
all threads of all inferiors of that target, to ultimately yield exactly
on thread.  And this happens quite often, which means we unnecessarily
spend time iterating on threads to find the one we are looking for.  The
same thing happens if an inferior-specific ptid is given, although there
the iterator yields all the threads of that inferior.

In those cases, the callers of all_non_exited_threads could have
different behaviors depending on the kind of ptid, to avoid this
inefficiency, but that would be very tedious.  Using
all_non_exited_threads has the advantage that one simple implementation
can work seamlessly on multiple threads or on one specific thread, just
by playing with the ptid.

Instead, optimize all_matching_threads_iterator directly to detect these
different cases and limiting what we iterate on to just what we need.

 - if filter_ptid is minus_one_ptid, do as we do now: filter inferiors
   based on filter_target, iterate on all of the matching inferiors'
   threads
 - if filter_ptid is a pid-only ptid (then a filter_target must
   necessarily be given), look up that inferior and iterate on all its
   threads
 - otherwise, filter_ptid is a thread-specific ptid, so look up that
   specific thread and "iterate" only on it

For the last case, what was an iteration on all threads of the filter
target now becomes a call to find_thread_ptid, which is quite efficient
now thanks to inferior::ptid_thread_map.

gdb/ChangeLog:

* thread-iter.h (class all_matching_threads_iterator)
<all_matching_threads_iterator>: Use default.
<enum class mode>: New.
<m_inf, m_thr>: Initialize.
<m_filter_ptid>: Remove.
* thread-iter.c (all_matching_threads_iterator::m_inf_matches):
Don't filter on m_filter_ptid.
(all_matching_threads_iterator::all_matching_threads_iterator):
Choose path based on filter_ptid (all threads, all threads of
inferior, single thread).
(all_matching_threads_iterator::advance): Likewise.

Change-Id: Ic6a19845f5f760fa1b8eac8145793c0ff431bbc9

gdb: maintain ptid -> thread map, optimize find_thread_ptid

When debugging a large number of threads (thousands), looking up a
thread by ptid_t using the inferior::thread_list linked list can add up.

Add inferior::thread_map, an std::unordered_map indexed by ptid_t, and
change the find_thread_ptid function to look up a thread using
std::unordered_map::find, instead of iterating on all of the
inferior's threads.  This should make it faster to look up a thread
from its ptid.

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

gdb: optimize selection of resumed thread with pending event

Consider a case where many threads (thousands) keep hitting a breakpoint
whose condition evaluates to false.  random_pending_event_thread is
responsible for selecting a thread from an inferior among all that are
resumed with a pending wait status.  It is currently implemented by
walking the inferior's thread list twice: once to count the number of
candidates and once to select a random one.

Since we now maintain a per target list of resumed threads with pending
event, we can implement this more efficiently by walking that list and
selecting the first thread that matches the criteria
(random_pending_event_thread looks for an thread from a specific
inferior, and possibly a filter ptid).  It will be faster especially in
the common case where there isn't any resumed thread with pending
event.  Currently, we have to iterate the thread list to figure this
out.  With this patch, the list of resumed threads with pending event
will be empty, so it's quick to figure out.

The random selection is kept, but is moved to
process_stratum_target::random_resumed_with_pending_wait_status.  The
same technique is used: do a first pass to count the number of
candidates, and do a second pass to select a random one.  But given that
the list of resumed threads with pending wait statuses will generally be
short, or at least shorter than the full thread list, it should be
quicker.

Note that this isn't completely true, in case there are multiple
inferiors on the same target.  Imagine that inferior A has 10k resumed
threads with pending wait statuses, and random_pending_event_thread is
called with inferior B.  We'll need to go through the list that contains
inferior A's threads to realize that inferior B has no resumed threads
with pending wait status.  But I think that this is a corner /
pathological case.  And a possible fix for this situation would be to
make random_pending_event_thread work per-process-target, rather than
per-inferior.

Change-Id: I1b71d01beaa500a148b5b9797745103e13917325

gdb: optimize check for resumed threads with pending wait status in maybe_set_commit_resumed_all_targets

Consider a test case where many threads (thousands) keep hitting a
breakpoint whose condition evaluates to false.
maybe_set_commit_resumed_all_targets is called at each handled event,
when the scoped_disable_commit_resumed object in fetch_inferior_event is
reset_and_commit-ed.  One particularly expensive check in there is
whether the target has at least one resumed thread with a pending wait
status (in which case, we don't want to commit the resumed threads, as
we want to consume this status first).  It is currently implemented as
walking all threads of the target.

Since we now maintain a per-target list of resumed threads with pending
status, we can do this check efficiently, by checking whether that list
is empty or not.

Add the process_stratum_target::has_resumed_with_pending_wait_status
method for this, and use it in maybe_set_commit_resumed_all_targets.

Change-Id: Ia1595baa1b358338f94fc3cb3af7f27092dad5b6

gdb: maintain per-process-target list of resumed threads with pending wait status

Looking up threads that are both resumed and have a pending wait
status to report is something that we do quite often in the fast path
and is expensive if there are many threads, since it currently requires
walking whole thread lists.

The first instance is in maybe_set_commit_resumed_all_targets.  This is
called after handling each event in fetch_inferior_event, to see if we
should ask targets to commit their resumed threads or not.  If at least
one thread is resumed but has a pending wait status, we don't ask the
targets to commit their resumed threads, because we want to consume and
handle the pending wait status first.

The second instance is in random_pending_event_thread, where we want to
select a random thread among all those that are resumed and have a
pending wait status.  This is called every time we try to consume
events, to see if there are any pending events that we we want to
consume, before asking the targets for more events.

To allow optimizing these cases, maintain a per-process-target list of
threads that are resumed and have a pending wait status.

In maybe_set_commit_resumed_all_targets, we'll be able to check in O(1)
if there are any such threads simply by checking whether the list is
empty.

In random_pending_event_thread, we'll be able to use that list, which
will be quicker than iterating the list of threads, especially when
there are no resumed with pending wait status threads.

About implementation details: using the new setters on class
thread_info, it's relatively easy to maintain that list.  Any time the
"resumed" or "pending wait status" property is changed, we check whether
that should cause the thread to be added or removed from the list.

In set_thread_exited, we try to remove the thread from the list, because
keeping an exited thread in that list would make no sense (especially if
the thread is freed).  My first implementation assumed that a process
stratum target was always present when set_thread_exited is called.
That's however, not the case: in some cases, targets unpush themselves
from an inferior and then call "exit_inferior", which exits all the
threads.  If the target is unpushed before set_thread_exited is called
on the threads, it means we could mistakenly leave some threads in the
list.  I tried to see how hard it would be to make it such that targets
have to exit all threads before unpushing themselves from the inferior
(that would seem logical to me, we don't want threads belonging to an
inferior that has no process target).  That seemed quite difficult and
not worth the time at the moment.  Instead, I changed
inferior::unpush_target to remove all threads of that inferior from the
list.

As of this patch, the list is not used, this is done in the subsequent
patches.

The debug messages in process-stratum-target.c need to print some ptids.
However, they can't use target_pid_to_str to print them without
introducing a dependency on the current inferior (the current inferior
is used to get the current target stack).  For debug messages, I find it
clearer to print the spelled out ptid anyway (the pid, lwp and tid
values).  Add a ptid_t::to_string method that returns a string
representation of the ptid that is meant for debug messages, a bit like
we already have frame_id::to_string.

Change-Id: Iad8f93db2d13984dd5aa5867db940ed1169dbb67

gdb: make thread_info::suspend private, add getters / setters

A following patch will want to take some action when a pending wait
status is set on or removed from a thread.  Add a getter and a setter on
thread_info for the pending waitstatus, so that we can add some code in
the setter later.

The thing is, the pending wait status field is in the
thread_suspend_state, along with other fields that we need to backup
before and restore after the thread does an inferior function call.
Therefore, make the thread_suspend_state member private
(thread_info::suspend becomes thread_info::m_suspend), and add getters /
setters for all of its fields:

 - pending wait status
 - stop signal
 - stop reason
 - stop pc

For the pending wait status, add the additional has_pending_waitstatus
and clear_pending_waitstatus methods.

I think this makes the thread_info interface a bit nicer, because we
now access the fields as:

  thread->stop_pc ()

rather than

  thread->suspend.stop_pc

The stop_pc field being in the `suspend` structure is an implementation
detail of thread_info that callers don't need to be aware of.

For the backup / restore of the thread_suspend_state structure, add
save_suspend_to and restore_suspend_from methods.  You might wonder why
`save_suspend_to`, as opposed to a simple getter like

  thread_suspend_state &suspend ();

I want to make it clear that this is to be used only for backing up and
restoring the suspend state, _not_ to access fields like:

  thread->suspend ()->stop_pc

Adding some getters / setters allows adding some assertions.  I find
that this helps understand how things are supposed to work.  Add:

 - When getting the pending status (pending_waitstatus method), ensure
   that there is a pending status.
 - When setting a pending status (set_pending_waitstatus method), ensure
   there is no pending status.

There is one case I found where this wasn't true - in
remote_target::process_initial_stop_replies - which needed adjustments
to respect that contract.  I think it's because
process_initial_stop_replies is kind of (ab)using the
thread_info::suspend::waitstatus to store some statuses temporarily, for
its internal use (statuses it doesn't intent on leaving pending).

process_initial_stop_replies pulls out stop replies received during the
initial connection using target_wait.  It always stores the received
event in `evthread->suspend.waitstatus`.  But it only sets
waitstatus_pending_p, if it deems the event interesting enough to leave
pending, to be reported to the core:

      if (ws.kind != TARGET_WAITKIND_STOPPED
  || ws.value.sig != GDB_SIGNAL_0)
evthread->suspend.waitstatus_pending_p = 1;

It later uses this flag a bit below, to choose which thread to make the
"selected" one:

      if (selected == NULL
  && thread->suspend.waitstatus_pending_p)
selected = thread;

And ultimately that's used if the user-visible mode is all-stop, so that
we print the stop for that interesting thread:

  /* In all-stop, we only print the status of one thread, and leave
     others with their status pending.  */
  if (!non_stop)
    {
      thread_info *thread = selected;
      if (thread == NULL)
thread = lowest_stopped;
      if (thread == NULL)
thread = first;

      print_one_stopped_thread (thread);
    }

But in any case (all-stop or non-stop), print_one_stopped_thread needs
to access the waitstatus value of these threads that don't have a
pending waitstatus (those that had TARGET_WAITKIND_STOPPED +
GDB_SIGNAL_0).  This doesn't work with the assertions I've
put.

So, change the code to only set the thread's wait status if it is an
interesting one that we are going to leave pending.  If the thread
stopped due to a non-interesting event (TARGET_WAITKIND_STOPPED +
GDB_SIGNAL_0), don't store it.  Adjust print_one_stopped_thread to
understand that if a thread has no pending waitstatus, it's because it
stopped with TARGET_WAITKIND_STOPPED + GDB_SIGNAL_0.

The call to set_last_target_status also uses the pending waitstatus.
However, given that the pending waitstatus for the thread may have been
cleared in print_one_stopped_thread (and that there might not even be a
pending waitstatus in the first place, as explained above), it is no
longer possible to do it at this point.  To fix that, move the call to
set_last_target_status in print_one_stopped_thread.  I think this will
preserve the existing behavior, because set_last_target_status is
currently using the current thread's wait status.  And the current
thread is the last one for which print_one_stopped_thread is called.  So
by calling set_last_target_status in print_one_stopped_thread, we'll get
the same result.  set_last_target_status will possibly be called
multiple times, but only the last call will matter.  It just means
possibly more calls to set_last_target_status, but those are cheap.

Change-Id: Iedab9653238eaf8231abcf0baa20145acc8b77a7

gdb: add setter / getter for thread_info resumed state

A following patch will want to do things when a thread's resumed state
changes.  Make the `resumed` field private (renamed to `m_resumed`) and
add a getter and a setter for it.  The following patch in question will
therefore be able to add some code to the setter.

Change-Id: I360c48cc55a036503174313261ce4e757d795319

gdb: use intrusive list for step-over chain

The threads that need a step-over are currently linked using an
hand-written intrusive doubly-linked list, so that seems a very good
candidate for intrusive_list, convert it.

For this, we have a use case of appending a list to another one (in
start_step_over).  Based on the std::list and Boost APIs, add a splice
method.  However, only support splicing the other list at the end of the
`this` list, since that's all we need.

Add explicit default assignment operators to
reference_to_pointer_iterator, which are otherwise implicitly deleted.
This is needed because to define thread_step_over_list_safe_iterator, we
wrap reference_to_pointer_iterator inside a basic_safe_iterator, and
basic_safe_iterator needs to be able to copy-assign the wrapped
iterator.  The move-assignment operator is therefore not needed, only
the copy-assignment operator is.  But for completeness, add both.

Change-Id: I31b2ff67c7b78251314646b31887ef1dfebe510c

gdb: make inferior_list use intrusive_list

Change inferior_list, the global list of inferiors, to use
intrusive_list.  I think most other changes are somewhat obvious
fallouts from this change.

There is a small change in behavior in scoped_mock_context.  Before this
patch, constructing a scoped_mock_context would replace the whole
inferior list with only the new mock inferior.  Tests using two
scoped_mock_contexts therefore needed to manually link the two inferiors
together, as the second scoped_mock_context would bump the first mock
inferior from the thread list.  With this patch, a scoped_mock_context
adds its mock inferior to the inferior list on construction, and removes
it on destruction.  This means that tests run with mock inferiors in the
inferior list in addition to any pre-existing inferiors (there is always
at least one).  There is no possible pid clash problem, since each
scoped mock inferior uses its own process target, and pids are per
process target.

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

gdb: introduce intrusive_list, make thread_info use it

GDB currently has several objects that are put in a singly linked list,
by having the object's type have a "next" pointer directly.  For
example, struct thread_info and struct inferior.  Because these are
simply-linked lists, and we don't keep track of a "tail" pointer, when
we want to append a new element on the list, we need to walk the whole
list to find the current tail.  It would be nice to get rid of that
walk.  Removing elements from such lists also requires a walk, to find
the "previous" position relative to the element being removed.  To
eliminate the need for that walk, we could make those lists
doubly-linked, by adding a "prev" pointer alongside "next".  It would be
nice to avoid the boilerplate associated with maintaining such a list
manually, though.  That is what the new intrusive_list type addresses.

With an intrusive list, it's also possible to move items out of the
list without destroying them, which is interesting in our case for
example for threads, when we exit them, but can't destroy them
immediately.  We currently keep exited threads on the thread list, but
we could change that which would simplify some things.

Note that with std::list, element removal is O(N).  I.e., with
std::list, we need to walk the list to find the iterator pointing to
the position to remove.  However, we could store a list iterator
inside the object as soon as we put the object in the list, to address
it, because std::list iterators are not invalidated when other
elements are added/removed.  However, if you need to put the same
object in more than one list, then std::list<object> doesn't work.
You need to instead use std::list<object *>, which is less efficient
for requiring extra memory allocations.  For an example of an object
in multiple lists, see the step_over_next/step_over_prev fields in
thread_info:

  /* Step-over chain.  A thread is in the step-over queue if these are
     non-NULL.  If only a single thread is in the chain, then these
     fields point to self.  */
  struct thread_info *step_over_prev = NULL;
  struct thread_info *step_over_next = NULL;

The new intrusive_list type gives us the advantages of an intrusive
linked list, while avoiding the boilerplate associated with manually
maintaining it.

intrusive_list's API follows the standard container interface, and thus
std::list's interface.  It is based the API of Boost's intrusive list,
here:

 https://www.boost.org/doc/libs/1_73_0/doc/html/boost/intrusive/list.html

Our implementation is relatively simple, while Boost's is complicated
and intertwined due to a lot of customization options, which our version
doesn't have.

The easiest way to use an intrusive_list is to make the list's element
type inherit from intrusive_node.  This adds a prev/next pointers to
the element type.  However, to support putting the same object in more
than one list, intrusive_list supports putting the "node" info as a
field member, so you can have more than one such nodes, one per list.

As a first guinea pig, this patch makes the per-inferior thread list use
intrusive_list using the base class method.

Unlike Boost's implementation, ours is not a circular list.  An earlier
version of the patch was circular: the intrusive_list type included an
intrusive_list_node "head".  In this design, a node contained pointers
to the previous and next nodes, not the previous and next elements.
This wasn't great for when debugging GDB with GDB, as it was difficult
to get from a pointer to the node to a pointer to the element.  With the
design proposed in this patch, nodes contain pointers to the previous
and next elements, making it easy to traverse the list by hand and
inspect each element.

The intrusive_list object contains pointers to the first and last
elements of the list.  They are nullptr if the list is empty.
Each element's node contains a pointer to the previous and next
elements.  The first element's previous pointer is nullptr and the last
element's next pointer is nullptr.  Therefore, if there's a single
element in the list, both its previous and next pointers are nullptr.
To differentiate such an element from an element that is not linked into
a list, the previous and next pointers contain a special value (-1) when
the node is not linked.  This is necessary to be able to reliably tell
if a given node is currently linked or not.

A begin() iterator points to the first item in the list.  An end()
iterator contains nullptr.  This makes iteration until end naturally
work, as advancing past the last element will make the iterator contain
nullptr, making it equal to the end iterator.  If the list is empty,
a begin() iterator will contain nullptr from the start, and therefore be
immediately equal to the end.

Iterating on an intrusive_list yields references to objects (e.g.
`thread_info&`).  The rest of GDB currently expects iterators and ranges
to yield pointers (e.g. `thread_info*`).  To bridge the gap, add the
reference_to_pointer_iterator type.  It is used to define
inf_threads_iterator.

Add a Python pretty-printer, to help inspecting intrusive lists when
debugging GDB with GDB.  Here's an example of the output:

    (top-gdb) p current_inferior_.m_obj.thread_list
    $1 = intrusive list of thread_info = {0x61700002c000, 0x617000069080, 0x617000069400, 0x61700006d680, 0x61700006eb80}

It's not possible with current master, but with this patch [1] that I
hope will be merged eventually, it's possible to index the list and
access the pretty-printed value's children:

    (top-gdb) p current_inferior_.m_obj.thread_list[1]
    $2 = (thread_info *) 0x617000069080
    (top-gdb) p current_inferior_.m_obj.thread_list[1].ptid
    $3 = {
      m_pid = 406499,
      m_lwp = 406503,
      m_tid = 0
    }

Even though iterating the list in C++ yields references, the Python
pretty-printer yields pointers.  The reason for this is that the output
of printing the thread list above would be unreadable, IMO, if each
thread_info object was printed in-line, since they contain so much
information.  I think it's more useful to print pointers, and let the
user drill down as needed.

[1] https://sourceware.org/pipermail/gdb-patches/2021-April/178050.html

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

Automatic date update in version.in

Add the SEC_ELF_OCTETS flag to debug sections created by the assembler.

PR 28054
gas * config/obj-elf.c (obj_elf_change_section): Set the
SEF_ELF_OCTETS flag on debug sections.

[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.

Updated French translation for the binutils sub-directory

Fix a translation problem for the text generated by readelf at the start of a dump of a dynamic section.

PR 28072
binutils * readelf.c (process_dynamic_section): Use ngettext to help with translation of header text.

[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-05  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".

testsuite: fix whitespace problems in gdb.mi/mi-break.exp

Replace leading 8-spaces with tab and remove trailing space in
gdb.mi/mi-break.exp.

Automatic date update in version.in

Automatic date update in version.in

Tidy commit 49910fd88dcd

Pointer range checking is UB if the values compared are outside the
underlying array elements (plus one).

* dwarf2.c (read_address): Remove accidental commit.
(read_ranges): Compare offset rather than pointers.

PR28069, assertion fail in dwarf.c:display_discr_list

We shouldn't be asserting on anything to do with leb128 values, or
reporting file and line numbers when something unexpected happens.
leb128 data is of indeterminate length, perfect for fuzzer mayhem.
It would only make sense to assert or report dwarf.c/readelf.c source
lines if the code had already sized and sanity checked the leb128
values.

After removing the assertions, the testcase then gave:

    <37>   DW_AT_discr_list  : 5 byte block: 0 0 0 0 0  (label 0, label 0, label 0, label 0, <corrupt>
readelf: Warning: corrupt discr_list - unrecognized discriminant byte 0x5

    <3d>   DW_AT_encoding    : 0 (void)
    <3e>   DW_AT_identifier_case: 0 (case_sensitive)
    <3f>   DW_AT_virtuality  : 0 (none)
    <40>   DW_AT_decimal_sign: 5 (trailing separate)

So the DW_AT_discr_list was showing more data than just the 5 byte
block.  That happened due to "end" pointing a long way past the end of
block, and uvalue decrementing past zero on one of the leb128 bytes.

PR 28069
* dwarf.c (display_discr_list): Remove assertions.  Delete "end"
parameter, use initial "data" pointer as the end.  Formatting.
Don't count down bytes as they are read.
(read_and_display_attr_value): Adjust display_discr_list call.
(read_and_print_leb128): Don't pass __FILE__ and __LINE__ to
report_leb_status.
* dwarf.h (report_leb_status): Don't report file and line
numbers.  Delete file and lnum parameters,
(READ_ULEB, READ_SLEB): Adjust.

Automatic date update in version.in

ld/NEWS: Clarify -z [no]indirect-extern-access

-z [no]indirect-extern-access are only for x86 ELF linker.

elf: Limits 2 GNU_PROPERTY_1_NEEDED tests to Linux/x86

Run property-1_needed-1b.d and property-1_needed-1c.d, which pass
-z [no]indirect-extern-access to linker, only run for Linux/x86 targets.

* testsuite/ld-elf/property-1_needed-1b.d: Only run for
Linux/x86 targets.
* testsuite/ld-elf/property-1_needed-1c.d: Likewise.