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.

gdb/disasm: read opcodes bytes with a single read_code call

This commit reduces the number of times we call read_code when
printing the instruction opcode bytes during disassembly.

I've added a new gdb::byte_vector within the
gdb_pretty_print_disassembler class, in line with all the other
buffers that gdb_pretty_print_disassembler needs.  This byte_vector is
then resized as needed, and filled with a single read_code call for
each instruction.

There should be no user visible changes after this commit.

gdb/testsuite: new test for -data-disassemble opcodes format

Add another test for the output of MI command -data-disassemble.  The
new check validates the format of the 'opcodes' field, specifically,
this test checks that the field contains a series of bytes, separated
by a single space.

We also check that the bytes are in the correct order, that is, the
first byte is from the lowest address, and subsequent bytes are from
increasing addresses.

The motivation for this test (besides more tests being generally good)
is that I plan to make changes to how opcode bytes are displayed in
the disassembler output, and I want to ensure that I don't break any
existing MI behaviour.

There should be no user visible changes to GDB after this commit.

Automatic date update in version.in

Automatic date update in version.in

RISC-V: Relax "fmv.[sdq]" requirements

This commit relaxes requirements to "fmv.s" instructions from 'F' to ('F'
or 'Zfinx').  The same applies to "fmv.d" and "fmv.q".  Note that 'Zhinx'
extension already contains "fmv.h" instruction (as well as 'Zfh').

gas/ChangeLog:

* testsuite/gas/riscv/zfinx.s: Add "fmv.s" instruction.
* testsuite/gas/riscv/zfinx.d: Likewise.
* testsuite/gas/riscv/zdinx.s: Add "fmv.d" instruction.
* testsuite/gas/riscv/zdinx.d: Likewise.
* testsuite/gas/riscv/zqinx.d: Add "fmv.q" instruction.
* testsuite/gas/riscv/zqinx.s: Likewise.

opcodes/ChangeLog:

* riscv-opc.c (riscv_opcodes): Relax requirements to "fmv.[sdq]"
instructions to support those in 'Zfinx'/'Zdinx'/'Zqinx'.

RISC-V: Reorganize and enhance 'Zfinx' tests

This commit adds certain test cases for 'Zfinx'/'Zdinx'/'Zqinx' extensions
and reorganizes them, fixing coding style while improving coverage.
This is partially based on jiawei's 'Zhinx' testcases.

gas/ChangeLog:

* testsuite/gas/riscv/zfinx.s: Use different registers for
better encode space testing.  Make indentation consistent.
Add tests for instruction with rounding mode.  Change march
to minimum required extensions.  Remove source line.
* testsuite/gas/riscv/zfinx.d: Likewise.
* testsuite/gas/riscv/zdinx.s: Likewise.
* testsuite/gas/riscv/zdinx.d: Likewise.
* testsuite/gas/riscv/zqinx.s: Likewise.
Also use even-numbered registers to use valid register pairs.
* testsuite/gas/riscv/zqinx.d: Likewise.

Signed-off-by: Tsukasa OI <research_trasio@irq.a4lg.com>
Signed-off-by: jiawei <jiawei@iscas.ac.cn>

RISC-V: Eliminate long-casts of X_add_number in diagnostics

There is no need for casts to (signed/unsigned) long, as we can use
C99's PRId64/PRIu64 format specifiers.

RISC-V: fallout from "re-arrange opcode table for consistent alias handling"

Several new testcasee have appeared since the submission of said change,
some of which now also need adjustment.

RISC-V: fix build after "Add support for arbitrary immediate encoding formats"

Pre- and post-increment/decrement are side effects, the behavior of
which is undefined when combined with passing an address of the accessed
variable in the same function invocation. There's no need for the
increments here - simply adding 1 achieves the intended effect without
triggering compiler diagnostics (which are fatal with -Werror).

objcopy: avoid "shadowing" of remove() function name

remove() is a standard library function (declared in stdio.h), which
triggers a "shadows a global declaration" warning with some gcc versions.

RISC-V: drop stray INSN_ALIAS flags

FENCE.TSO isn't an alias. ZIP and UNZIP in the long run likely are, but
presently they aren't. This fixes disassembly of these insns with
-Mno-aliases.

RISC-V: re-arrange opcode table for consistent alias handling

For disassembly to pick up aliases in favor of underlying insns (helping
readability in the common case), the aliases need to come ahead of the
"base" insns. Slightly more code movement is needed because of insns
with the same name needing to stay next to each other.

Note that the "rorw" alias entry also has the missing INSN_ALIAS added
here.

Clone a few testcases to exercise -Mno-aliases some more, better
covering the differences between the default and that disassembly mode.

x86: correct build dependencies in opcodes/

With the command in the rule merely being "echo", i386-tbl.h won't be
rebuilt if missing, when at the same time i386-init.h is present and
up-to-date. Use a pattern rule instead to express the multiple targets
correctly (the &: rule separator is supported only by GNU make 4.3 and
newer). Note that now, for the opposite case to work (i386-tbl.h is
up-to-date but i386-init.h is missing), i386-init.h also needs
mentioning as a dependency somewhere: Add a fake dependency for
i386-opc.lo ("fake" because i386-opc.c doesn't include that header).

At the same time use $(AM_V_GEN) in the actual rule, replacing the
earlier (open-coded) "echo". And while there also drop a duplicate
dependency of i386-gen.o on i386-opc.h.

x86: improve match_template()'s diagnostics

At the example of

extractps $0, %xmm0, %xmm0
insertps $0, %xmm0, %eax

(both having respectively the same mistake of using the wrong kind of
destination register) it is easy to see that current behavior is far
from ideal: The former results in "unsupported instruction" for 32-bit
code simply because the 2nd template we have is a Cpu64 one. Instead we
should aim at emitting the "best" possible error, which will typically
be the one where we passed the largest number of checks. Generalize the
original "specific_error" approach by making it apply to the entire
matching loop, utilizing that line numbers increase as we pass further
checks.

x86/Intel: restrict suffix derivation

While in some cases deriving an AT&T-style suffix from an Intel syntax
memory operand size specifier is necessary, in many cases this is not
only pointless, but has led to the introduction of various workarounds:
Excessive use of IgnoreSize and NoRex64 as well as the ToDword and
ToQword attributes. Suppress suffix derivation when we can clearly tell
that the memory operand's size isn't going to be needed to infer the
possible need for the low byte/word opcode bit or an operand size prefix
(0x66 or REX.W).

As a result ToDword and ToQword can be dropped entirely, plus a fair
number of IgnoreSize and NoRex64 can also be got rid of. Note that
IgnoreSize needs to remain on legacy encoded SIMD insns with GPR
operand, to avoid emitting an operand size prefix in 16-bit mode. (Since
16-bit code using SIMD insns isn't well tested, clone an existing
testcase just enough to cover a few insns which are potentially
problematic but are being touched here.)

Note that while folding the VCVT{,T}S{S,D}2SI templates, VCVT{,T}SH2SI
isn't included there. This is to fulfill the request of not allowing L
and Q suffixes there, despite the inconsistency with VCVT{,T}S{S,D}2SI.

LoongArch: Update ELF e_flags handling according to specification.

  Update handling of e_flags according to the documentation
  update [1] (discussions [2][3]).

  Object file bitness is now represented in the EI_CLASS byte.
  The e_flags field is now interpreted as follows:

  e_flags[2:0]: Base ABI modifier

  - 0x1: soft-float
  - 0x2: single-precision hard-float
  - 0x3: double-precision hard-float

  e_flags[7:6]: ELF object ABI version

  - 0x0: v0
  - 0x1: v1

  [1]: https://github.com/loongson/LoongArch-Documentation/blob/main/docs/LoongArch-ELF-ABI-EN.adoc#e_flags-identifies-abi-type-and-version
  [2]: https://github.com/loongson/LoongArch-Documentation/pull/61
  [3]: https://github.com/loongson/LoongArch-Documentation/pull/47

gprofng: fix cppcheck warnings

gprofng/ChangeLog
2022-09-29  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* common/hwcdrv.c: Fix cppcheck warning.
* src/ABS.h: Likewise.
* src/CompCom.cc: Likewise.

[gdb/testsuite] Fix gdb.mi/mi-sym-info.exp on openSUSE Tumbleweed

On openSUSE Tumbleweed, I run into:
...
FAIL: gdb.mi/mi-sym-info.exp: List all functions from debug information only
...

The problem is in matching this string:
...
{name="_start",type="void (void)",description="void _start(void);"}
...
using regexp fun_re, which requires a line field:
...
set fun_re \
    "\{line=\"$decimal\",name=${qstr},type=${qstr},description=${qstr}\}"
...

Fix this by making the line field optional in fun_re.

Tested on x86_64-linux.

RISC-V: Add privileged extensions without instructions/CSRs

Currently, GNU Binutils does not support following privileged extensions:

-   'Smepmp'
-   'Svnapot'
-   'Svpbmt'

as they do not provide new CSRs or new instructions ('Smepmp' extends the
privileged architecture CSRs but does not define the CSR itself).  However,
adding them might be useful as we no longer have to "filter" ISA strings
just for toolchains (if full ISA string is given by a vendor, we can
straightly use it).

And there's a fact that supports this theory: there's already an
(unprivileged) extension which does not provide CSRs or instructions (but
only an architectural guarantee): 'Zkt' (constant timing guarantee for
certain subset of RISC-V instructions).

This simple commit simply adds three privileged extensions listed above.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Smepmp',
'Svnapot' and 'Svpbmt' extensions.

gdb: Remove unused extra_lines variable

Clang generates a warning if there is a variable that is set but not used
otherwise ("-Wunused-but-set-variable").  On the default configuration, it
causes a build failure (unless "--disable-werror" is specified).

The only extra_lines use in arrange_linetable function is removed on the
commit 558802e4d1c5dcbd0df7d2c6ef62a6deac247a2f
("gdb: change subfile::line_vector to an std::vector").  So, this variable
should be removed to prevent a build failure.

[gdb/testsuite] Add aranges to gdb.dwarf2/dw2-dir-file-name.exp

Since commit 52b920c5d20 ("[gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
for ppc64le"), the test-case fails with target board cc-with-debug-names, due
to missing .debug_aranges info.

Add the missing .debug_aranges info.

Also add a file_id option to Dwarf::assemble, to make it possible to contribute
to an already open file.

Tested on x86_64-linux.

[gdb/c++] Print destructor the same for gcc and clang

Consider the test-case contained in this patch.

With g++ (7.5.0) we have for "ptype A":
...
type = class A {
  public:
    int a;

    A(void);
    ~A();
}
...
and with clang++ (13.0.1):
...
type = class A {
  public:
    int a;

    A(void);
    ~A(void);
}
...
and we observe that the destructor is printed differently.

There's a difference in debug info between the two cases: in the clang case,
there's one artificial parameter, but in the g++ case, there are two, and
these similar cases are handled differently in cp_type_print_method_args.

This is due to this slightly convoluted bit of code:
...
  i = staticp ? 0 : 1;
  if (nargs > i)
    {
      while (i < nargs)
        ...
    }
  else if (varargs)
    gdb_printf (stream, "...");
  else if (language == language_cplus)
    gdb_printf (stream, "void");
...

The purpose of "i = staticp ? 0 : 1" is to skip the printing of the implicit
this parameter.

In commit 5f4d1085085 ("c++/8218: Destructors w/arguments"), skipping of other
artificial parameters was added, but using a different method: rather than
adjusting the potential loop start, it skips the parameter in the loop.

The observed difference in printing is explained by whether we enter the loop:
- in the clang case, the loop is not entered and we print "void".
- in the gcc case, the loop is entered, and nothing is printed.

Fix this by rewriting the code to:
- always enter the loop
- handle whether arguments need printing in the loop
- keep track of how many arguments are printed, and
  use that after the loop to print void etc.
such that we have the same for both gcc and clang:
...
    A(void);
    ~A(void);
...

Note that I consider the discussion of whether we want to print:
- A(void) / ~A(void), or
- A() / ~A()
out-of-scope for this patch.

Tested on x86_64-linux.

PR29626, Segfault when disassembling ARM code

PR 29626
* arm-dis.c (mapping_symbol_for_insn): Return false on zero
symtab_size.  Delete later symtab_size test.

Automatic date update in version.in

gdb: make target_auxv_parse static and rename

It is only used in auxv.c.  Also, given it is not strictly a wrapper
around target_ops::auxv (since 27a48a9223d0 "Add auxv parsing to the
architecture vector."), I think that the name prefixed with target is a
bit misleading.  Rename to just parse_auxv.

Change-Id: I41cca055b92c8ede37c258ba6583746a07d8f77e

gdb: make fprint_target_auxv static

It's only used in auxv.c.

Change-Id: I4992d9aae37b6631a074ab99bbab2f619725b642

gdb: constify auxv parse functions

Constify the input parameters of the various auxv parse functions, they
don't need to modify the raw auxv data.

Change-Id: I13eacd5ab8e925ec2b5c1f7722cbab39c41516ec

gdb: constify target_stack::is_pushed

The target_ops parameters here can be made const.

Change-Id: Ibc18b17d6b21d06145251a03e68aca90538117d6

Constify target_desc declarations

This patch changes various global target_desc declarations to const, thereby
correcting a prominent source of ODR violations in PowerPC-related target code.
The majority of files/changes are mechanical const-ifications accomplished by
regenerating the C files in features/.

This also required manually updating mips-linux-tdep.h,  s390-linux-tdep.h,
nios2-tdep.h, s390-tdep.h, arch/ppc-linux-tdesc.h, arch/ppc-linux-common.c,
and rs6000-tdep.c.

Patch tested against the sourceware trybot, and fully regression tested against
our (Red Hat's) internal  test infrastructure on Rawhide aarch64, s390x, x86_64,
and powerpcle.

With this patch, I can finally enable LTO in our GDB package builds. [Tested
with a rawhide scratch build containing this patch.]

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

cleanup: Add missing feature/ XML files to Makefile

This patch adds some missing .xml files to features/Makefile so that when the
directory's C files are regenerated, all files are appropriately remade.

This has demonstrated that there have been several "misses" in regenerating
files in this directory. Namely, arm-secext.c and sparc{32,64}-solaris.c. For
the former case, there was what essentially amounts to a typo regarding the
create feature function's name. In the later case, this file has missed at least
one important update in July, 2020, when allocate_target_description was
changed to return a unique pointer.

Those corrections are included.

Add -B to the help output from gprof, and add suitable documentation.

PR 29627
* gprof.c (usage): Add -B.
* gprof.texi (synopsis): Add -B.
(Output Options): Add entry for -B.

Automatic date update in version.in

Fix GDB build: ELF support check & -lzstd

GDB fails to build for me, on Ubuntu 20.04.  I get:

 ...
   CXXLD  gdb
 /usr/bin/ld: linux-tdep.o: in function `linux_corefile_thread(thread_info*, linux_corefile_thread_data*)':
 /home/pedro/gdb/binutils-gdb/src/gdb/linux-tdep.c:1831: undefined reference to `gcore_elf_build_thread_register_notes(gdbarch*, thread_info*, gdb_signal, bfd*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, int*)'
 /usr/bin/ld: linux-tdep.o: in function `linux_make_corefile_notes(gdbarch*, bfd*, int*)':
 /home/pedro/gdb/binutils-gdb/src/gdb/linux-tdep.c:2117: undefined reference to `gcore_elf_make_tdesc_note(bfd*, std::unique_ptr<char, gdb::xfree_deleter<char> >*, int*)'
 collect2: error: ld returned 1 exit status
 make[2]: *** [Makefile:2149: gdb] Error 1
 make[2]: Leaving directory '/home/pedro/gdb/binutils-gdb/build/gdb'
 make[1]: *** [Makefile:11847: all-gdb] Error 2
 make[1]: Leaving directory '/home/pedro/gdb/binutils-gdb/build'
 make: *** [Makefile:1004: all] Error 2

Those undefined functions exist in gdb/gcore-elf.c, which is only
included in the build if GDB's configure thinks that the target you're
configuring for is an ELF target.  GDB's configure thinks my system
isn't ELF, which is incorrect.

For the ELF support check, gdb/config.log shows:

 configure:17387: checking for ELF support in BFD
 configure:17407: gcc -o conftest -I/home/pedro/gdb/binutils-gdb/src/gdb/../include -I../bfd -I/home/pedro/gdb/binutils-gdb/src/gdb/../bfd -g3 -O0      -L../bfd -L../libiberty  -lzstd   conftest.c -lbfd -liberty -lz  -lncursesw -lm -ldl  >&5
 /usr/bin/ld: ../bfd/libbfd.a(compress.o): in function `decompress_contents':
 /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:42: undefined reference to `ZSTD_decompress'
 /usr/bin/ld: /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:44: undefined reference to `ZSTD_isError'
 /usr/bin/ld: ../bfd/libbfd.a(compress.o): in function `bfd_compress_section_contents':
 /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:195: undefined reference to `ZSTD_compress'
 /usr/bin/ld: /home/pedro/gdb/binutils-gdb/src/bfd/compress.c:198: undefined reference to `ZSTD_isError'
 collect2: error: ld returned 1 exit status
 configure:17407: $? = 1
 ...
 configure:17417: result: no

Note how above, in the gcc command line, "-lzstd" appears before
"-lbfd".  That explain the link failure.  It should appear after, like
-lz does.

This commit fixes it, by moving ZSTD_LIBS from LDFLAGS to LIBS, next
to -lz, in GDB_AC_CHECK_BFD, and regenerating gdb/configure.

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

gdb: remove trailing spaces in README

Change-Id: Ic7f8e415acd1bff6194cf08ed646bff45571f165

Treat Character as a discrete type in Ada

A user noticed that gdb would assert when printing a certain array
with array-indexes enabled.  This turned out to be caused by the array
having an index type of Character, which is completely valid in Ada.
This patch changes the Ada support to recognize Character as a
discrete type, and adds some tests.

Because this is Ada-specific and was also reviewed internally, I am
checking it in.

The help document of size misses an option.

PR 29628
* size.c (usage): Add -f.
* doc/binutils.texi (size): Add -f.

ld/testsuite: force warnings when dealing with execstack tests

Binutils can be configured to avoid printing the execstack or RWD
segment warnings. In this case, the first test of PR ld/29072 will fail.
Fix that by always manually forcing the warnings for it.

ld/ChangeLog:

* testsuite/ld-elf/elf.exp (PR ld/29072): Force execstack and
RWD segment warnings.

Re: egrep in binutils

Multi-line patterns for grep are not supported on some old versions
of grep.

binutils/
* embedspu.sh: Replace multi-line grep with sed.
ld/
* testsuite/ld-elfvers/vers.exp: Replace multi-line grep with sed.

Renenerate {gdb,gdbserver}/configure

Pick up config/lib-ld.m4 changes from:

 commit 67d1991b785bdfef1d70cddfa0202b99b43ccce9
 Author:     Alan Modra <amodra@gmail.com>
 AuthorDate: Wed Sep 28 13:37:31 2022 +0930
 Commit:     Alan Modra <amodra@gmail.com>
 CommitDate: Wed Sep 28 13:37:31 2022 +0930

     egrep in binutils

Change-Id: Ifc84d30f1fca015e80bafa80f9a35616b0077220

The help document of as misses some many options

PR 29623
* as.c (show_usage): Document the --dump-config,
--gdwarf-cie-version, --hash-size, --multibyte-handling,
and --reduce-memory-overheads options.
* config/tc-i386.c (md_show_usage): Document the -O option.
* doc/as.texi: Document the --dump-config, --emulation,
--hash-size, and --reduce-memory-overheads options.

egrep in binutils

Apparently some distros have a nagging egrep that helpfully tells you
egrep is deprecated and to use "grep -E".  The nag message causes a ld
testsuite failure.  What's more the advice isn't that good.  The "-E"
flag may not be available with older versions of grep.

This patch fixes bare invocation of egrep within binutils, replacing
it with the autoconf $EGREP or with grep.

config/
* lib-ld.m4 (AC_LIB_PROG_LD_GNU): Require AC_PROG_EGREP and
invoke $EGREP.
(AC_LIB_PROG_LD): Likewise.
binutils/
* configure: Regenerate.
* embedspu.sh: Replace egrep with grep.
gold/
* testsuite/Makefile.am (flagstest_compress_debug_sections.check):
Replace egrep with grep.
* testsuite/Makefile.in: Regenerate.
* testsuite/bnd_ifunc_1.sh: Replace egrep with $EGREP.
* testsuite/bnd_ifunc_2.sh: Likewise.
* testsuite/bnd_plt_1.sh: Likewise.
* testsuite/discard_locals_test.sh: Likewise.
* testsuite/gnu_property_test.sh: Likewise.
* testsuite/no_version_test.sh: Likewise.
* testsuite/pr18689.sh: Likewise.
* testsuite/pr26936.sh: Likewise.
* testsuite/retain.sh: Likewise.
* testsuite/split_i386.sh: Likewise.
* testsuite/split_s390.sh: Likewise.
* testsuite/split_x32.sh: Likewise.
* testsuite/split_x86_64.sh: Likewise.
* testsuite/ver_test_pr16504.sh: Likewise.
intl/
* configure: Regenerate.
ld/
* testsuite/ld-elfvers/vers.exp (test_ar): Replace egrep with grep.

regen bfd/configure

asan: _bfd_stab_section_find_nearest_line segv

The segv was on "info->strs[strsize - 1] = 0;" with strsize zero.  OK,
if strsize is zero we don't have any filenames in stabs so no useful
info.

* syms.c (_bfd_stab_section_find_nearest_line): Exit if either
stabsize or strsize is zero.

asan: segv in _bfd_archive_close_and_cleanup

Uninitialised arelt_data->parent_cache led to this segv.

* pdb.c (pdb_get_elt_at_index): Clear arelt_data.

Automatic date update in version.in

sim: Link ZSTD_LIBS

This fixes linker errors in a `../../configure --enable-targets
--enable-sim; make all-gdb` build.

gold: Suppress "unused" variable warning on Clang

Clang generates a warning if there is a variable that is set but not used
otherwise ("-Wunused-but-set-variable").  On the default configuration, it
causes a build failure (unless "--disable-werror" is specified).

Because the cause of this error is in the Bison-generated code
($(srcdir)/gold/yyscript.y -> $(builddir)/gold/yyscript.c),
this commit suppresses this warning ("-Wunused-but-set-variable") by placing
DIAGNOSTIC_IGNORE_UNUSED_BUT_SET_VARIABLE macro at the end of user
prologue on yyscript.y.

* yyscript.y: Suppress -Wunused-but-set-variable warning on
the Bison-generated code.

libctf: Add ZSTD_LIBS to LIBS so that ac_cv_libctf_bfd_elf can be true

binutils, gdb: support zstd compressed debug sections

PR29397 PR29563: Add new configure option --with-zstd which defaults to
auto.  If pkgconfig/libzstd.pc is found, define HAVE_ZSTD and support
zstd compressed debug sections for most tools.

* bfd: for addr2line, objdump --dwarf, gdb, etc
* gas: support --compress-debug-sections=zstd
* ld: support ELFCOMPRESS_ZSTD input and --compress-debug-sections=zstd
* objcopy: support ELFCOMPRESS_ZSTD input for
  --decompress-debug-sections and --compress-debug-sections=zstd
* gdb: support ELFCOMPRESS_ZSTD input.  The bfd change references zstd
  symbols, so gdb has to link against -lzstd in this patch.

If zstd is not supported, ELFCOMPRESS_ZSTD input triggers an error.  We
can avoid HAVE_ZSTD if binutils-gdb imports zstd/ like zlib/, but this
is too heavyweight, so don't do it for now.

```
% ld/ld-new a.o
ld/ld-new: a.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support
...

% ld/ld-new a.o --compress-debug-sections=zstd
ld/ld-new: --compress-debug-sections=zstd: ld is not built with zstd support

% binutils/objcopy --compress-debug-sections=zstd a.o b.o
binutils/objcopy: --compress-debug-sections=zstd: binutils is not built with zstd support

% binutils/objcopy b.o --decompress-debug-sections
binutils/objcopy: zstd.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support
...
```

PR29617, ld segfaults when bfd_close fails

PR 29617
* ldmain.c (main): Don't access output_bfd after bfd_close.

Automatic date update in version.in

gdb/testsuite: update field names in gdb-gdb.py.in

Patches that renamed the type::length and type::target_type fields
didn't update gdb-gdb.py.in accordingly, do that.

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

gdb/testsuite: use gdb_test in gdb.gdb/python-helper.exp

If some command in there gives the wrong answer, we currently have to
wait for a timeout for the test to continue.  For instance, I currently
see:

    print *val->type
    $1 = Python Exception <class 'gdb.error'>: Cannot take address of method length.

    (outer-gdb) FAIL: gdb.gdb/python-helper.exp: pretty print type (timeout)

We can avoid this and modernize the test at the same time by using the
-prompt option of gdb_test.

gdb_test_no_output currently accepts a -prompt_re option (the variable
name passed to parse_args defines the option name), but I think
it's a typo.  It's supposed to be -prompt, like gdb_test.  I can't find
anything using -prompt_re using grep.  Change it to just "prompt".

Change-Id: Icc0a9a0ef482e62460c708bccdd544c11d711eca

gdb/testsuite: bump duration for the whole test in do_self_tests

When running gdb.gdb/python-helper.exp, I get some timeouts:

    continue
    Continuing.
    print 1

    FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb (timeout)

At this time, GDB is actually processing the stop and reading in some
CUs.  selftest_setup does bump the timeout, but it's not for the whole
test.

Since debugging GDB with GDB is (unfortunately) a bit slow, bump the
timeout for the whole duration of the setup and body.  On my optimized
build, the command takes just a bit more than the current timeout of 10
seconds.  But it's much slower if running the test on an unoptimized
build, so I think it's necessary to bump the timeout for that in any
case.

Change-Id: I4d38285870e76c94f9d0bfdb60648a2e7f2cfa5d

binutils/testsuite: handle the different install names of c++filt

c++filt is always named cxxfilt in a build directory, but in a install
directory it would be named either cxxfilt or c++filt (depending on
the host).  Handle this last case in testsuite.

binutils/ChangeLog:
        *  testsuite/config/default.exp (CXXFILE): if cxxfilt not found,
        try c++filt.

binutils/testsuite: skip gentestdlls related tests if missing

When launching the testsuite through runtest outside the build tree,
gentestdlls might not be available, this binary being created by make
check.
Simply untested the related tests instead of crashing.

binutils/ChangeLog:

* testsuite/binutils-all/objdump.exp: Skip dotnet tests if
gentestdlls is not available.

[gdb/testsuite] Fix gdb.dwarf2/dw2-unspecified-type-foo.c with -m32

When running test-case gdb.dwarf2/dw2-unspecified-type-foo.c with target board
unix/-m32, I run into:
...
(gdb) PASS: gdb.dwarf2/dw2-unspecified-type.exp: ptype foo
p ((int (*) ()) foo) ()^M
$1 = -135698472^M
...

Add the missing "return 0" in foo, which fixes this.

Tested on x86_64-linux.

PR29613, use of uninitialized value in objcopy

PR 29613
* elf.c (_bfd_elf_write_secondary_reloc_section): Trim sh_size
back to relocs written.  Use better types for vars.

PR29542, PowerPC gold internal error in get_output_view,

We were attempting to set a BSS style section contents.

PR 29542
* powerpc.cc (Output_data_plt_powerpc::do_write): Don't set .plt,
.iplt or .lplt section contents when position independent.

stab nearest_line bfd_malloc_and_get_section

bfd_malloc_and_get_section performs some sanity checks on the section
size before allocating memory.  This patch avails the stab
nearest_line code of that sanity checking, and tidies up memory
afterward.

* coffgen.c (_bfd_coff_close_and_cleanup): Call _bfd_stab_cleanup.
* elf.c (_bfd_elf_close_and_cleanup): Likewise.
* syms.c (_bfd_stab_section_find_nearest_line): Set *pinfo earlier.
Use bfd_malloc_and_get_section.  Free malloc'd buffers on failure.
Malloc indextable.
(_bfd_stab_cleanup): New function.
* libbfd-in.h (_bfd_stab_cleanup): Declare.
* libbfd.h: Regnerate.

PKG_CHECK_MODULES for msgpack and jansson

Using AS_IF rather than shell "if" is recommended for conditionals
that contain non-trivial autoconf macros, because autoconf will emit
any AC_REQUIREd autoconf macro expansions outside of the conditional.
This makes them available elsewhere in the configure script.

binutils/
* configure.ac (msgpack): Use "AS_IF" rather than "if".
* configure: Regenerate.
ld/
* configure.ac (jansson): Use "AS_IF" rather than "if".
* configure: Regenerate.

Automatic date update in version.in

Automatic date update in version.in

gdb/source.c: Fix undefined behaviour dereferencing empty string

When a source file's dirname is solely made up of directory separators
we end up trying to dereference the last character of an empty string
with std::string::back, which results in undefined behaviour. A typical
use case where this can happen is when the root directory "/" is used as
a compilation directory.

With libstdc++.so.6.0.28 we get no out-of-bounds checks and the byte
preceding the storage of the empty string is returned. The character
value of this byte depends on heap implementation and usage, but when
this byte happens to hold the value of the directory separator character
we go on to call std::string::pop_back on the empty string which results
in an out_of_range exception which terminates GDB.

Fix this by using path_join. prepare_path_for_appending ensures that the
filename component is relative.

The testsuite has been run before and after the change and no
regressions were found.

gdbserver: remove unused for loop

In this commit,

  commit cf6c1e710ee162a5adb0ae47acb731f2bfecc956
  Date:   Mon Jul 11 20:53:48 2022 +0800

    gdbserver: remove unused variable

I removed an unused variable in handle_v_run.  Pedro then pointed out
that the for loop after it was also unused.  After a period of smoke
testing, no exceptions were found.

Tested on x86_64-linux.

The problem with warning in elf_object_p

elfcode.h can emit three warnings in elf_object_p for various things,
"section extending past end of file", "corrupt string table index",
and "program header with invalid alignment".  The problem with doing
this is that the warning can be emitted for multiple possible targets
as each one is tried.  I was looking at a fuzzer testcase that had an
object file with 6144 program headers, 5316 of which had invalid
alignment.  It would be bad enough to get 5316 messages all the same,
but this object was contained in an archive and resulted in 4975776
repeats.

Some trimming can be done by not warning if the bfd is already marked
read_only, as is done for the "section extending past end of file"
warning, but that still results in an unacceptable number of
warnings for object files in archives.  Besides that, it is just wrong
to warn about a problem detected by a target elf_object_p other than
the one that actually matches.  At some point we might have more
target specific warnings.

So what to do?  One obvious solution is to remove the warnings.
Another is to poke any warning strings into the target xvec, emitting
them if that xvec is the final one chosen.  This also has the benefit
of solving the archive problem.  A warning when recursing into
_bfd_check_format for the first element of the archive (to find the
correct target for the archive) will still be on the xvec at the point
that target is chosen for the archive.  However, target xvecs are
read-only.  Thus the need for per_xvec_warn to logically extend
bfd_target with a writable field.  I've made per_xvec_warn one larger
than bfd_target_vector to provide one place for user code that makes
private copies of target xvecs.

* elfcode.h (elf_swap_shdr_in, elf_object_p): Stash potential
warnings in _bfd_per_xvec_warn location.
* format.c (clear_warnmsg): New function.
(bfd_check_format_matches): Call clear_warnmsg before trying
a new xvec.  Print warnings for the successful non-archive
match.
* targets.c: Include libiberty.h.
(_bfd_target_vector_entries): Use ARRAY_SIZE.
(per_xvec_warn): New.
(_bfd_per_xvec_warn): New function.
* Makefile.am (LIBBFD_H_FILES): Add targets.c.
* Makefile.in: Regenerate.
* libbfd.h: Regenerate.

Re: bfd_cleanup for object_p

Bits still missing from commit cb001c0d283d.

* aoutx.h (aout_@var{size}_some_aout_object_p): Correct synopsis.
* i386lynx.c (lynx_core_file_p): Correct return type.
* ptrace-core.c (ptrace_unix_core_file_p): Likewise.

Automatic date update in version.in

Support AT_USRSTACKBASE and AT_USRSTACKLIM.

FreeBSD's kernel has recently added two new ELF auxiliary vector
entries to describe the location of the user stack for the initial
thread in a process.

This change displays the proper name and description of these entries
in 'info auxv'.

RISC-V: Add Zawrs ISA extension support

This patch adds support for the Zawrs ISA extension
("wrs.nto" and "wrs.sto" instructions).

The specification can be found here:
https://github.com/riscv/riscv-zawrs/blob/main/zawrs.adoc

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

gdb/testsuite/tui: start GDB with "set filename-display basename"

The test gdb.tui/tui-missing-src.exp fails on my CI machine, and I
concluded that it is caused by the long source directory name:

  /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb

The long name causes some particular redrawing that doesn't happen for
shorter directories, and causes a Term::command call to return too
early.

This can be reproduced by cloning the binutils-gdb repo in a directory
with a name similar to the one shown above.

    $ pwd
    /home/simark/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd64/target_board/unix/src/binutils-gdb/build/gdb
    $ make check-read1 TESTS="gdb.tui/tui-missing-src.exp"
    FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 ()
    FAIL: gdb.tui/tui-missing-src.exp: f2.c must be displayed in source window
    FAIL: gdb.tui/tui-missing-src.exp: check source box is empty after return
    FAIL: gdb.tui/tui-missing-src.exp: Back in main

Note that using "make check" instead of "make check-read1" only shows
the last 2 failures for me.

When running gdb.tui/tui-missing-src.exp in a directory with a shorter
name, the terminal looks like this by the time the "checking if inside
f2" test runs:

    Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 23):
        0 +-...ld/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-missing-src/f2.c-+
        1 |        1                                                                     |
        2 |        2  int                                                                |
        3 |        3  f2 (int x)                                                         |
        4 |        4  {                                                                  |
        5 |  >     5    x <<= 1;                                                         |
        6 |        6    return x+5;                                                      |
        7 |        7  }                                                                  |
        8 |        8                                                                     |
        9 |        9                                                                     |
       10 |       10                                                                     |
       11 |       11                                                                     |
       12 |       12                                                                     |
       13 |       13                                                                     |
       14 +------------------------------------------------------------------------------+
       15 multi-thre Thread 0x7ffff7cc07 In: f2                  L5    PC: 0x555555555143
       16     at /home/simark/build/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-
       17 missing-src/main.c:6
       18 (gdb) next
       19 (gdb) step
       20 f2 (x=4)
       21     at /home/simark/build/binutils-gdb-noasan/gdb/testsuite/outputs/gdb.tui/tui-
       22 missing-src/f2.c:5
       23 (gdb)
    PASS: gdb.tui/tui-missing-src.exp: checking if inside f2 ()

When running the `Term::command "step"` just before, GDB writes the
"step", which makes the `wait_for` proc go in the "looking for the
prompt" mode, to know when the command's execution is complete.  As some
new output appears, lines that must disappear are deleted using the
"Delete Line" operation [1] and some new ones are drawn.  The source
window gets redrawn with the contents of the f2.c file.  Then, GDB
writes the prompt (at line 23 above), which satisfies `wait_for`, which
then returns.  The state of the terminal is therefore correct for the
"check if inside f2" and "f2.c must be displayed in the source window"
tests.

In the non-working case, the terminal looks like this by the time the
"check if inside f2" test runs:

     Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 17):
        0 +------------------------------------------------------------------------------+
        1 |                                                                              |
        2 |                                                                              |
        3 |                                                                              |
        4 |                                                                              |
        5 |                                                                              |
        6 |                                                                              |
        7 |               [ No Source Available ]                                        |
        8 |                                                                              |
        9 |                                                                              |
       10 |                                                                              |
       11 |                                                                              |
       12 |                                                                              |
       13 |                                                                              |
       14 +------------------------------------------------------------------------------+
       15 multi-thre Thread 0x7ffff7cc1b In: main                L7    PC: 0x555555555128
       16 sing-src/main.c:6
       17 (gdb) ary breakpoint 1, main ()
       18     at /home/simark/workspace/binutils-gdb_master_linuxbuild/platform/jammy-amd6
       19 4/target_board/unix/src/binutils-gdb/build/gdb/testsuite/outputs/gdb.tui/tui-mis
       20 sing-src/main.c:6
       21 (gdb) next
       22 (gdb) step
       23
    FAIL: gdb.tui/tui-missing-src.exp: checking if inside f2 ()

What happened is: GDB wrote the "step" command, which make the
`wait_for` proc go in its "looking for the prompt" mode.  However,
curses decided to redraw whatever scrolled up to line 17 using some
standard character insertion operations:

    +++ Cursor Down (1), cursor: (16, 0) -> (17, 0)
    +++ Inserting string '('
    +++   Inserted char '(', cursor: (17, 0) -> (17, 1)
    +++ Inserted string '(', cursor: (17, 0) -> (17, 1)
    +++ Inserting string 'g'
    +++   Inserted char 'g', cursor: (17, 1) -> (17, 2)
    +++ Inserted string 'g', cursor: (17, 1) -> (17, 2)
    +++ Inserting string 'd'
    +++   Inserted char 'd', cursor: (17, 2) -> (17, 3)
    +++ Inserted string 'd', cursor: (17, 2) -> (17, 3)
    +++ Inserting string 'b'
    +++   Inserted char 'b', cursor: (17, 3) -> (17, 4)
    +++ Inserted string 'b', cursor: (17, 3) -> (17, 4)
    +++ Inserting string ')'
    +++   Inserted char ')', cursor: (17, 4) -> (17, 5)
    +++ Inserted string ')', cursor: (17, 4) -> (17, 5)
    +++ Inserting string ' '
    +++   Inserted char ' ', cursor: (17, 5) -> (17, 6)
    +++ Inserted string ' ', cursor: (17, 5) -> (17, 6)

And that causes `wait_for` to think the "step" command is complete.
This is wrong, as the prompt at line 17 isn't the prompt drawn after the
completion of the "step" command.  The subsequent tests now run with a
partially updated screen (what is shown above) and obviously fail.

The ideal way to fix this would be for `wait_for` to be smarter, to
avoid it confusing the different prompts drawn.

However, I would also like to reduce the variations in TUI test results
due to the directories (source and build) in which tests are ran.  TUI
tests are more prone to differences in test results due to variations in
directory names than other tests, as it makes curses take different
redrawing decisions.  So in this patch, I propose to make TUI tests use
"set filename-display basename", which makes GDB omit directory names
when it prints file names.  This way, regardless of where you run the
tests, you should get the same results (all other things being equal).

Doing this happens to fix my failures and makes my CI happy (which in
turns makes me happy).  To be clear, I understand that this does not fix
the root issue of `proc wait_for` being confused.  However, it makes TUI
test runs be more similar for everyone, such that there's less chance of
TUI tests randomly failing for somebody.  If some other change triggers
the `wait_for` problem again in the future, hopefully everybody will see
the problem and we can work on getting it fixed more easily than if just
one unlucky person sees the problem.

Note that there are other reasons why TUI tests could vary, like
different curses library versions taking different re-drawing decisions.
However, I think my change is a good step towards more stable test
results.

[1] https://vt100.net/docs/vt510-rm/DL.html

Change-Id: Ib18da83317e7b78a46f77892af0d2e39bd261bf5

gdb/csky add cskyv2-linux.xml for cskyv2-linux.c

Add cskyv2-linux.xml for re-generating cskyv2-linux.c if needed.
Also update cskyv2-linux.c.

pdb: _bfd_generic_close_and_cleanup

Every format that might appear inside a generic archive needs to call
_bfd_generic_close_and_cleanup, so that the archive element lookup
htab can be tidied on closing an element.  Otherwise you get stale
entries in the htab pointing at freed and perhaps reused memory,
resulting in segfaults when the archive is closed.

Calling _bfd_generic_close_and_cleanup on close means tdata needs to
be set up too, since pdb claims to be of format bfd_archive.

* pdb.c (pdb_close_and_cleanup): Define as
_bfd_generic_close_and_cleanup.
(pdb_archive_p): Set up tdata for bfd_archive format.

Don't attempt to compress bss sections

It doesn't make sense to try to compress a section without contents
since those sections take no space on disk.  Compression can only
increase the disk image size.

* coffgen.c (make_a_section_from_file): Exclude !SEC_HAS_CONTENTS
sections from compression and decompression.
* elf.c (_bfd_elf_make_section_from_shdr): Likewise.

Automatic date update in version.in

gdb/testsuite/lib/future.exp: follow dejagnu default_target_compile

GDB's testsuite can override dejagnu's default_target_compile if the
system provided dejagnu installation does not provide support to compile
languages GDB needs.

Recent version of dejagnu (1.6.3, installed on RHEL-9) includes ba60272
"Establish a default C compiler by evaluating [find_gcc] if no other
compiler is given."[1].  This commit removed calls such as
`set_board_info compiler  "[find_gcc]"` from the various baseboards
and has default_target_compile call `find_gcc` itself to find a compiler
if none was specified by the board description.

On systems with dejagnu-1.6.3, if GDB's overrides is needed to support
languages still unknown to dejagnu, we end up in the following
situation:
  - The system board files do not set the C compiler anymore,
  - GDB's replacement for default_target_compile assumes that the
    compiler should have been set up by the board file.

In this situation, no one sets the C compiler for the board and as a
result many test are not compiled and not executed:

    [...]
    Running .../gdb/testsuite/gdb.base/bt-on-error-and-warning.exp ...
    gdb compile failed, default_target_compile: No compiler to compile with
    Running .../gdb/testsuite/gdb.base/dprintf-non-stop.exp ...
    gdb compile failed, default_target_compile: No compiler to compile with
    Running .../gdb/testsuite/gdb.base/structs3.exp ...
    gdb compile failed, default_target_compile: No compiler to compile with
    [...]

We are observing this error with ROCgdb[2], a downstream port of GDB
supporting AMD GPUs.  This port needs to use GDB's override of
default_target_compile to compile HIP programs since dejagnu does not
provide support for this language yet.

This patch changes gdb_default_target_compile_1 in a similar way
default_target_compile has been updated so both implementations remain
compatible.  Even if this is not strictly required by GDB just yet,
I believe keeping both implementations in sync desirable.

Using board files provided with dejagnu <=1.6.2 is still supported: if
the compiler is set by the board file, gdb_default_target_compile_1 uses
it and does not need `find_gcc`.

Patch tested on x86_64 RHEL-9 and ubuntu-20.04 on top of GDB and ROCgdb.

[1] http://git.savannah.gnu.org/gitweb/?p=dejagnu.git;a=commit;h=ba60272a5ac6f6a7012acca03f596a6ed003f044
[2] https://github.com/ROCm-Developer-Tools/ROCgdb

Change-Id: Ibff52684d9cab8243a7c6748ecbd29f50c37e669

RISC-V: Add T-Head MemPair vendor extension

T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.

This patch adds the XTheadMemPair extension, a collection of T-Head specific
two-GP-register memory operations.
The 'th' prefix and the "XTheadMemPair" extension are documented in a PR
for the RISC-V toolchain conventions ([1]).

[1] https://github.com/riscv-non-isa/riscv-toolchain-conventions/pull/19

Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add support for literal instruction arguments

This patch introduces support for arbitrary literal instruction
arguments, that are not encoded in the opcode.

A typical use case for this feature would be an instruction that
applies an implicit shift by a constant value on an immediate
(that is a real operand). With this patch it is possible to make
this shift visible in the dissasembly and support such artificial
parameter as part of the asssembly code.

Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>