testsuite, fortran: adapt tests for ifort's 'start' behavior

The modified tests array-slices-bad.exp and vla-type.exp both set a
breakpoint at the first real statement in the respective executables.

Normally, the expected behavior of fortran_runto_main for these would be
the stopping of the debugger at exactly the first statment in the code.

Strangely, neither gfortran nor ifx seem to do this for these tests.
Instead, issuing 'start' in ifx (for either of the 2 tests) lets GDB
stop at the 'program ...' line and gfortran stops at a variable
declaration line.  E.g. for vla-type it stops at

  41        type(five)               :: fivearr (2)

So, actually, ifort's behavior can be considered to be a bit more
'correct' here.  This patch remove the fortran_runto_main in the
two tests and instead uses runto to directly run to the first breakpoint
set at the first program statement.  This works with both compiler
behaviors and makes the tests more robust.

Approved-by: Kevin Buettner <kevinb@redhat.com>

testsuite, fortran: Remove self assignment non-statements

There were a couple of places in the testsuite where instructions like

  var = var

were written in the source code of tests.  These were usually dummy
statements meant to generate a line table entry at that line on which
to break later on.

This worked fine for gfortran and ifx, but it seems that, when compiled
with ifort (2021.6.0) these statements do not actually create any
assmbler instructions and especially no line table entries.  Consider
the program

  program test
    Integer var :: var = 1
    var = var
  end program

compiled with gfortran (13.0.0, -O0 -g).  The linetable as emitted by
'objdump --dwarf=decodedline ./a.out' looks like

  test.f90:
  File name   Line number    Starting address    View    Stmt
  test.f90              1            0x401172               x
  test.f90              3            0x401176               x
  test.f90              4            0x401182               x
  test.f90              4            0x401185               x
  test.f90              4            0x401194               x
  test.f90              -            0x4011c0

actually containing line table info for line 3.  Running gdb, breaking
at 3 and checking the assembly we see

   0x0000000000401172 <+0>:     push   %rbp
   0x0000000000401173 <+1>:     mov    %rsp,%rbp
=> 0x0000000000401176 <+4>:     mov    0x2ebc(%rip),%eax   # 0x404038 <var.1>
   0x000000000040117c <+10>:    mov    %eax,0x2eb6(%rip)   # 0x404038 <var.1>
   0x0000000000401182 <+16>:    nop
   0x0000000000401183 <+17>:    pop    %rbp
   0x0000000000401184 <+18>:    ret

so two mov instructions are being issued for this assignment one copying
the value into a register and one writing it back to the same memory.
Ifort (2021.6.0, -O0 -g) on the other hand does not emit anything here
and also has no line table entry:

  test.f90:
  File name   Line number    Starting address    View    Stmt
  test.f90              1            0x4040f8               x
  test.f90              4            0x404109               x
  test.f90              4            0x40410e               x
  test.f90              -            0x404110

As I do not think that this is really a bug (on either side, gfortran/ifx or
ifort), and as I don't think this behavior is covered in the Fortran
standard, I changed these lines to become actual value assignments.

This removes a few FAILs in the testsuite when ran with ifort.

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

testsuite, fortran: make mixed-lang-stack less compiler dependent

In the gdb.fortran/mixed-lang-stack.exp test when somewhere deep in a
bunch of nested function calls we issue and test a 'info args' command
for the mixed_func_1b function (when in that function's frame).

The signature of the function looks like

  subroutine mixed_func_1b(a, b, c, d, e, g)
    use type_module
    implicit none

    integer :: a
    real(kind=4) :: b
    real(kind=8) :: c
    complex(kind=4) :: d
    character(len=*) :: e
    character(len=:), allocatable :: f
    TYPE(MyType) :: g

and usually one would expect arguments a, b, c, d, e, and g to be
emitted here.  However, due to some compiler dependent treatment of the
e array the actual output in the test (with gfortran/ifx) is

  (gdb) info args
  a = 1
  b = 2
  c = 3
  d = (4,5)
  e = 'abcdef'
  g = ( a = 1.5, b = 2.5 )
  _e = 6

where the compiler generated '_e' is emitted as the length of e.  While
ifort also generates an additional length argument, the naming (which is
up to the compilers here I think, I could not find anything in the
Fortran standard about this) is different and we see

  (gdb) info args
  a = 1
  b = 2
  c = 3
  d = (4,5)
  e = 'abcdef'
  g = ( a = 1.5, b = 2.5 )
  .tmp.E.len_V$4a = 6

To make both outputs pass the test, I kept the additional argument for now and
made the regex for the emitted name of the last variable match any
arbitrary name.

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

gdb: add Abdul Basit Ijaz to gdb/MAINTAINERS

Signed-off-by: Ijaz, Abdul B <abdul.b.ijaz@intel.com>

kvx: Add a testcase for bundles with KVXMAXBUNDLEWORDS syllables

* testsuite/gas/kvx/fat-bundles.s: New test.
* testsuite/gas/kvx/kv3-1-fat-bundles.d: New test.
* testsuite/gas/kvx/kv3-2-fat-bundles.d: New test.

PR30793, kvx_reassemble_bundle index 8 out of bounds

While the patch already committed for pr30793 prevents the asan error,
there is a problem: Now the last element of bundle_words never gets
written.  That's very likely wrong, or KVXMAXBUNDLEWORDS is too big.
So this patch rearranges things a little to support writing of all of
bundle_words and does the parallel bit checking only when filling
bundle_words.  In the normal case, kvx_reassemble_bundle will see
bundle_words[word_count-1] with the parallel bit clear and all other
words having it set.  In the error case where all words in
bundle_words have the parallel bit set, kvx_reassemble_bundle will be
passed a wordcount of KVXMAXBUNDLEWORDS + 1.  I've also made
kvx_reassemble_bundle return true for success rather than zero, and
removed the unnecessary check for zero wordcount.

PR 30793
* kvx-dis.c (kvx_reassemble_bundle): Return bool, true on success.
Fail if wordcount is too large.  Don't check for wordcount zero.
Don't check kvx_has_parallel_bit.
(print_insn_kvx): Rewrite code reading bundle_words as a for loop.
Don't stop reading at KVXMAXBUNDLEWORDS - 1.
(decode_prologue_epilogue_bundle): Similarly.

Fix bug in -var-evaluate-expression

This bug points out that if one uses -var-set-visualizer with "None"
-- to disable a pretty-printer for a varobj -- then
-var-evaluate-expression will still use pretty-printing.

This is a combination of bugs.  First, setting the visualizer does not
update the display text; and second, computing the display text should
use "raw" when Python is available but no visualizer is desired.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11738
Reviewed-by: Keith Seitz <keiths@redhat.com>

Remove variable_default_display

variable_default_display has a single caller now, so remove it.

Reviewed-by: Keith Seitz <keiths@redhat.com>

Remove dead code from varobj_set_display_format

varobj_set_display_format takes an enum and exhaustively switches on
the values -- but also has a default.  This default case is dead code.

Reviewed-by: Keith Seitz <keiths@redhat.com>

Allow pretty-printer 'children' method to return strings

A user noticed that, while a pretty-printer can return Python strings
from its "children" method, this does not really work for MI.  I
tracked this down to my_value_of_variable calling into
c_value_of_variable, which specially handles arrays and structures --
not using the actual contents of the string.

Now, this part of MI seems bad to me, but rather than change that,
this applies the fix to only dynamic varobjs, which is the only
scenario where a string like this can really be returned.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18282
Reviewed-by: Keith Seitz <keiths@redhat.com>

[gdb/symtab] Fix gdb-index writing for .debug_types

With test-case gdb.ada/same_enum.exp and target board dwarf4-gdb-index we run
into:
...
(gdb) print red^M
No definition of "red" in current context.^M
(gdb) FAIL: gdb.ada/same_enum.exp: print red
...

[ This is a regression since commit 844a72efbce ("Simplify gdb_index writing"),
so this is broken in gdb 12 and 13. ]

The easiest way to see what's going wrong is with readelf.  We have in section
.gdb_index:
...
[7194] pck__red:
        2 [static, variable]
        3 [static, variable]
...
which points to the CUs 2 and 3 in the CU list (shown using "2" and "3"), but
should be pointing to the TUs 2 and 3 in the TU list (shown using "T2" and
"T3").

Fix this by removing the counter / types_counter distinction in
write_gdbindex, such that we get the expected:
...
[7194] pck__red:
        T2 [static, variable]
        T3 [static, variable]
...

[ While reading write_gdbindex I noticed a few oddities related to dwz
handling, I've filed PR30829 about this. ]

Tested on x86_64-linux.

Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30827
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30827

[gdb/ada] Extend type equivalence test in ada_resolve_enum

When running test-case gdb.ada/local-enum.exp with target board debug-types, I
run into:
...
(gdb) print v1(three)^M
No name 'three' in enumeration type 'local__e1'^M
(gdb) FAIL: gdb.ada/local-enum.exp: print v1 element
...

The array V1 is of type A1 which is an array with index type E1, containing
"three" as enumerator:
...
  type E1 is (one, two, three);
  type A1 is array (E1) of Integer;
  V1 : A1 := (0, 1, 2);
...

There's also a type E2 that contains three as enumerator:
...
  type E2 is (three, four, five);
...

When doing "print v1(three)", it's the job of ada_resolve_enum to resolve
"three" to type E1 rather than type E2.

When using target board debug-types, the enums E1 and E2 are replicated in the
.debug_types section, and consequently in ada_resolve_enum the type
equivalence check using a pointer comparison fails:
...
  for (int i = 0; i < syms.size (); ++i)
    {
      /* We already know the name matches, so we're just looking for
 an element of the correct enum type.  */
      if (ada_check_typedef (syms[i].symbol->type ()) == context_type)
  return i;
    }
...

Fix this by also trying a structural comparison using
ada_identical_enum_types_p.

Tested on x86_64-linux.

Approved-By: Tom Tromey <tom@tromey.com>
PR ada/29335
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29335

[gdb/ada] Move identical enums handling later

When running test-case gdb.ada/arr_acc_idx_w_gap.exp with target board
cc-with-dwz, I run into:
...
(gdb) print enum_with_gaps'enum_rep(lit3)^M
'Enum_Rep requires argument to have same type as enum^M
(gdb) FAIL: gdb.ada/arr_acc_idx_w_gap.exp: enum_rep
...

With target_board unix, we have instead:
...
(gdb) print enum_with_gaps'enum_rep(lit3)^M
$16 = 13^M
(gdb) PASS: gdb.ada/arr_acc_idx_w_gap.exp: enum_rep
...

Conversely, when I add this test to the test-case:
...
     gdb_test "print enum_with_gaps'enum_rep(lit3)" " = 13" \
  "enum_rep"
+    gdb_test "print enum_subrange'enum_rep(lit3)" " = 13" \
+ "other enum_rep"
...
the extra test passes with target board cc-with-dwz, but fails with target
board unix.

The problem is here in remove_extra_symbols:
...
  if (symbols_are_identical_enums (syms))
    syms.resize (1);
...
where one of the two identical enums is picked before the enum_rep handling
can resolve lit3 to one of the two.

Fix this by moving the code to ada_resolve_variable.

Tested on x86_64-linux.

Approved-By: Tom Tromey <tom@tromey.com>
PR ada/30726
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30726

Simplify block_find_symbol

block_find_symbol takes a callback function, but only two callbacks
are ever passed to it -- and they are similar enough that it seems
cleaner to just have block_find_symbol do the work itself.  Also,
block_find_symbol can take a lookup_name_info as an argument,
following the general idea of pushing the construction of these
objects as high in the call chain as feasible.

Regression tested on x86-64 Fedora 38.

Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>

gdb/mi: make current_token a field of mi_interp

Following the commit f818c32ba459 ("gdb/mi: fix ^running record with
multiple MI interpreters"), I thought it would make sense to make
current_token a field of mi_interp.  This variable contains the token of
the currently handled MI command, like the 222 in:

    222-exec-continue

I didn't find any bug related to that, it's just a "that seems nicer"
cleanup, since the current token is a fundamentally per-interp thing.

mi_execute_command needs a check similar to what we already have in
mi_cmd_gdb_exit: when invoked from Python's gdb.execute_mi, the current
interpreter is not an mi_interp.  When using the Python gdb.execute_mi
function, there is no such concept of token, so we can just skip that.

There should be no user-visible change.

Change-Id: Ib52b3c0cba4b7c9d805b432c809692a86e4945ad
Approved-By: Tom Tromey <tom@tromey.com>

gdb: fix indentation in mi/mi-parse.h

Change-Id: Ib841a77a9494648aee9f970141424363664ff6e8

Add testcase for generation of 32/64_PCREL.

Use 32/64_PCREL to replace a pair of ADD32/64 and SUB32/64.

Subtraction for labels that require static relocation
usually generates ADD32/64 and SUB32/64.

If subsy of BFD_RELOC_32/64 and PC in same segment,
and disable relax or PC at start of subsy or enable
relax but not in SEC_CODE, we generate 32/64_PCREL
to replace a pair of ADD32/64 and SUB32/64.

RISC-V: Clarify the naming rules of vendor operands.

The vendor operands should be named starting with `X', and preferably the
second letter (or multiple following letters) is enough to differentiate
them from other vendors.

Therefore, added letter `t' after `X' for t-head operands, to differentiate
from future different vendor's operands.

bfd/
* elfxx-riscv.c (riscv_supported_vendor_x_ext): Removed the vendor
document link since it should already be recorded in the
gas/doc/c-riscv.texi.
gas/
* config/tc-riscv.c (validate_riscv_insn): Added `t' after `X' for
t-head operands.  Minor updates for indents and comments.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Minor updates.
opcodes/
* riscv-dis.c (print_insn_args): Added `t' after `X' for t-head
operands.  Minor updates for indents and comments.
* riscv-opc.c (riscv_opcode): Likewise.

gold: Use char16_t, char32_t instead of uint16_t, uint32_t as character types

The std::basic_string template type is only specified for
instantiations using character types.  Newer (LLVM) libc++
implementations no longer allow non-character integer types
to be used.

gold/
* output.cc: Include <uchar.h>.
(Output_section::add_merge_input_section): Use char16_t and
char32_t for 2- and 4-byte entry size, respectively.
* stringpool.cc: Include <uchar.h>.
(Stringpool_template): Explicitly instantiate for char16_t,
char32_t instead of uint16_t, uint32_t.
* merge.cc (Output_merge_string): Likewise.

Automatic date update in version.in

PR30828, notes obstack memory corruption

Commit 3bab069c29b3 carelessly allowed "string" to be released from
the notes obstack twice, with the second call to obstack_free
releasing memory for a fixup that just happened to be the same size as
the original string.  The fixup then of course was overwritten.
This patch fixes that problem, and another that could occur on an
error path.

PR 30828
* stabs.c (s_stab_generic): Don't free string twice.  Don't
blow away entire notes obstack on a missing string.

[gdb/testsuite] Fix gdb.ada/same_enum.exp

Test-case gdb.ada/same_enum.exp is supposed to be a regression test for this
bit of code in remove_extra_symbols:
...
  if (symbols_are_identical_enums (syms))
    syms.resize (1);
...

The test-case does "print red" and expects one of these two choices to be
picked by remove_extra_symbols:
...
  type Color is (Black, Red, Green, Blue, White);
  type RGB_Color is new Color range Red .. Blue;
...
but because only the type Color is used:
...
  FC : Color := Red;
  SC : Color := Green;
...
the RGB_Color type is eliminated from the debug info, and consequently
remove_extra_symbols has no effect for the test-case.

In other words, we have:
...
(gdb) ptype Color ^M
type = (black, red, green, blue, white)^M
(gdb) ptype RGB_Color^M
No definition of "rgb_color" in current context.^M
...

Fix this by changing the type of SC to RGB_Color, and add prints of the two
types to check that they're both available.

With the test-case fixed, if we disable the bit of code in
remove_extra_symbols we get:
...
(gdb) print red^M
Multiple matches for red^M
[0] cancel^M
[1] pck.color'(pck.red) (enumeral)^M
[2] pck.rgb_colorB'(pck.red) (enumeral)^M
> FAIL: gdb.ada/same_enum.exp: print red (timeout)
...
in other words, the test-case now properly functions as a regression test.

Tested on x86_64-linux.

[gdb/symtab] Fix too many symbols in gdbpy_lookup_static_symbols

When running test-case gdb.python/py-symbol.exp with target board
cc-with-dwz-m, we run into:
...
(gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M
4^M
(gdb) FAIL: gdb.python/py-symbol.exp: \
  print (len (gdb.lookup_static_symbols ('rr')))
...
while with target board unix we have instead:
...
(gdb) python print (len (gdb.lookup_static_symbols ('rr')))^M
2^M
(gdb) PASS: gdb.python/py-symbol.exp: \
  print (len (gdb.lookup_static_symbols ('rr')))
...

The problem is that the loop in gdbpy_lookup_static_symbols loops over compunits
representing both CUs and PUs:
...
    for (compunit_symtab *cust : objfile->compunits ())
...

When doing a lookup on a PU, the user link is followed until we end up at a CU,
and the lookup is done in that CU.

In other words, when doing a lookup in the loop for a PU we duplicate the
lookup for a CU that is already handled by the loop.

Fix this by skipping PUs in the loop in gdb.lookup_static_symbols.

Tested on x86_64-linux.

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

[gdb/symtab] Handle PU in iterate_over_some_symtabs

When running test-case gdb.base/setshow.exp with target board cc-with-dwz I
run into:
...
(gdb) info line 1^M
Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M
Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M
(gdb) FAIL: gdb.base/setshow.exp: test_setshow_annotate: annotation_level 1
...
while the expected output is:
...
Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.
��setshow.c:1:0:beg:0x400527
...

The second line of the expected output is missing due to the first line of the
expected output being repeated, so the problem is that the "Line 1" line is
printed twice.

This happens because the PU imported by the CU reuses the filetab of the CU,
and both the CU and PU are visited by iterate_over_some_symtabs.

Fix this by skipping PUs in iterate_over_some_symtabs.

Tested on x86_64-linux, target boards unix, cc-with-dwz and cc-with-dwz-m.

Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30797
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30797

src-release.sh (SIM_SUPPORT_DIRS): Add libsframe, libctf/swap.h and gnulib

Without this, a simulator build breaks when building from a tarball
made by "./src-release.sh -b sim", when building e.g. bfd and
libsframe.  See also previous similar commits for GDB_SUPPORT_DIRS.

The libctf library does not needed to be built, but building
libsframe requires libctf/swap.h, with no dependencies on built or
configured contents.  Do as for the single gdb files and include
explicitly only that file.

Automatic date update in version.in

Fix 30808 gprofng tests failed

In gprofng testing, we need a tempory gprofng installation to resolve run-time
dependencies on libraries (libgprofng, libopcodes, libbfd, etc).
We set LD_LIBRARY_PATH and GPROFNG_SYSCONFDIR to find our libraries and
configuration file. These variables must be set for all gprofng tests.

Tested on aarch64 and x86_64 with and without --enable-shared and --target=<>.

gprofng/ChangeLog
2023-08-31  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/30808
* testsuite/config/default.exp: Make a temporary install dir.
Set LD_LIBRARY_PATH, GPROFNG_SYSCONFDIR.
* testsuite/lib/Makefile.skel: Move LD_LIBRARY_PATH and
GPROFNG_SYSCONFDIR setting in testsuite/config/default.exp.

gdb/testsuite: Make hook-stop.exp ignore termination message from GDB stub

When a GDB stub is run via "target remote |", it sometimes produces
extra output that ends up mixed with GDB's own output.  For example,
QEMU's built-in GDB stub responds to the vKill packet by printing

nios2-elf-qemu-system: QEMU: Terminated via GDBstub

before exiting.

This patch fixes the regexp in gdb.base/hook-stop.exp to allow such
messages between GDB's "continuing" and "Inferior killed" messages.

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

gdb/testsuite: Disable some tests that are broken on remote Windows host

These testcases assume host==build or that the remote host has a Posix
shell to run commands in.  Don't try to run them if that's not the case.

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

gdb/testsuite: Adjust some testcases to allow Windows pathnames

This patch fixes some testcases that formerly had patterns with
hardwired "/" pathname separators in them, which broke when testing on
(remote) Windows host.

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

gdb/testsuite: Fix style.exp failures on targets without argc/argv support

Some embedded targets don't have full support for argc/argv.  argv
may print as "0x0" or as an address with a symbol name following.
This causes problems for the regexps in the style.exp line-wrapping
tests that assume it always prints as an ordinary address in backtrace
output.

This patch generalizes the regexps to handle these additional forms
and reworks some of the line-wrapping tests to account for the argv
address string being shorter or longer than a regular address.

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

Handle array- and string-like values in no-op pretty printers

This changes the no-op pretty printers -- used by DAP -- to handle
array- and string-like objects known by the gdb core.  Two new tests
are added, one for Ada and one for Rust.

Add new Python APIs to support DAP value display

gdb's language code may know how to display values specially.  For
example, the Rust code understands that &str is a string-like type, or
Ada knows how to handle unconstrained arrays.  This knowledge is
exposed via val-print, and via varobj -- but currently not via DAP.

This patch adds some support code to let DAP also handle these cases,
though in a somewhat more generic way.

Type.is_array_like and Value.to_array are added to make Python aware
of the cases where gdb knows that a structure type is really
"array-like".

Type.is_string_like is added to make Python aware of cases where gdb's
language code knows that a type is string-like.

Unlike Value.string, these cases are handled by the type's language,
rather than the current language.

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

Select frame when fetching a frame variable in DAP

Right now, if a program uses multiple languages, DAP value formatting
will always use the language of the innermost frame.  However, it is
better to use the variable's defining frame instead.  This patch does
this by selecting the frame first.

This also fixes a possibly latent bug in the "stepOut" command --
"finish" is sensitive to the selected frame, but the DAP code may
already select other frames when convenient.  The DAP stepOut request
only works on the newest frame, so be sure to select it before
invoking "finish".

Introduce type::is_array_like and value_to_array

This adds the type::is_array_like method and the value_to_array
function.

The former can be used to see whether a given type is known to be
"array-like".  This is the currently the case for certain
compiler-generated structure types; in particular both the Ada and
Rust compilers do this.

Use ada_value_subscript in valpy_getitem

Ada has a few complexities when it comes to array handling.  Currently
these are all handled in Ada-specific code -- but unfortunately that
means they aren't really accessible to Python.

This patch changes the Python code to defer to Ada when given an Ada
array.  In order to make this work, one spot in ada-lang.c had to be
updated to set the "GNAT-specific" flag on an array type.

The test case for this will come in a later patch.

Introduce TYPE_SPECIFIC_RUST_STUFF

This adds a new enum constant, TYPE_SPECIFIC_RUST_STUFF, and changes
the DWARF reader to set this on Rust types.  This will be used as a
flag in a later patch.

Note that the size of the type_specific_field bitfield had to be
increased.  I checked that this did not impact the size of main_type.

Refactor Rust code for slice-to-array operation

This patch exposes rust_slice_type_p and introduces
rust_slice_to_array, in preparation for subsequent patches that will
need these.

Move rust_language::lookup_symbol_nonlocal

This moves rust_language::lookup_symbol_nonlocal to rust-lang.c.
There's no need to have it in rust-lang.h and moving it lets us avoid
adding new includes in a later patch.

gdb/riscv: Fix oob memory access when printing info registers

If the length of a register name was greater than 15,
print_spaces was called with a negative number, which
prints random data from the heap instead of the requested
number of spaces.

This could happen if a target-description file was used
to specify additional long-named registers.

Fix is simple - don't ask for fewer than 1 space (since
we still want column separation).

Approved-by: Kevin Buettner <kevinb@redhat.com>

Read Ada main name from executable, not inferior

An upstream bug report points out this bug: if the user switches from
one Ada executable to another without "kill"ing the inferior, then the
"start" command will fail.

What happens here is that the Ada "main" name is found in a constant
string in the executable.  But, if the inferior is running, then the
process_stratum target reads from the inferior memory.

This patch fixes the problem by changing the main name code to set
trust-readonly-sections, causing the target stack to read from the
executable instead.

I looked briefly at changing GNAT to emit DW_AT_main_subprogram
instead, but this looks to be pretty involved.

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

Avoid crash with Ada and -fdata-sections

A user noticed that gdb would crash when showing a backtrace.
Investigation showed this to be a crash in the DWARF reader when
handling a "pragma export" symbol.  The bug here is that earlier code
decides to eliminate the symbol, but the export code tries to add it
anyway -- but to a NULL list.

readelf: Add option to display the names of sections referenced by symbols.

  PR 30684
  * readelf.c (extra_sym_info): New variable. (section_name_valid): Also check for filedata being NULL. (section_name_print): Delete. (section_index_real): New function.  Returns true if the given section index references a real section. (print_symbol): Rename to print_sumbol_name. (printable_section_name): Use a rotating array of static buffers for the return string. (printable_section_name_from_index): Merge code from dump_relocations and get_symbol_index_type into here. (long_option_values): Add OPTION_NO_EXTRA_SYM_INFO. (options): Add "extra-sym-info" and "no-extra-sym-info". (usage): Mention new options. (parse_args): Parse new options. (get_symbol_index_type): Delete. (print_dynamic_symbol_size): Rename to print_symbol_size. (print_dynamic_symbol): Rename to print_symbol. (print_symbol_table_heading): New function. (process_symbol_table): Use new function.
  * doc/binutils.texi: Document the new option.
  * NEWS: Mention the new feature.

RISC-V: fold duplicate code in vector_macro()

There's no need to have almost identical code twice. Do away with
M_VMSGEU and instead simply use an unused (for these macros) field to
tell apart both variants.

RISC-V: Add stub support for the 'Svadu' extension

This commit implements support for 'Svadu' extension.  Because it does not
add any instructions or CSRs (but adds bits to existing CSRs), this commit
only adds extension name support and implication to the 'Zicsr' extension.

This is based on the "Hardware Updating of PTE A/D Bits (Svadu)"
specification, version 1.0-rc1 (Frozen):
<https://github.com/riscv/riscv-svadu/releases/tag/v1.0-rc1>

bfd/ChangeLog:

* elfxx-riscv.c (riscv_implicit_subsets): Add implication from
'Svadu' to 'Zicsr'.  (riscv_supported_std_s_ext) Add 'Svadu'.

RISC-V: Fix typo in the testsuite

gas/ChangeLog:

* testsuite/gas/riscv/csr.s: Fix typo. mhcounteren is superseded
by minstretcfg, not mcyclecfg.

RISC-V: Add 'Smcntrpmf' extension and its CSRs

This commit adds now stable and approved 'Smcntrpmf' extension defined by
the RISC-V Cycle and Instret Privilege Mode Filtering specification.

Note that, because mcyclecfg and minstretcfg CSRs conflict with the
privileged specification version 1.9.1, CSRs for this extension are only
enabled on the privileged specification version 1.10 or later.

By checking the base privileged specification, we no longer need to change
the design of base CSR handling.

This is based on the specification version v1.0_rc1 (Frozen):
<https://github.com/riscv/riscv-smcntrpmf/commit/32b752c40d59c1b5e95de83399c1f54be6669163>

bfd/ChangeLog:

* elfxx-riscv.c (riscv_implicit_subsets): Add implication rule from
the new 'Smcntrpmf' extension.  (riscv_supported_std_s_ext): Add
'Smcntrpmf' to the supported S extension list.

gas/ChangeLog:

* config/tc-riscv.c (enum riscv_csr_class): Add new CSR classes
CSR_CLASS_SMCNTRPMF and CSR_CLASS_SMCNTRPMF_32.
(riscv_csr_address): Add handling for new CSR classes.
* testsuite/gas/riscv/csr-dw-regnums.s: Add new CSRs.  Move
"mscounteren" and "mhcounteren" CSRs and note that they are now
aliases.
* testsuite/gas/riscv/csr-dw-regnums.d: Reflect the change.
* testsuite/gas/riscv/csr.s: Add new CSRs.  Move "mscounteren"
and "mhcounteren" CSRs and note that they are now reused for
the 'Smcntrpmf' extension.
* testsuite/gas/riscv/csr-version-1p9p1.d: Reflect the changes of
csr.s.
* testsuite/gas/riscv/csr-version-1p9p1.l: Likewise.
* testsuite/gas/riscv/csr-version-1p10.d: Likewise.
* testsuite/gas/riscv/csr-version-1p10.l: Likewise.
* testsuite/gas/riscv/csr-version-1p11.d: Likewise.
* testsuite/gas/riscv/csr-version-1p11.l: Likewise.
* testsuite/gas/riscv/csr-version-1p12.d: Likewise.
* testsuite/gas/riscv/csr-version-1p12.l: Likewise.

include/ChangeLog:

* opcode/riscv-opc.h: Add new CSRs noting that this extension is
incompatible with the privileged specification version 1.9.1.
Move "mscounteren" and "mhcounteren" CSRs, make them aliases and
reuse the CSR numbers from the 'Smcntrpmf' extension.
(CSR_MSCOUNTEREN, CSR_MHCOUNTEREN) Remove as "mscounteren" and
"mhcounteren" are now aliases and new CSR macros are used instead.
(CSR_MCYCLECFG, CSR_MINSTRETCFG, CSR_MCYCLECFGH, CSR_MINSTRETCFGH):
New CSR macros.

RISC-V: Prohibit combination of 'E' and 'H'

According to the ratified privileged specification (version 20211203),
it says:

> The hypervisor extension depends on an "I" base integer ISA with 32 x
> registers (RV32I or RV64I), not RV32E, which has only 16 x registers.

Also in the latest draft, it also prohibits RV64E with the 'H' extension.
This commit prohibits the combination of 'E' and 'H' extensions.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_parse_check_conflicts): Prohibit 'E' and
'H' combinations.

gas/ChangeLog:

* testsuite/gas/riscv/march-fail-rv32eh.d: New failure test to
make sure that RV32E + 'H' is prohibited.
* testsuite/gas/riscv/march-fail-rv32eh.l: Likewise.

Automatic date update in version.in

arm: Make 'conflicting CPU architectures' error message more user-friendly

Error messages such as "conflicting CPU architectures 10/16" are not
very to understand, so this patch replaces the numbers with the
description they actually mean:
"conflicting CPU architectures ARM v7E-M vs Pre v4"

2023-09-01  Christophe Lyon  <christophe.lyon@linaro.org>

bfd/
* elf32-arm.c (tag_cpu_arch_combine): Add name_table parameter and
use it.
(elf32_arm_merge_eabi_attributes): Update call to
tag_cpu_arch_combine.

ld/
* testsuite/ld-arm/attr-merge-9.out: Update expected error
message.
* testsuite/ld-arm/attr-merge-arch-2.d: Likewise.

[gdb/testsuite] Fix race in gdb.base/add-symbol-file-attach.exp

When running test-case gdb.base/add-symbol-file-attach.exp with target board
unix/-m32, we run into:
...
(gdb) attach 3955^M
Attaching to process 3955^M
Load new symbol table from "add-symbol-file-attach"? (y or n) y^M
Reading symbols from add-symbol-file-attach/add-symbol-file-attach...^M
Reading symbols from /lib/libm.so.6...^M
Reading symbols from /usr/lib/debug/lib/libm-2.31.so-i386.debug...^M
Reading symbols from /lib/libc.so.6...^M
Reading symbols from /usr/lib/debug/lib/libc-2.31.so-i386.debug...^M
Reading symbols from /lib/ld-linux.so.2...^M
Reading symbols from /usr/lib/debug/lib/ld-2.31.so-i386.debug...^M
0xf7f53549 in __kernel_vsyscall ()^M
(gdb) FAIL: gdb.base/add-symbol-file-attach.exp: attach
...

The test fails because this regexp is used:
...
    -re ".*in \[_A-Za-z0-9\]*pause.*$gdb_prompt $" {
...

The regexp attempts to detect that the exec is somewhere in pause ():
...
int
main (int argc, char **argv)
{
  pause ();
  return 0;
}
...
but when the exec is blocked in pause, the backtrace is:
...
 (gdb) bt
 #0  0xf7fd2549 in __kernel_vsyscall ()
 #1  0xf7d84966 in __libc_pause () at ../sysdeps/unix/sysv/linux/pause.c:29
 #2  0x0804844c in main (argc=1, argv=0xffffce84)
     at /data/vries/gdb/src/gdb/testsuite/gdb.base/add-symbol-file-attach.c:26
...

We could simply extend the regexp to also match __kernel_vsyscall, but the
more fundamental problem is that the test is racy.

The attach can happen before the exec is blocked in pause (), somewhere in the
dynamic linker resolving the call to pause, in main or even earlier.

Note that for the test-case to be effective, the exec is not required to be in
pause ().  I added a "while (1);" loop at the start of main, reverted the
patch fixing the corresponding PR and reproduced the problem it's supposed to
detect.

Fix this by simply matching the "Reading symbols from" line, similar to what
an earlier test is doing.

While we're at it, rewrite the earlier test to also use the -wrap idiom.

Tested on x86_64-linux.

Automatic date update in version.in

Automatic date update in version.in

gdbserver: i387_cache_to_xsave: fix copy dest of zmm registers

On a machine with AVX512 support (AMD EPYC 9634), I see these failures:

    $ make check TESTS="gdb.arch/i386-avx512.exp" RUNTESTFLAGS="--target_board=native-gdbserver"
    ...
    FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[16] after writing ZMM regs
    FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[17] after writing ZMM regs
    FAIL: gdb.arch/i386-avx512.exp: check contents of zmm_data[18] after writing ZMM regs
    ...

The problem can be reduced to:

    (gdb) print $zmm16.v8_int64
    $1 = {0, 0, 0, 0, 0, 0, 0, 0}
    (gdb) print $zmm16.v8_int64 = {11,22,33,44,55,66,77,88}
    $2 = {11, 22, 33, 44, 55, 66, 77, 88}
    (gdb) print $zmm16.v8_int64
    $3 = {11, 22, 33, 44, 55, 66, 77, 88}
    (gdb) step
    5               ++x;
    (gdb) print $zmm16.v8_int64
    $4 = {11, 22, 77, 88, 0, 0, 0, 0}

Writing to the local regcache in GDB works fine, but the writeback to
gdbserver (which happens when resuming / stepping) doesn't work (the
code being stepped doesn't touch AVX registers, so we don't expect the
value of zmm16 to change when stepping).

The problem is on the gdbserver side, the zmmh and ymmh portions of the
zmm register are not memcpied at the right place in the xsave buffer.  Fix
that.  Note now how the two modified memcpy calls match the memcmp calls
just above them.

With this patch, gdb.arch/i386-avx512.exp passes completely for me.

Change-Id: I22c417e0f5e88d4bc635a0f08f8817a031c76433
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30818

Automatic date update in version.in

config: Fix host -rdynamic detection for build != host != target

[Merge from GCC commit 4d9bc81a5d8d884dee7a7781fa4c1577a6c9681a.]

The GCC_ENABLE_PLUGINS configure logic for detecting whether -rdynamic
is necessary and supported uses an appropriate objdump for $host
binaries (running on $build) in cases where $host is $build or
$target.

However, it is missing such logic in the case where $host is neither
$build nor $target, resulting in the compilers not being linked with
-rdynamic and plugins not being usable with such a compiler.  In fact
$ac_cv_prog_OBJDUMP, as used when $build = $host, is always an objdump
for $host binaries that runs on $build; that is, it's appropriate to
use in this case as well.

Tested in such a configuration that it does result in cc1 being linked
with -rdynamic as expected.  Also bootstrapped with no regressions for
x86_64-pc-linux-gnu.

config/
* gcc-plugin.m4 (GCC_ENABLE_PLUGINS): Use
export_sym_check="$ac_cv_prog_OBJDUMP -T" also when host is not
build or target.

Fix "usage" errors for some MI varobj commands

I noticed that the "usage" error for -var-set-frozen mentioned the
wrong command name.  Then I looked through the whole file and found a
couple other spots that didn't mention the command name at all.  This
patch fixes all of these.

Reviewed-by: Kevin Buettner <kevinb@redhat.com>

x86: unindent most of set_cpu_arch()

Inverting the initial if()'s condition allows to move out the bulk of
the function by a level, improving readability at least a bit. While
doing that also pull the push/pop handling up first, such that "else if"
after "return" isn't needed anymore; the order in which special cases
are checked doesn't really matter.

x86: rename CpuPCLMUL

The name we use internally isn't in line with the SDM, and also isn't in
line with CpuVPCLMULQDQ. Add the missing suffix, but of course leave
alone user facing names.

x86: correct source used for two non-AVX512 VEXWIG tests

These shouldn't wrongly include the AVX512VL sources. Obviously the
expectations therefore also need to change.

x86: drop Size64 from VMOVQ

Commit 916fae91358d ("Add Size64 to movq/vmovq with Reg64 operand" was
right in adding the attribute to MOVQ, but there was no need to add it
to VMOVQ. (See also the AVX512F form, which doesn't have the attribute
either.)

RISC-V: move various alias entries

For disassembly to only use spec-mandated aliases, respective non-alias
entries need to come ahead of their alias ones. Since identical
mnemonics need to stay together, whole groups are moved up where
necessary.

This partly reverts 839189bc932e ("RISC-V: re-arrange opcode table for
consistent alias handling"), but then also goes beyond a plain revert.

Reviewed-by: Tsukasa OI <research_trasio@irq.a4lg.com>
Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>

Fix ld Makefile variable naming: ELF_CLFAGS -> ELF_CFLAGS

Signed-off-by: Jerry Zhang Jian <jerry.zhangjian@sifive.com>

RISC-V: Fixed the wrong expansion for pseudo vmsge[u].vx instructions.

The original report was from Kiva Oyama <libkernelpanic@gmail.com>,
https://sourceware.org/pipermail/binutils/2023-August/129255.html

The vmsge[u].vx pseudo should be expanded to masked vmslt[u].vx only when
vd != v0.  Otherwise, it should be expanded to unmasked one.

gas/
* config/tc-riscv.c (vector_macro): Fixed the wrong expansion for
pseudo vmsge[u].vx instructions.
* testsuite/gas/riscv/vector-insns-vmsgtvx.d: Updated.

gdb: remove uses of alloca in gdbtypes.c

Replace two uses of alloca with std::string.

Change-Id: I970ae3f450da407494d95668a57bba8796d6292b
Approved-by: Kevin Buettner <kevinb@redhat.com>

Automatic date update in version.in

PR30806, CPPFLAGS are missing for bfd/chew, syslex_wrap and sysinfo

PR 30806
bfd/
* doc/local.mk (doc/chew.stamp): Add CPPFLAGS_FOR_BUILD.
* Makefile.in: Regenerate.
binutils/
* Makefile.am (syslex_wrap.@OBJEXT@): Add CPPFLAGS_FOR_BUILD.
(sysinfo.@OBJEXT@): Likewise.
* Makefile.in: Regenerate.

elf: Adjust PR ld/30791 tests

Adjust PR ld/30791 tests:

1. Generic linker targets don't comply with all orhpan section merging
rules.
2. z80 fails since a, b, c, d are registers for z80.
3. hppa fails since .text sections aren't merged for relocatable link.

PR ld/30791
* testsuite/ld-elf/pr30791a.d: Xfail for generic and z80
targets.
* testsuite/ld-elf/pr30791b.d: Xfail for hppa and z80 targets.

Add symbol::matches method

This adds symbol::matches, a wrapper for symbol_matches_domain.  Most
places calling symbol_matches_domain can call this method instead,
which is a bit less wordy and also (IMO) clearer.

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

gdb: remove TYPE_FIELD_PACKED

Replace with a new equivalent "is_packed" method on struct field.

Change-Id: I78647be3d408b40b63becb6b6f0fca211bede51c
Approved-By: Tom Tromey <tom@tromey.com>

gdb: remove TYPE_FIELD_BITSIZE

Replace with type::field + field::bitsize.

Change-Id: I2a24755a33683e4a2775a6d2a7b7a9ae7362e43a
Approved-By: Tom Tromey <tom@tromey.com>

gdb: remove FIELD_BITSIZE

Replace with field::bitsize.

Change-Id: I400be235d6a1f446d0a4aafac01df5e850185d3a
Approved-By: Tom Tromey <tom@tromey.com>

gdb: introduce field::bitsize / field::set_bitsize

Add these two methods, rename the field to m_bitsize to make it pseudo
private.

Change-Id: Ief95e5cf106e72f2c22ae47b033d0fa47202b413
Approved-By: Tom Tromey <tom@tromey.com>

gdb: remove TYPE_FIELD_ARTIFICIAL

Replace with type::field + field::is_artificial.

Change-Id: Ie3bacae49d9bd02e83e504c1ce01470aba56a081
Approved-By: Tom Tromey <tom@tromey.com>

gdb: remove FIELD_ARTIFICIAL

Replace uses with field::is_artificial.

Change-Id: I599616fdd9f4b6d044de492e8151aa6130725cd1
Approved-By: Tom Tromey <tom@tromey.com>

gdb: introduce field::is_artificial / field::set_is_artificial

Add these two methods, rename the field to m_artificial to make it
pseudo private.

Change-Id: If3a3825473d1d79bb586a8a074b87bba9b43fb1a
Approved-By: Tom Tromey <tom@tromey.com>

Remove eval_op_ternop

eval_op_ternop is only used by the implementation of
ternop_slice_operation.  While working on another series, it was
convenient for me to merge this function into its only caller.

Reviewed-by: Kevin Buettner <kevinb@redhat.com>

[symtab/27831] New test case: gdb.base/add-symbol-file-attach.exp

This commit adds a new test case for bug 27831.  See the contents
of the .exp file for a description of what it's about.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831
Approved-By: Tom Tromey <tom@tromey.com>

[symtab/27831] Fix OBJF_MAINLINE assert

This commit fixes a bug mentioned by Florian Weimer during the
libpthread/ld.so load order discussion from 2021.  Florian provided
instructions for reproducing the bug here:

https://sourceware.org/pipermail/gdb-patches/2021-April/177923.html

That particular test does some interesting things involving forks,
threads, and thread local storage.  Fortunately, none of that is
needed to reproduce the problem.

I've made a new test case (which is now found in a separate commit)
contained in the files gdb.base/add-symbol-file-attach.{c,exp}.  The
.c file is fairly simple as is the recipe for reproducing the problem.

After separately starting the test case and noting the process id,
start gdb (w/ no arguments), and do the following to reproduce the
assertion failure - for this run, the process id of the separately
started add-symbol-file-attach process is 4103218:

(gdb) add-symbol-file add-symbol-file-attach
add symbol table from file "add-symbol-file-attach"
(y or n) y
Reading symbols from add-symbol-file-attach...
(gdb) attach 4103218
Attaching to process 4103218
Load new symbol table from "/tmp/add-symbol-file-attach"? (y or n) y
Reading symbols from /tmp/add-symbol-file-attach...
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007f502130bf27 in pause () from /lib64/libc.so.6
(gdb) p foo
symtab.c:6417: internal-error: CORE_ADDR get_msymbol_address(objfile*,
  const minimal_symbol*): Assertion `(objf->flags & OBJF_MAINLINE) == 0'
  failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

The add-symbol-file command causes the symbols to be loaded without
the SYMFILE_MAINLINE (and hence the OBJFILE_MAINLINE) flags being
set.  This, in turn, causes the "maybe_copied" flag to be set for
the global symbol (named "foo" in the provided test case).

The attach command will cause another objfile to be created, but
it will reuse the symtabs from the objfile created by add-symbol-file,
leading to a situation in which the OBJFILE_MAINLINE flag will be set
for the new (attach-created) objfile, however the "maybe_copied"
flag will still be set for the global symbol.  Had it been loaded
anew, this flag would not be set due to OBJFILE_MAINLINE being set
for the objfile.

At present, minimal_symbol::value_address looks like this:

CORE_ADDR
minimal_symbol::value_address (objfile *objfile) const
{
  if (this->maybe_copied (objfile))
    return get_msymbol_address (objfile, this);
  else
    return (CORE_ADDR (this->unrelocated_address ())
    + objfile->section_offsets[this->section_index ()]);
}

So, we can now see the problem: When the "maybe_copied" flag is set,
get_msymbol_address() will be called.  However, get_msymbol_address()
assumes that it won't be called with the OBF_MAINLINE flag set for
the objfile in question.  It, in fact, contains an assert() which
makes sure that this is the case:

  gdb_assert ((objf->flags & OBJF_MAINLINE) == 0);

(If this assert is removed, then get_msymbol_address() recurses
infinitely for the case under consideration.)

So, the problem here is that the maybe_copied flag is set for the
symbol AND the OBJF_MAINLINE flag is set for the objfile.  As noted
earlier, this happens due to add-symbol-file being used; this causes
the maybe_copied flag to be set.  Later, when the attach is performed,
OBJF_MAINLINE will be set for that objfile, leading to this
unfortunate situation.

My first cut at a solution involved adjusting the
MSYMBOL_VALUE_ADDRESS macro (which has since been changed to be the
method noted above) to include a test of the OBJFILE_MAINLINE flag.
However, Simon Marchi, in his review of my patch, suggested a better
solution.  Simon observed that the 'maybe_copied' flag is (was, after
this commit) being set/initialized in record_minimal_symbol() using
using the objfile in the context in which the symbol was created.

Simon further observed:

  Today, a single copy is created, as symtabs are shared between
  objfiles.  This means that everything that we store into a symbol
  must be independent of any objfile.  However, the value of the
  maybe_copied field is dependent on the objfile in the context of
  which the symbol was created.  Meaning that when the symbol is
  re-used in the context of another objfile, the maybe_copied value is
  not right in the context of that objfile.

  So I think it means there isn't a single "is this symbol maybe
  copied" value, but instead "is this symbol maybe copied, in the
  context of this given objfile".  And the answer is yes or no,
  depending on whether the objfile is mainline.  So maybe_copied
  should become a method that takes an objfile and returns an answer
  based on that.

Simon's full review can be found here:

  https://sourceware.org/pipermail/gdb-patches/2021-May/178855.html

Simon also provided a patch which implements this suggestion.  The
current patch is mostly his work, though I did make some adjustments
during a rebase in addition to making some changes to account for a
concern from Tom Tromey.

During his review of the v3 series, Tom noted, "The old approach was
specific to ELF, while the new approach will be used by any object
format." Tom further observed, "...it seems like it could result in an
incorrect evaluation in some scenario."  This seemed plausible to me,
so I introduced the flag 'object_format_has_copy_relocs' to struct
objfile.  It is set at the end of elf_symfile_read() in elfread.c.
The minimal_symbol::maybe_copied method tests this new flag, forcing
this method to return false when the flag is not set.  If we find that
other object file formats use the same copy reloc mechanism as ELF,
then 'object_format_has_copy_relocs' should be set for objfiles using
those formats.

Lastly, I'll note that this is a strange use case.  It's far more
common to either let gdb figure out which file to load by itself when
attaching, i.e.

(gdb) attach 4104360
Attaching to process 4104360
Reading symbols from /tmp/add-symbol-file-attach...
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6
(gdb) p foo
$1 = 42

...or to use the "file" command prior to the attach, like this:

(gdb) file add-symbol-file-attach
Reading symbols from add-symbol-file-attach...
(gdb) attach 4104360
Attaching to program: /tmp/add-symbol-file-attach, process 4104360
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6

Both of these more common scenarios work perfectly fine; using
"add-symbol-file" to load the program to which you will attach
isn't recommended as a normal use case.  That said, it's bad for
gdb to assert, hence this fix.

Reviewed-by: Simon Marchi <simon.marchi@polymtl.ca>
Co-Authored-by: Simon Marchi <simon.marchi@polymtl.ca>
Approved-by: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831

Unify DW_TAG_typedef case in new_symbol

This patch merges the DW_TAG_typedef case in new_symbol with some
other type-related cases.  These all have identical code.

Reviewed-By: Guinevere Larsen <blarsen@redhat.com>

Revert "Simplify @node use in BFD documentation"

This reverts commit 8bb23cdbb498ff645bb0937bc8c0cb89e9e5ebd8.

My earlier patch to simplifify the @node uses in the BFD manual didn't
take into account (1) that BFD doesn't use the ordinary texinfo
sectioning commands, and (2) that some users are stuck on very ancient
versions of makeinfo.

This patch reverts the change.

I went through the entire manual using the spacebar, trying to find
the original problem I reported in the change, but couldn't.  I don't
know why.  Anyway, all this means is that, with this reversion,
editing the node structure will be slightly less convenient.

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

2023-08-30  Tom Tromey  <tom@tromey.com>

PR binutils/30703
* doc/webassembly.texi, doc/bfd.texi: Revert 8bb23cdb, adding
parameters back to @node.

[gdb/contrib] Require minimal dwz version in cc-with-tweaks.sh

I usually run target boards cc-with-dwz and cc-with-dwz-m using a dwz build
from current trunk, but the pathname to the build dir changed and I forgot to
update my test scripts, so the test scripts reverted to using system dwz,
version 0.12.

Consequently, I ran into:
...
(gdb) p ZERO^M
No symbol "ZERO" in current context.^M
(gdb) FAIL: gdb.base/enumval.exp: p ZERO
...
which is due to PR dwz/24468, which was fixed in version 0.13.

Fix this by minimally requiring dwz version 0.13 in cc-with-tweaks.sh, such
that this situation is detected and we get instead:
...
gdb compile failed, cc-with-tweaks.sh: dwz version 0.12 detected, version \
  0.13 or higher required
...

Tested on x86_64-linux, verified with shellcheck.

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

vms-alpha: Free memory on failure path

* vms-alpha.c (evax_bfd_print_eobj): Free rec on failure.

gas init_stab_section and get_stab_string_offset

get_stab_string_offset currently creates the stabstr section if not
already present, in the process keeping a reference to the malloc'd
section name string.  Really, the name belongs in bfd_alloc'd memory
or some obstack so that it doesn't show as a memory leak on exit.
s_stab_generic at least does allocate the name for the stab section on
an obstack, but doesn't tidy that as well as it could.  Return paths
after issuing a warning don't release the memory, nor the memory for
the "string" copy.

This patch fixes these problems.  s_stab_generic is rearranged so that
creation of the sections occurs earlier, before any potential uses of
the note obstack during expression parsing.  That makes it possible to
always free the section name strings unless used to create new
sections.  I've also avoided get_absolute_expression_and_terminator
as I see that function might skip over end-of-line, and lack of a
--input_line_pointer might have caused the following source line to be
ignored.  (Other uses of this function in gas are OK.)

* config/obj-coff.c (obj_coff_init_stab_section): Add stabstr
param.  Pass to get_stab_string_offset rather than name of
section.
* config/obj-som.c (obj_som_init_stab_section): Likewise.
* config/obj-elf.c (obj_elf_init_stab_section): Likewise.
(elf_init_stab_section): Adjust.
* config/obj-coff.h (INIT_STAB_SECTION): Update.
(obj_coff_init_stab_section): Update prototype.
* config/obj-som.h: Similarly.
* config/obj-elf.h: Similarly.
* config/obj-multi.h (INIT_STAB_SECTION): Update.
* obj.h (struct format_ops <init_stab_section>): Update.
* read.h (get_stab_string_offset): Update prototype.
* stabs.c (cached_sec): Delete.
(stabs_begin): Adjust to suit.
(get_stab_string_offset): Add stabstr param, delete stabstr_name
and free_stabstr_secname params.  Don't make stabstr section
here.
(eat_comma): New function.
(s_stab_generic): Replace stab_secname_obstack_end param with
bool freenames.  Move creation of stab and stabstr sections
earlier, so the names can be freed earlier before possible use
of notes obstack during expression parsing.  Tidy error paths
ensuring "string" is freed.  Use get_absolute_expression in
place of get_absolute_expression_and_terminator.
(s_stab): Adjust.
(s_xstab): Use notes_concat to make stabstr section name.

gas OBJ_PROCESS_STAB

This macro and the supporting functions have an unused "seg" first
argument.  Tidy that.

* config/obj-aout.c (obj_aout_process_stab): Delete first param.
* config/obj-ecoff.h (OBJ_PROCESS_STAB): Likewise.
* config/obj-elf.c (elf_process_stab): Likewise.
* config/obj-elf.h (OBJ_PROCESS_STAB): Likewise.
* config/obj-macho.h (OBJ_PROCESS_STAB): Likewise.
* config/obj-multi.h (OBJ_PROCESS_STAB): Likewise.
* ecoff.c (ecoff_stab): Likewise.
* ecoff.h (ecoff_stab): Likewise.
* obj.h (struct format_ops <process_stab>): Likewise.
* stabs.c (OBJ_PROCESS_STAB): Likewise.

[gdb/symtab] Replace TYPE_ALLOC with TYPE_ZALLOC where required

Handle the remaining uses of TYPE_ALLOC, either by:
- replacing with TYPE_ZALLOC, or
- adding a comment explaining why zero-initialization is not necessary.

Tested on x86_64-linux.

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

[gdb/symtab] Replace TYPE_ALLOC + B_CLRALL with TYPE_ZALLOC

I noticed some cases of TYPE_ALLOC followed by B_CLRALL.

Replace these with TYPE_ZALLOC.

Tested on x86_64-linux.

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

[gdb/symtab] Replace TYPE_ALLOC + memset with TYPE_ZALLOC

I noticed a case of TYPE_ALLOC followed by memset.

Replace this with TYPE_ZALLOC.

Tested on x86_64-linux.

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

[gdb/symtab] Do more zero-initialization of type::fields

Now that we've introduced type::{alloc_fields,copy_fields}, the places where
no zero-initialization of allocated fields is done are easy to spot:
...
$ find gdb* -type f | grep -v ChangeLog | xargs grep alloc_fields | grep false
gdb/coffread.c:  type->alloc_fields (nfields, false);
gdb/coffread.c:  type->alloc_fields (nsyms, false);
gdb/stabsread.c:   ftype->alloc_fields (nsemi, false);
gdb/gdbtypes.c:  resolved_type->alloc_fields (nfields, false);
gdb/gdbtypes.c:  alloc_fields (nfields, false);
gdb/gdbtypes.c:  alloc_fields (nfields, false);
gdb/mdebugread.c: t->alloc_fields (nfields, false);
gdb/mdebugread.c:   ftype->alloc_fields (nparams, false);
...

All hits in gdbtypes.c are ok.  There are two hits in the two variants of
copy_fields, and there's already a comment for the third.

AFAICT, the other ones are not ok, so fix those by dropping the "false"
argument.

Tested on x86_64-linux.

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

[gdb/symtab] Factor out type::{alloc_fields,copy_fields}

After finding this code in buildsym_compunit::finish_block_internal:
...
              ftype->set_fields
                ((struct field *)
                 TYPE_ALLOC (ftype, nparams * sizeof (struct field)));
...
and fixing PR30810 by using TYPE_ZALLOC, I wondered if there were more
locations that needed fixing.

I decided to make things easier to spot by factoring out a new function
alloc_fields:
...
 /* Allocate the fields array of this type, with NFIELDS elements.  If INIT,
     zero-initialize the allocated memory.  */
  void
  type::alloc_fields (unsigned int nfields, bool init = true);
...
where:
- a regular use would be "alloc_fields (nfields)", and
- an exceptional use that needed no initialization would be
  "alloc_fields (nfields, false)".

Pretty soon I discovered that most of the latter cases are due to
initialization by memcpy, so I added two variants of copy_fields as well.

After this rewrite there are 8 uses of set_fields left:
...
gdb/coffread.c:   type->set_fields (nullptr);
gdb/coffread.c:   type->set_fields (nullptr);
gdb/coffread.c:   type->set_fields (nullptr);
gdb/eval.c:  type->set_fields
gdb/gdbtypes.c:  type->set_fields (args);
gdb/gdbtypes.c:  t->set_fields (XRESIZEVEC (struct field, t->fields (),
gdb/dwarf2/read.c:      type->set_fields (new_fields);
gdb/dwarf2/read.c:       sub_type->set_fields (sub_type->fields () + 1);
...

These fall into the following categories:
- set to nullptr (coffread.c),
- type not owned by objfile or gdbarch (eval.c), and
- modifying an existing fields array, like adding an element at the end or
  dropping an element at the start (the rest).

Tested on x86_64-linux.

[gdb/symtab] Fix uninitialized memory in buildsym_compunit::finish_block_internal

When running test-case gdb.dwarf2/per-bfd-sharing.exp with target board stabs,
gdb either segfaults or asserts due to reading uninitialized memory, allocated
here in buildsym_compunit::finish_block_internal:
...
      ftype->set_fields
((struct field *)
 TYPE_ALLOC (ftype, nparams * sizeof (struct field)));
...

Fix this by using TYPE_ZALLOC instead.

Tested on x86_64-linux.

Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30810
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30810

arc: Update elfarcv2 script template

Update ARC's elfarcv2 script template with:

- The .ivt section (Interrupt Vector Table) is mapped at the begining
  of STARTUP_MEMORY when ivtbase_addr is not defined. Previously, it
  was pointing to 0x00.

- MEMORY_FILE is a new emulation paramter and sets the name for the
  linker script file which holds the MEMORY commands required by
  arcv2elfx emulation.

- Four new linker variables are introduced available when arcv2elf emulation is used:
  * __TEXT_REGION_ORIGIN__ Once defined it is setting the text region origin. By default it points to zero.
  * __TEXT_REGION_LENGTH__ Once defined it is setting the text region length. By default it is set to 2M.
  * __DATA_REGION_ORIGIN__ Once defined it is setting the data region origin. By default it is set to 0x80000000.
  * __DATA_REGION_LENGTH__ Once defined it is setting the data region length. By default it is set to 2M.

ld/ChangeLog:

* scripttempl/elfarcv2.sc: Update script template.

Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>

elf: Don't merge sections with different SHF_LINK_ORDER

For relocatable link, don't merge 2 SHF_LINK_ORDER sections if output
sections of their linked to sections are different.

* ldelf.c (elf_orphan_compatible): Don't merge sections with
different SHF_LINK_ORDER.
* testsuite/ld-elf/pr30791a.d: New file.
* testsuite/ld-elf/pr30791a.s: Likewise.
* testsuite/ld-elf/pr30791b.d: Likewise.
* testsuite/ld-elf/pr30791b.s: Likewise.
* testsuite/ld-elf/pr30791c.s: Likewise.
* testsuite/ld-elf/pr30791d.s: Likewise.

elf: Check DT_SYMTAB only on non-IR object

Check DT_SYMTAB only on non-IR object of archive member to avoid crash
on LLVM IR object with NULL elf_tdata.

PR ld/30811
* elflink.c (elf_link_is_defined_archive_symbol): Check
DT_SYMTAB only on non-IR object.

Automatic date update in version.in

libbfd.texi zero size

Pattern rules in doc/local.mk exist that specify how to make
libbfd.texi from libfd.h or libbfd.c.  Since both files exist and the
libbfd.h rule is first, libbfd.h is used.  libbfd.h doesn't contain
the documentation..

* doc/local.mk (doc/%stamp): Put rule making this from %.c
before %.h rule.
* Makefile.in: Regenerate.
* libbfd.c (Byte swapping routines): Don't omit description.

DEFAULT_BUFFERSIZE

There isn't any reason to think that a particular buffer size is
ideal in bfd, so let's just not define it.

* libbfd-in.h (DEFAULT_BUFFERSIZE): Don't define.
* libbfd.h: Regenerate.
* archive.c (AR_WRITE_BUFFERSIZE): Substitute value.
* vms-lib.c (_bfd_vms_lib_write_archive_contents): Likewise.
* coff-rs6000.c (do_copy): Likewise, and use sizeof.

[gdb/testsuite] Fix gdb.dwarf2/nullptr_t.exp with cc-with-dwz-m

When running test-case gdb.dwarf2/nullptr_t.exp with target board
cc-with-dwz-m, I run into:
...
FAIL: gdb.dwarf2/nullptr_t.exp: decltype(nullptr) symbol
...

The problem is that were looking for "typedef void decltype\\(nullptr\\)"
using "maint print symbols -source $srcfile", but dwz has moved the typedef to
a PU, so it's shown by "maint print symbols -source <unknown>" instead.

Fix this by dropping the "-source $srcfile" bit.

Tested on x86_64-linux, with make-check-all.sh.

gdb: simplify vector construction in eval_op_rust_array

Replace the manual fill of the vector with the appropriate std::vector
constructor that makes N copies of the provided value.

Change-Id: I579570748c48f53d35024105269d83c716294746
Approved-By: Tom Tromey <tom@tromey.com>