Cleanup of the dwarf_expr_context constructor

Move the initial values for dwarf_expr_context class data members
to the class declaration in expr.h.

gdb/ChangeLog:

        * dwarf2/expr.c (dwarf_expr_context::dwarf_expr_context):
        Remove initial data members values.
        * dwarf2/expr.h (dwarf_expr_context): Add initial values
        to the class data members.

Replace the symbol needs evaluator with a parser

This patch addresses a design problem with the symbol_needs_eval_context
class. It exposes the problem by introducing two new testsuite test
cases.

To explain the issue, I first need to explain the dwarf_expr_context
class that the symbol_needs_eval_context class derives from.

The intention behind the dwarf_expr_context class is to commonize the
DWARF expression evaluation mechanism for different evaluation
contexts. Currently in gdb, the evaluation context can contain some or
all of the following information: architecture, object file, frame and
compilation unit.

Depending on the information needed to evaluate a given expression,
there are currently three distinct DWARF expression evaluators:

 - Frame: designed to evaluate an expression in the context of a call
   frame information (dwarf_expr_executor class). This evaluator doesn't
   need a compilation unit information.

 - Location description: designed to evaluate an expression in the
   context of a source level information (dwarf_evaluate_loc_desc
   class). This evaluator expects all information needed for the
   evaluation of the given expression to be present.

 - Symbol needs: designed to answer a question about the parts of the
   context information required to evaluate a DWARF expression behind a
   given symbol (symbol_needs_eval_context class). This evaluator
   doesn't need a frame information.

The functional difference between the symbol needs evaluator and the
others is that this evaluator is not meant to interact with the actual
target. Instead, it is supposed to check which parts of the context
information are needed for the given DWARF expression to be evaluated by
the location description evaluator.

The idea is to take advantage of the existing dwarf_expr_context
evaluation mechanism and to fake all required interactions with the
actual target, by returning back dummy values. The evaluation result is
returned as one of three possible values, based on operations found in a
given expression:

- SYMBOL_NEEDS_NONE,
- SYMBOL_NEEDS_REGISTERS and
- SYMBOL_NEEDS_FRAME.

The problem here is that faking results of target interactions can yield
an incorrect evaluation result.

For example, if we have a conditional DWARF expression, where the
condition depends on a value read from an actual target, and the true
branch of the condition requires a frame information to be evaluated,
while the false branch doesn't, fake target reads could conclude that a
frame information is not needed, where in fact it is. This wrong
information would then cause the expression to be actually evaluated (by
the location description evaluator) with a missing frame information.
This would then crash the debugger.

The gdb.dwarf2/symbol_needs_eval_fail.exp test introduces this
scenario, with the following DWARF expression:

                   DW_OP_addr $some_variable
                   DW_OP_deref

                   # conditional jump to DW_OP_bregx
                   DW_OP_bra 4
                   DW_OP_lit0

                   # jump to DW_OP_stack_value
                   DW_OP_skip 3
                   DW_OP_bregx $dwarf_regnum 0
                   DW_OP_stack_value

This expression describes a case where some variable dictates the
location of another variable. Depending on a value of some_variable, the
variable whose location is described by this expression is either read
from a register or it is defined as a constant value 0. In both cases,
the value will be returned as an implicit location description on the
DWARF stack.

Currently, when the symbol needs evaluator fakes a memory read from the
address behind the some_variable variable, the constant value 0 is used
as the value of the variable A, and the check returns the
SYMBOL_NEEDS_NONE result.

This is clearly a wrong result and it causes the debugger to crash.

The scenario might sound strange to some people, but it comes from a
SIMD/SIMT architecture where $some_variable is an execution mask.  In
any case, it is a valid DWARF expression, and GDB shouldn't crash while
evaluating it. Also, a similar example could be made based on a
condition of the frame base value, where if that value is concluded to
be 0, the variable location could be defaulted to a TLS based memory
address.

The gdb.dwarf2/symbol_needs_eval_timeout.exp test introduces a second
scenario. This scenario is a bit more abstract due to the DWARF
assembler lacking the CFI support, but it exposes a different
manifestation of the same problem. Like in the previous scenario, the
DWARF expression used in the test is valid:

                       DW_OP_lit1
                       DW_OP_addr $some_variable
                       DW_OP_deref

                       # jump to DW_OP_fbreg
                       DW_OP_skip 4
                       DW_OP_drop
                       DW_OP_fbreg 0
                       DW_OP_dup
                       DW_OP_lit0
                       DW_OP_eq

                       # conditional jump to DW_OP_drop
                       DW_OP_bra -9
                       DW_OP_stack_value

Similarly to the previous scenario, the location of a variable A is an
implicit location description with a constant value that depends on a
value held by a global variable. The difference from the previous case
is that DWARF expression contains a loop instead of just one branch. The
end condition of that loop depends on the expectation that a frame base
value is never zero. Currently, the act of faking the target reads will
cause the symbol needs evaluator to get stuck in an infinite loop.

Somebody could argue that we could change the fake reads to return
something else, but that would only hide the real problem.

The general impression seems to be that the desired design is to have
one class that deals with parsing of the DWARF expression, while there
are virtual methods that deal with specifics of some operations.

Using an evaluator mechanism here doesn't seem to be correct, because
the act of evaluation relies on accessing the data from the actual
target with the possibility of skipping the evaluation of some parts of
the expression.

To better explain the proposed solution for the issue, I first need to
explain a couple more details behind the current design:

There are multiple places in gdb that handle DWARF expression parsing
for different purposes. Some are in charge of converting the expression
to some other internal representation (decode_location_expression,
disassemble_dwarf_expression and dwarf2_compile_expr_to_ax), some are
analysing the expression for specific information
(compute_stack_depth_worker) and some are in charge of evaluating the
expression in a given context (dwarf_expr_context::execute_stack_op
and decode_locdesc).

The problem is that all those functions have a similar (large) switch
statement that handles each DWARF expression operation. The result of
this is a code duplication and harder maintenance.

As a step into the right direction to solve this problem (at least for
the purpose of a DWARF expression evaluation) the expression parsing was
commonized inside of an evaluator base class (dwarf_expr_context). This
makes sense for all derived classes, except for the symbol needs
evaluator (symbol_needs_eval_context) class.

As described previously the problem with this evaluator is that if the
evaluator is not allowed to access the actual target, it is not really
evaluating.

Instead, the desired function of a symbol needs evaluator seems to fall
more into expression analysis category. This means that a more natural
fit for this evaluator is to be a symbol needs analysis, similar to the
existing compute_stack_depth_worker analysis.

Another problem is that using a heavyweight mechanism of an evaluator
to do an expression analysis seems to be an unneeded overhead. It also
requires a more complicated design of the parent class to support fake
target reads.

The reality is that the whole symbol_needs_eval_context class can be
replaced with a lightweight recursive analysis function, that will give
more correct result without compromising the design of the
dwarf_expr_context class. The analysis treats the expression byte
stream as a DWARF operation graph, where each graph node can be
visited only once and each operation can decide if the frame context
is needed for their evaluation.

The downside of this approach is adding of one more similar switch
statement, but at least this way the new symbol needs analysis will be
a lightweight mechnism and it will provide a correct result for any
given DWARF expression.

A more desired long term design would be to have one class that deals
with parsing of the DWARF expression, while there would be a virtual
methods that deal with specifics of some DWARF operations. Then that
class would be used as a base for all DWARF expression parsing mentioned
at the beginning.

This however, requires a far bigger changes that are out of the scope
of this patch series.

The new analysis requires the DWARF location description for the
argc argument of the main function to change in the assembly file
gdb.python/amd64-py-framefilter-invalidarg.S. Originally, expression
ended with a 0 value byte, which was never reached by the symbol needs
evaluator, because it was detecting a stack underflow when evaluating
the operation before. The new approach does not simulate a DWARF
stack anymore, so the 0 value byte needs to be removed because it
makes the DWARF expression invalid.

gdb/ChangeLog:

        * dwarf2/loc.c (class symbol_needs_eval_context): Remove.
        (dwarf2_get_symbol_read_needs): New function.
        (dwarf2_loc_desc_get_symbol_read_needs): Remove.
        (locexpr_get_symbol_read_needs): Use
        dwarf2_get_symbol_read_needs.

gdb/testsuite/ChangeLog:

        * gdb.python/amd64-py-framefilter-invalidarg.S : Update argc
          DWARF location expression.
        * lib/dwarf.exp (_location): Handle DW_OP_fbreg.
        * gdb.dwarf2/symbol_needs_eval.c: New file.
        * gdb.dwarf2/symbol_needs_eval_fail.exp: New file.
        * gdb.dwarf2/symbol_needs_eval_timeout.exp: New file.

[PATCH 2/2] Add tests for Intel AVX512_FP16 instructions

Intel AVX512 FP16 instructions use maps 3, 5 and 6. Maps 5 and 6 use 3 bits
in the EVEX.mmm field (0b101, 0b110). Map 5 is for instructions that were FP32
in map 1 (0Fxx). Map 6 is for instructions that were FP32 in map 2 (0F38xx).
There are some exceptions to this rule. Some things in map 1 (0Fxx) with imm8
operands predated our current conventions; those instructions moved to map 3.
FP32 things in map 3 (0F3Axx) found new opcodes in map3 for FP16 because map3
is very sparsely populated. Most of the FP16 instructions share opcodes and
prefix (EVEX.pp) bits with the related FP32 operations.

Intel AVX512 FP16 instructions has new displacements scaling rules, please refer
to the public software developer manual for detail information.

gas/

2021-08-05  Igor Tsimbalist  <igor.v.tsimbalist@intel.com>
            H.J. Lu  <hongjiu.lu@intel.com>
            Wei Xiao <wei3.xiao@intel.com>
            Lili Cui  <lili.cui@intel.com>

* testsuite/gas/i386/i386.exp: Run FP16 tests.
* testsuite/gas/i386/avx512_fp16-intel.d: New test.
* testsuite/gas/i386/avx512_fp16-inval-bcast.l: Ditto.
* testsuite/gas/i386/avx512_fp16-inval-bcast.s: Ditto.
* testsuite/gas/i386/avx512_fp16.d: Ditto.
* testsuite/gas/i386/avx512_fp16.s: Ditto.
* testsuite/gas/i386/avx512_fp16_pseudo_ops.d: Ditto.
* testsuite/gas/i386/avx512_fp16_pseudo_ops.s: Ditto.
* testsuite/gas/i386/avx512_fp16_vl-intel.d: Ditto.
* testsuite/gas/i386/avx512_fp16_vl.d: Ditto.
* testsuite/gas/i386/avx512_fp16_vl.s: Ditto.
* testsuite/gas/i386/x86-64-avx512_fp16-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx512_fp16-inval-bcast.l: Ditto.
* testsuite/gas/i386/x86-64-avx512_fp16-inval-bcast.s: Ditto.
* testsuite/gas/i386/x86-64-avx512_fp16.d: Ditto.
* testsuite/gas/i386/x86-64-avx512_fp16.s: Ditto.
* testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.d: Ditto.
* testsuite/gas/i386/x86-64-avx512_fp16_pseudo_ops.s: Ditto.
* testsuite/gas/i386/x86-64-avx512_fp16_vl-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx512_fp16_vl.d: Ditto.
* testsuite/gas/i386/x86-64-avx512_fp16_vl.s: Ditto.
* testsuite/gas/i386/x86-64-avx512_fp16-inval-register.l: Ditto.
* testsuite/gas/i386/x86-64-avx512_fp16-inval-register.s: Ditto.
* testsuite/gas/i386/x86-64-avx512_fp16-bad.d: Ditto.
* testsuite/gas/i386/x86-64-avx512_fp16-bad.s: Ditto.
* testsuite/gas/i386/x86-64-default-suffix-avx.d: Add new testcase.
* testsuite/gas/i386/x86-64-default-suffix.d: Ditto.
* testsuite/gas/i386/x86-64-default-suffix.s: Ditto.
* testsuite/gas/i386/xmmword.l: Ditto.
* testsuite/gas/i386/xmmword.s: Ditto.

[PATCH 1/2] Enable Intel AVX512_FP16 instructions

Intel AVX512 FP16 instructions use maps 3, 5 and 6. Maps 5 and 6 use 3 bits
in the EVEX.mmm field (0b101, 0b110). Map 5 is for instructions that were FP32
in map 1 (0Fxx). Map 6 is for instructions that were FP32 in map 2 (0F38xx).
There are some exceptions to this rule. Some things in map 1 (0Fxx) with imm8
operands predated our current conventions; those instructions moved to map 3.
FP32 things in map 3 (0F3Axx) found new opcodes in map3 for FP16 because map3
is very sparsely populated. Most of the FP16 instructions share opcodes and
prefix (EVEX.pp) bits with the related FP32 operations.

Intel AVX512 FP16 instructions has new displacements scaling rules, please refer
to the public software developer manual for detail information.

gas/

2021-08-05  Igor Tsimbalist  <igor.v.tsimbalist@intel.com>
            H.J. Lu  <hongjiu.lu@intel.com>
            Wei Xiao <wei3.xiao@intel.com>
            Lili Cui  <lili.cui@intel.com>

* config/tc-i386.c (struct Broadcast_Operation): Adjust comment.
(cpu_arch): Add .avx512_fp16.
(cpu_noarch): Add noavx512_fp16.
(pte): Add evexmap5 and evexmap6.
(build_evex_prefix): Handle EVEXMAP5 and EVEXMAP6.
(check_VecOperations): Handle {1to32}.
(check_VecOperands): Handle CheckRegNumb.
(check_word_reg): Handle Toqword.
(i386_error): Add invalid_dest_and_src_register_set.
(match_template): Handle invalid_dest_and_src_register_set.
* doc/c-i386.texi: Document avx512_fp16, noavx512_fp16.

opcodes/

2021-08-05  Igor Tsimbalist  <igor.v.tsimbalist@intel.com>
            H.J. Lu  <hongjiu.lu@intel.com>
            Wei Xiao <wei3.xiao@intel.com>
            Lili Cui  <lili.cui@intel.com>

* i386-dis.c (EXwScalarS): New.
(EXxh): Ditto.
(EXxhc): Ditto.
(EXxmmqh): Ditto.
(EXxmmqdh): Ditto.
(EXEvexXwb): Ditto.
(DistinctDest_Fixup): Ditto.
(enum): Add xh_mode, evex_half_bcst_xmmqh_mode, evex_half_bcst_xmmqdh_mode
and w_swap_mode.
(enum): Add PREFIX_EVEX_0F3A08_W_0, PREFIX_EVEX_0F3A0A_W_0,
PREFIX_EVEX_0F3A26, PREFIX_EVEX_0F3A27, PREFIX_EVEX_0F3A56,
PREFIX_EVEX_0F3A57, PREFIX_EVEX_0F3A66, PREFIX_EVEX_0F3A67,
PREFIX_EVEX_0F3AC2, PREFIX_EVEX_MAP5_10, PREFIX_EVEX_MAP5_11,
PREFIX_EVEX_MAP5_1D, PREFIX_EVEX_MAP5_2A, PREFIX_EVEX_MAP5_2C,
PREFIX_EVEX_MAP5_2D, PREFIX_EVEX_MAP5_2E, PREFIX_EVEX_MAP5_2F,
PREFIX_EVEX_MAP5_51, PREFIX_EVEX_MAP5_58, PREFIX_EVEX_MAP5_59,
PREFIX_EVEX_MAP5_5A_W_0, PREFIX_EVEX_MAP5_5A_W_1,
PREFIX_EVEX_MAP5_5B_W_0, PREFIX_EVEX_MAP5_5B_W_1,
PREFIX_EVEX_MAP5_5C, PREFIX_EVEX_MAP5_5D, PREFIX_EVEX_MAP5_5E,
PREFIX_EVEX_MAP5_5F, PREFIX_EVEX_MAP5_78, PREFIX_EVEX_MAP5_79,
PREFIX_EVEX_MAP5_7A, PREFIX_EVEX_MAP5_7B, PREFIX_EVEX_MAP5_7C,
PREFIX_EVEX_MAP5_7D_W_0, PREFIX_EVEX_MAP6_13, PREFIX_EVEX_MAP6_56,
PREFIX_EVEX_MAP6_57, PREFIX_EVEX_MAP6_D6, PREFIX_EVEX_MAP6_D7
(enum): Add EVEX_MAP5 and EVEX_MAP6.
(enum): Add EVEX_W_MAP5_5A, EVEX_W_MAP5_5B,
EVEX_W_MAP5_78_P_0, EVEX_W_MAP5_78_P_2, EVEX_W_MAP5_79_P_0,
EVEX_W_MAP5_79_P_2, EVEX_W_MAP5_7A_P_2, EVEX_W_MAP5_7A_P_3,
EVEX_W_MAP5_7B_P_2, EVEX_W_MAP5_7C_P_0, EVEX_W_MAP5_7C_P_2,
EVEX_W_MAP5_7D, EVEX_W_MAP6_13_P_0, EVEX_W_MAP6_13_P_2,
(get_valid_dis386): Properly handle new instructions.
(intel_operand_size): Handle new modes.
(OP_E_memory): Ditto.
(OP_EX): Ditto.
* i386-dis-evex.h: Updated for AVX512_FP16.
* i386-dis-evex-mod.h: Updated for AVX512_FP16.
* i386-dis-evex-prefix.h: Updated for AVX512_FP16.
* i386-dis-evex-reg.h : Updated for AVX512_FP16.
* i386-dis-evex-w.h : Updated for AVX512_FP16.
* i386-gen.c (cpu_flag_init): Add CPU_AVX512_FP16_FLAGS,
and CPU_ANY_AVX512_FP16_FLAGS. Update CPU_ANY_AVX512F_FLAGS
and CPU_ANY_AVX512BW_FLAGS.
(cpu_flags): Add CpuAVX512_FP16.
(opcode_modifiers): Add DistinctDest.
* i386-opc.h (enum): (AVX512_FP16): New.
(i386_opcode_modifier): Add reqdistinctreg.
(i386_cpu_flags): Add cpuavx512_fp16.
(EVEXMAP5): Defined as a macro.
(EVEXMAP6): Ditto.
* i386-opc.tbl: Add Intel AVX512_FP16 instructions.
* i386-init.h: Regenerated.
* i386-tbl.h: Ditto.

PR28167, vms-alpha build_module_list

PR 28167
* vms-alpha.c (build_module_list): Malloc and free section contents.
Don't read past end of section.

PR28166, _bfd_elf_mips_get_relocated_section_contents

Some of the code paths unpacking mips relocs left arelent->sym_ptr_ptr
uninitialised.

PR 28166
* elf64-mips.c (mips_elf64_slurp_one_reloc_table): Don't leave
sym_ptr_ptr uninitialised.

PR28165, buffer overflow in elf32-rx.c:rx_info_to_howto_rela

PR 28165
* elf32-rx.c (rx_elf_howto_table): Add missing empty entries.
(rx_info_to_howto_rela): Assert rx_elf_howto_table is correct size.
Use actual size when sanity checking r_type.

Re: elf: Treat undefined version as hidden

Fix fallout in cris testsuite

PR binutils/28158
* ld-cris/libdso-1c.d: Update for version display change.
* ld-cris/libdso-15b.d: Likewise.

gdb/testsuite: update test gdb.base/step-over-syscall.exp

I was looking at PR gdb/19675 and the related test
gdb.base/step-over-syscall.exp.  This test includes a call to kfail
when we are testing a displaced step over a clone syscall.

While looking at the test I removed the call to kfail and ran the
test, and was surprised that the test passed.

I ran the test a few times and it does sometimes fail, but mostly it
passed fine.

PR gdb/19675 describes how, when we displaced step over a clone, the
new thread is created with a $pc in the displaced step buffer.  GDB
then fails to "fix" this $pc (for the new thread), and the thread will
be set running with its current $pc value.  This means that the new
thread will just start executing from whatever happens to be after the
displaced stepping buffer.

In the original PR gdb/19675 bug report Yao Qi was seeing the new
thread cause a segfault, the problem is, what actually happens is
totally undefined.

On my machine, I'm seeing the new thread reenter main, it then starts
trying to run the test again (in the new thread).  This just happens
to be safe enough (in this simple test) that most of the time the
inferior doesn't crash.

In this commit I try to make the test slightly more likely to fail by
doing a couple of things.

First, I added a static variable to main, this is set true when the
first thread enters main, if a second thread ever enters main then I
force an abort.

Second, when the test is finishing I want to ensure that the new
threads have had a chance to do "something bad" if they are going to.
So I added a global counter, as each thread starts successfully it
decrements the counter.  The main thread does not proceed to the final
marker function (where GDB has placed a breakpoint) until all threads
have started successfully.  This means that if the newly created
thread doesn't successfully enter clone_fn then the counter will never
reach zero and the test will timeout.

With these two changes my hope is that the test should fail more
reliably, and so, I have also changed the test to call setup_kfail
before the specific steps that we expect to misbehave instead of just
calling kfail and skipping parts of the test completely.  The benefit
of this is that if/when we fix GDB this test will start to KPASS and
we'll know to update this test to remove the setup_kfail call.

Automatic date update in version.in

gdb: Use unwinder name in frame_info::to_string

While working on a stack unwinding issue using 'set debug frame on', I
noticed the frame_info::to_string method could be slightly improved.

Unwinders have been given a name in
a154d838a70e96d888620c072e2d6ea8bdf044ca.  Before this patch, frame_info
debug output prints the host address of the used unwinder, which is not
easy to interpret.  This patch proposes to use the unwinder name
instead since we now have it.

Before the patch:

    {level=1,type=NORMAL_FRAME,unwind=0x2ac1763ec0,pc=0x3ff7fc3460,id={stack=0x3ff7ea79b0,code=0x0000003ff7fc33ac,!special},func=0x3ff7fc33ac}

With the patch:

    {level=1,type=NORMAL_FRAME,unwinder="riscv prologue",pc=0x3ff7fc3460,id={stack=0x3ff7ea79b0,code=0x0000003ff7fc33ac,!special},func=0x3ff7fc33ac}

Tested on riscv64-linux-gnu.

gdb/testsuite: fix gdb.base/info-macros.exp with clang

The test gdb.base/info-macros.exp says that it doesn't pass the "debug"
option to prepare_for_testing because that would cause -g to appear
after -g3 on the command line, and that would cause some gcc versions to
not include macro info.  I don't know what gcc versions this refers to.
I tested with gcc 4.8, and that works fine with -g after -g3.

The current state is problematic when testing with CC_FOR_TARGET=clang,
because then only -fdebug-macro is included.  No -g switch if included,
meaning we get a binary without any debug info, and the test fails.

One way to fix it would be to add "debug" to the options when the
compiler is clang.

However, the solution I chose was to specify "debug" in any case, even
for gcc.  Other macro tests such as gdb.base/macscp.exp do perfectly
fine with it.  Also, this lets the test use the debug flag specified by
the board file.  For example, we can test with GCC and DWARF 5, with:

    $ make check RUNTESTFLAGS="--target_board unix/gdb:debug_flags=-gdwarf-5" TESTS="gdb.base/info-macros.exp"

With the hard-coded -g3, this wouldn't actually test with DWARF 5.

Change-Id: I33fa92ee545007d3ae9c52c4bb2d5be6b5b698f1

gdb: avoid dereferencing empty str_offsets_base optional in dwarf_decode_macros

Since 4d7188abfdf2 ("gdbsupport: add debug assertions in
gdb::optional::get"), some macro-related tests fail on Ubuntu 20.04 with
the system gcc 9.3.0 compiler when building with _GLIBCXX_DEBUG.  For
example, gdb.base/info-macros.exp results in:

   (gdb) break -qualified main
   /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/gdb_optional.h:206: internal-error: T& gdb::optional<T>::get() [with T = long unsigned int]: Assertion `this->has_value ()' failed.

The binary contains DWARF 4 debug info and includes a pre-standard
(pre-DWARF 5) .debug_macro section.  The CU doesn't have a
DW_AT_str_offsets_base attribute (which doesn't exist in DWARF 4).  The
field dwarf2_cu::str_offsets_base is therefore empty.  At
dwarf2/read.c:24138, we unconditionally read the value in the optional,
which triggers the assertion shown above.

The same thing happens when building the test program with DWARF 5 with
the same gcc compiler, as that version of gcc doesn't use indirect
string forms, even with DWARF 5.  So it still doesn't add a
DW_AT_str_offsets_base attribute on the CU.

Fix that by propagating down a gdb::optional<ULONGEST> for the str
offsets base instead of ULONGEST.  That value is only used in
dwarf_decode_macro_bytes, when encountering an "strx" macro operation
(DW_MACRO_define_strx or DW_MACRO_undef_strx).  Add a check there that
we indeed have a value in the optional before reading it.  This is
unlikely to happen, but could happen in theory with an erroneous file
that uses DW_MACRO_define_strx but does not provide a
DW_AT_str_offsets_base (in practice, some things would probably have
failed before and stopped processing of debug info).  I tested the
complaint by inverting the condition and using a clang-compiled binary,
which uses the strx operators.  This is the result:

    During symbol reading: use of DW_MACRO_define_strx with unknown string offsets base [in module /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/info-macros/info-macros]

The test now passes cleanly with the setup mentioned above, and the
testsuite looks on par with how it was before 4d7188abfdf2.

Change-Id: I7ebd2724beb7b9b4178872374c2a177aea696e77

gdb: fix typo in complaint in dwarf2/macro.c

I saw this complaint when my code had some bug, and spotted the typo.
Fix it, and while at it mention DW_MACRO as well (it would be confusing
to only see DW_MACINFO with a file that uses a DWARF 5 .debug_macro
section).  I contemplated the idea of passing the knowledge of whether
we are dealing with a .debug_macro section or .debug_macinfo section, to
print only the right one.  But in the end, I don't think that trouble is
necessary for a complaint nobody is going to see.

Change-Id: I276ce8da65c3eac5304f64a1e246358ed29cdbbc

gdb: fix warnings in bsd-kvm.c

Building on OpenBSD, I get warnings like:

      CXX    bsd-kvm.o
    /home/simark/src/binutils-gdb/gdb/bsd-kvm.c:241:18: error: ISO C++11 does not allow conversion from string literal to 'char *' [-Werror,-Wwritable-strings]
      nl[0].n_name = "_dumppcb";
                     ^

Silence those by adding casts.

Change-Id: I2bef4eebcc306762a4e3e5b5c52f67ecf2820503

IBM Z: Remove lpswey parameter

opcodes/
* s390-opc.c (INSTR_SIY_RD): New instruction format.
(MASK_SIY_RD): New instruction mask.
* s390-opc.txt: Change instruction format of lpswey to SIY_RD.

gas/
* testsuite/gas/s390/zarch-arch14.d: Remove last operand of
lpswey.
* testsuite/gas/s390/zarch-arch14.s: Likewise.

PR28162, segment fault in mips_elf_assign_gp

For the testcase in the PR, _bfd_mips_elf32_gprel16_reloc is passed a
NULL output_bfd.  As expected for reloc special functions if called by
objdump or when final linking.  The function attempts to find the
output by
  output_bfd = symbol->section->output_section->owner;
That makes some sense, since when handling a gp-relative reloc we need
the relevant gp to which the symbol is relative.  Possibly the gp
value can be one for a shared library?  But that doesn't seem useful
or supported by the various abi docs and won't work as written.
Symbols defined in shared libraries have section->output_section
NULL, and what's more the code in mips_elf_assign_gp isn't set up to
look at shared library symbols.

Also, if the symbol is a SHN_ABS one the owner of *ABS* section is
NULL, which will result in the testcase segfault.  The only gp to
which an absolute symbol can be relative is the linker output bfd when
linking, or the input bfd when not.  This patch arranges to do that
for all gp-relative reloc symbols.

* elf32-mips.c (_bfd_mips_elf32_gprel16_reloc): Don't use the
section symbol to find the output bfd, use input_section.
(mips_elf_gprel32_reloc, mips16_gprel_reloc): Likewise.
* elf64-mips.c (mips_elf64_gprel16_reloc): Likewise.
(mips_elf64_literal_reloc, mips_elf64_gprel32_reloc): Likewise.
(mips16_gprel_reloc): Likewise.

[gdb/symtab] Use lambda function instead of addrmap_foreach_check

Use a lambda function instead of addrmap_foreach_check,
which removes the need for static variables.

Also remove unnecessary static on local var temp_obstack in test_addrmap.

gdb/ChangeLog:

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

* addrmap.c (addrmap_foreach_check): Remove.
(array, val1, val2): Move ...
(test_addrmap): ... here.  Remove static on temp_obstack.  Use lambda
function instead of addrmap_foreach_check.

elf: Treat undefined version as hidden

Since undefined version can't be used to resolve any references without
the original definition, treat it as hidden.

bfd/

PR binutils/28158
* elf.c (_bfd_elf_get_symbol_version_string): Treat undefined
version as hidden.

ld/

PR binutils/28158
* testsuite/ld-elf/linux-x86.exp: Run PR binutils/28158 tests.
* testsuite/ld-elf/pr28158-1.c: New file.
* testsuite/ld-elf/pr28158-2.S: Likewise.
* testsuite/ld-elf/pr28158.nd: Likewise.
* testsuite/ld-elf/pr28158.rd: Likewise.
* testsuite/ld-elf/pr28158.t: Likewise.
* testsuite/ld-elfvers/vers2.dsym: Updated.
* testsuite/ld-elfvers/vers3.dsym: Likewise.
* testsuite/ld-elfvers/vers6.dsym: Likewise.
* testsuite/ld-elfvers/vers19.dsym: Likewise.
* testsuite/ld-elfvers/vers22.dsym: Likewise.
* testsuite/ld-elfvers/vers23.dsym: Likewise.
* testsuite/ld-elfvers/vers23d.dsym: Likewise.
* testsuite/ld-elfvers/vers27d4.dsym: Likewise.
* testsuite/ld-elfvers/vers28c.dsym: Likewise.

[gdb/symtab] Implement addrmap_mutable_find

Currently addrmap_mutable_find is not implemented:
...
static void *
addrmap_mutable_find (struct addrmap *self, CORE_ADDR addr)
{
  /* Not needed yet.  */
  internal_error (__FILE__, __LINE__,
                  _("addrmap_find is not implemented yet "
                    "for mutable addrmaps"));
}
...

I implemented this because I needed it during debugging, to be able to do:
...
(gdb) p ((dwarf2_psymtab *)addrmap_find (map, addr))->filename
...
before and after a call to addrmap_set_empty.

Since this is not used otherwise, added addrmap unit test.

Build on x86_64-linux, tested by doing:
...
$ gdb -q -batch -ex "maint selftest addrmap"
Running selftest addrmap.
Ran 1 unit tests, 0 failed
...

gdb/ChangeLog:

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

        * gdb/addrmap.c (addrmap_mutable_find): Implement
        [GDB_SELF_TESTS] (CHECK_ADDRMAP_FIND): New macro.
        [GDB_SELF_TESTS] (core_addr, addrmap_foreach_check, test_addrmap)
(_initialize_addrmap): New function.

gas: correctly output XCOFF tbss symbols with XTY_CM type.

Global tbss symbols weren't correctly handled and were generating
a symbol with XTY_SD instead of XTY_CM as expected.

gas/
* config/tc-ppc.c (ppc_frog_symbol): Generate a XTY_CM when
a symbol has a storage class of XMC_UL.

gas: always add dummy symbols when creating XCOFF sections.

Most of the algorithms for XCOFF in tc-ppc.c assume that
the csects field of a ppc_xcoff_section isn't NULL.
This was already made for most of the sections with the creation
of a dummy symbol.
This patch simply mades it default when creating a xcoff_section.

gas/
* config/tc-ppc.c (ppc_init_xcoff_section): Always create
the dummy symbol.
(md_begin): Adjust ppc_init_xcoff_section call.
(ppc_comm): Likewise.
(ppc_change_csect): Likewise.

PR28156, rename.c doesn't compile with MinGW

Guard against lack of struct timespec definition.

PR 28156
* rename.c (get_stat_atime, get_stat_mtime): Don't compile
unless HAVE_UTIMENSAT is defined.

PR28155, Superfluous "the" in the man page

PR 28155
* ld.texi (Options <runtime library name>): Correct grammar.

revise PE IMAGE_SCN_LNK_NRELOC_OVFL test

* coffcode.h (coff_set_alignment_hook): Test that the resulting
reloc count is not less than 0xffff.

gdb: follow-fork: push target and add thread in target_follow_fork

In the context of ROCm-gdb [1], the ROCm target sits on top of the
linux-nat target.  when a process forks, it needs to carry over some
data from the forking inferior to the fork child inferior.  Ideally, the
ROCm target would implement the follow_fork target_ops method, but there
are some small problems.  This patch fixes these, which helps the ROCm
target, but also makes things more consistent and a bit nicer in
general, I believe.

The main problem is: when follow-fork-mode is "parent",
target_follow_fork is called with the parent as the current inferior.
When it's "child", target_follow_fork is called with the child as the
current inferior.  This means that target_follow_fork is sometimes
called on the parent's target stack and sometimes on the child's target
stack.

The parent's target stack may contain targets above the process target,
such as the ROCm target.  So if follow-fork-child is "parent", the ROCm
target would get notified of the fork and do whatever is needed.  But
the child's target stack, at that moment, only contains the exec and
process target copied over from the parent.  The child's target stack is
set up by follow_fork_inferior, before calling target_follow_fork.  In
that case, the ROCm target wouldn't get notified of the fork.

For consistency, I think it would be good to always call
target_follow_fork on the parent inferior's target stack.  I think it
makes sense as a way to indicate "this inferior has called fork, do
whatever is needed".  The desired outcome of the fork (whether an
inferior is created for the child, do we need to detach from the child)
can be indicated by passed parameter.

I therefore propose these changes:

 - make follow_fork_inferior always call target_follow_fork with the
   parent as the current inferior.  That lets all targets present on the
   parent's target stack do some fork-related handling and push
   themselves on the fork child's target stack if needed.

   For this purpose, pass the child inferior down to target_follow_fork
   and follow_fork implementations.  This is nullptr if no inferior is
   created for the child, because we want to detach from it.

 - as a result, in follow_fork_inferior, detach from the parent inferior
   (if needed) only after the target_follow_fork call.  This is needed
   because we want to call target_follow_fork before the parent's
   target stack is torn down.

 - hand over to the targets in the parent's target stack (including the
   process target) the responsibility to push themselves, if needed, to
   the child's target stack.  Also hand over the responsibility to the
   process target, at the same time, to create the child's initial
   thread (just like we do for follow_exec).

 - pass the child inferior to exec_on_vfork, so we don't need to swap
   the current inferior between parent and child.  Nothing in
   exec_on_vfork depends on the current inferior, after this change.

   Although this could perhaps be replaced with just having the exec
   target implement follow_fork and push itself in the child's target
   stack, like the process target does... We would just need to make
   sure the process target calls beneath()->follow_fork(...).  I'm not
   sure about this one.

gdb/ChangeLog:

* target.h (struct target_ops) <follow_fork>: Add inferior*
parameter.
(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_target::follow_fork): Likewise, and call
inf_ptrace_target::follow_fork.
* linux-nat.h (class linux_nat_target) <follow_fork>: Likewise.
* linux-nat.c (linux_nat_target::follow_fork): Likewise, and
call inf_ptrace_target::follow_fork.
* obsd-nat.h (obsd_nat_target) <follow_fork>: Likewise.
* obsd-nat.c (obsd_nat_target::follow_fork): Likewise, and call
inf_ptrace_target::follow_fork.
* remote.c (class remote_target) <follow_fork>: Likewise.
(remote_target::follow_fork): Likewise, and call
process_stratum_target::follow_fork.
* process-stratum-target.h (class process_stratum_target)
<follow_fork>: New.
* process-stratum-target.c
(process_stratum_target::follow_fork): New.
* target-delegates.c: Re-generate.

[1] https://github.com/ROCm-Developer-Tools/ROCgdb

Change-Id: I460bd0af850f0485e8aed4b24c6d8262a4c69929

Automatic date update in version.in

Fixes for mi-fortran-modules.exp fixes

Output has additional information for a given filename.

gdb/testsuite/ChangeLog
* gdb.mi/mi-fortran-modules.exp (system_modules_pattern,
system_module_symbols_pattern): Add check for additional symbols
on the line

gdbsupport: add debug assertions in gdb::optional::get

The libstdc++ version of optional contains some runtime checks enabled
when _GLIBCXX_DEBUG is defined.  I think it would be useful if our
version contained similar checks.

Add checks in the two `get` methods, also conditional on _GLIBCXX_DEBUG.
I think it's simpler to use that macro rather than introducing a new
GDB-specific one, as I think that if somebody is interested in enabling
these runtime checks, they'll also be interested in enabling the
libstdc++ runtime checks (and vice-versa).

I implemented these checks using gdb_assert.  Note that gdb_assert
throws (after querying the user), and we are in noexcept methods.  That
means that std::terminate / abort will immediately be called.  I think
this is ok, since if those were "real" _GLIBCXX_DEBUG checks, abort
would be called straight away.

If I add a dummy failure, it looks like so:

    $ ./gdb -q -nx --data-directory=data-directory
    /home/simark/src/binutils-gdb/gdb/../gdbsupport/gdb_optional.h:206: internal-error: T& gdb::optional<T>::get() [with T = int]: Assertion `this->has_value ()' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    Quit this debugging session? (y or n) n
    [1]    658767 abort (core dumped)  ./gdb -q -nx --data-directory=data-directory

Change-Id: Iadfdcd131425bd2ca6a2de30d7b22e9b3cc67793

[gdb/testsuite] templates.exp to accept clang++ output

Please consider below testcase with intended error.
``````````
    constexpr const char cstring[] = "Eta";
    template <const char*, typename T> class Column {};
    using quick = Column<cstring,double>; // cstring without '&'

    void lookup() {
      quick c1;
      c1.ls();
    }
``````````
It produces below error.
``````````
no member named 'ls' in 'Column<&cstring, double>'.
``````````
Please note that error message contains '&' for cstring, which is absent
in actual program.
Clang++ does not generate & in such cases and this should also be
accepted as correct output.

gdb/testsuite/ChangeLog:

* gdb.cp/templates.exp: Accept different but correct output
from the Clang++ compiled binary also.

Automatic date update in version.in

Handle compiler-generated suffixes in Ada names

The compiler may add a suffix to a mangled name.  A typical example
would be splitting a function and creating a ".cold" variant.

This patch changes Ada decoding (aka demangling) to handle these
suffixes.  It also changes the encoding process to handle them as
well.

A symbol like "function.cold" will now be displayed to the user as
"function[cold]".  The "." is not simply preserved because that is
already used in Ada.

Remove uses of fprintf_symbol_filtered

I believe that many calls to fprintf_symbol_filtered are incorrect.
In particular, there are some that pass a symbol's print name, like:

  fprintf_symbol_filtered (gdb_stdout, sym->print_name (),
   current_language->la_language, DMGL_ANSI);

fprintf_symbol_filtered uses the "demangle" global to decide whether
or not to demangle -- but print_name does this as well.  This can lead
to double-demangling.  Normally this could be innocuous, except I also
plan to change Ada demangling in a way that causes this to fail.

Handle type qualifier for enumeration name

Pierre-Marie noticed that the Ada expression "TYPE'(NAME)" resolved
incorrectly when "TYPE" was an enumeration type.  Here, "NAME" should
be unambiguous.

This patch fixes this problem.  Note that the patch is not perfect --
it does not give an error if TYPE is an enumeration type but NAME is
not an enumerator but does have some other meaning in scope.  Fixing
this proved difficult, and so I've left it out.

Remove the type_qualifier global

The type_qualifier global is no longer needed in the Ada expression
parser, so this removes it.

Defer Ada character literal resolution

In Ada, an enumeration type can use a character literal as one of the
enumerators.  The Ada expression parser handles the appropriate
conversion.

It turns out, though, that this conversion was handled incorrectly.
For an expression like TYPE'(EXP), the conversion would be done for
any such literal appearing in EXP -- but only the outermost such
expression should really be affected.

This patch defers the conversion until the resolution phase, fixing
the bug.

Refactor Ada resolution

In a subsequent patch, it will be convenient if an Ada expression
operation can supply its own replacement object.  This patch refactors
Ada expression resolution to make this possible.

Remove add_symbols_from_enclosing_procs

I noticed that add_symbols_from_enclosing_procs is empty, and can be
removed.  The one caller, ada_add_local_symbols, can also be
simplified, removing some code that, I think, was an incorrect attempt
to handle nested functions.

Avoid crash in varobj deletion

PR varobj/28131 points out a crash in the varobj deletion code.  It
took a while to reproduce this, but essentially what happens is that a
top-level varobj deletes its root object, then deletes the "dynamic"
object.  However, deletion of the dynamic object may cause
~py_varobj_iter to run, which in turn uses gdbpy_enter_varobj:

gdbpy_enter_varobj::gdbpy_enter_varobj (const struct varobj *var)
: gdbpy_enter (var->root->exp->gdbarch, var->root->exp->language_defn)
{
}

However, because var->root has already been destroyed, this is
invalid.

I've added a new test case.  This doesn't reliably crash, but the
problem can easily be seen under valgrind (and, I presume, with ASAN,
though I did not try this).

Tested on x86-64 Fedora 32.  I also propose putting this on the GDB 11
branch, with a suitable ChangeLog entry of course.

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

[gdb/testsuite] Fix gdb.dwarf2/dw2-using-debug-str.exp with cc-with-dwz-m

When running with target board cc-with-dwz-m, we run into:
...
(gdb) file dw2-using-debug-str-no-debug-str^M
Reading symbols from dw2-using-debug-str-no-debug-str...^M
(gdb) FAIL: gdb.dwarf2/dw2-using-debug-str.exp: file dw2-using-debug-str
...

With native, the .debug_str section is present in the
dw2-using-debug-str executable, and removed from the
dw2-using-debug-str-no-debug-str executable.  When loading the latter, a dwarf
error is triggered.

With cc-with-dwz-m, the .debug_str section is not present in the
dw2-using-debug-str executable, because it's already moved to
.tmp/dw2-using-debug-str.dwz.  Consequently, the removal has no effect, and no
dwarf error is triggered, which causes the FAIL.

The same problem arises with target board cc-with-gnu-debuglink.

Fix this by detecting whether the .debug_str section is missing, and skipping
the remainder of the test-case.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.dwarf2/dw2-using-debug-str.exp: Handle missing .debug_str
section in dw2-using-debug-str.

[gdb/testsuite] Fix gdb.dwarf2/dw2-using-debug-str.exp with cc-with-gdb-index

When running with target board cc-with-gdb-index, we run into:
...
(gdb) file dw2-using-debug-str-no-debug-str^M
Reading symbols from dw2-using-debug-str-no-debug-str...^M
Dwarf Error: DW_FORM_strp used without required section^M
(gdb) FAIL: gdb.dwarf2/dw2-using-debug-str.exp: file dw2-using-debug-str
...

The test expects the dwarf error, but has no matching pattern for the entire
output.

Fix this by updating the regexp.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.dwarf2/dw2-using-debug-str.exp: Update regexp to match
cc-with-gdb-index output.

[gdb/testsuite] Fix gdb.dwarf2/per-bfd-sharing.exp with cc-with-gdb-index

When running with target board cc-with-gdb-index, we run into:
...
rm: cannot remove '/tmp/tmp.JmYTeiuFjj/*.gdb-index': \
  No such file or directory^M
FAIL: gdb.dwarf2/per-bfd-sharing.exp: \
  couldn't remove files in temporary cache dir
...

Fix this, as in gdb.base/index-cache.exp, by only FAILing when
$expecting_index_cache_use.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.dwarf2/per-bfd-sharing.exp: Only expect index-cache files
when $expecting_index_cache_use.

[gdb/testsuite] Fix gdb.dwarf2/gdb-index-nodebug.exp with cc-with-gdb-index

When running with target board cc-with-gdb-index, we run into:
...
(gdb) save gdb-index .^M
Error while writing index for `gdb-index-nodebug': \
  Cannot use an index to create the index^M
(gdb) FAIL: gdb.dwarf2/gdb-index-nodebug.exp: try to save gdb index
...

Fix this by detecting an already present index, and marking the test
unsupported.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.dwarf2/gdb-index-nodebug.exp: Mark unsupported when index
already present.

[gdb/testsuite] Fix gdb.dwarf2/fission-relative-dwo.exp with cc-with-gdb-index

When running with target board cc-with-gdb-index, we run into:
...
gdb compile failed, warning: Could not find DWO CU \
  fission-relative-dwo.dwo(0x1234) referenced by CU at offset 0xc7 \
  [in module outputs/gdb.dwarf2/fission-relative-dwo/.tmp/fission-relative-dwo]
UNTESTED: gdb.dwarf2/fission-relative-dwo.exp: fission-relative-dwo.exp
ERROR: failed to compile fission-relative-dwo
...

The problem is that:
- the .dwo file is found relative to the executable, and
- cc-with-tweaks.sh moves the executable to a temp dir, but not
  the .dwo file.

Fix this by copying the .dwo file alongside the executable in the temp dir.

Verified changes using shellcheck.

Tested on x86_64-linux.

gdb/ChangeLog:

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

* contrib/cc-with-tweaks.sh: Copy .dwo files alongside executable.

gdb: Make the builtin "boolean" type an unsigned type

When printing the fields of a register that is of a custom struct type,
the "unpack_bits_as_long ()" function is used:

    do_val_print (...)
      cp_print_value_fields (...)
        value_field_bitfield (...)
          unpack_value_bitfield (...)
            unpack_bits_as_long (...)

This function may sign-extend the extracted field while returning it:

    val >>= lsbcount;

    if (...)
      {
        valmask = (((ULONGEST) 1) << bitsize) - 1;
        val &= valmask;
        if (!field_type->is_unsigned ())
     if (val & (valmask ^ (valmask >> 1)))
         val |= ~valmask;
      }

    return val;

lsbcount:   Number of lower bits to get rid of.
bitsize:    The bit length of the field to be extracted.
val:        The register value.
field_type: The type of field that is being handled.

While the logic here is correct, there is a problem when it is
handling "field_type"s of "boolean".  Those types are NOT marked
as "unsigned" and therefore they end up being sign extended.
Although this is not a problem for "false" (0), it definitely
causes trouble for "true".

This patch constructs the builtin boolean type as such that it is
marked as an "unsigned" entity.

The issue tackled here was first encountered for arc-elf32 target
running on an x86_64 machine.  The unit-test introduced in this change
has passed for all the targets (--enable-targets=all) running on the
same x86_64 host.

Fixes: https://sourceware.org/PR28104

Automatic date update in version.in

[gdb/testsuite] Fix gdb.base/maint.exp with cc-with-gdb-index

With target board cc-with-gdb-index we run into:
...
FAIL: gdb.base/maint.exp: maint print statistics
...

The output that is checked is:
...
Statistics for 'maint':^M
  Number of "minimal" symbols read: 53^M
  Number of "full" symbols read: 40^M
  Number of "types" defined: 60^M
  Number of symbol tables: 7^M
  Number of symbol tables with line tables: 2^M
  Number of symbol tables with blockvectors: 2^M
  Number of read CUs: 2^M
  Number of unread CUs: 5^M
  Total memory used for objfile obstack: 20320^M
  Total memory used for BFD obstack: 4064^M
  Total memory used for string cache: 4064^M
...
and the regexp doesn't match because it expects the "Number of read/unread
CUs" lines in a different place.

Fix this by updating the regexp.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.base/maint.exp: Update "maint print statistics" to match
output with target board cc-with-gdb-index.

[gdb/testsuite] Fix gdb.base/index-cache.exp with cc-with-gdb-index

With target board cc-with-gdb-index we run into:
...
FAIL: gdb.base/index-cache.exp: couldn't remove files in temporary cache dir
...

The problem is that there are no files to remove, because the index cache
isn't used, as indicated by $expecting_index_cache_use.

Fix this by only FAILing when $expecting_index_cache_use.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

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

* gdb.base/index-cache.exp:

Automatic date update in version.in

Automatic date update in version.in

Use iterator_range in more places

This changes a couple of spots to replace custom iterator range
classes with a specialization of iterator_range.

Regression tested on x86-64 Fedora 34.

Replace exception_print_same with operator!=

I noticed that exception_print_same is only used in a single spot, and
it seemed to be better as an operator!= method attached to
gdb_exception.

Regression tested on x86-64 Fedora 34.

[gdb/build] Disable attribute nonnull

With trunk gcc (12.0) we're running into a -Werror=nonnull-compare build
breaker in gdb, which caused a broader review of the usage of the nonnull
attribute.

The current conclusion is that it's best to disable this.  This is explained
at length in the gdbsupport/common-defs.h comment.

Tested by building with trunk gcc.

gdb/ChangeLog:

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

* gdbsupport/common-defs.h (ATTRIBUTE_NONNULL): Disable.

gas: ensure XCOFF DWARF subsection are initialized to 0

debug_abbrev doesn't use end_exp to compute its size. However, it must
be NULL. Otherwise, ppc_xcoff_end might try to access uninitialized
memory.

gas/
* config/tc-ppc.c (ppc_dwsect): Use XCNEW instead of XNEW when creating
a new subsection.

bfd: ensure that symbols targeted by DWARF relocations are kept in XCOFF

This patch improves XCOFF garbage collector pass, in order to keep
symbols being referenced only by special sections like DWARF sections.

bfd/
* xcofflink.c (xcoff_mark): Replace SEC_MARK by gc_mark.
Look through relocations even if xcoff_section_data is NULL.
(xcoff_sweep): Check if any sections of a file is kept before
adding its special sections.
Call xcoff_mark for special sessions being kept instead of just
marking them.
(SEC_MARK): Remove
(xcoff_mark_symbol): Replace SEC_MARK by gc_mark.
(xcoff_keep_symbol_p): Likewise.
(bfd_xcoff_size_dynamic_sections): Likewise.
(xcoff_find_tc0): Likewise.

bfd: avoid a crash when debug_section isn't created in XCOFF

bfd/
* xcofflink.c (bfd_xcoff_size_dynamic_sections):
Add check to know if debug_section is initialized.

readelf: catch archive_file_size of -1

Fuzzers might put -1 in arhdr.ar_size.  If the size is rounded up to
and even number of bytes we get zero.

* readelf.c (process_archive): Don't round up archive_file_size.
Do round up next_arhdr_offset calculation.

reloc_upper_bound size calculations

Section reloc_count is an unsigned int.  Adding one for a NULL
terminator to an array of arelent pointers can wrap the count to
zero.  Avoid that by doing the addition as longs.

* coffgen.c (coff_get_reloc_upper_bound): Don't overflow unsigned
int expression.
* elf.c (_bfd_elf_get_reloc_upper_bound): Likewise.
* elf64-sparc.c (elf64_sparc_get_reloc_upper_bound): Likewise.
* mach-o.c (bfd_mach_o_get_reloc_upper_bound): Likewise.
* vms-alpha.c (alpha_vms_get_reloc_upper_bound): Likewise.

Sanity check _bfd_coff_read_string_table

* coffgen.c (_bfd_coff_read_string_table): Catch overflows
when calculating string table file location.

IMAGE_SCN_LNK_NRELOC_OVFL

From microsoft docs: It is an error if IMAGE_SCN_LNK_NRELOC_OVFL is
set and there are fewer than 0xffff relocations in the section.

* coffcode.h (coff_set_alignment_hook): Sanity check overflow
reloc count.

gdb: fix nr_bits gdb_assert in append_flags_type_field

The assertion

    gdb_assert (nr_bits >= 1 && nr_bits <= type_bitsize);

is not correct.  Well, it's correct in that we do want the number of
bits to be in the range [1, type_bitsize].  But we don't check anywhere
that the end of the specified flag is within the containing type.

The following code should generate a failed assertion, as the flag goes
past the 32 bits of the underlying type, but it's currently not caught:

    static void
    test_print_flag (gdbarch *arch)
    {
      type *flags_type = arch_flags_type (arch, "test_type", 32);
      type *field_type = builtin_type (arch)->builtin_uint32;
      append_flags_type_field (flags_type, 31, 2, field_type, "invalid");
    }

(You can test this by registering it as a selftest using
selftests::register_test_foreach_arc and running.)

Change the assertion to verify that the end bit is within the range of
the underlying type.  This implicitly verifies that nr_bits is not
too big as well, so we don't need a separate assertion for that.

Change-Id: I9be79e5fd7a5917bf25b03b598727e6274c892e8
Co-Authored-By: Tony Tye <Tony.Tye@amd.com>

Automatic date update in version.in

obsd-nat: Report both thread and PID in ::pid_to_str.

This improves the output of info threads when debugging multiple
inferiors (e.g. after a fork with detach_on_fork disabled).

obsd-nat: Various fixes for fork following.

- Don't use #ifdef's on ptrace ops.  obsd-nat.h didn't include
  <sys/ptrace.h>, so the virtual methods weren't always overridden
  causing the fork following to not work.  In addition, the thread and
  fork code is intertwined in ::wait and and the lack of #ifdef's
  there already assumed both were present.  Finally, both of these
  ptrace ops have been present in OpenBSD for at least 10 years.

- Move duplicated code to enable PTRACE_FORK event reporting to a
  single function and invoke it on new child processes reported via
  PTRACE_FORK.

- Don't return early from PTRACE_FORK handling, but instead reset
  wptid to the correct ptid if the child reports its event before the
  parent.  This allows the ptid fixup code to add thread IDs if the
  first event for a process is a PTRACE_FORK event.  This also
  properly returns ptid's with thread IDs when reporting PTRACE_FORK
  events.

- Handle detach_fork by skipping the PT_DETACH.

obsd-nat: Various fixes to obsd_nat_target::wait.

- Call inf_ptrace_target::wait instead of duplicating the code.
  Replace a check for WIFSTOPPED on the returned status from waitpid
  by checking for TARGET_WAITKIND_STOPPED in the parsed status as is
  done in fbsd_nat_target::wait.

- Don't use inferior_ptid when deciding if a new process is a child vs
  parent of the fork.  Instead, use find_inferior_pid and assume that
  if an inferior already exists, the pid in question is the parent;
  otherwise, the pid is the child.

- Don't use inferior_ptid when deciding if the ptid of the process
  needs to be updated with an LWP ID, or if this is a new thread.
  Instead, use the approach from fbsd-nat which is to check if a ptid
  without an LWP exists and if so update the ptid of that thread
  instead of adding a new thread.

x86-bsd-nat: Only define gdb_ptrace when using debug registers.

This fixes an unused function warning on OpenBSD which does not
support PT_GETDBREGS.

Don't compile x86 debug register support on OpenBSD.

Simon Marchi tried gdb on OpenBSD, and it immediately segfaults when
running a program.  Simon tracked down the problem to x86_dr_low.get_status
being nullptr at this point:

    (lldb) print x86_dr_low.get_status
    (unsigned long (*)()) $0 = 0x0000000000000000
    (lldb) bt
    * thread #1, stop reason = step over
      * frame #0: 0x0000033b64b764aa gdb`x86_dr_stopped_data_address(state=0x0000033d7162a310, addr_p=0x00007f7ffffc5688) at x86-dregs.c:645:12
        frame #1: 0x0000033b64b766de gdb`x86_dr_stopped_by_watchpoint(state=0x0000033d7162a310) at x86-dregs.c:687:10
        frame #2: 0x0000033b64ea5f72 gdb`x86_stopped_by_watchpoint() at x86-nat.c:206:10
        frame #3: 0x0000033b64637fbb gdb`x86_nat_target<obsd_nat_target>::stopped_by_watchpoint(this=0x0000033b65252820) at x86-nat.h:100:12
        frame #4: 0x0000033b64d3ff11 gdb`target_stopped_by_watchpoint() at target.c:468:46
        frame #5: 0x0000033b6469b001 gdb`watchpoints_triggered(ws=0x00007f7ffffc61c8) at breakpoint.c:4790:32
        frame #6: 0x0000033b64a8bb8b gdb`handle_signal_stop(ecs=0x00007f7ffffc61a0) at infrun.c:6072:29
        frame #7: 0x0000033b64a7e3a7 gdb`handle_inferior_event(ecs=0x00007f7ffffc61a0) at infrun.c:5694:7
        frame #8: 0x0000033b64a7c1a0 gdb`fetch_inferior_event() at infrun.c:4090:5
        frame #9: 0x0000033b64a51921 gdb`inferior_event_handler(event_type=INF_REG_EVENT) at inf-loop.c:41:7
        frame #10: 0x0000033b64a827c9 gdb`infrun_async_inferior_event_handler(data=0x0000000000000000) at infrun.c:9384:3
        frame #11: 0x0000033b6465bd4f gdb`check_async_event_handlers() at async-event.c:335:4
        frame #12: 0x0000033b65070917 gdb`gdb_do_one_event() at event-loop.cc:216:10
        frame #13: 0x0000033b64af0db1 gdb`start_event_loop() at main.c:421:13
        frame #14: 0x0000033b64aefe9a gdb`captured_command_loop() at main.c:481:3
        frame #15: 0x0000033b64aed5c2 gdb`captured_main(data=0x00007f7ffffc6470) at main.c:1353:4
        frame #16: 0x0000033b64aed4f2 gdb`gdb_main(args=0x00007f7ffffc6470) at main.c:1368:7
        frame #17: 0x0000033b6459d787 gdb`main(argc=5, argv=0x00007f7ffffc6518) at gdb.c:32:10
        frame #18: 0x0000033b6459d521 gdb`___start + 321

On BSDs, get_status is set in _initialize_x86_bsd_nat, but only if
HAVE_PT_GETDBREGS is defined.  PT_GETDBREGS doesn't exist on OpenBSD, so
get_status (and the other fields of x86_dr_low) are left as nullptr.

OpenBSD doesn't support getting or setting the x86 debug registers, so
fix by omitting debug register support entirely on OpenBSD:

- Change x86bsd_nat_target to only inherit from x86_nat_target if
  PT_GETDBREGS is supported.

- Don't include x86-nat.o and nat/x86-dregs.o for OpenBSD/amd64.  They
  were already omitted for OpenBSD/i386.

Fix for gdb.tui/tui-layout-asm.exp

The width of the window is too narrow to display the entire assembly line.
The width of the columns in the window changes as the test walks thru the
terminal window output.  The column change results in the first and second
reads of the same line to differ thus causing the test to fail.  Increasing
the width of the window keeps the column width consistent thru the test.

If the test fails, the added check prints an message to the log file if
the failure may be due to the window being too narrow.

gdb/testsuite/ChangeLog

* gdb.tui/tui-layout-asm.exp: Replace window width of 80 with the
tui_asm_window_width variable for the width. Add if
count_whitespace check.
(count_whitespace): New proc

guile/scm-math: indentation fixes

Changes the indenting of a few expressions in
vlscm_convert_typed_number to be better in line with the prevailing
code style.

gdb/ChangeLog:

2021-07-30  George Barrett  <bob@bob131.so>

* guile/scm-math.c (vlscm_convert_typed_number): Fix the
indentation of calls to gdbscm_make_out_of_range_error.

Change-Id: I7463998b77c17a00e88058e89b52fa029ee40e03

guile: fix make-value with pointer type

Calling the `make-value' procedure with an integer value and a pointer
type for the #:type argument triggers a failed assertion in
`get_unsigned_type_max', as that function doesn't consider pointers to
be an unsigned type. This commit fixes the issue by adding a separate
code path for pointers.

As previously suggested, range checking is done using a new helper
function in gdbtypes.

gdb/ChangeLog:

2021-07-30  George Barrett  <bob@bob131.so>

* gdbtypes.h (get_pointer_type_max): Add declaration.
* gdbtypes.c (get_pointer_type_max): Add definition for new
helper function.
* guile/scm-math.c (vlscm_convert_typed_number): Add code path
for handling conversions to pointer types without failing an
assert.

gdb/testsuite/ChangeLog:

2021-07-30  George Barrett  <bob@bob131.so>

* gdb.guile/scm-math.exp (test_value_numeric_ops): Add test
for creating pointers with make-value.
(test_make_pointer_value, test_pointer_numeric_range): Add
test procedures containing checks for integer-to-pointer
validation.

Change-Id: I9994dd1c848840a3d995f745e6d72867732049f0

gdbtypes: return value from get_unsigned_type_max

Changes the signature of get_unsigned_type_max to return the computed
value rather than returning void and writing the value into a pointer
passed by the caller.

gdb/ChangeLog:

2021-07-30  George Barrett  <bob@bob131.so>

* gdbtypes.h (get_unsigned_type_max): Change signature to
return the result instead of accepting a pointer argument in
which to store the result.
* gdbtypes.c (get_unsigned_type_max): Likewise.
* guile/scm-math.c (vlscm_convert_typed_number): Update caller
of get_unsigned_type_max.
(vlscm_integer_fits_p): Likewise.

Change-Id: Ibb1bf0c0fa181fac7853147dfde082a7d1ae2323

gas: improve C_BSTAT and C_STSYM symbols handling on XCOFF

A C_BSTAT debug symbol specifies the beginning of a static block.
Its n_value is the index of the csect containing static symbols.
A C_STSYM debug symbol represents the stabstring of a statically
allocated symbol. Its n_value is the offset in the csect pointed
by the containing C_BSTAT.

These two special n_value were not correctly handled both when
generating object files with gas or when reading them with objdump.
This patch tries to improve that and, above all, to allow gas-generated
object files with such symbols to be accepted by AIX ld.

bfd/
* coff-bfd.c (bfd_coff_get_syment): Adjust n_value of symbols
having fix_value = 1 in order to be an index and not a memory
offset.
* coffgen.c (coff_get_symbol_info): Likewize.
(coff_print_symbol): Likewize.

gas/
* config/tc-ppc.c (ppc_frob_label): Don't change within if
already set.
(ppc_stabx): Remove workaround changing exp.X_add_symbol's
within.
* config/tc-ppc.h (struct ppc_tc_sy): Update comments.
* symbols.c (resolve_symbol_value): Remove symbol update
when final_val is 0 and it's an AIX debug symbol.
* testsuite/gas/ppc/aix.exp: Add new tests.
* testsuite/gas/ppc/xcoff-stsym-32.d: New test.
* testsuite/gas/ppc/xcoff-stsym-64.d: New test.
* testsuite/gas/ppc/xcoff-stsym.s: New test.

Guile: temporary breakpoints

Adds API to the Guile bindings for creating temporary breakpoints and
querying whether an existing breakpoint object is temporary. This is
effectively a transliteration of the Python implementation.

It's worth noting that the added `is_temporary' flag is ignored in the
watchpoint registration path. This replicates the behaviour of the
Python implementation, but might be a bit surprising for users.

gdb/ChangeLog:

2021-06-09  George Barrett  <bob@bob131.so>

* guile/scm-breakpoint.c (gdbscm_breakpoint_object::spec): Add
is_temporary field.
(temporary_keyword): Add keyword object for make-breakpoint
argument parsing.
(gdbscm_make_breakpoint): Accept #:temporary keyword argument
and store the value in the allocated object's
spec.is_temporary.
(gdbscm_register_breakpoint_x): Pass the breakpoint's
spec.is_temporary value to create_breakpoint.
(gdbscm_breakpoint_temporary): Add breakpoint-temporary?
procedure implementation.
(breakpoint_functions::make-breakpoint): Update documentation
string and fix a typo.
(breakpoint_functions::breakpoint-temporary?): Add
breakpoint-temporary? procedure.
(gdbscm_initialize_breakpoints): Initialise temporary_keyword
variable.
NEWS (Guile API): Mention new temporary breakpoints API.

gdb/doc/ChangeLog:

2021-06-09  George Barrett  <bob@bob131.so>

* guile.texi (Breakpoints In Guile): Update make-breakpoint
documentation to reflect new #:temporary argument.
Add documentation for new breakpoint-temporary? procedure.

gdb/testsuite/ChangeLog:

2021-06-09  George Barrett  <bob@bob131.so>

* gdb.guile/scm-breakpoint.exp: Add additional tests for
temporary breakpoints.

Change-Id: I2de332ee7c256f5591d7141ab3ad50d31b871d17

Automatic date update in version.in

gdb: clean up some things in features/Makefile

Clean up some things I noticed:

 - we generate a regformats/microblaze-with-stack-protect.dat file.  I
   don't think this is used.  It could be used by a GDBserver built for
   Microblaze, but GDBserver isn't ported to Microblaze.  So I don't
   think that's used at all.  Remove the entry in features/Makefile and
   the file itself.

 - There are a bunch of *-expedite values in features/Makefile for
   architectures for which we don't generate dat files.  AFAIK, these
   *-expedite values are only used when generating dat files.  Remove
   those that are not necessary.

 - 32bit-segments.xml is not listed in the Makfile, but it's used.  This
   means that it wouldn't get re-generated if we were to change how C
   files are generated from the XML.  It looks like it was simply
   forgotten, add it.

Change-Id: I112d00db317102270e1df924473c37122ccb6c3a

x86: Simplify check for distinct TMM register operands

If any pair of operands in AMX instructions with 3 TMM register operands
are the same, the instruction will UD.  Don't call register_number to
check for distinct TMM register operands since all TMM register operands
have the same size.

* config/tc-i386.c (check_VecOperands): Remove register_number
call when checking for distinct TMM register operands.

ld: Run tmpdir/pr28138 only for native build

* PR ld/28138
* testsuite/ld-plugin/lto.exp: Run tmpdir/pr28138 only for
native build.

bfd: Close the file descriptor if there is no archive fd

Close the file descriptor if there is no archive plugin file descriptor
to avoid running out of file descriptors on thin archives with many
archive members.

bfd/

PR ld/28138
* plugin.c (bfd_plugin_close_file_descriptor): Close the file
descriptor there is no archive plugin file descriptor.

ld/

PR ld/28138
* testsuite/ld-plugin/lto.exp: Run ld/28138 tests.
* testsuite/ld-plugin/pr28138.c: New file.
* testsuite/ld-plugin/pr28138-1.c: Likewise.
* testsuite/ld-plugin/pr28138-2.c: Likewise.
* testsuite/ld-plugin/pr28138-3.c: Likewise.
* testsuite/ld-plugin/pr28138-4.c: Likewise.
* testsuite/ld-plugin/pr28138-5.c: Likewise.
* testsuite/ld-plugin/pr28138-6.c: Likewise.
* testsuite/ld-plugin/pr28138-7.c: Likewise.

ld: Report error reason when a library cannot be found

With "ulimit -n 20", report:

ld: cannot find -lgcc: Too many open files

instead of

ld: cannot find -lgcc

* ldfile.c (ldfile_open_file): Rport error reason when a library
cannot be found.

texi2pod.pl: add no-op --no-split option support [PR28144]

Change 2faf902da ("generate single html manual page by default")
added use of --no-split option to makeinfo. binutils reuses
makeinfo options for texi2pod.pl wrapper. Unsupported option
led to silent manpage truncation.

The change adds no-op option support.

etc/

* texi2pod.pl: Handle no-op --no-split option.

gdb: fix missing space in some info variables output

Fixes PR gdb/28121.  When a user declares an array like this:

  int * const foo_1[3];

And in GDB the user does this:

  (gdb) info variables foo
  All variables matching regular expression "foo":

  File test.c:
  1: int * constfoo_1[3];

Notice the missing space between 'const' and 'foo_1'.  This is fixed
in c_type_print_varspec_prefix (c-typeprint.c) by passing through the
flag that indicates if a trailing space is needed, rather than hard
coding the flag to false as we currently do.

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

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

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

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

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

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

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

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

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

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

gdb/ChangeLog:

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

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

Externalize the _bfd_set_gp_value function

This change adds an external-visible wrapper for the _bfd_set_gp_value
function.  This is a prerequisite for some gdb patches that better
handle powerpc64le relocations against ".TOC.".

* bfd.c (bfd_set_gp_value): New externally visible wrapper
for _bfd_set_gp_value.
* bfd-in2.h: Regenerate.

PowerPC: ignore sticky options for .machine

PowerPC gas and objdump for a long time have allowed certain -m/-M
options that extend a base cpu with extra functional units to be
specified before the base cpu.  For example, "-maltivec -mpower4" is
the same as "-mpower4 -maltivec".  See
https://sourceware.org/pipermail/binutils/2008-January/054935.html

It doesn't make as much sense that .machine keep any of these
"sticky" flags when handling a new base cpu.  See gcc PR101393.  I
think that instead .machine ought to override the command line.
That's what this patch does.  It is still possible to extend cpu
functionality with .machine.  For example the following can be
assembled when selecting a basic -mppc on the command line:
.machine power5
.machine altivec
frin 1,2
lvsr 3,4,5
Here, ".machine altivec" extends the ".machine power5" so that both
the power5 "frin" instruction and the altivec "lvsr" instruction are
enabled.  Swapping the two ".machine" directives would result in
failure to assemble "lvsr".

This change will expose some assembly errors, such as the one in
glibc/sysdeps/powerpc/powerpc64/tst-ucontext-ppc64-vscr.c, a file
compiled with -maltivec but containing
  asm volatile (".machine push;\n"
".machine \"power5\";\n"
"vspltisb %0,0;\n"
"vspltisb %1,-1;\n"
"vpkuwus %0,%0,%1;\n"
"mfvscr %0;\n"
"stvx %0,0,%2;\n"
".machine pop;"
: "=v" (v0), "=v" (v1)
: "r" (vscr_ptr)
: "memory");
It's just wrong to choose power5 for a bunch of altivec instructions
and in fact all of those .machine directives are unnecessary.

* config/tc-ppc.c (ppc_machine): Don't use command line
sticky options.

Automatic date update in version.in

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

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

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

Fix by marking this as XFAIL.

Tested on x86_64-linux.

gdb/ChangeLog:

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

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

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

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

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

Fix by marking this and related FAILs as XFAIL.

Tested on x86_64-linux.

gdb/ChangeLog:

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

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

gdb: remove VALUE_FRAME_ID and fix another frame debug issue

This commit was originally part of this patch series:

  (v1): https://sourceware.org/pipermail/gdb-patches/2021-May/179357.html
  (v2): https://sourceware.org/pipermail/gdb-patches/2021-June/180208.html
  (v3): https://sourceware.org/pipermail/gdb-patches/2021-July/181028.html

However, that series is being held up in review, so I wanted to break
out some of the non-related fixes in order to get these merged.

This commit addresses two semi-related issues, both of which are
problems exposed by using 'set debug frame on'.

The first issue is in frame.c in get_prev_frame_always_1, and was
introduced by this commit:

  commit a05a883fbaba69d0f80806e46a9457727fcbe74c
  Date:   Tue Jun 29 12:03:50 2021 -0400

      gdb: introduce frame_debug_printf

This commit replaced fprint_frame with frame_info::to_string.
However, the former could handle taking a nullptr while the later, a
member function, obviously requires a non-nullptr in order to make the
function call.  In one place we are not-guaranteed to have a
non-nullptr, and so, there is the possibility of triggering undefined
behaviour.

The second issue addressed in this commit has existed for a while in
GDB, and would cause this assertion:

  gdb/frame.c:622: internal-error: frame_id get_frame_id(frame_info*): Assertion `fi->this_id.p != frame_id_status::COMPUTING' failed.

We attempt to get the frame_id for a frame while we are computing the
frame_id for that same frame.

What happens is that when GDB stops we create a frame_info object for
the sentinel frame (frame #-1) and then we attempt to unwind this
frame to create a frame_info object for frame #0.

In the test case used here to expose the issue we have created a
Python frame unwinder.  In the Python unwinder we attemt to read the
program counter register.

Reading this register will initially create a lazy register value.
The frame-id stored in the lazy register value will be for the
sentinel frame (lazy register values hold the frame-id for the frame
from which the register will be unwound).

However, the Python unwinder does actually want to examine the value
of the program counter, and so the lazy register value is resolved
into a non-lazy value.  This sends GDB into value_fetch_lazy_register
in value.c.

Now, inside this function, if 'set debug frame on' is in effect, then
we want to print something like:

  frame=%d, regnum=%d(%s), ....

Where 'frame=%d' will be the relative frame level of the frame for
which the register is being fetched, so, in this case we would expect
to see 'frame=0', i.e. we are reading a register as it would be in
frame #0.  But, remember, the lazy register value actually holds the
frame-id for frame #-1 (the sentinel frame).

So, to get the frame_info for frame #0 we used to call:

  frame = frame_find_by_id (VALUE_FRAME_ID (val));

Where VALUE_FRAME_ID is:

  #define VALUE_FRAME_ID(val) (get_prev_frame_id_by_id (VALUE_NEXT_FRAME_ID (val)))

That is, we start with the frame-id for the next frame as obtained by
VALUE_NEXT_FRAME_ID, then call get_prev_frame_id_by_id to get the
frame-id of the previous frame.

The get_prev_frame_id_by_id function finds the frame_info for the
given frame-id (in this case frame #-1), calls get_prev_frame to get
the previous frame, and then calls get_frame_id.

The problem here is that calling get_frame_id requires that we know
the frame unwinder, so then have to try each frame unwinder in turn,
which would include the Python unwinder.... which is where we started,
and thus we have a loop!

To prevent this loop GDB has an assertion in place, which is what
actually triggers.

Solving the assertion failure is pretty easy, if we consider the code
in value_fetch_lazy_register and get_prev_frame_id_by_id then what we
do is:

  1. Start with a frame_id taken from a value,
  2. Lookup the corresponding frame,
  3. Find the previous frame,
  4. Get the frame_id for that frame, and
  5. Lookup the corresponding frame
  6. Print the frame's level

Notice that steps 3 and 5 give us the exact same result, step 4 is
just wasted effort.  We could shorten this process such that we drop
steps 4 and 5, thus:

  1. Start with a frame_id taken from a value,
  2. Lookup the corresponding frame,
  3. Find the previous frame,
  6. Print the frame's level

This will give the exact same frame as a result, and this is what I
have done in this patch by removing the use of VALUE_FRAME_ID from
value_fetch_lazy_register.

Out of curiosity I looked to see how widely VALUE_FRAME_ID was used,
and saw it was only used in one other place in valops.c:value_assign,
where, once again, we take the result of VALUE_FRAME_ID and pass it to
frame_find_by_id, thus introducing a redundant frame_id lookup.

I don't think the value_assign case risks triggering the assertion
though, as we are unlikely to call value_assign while computing the
frame_id for a frame, however, we could make value_assign slightly
more efficient, with no real additional complexity, by removing the
use of VALUE_FRAME_ID.

So, in this commit, I completely remove VALUE_FRAME_ID, and replace it
with a use of VALUE_NEXT_FRAME_ID, followed by a direct call to
get_prev_frame_always, this should make no difference in either case,
and resolves the assertion issue from value.c.

As I said, this patch was originally part of another series, the
original test relied on the fixes in that original series.  However, I
was able to create an alternative test for this issue by enabling
frame debug within an existing test script.

This commit probably fixes bug PR gdb/27938, though the bug doesn't
have a reproducer attached so it is not possible to know for sure.

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

Correct gs264e bfd_mach in mips_arch_choices.

opcodes/
    * mips-dis.c (mips_arch_choices): Correct gs264e bfd_mach.

Fix ld test case that assumes --enable-textrel-check

ld/
* testsuite/ld-x86-64/x86-64.exp (Build textrel-1): Use --warn-textrel.

Automatic date update in version.in

bfd: Set error to bfd_error_malformed_archive only if unset

When reading an archive member, set error to bfd_error_malformed_archive
on open_nested_file failure only if the error is unset.

PR ld/28138
* archive.c (_bfd_get_elt_at_filepos): Don't set error to
bfd_error_malformed_archive if it has been set.

Fix for mi-reverse.exp

This test fails on PPC64 because PPC64 prints the value of 3.5 with
more significant digits than on Intel. The patch updates the regular
expression to allow for more significant digits on the constant.

gdb/testsuite/ChangeLog

* gdb.mi/mi-reverse.exp: mi_execute_to exec-step reverse add check
for additional digits.

Fix the Windows build

The gdb build was broken on Windows after the patch to change
get_inferior_cwd.  This patch fixes the build.

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

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

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

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

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

The correct extraction should be:

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

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

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

PATCH [10/10] arm: Alias 'ra_auth_code' to r12 for pacbti.

gas/
2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>

* config/tc-arm.c (reg_names): Alias 'ra_auth_code' to r12.

PATCH [9/10] arm: add 'pacg' instruction for Armv8.1-M pacbti extension

gas/
2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>

* config/tc-arm.c (T16_32_TAB): Add '_pacg'.
(do_t_pacbti_pacg): New function.
(insns): Define 'pacg' insn.
* testsuite/gas/arm/armv8_1-m-pacbti.d: Add 'pacg' test.
* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.

opcodes/
2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>

* arm-dis.c (thumb32_opcodes): Add 'pacg'.

PATCH [8/10] arm: add 'autg' instruction for Armv8.1-M pacbti extension

gas/
2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>

* config/tc-arm.c (T16_32_TAB): Add '_autg'.
(insns): Define 'autg' insn.
* testsuite/gas/arm/armv8_1-m-pacbti.d: Add autg test.
* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.

opcodes/
2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>

* arm-dis.c (thumb32_opcodes): Add 'autg'.

PATCH [7/10] arm: add 'bxaut' instruction for Armv8.1-M pacbti extension

gas/
2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>

* config/tc-arm.c (T16_32_TAB): Add '_bxaut'.
(do_t_pacbti_nonop): New function.
(insns): Define 'bxaut' insn.
* testsuite/gas/arm/armv8_1-m-pacbti.d: Add 'bxaut' test.
* testsuite/gas/arm/armv8_1-m-pacbti.s: Likewise.

opcodes/
2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>

* arm-dis.c (thumb32_opcodes): Add 'bxaut'.

PATCH [6/10] arm: Add -march=armv8.1-m.main+pacbti flag

gas/
2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>

* config/tc-arm.c (pacbti_ext): Define.
(BAD_PACBTI): New macro.
(armv8_1m_main_ext_table): Add 'pacbti' extension.

include/
2021-06-11  Andrea Corallo  <andrea.corallo@arm.com>

* opcode/arm.h (ARM_EXT3_PACBTI, ARM_AEXT3_V8_1M_MAIN_PACBTI): New
macro.