Boolify need_escape in generic_emit_char

This changes 'need_escape' in generic_emit_char to be of type bool,
rather than int.

Fix latent quote char bug in generic_printstr

generic_printstr prints an empty string like:

      fputs_filtered ("\"\"", stream);

However, this seems wrong to me if the quote character is something
other than double quote.  This patch fixes this latent bug.  Thanks to
Andrew for the test case.

Co-authored-by: Andrew Burgess <aburgess@redhat.com>

Fix the guile build

The frame_info_ptr patches broke the build with Guile.  This patch
fixes the problem.  In mos cases I chose to preserve the use of
frame_info_ptr, at least where I could be sure that the object
lifetime did not interact with Guile's longjmp-based exception scheme.

Tested on x86-64 Fedora 34.

[gdb/testsuite] Detect trailing ^C/^D in command

Detect a trailing ^C/^D in the command argument of gdb_test_multiple, and
error out.

Tested on x86_64-linux.

[gdb/testsuite] Fix error message for cmd with trailing newline

I noticed that the error message in gdb_test_multiple about trailing newline
in a command does not mention the offending command, nor the word command:
...
    if [string match "*\[\r\n\]" $command] {
        error "Invalid trailing newline in \"$message\" test"
    }
...

Fix this by using instead:
...
        error "Invalid trailing newline in \"$command\" command"
...

Also add a test-case to trigger this: gdb.testsuite/gdb-test.exp.

Tested on x86_64-linux.

gdb: include the base address in in-memory bfd filenames

The struct target_buffer (in gdb_bfd.c) is used to hold information
about an in-memory BFD object created by GDB.  For now this mechanism
is used by GDB when loading information about JIT symfiles.

This commit updates target_buffer (in gdb_bfd.c) to be more C++ like,
and, at the same time, adds the base address of the symfile into the
BFD filename.

Right now, every in-memory BFD is given the filename "<in-memory>".
This filename is visible in things like 'maint info symtabs' and
'maint info line-table'.  If there are multiple in-memory BFD objects
then it can be hard to match keep track if which BFD is which.  This
commit changes the name to be "<in-memory@ADDRESS>" where ADDRESS is
replaced with the base address for where the in-memory symbol file was
read from.

As an example of how this is useful, here's the output of 'maint info
jit' showing a single loaded JIT symfile:

  (gdb) maintenance info jit
  jit_code_entry address symfile address    symfile size
  0x00000000004056b0     0x0000000007000000 17320

And here's part of the output from 'maint info symtabs':

  (gdb) maintenance info symtabs
  ...snip...
  { objfile <in-memory@0x7000000> ((struct objfile *) 0x5258250)
    { ((struct compunit_symtab *) 0x4f0afb0)
      debugformat DWARF 4
      producer GNU C17 9.3.1 20200408 (Red Hat 9.3.1-2) -mtune=generic -march=x86-64 -g -fno-stack-protector -fpic
      name jit-elf-solib.c
      dirname /tmp/binutils-gdb/build/gdb/testsuite
      blockvector ((struct blockvector *) 0x5477850)
      user ((struct compunit_symtab *) (null))
   { symtab /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/jit-elf-solib.c ((struct symtab *) 0x4f0b030)
     fullname (null)
     linetable ((struct linetable *) 0x5477880)
   }
    }
  }

I've added a new test that checks the new in-memory file names are
generated correctly, and also checks that the in-memory JIT files can
be dumped back out using 'dump binary memory'.

gdb: remove filename arg from gdb_bfd_open_from_target_memory

The filename argument to gdb_bfd_open_from_target_memory was never
used; this argument had a default value of nullptr, and the only call
to this function, in jit.c, relied on the default value.

In the next commit I'm going to make some changes to the
gdb_bfd_open_from_target_memory function, and, though I could take
account of a filename parameter, it seems pointless to maintain an
unused argument.

This commit removes the filename argument.

There should be no user visible changes after this commit.

gdb: add infcall specific debugging

Add two new commands:

  set debug infcall on|off
  show debug infcall

These enable some new debugging related to when GDB makes inferior
function calls.  I've added some basic debugging for what I think are
the major steps in the inferior function call process, but I'm sure we
might want to add more later.

gdb: extra debug output in thread.c

Add some extra 'threads' debug in a couple of places in thread.c.
I've also added an additional gdb_assert in one case.

gdb: improve infrun_debug_show_threads output

This commit switches to use INFRUN_SCOPED_DEBUG_START_END in the
infrun_debug_show_threads function, which means the output will get an
extra level of indentation, this looks a little nicer I think.

Add ability to create reproducible source tarballs.

* src-release.sh: Add "-r <date>" option to create reproducible
tarballs based upon a fixed timestamp of <date>.
* binutils/README-how-to-make-a-release: Add a line showing how to
use -r <date> when creating a binutils release.

gdb/frame: Add reinflation method for frame_info_ptr

Currently, despite having a smart pointer for frame_infos, GDB may
attempt to use an invalidated frame_info_ptr, which would cause internal
errors to happen.  One such example has been documented as PR
python/28856, that happened when printing frame arguments calls an
inferior function.

To avoid failures, the smart wrapper was changed to also cache the frame
id, so the pointer can be reinflated later.  For this to work, the
frame-id stuff had to be moved to their own .h file, which is included
by frame-info.h.

Frame_id caching is done explicitly using the prepare_reinflate method.
Caching is done manually so that only the pointers that need to be saved
will be, and reinflating has to be done manually using the reinflate
method because the get method and the -> operator must not change
the internals of the class.  Finally, attempting to reinflate when the
pointer is being invalidated causes the following assertion errors:

check_ptrace_stopped_lwp_gone: assertion `lp->stopped` failed.
get_frame_pc: Assertion `frame->next != NULL` failed.

As for performance concerns, my personal testing with `time make
chec-perf GDB_PERFTEST_MODE=run` showed an actual reduction of around
10% of time running.

This commit also adds a testcase that exercises the python/28856 bug with
7 different triggers, run, continue, step, backtrace, finish, up and down.
Some of them can seem to be testing the same thing twice, but since this
test relies on stale pointers, there is always a chance that GDB got lucky
when testing, so better to test extra.

Regression tested on x86_64, using both gcc and clang.

Approved-by: Tom Tomey <tom@tromey.com>

Change GDB to use frame_info_ptr

This changes GDB to use frame_info_ptr instead of frame_info *
The substitution was done with multiple sequential `sed` commands:

sed 's/^struct frame_info;/class frame_info_ptr;/'
sed 's/struct frame_info \*/frame_info_ptr /g' - which left some
    issues in a few files, that were manually fixed.
sed 's/\<frame_info \*/frame_info_ptr /g'
sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace
    problems.

The changed files were then manually checked and some 'sed' changes
undone, some constructors and some gets were added, according to what
made sense, and what Tromey originally did

Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
Approved-by: Tom Tomey <tom@tromey.com>

Introduce frame_info_ptr smart pointer class

This adds frame_info_ptr, a smart pointer class.  Every instance of
the class is kept on an intrusive list.  When reinit_frame_cache is
called, the list is traversed and all the pointers are invalidated.
This should help catch the typical GDB bug of keeping a frame_info
pointer alive where a frame ID was needed instead.

Co-Authored-By: Bruno Larsen <blarsen@redhat.com>
Approved-by: Tom Tomey <tom@tromey.com>

Remove frame_id_eq

This replaces frame_id_eq with operator== and operator!=.  I wrote
this for a version of this series that I later abandoned; but since it
simplifies the code, I left this patch in.

Approved-by: Tom Tomey <tom@tromey.com>

gdb/testsuite: use 'end' at the end of python blocks

Within the testsuite, use the keyword 'end' to terminate blocks of
Python code being sent to GDB, rather than sending \004.  I could only
find three instances of this, all in tests that I originally wrote.  I
have no memory of there being any special reason why I used \004
instead of 'end' - I assume I copied this from somewhere else that has
since changed.

Non of the tests being changed here are specifically about whether
\004 can be used to terminate a Python block, so I think switching to
the more standard 'end' keyword is the right choice.

gdbsupport: re-generate configure

I get this diff when re-generating configure, probably leftover from
67d1991b785 ("egrep in binutils").

Change-Id: I759c88c2bad648736d33ff98089db45c9b686356

Merge configure.ac from gcc project

To merge with gcc's copy of configure.ac we need to revert changes to
configure.ac in the following gcc commits:
dc832fb39fc0 2022-08-25
fc259b522c0f 2022-06-25
Then reapply configure.ac changes in binutils from these binutils
commits:
50ad1254d503 2021-01-09
bb368aad297f 2022-03-11
e5f2f7d901ee 2022-07-26
2cac01e3ffff 2022-09-26
Plus copy over gcc's config/ax_cxx_compile_stdcxx.m4, then regenerate
configure.

Automatic date update in version.in

Automatic date update in version.in

Merge both implementations of debug_names::insert

The class debug_names has two 'insert' overloads, but only one of them
is ever called externally, and it simply forwards to the other
implementation.  It seems cleaner to me to have a single method, so
this patch merges the two.

[gdb/testsuite] Fix silent fail in gdb.server/connect-with-no-symbol-file.exp

With native and target boards native-gdbserver, remote-gdbserver-on-localhost and
remote-stdio-gdbserver I have for gdb.server/connect-with-no-symbol-file.exp:
...
 # of expected passes            8
...
but with native-extended-gdbserver I have instead:
...
 # of expected passes            8
 # of unexpected failures        4
...

The extra FAILs are of the form:
...
(gdb) detach^M
Detaching from pid process 28985^M
[Inferior 1 (process 28985) detached]^M
(gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=: \
  action=permission: connection to GDBserver succeeded
...
and are due to the fact that the actual gdb output doesn't match the regexp:
...
    gdb_test "detach" \
       ".*Detaching from program: , process.*Ending remote debugging.*" \
       "connection to GDBserver succeeded"
...

With native, the actual gdb output is:
...
(gdb) detach^M
Detaching from pid process 29657^M
Ending remote debugging.^M
[Inferior 1 (process 29657) detached]^M
(gdb) Remote debugging from host ::1, port 51028^M
...
and because the regexp doesn't match, it triggers an implicit clause for
"Ending remote debugging" in gdb_test_multiple, which has the consequence
that the FAIL is silent.

Fix:
- the regexp by making it less strict
- the silent fail by rewriting into a gdb_test_multiple, and adding an
  explicit fail clause.

Tested on x86_64-linux, using native and aforementioned target boards.

Automatic date update in version.in

gdb/testsuite: fix gdb.threads/linux-dp.exp regex

On ubuntu 22.04 with the libc6-dbg package installed, I have the
following failure:

    where
    #0  print_philosopher (n=3, left=33 '!', right=33 '!') at .../gdb/testsuite/gdb.threads/linux-dp.c:105
    #1  0x000055555555576a in philosopher (data=0x55555555937c) at .../gdb/testsuite/gdb.threads/linux-dp.c:148
    #2  0x00007ffff7e11b43 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
    #3  0x00007ffff7ea3a00 in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
    (gdb) FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit

The regex for this test accounts for different situations (with /
without debug symbol) but assumes that if debug info is present the
backtrace shows execution under pthread_create.  However, for the
implementation under test, we are under start_thread.

Update the regex to accept start_thread.

Tested on Ubuntu-22.04 x86_64 with and without libc6-dbg debug symbols
available.

Change-Id: I1e1536279890bca2cd07f038e026b41e46af44e0

[gdb/testsuite] Handle host cleanfiles

When running test-case gdb.server/abspath.exp with host board
local-remote-host-notty, I get:
...
$ git sti
  ...
        deleted:    gdb/testsuite/gdb.xml/trivial.xml
...

This happens as follows.  The test-case calls skip_gdbserver_test, which calls
gdb_skip_xml_test, which does:
...
    set xml_file [gdb_remote_download host "${srcdir}/gdb.xml/trivial.xml"]
...

Then proc gdb_remote_download appends $xml_file (which for this particular
host board happens to be ${srcdir}/gdb.xml/trivial.xml) to cleanfiles, which
ends up being handled in gdb_finish by:
...
       eval remote_file target delete $cleanfiles
...

The problem is that a host file is deleted using target delete.

Fix this by splitting cleanfiles up in cleanfiles_target and cleanfiles_host.

Tested on x86_64-linux.

[gdb/testsuite] Remove unnecessary warning in gdb.base/default.exp

When running test-case gdb.base/default.exp with target board
native-gdbserver, we get:
...
WARNING: Skipping backtrace and break tests because of GDB stub.
...

There's no need for such a warning, so remove it.

Tested on x86_64-linux with native and target board native-gdbserver.

[gdb/testsuite] Fix have_mpx with remote-gdbserver-on-localhost

With target board remote-gdbserver-on-localhost and gdb.arch/i386-mpx-call.exp
I run into:
...
FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
...

This is due to the have_mpx test which should return 0, but instead returns 1
because the captured output:
...
No MPX support
No MPX support
...
does not match the used regexp:
...
    set status [expr ($status == 0) \
                   && ![regexp "^No MPX support\r\n" $output]]
...
which does match the captured output with native:
...
No MPX support^M
No MPX support^M
...

Fix this by making the \r in the regexp optional.

Tested on x86_64-linux, with native and target board
remote-gdbserver-on-localhost.

[gdb/testsuite] Fix DUPLICATEs with remote-gdbserver-on-localhost

Fix some DUPLICATEs that we run into with target board
remote-gdbserver-on-localhost, by using test_with_prefix.

Tested on x86_64-linux, with native and target board
remote-gdbserver-on-localhost.

[gdb/testsuite] Fix path in test name in gdb_load_shlib

When running test-case gdb.server/solib-list.exp with target board
remote-gdbserver-on-localhost, I run into:
...
(gdb) set solib-search-path $outputs/gdb.server/solib-list^M
(gdb) PASS: gdb.server/solib-list.exp: non-stop 0: \
  set solib-search-path $outputs/gdb.server/solib-list
PATH: gdb.server/solib-list.exp: non-stop 0: \
  set solib-search-path $outputs/gdb.server/solib-list
...

This is due to this code in gdb_load_shlib:
...
       gdb_test "set solib-search-path [file dirname $file]" "" ""
...

Fix this by setting an explicit test name.

Tested on x86_64-linux, with native and target boards
remote-gdbserver-on-localhost, native-gdbserver and native-extended-gdbserver.

PR29653, objcopy/strip: fuzzed small input file induces large output file

_bfd_check_format functions should not print errors or warnings if
they return NULL.  A NULL return means the particular target under
test does not match, so there isn't any reason to make a complaint
about the target.  In fact there isn't a good reason to warn even if
the target matches, except via the _bfd_per_xvec_warn mechanism; Some
other target might be a better match.

This patch tidies pe_bfd_object_p with the above in mind, and
restricts the PE optional header SectionAlignment and FileAlignment
fields somewhat.  I chose to warn on nonsense values rather than
refusing to match.  Refusing to match would be OK too.

PR 29653
* peXXigen.c (_bfd_XXi_swap_aouthdr_in): Don't emit error about
invalid NumberOfRvaAndSizes here.  Limit loop copying data
directory to IMAGE_NUMBEROF_DIRECTORY_ENTRIES.
* peicode.h (pe_bfd_object_p): Don't clear and test bfd_error
around bfd_coff_swap_aouthdr_in.  Warn on invalid SectionAlignment,
FileAlignment and NumberOfRvaAndSizes.  Don't return NULL on
invalid NumberOfRvaAndSizes.

Automatic date update in version.in

Fix indentation in riscv-tdep.c

This just fixes some indentation in riscv-tdep.c.

gdb/arm: Handle lazy FPU state preservation

Read LSPEN, ASPEN and LSPACT bits from FPCCR and use them together
with FPCAR to identify if lazy FPU state preservation is active for
the current frame.  See "Lazy context save of FP state", in B1.5.7,
also ARM AN298, supported by Cortex-M4F architecture for details on
lazy FPU register stacking.  The same conditions are valid for other
Cortex-M cores with FPU.

This patch has been verified on a STM32F4-Discovery board by:
a) writing a non-zero value (lets use 0x1122334455667788 as an
   example) to all the D-registers in the main function
b) configured the SysTick to fire
c) in the SysTick_Handler, write some other value (lets use
   0x0022446688aaccee as an example) to one of the D-registers (D0 as
   an example) and then do "SVC #0"
d) in the SVC_Handler, write some other value (lets use
   0x0099aabbccddeeff) to one of the D-registers (D0 as an example)

In GDB, suspend the execution in the SVC_Handler function and compare
the value of the D-registers for the SVC_handler frame and the
SysTick_Handler frame.  With the patch, the value of the modified
D-register (D0) should be the new value (0x009..eff) on the
SVC_Handler frame, and the intermediate value (0x002..cee) for the
SysTick_Handler frame.  Now compare the D-register value for the
SysTick_Handler frame and the main frame.  The main frame should
have the initial value (0x112..788).

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan ROUX <yvan.roux@foss.st.com>

[gdb/symtab] Factor out have_complaint

After committing 8ba677d3560 ("[gdb/symtab] Don't complain about function
decls") I noticed that quite a bit of code in read_func_scope is used to decide
whether to issue the "cannot get low and high bounds for subprogram DIE at
$hex" complaint, which executes unnecessarily if we have the default
"set complaints 0".

Fix this by (NFC):
- factoring out new static function have_complaint from macro complaint, and
- using it to wrap the relevant code in read_func_scope.

Tested on x86_64-linux.

gdb: add missing nullptr checks in bpstat_check_breakpoint_conditions

Add a couple of missing nullptr checks in the function
bpstat_check_breakpoint_conditions.

No user visible change after this commit.

gdb: more infrun debug from breakpoint.c

This commit adds additional infrun debug from the breakpoint.c file.
The new debug output all relates to breakpoint condition evaluation.

There is already some infrun debug emitted from the breakpoint.c file,
so hopefully, adding more will not be contentious.  I think the
functions being instrumented make sense as part of the infrun process,
the inferior stops, evaluates the condition, and then either stops or
continues.  This new debug gives more insight into that process.

I had to make the bp_location* argument to find_loc_num_by_location
const, and add a declaration for find_loc_num_by_location.

There should be no user visible changes unless they turn on debug
output.

gdb: add some additional debug in mark_async_event_handler

Extend the existing debug printf call to include the previous state of
the async_event_handler object.

RISC-V: Print XTheadMemPair literal as "immediate"

The operand type "Xl(...)" denotes that (...) is a literal.  Specifically,
they are intended to be a constant immediate value.

This commit prints "Xl(...)" operand with dis_style_immediate style,
not dis_style_text.

opcodes/ChangeLog:

* riscv-dis.c (print_insn_args): Use dis_style_immediate on
the constant literal of the "Xl..." operand.

RISC-V: Fix T-Head immediate types on printing

This commit fixes two minor typing-related issues for
T-Head immediate operands.

1.  A signed type must be specified when printing with %i.
2.  unsigned/signed int is not portable enough for max 32-bit immediates.
    Instead, we should use unsigned/signed long.
    The format string is changed accordingly.

opcodes/ChangeLog:

* riscv-dis.c (print_insn_args): Fix T-Head immediate types on
printing.

RISC-V: Print comma and tabs as the "text" style

On the RISC-V disassembler, some separators have non-text style when
printed with another word with another style.

This commit splits those, making sure that those comma and tabs are printed
with the "text" style.

opcodes/ChangeLog:

* riscv-dis.c (print_insn_args): Split and print the comma as
text.  (riscv_disassemble_insn): Split and print tabs as text.
(riscv_disassemble_data): Likewise.

RISC-V: Optimize riscv_disassemble_data printf

This commit makes types of printf arguments on riscv_disassemble_data
as small as possible (as long as we can preserve the portability) to reduce
the cost of printf (especially on 32-bit host).

opcodes/ChangeLog:

* riscv-dis.c (riscv_disassemble_data): Use smallest possible type
to printing data.

RISC-V: Fix printf argument types corresponding %x

"%x" format specifier requires unsigned type, not int.  This commit
fixes this issue on the RISC-V disassembler.

opcodes/ChangeLog:

* riscv-dis.c (print_insn_args): Fix printf argument types where
the format specifier is "%x".

RISC-V: Fix immediates to have "immediate" style

This commit fixes certain print calls on immediate operands to have
dis_style_immediate.

opcodes/ChangeLog:

* riscv-dis.c (print_insn_args): Fix immediates to have
"immediate" style.  (riscv_disassemble_data): Likewise.

Automatic date update in version.in

Re: bfd BLD-POTFILES.in dependencies

Removing $BLD_POTFILES from BFD-POTFILES.in was correct, but left a
hole in dependencies.
make[4]: Entering directory '/home/alan/build/gas/all/bfd/po'
make[4]: *** No rule to make target '../elf32-aarch64.c', needed by '/home/alan/src/binutils-gdb/bfd/po/bfd.pot'.  Stop.

* Makefile.am (BUILT_SOURCES): Add BUILD_CFILES.
* Makefile.in: Regenerate.

x86/gas: support quoted address scale factor in AT&T syntax

An earlier attempt (e68c3d59acd0 ["x86: better respect quotes in
parse_operands()"]) needed undoing (cc0f96357e0b ["x86: permit
parenthesized expressions again as addressing scale factor"]) as far its
effect here went. As indicated back then, the issue is the backwards
scanning of the operand string to find the matching opening parenthesis.
Switch to forward scanning, finding the last outermost unquoted opening
parenthesis (which is the one matching the trailing closing one).

Arm64: support CLEARBHB alias

While the Arm v8 ARM (rev I-a) still doesn't mention this alias, it is
(typically via a macro) already in use in kernels and alike.

PR29647, objdump -S looping

Fuzzed input with this in .debug_line
  [0x0000003b]  Special opcode 115: advance Address by 8 to 0x401180 and Line by -2 to -1

PR 29647
* objdump.c (print_line): Don't decrement line number here..
(dump_lines): ..do so here instead, ensuring loop terminates.

Re: stab nearest_line bfd_malloc_and_get_section

It didn't take long for the fuzzers to avoid size checks in
bfd_malloc_and_get_section.  Plug this hole.

* syms.c (_bfd_stab_section_find_nearest_line): Ignore fuzzed
sections with no contents.

gprofng: fix build with --enable-pgo-build=lto

gprofng/ChangeLog
2022-10-04  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29579
* libcollector/dispatcher.c: Fix the symbol version in SYMVER_ATTRIBUTE.
* libcollector/iotrace.c: Likewise.
* libcollector/linetrace.c: Likewise.
* libcollector/mmaptrace.c: Likewise.
* libcollector/synctrace.c: Likewise.

Automatic date update in version.in

Remove decode_location_spec_default

This removes decode_location_spec_default, inlining it into its sole
caller.

Regression tested on x86-64 Fedora 34.

gas: NEWS: Mention the T-Head extensions that were recently added

[gdb/symtab] Don't complain about function decls

[ Requires "[gdb/symtab] Don't complain about inlined functions" as
submitted here (
https://sourceware.org/pipermail/gdb-patches/2022-September/191762.html ). ]

With the test-case included in this patch, we get:
...
(gdb) ptype main^M
During symbol reading: cannot get low and high bounds for subprogram DIE \
  at 0xc1^M
type = int (void)^M
(gdb) FAIL: gdb.dwarf2/anon-ns-fn.exp: ptype main without complaints
...

The DIE causing the complaint is a function declaration:
...
 <2><c1>: Abbrev Number: 3 (DW_TAG_subprogram)
    <c2>   DW_AT_name        : foo
    <c8>   DW_AT_declaration : 1
...
which is referred to from the DIE representing the function definition:
...
 <1><f4>: Abbrev Number: 7 (DW_TAG_subprogram)
    <f5>   DW_AT_specification: <0xc1>
    <f9>   DW_AT_low_pc      : 0x4004c7
    <101>   DW_AT_high_pc     : 0x7
...
which does contain the low and high bounds.

Fix this by not complaining about function declarations.

Tested on x86_64-linux.

[gdb/symtab] Don't complain about inlined functions

With the test-case included in this patch, we get:
...
(gdb) ptype main^M
During symbol reading: cannot get low and high bounds for subprogram DIE \
  at 0x113^M
During symbol reading: cannot get low and high bounds for subprogram DIE \
  at 0x11f^M
type = int (void)^M
(gdb) FAIL: gdb.dwarf2/inline.exp: ptype main
...

The complaints are about foo, with DW_AT_inline == DW_INL_inlined:
...
 <1><11f>: Abbrev Number: 6 (DW_TAG_subprogram)
    <120>   DW_AT_name        : foo
    <126>   DW_AT_prototyped  : 1
    <126>   DW_AT_type        : <0x10c>
    <12a>   DW_AT_inline      : 1       (inlined)
...
and foo2, with DW_AT_inline == DW_INL_declared_inlined:
...
 <1><113>: Abbrev Number: 5 (DW_TAG_subprogram)
    <114>   DW_AT_name        : foo2
    <11a>   DW_AT_prototyped  : 1
    <11a>   DW_AT_type        : <0x10c>
    <11e>   DW_AT_inline      : 3       (declared as inline and inlined)
...

Fix this by not complaining about inlined functions.

Tested on x86_64-linux.

gdb/riscv: Partial support for instructions up to 176-bit

Because riscv_insn_length started to support instructions up to 176-bit,
we need to increase buf size to 176-bit in size.

Also, that would break an assumption in riscv_insn::decode so this commit
fixes it, noting that instructions longer than 64-bit are not fully
supported yet.

RISC-V: Fix buffer overflow on print_insn_riscv

Because riscv_insn_length started to support instructions up to 176-bit,
we need to increase packet buffer size to 176-bit in size.

include/ChangeLog:

* opcode/riscv.h (RISCV_MAX_INSN_LEN): Max instruction length for
use in buffer size.

opcodes/ChangeLog:

* riscv-dis.c (print_insn_riscv): Increase buffer size for max
176-bit length instructions.

RISC-V: Renamed INSN_CLASS for floating point in integer extensions.

Just added suffix _INX for those INSN_CLASS should be enough to represent
their fpr can be replaced by gpr.

Note that at least dejagnu version 1.5.3 is required in order to be ale to run the testsuites.

* README-maintainer-mode: Add a minimum version of dejagnu
requirement.

opcodes/riscv: style csr names as registers

While reviewing another patch I noticed that RISC-V CSR names are
given the text style, not the register style.  This patch fixes this
mistake.

[AArch64] Update FPSR/FPCR fields for FPU and SVE

I noticed some missing flags/fields from FPSR and FPCR registers in
both the FPU and SVE target descriptions.

This patch adds those and makes the SVE versions of FPSR and FPCR
use the proper flags/bitfields types.

Support objcopy changing compression to or from zstd

Commit 2cac01e3ffff lacked support for objcopy changing compression
style.  Add that support, which meant a rewrite of
bfd_compress_section_contents.  In the process I've fixed some memory
leaks.

* compress.c (bfd_is_section_compressed_info): Rename from
bfd_is_section_compressed_with_header and add ch_type param
to return compression header ch_type field.
Update all callers.
(decompress_section_contents): Remove buffer and size params.
Rewrite.  Update callers.
(bfd_init_section_compress_status): Free contents on failure.
(bfd_compress_section): Likewise.
* elf.c (_bfd_elf_make_section_from_shdr): Support objcopy
changing between any of the three compression schemes.  Report
"unable to compress/decompress" rather than "unable to
initialize compress/decompress status" on compress/decompress
failures.
* bfd-in2.h: Regenerate.

Re: compress .gnu.debuglto_.debug_* sections if requested

Enable zlib-gnu compression for .gnu.debuglto_.debug_*.  This differs
from zlib-gnu for .debug_* where the name is changed to .zdebug_*.
The name change isn't really needed.

bfd/
* elf.c (elf_fake_sections): Replace "." with ".z" in debug
section names only when name was ".d*", ie. ".debug_*".
(_bfd_elf_assign_file_positions_for_non_load): Likewise.
gas/
* write.c (compress_debug): Compress .gnu.debuglto_.debug_*
for zlib-gnu too.  Compress .gnu.linkonce.wi.*.

compress .gnu.debuglto_.debug_* sections if requested

Right now, when using LTO, the intermediate object files do contain
debug info in sections starting with .gnu.debuglto_ prefix and are
not compressed when --compress-debug-sections is used.

It's a mistake and we can save quite some disk space. The following
example comes from tramp3d when the corresponding LTO sections
are compressed with zlib:

$ bloaty tramp3d-v4-v2.o -- tramp3d-v4.o
    FILE SIZE        VM SIZE
 --------------  --------------
   +83%     +10  [ = ]       0    [Unmapped]
 -68.0%    -441  [ = ]       0    .gnu.debuglto_.debug_line
 -52.3%    -759  [ = ]       0    .gnu.debuglto_.debug_line_str
 -62.4% -3.24Ki  [ = ]       0    .gnu.debuglto_.debug_abbrev
 -64.8% -1.12Mi  [ = ]       0    .gnu.debuglto_.debug_info
 -88.8% -4.58Mi  [ = ]       0    .gnu.debuglto_.debug_str
 -27.7% -5.70Mi  [ = ]       0    TOTAL

bfd/ChangeLog:

* elf.c (_bfd_elf_make_section_from_shdr): Compress all debug
  info sections.

gas/ChangeLog:

* write.c (compress_debug): Compress also ".gnu.debuglto_.debug_"
if the compression algorithm is different from zlib-gnu.

RISC-V/gas: allow generating up to 176-bit instructions with .insn

For the time being simply utilize O_big to avoid widening other fields,
bypassing append_insn() etc.

RISC-V/gas: don't open-code insn_length()

Use the helper when it can be used.

RISC-V/gas: drop stray call to install_insn()

add_fixed_insn(), by calling move_insn(), already invokes install_insn().

RISC-V/gas: drop riscv_subsets static variable

It's fully redundant with the subset_list member of riscv_rps_as.

RISC-V: don't cast expressions' X_add_number to long in diagnostics

There's no need for such workarounds anymore now that we use C99
uniformly. This addresses several testsuite failures encountered when
(cross-)building on a 32-bit host.

ignore DWARF debug information for -gsplit-dwarf with dwarf-5

Skip dwo_id for split dwarf.

* dwarf2.c (parse_comp_unit): Skip DWO_id for DW_UT_skeleton.

Automatic date update in version.in

Fix self-move warning check for GCC 13+

GCC 13 got the self-move warning (0abb78dda084a14b3d955757c6431fff71c263f3),
but that warning is only checked for clang, resulting in:

/usr/lib/gcc-snapshot/bin/g++ -x c++    -I. -I. -I./config -DLOCALEDIR="\"/tmp/gdb-m68k-linux/share/locale\"" -DHAVE_CONFIG_H -I./../include/opcode -I./../readline/readline/.. -I./../zlib  -I../bfd -I./../bfd -I./../include -I../libdecnumber -I./../libdecnumber  -I./../gnulib/import -I../gnulib/import -I./.. -I.. -I./../libbacktrace/ -I../libbacktrace/  -DTUI=1    -I./.. -pthread  -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-variable -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-error=maybe-uninitialized -Wno-mismatched-tags -Wsuggest-override -Wimplicit-fallthrough=3 -Wduplicated-cond -Wshadow=local -Wdeprecated-copy -Wdeprecated-copy-dtor -Wredundant-move -Wmissing-declarations -Wstrict-null-sentinel -Wformat -Wformat-nonliteral -Werror -g -O2   -c -o unittests/environ-selftests.o -MT unittests/environ-selftests.o -MMD -MP -MF unittests/.deps/environ-selftests.Tpo unittests/environ-selftests.c
unittests/environ-selftests.c: In function 'void selftests::gdb_environ_tests::test_self_move()':
unittests/environ-selftests.c:228:7: error: moving 'env' of type 'gdb_environ' to itself [-Werror=self-move]
  228 |   env = std::move (env);
      |   ~~~~^~~~~~~~~~~~~~~~~
unittests/environ-selftests.c:228:7: note: remove 'std::move' call
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:1896: unittests/environ-selftests.o] Error 1
make[1]: Leaving directory '/var/lib/laminar/run/gdb-m68k-linux/3/binutils-gdb/gdb'
make: *** [Makefile:13193: all-gdb] Error 2

gdb: constify inferior::target_is_pushed

Change-Id: Ia4143b9c63cb76e2c824ba773c66f5c5cd94b2aa

[AArch64] Handle W registers as pseudo-registers instead of aliases of X registers

The aarch64 port handles W registers as aliases of X registers. This is
incorrect because X registers are 64-bit and W registers are 32-bit.

This patch teaches GDB how to handle W registers as pseudo-registers of
32-bit, the bottom half of the X registers.

Testcase included.

[AArch64] Fix pseudo-register numbering in the presence of unexpected additional registers

When using AArch64 GDB with the QEMU debugging stub (in user mode), we get
additional system registers that GDB doesn't particularly care about, so
it doesn't number those explicitly.

But given the pseudo-register numbers are above the number of real registers,
we need to setup/account for the real registers first before going ahead and
numbering the pseudo-registers.  This has to happen at the end of
aarch64_gdbarch_init, after the call to tdesc_use_registers, as that
updates the total number of real registers.

This is in preparation to supporting pointer authentication for bare metal
aarch64 (QEMU).

readelf: DO not load section headers from file offset zero

* readelf.c (get_32bit_section_headers): Return false if the
e_shoff field is zero.
(get_64bit_section_headers): Likewise.

RISC-V: Move supervisor instructions after all unprivileged ones

This location of supervisor instructions is out of place (because many other
privileged instructions are located at the tail but after the supervisor
instructions, we have many unprivileged instructions including bit
manipulation / crypto / vector instructions).

Not only that, this is harmful to implement pseudoinstructions in the latest
'P'-extension proposal (CLROV and RDOV).  This commit moves supervisor
instructions after all unprivileged instructions.

opcodes/ChangeLog:

* riscv-opc.c (riscv_opcodes): Adjust indents.  Move supervisor
instructions after all unprivileged instructions.

Improve GDB's baseclass detection with typedefs

When a class inherits from a typedef'd baseclass, GDB may be unable to
find the baseclass if the user is not using the typedef'd name, as is
tested on gdb.cp/virtbase2.exp; the reason that test case is working
under gcc is that the dwarf generated by gcc links the class to the
original definition of the baseclass, not to the typedef.  If the
inheritance is linked to the typedef, such as how clang does it,
gdb.cp/virtbase2.exp starts failing.

This can also be seen in gdb.cp/impl-this.exp, when attempting to print
D::Bint::i, and GDB not being able to find the baseclass Bint.

This happens because searching for baseclasses only uses the macro
TYPE_BASECLASS_NAME, which returns the typedef'd name. However, we can't
switch that macro to checking for typedefs, otherwise we wouldn't be
able to find the typedef'd name anymore. This is fixed by searching for
members or baseclasses by name, we check both the saved name and the
name after checking for typedefs.

This also fixes said long-standing bug in gdb.cp/impl-this.exp when the
compiler adds information about typedefs in the debuginfo.

RISC-V: Assign DWARF numbers to vector registers

This commit assigns DWARF register numbers to vector registers (v0-v31:
96..127) to implement RISC-V DWARF Specification version 1.0-rc4
(now in the frozen state):

https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0-rc4

binutils/ChangeLog:

* dwarf.c (dwarf_regnames_riscv): Assign DWARF register numbers
96..127 to vector registers v0-v31.

gas/ChangeLog:

* config/tc-riscv.c (tc_riscv_regname_to_dw2regnum): Support
vector registers.
* testsuite/gas/riscv/dw-regnums.s: Add vector registers to the
DWARF register number test.
* testsuite/gas/riscv/dw-regnums.d: Likewise.

RISC-V: Add testcase for DWARF register numbers

Although it had csr-dw-regnums.d (for CSRs), it didn't have DWARF register
number test for GPRs/FPRs.

This commit adds dw-regnums.{s,d} to test such registers.

gas/ChangeLog:

* testsuite/gas/riscv/dw-regnums.s: New DWARF register number test
for GPRs/FPRs.
* testsuite/gas/riscv/dw-regnums.d: Likewise.

Automatic date update in version.in

[gdb/testsuite] Fix waitpid testing in next-fork-other-thread.c

In next-fork-other-thread.c, there's this loop:
...
      do
        {
          ret = waitpid (pid, &stat, 0);
        } while (ret == EINTR);
...

The loop condition tests for "ret == EINTR" but waitpid signals EINTR by
returning -1 and setting errno to EINTR.

Fix this by changing the loop condition to "ret == -1 && errno == EINTR".

Tested on x86_64-linux.

gdb/testsuite: handle invalid .exp names passed in TESTS

I ran some tests like:

  $ make check-gdb TESTS="gdb.base/break.exp"

then, then I went to rerun the tests later, I managed to corrupt the
command line, like this:

  $ make check-gdb TESTS="gdb.base/breakff.exp"

the make command did exit with an error, but DejaGnu appeared to
report that every test passed!  The tail end of the output looks like
this:

  Illegal Argument "no-matching-tests-found"
  try "runtest --help" for option list
   === gdb Summary ===

  # of expected passes 115
  /tmp/build/gdb/gdb version  13.0.50.20220831-git -nw -nx -iex "set height 0" -iex "set width 0" -data-directory /tmp/build/gdb/testsuite/../data-directory

  make[3]: *** [Makefile:212: check-single] Error 1
  make[3]: Leaving directory '/tmp/build/gdb/testsuite'
  make[2]: *** [Makefile:161: check] Error 2
  make[2]: Leaving directory '/tmp/build/gdb/testsuite'
  make[1]: *** [Makefile:1916: check] Error 2
  make[1]: Leaving directory '/tmp/build/gdb'
  make: *** [Makefile:13565: check-gdb] Error 2

For a while, I didn't spot that DejaGnu had failed at all, I saw the
115 passes, and thought everything had run correctly - though I was
puzzled that make was reporting an error.

What happens is that in gdb/testsuite/Makefile, in the check-single
rule, we first run DejaGnu, then run the dg-add-core-file-count.sh
script, and finally, we use sed to extract the results from the
gdb.sum file.

In my case, with the invalid test name, DejaGnu fails, but the
following steps are still run, the final result, the 115 passes, is
then extracted from the pre-existing gdb.sum file.

If I use 'make -jN' then the 'check-parallel' rule, rather than the
'check-single' rule is used.  In this case the behaviour is slightly
different, the tail end of the output now looks like this:

  No matching tests found.

  make[4]: Leaving directory '/tmp/build/gdb/testsuite'
  find: ‘outputs’: No such file or directory
  Usage: ../../../src/gdb/testsuite/../../contrib/dg-extract-results.py [-t tool] [-l variant-list] [-L] log-or-sum-file ...

      tool           The tool (e.g. g++, libffi) for which to create a
                     new test summary file.  If not specified then output
                     is created for all tools.
      variant-list   One or more test variant names.  If the list is
                     not specified then one is constructed from all
                     variants in the files for <tool>.
      sum-file       A test summary file with the format of those
                     created by runtest from DejaGnu.
      If -L is used, merge *.log files instead of *.sum.  In this
      mode the exact order of lines may not be preserved, just different
      Running *.exp chunks should be in correct order.
  find: ‘outputs’: No such file or directory
  Usage: ../../../src/gdb/testsuite/../../contrib/dg-extract-results.py [-t tool] [-l variant-list] [-L] log-or-sum-file ...

      tool           The tool (e.g. g++, libffi) for which to create a
                     new test summary file.  If not specified then output
                     is created for all tools.
      variant-list   One or more test variant names.  If the list is
                     not specified then one is constructed from all
                     variants in the files for <tool>.
      sum-file       A test summary file with the format of those
                     created by runtest from DejaGnu.
      If -L is used, merge *.log files instead of *.sum.  In this
      mode the exact order of lines may not be preserved, just different
      Running *.exp chunks should be in correct order.
  make[3]: Leaving directory '/tmp/build/gdb/testsuite'
  make[2]: Leaving directory '/tmp/build/gdb/testsuite'
  make[1]: Leaving directory '/tmp/build/gdb'

Rather than DejaGnu failing, we now get a nice 'No matching tests
found' message, followed by some other noise.  This other noise is
first `find` failing, followed by the dg-extract-results.py script
failing.

What happens here is that, in the check-parallel rule, the outputs
directory is deleted before DejaGnu is invoked.  Then we try to run
all the tests, and finally we use find and dg-extract-results.py to
combine all the separate .sun and .log files together.  However, if
there are no tests run then the outputs/ directory is never created,
so the find command and consequently the dg-extract-results.py script,
fail.

This commit aims to fix the following issues:

 (1) For check-single and check-parallel rules, don't run any of the
 post-processing steps if DejaGnu failed to run.  This will avoid all
 the noise after the initial failure of DejaGnu,

 (2) For check-single ensure that we don't accidentally report
 previous results, this is related to the above, but is worth calling
 out as a separate point, and

 (3) For check-single, print the 'No matching tests found' message
 just like we do for a parallel test run.  This makes the parallel and
 non-parallel testing behaviour more similar, and I think is clearer
 than the current 'Illegal Argument' error message.

Points (1) and (2) will be handled by moving the post processing steps
inside an if block within the recipe.  For check-single I propose
deleting the gdb.sum and gdb.log files before running DejaGnu, this is
similar (I think) to how we delete the outputs/ directory in the
check-parallel rule.

For point (3) I plan to split the check-single rule in two, the
existing check-single will be renamed do-check-single, then a new
check-single rule will be added.  The new check-single rule can either
depend on the new do-check-single, or will ensure the 'No matching
tests found' message is printed when appropriate.

gdb/disasm: better intel flavour disassembly styling with Pygments

This commit was inspired by this stackoverflow post:

  https://stackoverflow.com/questions/73491793/why-is-there-a-%C2%B1-in-lea-rax-rip-%C2%B1-0xeb3

One of the comments helpfully links to this Python test case:

  from pygments import formatters, lexers, highlight

  def colorize_disasm(content, gdbarch):
      try:
          lexer = lexers.get_lexer_by_name("asm")
          formatter = formatters.TerminalFormatter()
          return highlight(content, lexer, formatter).rstrip().encode()
      except:
          return None

  print(colorize_disasm("lea [rip+0x211]  # COMMENT", None).decode())

Run the test case and you should see that the '+' character is
underlined, and could be confused with a combined +/- symbol.

What's happening is that Pygments is failing to parse the input text,
and the '+' is actually being marked in the error style.  The error
style is red and underlined.

It is worth noting that the assembly instruction being disassembled
here is an x86-64 instruction in the 'intel' disassembly style, rather
than the default att style.  Clearly the Pygments module expects the
att syntax by default.

If we change the test case to this:

  from pygments import formatters, lexers, highlight

  def colorize_disasm(content, gdbarch):
      try:
          lexer = lexers.get_lexer_by_name("asm")
          lexer.add_filter('raiseonerror')
          formatter = formatters.TerminalFormatter()
          return highlight(content, lexer, formatter).rstrip().encode()
      except:
          return None

  res = colorize_disasm("lea rax,[rip+0xeb3] # COMMENT", None)
  if res:
      print(res.decode())
  else:
      print("No result!")

Here I've added the call: lexer.add_filter('raiseonerror'), and I am
now checking to see if the result is None or not.  Running this and
the test now print 'No result!' - instead of styling the '+' in the
error style, we instead give up on the styling attempt.

There are two things we need to fix relating to this disassembly
text.  First, Pygments is expecting att style disassembly, not the
intel style that this example uses.  Fortunately, Pygments also
supports the intel style, all we need to do is use the 'nasm' lexer
instead of the 'asm' lexer.

However, this leads to the second problem; in our disassembler line we
have '# COMMENT'.  The "official" Intel disassembler style uses ';'
for its comment character, however, gas and libopcodes use '#' as the
comment character, as gas uses ';' for an instruction separator.

Unfortunately, Pygments expects ';' as the comment character, and
treats '#' as an error, which means, with the addition of the
'raiseonerror' filter, that any line containing a '#' comment, will
not get styled correctly.

However, as the i386 disassembler never produces a '#' character other
than for comments, we can easily "fix" Pygments parsing of the
disassembly line.  This is done by creating a filter.  This filter
looks for an Error token with the value '#', we then change this into
a comment token.  Every token after this (until the end of the line)
is also converted into a comment.

In this commit I do the following:

  1. Check the 'disassembly-flavor' setting and select between the
  'asm' and 'nasm' lexers based on the setting.  If the setting is not
  available then the 'asm' lexer is used by default,

  2. Use "add_filter('raiseonerror')" to ensure that the formatted
  output will not include any error text, which would be underlined,
  and might be confusing,

  3. If the 'nasm' lexer is selected, then add an additional filter
  that will format '#' and all other text on the line, as a comment,
  and

  4. If Pygments throws an exception, instead of returning None,
  return the original, unmodified content.  This will mean that this
  one instruction is printed without styling, but GDB will continue to
  call into the Python code to style later instructions.

I haven't included a test specifically for the above error case,
though I have manually check that the above case now styles
correctly (with no underline).  The existing style tests check that
the disassembler styling still works though, so I know I've not
generally broken things.

One final thought I have after looking at this issue is that I wonder
now if using Pygments for styling disassembly from every architecture
is actually a good idea?

Clearly, the 'asm' lexer is OK with att style x86-64, but not OK with
intel style x86-64, so who knows how well it will handle other random
architectures?

When I first added this feature I tested it against some random
RISC-V, ARM, and X86-64 (att style) code, and it seemed fine, but I
never tried to make an exhaustive check of all instructions, so its
quite possible that there are corner cases where things are styled
incorrectly.

With the above changes I think that things should be a bit better
now.  If a particular instruction doesn't parse correctly then our
Pygments based styling code will just not style that one instruction.
This is combined with the fact that many architectures are now moving
to libopcodes based styling, which is much more reliable.

So, I think it is fine to keep using Pygments as a fallback mechanism
for styling all architectures, even if we know it might not be perfect
in all cases.

gdb: improve disassembler styling when Pygments raises an exception

While working on another issue relating to GDB's use of the Python
Pygments package for disassembly styling I noticed an issue in the
case where the Pygments package raises an exception.

The intention of the current code is that, should the Pygments package
raise an exception, GDB will disable future attempts to call into the
Pygments code.  This was intended to prevent repeated errors during
disassembly if, for some reason, the Pygments code isn't working.

Since the Pygments based styling was added, GDB now supports
disassembly styling using libopcodes, but this is only available for
some architectures.  For architectures not covered by libopcodes
Pygments is still the only option.

What I observed is that, if I disable the libopcodes styling, then
setup GDB so that the Pygments based styling code will indicate an
error (by returning None), GDB does, as expected, stop using the
Pygments based styling.  However, the libopcodes based styling will
instead be used, despite this feature having been disabled.

The problem is that the disassembler output is produced into a
string_file buffer.  When we are using Pygments, this buffer is
created without styling support.  However, when Pygments fails, we
recreate the buffer with styling support.

The problem is that we should only recreate the buffer with styling
support only if libopcodes styling is enabled.  This was an oversight
in commit:

  commit 4cbe4ca5da5cd7e1e6331ce11f024bf3c07b9744
  Date:   Mon Feb 14 14:40:52 2022 +0000

      gdb: add support for disassembler styling using libopcodes

This commit:

  1. Factors out some of the condition checking logic into two new
  helper functions use_ext_lang_for_styling and
  use_libopcodes_for_styling,

  2. Reorders gdb_disassembler::m_buffer and gdb_disassembler::m_dest,
  this allows these fields to be initialised m_dest first, which means
  that the new condition checking functions can rely on m_dest being
  set, even when called from the gdb_disassembler constructor,

  3. Make use of the new condition checking functions each time
  m_buffer is initialised,

  4. Add a new test that forces the Python disassembler styling
  function to return None, this will cause GDB to disable use of
  Pygments for styling, and

  5. When we reinitialise m_buffer, and re-disassemble the
  instruction, call reset the in-comment flag.  If the instruction
  being disassembler ends in a comment then the first disassembly pass
  will have set the in-comment flag to true.  This shouldn't be a
  problem as we will only be using Pygments, and thus performing a
  re-disassembly pass, if libopcodes is disabled, so the in-comment
  flag will never be checked, even if it is set incorrectly.  However,
  I think that having the flag set correctly is a good thing, even if
  we don't check it (you never know what future uses might come up).

gdb/testsuite: extend styling test for libopcodes styling

This commit extends the gdb.base/style.exp test to cover disassembler
styling using libopcodes (where available).

The test will try to enable libopcode based styling, if this
works (because such styling is available) then some tests are run to
check that the output is styled, and that the styling can be disabled
using 'set style disassembler enabled off'.  If libopcodes styling is
not available on the current architecture then these new tests will be
skipped.

I've moved the Python Pygments module check inside the
test_disable_disassembler_styling function now, so that the test will
be run even when Python Pygments is not available, this allows the new
tests discussed above.

If the Pygments module is not available then the Pygments based tests
will be skipped just as they were before.

gdb: update now gdbarch_register_name doesn't return nullptr

After the previous few commit, gdbarch_register_name no longer returns
nullptr.  This commit audits all the calls to gdbarch_register_name
and removes any code that checks the result against nullptr.

There should be no visible change after this commit.

gdb: final cleanup of various gdbarch_register_name methods

Building on the previous commits, this commit goes through the various
gdbarch_register_name methods and removes all the remaining 'return
NULL' cases, I claim that these either couldn't be hit, or should be
returning the empty string.

In all cases the return of NULL was used if the register number being
passed to gdbarch_register_name was "invalid", i.e. negative, or
greater than the total number of declared registers.  I don't believe
either of these cases can occur, and the previous commit asserts that
this is the case.  As a result we can simplify the code by removing
these checks.  In many cases, where the register names are held in an
array, I was able to add a static assert that the array contains the
correct number of strings, after that, a direct access into the array
is fine.

I don't have any means of testing these changes.

gdb/csky: remove nullptr return from csky_pseudo_register_name

Building on the previous commits, in this commit I remove two
instances of 'return NULL' from csky_pseudo_register_name, and replace
them with a return of the empty string.

These two are particularly interesting, and worth pulling into their
own commit, because these returns of NULL appear to be depended on
within other parts of the csky code.

In csky-linux-tdep.c in the register collect/supply code, GDB checks
for the register name being nullptr in order to decide if a target
supports a particular feature or not.  I've updated the code to check
for the empty string.

I have no way of testing this change.

gdb: add asserts to gdbarch_register_name

This commit adds asserts to gdbarch_register_name that validate the
parameters, and the return value.

The interesting thing here is that gdbarch_register_name is generated
by gdbarch.py, and so, to add these asserts, I need to update the
generation script.

I've added two new arguments for Functions and Methods (as declared in
gdbarch-components.py), these arguments are 'param_checks' and
'result_checks'.  Each of these new arguments can be used to list some
expressions that are then used within gdb_assert calls in the
generated code.

The asserts that validate the API as described in the comment I added
to gdbarch_register_name a few commits back; the register number
passed in needs to be a valid cooked register number, and the result
being returned should not be nullptr.

gdb: check for duplicate register names in selftest

Building on the previous commit, this commit extends the register_name
selftest to check for duplicate register names.

If two registers in the cooked register set (real + pseudo registers)
have the same name, then this will show up as duplicate registers in
the 'info all-registers' output, but the user will only be able to
interact with one copy of the register.

In this commit I extend the selftest that I added in the previous
commit to check for duplicate register names, I didn't include this
functionality in the previous commit because one architecture needed
fixing, and I wanted to keep those fixes separate from the fixes in
the previous commit.

The problematic architecture(s) are powerpc:750 and powerpc:604.  In
both of these cases the 'dabr' register appears twice, there's a
definition of dabr in power-oea.xml which is included into both
powerpc-604.xml and powerpc-750.xml.  Both of these later two xml
files also define the dabr register.

I'm hopeful that this change shouldn't break anything, but I don't
have the ability to actually test this change, however:

On the gdbserver side, neither powerpc-604.xml nor powerpc-750.xml are
mentioned in gdbserver/configure.srv, which I think means that
gdbserver will never use these descriptions, and,

Within GDB the problematic descriptions are held in the variables
tdesc_powerpc_604 and tdesc_powerpc_750, which are only mentioned in
the variants array in rs6000-tdep.c, this is used when looking up a
description based on the architecture.

For a native Linux target however, this will not be used as
ppc_linux_nat_target::read_description exists, which calls
ppc_linux_match_description, which I don't believe can return either
of the problematic descriptions.

This leaves the other native targets, FreeBSD, AIX, etc.  These don't
appear to override the ::read_description method, so will potentially
return the problematic descriptions, but, in each case I think the
::fetch_registers and ::store_registers methods will ignore the dabr
register, which will leave the register as <unavailable>.

So, my proposed solution is to just remove the duplicate register from
each of powerpc-604.xml and powerpc-750.xml, then regenerate the
corresponding C++ source file.  With this change made, the selftest
now passes for all architectures.

gdb: add a gdbarch_register_name self test, and fix some architectures

This commit adds a self-test that checks that gdbarch_register_name
never returns nullptr for any valid register number.

Most architectures already met this requirement, there were just 6
that failed the new selftest, and are updated in this commit.

Beyond the self-tests I don't have any facilities to test that the
architectures I've adjusted still work correctly.

If you review all the various gdbarch_register_name implementations
then you will see that there are far more architectures that seem like
they might return nullptr in some situations, e.g. alpha, avr, bpf,
etc.  This commit doesn't attempt to address these cases as non of
them are hit during the selftest.  Many of these cases can never be
hit, for example, in alpha_register_name GDB checks for a register
number less than zero, this case can't happen and could be changed
into an assert.

A later commit in this series will have a general cleanup of all the
various register_name methods, and remove all references to NULL from
their code, however, as that commit will be mostly adjusting code that
is never hit, I want to keep those changes separate.

The selftest has been tested on x86-64, but I don't have access to
suitable systems to fully test any of the *-tdep.c code I've changed
in this commit.

gdb/gdbarch: add a comment to gdbarch_register_name

After the previous commit, this commit sets out to formalise the API
for gdbarch_register_name.  Not every architecture is actually in
compliance with the API I set out here, but I believe that most are.

I think architectures that don't comply with the API laid out here
will fail the gdb.base/completion.exp test.

The claims in the comment are I feel, best demonstrated with the
asserts in this code:

  const char *
  gdbarch_register_name (struct gdbarch *gdbarch, int regnr)
  {
    gdb_assert (regnr >= 0);
    gdb_assert (regnr < gdbarch_num_cooked_regs (gdbarch));

    const char *name = gdbarch->register_name (gdbarch, regnr);

    gdb_assert (name != nullptr);

    return name;
  }

Like I said, I don't believe every architecture follows these rules
right now, which is why I'm not actually adding any asserts.  Instead,
this commit adds a comment to gdbarch_register_name, this comment is
where I'd like to get to, rather than where we are right now.

Subsequent commits will fix all targets to be in compliance with this
comment, and will even add the asserts shown above to
gdbarch_register_name.

gdb/riscv: fix failure in gdb.base/completion.exp

I noticed a test failure in gdb.base/completion.exp for RISC-V on
a native Linux target, this is the failure:

  (gdb) FAIL: gdb.base/completion.exp: complete 'info registers '

The problem is caused by a mismatch in the output of 'maint print
registers' and the completion list for 'info registers'.  The 'info
registers' completion list contains less registers than
expected. Additionally, the list of registers extracted from the
'maint print registers' list was wrong too, in some cases the test was
grabbing the register number, rather than a register name,

Both of these problems have the same root cause, riscv_register_name
returns nullptr for some registers when it should return an empty
string.

The gdbarch_register_name API is not clearly documented anywhere, and
at first glance it would appear that the function can return either
nullptr, or an empty string to indicate that a register is not
available on the current target.  Indeed, there are plenty of places
in GDB where we compare the output of gdbarch_register_name to both
nullptr and '\0' in order to see if a register is supported or not,
and there are plenty of targets that return empty string in some
cases, and nullptr in others.

However, the 'info registers' completion code (reg_or_group_completer)
clearly depends on user_reg_map_regnum_to_name only returning nullptr
when the passed in regnum is greater than the maximum possible
register number (i.e. after all physical registers, pseudo-registers,
and user-registers), this means that gdbarch_register_name should not
be returning nullptr.

I did consider "fixing" user_reg_map_regnum_to_name, if
gdbarch_register_name returns nullptr, I could convert to an empty
string at this point, but that felt like a real hack, so I discarded
that plan.

The next possibility I considered was "fixing" reg_or_group_completer
to not rely on nullptr to indicate the end marker.  Or rather, I could
have reg_or_group_completer use gdbarch_num_cooked_regs, we know that
we should check at least that many register numbers.  Then, once we're
passed that limit, we keep checking until we hit a nullptr.  This
would absolutely work, and didn't actually feel that bad, but, it
still felt a little weird that gdbarch_register_name could return
nullptr OR the empty string to mean the same thing, so I wondered if
the "right" solution was to have gdbarch_register_name not return
nullptr.  With this in mind I tried an experiment:

I added a self-test that, for each architecture, calls
gdbarch_register_name for every register number up to the
gdbarch_num_cooked_regs limit, and checks that the name is not
nullptr.

Only a handful of architectures failed this test, RISC-V being one of
them.

This seems to suggest that most architectures agree that the correct
API for gdbarch_register_name is to return an empty string for
registers that are not supported on the current target, and that
returning nullptr is really a mistake.

In this commit I will update the RISC-V target so that GDB no longer
returns nullptr from riscv_register_name, instead we return the empty
string.

In subsequent commits I will add the selftest that I mention above,
and will fix the targets that fail the selftest.

With this change the gdb.base/completion.exp test now passes.

gdb/testsuite: rewrite capture_command_output proc

I noticed a test failure in gdb.base/completion.exp for RISC-V on a
native Linux target.  Upon investigation I discovered a couple of
reasons for the failure, this commit addresses one of them.  A later
commit will address the other issue.

The completion.exp test makes use of the capture_command_output proc
to collect the output of the 'maint print registers' command.  For
RISC-V this command produces a lot of output.

Currently the capture_command_output proc tries to collect the
complete command output in a single expect buffer, and what I see is
an error caused by the expect buffer becoming full.

This commit rewrites capture_command_output to make use of
gdb_test_multiple to collect the command output line at a time, in
this way we avoid overflowing the expect buffer.

The capture_command_output proc has some logic for skipping a prefix
pattern, which is passed in to the proc as an argument.  In order to
handle this correctly (only matching the prefix at the start of the
command output), I use two gdb_test_multiple calls, the first spots
and discards the echoed command and the (optional) prefix pattern, the
second gdb_test_multiple call then collects the rest of the command
output line at a time until a prompt is seen.

There is one slight oddity with the current implementation, which I
have changed in my rewrite, this does, slightly, change the behaviour
of the proc.

The current implementation uses this pattern:

  -re "[string_to_regexp ${command}]\[\r\n\]+${prefix}(.*)\[\r\n\]+$gdb_prompt $"

Now a typical command output will look like this:

  output here\r\n
  (gdb)

As the TCL regexp matching is greedy, TCL will try to match as much as
possible in one part of the pattern before moving on to the next.
Thus, when this matches against (.*)[\r\n]+, the (.*) will end up
matching against 'output here\r' and the [\r\n]+ will match '\n' only.

In short the previous implementation would leave the '\r' on the end
of the returned text, but not the final trailing '\n'.

Now clearly I could make a new version of capture_command_output that
maintained this behaviour, but I couldn't see any reason to do this.
So, my new implementation drops the final '\r\n' completely, in our
example above we now return 'output here' with no '\r'.

This change doesn't seem to affect any of the existing tests, but I
thought it was worth mentioning.

gdb/mi: new options for -data-disassemble command

Now that the disassembler has two different strategies for laying out
the opcode bytes of an instruction (see /r vs /b for the disassemble
command), I wanted to add support for this to the MI disassemble
command.

Currently the -data-disassemble command takes a single 'mode' value,
which currently has 6 different values (0 -> 5), 3 of these modes
relate to opcode display.

So, clearly I should just add an additional 3 modes to handle the new
opcode format, right?

No, I didn't think that was a great idea either.

So, I wonder, could I adjust the -data-disassemble command in a
backward compatible way, that would allow GDB to move away from using
the mode value altogether?

I think we can.

In this commit, I propose adding two new options to -data-disassemble,
these are:

  --opcodes none|bytes|display
  --source

Additionally, I will make the mode optional, and default to mode 0 if
no mode value is given.  Mode 0 is the simplest, no source code, no
opcodes disassembly mode.

The two new options are only valid for mode 0, if they are used with
any other mode then an error is thrown.

The --opcodes option can add opcodes to the result, with 'bytes' being
equivalent to 'disassemble /b' and 'display' being 'disassemble /r'.

The --source option will enable the /s style source code display, this
is equivalent to modes 4 and 5.  There is no way, using the new
command options to get the now deprecated /m style source code
display, that is mode 1 and 3.

My hope is that new users of the MI will not use the mode at all, and
instead will just use the new options to achieve the output they need.
Existing MI users can continue to use the mode, and will not need to
be updated to use the new options.

gdb/mi: some int to bool conversion

Just some simple int to bool conversion in mi_cmd_disassemble.  There
should be no user visible changes after this commit.

gdb/doc: update syntax of -data-disassemble command arguments

The argument documentation for -data-disassemble looks like this:

   -data-disassemble
      [ -s @var{start-addr} -e @var{end-addr} ]
    | [ -a @var{addr} ]
    | [ -f @var{filename} -l @var{linenum} [ -n @var{lines} ] ]
    -- @var{mode}

However, I believe, according to the 'Notation and Terminology'
section, this means that the there are 3 optional location
specification argument groups for the command, followed by a
non-optional '-- mode'.

However, this is not true, one of the location specifications must be
given, i.e. we can't choose to give NO location specification, which
is what the above implies.

I propose that we change this to instead be:

   -data-disassemble
    ( -s @var{start-addr} -e @var{end-addr}
    | -a @var{addr}
    | -f @var{filename} -l @var{linenum} [ -n @var{lines} ] )
    -- @var{mode}

By placing all the location specifications within '( ... )' we
indication that these are a group, from which one of the options,
separated by '|', must be selected.

However, the 'Notation and Terminology' section only describes two
uses for parenthesis: '( GROUP )*' and '( GROUP )+', in the first case
GROUP is repeated zero or more times, and in the second GROUP is
repeated 1 or more times.

Neither of those exactly describe what I want, which is GROUP must
appear exactly once.  I propose to extend 'Notation and Terminology'
to include '( GROUP )' which means that GROUP should appear exactly
once.

This change is important because, in a later commit, I want to add
additional optional arguments to the -data-disassemble command, and
things start to get confusing with the original syntax.

gdb: make gdb_disassembly_flag unsigned

In a later commit I want to use operator~ on a gdb_disassembly_flag
flag value.  This is currently not possible as gdb_disassembly_flag
is, by default, signed.

This commit just makes this enum unsigned.

There should be no user visible changes after this commit.

gdb: disassembler opcode display formatting

This commit changes the format of 'disassemble /r' to match GNU
objdump.  Specifically, GDB will now display the instruction bytes in
as 'objdump --wide --disassemble' does.

Here is an example for RISC-V before this patch:

  (gdb) disassemble /r 0x0001018e,0x0001019e
  Dump of assembler code from 0x1018e to 0x1019e:
     0x0001018e <call_me+66>:     03 26 84 fe     lw      a2,-24(s0)
     0x00010192 <call_me+70>:     83 25 c4 fe     lw      a1,-20(s0)
     0x00010196 <call_me+74>:     61 65   lui     a0,0x18
     0x00010198 <call_me+76>:     13 05 85 6a     addi    a0,a0,1704
     0x0001019c <call_me+80>:     f1 22   jal     0x10368 <printf>
  End of assembler dump.

And here's an example after this patch:

  (gdb) disassemble /r 0x0001018e,0x0001019e
  Dump of assembler code from 0x1018e to 0x1019e:
     0x0001018e <call_me+66>:     fe842603                lw      a2,-24(s0)
     0x00010192 <call_me+70>:     fec42583                lw      a1,-20(s0)
     0x00010196 <call_me+74>:     6561                    lui     a0,0x18
     0x00010198 <call_me+76>:     6a850513                addi    a0,a0,1704
     0x0001019c <call_me+80>:     22f1                    jal     0x10368 <printf>
  End of assembler dump.

There are two differences here.  First, the instruction bytes after
the patch are grouped based on the size of the instruction, and are
byte-swapped to little-endian order.

Second, after the patch, GDB now uses the bytes-per-line hint from
libopcodes to add whitespace padding after the opcode bytes, this
means that in most cases the instructions are nicely aligned.

It is still possible for a very long instruction to intrude into the
disassembled text space.  The next example is x86-64, before the
patch:

  (gdb) disassemble /r main
  Dump of assembler code for function main:
     0x0000000000401106 <+0>:     55      push   %rbp
     0x0000000000401107 <+1>:     48 89 e5        mov    %rsp,%rbp
     0x000000000040110a <+4>:     c7 87 d8 00 00 00 01 00 00 00   movl   $0x1,0xd8(%rdi)
     0x0000000000401114 <+14>:    b8 00 00 00 00  mov    $0x0,%eax
     0x0000000000401119 <+19>:    5d      pop    %rbp
     0x000000000040111a <+20>:    c3      ret
  End of assembler dump.

And after the patch:

  (gdb) disassemble /r main
  Dump of assembler code for function main:
     0x0000000000401106 <+0>:     55                      push   %rbp
     0x0000000000401107 <+1>:     48 89 e5                mov    %rsp,%rbp
     0x000000000040110a <+4>:     c7 87 d8 00 00 00 01 00 00 00   movl   $0x1,0xd8(%rdi)
     0x0000000000401114 <+14>:    b8 00 00 00 00          mov    $0x0,%eax
     0x0000000000401119 <+19>:    5d                      pop    %rbp
     0x000000000040111a <+20>:    c3                      ret
  End of assembler dump.

Most instructions are aligned, except for the very long instruction.
Notice too that for x86-64 libopcodes doesn't request that GDB group
the instruction bytes.  This matches the behaviour of objdump.

In case the user really wants the old behaviour, I have added a new
modifier 'disassemble /b', this displays the instruction byte at a
time.  For x86-64, which never groups instruction bytes, /b and /r are
equivalent, but for RISC-V, using /b gets the old layout back (except
that the whitespace for alignment is still present).  Consider our
original RISC-V example, this time using /b:

  (gdb) disassemble /b 0x0001018e,0x0001019e
  Dump of assembler code from 0x1018e to 0x1019e:
     0x0001018e <call_me+66>:     03 26 84 fe             lw      a2,-24(s0)
     0x00010192 <call_me+70>:     83 25 c4 fe             lw      a1,-20(s0)
     0x00010196 <call_me+74>:     61 65                   lui     a0,0x18
     0x00010198 <call_me+76>:     13 05 85 6a             addi    a0,a0,1704
     0x0001019c <call_me+80>:     f1 22                   jal     0x10368 <printf>
  End of assembler dump.

Obviously, this patch is a potentially significant change to the
behaviour or /r.  I could have added /b with the new behaviour and
left /r alone.  However, personally, I feel the new behaviour is
significantly better than the old, hence, I made /r be what I consider
the "better" behaviour.

The reason I prefer the new behaviour is that, when I use /r, I almost
always want to manually decode the instruction for some reason, and
having the bytes displayed in "instruction order" rather than memory
order, just makes this easier.

The 'record instruction-history' command also takes a /r modifier, and
has been modified in the same way as disassemble; /r gets the new
behaviour, and /b has been added to retain the old behaviour.

Finally, the MI command -data-disassemble, is unchanged in behaviour,
this command now requests the raw bytes of the instruction, which is
equivalent to the /b modifier.  This means that the MI output will
remain backward compatible.