x86: limit data passed to i386_dis_printf()

The function doesn't use "ins" for other than retrieving "info". Remove
a thus pointless level of indirection.

x86: limit data passed to prefix_name()

Make apparent that neither what "ins" points to nor, in particular, that
"ins->info->private_data" is actually used in the function.

x86/Intel: reduce ELF/PE conditional scope in x86_cons()

All the Intel syntax related state adjustments apply independent of
target or object format.

gas: move shift count check

... out of mainline code, grouping together the two case labels. This
then also make more obvious that the comment there applies to both forms
of shifts.

x86: rework AMX control insn disassembly

Consistently do 64-bit first, VEX.L second, VEX.W third, ModR/M fourth,
and only then prefix, resulting in fewer table entries. Note that in the
course of the re-work
- TILEZERO has a previously missing decode step through rm_table[]
  added,
- a wrong M_0 suffix for TILEZERO is also corrected to be M_1 (now an
  infix).

x86: rework AMX multiplication insn disassembly

Consistently do 64-bit first, ModR/M second, VEX.L third, VEX.W fourth,
and prefix last, resulting in fewer table entries. Note that in the
course of the re-work wrong M_0 suffixes are also corrected to be M_1
(partly infixes now).

Since it ended up confusing while testing the change, also adjust the
test name in x86-64-amx-bad.d (to be distinct from x86-64-amx.d's).

Re: Keeping track of rs6000-coff archive element pointers

Commit de7b90610e9e left a hole in the element checking, explained by
the comment added to _bfd_xcoff_openr_next_archived_file.  While
fixing this, tidy some types used to hold unsigned values so that
casts are not needed to avoid signed/unsigned comparison warnings.
Also tidy a few things in xcoff.h.

bfd/
* coff-rs6000.c (_bfd_xcoff_openr_next_archived_file): Check
that we aren't pointing back at the last element.  Make
filestart a ufile_ptr.  Update for xcoff_artdata change.
(_bfd_strntol, _bfd_strntoll): Return unsigned values.
(_bfd_xcoff_slurp_armap): Make off a ufile_ptr.
(add_ranges): Update for xcoff_artdata change.
* libbfd-in.h (struct artdata): Make first_file_filepos a
ufile_ptr.
* libbfd.h: Regenerate.
include/
* coff/xcoff.h (struct xcoff_artdata): Replace min_elt with
ar_hdr_size.
(xcoff_big_format_p): In the !SMALL_ARCHIVE case return true
for anything but a small archive.

Remove deprecated bfd_read

20+ years is long enough to warn.

* bfd-in.h (bfd_read, bfd_write): Don't define
(_bfd_warn_deprecated): Don't declare.
* bfd-in2.h: Regenerate.
* libbfd.c (_bfd_warn_deprecated): Delete.

Make bfd_byte an int8_t, flagword a uint32_t

* bfd-in.h (bfd_byte): Typedef as int8_t.
(flagword): Typedef as uint32_t.
(bfd_vma, bfd_signed_vma, bfd_size_type, symvalue): Use stdint
types in !BFD64 case.
* bfd-in2.h: Regenerate.

Automatic date update in version.in

gas: bpf: fix tests for pseudo-c syntax

This patch fixes the GAS BPF testsuite so the tests for pseudo-c
syntax are actually executed.

2023-04-27  Jose E. Marchesi  <jose.marchesi@oracle.com>

* testsuite/gas/bpf/mem.dump: New file.
* testsuite/gas/bpf/mem-pseudoc.d: Likewise.
* testsuite/gas/bpf/mem.d: #dump mem.dump.
* testsuite/gas/bpf/lddw.dump: New file.
* testsuite/gas/bpf/lddw-pseudoc.d: Likewise.
* testsuite/gas/bpf/lddw.d: #dump lddw.dump.
* testsuite/gas/bpf/jump.dump: New file.
* testsuite/gas/bpf/jump-pseudoc.d: Likewise
* testsuite/gas/bpf/jump.d: #dump jump.dump.
* testsuite/gas/bpf/jump32.dump: New file.
* testsuite/gas/bpf/jump32-pseudoc.d: Likewise.
* testsuite/gas/bpf/jump32.d: #dump jump32.dump.
* testsuite/gas/bpf/lddw-be.dump: New file.
* testsuite/gas/bpf/lddw-be-pseudoc.d: Likewise.
* testsuite/gas/bpf/lddw-be.d: #dump lddw-be.dump.
* testsuite/gas/bpf/indcall-1.dump: New file.
* testsuite/gas/bpf/indcall-1-pseudoc.d: Likewise.
* testsuite/gas/bpf/indcall-1.d: #dump indcall-1.dump.
* testsuite/gas/bpf/indcall-1-pseudoc.s (main): Fix lddw
instruction.
* testsuite/gas/bpf/atomic.dump: New file.
* testsuite/gas/bpf/atomic-pseudoc.d: Likewise.
* testsuite/gas/bpf/atomic.d: #dump atomic.dump.
* testsuite/gas/bpf/alu32.dump: New file.
* testsuite/gas/bpf/alu32-pseudoc.d: Likewise.
* testsuite/gas/bpf/alu32.d: #dump alu32.dump.
* testsuite/gas/bpf/alu.dump: New file.
* testsuite/gas/bpf/alu-pseudoc.d: Likewise.
* testsuite/gas/bpf/alu.d: #dump alu.dump.

* testsuite/gas/bpf/alu-be.dump: New file.
* testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
* testsuite/gas/bpf/alu-be.d: #dump alu-be.dump.
* testsuite/gas/bpf/alu32-be-pseudoc.d: New file.
* testsuite/gas/bpf/alu32-be-dump: Likewise.
* testsuite/gas/bpf/alu32-be.d: #dump alu32-be-dump.
* testsuite/gas/bpf/bpf.exp: Run *-pseudoc tests.

Avoid some compiler warnings in gdb.ada

Running gdb.ada/verylong.exp shows a warning from the Ada compiler:

prog.adb:16:11: warning: file name does not match unit name, should be "main.adb" [enabled by default]

This patch fixes the problem, and another similar one in
unchecked_union.exp.

Fix PR30358, performance with --sort-section

since af31506c we only use the binary tree when section sorting is
required.  While its unbalanced and hence can degrade to a linear list
it should otherwise have been equivalent to the old code relying on
insertion sort.  Unfortunately it was not.  The old code directly used
lang_add_section to populate the sorted list, the new code first
populates the tree and only then does lang_add_section on the sorted
result.

In the testcase we have very many linkonce section groups, and hence
lang_add_section won't actually insert anything for most of them.  That
limited the to-be-sorted list length previously.  The tree-sorting code
OTOH first created a tree of all candidates sections, including those
that wouldn't be inserted by lang_add_section, hence increasing the size
of the sorting problem.  In the testcase the chain length went from
about 1500 to 106000, and in the degenerated case (as in the testcase)
that goes in quadratically.

This splits out most of the early-out code from lang_add_section to its
own function and uses the latter to avoid inserting into the tree.  This
refactoring slightly changes the order of early-out tests (the ones
based on section flags is now done last, and only in lang_add_section).
The new function is not a pure predicate: it can give warnings and it
might change output_section, like the old early-out code did.  I have
also added a skip-warning case in the first discard case, whose
non-existence seemed to have been an oversight.

PR 30358
* ldlang.c (wont_add_section_p): Split out from ...
(lang_add_section): ... here.
(output_section_callback_sort): Use wont_add_section_p to not
always add sections to the sort tree.

gdb/doc: extend the documentation of the jump command

This commit addresses PR gdb/7946.  While checking for bugs relating
to the jump command I noticed a long standing bug that points out a
deficiency with GDB's documentation of the jump command.

The bug points out that 'jump 0x...' is not always the same as 'set
$pc = 0x...' and then 'continue'.  Writing directly to the $pc
register does not update any auxiliary state, e.g. $npc on SPARC,
while using 'jump' does.

It felt like this would be an easy issue to address by adding a
paragraph to the docs, so I took a stab at writing something suitable.

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

Approved-By: Eli Zaretskii <eliz@gnu.org>

gdb/testsuite: special case '^' in gdb_test pattern

In this commit I propose that we add special handling for the '^' when
used at the start of a gdb_test pattern.  Consider this usage:

  gdb_test "some_command" "^command output pattern"

I think the intention here is pretty clear - run 'some_command', and
the output from the command should be exactly 'command output
pattern'.

After the previous commit which tightened up how gdb_test matches the
final newline and prompt we know that the only thing after the output
pattern will be a single newline and prompt, and the leading '^'
ensures that there's no output before 'command output pattern', so
this will do what I want, right?

... except it doesn't.  The command itself will also needs to be
matched, so I should really write:

  gdb_test "some_command" "^some_command\r\ncommand output pattern"

which will do what I want, right?  Well, that's fine until I change
the command and include some regexp character, then I have to write:

  gdb_test "some_command" \
    "^[string_to_regexp some_command]\r\ncommand output pattern"

but this all gets a bit verbose, so in most cases I simply don't
bother anchoring the output with a '^', and a quick scan of the
testsuite would indicate that most other folk don't both either.

What I propose is this: the *only* thing that can appear immediately
after the '^' is the command converted into a regexp, so lets do that
automatically, moving the work into gdb_test.  Thus, when I write:

  gdb_test "some_command" "^command output pattern"

Inside gdb_test we will spot the leading '^' in the pattern, and
inject the regexp version of the command after the '^', followed by a
'\r\n'.

My hope is that given this new ability, folk will be more inclined to
anchor their output patterns when this makes sense to do so.  This
should increase our ability to catch any unexpected output from GDB
that appears as a result of running a particular command.

There is one problem case we need to consider, sometime people do
this:

  gdb_test "" "^expected output pattern"

In this case no command is sent to GDB, but we are still expecting
some output from GDB.  This might be a result of some asynchronous
event for example.  As there is no command sent to GDB (from the
gdb_test) there will be no command text to parse.

In this case my proposed new feature injects the command regexp, which
is the empty string (as the command itself is empty), but still
injects the '\r\n' after the command regexp, thus we end up with this
pattern:

  ^\r\nexpected output pattern

This extra '\r\n' is not what we should expected here, and so there is
a special case inside gdb_test -- if the command is empty then don't
add anything after the '^' character.

There are a bunch of tests that do already use '^' followed by the
command, and these can all be simplified in this commit.

I've tried to run all the tests that I can to check this commit, but I
am certain that there will be some tests that I manage to miss.
Apologies for any regressions this commit causes, hopefully fixing the
regressions will not be too hard.

Reviewed-By: Tom Tromey <tom@tromey.com>

gdb/testsuite: change newline patterns used in gdb_test

This commit makes two changes to how we match newline characters in
the gdb_test proc.

First, for the newline pattern between the command output and the
prompt, I propose changing from '[\r\n]+' to an explicit '\r\n'.

The old pattern would spot multiple newlines, and so there are a few
places where, as part of this commit, I've needed to add an extra
trailing '\r\n' to the pattern in the main test file, where GDB's
output actually includes a blank line.

But I think this is a good thing.  If a command produces a blank line
then we should be checking for it, the current gdb_test doesn't do
that.  But also, with the current gdb_test, if a blank line suddenly
appears in the output, this is going to be silently ignored, and I
think this is wrong, the test should fail in that case.

Additionally, the existing pattern will happily match a partial
newline.  There are a strangely large number of tests that end with a
random '.' character.  Not matching a literal period, but matching any
single character, this is then matching half of the trailing newline
sequence, while the \[\r\n\]+ in gdb_test is matching the other half
of the sequence.  I can think of no reason why this would be
intentional, I suspect that the expected output at one time included a
period, which has since been remove, but I haven't bothered to check
on this.  In this commit I've removed all these unneeded trailing '.'
characters.

The basic rule of gdb_test after this is that the expected pattern
needs to match everything up to, but not including the newline
sequence immediately before the GDB prompt.  This is generally how the
proc is used anyway, so in almost all cases, this commit represents no
significant change.

Second, while I was cleaning up newline matching in gdb_test, I've
also removed the '[\r\n]*' that was added to the start of the pattern
passed to gdb_test_multiple.

The addition of this pattern adds no value.  If the user pattern
matches at the start of a line then this would match against the
newline sequence.  But, due to the '*', if the user pattern doesn't
match at the start of a line then this group doesn't care, it'll
happily match nothing.

As such, there's no value to it, it just adds more complexity for no
gain, so I'm removing it.  No tests will need updating as a
consequence of this part of the patch.

Reviewed-By: Tom Tromey <tom@tromey.com>

gdb/testsuite: use 'return' in gdb_test_no_output

A TCL proc will return the return value of the last command executed
within the proc's body if there is no explicit return call, so
gdb_test_no_output is already returning the return value of
gdb_test_multiple.

However, I'm not a fan of (relying on) this implicit return value
behaviour -- I prefer to be explicit about what we are doing.  So in
this commit I have extended the comment on gdb_test_no_output to
document the possible return values (just as gdb_test does), and
explicitly call return.

This should make no different to our testing, but I think it's clearer
now what the gdb_test_no_output proc is expected to do.

The two tests gdb.base/auxv.exp and gdb.base/list.exp both rely on the
return value of gdb_test_no_output, and continue to pass after this
change.

I also spotted that gdb.base/watchpoint.exp could be updated to make
use of gdb_test_no_output, so I did that.

Reviewed-By: Tom Tromey <tom@tromey.com>

gdb: remove some trailing newlines from warning messages

While working on a later patch in this series, which tightens up some
of our pattern matching when using gdb_test, I ran into some failures
caused by some warnings having a trailing newline character.

The warning function already adds a trailing newline, and it is my
understanding that we should not be adding a second by including a
newline at the end of any warning message.

The problem cases I found were in language.c and remote.c, in this
patch I fix the cases I hit, but I also checked all the other warning
calls in these two files and removed any additional trailing newlines
I found.

In remote.c the warning actually had a newline character in the middle
of the warning message (in addition to the trailing newline), which
I've removed.  I don't think it's helpful to forcibly split a warning
as was done here -- in the middle of a sentence.  Additionally, the
message isn't even that long (71 characters), so I think removing this
newline is an improvement.

None of the expected test result need updating with this commit,
currently the patterns in gdb_test will match one or more newline
sequences, so the tests are as happy with one newline (after this
commit) as they are with two newlines (before this commit).  A later
commit will change gdb_test so that it is not so forgiving, and these
warnings would have caused some failures.

Reviewed-By: Tom Tromey <tom@tromey.com>

gdb/testsuite: fix occasional failure in gdb.base/clear_non_user_bp.exp

I noticed that the gdb.base/clear_non_user_bp.exp test would sometimes
fail when run from a particular directory.

The test tries to find the number of the first internal breakpoint
using this proc:

  proc get_first_maint_bp_num { } {
      gdb_test_multiple "maint info break" "find first internal bp num" {
   -re -wrap "(-\[0-9\]).*" {
       return $expect_out(1,string)
   }
      }
      return ""
  }

The problem is, at the time we issue 'maint info break' there are both
internal breakpoint and non-internal (user created) breakpoints in
place.  The user created breakpoints include the path to the source
file.

Sometimes, I'll be working from a directory that includes a number,
like '/tmp/blah-1/gdb/etc', in which case the pattern above actually
matches the '-1' from 'blah-1'.  In this case there's no significant
problem as it turns out that -1 is the number of the first internal
breakpoint.

Sometimes my directory name might be '/tmp/blah-4/gdb/etc', in which
case the above pattern patches '-4' from 'blah-4'.  It turns out this
is also not a problem -- the test doesn't actually need the first
internal breakpoint number, it just needs the number of any internal
breakpoint.

But sometimes my directory name might be '/tmp/blah-0/gdb/etc', in
which case the pattern above matches '-0' from 'blah-0', and in this
case the test fails - there is no internal breakpoint '-0'.

Fix this by spotting that the internal breakpoint numbers always
occurs after a '\r\n', and that they never start with a 0.  Our
pattern becomes:

   -re -wrap "\r\n(-\[1-9\]\[0-9\]*).*" {
       return $expect_out(1,string)
   }

After this I'm no longer seeing any failures.

Reviewed-By: Tom Tromey <tom@tromey.com>

gdb, doc: add index entry for the $_inferior_thread_count convenience var

Add a marker in the documentation for indexing the $_inferior_thread_count
variable.

Approved-By: Eli Zaretskii <eliz@gnu.org>

Add support for %x and %lx formats to the linker's vinfo() function.

Automatic date update in version.in

RISC-V: Support XVentanaCondOps extension

    Ventana Micro has published the specification for their
    XVentanaCondOps ("conditional ops") extension at
      https://github.com/ventanamicro/ventana-custom-extensions/releases/download/v1.0.0/ventana-custom-extensions-v1.0.0.pdf
    which contains two new instructions
      - vt.maskc
      - vt.maskcn
    that can be used in constructing branchless sequences for
    various conditional-arithmetic, conditional-logical, and
    conditional-select operations.

    To support such vendor-defined instructions in the mainline binutils,
    this change also adds a riscv_supported_vendor_x_ext secondary
    dispatch table (but also keeps the behaviour of allowing any unknow
    X-extension to be specified in addition to the known ones from this
    table).

    As discussed, this change already includes the planned/agreed future
    requirements for X-extensions (which are likely to be captured in the
    riscv-toolchain-conventions repository):
      - a public specification document is available (see above) and is
        referenced from the gas-documentation
      - the naming follows chapter 27 of the RISC-V ISA specification
      - instructions are prefixed by a vendor-prefix (vt for Ventana)
        to ensure that they neither conflict with future standard
        extensions nor clash with other vendors

    bfd/ChangeLog:

            * elfxx-riscv.c (riscv_get_default_ext_version): Add riscv_supported_vendor_x_ext.
            (riscv_multi_subset_supports): Recognize INSN_CLASS_XVENTANACONDOPS.

    gas/ChangeLog:

            * doc/c-riscv.texi: Add section to list custom extensions and
              their documentation URLs.
            * testsuite/gas/riscv/x-ventana-condops.d: New test.
            * testsuite/gas/riscv/x-ventana-condops.s: New test.

    include/ChangeLog:

            * opcode/riscv-opc.h Add vt.maskc and vt.maskcn.
            * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_XVENTANACONDOPS.

    opcodes/ChangeLog:

            * riscv-opc.c: Add vt.maskc and vt.maskcn.

    Series-version: 1
Series-to: binutils@sourceware.org
    Series-cc: Kito Cheng <kito.cheng@sifive.com>
    Series-cc: Nelson Chu <nelson.chu@sifive.com>
    Series-cc: Greg Favor <gfavor@ventanamicro.com>
    Series-cc: Christoph Muellner <cmuellner@gcc.gnu.org>

gas: documentation for the BPF pseudo-c asm syntax

This patch expands the GAS manual in order to specify the alternate
pseudo-C assembly syntax used in BPF, and now supported by the
assembler.

gas/ChangeLog:

2023-04-19  Jose E. Marchesi  <jose.marchesi@oracle.com>

PR gas/29757
* doc/c-bpf.texi (BPF Pseudo-C Syntax): New section.

gas: BPF pseudo-c syntax tests

This patch expands the GAS BPF testsuite in order to also test the
alternative pseudo-C syntax used in BPF assembly.

This includes three main changes:

- Some general GAS tests involving assignment and equality operands in
  expressions (such as = and ==) are disabled in bpf-* targets,
  because the syntax collides with the pseudo-C BPF assembly syntax.

- New tests are added to the BPF GAS testsuite that test the pseudo-c
syntax.  Tests for all BPF instructions are included.

- New tests are added to the BPF GAS testsuite that test the support
  for both syntaxes in the same source.

gas/ChangeLog:

2023-04-20  Guillermo E. Martinez  <guillermo.e.martinez@oracle.com>

PR gas/29728
* testsuite/gas/all/assign-bad-recursive.d: Skip test in bpf-*
targets.
* testsuite/gas/all/eqv-dot.d: Likewise.
* testsuite/gas/all/gas.exp: Skip other assignment tests in bpf-*.
* testsuite/gas/bpf/alu-pseudoc.s: New file.
* testsuite/gas/bpf/pseudoc-normal.s: Likewise.
* testsuite/gas/bpf/pseudoc-normal.d: Likewise.
* testsuite/gas/bpf/pseudoc-normal-be.d: Likewise.
* testsuite/gas/bpf/mem-pseudoc.s: Likewise.
* testsuite/gas/bpf/lddw-pseudoc.s: Likewise.
* testsuite/gas/bpf/jump32-pseudoc.s: Likewise.
* testsuite/gas/bpf/jump-pseudoc.s: Likewise.
* testsuite/gas/bpf/indcall-1-pseudoc.s: Likewise.
* testsuite/gas/bpf/atomic-pseudoc.s: Likewise.
* testsuite/gas/bpf/alu32-pseudoc.s: Likewise.
* testsuite/gas/bpf/*.d: Add -pseudoc variants of the tests.

gas: support for the BPF pseudo-c assembly syntax

This patch adds support to the GNU assembler for an alternative
assembly syntax used in BPF.  This syntax is C-like and very
unconventional for an assembly language, but it is generated by
clang/llvm and is also used in inline asm templates in kernel code, so
we ought to support it.

After this patch, the assembler is able to parse instructions in both
supported syntax: the normal assembly-like syntax and the pseudo-C
syntax.  Instruction formats can be mixed in the source program: the
assembler recognizes the right syntax to use.

gas/ChangeLog:

2023-04-20  Guillermo E. Martinez  <guillermo.e.martinez@oracle.com>

PR gas/29728
* config/tc-bpf.h (TC_EQUAL_IN_INSN): Define.
* config/tc-bpf.c (LEX_IS_SYMBOL_COMPONENT): Define.
(LEX_IS_WHITESPACE): Likewise.
(LEX_IS_NEWLINE): Likewise.
(LEX_IS_ARITHM_OP): Likewise.
(LEX_IS_STAR): Likewise.
(LEX_IS_CLSE_BR): Likewise.
(LEX_IS_OPEN_BR): Likewise.
(LEX_IS_EQUAL): Likewise.
(LEX_IS_EXCLA): Likewise.
(ST_EOI): Likewise.
(MAX_TOKEN_SZ): Likewise.
(init_pseudoc_lex): New function.
(md_begin): Call init_pseudoc_lex.
(valid_expr): New function.
(build_bpf_non_generic_load): Likewise.
(build_bpf_atomic_insn): Likewise.
(build_bpf_jmp_insn): Likewise.
(build_bpf_arithm_insn): Likewise.
(build_bpf_endianness): Likewise.
(build_bpf_load_store_insn): Likewise.
(look_for_reserved_word): Likewise.
(is_register): Likewise.
(is_cast): Likewise.
(get_token): Likewise.
(bpf_pseudoc_to_normal_syntax): Likewise.
(md_assemble): Try pseudo-C syntax if an instruction cannot be
parsed.

sim: bpf: update to new BPF relocations

This patch updates the BPF GNU sim testsuite in order to match the new
BPF relocations introduced in binutils in a recent patch [1].

[1] https://sourceware.org/pipermail/binutils/2023-March/126429.html

[gdb/tui] Fix length of status line string

In commit 5d10a2041eb ("gdb: add string_file::release method") this was added:
...
+  std::string string_val = string.release ();
...
without updating subsequent uses of string.size (), which returns 0 after the
string.release () call.

Fix this by:
- using string_val.size () instead of string.size (), and
- adding an assert that would have caught this regression.

Tested on x86_64-linux.

Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
PR tui/30389
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30389

Rewrite gdb_mpz::operator==

Simon pointed out that the recent changes to gdb_mpz caused a build
failure on amd64 macOS.  It turns out to be somewhat difficult to
overload a method in a way that will work "naturally" for all integer
types; especially in a case like gdb_mpz::operator==, where it's
desirable to special case all integer types that are no wider than
'long'.

After a false start, I came up with this patch, which seems to work.
It applies the desirable GMP special cases directly in the body,
rather than via overloads.

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

Updated debug architecture version checks for fbsd

There are two new debug architecture version entries.  I updated the
code for Linux, but fbsd also needs updating.

This patch does this, and should be pretty straightforward.

I can't test this on native fbsd, but I'm fairly confident it should
work.

Signed-off-by: Luis Machado <luis.machado@arm.com>

Add new debug architecture version

Teach gdb about a new debug architecture version for AArch64 (0x11).

No user-visible changes.

Regression-tested on aarch64-linux Ubuntu 20.04/22.04.

Signed-off-by: Luis Machado <luis.machado@arm.com>

i386-dis.c UB shift and other tidies

1) i386-dis.c:12055:11: runtime error: left shift of negative value -1
Bit twiddling is best done unsigned, due to UB on overflow of signed
expressions.  Fix this by using bfd_vma rather than bfd_signed_vma
everywhere in i386-dis.c except print_displacement.

2) Return get32s and get16 value in a bfd_vma, reducing the need for
temp variables.

3) Introduce get16s and get8s functions to simplify the code.

4) With some optimisation options gcc-13 legitimately complains about
a fall-through in OP_I.  Fix that.  OP_I also doesn't need to use
"mask" which was wrong for w_mode anyway.

5) Masking with & 0xffffffff is better than casting to unsigned.  We
don't know for sure that unsigned int is 32-bit.

6) We also don't know that unsigned char is 8 bits.  Mask codep
accesses everywhere.  I don't expect binutils will work on anything
other than an 8-bit char host, but if we are masking codep accesses in
some places we might as well be consistent.  (Better would be to use
stdint.h types more in binutils.)

binutils runtest $CC

I noticed in the binutile Makefile that runtest is being invoked with
CC, CC_FOR_BUILD and other compiler related flags in the environment.
That doesn't work.  Those variables ought to be passed on the runtest
command line.

After fixing that I had some fails due to binutils testprog.c now
being compiled with the default "-g -O2" picked up in
CFLAGS_FOR_TARGET.  Hack around that by passing -O0.

Also, with the binutils testsuite now taking notice of CC_FOR_TARGET,
I found a couple of debuginfod.exp fails with one of my compilers that
happened to be built without --debug-id being enabled by default.

* Makefile.am (check-DEJAGNU): Pass $CC and other variable on
the runtest command line rather than futilely in the
environment.  Add -O0 to CFLAGS_FOR_TARGET.
* Makefile.in: Regenerate.
* testsuite/binutils-all/debuginfod.exp: Compile testprog.c
with -Wl,--build-id.

Avoid another -Werror=dangling-pointer

write.c:415:7: error: dangling pointer ‘prev_frag’ to ‘dummy’ may be used

* write.c (chain_frchains_together_1): Rewrite loop as a do
while to avoid false positive -Wdangling-pointer.

Automatic date update in version.in

Use scoped_restore in varobj.c

One spot in varobj.c should use scoped_restore to save and restore
input_radix.  Note that the current code may fail to restore it on
error, so this patch fixes a latent bug.

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

Remove some "goto"s from parse.c

parser_state::push_dollar has some unnecessary "goto"s.  Replacing
them cleans up the code.  Regression tested on x86-64 Fedora 36.

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

section-select: Fix performance problem (PR30367)

when using many wild-statements with non-wildcard filenames we
were running into quadraticness via repeatedly using lookup_name
on a long list of loaded files.  I've originally retained using
lookup_name because that preserved existing behaviour most obviously.
In particular in matching wild-statements when using a non-wildcard
filename it matches against local_sym_name, not the filename member.
If the wildspec would have an archive-spec or a wildcard it would use
the filename member, though.  Also it would load the named file
(and ignore it, as being not equal to the currently considered
input-statement).

Rewrite this to not use lookup_name but retain the comparison
against local_sym_name with a comment to that effect.

PR 30367
* ldlang.c (walk_wild_section_match): Don't use lookup_name
but directly compare spec and local_sym_name.

RISC-V: adjust logic to avoid register name symbols

Special casing GPR names in my_getSmallExpression() leads to a number of
inconsistencies. Generalize this by utilizing the md_parse_name() hook,
limited to when instruction operands are being parsed (really: probed).
Then both the GPR lookup there and the yet more ad hoc workaround for
PR/gas 29940 can be removed (including its extension needed for making
the compressed form JAL work again).

RISC-V: test for expected / no unexpected symbols

Both the temporary workaround for PR/gas 29940 and the existing special
casing of GPRs in my_getSmallExpression() aren't really tested anywhere
(i.e. with the workarounds remove testing would still succeed). Nor is
there any test for uses of symbols with names matching GPRs, where such
is permitted. Before altering how this is to be dealt with, install two
testcases covering the expected behavior. (For now this includes only
known affected insns; re-ordering of entries in riscv_opcodes[] could,
however, yield more of them.)

RISC-V: don't recognize bogus relocations

With my_getSmallExpression() consistently and silently failing on
relocation operators not fitting an insn, it is no longer necessary to
hand it percent_op_itype[] "just in case" (i.e. to avoid errors when a
subsequent parsing attempt for another operand combination might
succeed). This also eliminates the latent problem of percent_op_itype[]
and percent_op_stype[] growing a non-identical set of recognized
relocation operators.

RISC-V: avoid redundant and misleading/wrong error messages

The use of a wrong (for the insn) relocation operator (or a future one
which simply isn't recognized by older gas yet) doesn't render the (rest
of the) expression "bad". Furthermore alongside the error from
expression() in most cases the parser would emit another error then
anyway. Suppress the call to my_getExpression() in such a case,
arranging for a guaranteed subsequent error message by marking the
expression "illegal".

RISC-V: drop "percent_op" parameter from my_getOpcodeExpression()

Both callers check for no relocations, so there's no point parsing for
some. Have the function pass percent_op_null into
my_getSmallExpression(). Note that there's no point passing
percent_op_itype: Elsewhere, especially when processing compressed alias
insns ahead of non-alias ones, this has the effect of avoiding "bad
expression" errors when another parsing pass may follow (and succeed).
Here, however, all alternative forms of an insn type will again start
with the same O4 or O2, so avoiding errors earlier on doesn't really
help. Plus constructs with a relocation specifier (as percent_op_itype
would permit) can't be specified anyway, as the scrubber eats the
whitespace between .insn's type and the O4 or O2 expression when that
starts with % or ( - i.e. these will be seen as e.g. "i%lo(x)", and
riscv_ip() looks only for whitespace when finding the end of a mnemonic.

RISC-V: minor effort reduction in relocation specifier parsing

The sole caller of parse_relocation() has already checked for the %
prefix, so there's no need to check for it again in the strncasecmp()
and there's also no reason to make the involved string literals longer
than necessary.

[gdb/testsuite] Fix timeout in gdb.tui/empty.exp

In test-case gdb.tui/empty.exp we run into:
...
WARNING: timeout in accept_gdb_output
PASS: gdb.tui/empty.exp: src: 90x40: box 1
...

We timeout here in Term::resize:
...
# Due to the strange column resizing behavior, and because we
# don't care about this intermediate resize, we don't check
# the size here.
wait_for "@@ resize done $_resize_count"
...
because the string we're trying to match is split over two lines:
...
25 -----------------------------------------------------------------------------+No
26 ne No process In:                                               L??   PC: ?? @@
27 resize done 0, size = 79x40
28 (gdb)
...

Fix this by dropping the "@@ " prefix.

Tested on x86_64-linux.

[gdb/testsuite] Fix timeout in gdb.tui/completion.exp

With test-case gdb.tui/completion.exp, we run into:
...
WARNING: timeout in accept_gdb_output
PASS: gdb.tui/completion.exp: check focus completions
...

The timeout happens in this command:
...
Term::command "layout src"
...
which waits for:
- "(gdb) layout src", and then
- "(gdb) ".

Because the "layout src" command enables the TUI there's just a prompt.

Fix this by using Term::command_no_prompt_prefix.

Tested on x86_64-linux.

[gdb/testsuite] Fix timeout in gdb.tui/new-layout.exp

In test-case gdb.tui/new-layout.exp we run into:
...
WARNING: timeout in accept_gdb_output
PASS: gdb.tui/new-layout.exp: layout=cmd_only {cmd 1} {} {}: \
  bottom of cmd window is blank
...

The timeout happens here:
...
    Term::command "layout src"
...

Before the "layout src" command we have:
...
Screen Dump (size 80 columns x 24 rows, cursor at column 46, row 7):
    0 +-tui-layout.c-------------------------+(gdb) layout example3
    1 |       20 {                           |(gdb) layout src
    2 |       21   return 0;                 |(gdb) winheight cmd 8
    3 |       22 }                           |(gdb) layout example4
    4 |       23                             |(gdb) layout src
    5 |       24                             |(gdb) winheight cmd 8
    6 |       25                             |(gdb) layout example5
    7 |       26                             |(gdb)
    8 |       27                             |
    9 |       28                             |
   10 |       29                             |
   11 |       30                             |
   12 |       31                             |
   13 |       32                             |
   14 |       33                             |
   15 |       34                             |
   16 |       35                             |
   17 |       36                             |
   18 |       37                             |
   19 |       38                             |
   20 |       39                             |
   21 |       40                             |
   22 +--------------------------------------+
   23 exec No process In:                                                L??   PC: ??
...
and after:
...
Screen Dump (size 80 columns x 24 rows, cursor at column 6, row 16):
    0 +-tui-layout.c-----------------------------------------------------------------+
    1 |       20 {                                                                   |
    2 |       21   return 0;                                                         |
    3 |       22 }                                                                   |
    4 |       23                                                                     |
    5 |       24                                                                     |
    6 |       25                                                                     |
    7 |       26                                                                     |
    8 |       27                                                                     |
    9 |       28                                                                     |
   10 |       29                                                                     |
   11 |       30                                                                     |
   12 |       31                                                                     |
   13 |       32                                                                     |
   14 +------------------------------------------------------------------------------+
   15 exec No process In:                                                L??   PC: ??
   16 (gdb)
   17
   18
   19
   20
   21
   22
   23
...

The Term::command "layout src" is waiting to match:
- "(gdb) layout src", and then
- "(gdb) ".

The first part fails to match on a line:
...
|       26                             |(gdb) layout src
...
because it expects the prompt at the start of the line.

Fix this by allowing the prompt at the start of a window as well.

Tested by x86_64-linux.

[gdb/testsuite] Fix timeout in gdb.tui/main.exp

With test-case gdb.tui/main.exp we run into:
...
WARNING: timeout in accept_gdb_output
PASS: gdb.tui/main.exp: show main after file
...

The problem is that this command:
...
Term::command "file [standard_output_file $testfile]"
...
tries to match "(gdb) $cmd", but due to the long file name, $cmd is split up
over two lines:
...
   16 (gdb) file /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.tui/main/ma
   17 in
   18 Reading symbols from /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.t
   19 ui/main/main...
   20 (gdb)
...

Fix this by matching "Reading symbols from" instead.

Tested on x86_64-linux.

[gdb/testsuite] Fix timeout in gdb.tui/corefile-run.exp

With test-case gdb.tui/corefile-run.exp we run into:
...
WARNING: timeout in accept_gdb_output
PASS: gdb.tui/corefile-run.exp: load corefile
...

The timeout happens in this command:
...
Term::command "core-file $core"
...
because it tries to match "(gdb) $cmd" but $cmd is split over two lines:
...
   16 (gdb) core-file /data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb.tui/co
   17 refile-run/corefile-run.core
   18 [New LWP 5370]
   19 Core was generated by `/data/vries/gdb/leap-15-4/build/gdb/testsuite/outputs/gdb
   20 .tui/corefile-run/coref'.
   21 Program terminated with signal SIGTRAP, Trace/breakpoint trap.
   22 #0  main () at tui-layout.c:21
   23 (gdb)
...

Fix this by using send_gdb "$cmd\n" and wait_for "Program terminated" instead.

Tested on x86_64-linux.

[gdb/testsuite] Add debug prints in Term::wait_for

The semantics of wait_for are non-trivial, and a bit hard to understand
sometimes.

Add some debug prints in wait_for that make it clear:
- what regexps we're trying to match,
- what strings we compare to the regexps, and
- whether there's a match or mismatch.

I've added this ad-hoc a couple of times, and it seems that it's worth having
readily available.

The debug prints are enabled by adding DEBUG_TUI_MATCHING=1 to the
RUNTESTFLAGS:
...
$ make check RUNTESTFLAGS="gdb.tui/empty.exp DEBUG_TUI_MATCHING=1"
...

Tested on x86_64-linux.

[gdb/testsuite] Add warning for timeout in accept_gdb_output

In accept_gdb_output we have:
...
            timeout {
                # Assume a timeout means we somehow missed the
                # expected result, and carry on.
                return 0
            }
...

The timeout is silent, and though in some places the return value is checked,
this is not done consistently, and consequently there are silent timeouts
when running the TUI testsuite (gdb.tui/*.exp and gdb.python/tui*.exp).

Each timeout is 10 seconds, and there are 5 in total in the TUI tests, taking
50 seconds overall:
...
real    1m0.275s
user    0m10.440s
sys     0m1.343s
...

With an entire testsuite run taking about 30 minutes, that is about 2.5% of
the time spent waiting in TUI tests.

Let's make the timeouts visible using a warning, such that they can be fixed.

Tested on x86_64-linux.

Automatic date update in version.in

[gdb/testsuite] Fix auto-indent in gdb.gdb/python-helper.exp

When editing gdb.gdb/python-helper.exp, auto-indent is broken in my editor
(emacs).

The problem is that this:
...
if { 1 } {
    foo "{" "}"<ENTER>bar
}
...
produces this:
...
if { 1 } {
    foo "{" "}"
bar
}
...

Note that this doesn't happen for "{}".

Fix this by using "\{" and "\}".

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.gdb/python-helper.exp with -O2 -flto

On openSUSE Leap 15.4, with gcc 7.5.0, when building gdb with
-O2 -g -flto=auto, I run into:
...
FAIL: gdb.gdb/python-helper.exp: hit breakpoint in outer gdb
FAIL: gdb.gdb/python-helper.exp: print integer from DWARF info
FAIL: gdb.gdb/python-helper.exp: print *type->main_type
...

Fix the first two FAILs by using $bkptno_numopt_re.

The last FAIL is due to:
...
(outer-gdb) print *type->main_type^M
A syntax error in expression, near `->main_type'.^M
(outer-gdb) FAIL: gdb.gdb/python-helper.exp: print *type->main_type
...
because:
...
(outer-gdb) print type^M
Attempt to use a type name as an expression^M
...

Fix this by making the test unresolved if "print type" or
"print type->main_type" doesn't succeed.

On openSUSE Tumbleweed, with gcc 13.0.1, when building gdb with
-O2 -g -flto=auto, I run into timeouts due to the breakpoint in c_print_type
not hitting.  Fix this by detecting the situation and bailing out.

Tested on x86_64-linux.

[gdb/testsuite] Fix -wrap in presence of -prompt in gdb_test_multiple

While writing a gdb_test_multiple call in a test-case I tried to use -wrap in
combination with -prompt and found out that it doesn't work, because -wrap uses
"$gdb_prompt $" instead of $prompt_regexp.

Fix this by making -wrap use $prompt_regexp.

Tested on x86_64-linux.

gdb: remove end_stepping_range observable

I noticed that this observable was never notified, which means we can
probably safely remove it.  The notification was removed in:

    commit 243a925328f8e3184b2356bee497181049c0174f
    Author: Pedro Alves <palves@redhat.com>
    Date:   Wed Sep 9 18:23:24 2015 +0100

        Replace "struct continuation" mechanism by something more extensible

print_end_stepping_range_reason in turn becomes unused, so remote it as
well.

Change-Id: If5da5149276c282d2540097c8c4327ce0f70431a

[gdb/testsuite] Use -std=gnu99 for gdb.server/attach-flag.exp

When using a compiler defaulting to -std=gnu90, we run into:
...
Running gdb.server/attach-flag.exp ...
gdb compile failed, attach-flag.c: In function 'main':
attach-flag.c:22:3: error: 'for' loop initial declarations are only allowed \
  in C99 or C11 mode
   for (int i = 0; i < NTHREADS; i++)
   ^~~
attach-flag.c:22:3: note: use option -std=c99, -std=gnu99, -std=c11 or \
  -std=gnu11 to compile your code
...

Fix this by using -std=gnu99.

Tested on x86_64-linux.

[gdb/testsuite] Require GCC >= 5.x.x in gdb.base/utf8-identifiers.exp

Test-case gdb.base/utf8-identifiers.exp compiles starting with GCC 5, so
require this.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.multi/multi-arch.exp on powerpc64le

When running test-case gdb.multi/multi-arch.exp on powerpc64le-linux, I run into:
...
Running gdb/testsuite/gdb.multi/multi-arch.exp ...
gdb compile failed, In file included from /usr/include/features.h:399:0,
                 from /usr/include/stdio.h:27,
                 from gdb/testsuite/gdb.multi/hangout.c:18:
/usr/include/gnu/stubs.h:8:27: fatal error: gnu/stubs-32.h: \
  No such file or directory
 # include <gnu/stubs-32.h>
                           ^
compilation terminated.
...

The problem is that the test-case attempts to use gcc -m32 to produce an
executable while that's not available.

Fix this by:
- introduce a new caching proc have_compile_and_link_flag, and
- using have_compile_and_link_flag in test-case gdb.multi/multi-arch.exp.

Tested on:
- x86_64-linux (openSUSE Leap 15.4), and
- powerpc64le-linux (CentOS-7).

[gdb/testsuite] Add basic lmap for tcl < 8.6

With test-case gdb.dwarf2/dw2-abs-hi-pc.exp and tcl 8.5, I run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.dwarf2/dw2-abs-hi-pc.exp.
ERROR: invalid command name "lmap"
    while executing
"::gdb_tcl_unknown lmap i {dw2-abs-hi-pc.c dw2-abs-hi-pc-hello.c \
  dw2-abs-hi-pc-world.c} { expr { "$srcdir/$subdir/$i" } }"
...

Fix this by adding basic lmap support for tcl version < 8.6.

Tested on x86_64-linux.

[gdb/testsuite] Don't use string cat in gdb.dwarf2/dw2-abs-hi-pc.exp

Test-case gdb.dwarf2/dw2-abs-hi-pc.exp uses string cat:
...
set sources [lmap i $sources { string cat "${srcdir}/${subdir}/" $i }]
...
but that's only supported starting tcl 8.6.

Fix this by using "expr" instead:
...
set sources [lmap i $sources { expr { "$srcdir/$subdir/$i" } }]
...

Tested on x86_64-linux.

New georgian translation for the bfd sub-directory

Revert "x86: work around compiler diagnosing dangling pointer"

This reverts commit 983db9932a302f9e2ae1f1d4fd7c3149560bc269.

gcc-13 i386-dis.c warning

opcodes/i386-dis.c: In function ‘print_insn’:
opcodes/i386-dis.c:9865:22: error: storing the address of local
variable ‘priv’ in ‘*info.private_data’ [-Werror=dangling-pointer=]

* i386-dis.c (print_insn): Clear info->private_data before
returning.

asan: segfault in coff_mangle_symbols

The testcase managed to trigger creation of a wild pointer in
coff_slurp_symbol_table.  Stop that happening, and fix an unrelated
problem I happened to see in bfd_coff_get_syment.

* coff-bfd.c (bfd_coff_get_syment): Clear fix_value after
converting n_value from a pointer to an index.
* coffcode.h (coff_slurp_symbol_table <C_BSTAT>): Sanity check
symbol value before converting to a pointer.

objcopy of archives tidy

This makes sure the input element bfd is closed before exiting the
loop copying elements.

* objcopy.c (copy_archive): Rename output_bfd to output_element.
Localise last_element.  Close this_element in more error cases.

[gdb/testsuite] Skip dap tests for tcl 8.5

When running the dap tests on a system with tcl 8.5, we run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.dap/memory.exp.
ERROR: bad class "entier": must be alnum, alpha, ascii, control, boolean, \
  digit, double, false, graph, integer, list, lower, print, punct, space, \
  true, upper, wideinteger, wordchar, or xdigit
    while executing
"string is entier $num"
    (procedure "num" line 16)
    invoked from within
...

Fix this by:
- requiring tcl 8.6 in allow_dap_tests, and
- adding the missing require allow_dap_tests in gdb.dap/memory.exp.

Tested on x86_64-linux.

x86: work around compiler diagnosing dangling pointer

For quite come time print_insn() has been storing the address of a local
variable into info->private_data. Since the compiler can't know that the
field won't be accessed again after print_insn() returns, it may kind of
legitimately diagnose this. And recent enough gcc does as of the
introduction of the fetch_error() return paths (replacing setjmp()-based
error handling).

Utilizing that neither prefix_name() nor i386_dis_printf() actually use
info->private_data, zap the pointer in fetch_error(), after having
retrieved it for local use.

Automatic date update in version.in

MIPS: fix loongson3 llsc workaround

-mfix-looongson3-llsc may add sync instructions not needed on some
asm code with lots of debug info.

PR: 30153
* gas/config/tc-mips.c(fix_loongson3_llsc): clear logistic.

MIPS: default output r6 obj if the triple is r6

If the triple is mipsisa32r6* or mipsisa64r6*, ld/as should output
r6 objects by default.
The triples with vendor `img` should do same.

The examples include:
as xx.s -o xx.o
ld -r -b binary xx.dat -o xx.o

MIPS: support mips*64 as CPU and gnuabi64 as ABI

For MIPS64r6 ports, Debian as an example, `mipsisa64r6el` is
used as the cpu name in triple.
Let's recognize them by `mips*64*(el)`.

For 64bit Ports, like Debian's mips64el and mips64r6el ports,
`gnuabi64` is used as the abi section.
Let's use N64 abi by default for the triple with gnuabi64.

LoongArch: Fix loongarch32 test fails

Regenerated macro_op_32.d and add skip loongarch64-*-*.

gas/ChangeLog:

* testsuite/gas/loongarch/macro_op_32.d: Regenerated.

ld/ChangeLog:

* testsuite/ld-loongarch-elf/macro_op_32.d: Regenerated.

Automatic date update in version.in

[gdb/testsuite] Remove debug prints in gdb_find_gdc

When running the gdb.dlang test-cases, and forcing gdb_find_gdc to be used
rather than dejagnu's copy (mimicing what happens with an older dejagnu
without find_gdc), I run into these debug prints:
...
Tool Root: /data/vries/gdb/leap-15-4/build
CC: gdc
...

Remove these.

Tested on x86_64-linux.

gdb: Fix false match issue in skip_prologue_using_linetable

[ Changes in v2:
  - rebase on trunk
  Changes in v3:
  - add test-case ]

We should exclude matches to the ending PC to prevent false matches with the
next function, as prologue_end is located at the end PC.

  <fun1>:
    0x00: ... <-- start_pc
    0x04: ...
    0x08: ... <-- breakpoint
    0x0c: ret
  <fun2>:
    0x10: ret <-- end_pc | prologue_end of fun2

Tested on x86_64-linux.

Co-Authored-By: WANG Rui <r@hev.cc> (fix, tiny change [1])
Co-Authored-By: Tom de Vries <tdevries@suse.de> (test-case)
Approved-by: Kevin Buettner <kevinb@redhat.com>
[1] https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html

PR symtab/30369
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30369

Automatic date update in version.in

gdb: remove language_auto

I think that the language_auto enumerator and the auto_language class
can be removed.  There isn't really an "auto" language, it's only a
construct of the "set language" command to say "pick the appropriate
language automatically".  But "auto" is never the current language.  The
`current_language` points to the current effective language, and the
fact that we're in "auto language" mode is noted by the language_mode
global.

 - Change set_language to handle the "auto" (and "local", which is a
   synonym) early, instead of in the for loop.  I think it makes the two
   cases (auto vs explicit language) more clearly separated anyway.

 - Adjust add_set_language_command to hard-code the "auto" string,
   instead of using the "auto" language definition.

 - Remove auto_language, rename auto_or_unknown_language to
   unknown_language and move the bits of the existing unknown_language
   in there.

 - Remove the set_language at the end of _initialize_language.  I think
   it's not needed, because we call set_language in gdb_init, after all
   _initialize functions are called.  There is some chance that an
   _initialize function that runs after _initialize_language implicitly
   depends on current_language being set, but my testsuite runs haven't
   found anything like that.

 - Use language_unknown instead of language_auto when creating a minimal
   symbol (minimal_symbol_reader::record_full).  I think that this value
   is used to indicate that we don't know the symbol of the minimal
   symbol (yet), so language_unknown makes sense to me.  Update a
   condition accordingly in ada-lang.c.  symbol_find_demangled_name also
   appears to "normalize" this value from "unknown" to "auto", remove
   that part and update the condition to just check for
   language_unknown.

Change-Id: I47bcd6c15f607d9818f2e6e413053c2dc8ec5034
Reviewed-By: Tom Tromey <tom@tromey.com>

gdb: switch "set language" to getter/setter

The `language` global variable is mostly a scratch variable used for the
setting.  The source of truth is really current_language and
language_mode (auto vs manual), which are set by the
set_language_command callback.

Switch the setting to use the add_setshow_enum_cmd overload that takes a
value getter and setter.

Change-Id: Ief5b2f93fd7337eed7ec96023639ae3dfe62250b
Reviewed-By: Tom Tromey <tom@tromey.com>

gdb: remove return value of set_language

set_language returns the previous language, but nothing uses it.  Remove
the return value.  This lets us remove the assignment to
current_language, in _initialize_language.

Change-Id: Ifccf9b488434c1addf4626130a74e159a37d8c17
Reviewed-By: Tom Tromey <tom@tromey.com>

[gdb/testsuite] Add make-check-all.sh

Directory gdb/testsuite/boards contains a number of host/target boards, which
run a test-case (or test-cases) in a different way.

The benefits of using these boards are:
- improving test coverage of gdb,
- making the testsuite more robust, and
- making sure the test-cases work for non-native and remote setups, if
  possible.

Each board is slightly different, and developers need to learn how to use each
one, what parameters to pass and how, and which ones can be used in
combination with each other.  This is a threshold to start using them.

And then there quite a few, so I suppose typically only a few will be used by
each developer.

Add script gdb/testsuite/make-check-all.sh, that's intended to function as a
drop-in replacement of make check, while excercising all host/target boards in
gdb/testsuite/boards.

An example of make-check-all.sh for one test-case is:
...
 $  ~/gdb/src/gdb/testsuite/make-check-all.sh gdb.base/advance.exp
 LOCAL:
 # of expected passes            8
 TARGET BOARD: cc-with-gdb-index
 # of expected passes            8
   ...
 HOST BOARD: local-remote-host-notty, TARGET BOARD: remote-stdio-gdbserver
 # of expected passes            8
 HOST/TARGET BOARD: local-remote-host-native
 # of expected passes            8
...

Shell-checked and tested on x86_64-linux.

Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>

[gdb/cli] Add maint info screen

While working on PRs tui/30337 and cli/30346 I came across various notions of
width in gdb, as reported by gdb, readline, curses and the environment
variables.

As for gdb, readline and the environment variables, the way things work
is:
- Gdb asks readline to detect screen size,
- readline sets the actual screen size in the environment variables
  COLUMNS and LINES,
- readline reports back a screen size to gdb, which may have one column
  less than the actual screen size, to deal with lack of auto-wrap.
  This becomes gdb's notion of screen size (in other words the point where
  we can expect the gdb command line to wrap),
- Gdb then explicitly sets readline's screen size, which readline itself may
  adjust to deal with lack of auto-wrap.  This becomes readlines notion
  of screen size (well, internally the unadjusted one, but it'll report back
  the adjusted one).

Add a command "maint info screen" that prints these notions, both for width
and height.

For TERM=xterm we have:
...
$ TERM=xterm gdb -ex "maint info screen"
Number of characters gdb thinks are in a line is 118.
Number of characters readline reports are in a line is 118.
Number of characters curses thinks are in a line is 118.
Number of characters environment thinks are in a line is 118 (COLUMNS).
Number of lines gdb thinks are in a page is 27.
Number of lines readline reports are in a page is 27.
Number of lines curses thinks are in a page is 27.
Number of lines environment thinks are in a page is 27 (LINES).
...

And for TERM=ansi:
...
$ TERM=ansi gdb -ex "maint info screen"
Number of characters gdb thinks are in a line is 117.
Number of characters readline reports are in a line is 116.
Number of characters curses thinks are in a line is 118.
Number of characters environment thinks are in a line is 118 (COLUMNS).
Number of lines gdb thinks are in a page is 27.
Number of lines readline reports are in a page is 27.
Number of lines curses thinks are in a page is 27.
Number of lines environment thinks are in a page is 27 (LINES).
...

[ The fact that we have "characters readline reports are in a line is 116" is
is due to gdb making readline adjust twice for the lack of auto-wrap, this is
PR cli/30346.

Likewise we can detect tui/30337 by doing a resize in TUI mode and doing
"maint info screen":
...
Number of characters characters curses thinks are in a line is 110.
Number of characters environment thinks are in a line is 111 (COLUMNS). ]

And for TERM=ansi, with width and heigth set to 0:
...
Number of characters gdb thinks are in a line is 4294967295 (unlimited).
Number of characters readline reports are in a line is 32766 (unlimited - 1).
Number of characters curses thinks are in a line is 118.
Number of characters environment thinks are in a line is 118 (COLUMNS).
Number of lines gdb thinks are in a page is 4294967295 (unlimited).
Number of lines readline reports are in a page is 32767 (unlimited).
Number of lines curses thinks are in a page is 27.
Number of lines environment thinks are in a page is 27 (LINES).
...

[ Note that when doing a resize by say maximizing or de-maximizing a terminal,
all reported values are updated, except for curses when not in TUI mode.

Maybe that means there's a bug.  If not, then maybe we should not print
the curses lines unless in TUI mode, or annotate those lines such that it's
clear that the values may be not up-to-date. ]

I'd like to use this command in the regression test for PR cli/30346.

Tested on x86_64-linux.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom Tromey <tom@tromey.com>

Fix -Wmaybe-uninitialized warning in opcodes/i386-dis.c

A recent change in opcodes/i386-dis.c caused a build failure on my
x86-64 Fedora 36 system, which uses:

$ gcc --version
gcc (GCC) 12.2.1 20221121 (Red Hat 12.2.1-4)
[...]

The error is:

../../binutils-gdb/opcodes/i386-dis.c: In function ‘OP_J’:
../../binutils-gdb/opcodes/i386-dis.c:12705:22: error: ‘val’ may be used uninitialized [-Werror=maybe-uninitialized]
12705 |           disp = val & 0x8000 ? val - 0x10000 : val;
      |                  ~~~~^~~~~~~~

This patch fixes the warning.

opcodes/ChangeLog
2023-04-21  Tom Tromey  <tromey@adacore.com>

* i386-dis.c (OP_J): Check result of get16.

Use entry values for 32-bit PPC struct return

AdaCore has a local patch for PPC "finish", but last year, Ulrich
Weigand pointed out that this patch was incorrect.  It may work for
simple functions like the one in the internal test, but nothing
guarantees that r3 will be preserved by the callee, so checking r3 on
exit is not always correct.

This patch fixes the problem using the same approach as PPC64: use the
entry value of r3, if available.  Ulrich confirmed this matches the
PPC32 ABI.

Handle erroneous DW_AT_call_return_pc

On PPC64, with the test case included in an earlier patch, we found
that "finish" would still not correctly find the return value via
entry values.

The issue is simple.  The compiler emits:

   0x00000000100032b8 <+28>: bl      0x1000320c <pck__create_large>
   0x00000000100032bc <+32>: nop
   0x00000000100032c0 <+36>: li      r9,42

... but the DWARF says:

    <162a>   DW_AT_call_return_pc: 0x100032c0

That is, the declared return PC is one instruction past the actual
return PC.

This patch adds a new arch hook to handle this scenario, and
implements it for PPC64.  Some care is taken so that GDB will continue
to work if this compiler bug is fixed.  A GCC patch is here:

    https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613336.html

No check for 'nop' is done, as subsequent discussion revealed that the
linker might replace this with another instruction.

Handle function descriptors in call_site_target

call_site_target::iterate_over_addresses may look up a minimal symbol.
On platforms like PPC64 that use function descriptors, this may find
an unexpected address.  The fix is to use gdbarch_convert_from_func_ptr_addr
to convert from a function descriptor to the address recorded at the
call site.

I've added a new test case that is based on the internal AdaCore test
that provoked this bug.  However, I'm unable to test it as-is on
PPC64.

x86: drop (explicit) BFD64 dependency from disassembler

get64() is unreachable when !BFD64 (due to a check relatively early in
print_insn()). Let's avoid the associated #ifdef-ary (or else we should
extend it to remove more dead code).

x86: drop use of setjmp() from disassembler

With the longjmp() uses all gone, the setjmp() isn't necessary anymore
either.

x86: change fetch error handling for get<N>()

Make them return boolean and convert FETCH_DATA() uses to fetch_code().
With this no further users of FETCH_DATA() remain, so the macro and its
backing function are dropped as well.

Leave value types as they were for the helper functions, even if I don't
think that beyond get64() use of bfd_{,signed_}vma is really necessary.
With type change of "disp" in OP_E_memory(), change the 2nd parameter of
print_displacement() to a signed type as well, though (eliminating the
need for a local variable of signed type). This also eliminates the need
for custom printing of '-' in Intel syntax displacement expressions.

While there drop forward declarations which aren't really needed.

x86: change fetch error handling when processing operands

Make the handler functions all return boolean and convert FETCH_DATA()
uses to fetch_code().

x86: change fetch error handling in get_valid_dis386()

Introduce a special error indicator node, for the sole (real) caller
to recognize and act upon.

x86: change fetch error handling in ckprefix()

Use a tristate (enum) return value type to be able to express all three
cases which are of interest to the (sole) caller. This also allows doing
away with the abuse of "rex_used".

x86: change fetch error handling in top-level function

... and its direct helper get_sib(). Using setjmp()/longjmp() for fetch
error handling is problematic, as per
https://sourceware.org/pipermail/binutils/2023-March/126687.html. Start
using more conventional error handling instead.

Also introduce a fetch_modrm() helper, for subsequent re-use.

x86: move fetch error handling into a helper function

... such that it can be used from other than the setjmp() error handling
path.

Since I'd like the function's parameter to be pointer-to-const, two
other functions need respective constification then, too (along with
needing to be forward-declared).

bfd: fix STRICT_PE_FORMAT build

A semicolon was missing and "name" needs to be pointer-to-const. While
adding "const" there, also add it for "sec".

RISC-V: Optimize relaxation of gp with max_alignment.

This should be the first related issue, which posted in riscv-gnu-toolchain,
https://github.com/riscv-collab/riscv-gnu-toolchain/issues/497

If the output sections are not between gp and the symbol, then their alignments
shouldn't affect the gp relaxation.  However, this patch improves this idea
even more, it limits the range to the gp+-2k, which means only the output
section which are in the [gp-2K, gp+2K) range need to be considered.

Even if the output section candidates may be different for each relax passes,
the symbol that can be relaxed ar this round will not be truncated at next
round.  That is because this round you can do relaxation which means that the
section where the symbol is located is within the [gp-2K, gp+2K) range, so all
the output section alignments between them should be considered.  In other
words, if the alignments between them may cause truncated, then we should
already preserve the size and won't do the gp relaxation this time.

This patch can resolve the github issue which mentioned above, and also passed
all gcc/binutils regressions of riscv-gnu-toolchain, so should be worth and
safe enough to commit.

Originally, this patch also do the same optimization for the call relaxations,
https://sourceware.org/pipermail/binutils/2022-October/123918.html
But just in case there is something that has not been considered, we only
deal with the gp relaxation at this time.

bfd/
* elfnn-riscv.c (riscv_elf_link_hash_table): Added new bfd_vma,
max_alignment_for_gp.  It is used to record the maximum alignment of
the output sections, which are in the [gp-2K, gp+2k) range.
(riscv_elf_link_hash_table_create): Init max_alignment_for_gp to -1.
(_bfd_riscv_get_max_alignment): Added new parameter, gp.  If gp is
zero, then all the output section alignments are possible candidates;
Otherwise, only the output sections which are in the [gp-2K, gp+2K)
range need to be considered.
(_bfd_riscv_relax_lui): Called _bfd_riscv_get_max_alignment with the
non-zero gp if the max_alignment_for_gp is -1.
(_bfd_riscv_relax_pc): Likewise.
(_bfd_riscv_relax_section): Record the first input section, so that
we can reset the max_alignment_for_gp for each repeated relax passes.
ld/
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
* testsuite/ld-riscv-elf/relax-max-align-gp.*: New testcase.  It fails
without this patch.

ld: add missing period after @xref

At least older versions of one of the doc generation tools complain
(warn) about it missing.

Keeping track of rs6000-coff archive element pointers

rs6000-coff archives use a linked list of file offsets, where each
element points to the next element.  The idea is to allow updating of
large archives quickly without rewriting the whole archive.  (binutils
ar does not do this.)  Unfortunately this is an easy target for
fuzzers to create an archive that will cause ar or any other tool
processing archives to hang.  I'd implemented guards against pointing
back to the previous element, but of course that didn't last long.

So this patch implements a scheme to keep track of file offset ranges
used by elements as _bfd_read_ar_hdr is called for each element.  See
the add_range function comment.  I needed a place to stash the list,
so chose the obvious artdata.tdata backend extension to archive's
tdata, already used by xcoff.  That involved a little cleanup, because
while it would be possible to continue using different artdata.tdata
for the big and small archives, it's nicer to use a union.

If anyone is concerned this list of element ranges might grow large
and thus significantly slow down the tools, adjacent ranges are
merged.  In fact something like "ar t" will only ever have one range
on xcoff archives generated by binutils/ar.  I agree there might still
be a problem with ld random element access via the armap.

include/
* coff/xcoff.h (SIZEOF_AR_FILE_HDR): Use sizeof.
(SIZEOF_AR_FILE_HDR_BIG, SIZEOF_AR_HDR, SIZEOF_AR_HDR_BIG): Likewise.
(struct ar_ranges, struct xcoff_artdata): New.
(x_artdata): Define.
(xcoff_big_format_p): Rewrite.
(xcoff_ardata, xcoff_ardata_big): Delete.
bfd/
* coff-rs6000.c: Replace uses of xcoff_ardata and
xcoff_ardata_big throughout file.
(_bfd_xcoff_archive_p): Adjust artdata.tdata allocation.
(add_range): New function.
(_bfd_xcoff_read_ar_hdr): Use it here.  Fix memory leak.
(_bfd_xcoff_openr_next_archived_file): Remove old sanity
checks.  Set up range for header.
(xcoff_write_archive_contents_old): Make the temporary
artdata.tdata used here to pass info down to
_bfd_compute_and_write_armap a struct xcoff_artdata.
(xcoff_write_archive_contents_big): Likewise.
* coff64-rs6000.c: Replace uses of xcoff_ardata and
xcoff_ardata_big throughout file.
(xcoff64_archive_p): Adjust artdata.tdata allocation.

Delete struct artdata archive_head

This element is unused.  Ideally we'd be moving archive_head and
other archive specific fields from struct bfd to here, but that's a
much larger change than this little bit of cleanup.

* libbfd-in.h (struct artdata): Delete archive_head.
* libbfd.h: Regenerate.
* archive.c,
* coff-rs6000.c,
* coff64-rs6000.c: Delete comments mentioning artdata archive_head.

Automatic date update in version.in