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

PATCH [5/10] arm: Extend again arm_feature_set struct to provide more bits

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

* opcode/arm.h (arm_feature_set): Extend 'core' field.
(ARM_CPU_HAS_FEATURE, ARM_FSET_CPU_SUBSET, ARM_CPU_IS_ANY)
(ARM_MERGE_FEATURE_SETS, ARM_CLEAR_FEATURE, ARM_FEATURE_EQUAL)
(ARM_FEATURE_ZERO, ARM_FEATURE_CORE_EQUAL): Account for
'core[2]'.
(ARM_FEATURE_CORE_HIGH_HIGH): New macro.

PATCH [4/10] arm: add 'pac' 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 '_pac'.
(insns): Add 'pac' insn.
* testsuite/gas/arm/armv8_1-m-pacbti-bad.l: Add pac tests.
* testsuite/gas/arm/armv8_1-m-pacbti-bad.s: Likewise.
* testsuite/gas/arm/armv8_1-m-pacbti.d: Likewise.
* 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 'pac'.

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

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

* config/tc-arm.c (insns): Add 'aut.'
(T16_32_TAB): Add '_aut'.
* testsuite/gas/arm/armv8_1-m-pacbti-bad.l: Add 'aut' tests.
* testsuite/gas/arm/armv8_1-m-pacbti-bad.s: Likewise.
* testsuite/gas/arm/armv8_1-m-pacbti.d: Likewise.
* 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 'aut'.

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

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

* config/tc-arm.c
(enum operand_parse_code): Add OP_SP and OP_R12.
(parse_operands): Add switch cases for OP_SP and OP_R12.
(T16_32_TAB): Add '_pacbti'.
(do_t_pacbti): New function.
(insns): Add 'pacbti'.
* testsuite/gas/arm/armv8_1-m-pacbti-bad.d: New file.
* testsuite/gas/arm/armv8_1-m-pacbti-bad.l: Likewise.
* testsuite/gas/arm/armv8_1-m-pacbti-bad.s: Likewise.
* testsuite/gas/arm/armv8_1-m-pacbti.d: Add 'pacbti' to testcase.
* 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 'pacbti' instruction.

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

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

* config/tc-arm.c (insns): Add 'bti' insn.
* testsuite/gas/arm/armv8_1-m-pacbti.d: New file.
* 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 bti instruction.

gdb: move remaining ChangeLogs to legacy files

In commit:

  commit f069ea46a03ae868581d1c852da28e979ea1245a
  Date:   Sat Jul 3 16:29:08 2021 -0700

      Rename gdb/ChangeLog to gdb/ChangeLog-2021

The gdb/ChangeLog file was renamed, but all of the other ChangeLog
files relating to gdb were left in place.

As I understand things, the no ChangeLogs policy applies to all the
GDB related directories, so this commit renames all of the remaining
GDB related ChangeLog files.

As with the original commit, the intention behind this commit is to
hopefully stop people merging ChangeLog entries by mistake.

The renames carried out in this commit are:

    gdb/doc/ChangeLog -> gdb/doc/ChangeLog-1991-2021
    gdb/stubs/ChangeLog -> gdb/stubs/ChangeLog-2012-2020
    gdb/testsuite/ChangeLog -> gdb/testsuite/ChangeLog-2014-2021
    gdbserver/ChangeLog -> gdbserver/ChangeLog-2002-2021
    gdbsupport/ChangeLog -> gdbsupport/ChangeLog-2020-2021

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

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

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

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

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

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

Automatic date update in version.in

Automatic date update in version.in

Revert: PowerPC: Don't generate unused section symbols

Blindly following x86 broke linux kernel builds.

bfd/
* elf32-ppc.c (TARGET_KEEP_UNUSED_SECTION_SYMBOLS): Define as true.
* elf64-ppc.c (TARGET_KEEP_UNUSED_SECTION_SYMBOLS): Likewise.
gas/
* testsuite/gas/ppc/power4.d: Adjust for section sym change.
* testsuite/gas/ppc/test1elf32.d: Likewise.
* testsuite/gas/ppc/test1elf64.d: Likewise.
ld/
* testsuite/ld-powerpc/tlsexe.r: Adjust for section sym change.
* testsuite/ld-powerpc/tlsexe32.r: Likewise.
* testsuite/ld-powerpc/tlsexe32no.r: Likewise.
* testsuite/ld-powerpc/tlsexeno.r: Likewise.
* testsuite/ld-powerpc/tlsexenors.r: Likewise.
* testsuite/ld-powerpc/tlsexers.r: Likewise.
* testsuite/ld-powerpc/tlsexetoc.r: Likewise.
* testsuite/ld-powerpc/tlsexetocrs.r: Likewise.
* testsuite/ld-powerpc/tlsget.d: Likewise.
* testsuite/ld-powerpc/tlsget.wf: Likewise.
* testsuite/ld-powerpc/tlsget2.d: Likewise.
* testsuite/ld-powerpc/tlsget2.wf: Likewise.
* testsuite/ld-powerpc/tlsso.r: Likewise.
* testsuite/ld-powerpc/tlsso32.r: Likewise.
* testsuite/ld-powerpc/tlstocso.r: Likewise.

Re: ld script expression parsing

Commit 40726f16a8d7 broke references to sections within ADDR(), and
overlays with weird section names.

* ldgram.y (paren_script_name): New rule.
(exp): Use it for ALIGNOF, SIZEOF, ADDR, and LOADADDR.  Similarly
ensure script mode parsing for section name in SEGMENT_START.
(overlay_section): Delete unnecessary ldlex_script call.  Backup
on a lookahead NAME parsed in expression mode.
* testsuite/ld-elf/overlay.s: Add more sections.
* testsuite/ld-elf/overlay.t: Test '-' in section names.

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

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

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

gdb/ChangeLog:

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

* syscalls/netbsd.xml: Regenerate.

Automatic date update in version.in

gdb/testsuite: test get/set value of unregistered Guile parameter

When creating a parameter in Guile, you have to create it using
make-parameter and then register it with GDB with register-parameter!.
In between, it's still possible (though not documented) to set the
parameter's value.  I broke this use case by mistake while writing this
series, so thought it would be good to have a test for it.

I suppose that people could use this "feature" to give their parameter
an initial value, even though make-parameter has an initial-value
parameter for this.  Nevertheless, changing this behavior could break
some scripts, which is why I think it's important for it to be tested.

Change-Id: I5b2103e3cec0cfdcccf7ffb00eb05fed8626e66d

gdb: remove cmd_list_element::function::sfunc

I don't understand what the sfunc function type in
cmd_list_element::function is for.  Compared to cmd_simple_func_ftype,
it has an extra cmd_list_element parameter, giving the callback access
to the cmd_list_element for the command being invoked.  This allows
registering the same callback with many commands, and alter the behavior
using the cmd_list_element's context.

From the comment in cmd_list_element, it sounds like at some point it
was the callback function type for set and show functions, hence the
"s".  But nowadays, it's used for many more commands that need to access
the cmd_list_element object (see add_catch_command for example).

I don't really see the point of having sfunc at all, since do_sfunc is
just a trivial shim that changes the order of the arguments.  All
commands using sfunc could just as well set cmd_list_element::func to
their callback directly.

Therefore, remove the sfunc field in cmd_list_element and everything
that goes with it.  Rename cmd_const_sfunc_ftype to cmd_func_ftype and
use it for cmd_list_element::func, as well as for the add_setshow
commands.

Change-Id: I1eb96326c9b511c293c76996cea0ebc51c70fac0

gdb: rename cfunc to simple_func

After browsing the CLI code for quite a while and trying really hard, I
reached the conclusion that I can't give a meaningful explanation of
what "sfunc" and "cfunc" functions are, in cmd_list_element.  I don't
see a logic at all.  That makes it very difficult to do any kind of
change.  Unless somebody can make sense out of all that, I'd like to try
to retro-fit some logic in the cmd_list_element callback function code
so that we can understand what is going on, do some cleanups and add new
features.

The first change is about "cfunc".  I can't figure out what the "c" in
cfunc means.  It's not const, because there's already "const" in
"cmd_const_cfunc_ftype", and the previous "cmd_cfunc_ftype" had nothing
const..  It's not "cmd" or "command", because there's already "cmd" in
"cmd_const_cfunc_ftype".

The "main" command callback, cmd_list_element::func, has three
parameters, whereas cfunc has two.  It is missing the cmd_list_element
parameter.  So the only reason I see for cfunc to exist is to be a shim
between the three and two parameter versions.  Most commands don't need
to receive the cmd_list_element object, so adding it everywhere would be
long and would just add more unnecessary boilerplate.  So since this is
the "simple" version of the callback, compared to the "full", I suggest
renaming cmd_const_cfunc_ftype into cmd_simple_func_ftype, as well as
everything (like the utility functions) that goes with it.

Change-Id: I4e46cacfd77a66bc1cbf683f6a362072504b7868

gdb: make inferior::m_terminal an std::string

Same idea as the previous patch, but for m_terminal.

Change-Id: If9367d5db8c976a4336680adca4ea5bc31ab64d2

gdb: make inferior::m_cwd an std::string

Same idea as the previous patch, but for m_cwd.

To keep things consistent across the board, change get_inferior_cwd as
well, which is shared with GDBserver.  So update the related GDBserver
code too.

Change-Id: Ia2c047fda738d45f3d18bc999eb67ceb8400ce4e

gdb: make inferior::m_args an std::string

With the current code, both a NULL pointer and an empty string can mean
"no arguments".  We don't need this distinction.  Changing to a string
has the advantage that there is now a single state for that (an empty
string), which makes the code a bit simpler in my opinion.

Change-Id: Icdc622820f7869478791dbaa84b4a1c7fec21ced

gdb: add setter/getter for inferior cwd

Add cwd/set_cwd to the inferior class, remove set_inferior_args.
Keep get_inferior_args, because it is used from fork_inferior, in shared
code.  The cwd could eventually be passed as a parameter eventually,
though, I think that would be cleaner.

Change-Id: Ifb72ea865d7e6f9a491308f0d5c1595579d8427e

gdb: add setter/getter for inferior arguments

Add args/set_args to the inferior class, remove the set_inferior_args
and get_inferior_args functions, that would just be wrappers around
them.

Change-Id: If87d52f3402ce08be26c32897ae8915d9f6d1ea3

gdb: remove inferior::{argc,argv}

There are currently two states that the inferior args can be stored.
The main one is the `args` field, where they are stored as a single
string.  The other one is the `argc`/`argv` fields.

This last one is only used for arguments passed in GDB's
command line.  And the only outcome is that when get_inferior_args is
called, `argc`/`argv` are serialized into `args`.  So really,
`argc`/`argv` is just a staging area before moving the arguments in
`args`.

Simplify this by only keeping the `args` field.  Change
set_inferior_args_vector to immediately serialize the arguments into
`args`, work that would be done in get_inferior_args later anyway.

The only time where this work would be "wasted" is when the user passes
some arguments on the command line, but does not end up running the
program.  But that just seems unlikely.  And it's not that much work.

Change-Id: Ica0b9859397c095f6530350c8fb3c36905f2044a

gdb: un-share set_inferior_cwd declaration

The declaration of set_inferior_cwd is currently shared between gdb and
gdbserver, in gdbsupport/common-inferior.h.  It doesn't need to be, as
set_inferior_cwd is not called from common code.  Only get_inferior_cwd
needs to.

The motivation for this is that a future patch will change the prototype
of set_inferior_cwd in gdb, and I don't want to change it for gdbserver
unnecessarily.  I see this as a good cleanup in any case, to reduce to
just the essential what is shared between GDB and GDBserver.

Change-Id: I3127d27d078f0503ebf5ccc6fddf14f212426a73

gdb.base/setshow.exp: fix duplicate test name

Fix:

    DUPLICATE: gdb.base/setshow.exp: test_setshow_args: show args

by giving some explicit test names.

Change-Id: I2a738d3d3675ab9b45929e71f5aee0ea6bf92072

gdb.base/setshow.exp: split in procs

Split in multiple procs, one per topic, and start with a fresh GDB in
each.  I find it easier to work on a test with multiple smaller
independent test procedures.  For example, it's possible to comment all
but one when working on one.  It's also easier to add things without
having to think about the impact on existing tests, and vice-versa.

Change-Id: I19691eed8f9bcb975b2eeff7577cac66251bcbe2

gdb.base/setshow.exp: use save_vars to save/restore gdb_prompt

Using save_vars is a bit better than what we have now, as it ensures the
variable gets restored if the code within it throws an error.

Change-Id: I3bd6836e5b7efb61b078acadff1a1c8182c19a27

gdb/testsuite: split gdb.python/py-parameter.exp in procs

Split the file into multiple independent test procs, where each proc
starts with a fresh GDB.  I find it easier to understand what a test is
doing when each part of the test is isolated and self-contained.  It
makes it easier to comment out some parts of the test while working /
debugging a specific part.  It also makes it easier to add new things
(which a subsequent patch will do) without fear of impacting another part
of the test.

Change-Id: I8b4d52ac82b1492d79b679e13914ed177d8a836d

Fix for gdb.python/py-breakpoint.exp

Not all systems have hardware breakpoint support.  Add a check
to see if the system supports hardware breakpoints.

gdb/testsuite/ChangeLog

* gdb.python/py-breakpoint.exp (test_hardware_breakpoints): Add
check for hardware breakpoint support.

gdb/testsuite: don't error when trying to unset last_spawn_tty_name

In spawn_capture_tty_name (lib/gdb.exp) we either set or unset
last_spawn_tty_name depending on whether spawn_out(slave,name) exists
or not.

One situation that might cause spawn_out(slave,name) to not exists is
if the spawn function is called with the argument -leaveopen, which is
how it is called when processes are created as part of a pipeline, the
created process has no tty, instead its output is written to a file
descriptor.

If a pipeline is created consisting of multiple processes then there
will be multiple sequential calls to spawn, all using -leaveopen.  The
first of these calls is fine, spawn_out(slave,name) is not set, and so
in spawn_capture_tty_name we unset last_spawn_tty_name.  However, on
the second call to spawn, spawn_out(slave,name) is still not set and
so in spawn_capture_tty_name we again try to unset
last_spawn_tty_name, this now throws an error (as last_spawn_tty_name
is already unset).

Fix this issue by using -nocomplain with the call to unset in
spawn_capture_tty_name.

Before this commit I was seeing gdb.base/gnu-debugdata.exp report 1
pass, and 1 unsupported test.  After this commit I now see 16 passes
from this test script.

I have also improved the code that used to do this:

    if { [info exists spawn_out] } {
set ::last_spawn_tty_name $spawn_out(slave,name)
    } else {
        ...
    }

The problem here is that we check for the existence of spawn_out, and
then unconditionally read spawn_out(slave,name).  A situation could
arise where some other element of spawn_out is set,
e.g. spawn_out(foo), in which case we would enter the if block and try
to read a non-existent variable.  After this commit we now check
specifically for spawn_out(slave,name).

Finally, it is worth noting that before this issue was fixed runtest
itself, or rather the expect process behind runtest, would segfault
while exiting.  I haven't looked at all into what the problem is here
that caused expect to crash, as fixing the bug in GDB's testing
scripts made the segfault go away.

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.