Refactor py-inferior.exp

This changes py-inferior.exp to make it a bit more robust when adding
new inferiors during the course of the test.

Approved-By: Pedro Alves <pedro@palves.net>

Minor cleanups in py-inferior.exp

While working on this series, I noticed a some oddities in
py-inferior.exp.  One is an obviously incorrect comment, and the
others are confusing test names.  This patch fixes these.

Approved-By: Pedro Alves <pedro@palves.net>

Revert "Simplify auto_load_expand_dir_vars and remove substitute_path_component"

This reverts commit 02601231fdd91a7bd4837ce202906ea2ce661489.

This commit was a refactoring to remove an xrealloc and simplify
utils.[ch].  However, it has a flaw -- it mishandles a substitution
like "$datadir/subdir".

I am backing out the patch in the interests of fixing the regression
before GDB 14.  It can be reinstated (with modifications) later if we
like.

Regression tested on x86-64 Fedora 36.

Test that native targets can read a tdesc without a process attached.

This ensures that 'unset tdesc filename' does not generate any output
on a "bare" native target inferior without an attached process.

Add a have_native_target helper function for use with require.

Move logic from auto-connect-native-target.exp into this helper.

*-linux-nat: Handle null inferior in read_description.

Don't invoke ptrace in the target read_description method if there is
not an active inferior to query via ptrace.  Instead, use the default
register set for the architecture.

Previously the native target could report an error from a failed
ptrace operation when fetching a tdesc without an attached process.
For example on Linux x86-64:

(gdb) target native
Done.  Use the "run" command to start a process.
(gdb) unset tdesc filename
Couldn't get CS register: No such process.

*-fbsd-nat: Handle null inferior in read_description.

Don't invoke ptrace in the target read_description method if there is
not an active inferior to query via ptrace.  Instead, use the default
register set for the architecture.

Previously the native target could report an error from a failed
ptrace operation when fetching a tdesc without an attached process.
For example on FreeBSD/amd64:

(gdb) target native
Done.  Use the "run" command to start a process.
(gdb) unset tdesc filename
Couldn't get registers: Operation not permitted.

Re: Let '^' through the lexer

Fix "make pdf".

gdb/doc: document '+' argument for 'list' command

The command 'list' has accepted the argument '+' for many years already,
but this option wasn't documented either in the texinfo docs or in the
help text for the command.  This commit documents it.

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

gdb/cli: Improve UX when using list with no args

When using "list" with no arguments, GDB will first print the lines
around where the inferior is stopped, then print the next N lines until
reaching the end of file, at which point it warns the user "Line X out
of range, file Y only has X-1 lines.".  This is usually desirable, but
if the user can no longer see the original line, they may have forgotten
the current line or that a list command was used at all, making GDB's
error message look cryptic. It was reported in bugzilla as PR cli/30497.

This commit improves the user experience by changing the behavior of
"list" slightly when a user passes no arguments.  It now prints that the
end of the file has been reached and recommends that the user use the
command "list ." instead.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30497
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/cli: add '.' as an argument for 'list' command

Currently, after the user has used the list command once, there is no
self-contained way to ask GDB to print the location where the inferior is
stopped.  The current best options require either using a separate
command to scope out where the inferior is stopped, or using "list *$pc"
requiring knowledge of GDB standard registers.  This commit adds a way
to do that using '.' as a new argument for the 'list' command.  If the
inferior isn't running, the command prints around the main function.

Because this necessitated having the inferior running and the test was
(seemingly unnecessarily) using printf in a non-essential way and it
would make the resulting log harder to read for no benefit, it was
replaced by a different statement.

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

gdb/cli: Factor out code to list lines around a given line

A future patch will add more situations that calculates "lines around a
certain point" to be printed using print_source_lines, and the logic
could be re-used. As a preparation for those commits, this one factors
out that part of the logic of the list command into its own function.
No functional changes are expected

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

gprofng: 30602 [2.41] gprofng test hangs on i686-linux-gnu

There were several problems in the gprofng testing:
 - we did not catch a timeout for each test.
 - we used exit() to stop a failed test. But this stops all other tests.
 - we used a time_t (long) type in smalltest.c instead of a long long type.

PR gprofng/30602
* configure.ac: Launch only native testing.
* configure: Rebuild.
* testsuite/config/default.exp: Set TEST_TIMEOUT.
* testsuite/gprofng.display/setpath_map.exp: Use return instead of exit.
* testsuite/gprofng.display/gp-archive.exp: Likewise.
* testsuite/gprofng.display/gp-collect-app_F.exp: Likewise.
* testsuite/gprofng.display/display.exp: Delete an unnecessary test
for native testing.
* testsuite/lib/display-lib.exp (run_native_host_cmd): Add timeout.
* testsuite/lib/smalltest.c: Use a long long type instead of time_t.

Make the default gas symbol hash table larger

We may as well start with the symbol table a little larger, saving
time resizing.  Even a simple C hello world compiled with -O2 -g will
exceed 16 symbols (by well over 3 times with gcc-11).

* symbols.c (symbol_begin): Create sy_hash with more entries.

Fix loongarch build with gcc-4.5

* loongarch-opc.c (loongarch_alias_opcodes): Don't trigger
gcc-4.5 bug in handling of struct initialisation.

More tidies to objcopy archive handling

This makes sure copy_archive exits with ibfd and obfd closed.  Error
paths didn't do that, leading to memory leaks.  None of this matters
very much.

* objcopy.c (copy_archive): bfd_close ibfd and obfd on error
return paths.  Remove braces around "list" free.
(copy_file): Don't close invalid file descriptor.

AIX_WEAK_SUPPORT

Making target code depend on a host define like _AIX52 is never
correct, so out it goes.  Also, sort some config.bfd entries a little
to make it more obvious there is a config difference between aix5.1
and aix5.2.  These two changes should make no difference to anything
in binutils.  The gas define of AIX_WEAK_SUPPORT on the other hand was
wrong, so fix that.  Finally, fix some testsuite fails on aix < 5.2 by
simply not running the tests.

include/
* coff/internal.h (C_WEAKEXT): Don't depend on _AIX52.
bfd/
* coffcode.h (coff_slurp_symbol_table): Don't depend on _AIX52.
(coff_classify_symbol): Likewise.
* config.bfd: Sort some entries.
gas/
* configure.ac (AIX_WEAK_SUPPORT): Don't set for aix5.[01].
* configure: Regenerate.
* testsuite/gas/ppc/aix.exp (xcoff-visibility-1*) Don't run
for aix < 5.2.

Automatic date update in version.in

Implement 'Enum_Val and 'Enum_Rep

This patch implements the Ada 2022 attributes 'Enum_Val and 'Enum_Rep.

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

Remove ada_attribute_name

ada_attribute_name uses an array that must be kept in sync with an
enum -- but the comment here refers to an enum that no longer exists.
Looking at the sole caller, I see this can only be called for two
opcodes.  So, remove this entirely and inline it.

Let '^' through the lexer

so that the (existing) code in parser and expression evaluator
actually get to see it and handle it as XOR.  Also adjust docu
to match what's there.

elf_object_p load of dynamic symbols

This fixes an uninitialised memory access on a fuzzed file:
0 0xf22e9b in offset_from_vma /src/binutils-gdb/bfd/elf.c:1899:2
1 0xf1e90f in _bfd_elf_get_dynamic_symbols /src/binutils-gdb/bfd/elf.c:2099:13
2 0x10e6a54 in bfd_elf32_object_p /src/binutils-gdb/bfd/elfcode.h:851:9

Hopefully it will also stop any attempt to load dynamic symbols from
eu-strip debug files.

* elfcode.h (elf_object_p): Do not attempt to load dynamic
symbols for a file with no section headers until all the
program headers are swapped in.  Do not fail on eu-strip debug
files.

Automatic date update in version.in

[gdb/tui] Assume HAVE_WBORDER

The tui border-kind setting allows values acs, ascii and space.

The values ascii and space however don't work well with !HAVE_WBORDER.

Fix this by removing the !HAVE_WBORDER case, which was introduced for Ultrix
support, which is now obsolete.

Tested on x86_64-linux.

PR tui/30580
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30580

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

[gdb/tui] Make translate return entry->value instead of entry

The only use of "entry = translate (...)" is entry->value.

Simplify using the function by returning entry->value instead.

Tested on x86_64-linux.

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

[gdb/tui] Merge tui border-kind corner translation tables

The tables:
- tui_border_kind_translate_ulcorner
- tui_border_kind_translate_urcorner
- tui_border_kind_translate_llcorner
- tui_border_kind_translate_lrcorner
are identical.

Merge and rename to tui_border_kind_translate_corner.

Tested on x86_64-linux.

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

[gdb/tui] Introduce translate_acs

In function tui_update_variables we have the somewhat inconvenient:
...
  entry = translate (tui_border_kind, tui_border_kind_translate_lrcorner);
  int val = (entry->value < 0) ? ACS_LRCORNER : entry->value;
...

Add a new function translate_acs, that allows us to do the more straighforward:
...
  int val = translate_acs (tui_border_kind, tui_border_kind_translate_lrcorner,
   ACS_LRCORNER);
...

By special-casing "acs" in translate_acs, we can now remove the acs entries
from the translation tables.

Tested on x86_64-linux.

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

[gdb/tui] Remove default entries in TUI translation tables

The TUI translation tables contain default entries at the end:
...
static struct tui_translate tui_border_kind_translate_hline[] = {
  { "space",    ' ' },
  { "ascii",    '-' },
  { "acs",      -1 },
  { 0, 0 },
  { "ascii",    '-' }
};
...

A simpler way of implementing this would be to to declare the first (or last)
entry the default, but in fact these default entries are not used.

Make this explicit by removing the default entries, and asserting in translate
that an entry will always be found.

Tested on x86_64-linux.

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

.noinit and .persistent for msp430

Similar to the previous patch, but also tidy a few more sections.

* scripttempl/elf32msp430.sc (.text, .rodata, .data, .bss, .noinit),
(.persistent): Align the section rather than aligning inside.

.noinit and .persistent alignment

It's more elegant to make the section match up with its "_start"
symbol.  We could align by setting the address of the section (by
using ALIGN before the colon), but this way we also set sh_addralign
to at least $ALIGNMENT.

* scripttempl/elf.sc (.noinit, .persistent): Align the output
section rather than using ". = ALIGN();" at the beginning.
Set address to zero when not a final link.

Re: Align linkerscript symbols according to ABI

Align dot before symbols defined outside of output sections.  Before _end
is already aligned.

* scripttempl/elf.sc (def_symbol): Tidy excess space.
(_edata): Align before emitting symbol when SYMBOL_ABI_ALIGNMENT.

Re: Keeping track of rs6000-coff archive element pointers

bfd/
* coff-rs6000.c (add_range): Revise comment, noting possible fail.
(_bfd_xcoff_openr_next_archived_file): Start with clean ranges.
binutils/
* bfdtest1.c: Enhance to catch errors on second scan.

Automatic date update in version.in

Remove some TODOs from gdb.cp tests

This patch removes many TODOs from the gdb.cp tests.
Going through the patch:

* bs15503.exp - these have been commented out forever and rely on
  libstdc++ debuginfo.  It's better to just remove these.

* classes.exp - the test is wrong, I think, according to the C++ ABI
  that gdb understands; and the test can be fixed and comments removed
  with a simple change to the code.

* ctti.exp - there's no need to bail out any more, as the test works.

* exception.exp - the code relying on the line numbers can't work,
  because gdb never prints that message anyway.

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

x86: simplify table-referencing macros

First of all it is entirely unclear why THREE_BYTE_TABLE_PREFIX() was
introduced by bf890a93a7c4. Nothing uses the .prefix_requirement values
from the two relevant entries.

And then having VEX_Cn_TABLE() and friends take arguments is misleading.
These aren't used (or pointlessly used in the case of VEX_C5_TABLE); the
respective table index is decoded from the insn (or implied in the case
of VEX_C5_TABLE).

x86: convert 0FXOP to just XOP in enumerator names

There's nothing 0f-ish in XOP encodings.

x86: misc further register-only insns don't need to go through mod_table[]

Several already use OP_R(), which rejects the memory forms of insns, and
a few others can easily be converted to do so as well. Note that for it
to be able to use BadOp() without forward declaration, OP_Skip_MODRM() is
moved down.

While there add the previously missing PREFIX_OPCODE to legacy opcode
0FD7.

x86: various operations on mask registers can avoid going through mod_table[]

Now that we have OP_R(), use it here as well, while wiring memory-only
operands to OP_M() at the same time. To keep the number of consumed
opcode bytes similar to before, make BadOp() also account for VEX/XOP/
EVEX prefix bytes. To keep that change simple, convert need_vex to an
actual count of prefix bytes (keeping intact all prior boolean uses of
the field).

Note how this improves disassembly of such bad encodings, by at least
leaving a hint towards what a "nearby" instruction is. (For KSHIFT*
change the immediates test testcases use, such that disassembly remains
sufficiently in sync.)

While there also use Ux for VPMOV{B,W,D,Q}2M, where decoding through
mod_table[] was missing in the earlier scheme.

x86: slightly rework handling of some register-only insns

Fold OP_MS() and OP_XS() into OP_R(), paralleling OP_M(). Use operand
names (largely) matching those in the SDM. For 128-bit-only forms use
Uxmm though, marking 256-bit forms as bad. This then allows no longer
going through vex_len_table[] for two of the insns.

Specifically _do not_ continue to mis-use v_mode.

x86: SIMD shift-by-immediate don't need to go through mod_table[]

OP_MS() and OP_XS() reject memory forms of insns quite fine. This then
also eliminates mis-named enumerators (we use M_1 for register forms).

x86: misc further memory-only insns don't need to go through mod_table[]

Several already use OP_M(), which rejects the register forms of insns,
and a few others can easily be converted to do so as well. (Note that
FXSAVE_Fixup() wires through to OP_M(). Note further that OP_IndirE(),
which wasn't placed very well anyway, is moved down to avoid the need to
forward-declare BadOp().)

Also adjust formatting of and drop PREFIX_OPCODE from a few adjacent
entries.

x86: {,V}MOVNT* don't need to go through mod_table[]

Most of them use Mx already for the memory operand, which rejects the
register form of the insn. Use that operand type also for the two EVEX
forms which so far have used EXEvexXNoBcst (and thus failed to reject
the register forms), compensating by flagging broadcast as bad for all
Mx. This way several other insns which don't permit embedded broadcast
either are also covered at the same time.

x86: fold legacy/VEX {,V}MOV{H,L}* entries

By changing decode order to do ModR/M.mod last (rather than VEX.L), the
VEX entries (which are already reused by EVEX decoding) can be folded
with their legacy counterparts as well. Note how this change of decode
order also allows removing two auxiliary #define-s, which were
introduced during earlier folding (because of that unhelpful order of
steps).

x86: fold certain legacy/VEX table entries

Introduce macro V to expand to 'v' in the VEX/EVEX case, and replace a
couple of abort()s where legacy code can now legitimately make it. While
there for {,V}LDDQU drop hoing through mod_table[] - OP_M() rejects
register operands quite fine.

ld/PDB: fix off-by-1 in add_globals_ref()

Copying one too many bytes can corrupt memory, detected/reported by
glibc on a 32-bit distro.

Automatic date update in version.in

Remove target_close

I noticed that target_close is only called in two places:
solib-svr4.c, and target_ops_ref_policy::decref.

This patch fixes the former by changing target_bfd_reopen to return a
target_ops_up and then fixing the sole caller.  Then it removes
target_close by inlining its body into the decref method.

The advantage of this approach is that targets are now automatically
managed.

Regression tested on x86-64 Fedora 38.

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

Update TUI window title when changed

I wrote a TUI window in Python, and I noticed that setting its title
did not result in a refresh, so the new title did not appear.  This
patch corrects this problem.

Add Ada scope test for DAP

This adds a DAP test for fetching scopes and variables with an Ada
program.  This test is the reason that the FrameVars code does not
check is_constant on the symbols it returns.

Note that this test also shows that string-printing is incorrect in
Ada.  This is a known bug but I'm still considering how to fix it.

Handle typedefs in no-op pretty printers

The no-ops pretty-printers that were introduced for DAP have a classic
gdb bug: they neglect to call check_typedef.  This will cause some
strange behavior; for example not showing the children of a variable
whose type is a typedef of a structure type.  This patch fixes the
oversight.

Reimplement DAP stack traces using frame filters

This reimplements DAP stack traces using frame filters.  This slightly
simplifies the code, because frame filters and DAP were already doing
some similar work.  This also renames RegisterReference and
ScopeReference to make it clear that these are private (and so changes
don't have to worry about other files).

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

Simplify FrameVars

FrameVars implements its own variant of Symbol.is_variable.  This
patch replaces this code.

Fix oversights in frame decorator code

The frame decorator "FrameVars" code misses a couple of cases,
discovered when working on related DAP changes.

First, fetch_frame_locals does not stop when reaching a function
boundary.  This means it would return locals from any enclosing
functions.

Second, fetch_frame_args assumes that all arguments are at the
outermost scope, but this doesn't seem to be required by gdb.

Add new interface to frame filter iteration

This patch adds a new function, frame_iterator, that wraps the
existing code to find and execute the frame filters.  However, unlike
execute_frame_filters, it will always return an iterator -- whereas
execute_frame_filters will return None if no frame filters apply.

Nothing uses this new function yet, but it will used by a subsequent
DAP patch.

Fix execute_frame_filters doc string

When reading the doc string for execute_frame_filters, I wasn't sure
if the ranges were inclusive or exclusive.  This patch updates the doc
string to reflect my findings, and also fixes an existing typo.

Change 'handle_id' to be a local variable

The global variable 'handle_id' in tracectf.c is only used in a single
function, so change it to be a local variable.

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

Move definition of ctf_target type

This moves the definition of the ctf_target type into the
HAVE_LIBBABELTRACE block.  This type is only used in this block, so it
makes sense to only define it there.

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

Constify tfile_interp_line

This adds 'const' to tfile_interp_line.

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

Use function_view in traceframe_walk_blocks

This change traceframe_walk_blocks to take a function_view.  This
simplifies the code somewhat and lets us entirely remove one helper
function.

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

Use unique_ptr for trace_dirname

This changes trace_dirname to use unique_ptr, removing some manual
memory management.

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

Use unique_ptr for trace_filename

This changes trace_filename to use unique_ptr, removing some manual
memory management.

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

Replace use of xfree with byte_vector

This replaces a use of xfree with a byte_vector.

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

Remove a use of xfree

This removes a use of xfree from tracefile-tfile.c, replacing it with
a unique_xmalloc_ptr.

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

Avoid crash with absolute symbol

A user supplied an executable and a remote logfile that could be used
to crash gdb.  The problem is that the BFD section for a particular
symbol was null, because the section was not marked "allocated".
Digging deeper, the problem was that elfread.c dropped the section for
absolute symbols.  This patch fixes the crash.

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

gdbserver: handle all eval_result_type values in tracepoint.cc

It was pointed out[1] that after this commit:

  commit 3812b38d8de5804ad3eadd6c7a5d532402ddabab
  Date:   Thu Oct 20 11:14:33 2022 +0100

      gdbserver: allow agent expressions to fail with invalid memory access

Now that agent expressions might fail with the error
expr_eval_invalid_memory_access, we might overflow the
eval_result_names array in tracepoint.cc.  This is because the
eval_result_names array does not include a string for either
expr_eval_invalid_goto or expr_eval_invalid_memory_access.

I don't know if having expr_eval_invalid_goto missing is also a
problem, but it feels like eval_result_names should just include a
string for every possible error.

I could just add two more strings into the array, but I figure that a
more robust solution will be to move all of the error types, and their
associated strings, into a new ax-result-types.def file, and to then
include this file in both ax.h and tracepoint.cc in order to build
the enum eval_result_type and the eval_result_names string array.
Doing this means it is impossible to have a missing error string in
the future.

[1] https://inbox.sourceware.org/gdb-patches/01059f8a-0e59-55b5-f530-190c26df5ba3@palves.net/

Approved-By: Pedro Alves <pedro@palves.net>

gdb/testsuite: avoid stack addresses in test names

When comparing the test results for two different runs of GDB I
noticed a difference in the results for gdb.base/frame-view.exp.

The difference was caused by one of the tests including a stack
address in the test name:

  PASS: gdb.base/frame-view.exp: with_pretty_printer=false: select-frame view 0x7ffff7c5cea8 0x40115b

and

  PASS: gdb.base/frame-view.exp: with_pretty_printer=true: select-frame view 0x7ffff7c5cea8 0x40115b

If for whatever reason the stack address changes between test runs
then it becomes harder to compare results.

Fix this by giving the test a descriptive name that doesn't include a
stack address:

  PASS: gdb.base/frame-view.exp: with_pretty_printer=false: select thread 2 frame from thread 1

and

  PASS: gdb.base/frame-view.exp: with_pretty_printer=true: select thread 2 frame from thread 1

There's no change to what is actually tested after this commit.

gdb/testsuite: return after reporting a test unsupported

In this commit:

  commit 8bcead69665af3a9f9867cd34c3a1daf22120027
  Date:   Tue May 23 11:25:01 2023 +0100

      gdb/testsuite: add test for core file with a 0 pid

a new test gdb.arch/core-file-pid0.exp was added.  This test includes
a pre-generated core file for x86-64 and for other architectures the
test reports 'unsupported'.

However, after reporting 'unsupported' the test failed to perform an
early return, so the test would then carry on and try to actually
perform the test, which resulted in some TCL errors.

Fix this by returning after reporting the test unsupported.

gdb: include location number in breakpoint error message

This commit improves the output of this previous commit:

  commit 2dc3457a454a35d0617dc1f9cc1db77468471f95
  Date:   Fri Oct 14 13:22:55 2022 +0100

      gdb: include breakpoint number in testing condition error message

The earlier commit extended the error message:

  Error in testing breakpoint condition:

to include the breakpoint number, e.g.:

  Error in testing breakpoint condition 3:

This commit extends takes this further, and includes the location
number if the breakpoint has multiple locations, so we might now see:

  Error in testing breakpoint condition 3.2:

Just as with how GDB reports a normal breakpoint stop, if a breakpoint
only has a single location then the location number is not included,
this keeps things nice and consistent.

I've extended one of the tests to cover the new functionality.

Approved-By: Pedro Alves <pedro@palves.net>

gdb/testsuite: Testing with the nvfortran compiler

Currently, the Fortran test suite does not run with NVIDIA's Fortran
compiler (nvfortran).

The goal here is to get the tests running and preventing further
regressions during future work. This change does not do anything to fix
existing failures.

Teach the compiler detection about nvfortran. There is no underlying
information about whether this compiler is related to flang classic or
flang, so we cannot reuse the main and type definitions. Therefore, we
explicitly record the main method and type information observed when
using nvfortran.

The main name was extracted by trying to set breakpoints on both MAIN_
and MAIN__.

The following mapping of test to type names was used to extract how
nvfortran reports types.

info-types.exp: fortran_int4, fortran_int8, fortran_real4,
fortran_logical4

common-block.exp: fortran_real8

complex.exp: fortran_complex4 fortran_complex8

logical.exp: fortran_character1. Ran ptype on "c".

Types defined as fortran_complex16 do not compile with nvfortran, so it
was left unset.

gdb.fortran regression tests run with GNU, Intel, Intel LLVM and ACfL.
No regressions detected.

The gdb.fortran test results with nvfortran 23.3 are as follows.

Before:

    # of expected passes        523
    # of unexpected failures    107
    # of known failures         2
    # of unresolved testcases   1
    # of untested testcases     7
    # of duplicate test names   2

After:

    # of expected passes        5696
    # of unexpected failures    271
    # of known failures         12
    # of untested testcases     9
    # of unsupported tests      5

As can be seen from the above, there are now considerably more passing
assertions.

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

Automatic date update in version.in

PR30592 objcopy: allow --set-section-flags to add or remove SHF_X86_64_LARGE

For example, objcopy --set-section-flags .data=alloc,large will add
SHF_X86_64_LARGE to the .data section.  Omitting "large" will drop the
SHF_X86_64_LARGE flag.

The bfd_section flag is named generically, SEC_ELF_LARGE, in case other
processors want to follow SHF_X86_64_LARGE.  SEC_ELF_LARGE has the same
value as SEC_TIC54X_BLOCK used by coff.

bfd/
    * section.c: Define SEC_ELF_LARGE.
    * bfd-in2.h: Regenerate.
    * elf64-x86-64.c (elf_x86_64_section_flags, elf_x86_64_fake_sections,
    elf_x86_64_copy_private_section_data): New.

binutils/
    * NEWS: Mention the new feature for objcopy.
    * doc/binutils.texi: Mention "large".
    * objcopy.c (parse_flags): Parse "large".
    (check_new_section_flags): Error if "large" is used with a
    non-x86-64 ELF target.
    * testsuite/binutils-all/x86-64/large-sections.d: New.
    * testsuite/binutils-all/x86-64/large-sections.s: New.
    * testsuite/binutils-all/x86-64/large-sections-i386.d: New.
    * testsuite/binutils-all/x86-64/large-sections-2.d: New.
    * testsuite/binutils-all/x86-64/large-sections-2-x32.d: New.

Automatic date update in version.in

gdb/cp-namespace.c: Fix assert failure caused by malformed user input

When debugging C++ programs, it is possible to trigger a spurious assert
failure when attempting to set a breakpoint on a malformed symbol name.
Names of the form 'A>::B' and 'A)::B' trigger this assert failure in
cp_lookup_bare_symbol:

    $ gdb gdb
    [...]
    (gdb) br test>::assert
    Function "test>::assert" not defined.
    Make breakpoint pending on future shared library load? (y or [n]) y
    Breakpoint 1 (test>::assert) pending.
    (gdb) start
    [...]
    cp-namespace.c:181: internal-error: cp_lookup_bare_symbol: Assertion `strstr (name, "::") == NULL' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    ----- Backtrace -----
    0x5217e2 gdb_internal_backtrace_1
            /home/amerey/binutils-gdb/gdb/bt-utils.c:122
    0x521885 _Z22gdb_internal_backtracev
            /home/amerey/binutils-gdb/gdb/bt-utils.c:168
    0xaf8303 internal_vproblem
            /home/amerey/binutils-gdb/gdb/utils.c:396
    0xaf86be _Z15internal_verrorPKciS0_P13__va_list_tag
            /home/amerey/binutils-gdb/gdb/utils.c:476
    0xccdb3f _Z18internal_error_locPKciS0_z
            /home/amerey/binutils-gdb/gdbsupport/errors.cc:58
    0x5dded9 cp_lookup_bare_symbol
            /home/amerey/binutils-gdb/gdb/cp-namespace.c:181
    0x5de39d cp_lookup_symbol_in_namespace
            /home/amerey/binutils-gdb/gdb/cp-namespace.c:328
    [...]

Currently this assert is skipped if the symbol name contains '<' or '('.
Fix this spurious failure by also skipping the assert when the symbol
name contains '>' or ')'.

Regression tested on F38 x86_64.

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

Automatic date update in version.in

Fix result of DAP setExpression

A co-worker, Andry, noticed that the DAP setExpression implementation
returned the wrong fields -- it used "result" rather than "value", and
included "memoryReference", which isn't in the spec (an odd oversight,
IMO).

This patch fixes the problems.

Remove unchecked casts to mi_interp

Simon noticed a crash that could be caused via new Python
gdb.execute_mi function.  Looking into this, I found a few unchecked
casts to mi_interp, like:

-  struct mi_interp *mi = (struct mi_interp *) command_interp ();

This patch replaces all such casts with safer variants.

For -gdb-exit and mi_load_progress, I chose to have the functions
simply not generate any output.  It didn't seem useful to do so.

Some casts I eliminated by adding a parameter to a function.  Then, in
mi_execute_command, I changed the code to use
gdb::checked_static_cast.  This is appropriate because this particular
overload can only be called by the MI interpreter.

There does not seem to be a very good way to test -gdb-exit.

Regression tested on x86-64 Fedora 36.

gdb: check max-value-size when reading strings for printf

I noticed that the printf code for strings, printf_c_string and
printf_wide_c_string, don't take max-value-size into account, but do
load a complete string from the inferior into a GDB buffer.

As such it would be possible for an badly behaved inferior to cause
GDB to try and allocate an excessively large buffer, potentially
crashing GDB, or at least causing GDB to swap lots, which isn't
great.

We already have a setting to protect against this sort of thing, the
'max-value-size'.  So this commit updates the two function mentioned
above to check the max-value-size and give an error if the
max-value-size is exceeded.

If the max-value-size is exceeded, I chose to continue reading
inferior memory to figure out how long the string actually is, we just
don't store the results.  The benefit of this is that when we give the
user an error we can tell the user how big the string actually is,
which would allow them to correctly adjust max-value-size, if that's
what they choose to do.

The default for max-value-size is 64k so there should be no user
visible changes after this commit, unless the user was previously
printing very large strings.  If that is the case then the user will
now need to increase max-value-size.

gdb: remove last alloca call from printcmd.c

This commit removes the last alloca call from printcmd.c.  This is
similar to the patches I originally posted here:

  https://inbox.sourceware.org/gdb-patches/cover.1677533215.git.aburgess@redhat.com/

However, this change was not included in that original series.

The original series received push back because it was thought that
replacing alloca with a C++ container type would introduce unnecessary
malloc/free overhead.

However, in this case we are building a string, and (at least for
GCC), the std::string type has a small string optimisation, where
small strings are stored on the stack.

And in this case we are building what will usually be a very small
string, we're just constructing a printf format specifier for a hex
value, so it'll be something like '%#x' -- though it could also have a
width in there too -- but still, it should normally fit within GCCs
small string buffer.

So, in this commit, I propose replacing the use of alloca with a
std::string.  This shouldn't result (normally) in any additional
malloc or free calls, so should be similar in performance to the
original approach.

There should be no user visible differences after this commit.

gdb: remove two uses of alloca from printcmd.c

Remove a couple of uses of alloca from printcmd.c, and replace them
with gdb::byte_vector.

An earlier variant of this patch was proposed in this thread:

  https://inbox.sourceware.org/gdb-patches/cover.1677533215.git.aburgess@redhat.com/

however, there was push back on that thread due to it adding extra
dynamic allocation, i.e. moving the memory buffers off the stack on to
the heap.

However, of all the patches originally proposed, I think in these two
cases moving off the stack is the correct thing to do.  Unlike all the
other patches in the original series, where the data being read
was (mostly) small in size, a register, or a couple of registers, in
this case we are reading an arbitrary string from the inferior.  This
could be any size, and so should not be placed on the stack.

So in this commit I replace the use of alloca with std::byte_vector
and simplify the logic a little (I think) to take advantage of the
ability of std::byte_vector to dynamically grow in size.

Of course, really, we should probably be checking the max-value-size
setting as we load the string to stop GDB crashing if a corrupted
inferior causes GDB to try read a stupidly large amount of
memory... but I'm leaving that for a follow on patch.

There should be no user visible changes after this commit.

gdb: fix printf of wchar_t early in a gdb session

Given this test program:

  #include <wchar.h>

  const wchar_t wide_str[] = L"wide string";

  int
  main (void)
  {
    return 0;
  }

I observed this GDB behaviour:

  $ gdb -q /tmp/printf-wchar_t
  Reading symbols from /tmp/printf-wchar_t...
  (gdb) start
  Temporary breakpoint 1 at 0x40110a: file /tmp/printf-wchar_t.c, line 8.
  Starting program: /tmp/printf-wchar_t

  Temporary breakpoint 1, main () at /tmp/printf-wchar_t.c:8
  25   return 0;
  (gdb) printf "%ls\n", wide_str

  (gdb)

Notice that the printf results in a blank line rather than the
expected 'wide string' output.

I tracked the problem down to printf_wide_c_string (in printcmd.c), in
this function we do this:

  struct type *wctype = lookup_typename (current_language,
 "wchar_t", NULL, 0);
  int wcwidth = wctype->length ();

the problem here is that 'wchar_t' is a typedef.  If we look at the
comment on type::length() we see this:

  /* Note that if thistype is a TYPEDEF type, you have to call check_typedef.
     But check_typedef does set the TYPE_LENGTH of the TYPEDEF type,
     so you only have to call check_typedef once.  Since value::allocate
     calls check_typedef, X->type ()->length () is safe.  */

What this means is that after calling lookup_typename we should call
check_typedef in order to ensure that the length of the typedef has
been setup correctly.  We are not doing this in printf_wide_c_string,
and so wcwidth is incorrectly calculated as 0.  This is what leads GDB
to print an empty string.

We can see in c_string_operation::evaluate (in c-lang.c) an example of
calling check_typedef specifically to fix this exact issue.

Initially I did fix this problem by adding a check_typedef call into
printf_wide_c_string, but then I figured why not move the
check_typedef call up into lookup_typename itself, that feels like it
should be harmless when looking up a non-typedef type, but will avoid
bugs like this when looking up a typedef.  So that's what I did.

I can then remove the extra check_typedef call from c-lang.c, I don't
see any other places where we had extra check_typedef calls.  This
doesn't mean we definitely had bugs -- so long as we never checked the
length, or, if we knew that check_typedef had already been called,
then we would be fine.

I don't see any test regressions after this change, and my new test
case is now passing.

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

ld: fix build with old glibc / gcc

"rename" conflicts with a function of that name, which gcc from that
same timeframe then complains about. Use a name matching that of
struct input_remap's respective field.

arc: Update/Add ARCv3 support.

The ARC HS5x and ARC HS6x processors are based on the new ARCv3 ISA
that implements a full range of 32-bit and 64-bit instructions.  These
processors feature a high-speed 10-stage, dual-issue pipeline that
offers increased utilization of functional units with a limited
increase in power and area.  The HS5x processors feature a 32-bit
pipeline that can execute all ARCv3 32-bit instructions, while the
HS6x processors feature a full 64-bit pipeline and register file that
can execute both 32-bit and 64-bit instructions.  In addition, the ARC
HS6x supports 64-bit virtual and 52-bit physical address spaces to
enable direct addressing of current and future large memories, as well
as 128-bit loads and stores for efficient data movement.

This readelf patch updates/adds Synopsys ARCv3 machine name fileds and
supported relocations.

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

gdb/testsuite: fix license on recently added file

The license header on a file I recently contributed was incorrect.
The file was added in commit:

  commit 087969169836f802a09b1cd0502d2f22d7a8f7dc
  Date:   Tue May 23 11:25:21 2023 +0100

      gdb: handle core files with .reg/0 section names

The problems were:

  - GPLv2 instead of GPLv3,
  - Use the FSF postal address rather than their URL.

Nobody else has touched the file since I merged it, so I don't believe
there are any problems with me changing the license, this commit does
just that.

Udated Freach and Romainian translations for various sub-directories

Minor updates to release readme

Automatic date update in version.in

Linux: Avoid pread64/pwrite64 for high memory addresses (PR gdb/30525)

Since commit 05c06f318fd9 ("Linux: Access memory even if threads are
running"), GDB prefers pread64/pwrite64 to access inferior memory
instead of ptrace.  That change broke reading shared libraries on
SPARC64 Linux, as reported by PR gdb/30525 ("gdb cannot read shared
libraries on SPARC64").

On SPARC64 Linux, surprisingly (to me), userspace shared libraries are
mapped at high 64-bit addresses:

   (gdb) info sharedlibrary
   Cannot access memory at address 0xfff80001002011e0
   Cannot access memory at address 0xfff80001002011d8
   Cannot access memory at address 0xfff80001002011d8
   From                To                  Syms Read   Shared Object Library
   0xfff80001000010a0  0xfff8000100021f80  Yes (*)     /lib64/ld-linux.so.2
   (*): Shared library is missing debugging information.

Those addresses are 64-bit addresses with the high bits set.  When
interpreted as signed, they're negative.

The Linux kernel rejects pread64/pwrite64 if the offset argument of
type off_t (a signed type) is negative, which happens if the memory
address we're accessing has its high bit set.  See
linux/fs/read_write.c sys_pread64 and sys_pwrite64 in Linux.

Thankfully, lseek does not fail in that situation.  So the fix is to
use the 'lseek + read|write' path if the offset would be negative.

Fix this in both native GDB and GDBserver.

Tested on a SPARC64 GNU/Linux and x86-64 GNU/Linux.

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

riscv: Ensure LE instruction fetching

Currently riscv gdb code looks at arch byte order
when fetching instructions. This works when the
target is LE, but on BE arch it will byte swap the
instruction, while the riscv spec defines all
instructions are LE encoded regardless of
system memory endianess.

Fix Solaris regression (PR tdep/30252)

PR tdep/30252 reports that using GDB on Solaris fails an assertion in
target_resume:

 target.c:2648: internal-error: target_resume: Assertion `inferior_ptid != null_ptid' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n)

The backtrace, after running it through c++filt, looks like:

 ----- Backtrace -----
 0xa18914 gdb_internal_backtrace_1
 /root/binutils-gdb/gdb/bt-utils.c:122
 0xa18914 gdb_internal_backtrace()
 /root/binutils-gdb/gdb/bt-utils.c:168
 0xdec834 internal_vproblem
 /root/binutils-gdb/gdb/utils.c:401
 0xdecad8 internal_verror(char const*, int, char const*, __va_list_tag*)
 /root/binutils-gdb/gdb/utils.c:481
 0xf3638c internal_error_loc(char const*, int, char const*, ...)
 /root/binutils-gdb/gdbsupport/errors.cc:58
 0xd70580 target_resume(ptid_t, int, gdb_signal)
 /root/binutils-gdb/gdb/target.c:2648
 0xc59e85 procfs_target::wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>)
 /root/binutils-gdb/gdb/procfs.c:2187
 0xcf6da7 sol_thread_target::wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>)
 /root/binutils-gdb/gdb/sol-thread.c:442
 0xd73711 target_wait(ptid_t, target_waitstatus*, enum_flags<target_wait_flag>)
 /root/binutils-gdb/gdb/target.c:2586
 ...

The problem is that the procfs backend, while inside target_wait,
called target_resume without switching to the leader thread of that
resumption.

The target_resume interface is:

 /* Resume execution (or prepare for execution) of the current thread
    (INFERIOR_PTID), while optionally letting other threads of the
    current process or all processes run free.
    ...

Thus calling target_resume with inferior_ptid == null_ptid is bogus.

target_wait (which leads to procfs_target::wait on Solaris) is called
with inferior_ptid == null_ptid on entry exactly to help catch such
bogus uses.

From the backtrace, it seems that the relevant line in question is
procfs.c:2187:

2186  /* How to keep going without returning to wfi: */
2187  target_continue_no_signal (ptid);
2188  goto wait_again;

target_continue_no_signal is a small wrapper around target_resume,
which would make sense.

The fix is to not call target_resume or go via the target stack at
all.  Instead, factor out a new proc_resume function out of
procfs_target::resume, and call that.  The new function does not rely
on inferior_ptid.

I've not been able to test it myself, but Petr confirmed it fixes the
assertion failure with his test case, and Marcel Telka also confirmed
it solves the problem.

Tested-By: Petr Šumbera <petr.sumbera@oracle.com>
Tested-By: Marcel Telka <marcel@telka.sk>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30252
Change-Id: I6213c59b081d400a22e799ee621c2eff6dcafbf3

ld: fix plugin tests for MIPS PIC

On MIPS, for PIC objects, symbols may reference 2 times:
once from the caller, and once from GOT.
Thus ld may complains 2 times about "undefined reference".

So we add a new "#?" line to every effected testsuite.

Use run_host_cmd to run $CC and other no-section-header test fixes

We should be using run_host_cmd everywhere we invoke a compiler in the
ld testsuite, if we want to use ld/ld-new just built.  run_host_cmd
properly inserts $gcc_B_opt in cases where a user wants to test
binutils with a newly built compiler, ie. when $CC specifies -B itself.

Also, it is not good practice to exclude tests when non-native except
of course those tests that run a target binary.  Compiling and linking
often shows up problems.

* testsuite/ld-elf/no-section-header.exp (binutils_run_test):
Use run_host_cmd to invoke $CC_FOR_TARGET.  Run all tests
non-native too, except for attempting to run the binaries.
Run tests for ELF in general, not just linux.
* testsuite/ld-elf/pr25617-1-no-sec-hdr.rd: Allow localentry
symbol decoration, and support either sorting of symbols.
* testsuite/ld-elf/pr25617-1a-no-sec-hdr.rd: Likewise.
* testsuite/ld-elf/pr25617-1a-sec-hdr.rd: Likewise.
* testsuite/ld-elf/pr25617-1a-no-sec-hdr.nd: Accept D function syms.
* testsuite/ld-elf/start-shared-noheader-sysv.rd: Accept
mips-sgi-irix symbol output.
* testsuite/ld-elf/start-shared-noheader.nd: Likewise.

Re: Stop the linker's --dependency-file option from including temporary lto files.

PR 30568
* ldfile.c (ldfile_try_open_bfd): Fix build failure when
!BFD_SUPPORTS_PLUGINS.

ld: Use run_host_cmd_yesno in indirect.exp instead of catch exec

Catch "exec $CC_FOR_TARGET" won't use the gas/ld that we just build,
and in fact run_host_cmd_yesno is a better choice for it.

ld/ChangeLog:

* testsuite/ld-elf/indirect.exp: use run_host_cmd_yesno
instead of handwrite catch exec $CC_FOR_TARGET.

ld: Use [list ] syntax to define run_tests in indirect.exp

Currently, the var run_tests is defined by syntax {{}},
while in this case, variables cannot be used.
Thus $NOPIE_CFLAGS and $NOPIE_LDFLAGS are passed to cmd as names
instead of values:
  gcc ... $NOPIE_CFLAGS -c .../indirect5a.c -o tmpdir/indirect5a.o

Let's use [list [list ]] syntax instead.

ld/ChangeLog:

* testsuite/ld-elf/indirect.exp(run_tests): use [list [list]]
syntax instead of {{}}.

Automatic date update in version.in

Align linkerscript symbols according to ABI

Apply ABI specific alignment to symbols generated in the default
linker script.

Automatic date update in version.in

x86: optimize 128-bit VPBROADCASTQ to VPUNPCKLQDQ

The alternative is 1 byte shorter when the source is %xmm0-7, as a
2-byte VEX prefix can then be used.

x86: optimize pre-AVX512 {,V}PCMPGT* with identical sources

These are better expressed by the zeroing idiom {,V}PXOR. In some cases
this also results in a shorter encoding.

x86: optimize pre-AVX512 {,V}PCMPEQQ with identical sources

The {,V}PCMPEQD alternative is 1 byte shorter in many cases.