Automatic date update in version.in

Throw error when creating an overly large gdb-index file

The header in a .gdb_index section uses 32-bit unsigned offsets to
refer to other areas of the section.  Thus, there is a size limit of
2^32-1 which is currently unaccounted for by GDB's code for outputting
these sections.

At the moment, when GDB creates an overly large section, it will exit
abnormally due to an internal error, which is caused by a failed
assert in assert_file_size, which in turn is called from
write_gdbindex_1, both of which are in gdb/dwarf2/index-write.c.

This is what happens when that assert fails:

$ gdb -q -nx -iex 'set auto-load no' -iex 'set debuginfod enabled off' -ex file ./libgraph_tool_inference.so -ex "save gdb-index `pwd`/"
Reading symbols from ./libgraph_tool_inference.so...
No executable file now.
Discard symbol table from `libgraph_tool_inference.so'? (y or n) n
Not confirmed.
../../gdb/dwarf2/index-write.c:1069: internal-error: assert_file_size: Assertion `file_size == expected_size' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
0x55fddb4d78b0 gdb_internal_backtrace_1
../../gdb/bt-utils.c:122
0x55fddb4d78b0 _Z22gdb_internal_backtracev
../../gdb/bt-utils.c:168
0x55fddb98b5d4 internal_vproblem
../../gdb/utils.c:396
0x55fddb98b8de _Z15internal_verrorPKciS0_P13__va_list_tag
../../gdb/utils.c:476
0x55fddbb71654 _Z18internal_error_locPKciS0_z
../../gdbsupport/errors.cc:58
0x55fddb5a0f23 assert_file_size
../../gdb/dwarf2/index-write.c:1069
0x55fddb5a1ee0 assert_file_size
/usr/include/c++/13/bits/stl_iterator.h:1158
0x55fddb5a1ee0 write_gdbindex_1
../../gdb/dwarf2/index-write.c:1119
0x55fddb5a51be write_gdbindex
../../gdb/dwarf2/index-write.c:1273
[...]
---------------------
../../gdb/dwarf2/index-write.c:1069: internal-error: assert_file_size: Assertion `file_size == expected_size' failed.

This problem was encountered while building the python-graph-tool
package on Fedora.  The Fedora bugzilla bug can be found here:

https://bugzilla.redhat.com/show_bug.cgi?id=1773651

This commit prevents the internal error from occurring by calling error()
when the file size exceeds 2^32-1.

Using a gdb built with this commit, I now see this behavior instead:

$ gdb -q -nx -iex 'set auto-load no' -iex 'set debuginfod enabled off' -ex file ./libgraph_tool_inference.so -ex "save gdb-index `pwd`/"
Reading symbols from ./libgraph_tool_inference.so...
No executable file now.
Discard symbol table from `/mesquite2/fedora-bugs/1773651/libgraph_tool_inference.so'? (y or n) n
Not confirmed.
Error while writing index for `/mesquite2/fedora-bugs/1773651/libgraph_tool_inference.so': gdb-index maximum file size of 4294967295 exceeded
(gdb)

I wish I could provide a test case, but due to the sizes of both the
input and output files, I think that testing resources would be
strained or exceeded in many environments.

My testing on Fedora 38 shows no regressions.

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

gdb: fix buffer overflow in DWARF reader

In this commit:

  commit 48ac197b0c209ccf1f2de9704eb6cdf7c5c73a8e
  Date:   Fri Nov 19 10:12:44 2021 -0700

      Handle multiple addresses in call_site_target

a buffer overflow bug was introduced when the following code was
added:

  CORE_ADDR *saved = XOBNEWVAR (&objfile->objfile_obstack, CORE_ADDR,
                                addresses.size ());
  std::copy (addresses.begin (), addresses.end (), saved);

The definition of XOBNEWVAR is (from libiberty.h):

  #define XOBNEWVAR(O, T, S) ((T *) obstack_alloc ((O), (S)))

So 'saved' is going to point to addresses.size () bytes of memory,
however, the std::copy will write addresses.size () number of
CORE_ADDR sized entries to the address pointed to by 'saved', this is
going to result in memory corruption.

The mistake is that we should have used XOBNEWVEC, which allocates a
vector of entries, the definition of XOBNEWVEC is:

  #define XOBNEWVEC(O, T, N) \
    ((T *) obstack_alloc ((O), sizeof (T) * (N)))

Which means we will have set aside enough space to create a copy of
the contents of the addresses vector.

I'm not sure how to create a test for this problem, this issue cropped
up when debugging a particular i686 built binary, which just happened
to trigger a glibc assertion (likely due to random memory corruption),
debugging the same binary built for x86-64 appeared to work just fine.

Using valgrind on the failing GDB binary pointed straight to the cause
of the problem, and with this patch in place there are no longer
valgrind errors in this area.

If anyone has ideas for a test I'm happy to work on something.

Co-Authored-By: Keith Seitz <keiths@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>

[gdb/exp] Clean up asap in value_print_array_elements

I've been running the test-suite on an i686-linux laptop with 1GB of memory,
and 1 GB of swap, and noticed problems after running gdb.base/huge.exp: gdb
not being able to spawn for a large number of test-cases afterwards.

So I investigated the memory usage, on my usual x86_64-linux development
platform.

The test-case is compiled with -DCRASH_GDB=2097152, so this:
...
static int a[CRASH_GDB], b[CRASH_GDB];
...
with sizeof (int) == 4 represents two arrays of 8MB each.

Say we add a loop around the "print a" command and print space usage
statistics:
...
gdb_test "maint set per-command space on"
for {set i 0} {$i < 100} {incr i} {
    gdb_test "print a"
}
...

This gets us:
...
(gdb) print a^M
$1 = {0 <repeats 2097152 times>}^M
Space used: 478248960 (+469356544 for this command)^M
(gdb) print a^M
$2 = {0 <repeats 2097152 times>}^M
Space used: 486629376 (+8380416 for this command)^M
(gdb) print a^M
$3 = {0 <repeats 2097152 times>}^M
Space used: 495009792 (+8380416 for this command)^M
  ...
(gdb) print a^M
$100 = {0 <repeats 2097152 times>}^M
Space used: 1308721152 (+8380416 for this command)^M
...

In other words, we start out at 8MB, and the first print costs us about 469MB,
and subsequent prints 8MB, which accumulates to 1.3 GB usage. [ On the
i686-linux laptop, the first print costs us 335MB. ]

The subsequent 8MBs are consistent with the values being saved into the value
history, but the usage for the initial print seems somewhat excessive.

There is a PR open about needing sparse representation of large arrays
(PR8819), but this memory usage points to an independent problem.

The function value_print_array_elements contains a scoped_value_mark to free
allocated values in the outer loop, but it doesn't prevent the inner loop from
allocating a lot of values.

Fix this by adding a scoped_value_mark in the inner loop, after which we have:
...
(gdb) print a^M
$1 = {0 <repeats 2097152 times>}^M
Space used: 8892416 (+0 for this command)^M
(gdb) print a^M
$2 = {0 <repeats 2097152 times>}^M
Space used: 8892416 (+0 for this command)^M
(gdb) print a^M
$3 = {0 <repeats 2097152 times>}^M
Space used: 8892416 (+0 for this command)^M
  ...
(gdb) print a^M
$100 = {0 <repeats 2097152 times>}^M
Space used: 8892416 (+0 for this command)^M
...

Note that the +0 here just means that the mallocs did not trigger an sbrk.
This is dependent on malloc (which can use either mmap or sbrk or some
pre-allocated memory) and will likely vary between different tunings, versions
and implementations, so this does not give us a reliable way detect the
problem in a minimal way.

A more reliable way of detecting the problem is:
...
 void
 value_free_to_mark (const struct value *mark)
 {
+  size_t before = all_values.size ();
   auto iter = std::find (all_values.begin (), all_values.end (), mark);
   if (iter == all_values.end ())
     all_values.clear ();
   else
     all_values.erase (iter + 1, all_values.end ());
+  size_t after = all_values.size ();
+  if (before - after >= 1024)
+    fprintf (stderr, "value_free_to_mark freed %zu items\n", before - after);
...
which without the fix tells us:
...
+print a
value_free_to_mark freed 2097152 items
$1 = {0 <repeats 2097152 times>}
...

Fix a similar problem for Fortran:
...
+print array1
value_free_to_mark freed 4194303 items
$1 = (0, <repeats 2097152 times>)
...
in fortran_array_printer_impl::process_element.

The problem also exists for Ada:
...
+print Arr
value_free_to_mark freed 2097152 items
$1 = (0 <repeats 2097152 times>)
...
but is fixed by the fix for C.

Add Fortran and Ada variants of the test-case.  The *.exp files are similar
enough to the original to keep the copyright years range.

While writing the Fortran test-case, I ran into needing an additional print
setting to print the entire array in repeat form, filed as PR exp/30817.

I managed to apply the compilation loop for the Ada variant as well, but with
a cumbersome repetition style.  I noticed no other test-case uses gnateD, so
perhaps there's a better way of implementing this.

The regression test included in the patch is formulated in its weakest
form, to avoid false positive FAILs, which also means that smaller regressions
may not get detected.

Tested on x86_64-linux.

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

[gdb/testsuite] Modernize gdb.base/huge.exp

Rewrite test-case gdb.base/huge.exp:
- use build_executable rather than gdb_compile,
- use save_vars,
- factor out hardcoded loop limits min and max,
- handle compilation failure using require, and
- avoid using . in regexp to match $, {} and <>.

Tested on x86_64-linux.

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

x86: Vxy naming correction

Looking at the VEX and EVEX forms of vcvtneps2bf16 I noticed that
operand purpose isn't properly reflected in Vxy's definition. Rename
"dst" to "src", thus bringing things in line with Exy.

x86: support AVX10.1 vector size restrictions

Recognize "/<number>" suffixes on both -march=+avx10.1 and the
corresponding .arch directive, setting an upper bound on the vector size
that insns may use. Such a restriction can be reset by setting a new base
architecture, by using a suffix-less form, by disabling AVX10, or by
enabling any other VEX/EVEX-based vector extension.

While for most insns we can suppress their use with too wide operands
via registers becoming unavailable (or in Intel syntax memory operand
size specifiers not being recognized), mask register insns have to have
their minimum required vector size specified in a new attribute. (Of
course this new attribute could also be used on other insns.)

Note that .insn continues to be permitted to emit EVEX{512,256} (and
VEX256 ones) encodings regardless of vector size restrictions in place.
Of course these can't be expressed using zmm (or ymm) operands then,
but need using the EVEX.512.* forms (broadcast forms may be usable right
now, but this may go away so shouldn't be relied upon). This is why no
assertions should be added to build_{e,}vex_prefix().

x86: support AVX10.1/512

Since this is merely a re-branding of certain AVX512* features, there's
little code to be added.

The main aspect here are new testcases. In order to be able to re-use
some of the existing testcases, several of them need their start symbols
adjusted. Note that 256- and 128-bit tests want adding here, as these
need to work right away. Subsequently they'll gain vector length
constraints.

Since it was missing and is wanted here, also add an AVX512VL+VPOPCNTDQ
test.

x86: make AES/PCMULQDQ respectively prereqs of VAES/VPCMULQDQ

These probably should have been put in place already anyway, but they're
very much wanted in order to then put AVX10.1 support on top. Note that
to avoid reverse dependencies towards SSE (just like we already do for
AVX and XOP), add_isa_dependencies() needs some further tweaking.

While there also address a related anomaly: Disabling AES but neither
AVX nor VAES (similarly for {,V}PCLMULQDQ) would better keep the 128-bit
VEX-encoded forms available. Note that for this the VAES insns are moved
past the AVX+AES ones, to avoid the property-11 test suddenly failing.
The test really is wrong, but let's not also make things inconsistent:
Without the movement, YMM use would be correctly recorded for the
128-bit forms simply because the first template already matches, as long
as VAES wasn't disabled.  Yet it still wouldn't be if only AVX+AES were
enabled. Nor would behavior here then be the same as for VPCLMUL* insns.

Automatic date update in version.in

Fix: "Missing NULL check"

  * elf.c (_bfd_elf_init_reloc_shdr): Don't segfault on alloc fail.

Fix: "Possible Memory leak in bed hash.c"

  * elf-strtab.c (_bfd_elf_strtab_init): In the event of memory allocation failure, make sure that the hash table is freed.

Automatic date update in version.in

gdb/mi: remove warning about mi1

Remove a warning about mi1.  mi1 was removed in 975249ff4e26 ("Remove MI
version 1").  It is no longer possible to reach this warning, since
trying to use interpreter mi1 bails out before:

    $ ./gdb -nx -q --data-directory=data-directory -i mi1
    Interpreter `mi1' unrecognized

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

Avoid spurious breakpoint-setting failure in DAP

A user pointed out that if a DAP setBreakpoints request has a 'source'
field in a SourceBreakpoint object, then the gdb DAP implementation
will throw an exception.

While SourceBreakpoint does not allow 'source' in the spec, it seems
better to me to accept it.  I don't think we should fully go down the
"Postel's Law" path -- after all, we have the type-checker -- but at
the same time, if we do send errors, they should be intentional and
not artifacts of the implementation.

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

gdb: Fix -Wuninitialized issue

I see the following warning when building GDB on FreeBSD/amd64 with
Clang 14,

======================================================================
  CXX    mdebugread.o
mdebugread.c:1069:3: error: variable 'f' is uninitialized when used here [-Werror,-Wuninitialized]
                f->set_loc_enumval (tsym.value);
                ^
mdebugread.c:836:17: note: initialize the variable 'f' to silence this warning
        struct field *f;
                       ^
                        = nullptr
======================================================================

after digging a little, I realized that we can not simply do what
Clang 14 says.

The root cause of this issue is that we lost the initialization of
the variable 'f' in this commit,

  commit 2774f2dad5f05e68771c07df6ab0fb23baa2118e
  Date:   Thu Aug 31 09:37:44 2023 +0200

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

we have made these modifications,

 ---------------------------------------------------------------------
 --- a/gdb/mdebugread.c
 +++ b/gdb/mdebugread.c
 @@ -1034,9 +1034,7 @@ parse_symbol (SYMR *sh, union aux_ext *ax, char *ext_sh, int bigend,

         t->set_code (type_code);
         t->set_length (sh->value);
 -       t->set_num_fields (nfields);
 -       f = ((struct field *) TYPE_ALLOC (t, nfields * sizeof (struct field)));
 -       t->set_fields (f);
 +       t->alloc_fields (nfields, false);
 ---------------------------------------------------------------------

The problem is that the variable 'f' is used in the second half of
parse_symbol, that's why Clang complained.

To fix this issue we need to ensure that the varibale 'f' is
initialized.  Calling the fields method is an obvious way to fix this
issue.

Tested on FreeBSD/amd64 by rebuilding.

Approved-By: Tom de Vries <tdevries@suse.de>

gdb/testsuite/rocm: fix rocm-multi-inferior-gpu.cpp

The gdb/testsuite/gdb.rocm/multi-inferior-gpu.cpp testcase contains a
call to execl which does not have NULL as a last argument.  This is
an invalid use of execl.  This patch fixes this oversight.

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

Automatic date update in version.in

Specialize std::hash for ptid_t

This changes hash_ptid to instead be a specialization of std::hash.
This makes it a little easier to use with standard containers.

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

Update Python signal-handling documentation

I noticed a typo in the "Basic Python" node, and when fixing it
realized that the paragraph could use a link to the block_signals
function.  This patch is the result.

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

gdb/testsuite: use foreach_with_prefix in gdb.guile/scm-ports.exp

Simplify things a bit using foreach_with_prefix.  The only expected
change is in the naming of tests.

Change-Id: Icb5e55207e0209e0d44d9e7c16a2f5e11aa29017
Approved-By: Andrew Burgess <aburgess@redhat.com>

testsuite, fortran: Fix regression due to fix for ifort's 'start' behavior

Got a regression email due to merge of commit in CI config
tcwg_gdb_check/master-aarch64 :
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=41439185cd0075bbb1aedf9665685dba0827cfec

Begining of test "gdb.fortran/array-slices-bad.exp" was updated in above
commit to start the test from running to line with tag "First Breakpoint"
instead of "fortran_runto_main".  Reason of the regression is shared
libraries are still loaded after hitting the breakpoint as "nosharedlibrary"
is already called before hitting the breakpoint.

So now after this change test is updated accordingly to disable and unload
shared libraries symbols after hitting the first breakpoint.

Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: c++ify btrace_target_info

Following the example of private_thread_info and private_inferior, turn
struct btrace_target_info into a small class hierarchy.

Also merge btrace_tinfo_bts with btrace_tinfo_pt and inline into
linux_btrace_target_info.

Fixes PR gdb/30751.

gdb, btrace: move xml parsing into remote.c

The code is only used in remote.c and all functions can be declared static.

gdb/testsuite: fix gdb.arch/amd64-init-x87-values.exp on AMD CPUs

I see the following failure when running this test on an AMD machine:

    p/x $fioff^M
    $24 = 0x0^M
    (gdb) FAIL: gdb.arch/amd64-init-x87-values.exp: check_x87_regs_around_init: check post FLD1 value of $fioff

The register that GDB calls fioff normally contains the address of the
last instruction executed by the x87 unit.  It is available through the
FSAVE/FXSAVE/XSAVE instructions, at offset 0x8 of the FSAVE/FXSAVE/XSAVE
area.  You can read about it in the Intel manual [1] at section "10.5.1
FXSAVE Area" (and equivalent sections for FSAVE and XSAVE) or in the AMD
manual [2] at section "11.4.4 Saving Media and x87 Execution Unit
State".

The test therefore expects that after executing the FLD1 instruction,
the fioff register contains the address of the FLD1 instruction.

However, the FXSAVE and XSAVE instructions (which the kernel uses to
dump x87 register state which it provides GDB through ptrace) behave
differently on AMD CPUs.  In section "11.4.4.3 FXSAVE and FXRSTOR
Instructions" of the AMD manual, we read:

    The FXSAVE and FXRSTOR instructions save and restore the entire
    128-bit media, 64-bit media, and x87 state. These instructions
    usually execute faster than FSAVE/FNSAVE and FRSTOR because they do
    not normally save and restore the x87 exception pointers
    (last-instruction pointer, last data-operand pointer, and last
    opcode). The only case in which they do save the exception pointers
    is the relatively rare case in which the exception-summary bit in
    the x87 status word (FSW.ES) is set to 1, indicating that an
    unmasked exception has occurred.

So, unless a floating point exception happened and that exception is
unmasked in the x87 FPU control register (which isn't by default on
Linux, from what I saw), the "last instruction address" register (or
fioff as GDB calls it) will always be 0 on an AMD CPU.

For this reason, I think it's fine to change the test to accept the
value 0 - that's just how the processor works.

I toyed with the idea of changing the test program to make it so the CPU
would generate a non-zero fioff.  That is by unmasking an FPU exception
and executing an instruction to raise that kind exception.  It worked,
but then I would have to change the test more extensively, and it didn't
seem to be worth it.

[1] https://cdrdv2.intel.com/v1/dl/getContent/671200
[2] https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf

Change-Id: If2e1d932f600ca01b15f30b14b8d38bf08a3e00b
Reviewed-by: John Baldwin <jhb@FreeBSD.org>

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Make sure DW_CFA_advance_loc4 is in the same frag

Do the same as commit b9d8f5601bcf in another place generating
DW_CFA_advance_loc4.  The idea behind commit b9d8f5601bcf was that
when a DW_CFA_advance_loc4 of zero is seen in eh_frame_relax_frag and
eh_frame_convert_frag we want to remove the opcode entirely, not just
convert to a nop.  If the opcode was split over two frags then a size
adjustment would need to be done to the first frag, not just the
second as is correct for other cases with split frags.  This would
complicate the eh relaxation.  It's easier to ensure the frag is not
split.

* ehopt.c (check_eh_frame): Don't allow DW_CFA_advance_loc4
to be placed in a different frag to the rs_cfa.

Run 'black' on recent test case

The auto-builders pointed out that I neglected to run 'black' after a
rest testcase change.  This patch fixes the oversight.

Set insn_type for branch instructions on aarch64

gprofng uses insn_type in print_address_func().
But insn_type is always zero on aarch64.

opcodes/ChangeLog:
2023-09-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* opcodes/aarch64-dis.c (print_insn_aarch64_word): Set insn_type for
branch instructions.

gdb/doc: describe x87 registers

While investigating this [1], I initially had no idea what register
"fioff" stood for, making it difficult to map it to something in the
Intel or AMD manuals.  Similarly, I can imaging someone familiar with
x87 to want to print the "x87 last instruction address", and have no
clue that GDB makes it available as register "fioff".  The names of the
x87 state fields don't seem to be standardized, they even change between
sections of the Intel manual (between the FSAVE, FXSAVE and XSAVE area
descriptions).

Add some details to the doc to help one map GDB register names to x87
state fields.

[1] https://inbox.sourceware.org/gdb-patches/20230908022722.430741-1-simon.marchi@efficios.com/T/#u

Change-Id: I0ea1eb648358e62da4aa87eea3515ee8a09f2762
Approved-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Pedro Alves <pedro@palves.net>

gdb/doc: rename "x86 Architecture-specific Issues" section to "x86"

I'm looking to add some x86-specific information to the doc, but I find
the naming of this section odd.  It doesn't really talk about issues, it
just gives generally useful information.  Also, the sections about other
architectures don't mention "issues", just the architecture name.

Also, at least in the HTML version of the doc, the name is inconsistent
between the main table of content, where it appears as "x86
Architecture-specific Issues", and the sub-table of contents of the
"Architectures" section, where it appears as "i386".

Rename the section to just "x86".

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

aarch64: Remove unused function

set_expected_error is no longer used.  It has been replaced by
more specific error messages.

[gdb/testsuite] Make gdb.dwarf2/dwzbuildid.exp more robust

I ran test-case gdb.dwarf2/dwzbuildid.exp with target board cc-with-gdb-index,
and noticed that compilation failure for one exec prohibited testing of all
execs.

Fix this by restructuring the test-case, such that we have:
...
PASS: gdb.dwarf2/dwzbuildid.exp: testname=ok: set debug-file-directory
PASS: gdb.dwarf2/dwzbuildid.exp: testname=ok: print the_int
UNSUPPORTED: gdb.dwarf2/dwzbuildid.exp: testname=mismatch: compilation failed
UNSUPPORTED: gdb.dwarf2/dwzbuildid.exp: testname=fallback: compilation failed
...

Tested on x86_64-linux.

[gdb/testsuite] Add kfail in gdb.dwarf2/dwzbuildid.exp

When running test-case gdb.dwarf2/dwzbuildid.exp using target board readnow, I
get:
...
(gdb) file dwzbuildid-mismatch^M
Reading symbols from dwzbuildid-mismatch...^M
warning: File "dwzbuildid5.o" has a different build-id, file skipped^M
could not find '.gnu_debugaltlink' file for dwzbuildid-mismatch^M
(gdb) delete breakpoints^M
(gdb) info breakpoints^M
No breakpoints or watchpoints.^M
(gdb) break -qualified main^M
No symbol table is loaded.  Use the "file" command.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.dwarf2/dwzbuildid.exp: mismatch: gdb_breakpoint: set breakpoint at main
...

This is PR symtab/26797: when using readnow, a failure in reading the dwarf
results in the minimal symbols not being available.

Add a corresponding KFAIL.

Tested on x86_64-linux.

[gdb/testsuite] Add aranges in gdb.dwarf2/dwzbuildid.exp

While investigating the execs of gdb.dwarf2/dwzbuildid.exp using readelf I ran
into a warning:
...
$ readelf -w dwzbuildid-ok > READELF
readelf: Warning: .debug_info offset of 0x2e in .debug_aranges section does not
point to a CU header.
...

AFAICT, the warning is incorrect, I've filed PR binutils/30835 about that.

While looking at the .debug_aranges section, I noticed that the entries for
the CUs generated by the dwarf assembler are missing.

Fix this by adding the missing .debug_aranges entries.

Tested on x86_64-linux.

[gdb/testsuite] Fix build-ids in gdb.dwarf2/dwzbuildid.exp

When looking at the execs from test-case gdb.dwarf2/dwzbuildid.exp using
readelf, I run into:
...
$ readelf -w dwzbuildid-ok > READELF
readelf: Warning: Corrupt debuglink section: .gnu_debugaltlink
readelf: Warning: Build-ID is too short (0x6 bytes)
...

Fix this by ensuring the Build-IDs are the required 20 bytes.

Tested on x86_64-linux.

gdb/testsuite: fix gdb.mi/mi-condbreak-throw.exp failure

In commit:

  commit 3ce8f906be7a55d8c0375e6d360cc53b456d86ae
  Date:   Tue Aug 8 10:45:20 2023 +0100

      gdb: MI stopped events when unwindonsignal is on

a new test, gdb.mi/mi-condbreak-throw.exp, was added.  Unfortunately,
this test would fail when using the native-gdbserver board (and other
similar boards).

The problem was that one of the expected output patterns included some
output from the inferior.  When using the native-gdbserver board, this
output is not printed to GDB's tty, but is instead printed to
gdbserver's tty, the result is that the expected output no longer
matches, and the test fails.

Additionally, as the output is actually from the C++ runtime, rather
than the test's source file, changes to the C++ runtime could cause
the output to change.

To solve both of these issues, in this commit, I'm removing the
reference to the inferior's output, and replacing it with '.*', which
will skip the output if it is present, but is equally happy if the
output is not present.

After this commit gdb.mi/mi-condbreak-throw.exp now passes on all
boards, including native-gdbserver.

x86: restrict prefix use with .insn VEX/XOP/EVEX

Avoid triggering the respective abort() in output_insn().

gdb: remove interp_supports_command_editing

It is a trivial wrapper around the supports_command_editing method,
remove it.

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

gdb: remove interp_pre_command_loop

It is a trivial wrapper around the pre_command_loop method, remove it.

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

Automatic date update in version.in

testsuite, fortran: make kfail gfortran specific

The modified test in function-calls.exp actually passes with ifort and
ifx.  The particular fail seems to be specific to gfortran.  When the
test was introduced it was only tested with gfortran (actually the
whole patch was written with gfortran and the GNU Fortran argument
passing convention in mind).

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

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