Fix minor grammar issue in python.texi

I noticed a minor grammar problem in the 'GDB/MI Commands In Python'
node of the manual.  I'm checking in this patch to correct it.

Add support to readelf for the PT_OPENBSD_MUTABLE segment type.

binutils * readelf.c (get_segment_type): Handle PT_OPENBSD_MUTABLE segment type.
include  * elf/common.h (PT_OPENBSD_MUTABLE): Define.

[gdb/testsuite] Use gdb_remote_download in allow_opencl_tests

Simon reported that doing:
...
$ while make check-parallel TESTS='gdb.opencl/*.exp' -j 100; do true; done
...
could run into:
...
ERROR: remote_download to target of \
  /data/vries/gdb/src/gdb/testsuite/lib/opencl_kernel.cl to opencl_kernel.cl: \
  cp: cannot create regular file 'opencl_kernel.cl': File exists
...

Fix this by using gdb_remote_download (instead of plain remote_download) in
allow_opencl_test, which takes care of:
- downloading to a location which is safe for parallel testing, by
  using standard_output_file, and
- cleaning up the downloaded file, meaning we can remove the corresponding
  "remote_file target delete ${clprogram}" lines in allow_opencl_test.

Tested on x86_64-linux.

Reported-by: Simon Marchi <simon.marchi@efficios.com>

bfd: aarch64: Optimize BTI stubs PR30076

Don't insert a second stub if the target is already compatible with
an indirect branch.

bfd: aarch64: Fix stubs that may break BTI PR30076

Insert two stubs in a BTI enabled binary when fixing long calls: The
first is near the call site and uses an indirect jump like before,
but it targets the second stub that is near the call target site and
uses a direct jump.

This is needed when a single stub breaks BTI compatibility.

The stub layout is kept fixed between sizing and building the stubs,
so the location of the second stub is known at build time, this may
introduce padding between stubs when those are relaxed.  Stub layout
with BTI disabled is unchanged.

bfd: aarch64: Refactor stub sizing code

elfNN_aarch64_size_stubs has grown big, so factor out the call stub
related code before adding new logic there.

gdb/riscv: add systemtap support

This commit is initial support for SystemTap for RISC-V Linux.  The
following two tests exercise SystemTap functionality, and are showing
many failures, which are all fixed by this commit:

  gdb.cp/exceptprint.exp
  gdb.base/stap-probe.exp

One thing I wasn't sure about is if the SystemTap support should be
Linux specific, or architecture specific.  For aarch64, arm, ia64, and
ppc, the SystemTap support seems to libe in the ARCH-linux-tdep.c
file, while for amd64, i386, and s390 the implementation lives in
ARCH-tdep.c.  I have no idea which of these is the better choice -- or
maybe both choices are correct in the right circumstances, and I'm
just not aware of how to choose between them.

Anyway, for this patch I selected riscv-tdep.c (though clearly, moving
the changes to riscv-linux-tdep.c is trivial if anyone thinks that's a
more appropriate location).

The stap-probe.exp file tests immediate, register, and register
indirect operands, all of which appear to be working fine with this
commit.  The generic expression support doesn't appear to be
architecture specific, so I'd expect that to work fine too.

Automatic date update in version.in

gdb: remove gdbarch_displaced_step_fixup_p

The comment on the gdbarch_displaced_step_fixup gdbarch method
indicates that this method is optional and that GDB will perform some
default if this method is not supplied.  As such we define a predicate
gdbarch_displaced_step_fixup_p.

It may have been true at one point that the fixup method was optional,
but it is no longer true.  If this method is not defined and GDB tries
to complete a displaced step, then GDB is going to crash.

Additionally the gdbarch_displaced_step_fixup_p predicate is not used
anywhere in GDB.

In this commit I have removed the gdbarch_displaced_step_fixup_p
predicate, and I have updated the validation check for the
gdbarch_displaced_step_fixup method; if the
gdbarch_displaced_step_copy_insn method is defined then the fixup
method must also be defined.

I believe I've manually checked all the current places where
gdbarch_displaced_step_copy_insn is defined and they all also define
the fixup method, so this change should cause no problems for anyone.

There should be no user visible changes after this commit.

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

Remove unnecessary cast

I found an upcast from template_symbol to symbol.  This was necessary
long ago, but since symbols use inheritance now, it is not.  This
patch removes it.  Tested by rebuilding.

gdb/testsuite: adjust test cases to previous "maintenance info line-table" change

Commit 904d9b02a185 ("gdb: make "maintenance info line-table" show
relocated addresses again") changed the format of that command, but
failed to adjust some test cases that relied on it.  This patch fixes
it.

The failures fixed are:

    FAIL: gdb.base/maint.exp: maint info line-table w/o a file name
    FAIL: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: END with address 1 eliminated
    FAIL: gdb.dwarf2/dw2-ranges-base.exp: count END markers in line table

Change-Id: I946580d5e100f1beeac99a9e90d7819c6bb4ac6c

[gdb/testsuite] Fix gdb.cp/cp-relocate.exp for remote host

Fix test-case gdb.cp/cp-relocate.exp for remote host using
gdb_remote_download.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.cp/annota{2,3}.exp for native-extended-gdbserver

When running test-cases gdb.cp/annota{2,3}.exp with target board
native-extended-gdbserver, we run into a few FAILs, due to the test-cases
trying to match inferior output together with gdb output.

Fix this by ignoring the inferior output in this case.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.cp/*.exp for remote host

Fix a few test-cases in gdb.cp/*.exp for remote host using new proc
include_file.

Tested on x86_64-linux.

gdb: make "maintenance info line-table" show relocated addresses again

Commit 1acc9dca423f ("Change linetables to be objfile-independent")
changed "maintenance info line-table" to print unrelocated addresses
instead of relocated.  This breaks a few tests on systems where that
matters.  The ones I see are:

    Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/consecutive.exp ...
    FAIL: gdb.base/consecutive.exp: stopped at bp, 2nd instr (missing hex prefix)
    Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/async.exp ...
    FAIL: gdb.base/async.exp: stepi&
    FAIL: gdb.base/async.exp: nexti&
    FAIL: gdb.base/async.exp: finish&

These tests run "maintenance info line-table" to record the address of
some lines, and then use these addresses in expected patterns.  It
therefore expects these addresses to match the runtime addresses,
therefore the relocated addresses.

Add back the relocated addresses, next to the unrelocated addresses,
like so:

    INDEX  LINE   REL-ADDRESS        UNREL-ADDRESS      IS-STMT PROLOGUE-END
    0      6      0x0000555555555119 0x0000000000001119 Y
    1      7      0x000055555555511d 0x000000000000111d Y
    2      8      0x0000555555555123 0x0000000000001123 Y
    3      END    0x0000555555555125 0x0000000000001125 Y

The unrelocated addresses can always be useful trying to map this
information with a DWARF info dump.

Adjust the is_stmt_addresses proc in the testsuite to match the new
output.

Change-Id: I59558f167e13e63421c9e0f2cad192e7c95c10cf

coff_get_normalized_symtab bfd_release

We can't free "internal" on errors, since bfd_coff_swap_sym_in may
call bfd_alloc.  For example, _bfd_XXi_swap_sym_in may even create new
sections, which use bfd_alloc'd memory.  If "internal" is freed, all
more recently bfd_alloc'd memory is also freed.

* coffgen.c (coff_get_normalized_symtab): Don't bfd_release on
error.

Automatic date update in version.in

Remove unnecessary memsets in sframe-dump.c

* sframe-dump.c (dump_sframe_func_with_fres): Don't memset temp.

Sanity check coff-sh and coff-mcore sym string offset

* coff-mcore.c (coff_mcore_relocate_section): Sanity check sym
string offset when setting up name for use by error messages.
* coff-sh.c (sh_relocate_section): Likewise.

PR17910 sym string offset check

As far as I can see the only place that sets obj_coff_strings without
setting obj_coff_strings_len is pe_ILF_build_a_bfd.  Fix that and we
can simplify the sym string offset check.  This is just a tidy.
pe_ILF_build_a_bfd doesn't create bad symbols and
_bfd_coff_read_string_table will always result in non-zero
obj_coff_strings_len when obj_coff_strings is non-NULL.

PR 17910
* coffgen.c (_bfd_coff_internal_syment_name): Always sanity
check sym string offset.
* peicode.h (pe_ILF_build_a_bfd): Set obj_coff_strings_len.

PE fake section for C_SECTION syms

It's an odd thing to have objdump -x show a different section table
to objdump -h, but that can happen if swapping in symbols leads to
creating sections.  Setting SEC_LINKER_CREATED stops the display of
these sections, so that you get shown what is in the object file.

* peXXigen.c (_bfd_XXi_swap_sym_in): Set SEC_LINKER_CREATED on
fake section created for C_SECTION syms.  Don't zero asection
fields that are already zero.

XCOFF: use bfd_coff_close_and_cleanup

Free memory on closing bfds.  The COFF close_and_cleanup does more
work than _bfd_generic_close_and_cleanup (defined as
_bfd_archive_close_and_cleanup).

* coff-rs6000.c (_bfd_xcoff_close_and_cleanup): Define as
_bfd_coff_close_and_cleanup.
* coff64-rs6000.c (rs6000_xcoff64_vec, rs6000_xcoff64_aix_vec): Use
_bfd_coff_close_and_cleanup.

gas: expand_irp memory leaks

* macro.c (expand_irp): Free memory on error return paths.

x86: Check unbalanced braces in memory reference

Check unbalanced braces in memory reference to avoid assembler crash
caused by

commit e87fb6a6d0cdfc0e9c471b7825c20c238c2cf506
Author: Jan Beulich <jbeulich@suse.com>
Date:   Wed Oct 5 09:16:24 2022 +0200

    x86/gas: support quoted address scale factor in AT&T syntax

PR gas/30248
* config/tc-i386.c (i386_att_operand): Check unbalanced braces
in memory reference.
* testsuite/gas/i386/i386.exp: Run pr30248.
* testsuite/gas/i386/pr30248.d: New file.
* testsuite/gas/i386/pr30248.err: Likewise.
* testsuite/gas/i386/pr30248.s: Likewise.

PowerPC: regression fix for reverse-finish command.

The recent commit:

  commit 2a8339b71f37f2d02f5b2194929c9d702ef27223
  Author: Carl Love <cel@us.ibm.com>
  Date:   Thu Mar 9 16:10:18 2023 -0500

   PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp

   PPC64 multiple entry points, a normal entry point and an alternate entry
   point.  The alternate entry point is to setup the Table of Contents (TOC)
   register before continuing at the normal entry point.  When the TOC is
   already valid, the normal entry point is used, this is typically the case.
   The alternate entry point is typically referred to as the global entry
   point (GEP) in IBM.  The normal entry point is typically referred to as
   the local entry point (LEP).
     .....

Is causing regression failures on on PowerPC platforms.  The regression
failures are in tests:

  gdb.reverse/finish-precsave.exp
  gdb.btrace/tailcall.exp
  gdb.mi/mi-reverse.exp
  gdb.btrace/step.exp
  gdb.reverse/until-precsave.exp
  gdb.reverse/finish-reverse.exp
  gdb.btrace/tailcall-only.exp

The issue is in gdb/infcmd.c, function finish_command.  The value of the
two new variables ALT_ENTRY_POINT and ENTRY_POINT are being initializezed
to SAL.PC.  However, SAL has just been declared.  The value of SAL.PC is
zero at this point.  The intialization of ALT_ENTRY_POINT and ENTRY_POINT
needs to be after the initialization of SAL.

This patch moves the initialization of ALT_ENTRY_POINT and ENTRY_POINT
variables to fix the regression failures.

The patch has been tested on Power10 and on X86.

[gdb/testsuite] Check remote_exec results in board files

Make sure the result of each remote_exec in gdb/testsuite/boards/*.exp is
checked.

Tested on x86_64-linux.

[gdb/testsuite] Add missing quote in remote-gdbserver-on-localhost.exp

In a recent commit I forgot to add a double quote before chmod here:
...
      remote_exec build $rsh_cmd chmod go-rx ."
...

Fix it by adding the missing double quote.

[gdb/testsuite] Remove ${board}_file from remote-stdio-gdbserver.exp

Looking at the implementation of ${board}_file in remote-stdio-gdbserver.exp,
I don't see a relevant difference with the implementation of standard_file
in dejagnu.

Simplify the board by removing ${board}_file.

Tested on x86_64-linux, by running gdb.testsuite/board-sanity.exp.

[gdb/testsuite] Use localhost instead of 127.0.0.1 for boards

Some boards in gdb/testsuite/boards use the hardcoded ipv4 address "127.0.0.1".

Use instead "localhost".

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.xml/tdesc-regs.exp for remote host

Fix test-case gdb.xml/tdesc-regs.exp for remote host by using appropriate
filenames.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.xml/tdesc-reload.exp for remote host

Fix test-case gdb.xml/tdesc-reload.exp for remote host by using appropriate
filenames.

Tested on x86_64-linux.

[gdb/testsuite] Set remotedir in local-remote-host-native.exp

In commit ff581559f9d ("[gdb/testsuite] Add gdb.testsuite/board-sanity.exp") I
removed handling of HOST_DIR in local-remote-host-native.exp to fix FAILs
in test-case gdb.testsuite/board-sanity.exp.

Reintroduce handling of HOST_DIR using remotedir, now that using remotedir for
a host board no longer make compilation fail due to commit 80d6c79866f
("[gdb/testsuite] Handle remotedir in remote_upload").

This fixes an XFAIL in gdb.testsuite/board-sanity.exp, introduced in commit
3741934fdb0 ("[gdb/testsuite] Set remotedir by default in some boards").

Tested on x86_64-linux.

RISC-V: Fix disassemble fetch fail return value.

This bug reported in
https://sourceware.org/bugzilla/show_bug.cgi?id=30184
And discussed in
https://sourceware.org/pipermail/binutils/2023-February/126213.html

We also checked the implementation of return value in arm and mips.
So this patch changes the return value to -1, that can fix bugs and maintain
consistency with other architectures.

opcodes/ChangeLog:

        * riscv-dis.c (print_insn_riscv):Change the return value.

Remove .c header files from rs6000-aix-nat.c file

Since the tdesc_powerpc_vsx32, tdesc_powerpc_vsx64, tdesc_powerpc_altivec32 and tdesc_powerpc_altivec64
definitions are moved to ppc-tdep.h we no longer need to import these .c files.

Automatic date update in version.in

Remove some unnecessary includes from *-exp.y

I noticed a weird comment in one of the .y files, and then ended up
removing some unnecessary #includes from these files.

Tested by rebuilding.

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

Remove mi_version function

The mi_version function is unused, and I think it's better overall if
it is never used.  This patch removes it.  Tested by rebuilding.

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

Update python-helper.exp for type allocation changes

The type allocation changes introduced a failure in python-helper.exp
that I did not notice.  The bug is that, with these patches,
arch-allocated integer types have a TYPE_SPECIFIC_INT object attached.
This patch updates the test to allow this.

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

[gdb/testsuite] Handle remotedir in remote_upload

Dejagnu's remotedir implementation has support in remote_exec and
remote_download, but not remote_upload.

Consider the following scenario:
- downloading an executable to target,
- running it,
- uploading a file produced by the executable
while assuming remote target user remote-target with homedir
/home/remote-target and remotedir set to /home/remote-target/tmp.

Concretely, it looks like this:
...
 # binfile == "$outputs/gdb.abc/a.out"
 set target_binfile [remote_download target $binfile]
 # target_binfile == "/home/remote-target/tmp/a.out"
 remote_exec target $target_binfile
 # Running $target_binfile produced /home/remote-target/tmp/result.txt.
 set result [remote_upload target /home/remote-target/tmp/result.txt \
                 $outputs/gdb.abc/result.txt]
 # result == $outputs/gdb.abc/result.txt.
...

Add a remote_upload implementation that also handles remotedir in lib/gdb.exp,
overriding dejagnu's remote_upload, such that we can simplify the
remote_upload call to:
...
 set result [remote_upload target result.txt $outputs/gdb.abc/result.txt]
...

Tested on x86_64-linux.

PR testsuite/30250
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30250

gdb: fix crash during command completion

In some cases GDB will fail when attempting to complete a command that
involves a rust symbol, the failure can manifest as a crash.

The problem is caused by the completion_match_for_lcd object being
left containing invalid data during calls to cp_symbol_name_matches_1.

The first question to address is why we are calling a C++ support
function when handling a rust symbol.  That's due to GDB's auto
language detection for msymbols, in some cases GDB can't tell if a
symbol is a rust symbol, or a C++ symbol.

The test application contains symbols for functions which are
statically linked in from various rust support libraries.  There's no
DWARF for these symbols, so all GDB has is the msymbols built from the
ELF symbol table.

Here's the problematic symbol that leads to our crash:

    mangled: _ZN4core3str21_$LT$impl$u20$str$GT$5parse17h5111d2d6a50d22bdE
  demangled: core::str::<impl str>::parse

As an msymbol this is initially created with language auto, then GDB
eventually calls symbol_find_demangled_name, which loops over all
languages calling language_defn::sniff_from_mangled_name, the first
language that can demangle the symbol gets assigned as the language
for that symbol.

Unfortunately, there's overlap in the mangled symbol names,
some (legacy) rust symbols can be demangled as both rust and C++, see
cplus_demangle in libiberty/cplus-dem.c where this is mentioned.

And so, because we check the C++ language before we check for rust,
then the msymbol is (incorrectly) given the C++ language.

Now it's true that is some cases we might be able to figure out that a
demangled symbol is not actually a valid C++ symbol, for example, in
our case, the construct '::<impl str>::' is not, I believe, valid in a
C++ symbol, we could look for ':<' and '>:' and refuse to accept this
as a C++ symbol.

However, I'm not sure it is always possible to tell that a demangled
symbol is rust or C++, so, I think, we have to accept that some times
we will get this language detection wrong.

If we accept that we can't fix the symbol language detection 100% of
the time, then we should make sure that GDB doesn't crash when it gets
the language wrong, that is what this commit addresses.

In our test case the user tries to complete a symbol name like this:

  (gdb) complete break pars

This results in GDB trying to find all symbols that match 'pars',
eventually we consider our problematic symbol, and we end up with a
call stack that looks like this:

  #0  0x0000000000f3c6bd in strncmp_iw_with_mode
  #1  0x0000000000706d8d in cp_symbol_name_matches_1
  #2  0x0000000000706fa4 in cp_symbol_name_matches
  #3  0x0000000000df3c45 in compare_symbol_name
  #4  0x0000000000df3c91 in completion_list_add_name
  #5  0x0000000000df3f1d in completion_list_add_msymbol
  #6  0x0000000000df4c94 in default_collect_symbol_completion_matches_break_on
  #7  0x0000000000658c08 in language_defn::collect_symbol_completion_matches
  #8  0x0000000000df54c9 in collect_symbol_completion_matches
  #9  0x00000000009d98fb in linespec_complete_function
  #10 0x00000000009d99f0 in complete_linespec_component
  #11 0x00000000009da200 in linespec_complete
  #12 0x00000000006e4132 in complete_address_and_linespec_locations
  #13 0x00000000006e4ac3 in location_completer

In cp_symbol_name_matches_1 we enter a loop, this loop repeatedly
tries to match the demangled problematic symbol name against the user
supplied text ('pars').  Each time around the loop another component
of the symbol name is stripped off, thus, we check 'pars' against
these options:

  core::str::<impl str>::parse
  str::<impl str>::parse
  <impl str>::parse
  parse

As soon as we get a match the cp_symbol_name_matches_1 exits its loop
and returns.  In our case, when we're looking for 'pars', the match
occurs on the last iteration of the loop, when we are comparing to
'parse'.

Now the problem here is that cp_symbol_name_matches_1 uses the
strncmp_iw_with_mode, and inside strncmp_iw_with_mode we allow for
skipping over template parameters.  This allows GDB to match the
symbol name 'foo<int>(int,int)' if the user supplies 'foo(int,'.
Inside strncmp_iw_with_mode GDB will record any template arguments
that it has skipped over inside the completion_match_for_lcd object
that is passed in as an argument.

And so, when GDB tries to match against '<impl str>::parse', the first
thing it sees is '<impl str>', GDB assumes this is a template argument
and records this as a skipped region within the
completion_match_for_lcd object.  After '<impl str>' GDB sees a ':'
character, which doesn't match with the 'pars' the user supplied, so
strncmp_iw_with_mode returns a value indicating a non-match.  GDB then
removes the '<impl str>' component from the symbol name and tries
again, this time comparing to 'parse', which does match.

Having found a match, then in cp_symbol_name_matches_1 we record the
match string, and the full symbol name within the
completion_match_result object, and return.

The problem here is that the skipped region, the '<impl str>' that we
recorded in the penultimate loop iteration was never discarded, its
still there in our returned result.

If we look at what the pointers held in the completion_match_result
that cp_symbol_name_matches_1 returns, this is what we see:

  core::str::<impl str>::parse
  |          \________/  |
  |               |      '--- completion match string
  |               '---skip range
  '--- full symbol name

When GDB calls completion_match_for_lcd::finish, GDB tries to create a
string using the completion match string (parse), but excluding the
skip range, as the stored skip range is before the start of the
completion match string, then GDB tries to do some weird string
creation, which will cause GDB to crash.

The reason we don't often see this problem in C++ is that for C++
symbols there is always some non-template text before the template
argument.  This non-template text means GDB is likely to either match
the symbol, or reject the symbol without storing a skip range.

However, notice, I did say, we don't often see this problem.  Once I
understood the issue, I was able to reproduce the crash using a pure
C++ example:

  template<typename S>
  struct foo
  {
    template<typename T>
    foo (int p1, T a)
    {
      s = 0;
    }

    S s;
  };

  int
  main ()
  {
    foo<int> obj (2.3, 0);
    return 0;
  }

Then in GDB:

  (gdb) complete break foo(int

The problem here is that the C++ symbol for the constructor looks like
this:

  foo<int>::foo<double>(int, double)

When GDB enters cp_symbol_name_matches_1 the symbols it examines are:

  foo<int>::foo<double>(int, double)
  foo<double>(int, double)

The first iteration of the loop will match the 'foo', then add the
'<int>' template argument will be added as a skip range.  When GDB
find the ':' after the '<int>' the first iteration of the loop fails
to match, GDB removes the 'foo<int>::' component, and starts the
second iteration of the loop.

Again, GDB matches the 'foo', and now adds '<double>' as a skip
region.  After that the '(int' successfully matches, and so the second
iteration of the loop succeeds, but, once again we left the '<int>' in
place as a skip region, even though this occurs before the start of
our match string, and this will cause GDB to crash.

This problem was reported to the mailing list, and a solution
discussed in this thread:

  https://sourceware.org/pipermail/gdb-patches/2023-January/195166.html

The solution proposed here is similar to one proposed by the original
bug reported, but implemented in a different location within GDB.
Instead of placing the fix in strncmp_iw_with_mode, I place the fix in
cp_symbol_name_matches_1.  I believe this is a better location as it
is this function that implements the loop, and it is this loop, which
repeatedly calls strncmp_iw_with_mode, that should be resetting the
result object state (I believe).

What I have done is add an assert to strncmp_iw_with_mode that the
incoming result object is empty.

I've also added some other asserts in related code, in
completion_match_for_lcd::mark_ignored_range, I make some basic
assertions about the incoming range pointers, and in
completion_match_for_lcd::finish I also make some assertions about how
the skip ranges relate to the match pointer.

There's two new tests.  The original rust example that was used in the
initial bug report, and a C++ test.  The rust example depends on which
symbols are pulled in from the rust libraries, so it is possible that,
at some future date, the problematic symbol will disappear from this
test program.  The C++ test should be more reliable, as this only
depends on symbols from within the C++ source code.

Since I originally posted this patch to the mailing list, the
following patch has been merged:

  commit 6e7eef72164c00d6a5a7b0bce9fa01f5481f33cb
  Date:   Sun Mar 19 09:13:10 2023 -0600

      Use rust_demangle to fix a crash

This solves the problem of a rust symbol ending up in the C++ specific
code by changing the order languages are sorted.  However, this new
commit doesn't address the issue in the C++ code which was fixed with
this commit.

Given that the C++ issue is real, and has a reproducer, I'm still
going to merge this fix.  I've left the discussion of rust in this
commit message as I originally wrote it, but it should be read within
the context of GDB prior to commit 6e7eef72164c00d6a5a7.

Co-Authored-By: Zheng Zhan <zzlossdev@163.com>

x86: drop identifier_chars[]

It tries to resemble what's underlying is_part_of_name(), but doesn't
quite achieve that: '$' for example is unconditionally marked as part of
symbol names, but was included as identifier char for Intel syntax only.
Note that i386_att_operand() checks for the immediate prefix first, so
the wider coverage by starts_memory_operand() is has no real effect
there, but it does matter for something like

mov %fs:$dollar, %eax

which previously wasn't accepted (but which clearly is a memory
reference - there's no point in forcing people to parenthesize the
symbol name). Similarly including '%' as an identfier for Intel syntax
had no real significance to the rest of the assembler. If '%' was to be
valid in (unquoted) symbol names, LEX_PCT would need to be defined.

Note further that this also addresses the latent issue of a sub-target
defining LEX_AT or LEX_QM to zero: That would make '@' and/or '?' no
valid part of symbol names, but would have included them in what
is_identifier_char() considers a valid part of a name. (There's a minor
related issue which is actually being eliminated: te-interix.h allows
'@' only in the middle of symbol names, yet starts_memory_operand()
specifically looks at the first character of [possibly] a symbol name.)

In parse_real_register() there's no point also checking is_name_ender()
as at this point no character is marked solely LEX_END_NAME by any sub-
target. Checking is_name_beginner() is also pointless as the hash lookup
will fail anyway for a zero-length name.

While touching the check in parse_real_register() also drop the
"allow_naked_reg" part of the condition: This has only led to
inconsistent error messages.

x86/AT&T: restrict recognition of the "absolute branch" prefix character

While in principle merely rejecting this for .insn would be sufficient
for the purposes there, be more generic and reject it for anything that
isn't going to be a branch: All elements of same-mnemonic template
groups either are branches, or are not, and the few cases possibly
requiring a 2nd parsing pass aren't affected either. This then also
improves diagnostics for misuses like

inc *%eax
incl %fs:*(%eax)
add *$1, %eax

x86: drop "shimm" special case template expansions

With VexVVVV only being boolean, the SSE shift-by-immediate instructions
don't need special casing anymore for SSE2AVX handling. Simplify the two
respective templates. (No change to generated tables.)

x86: VexVVVV is now merely a boolean

With the SDM long having dropped the NDS/NDD/DDS concept of identifying
encoding variants, we can finally do away with this concept as well. Of
the few consumers of the attribute, only an assertion was still checking
for a particular value, which we don't really need to retain.

When touching lines anyway, modernize other aspects as well. This often
improves similarity to adjacent lines.

x86: re-work build_modrm_byte()'s register assignment

The function has accumulated a number of special cases for no real
reason. Some were necessary because insn attributes (SwapSources in
particular) weren't suitably utilized instead. Note that the addition of
SwapSources actually increases consistency among the templates: Like
others which already have the attribute, these are all insns where the
VEX.VVVV-encoded register comes first (or last when looking at the SDM).

Note that the vexvvvv attribute now has merely boolean meaning anymore,
in line with the SDM long having dropped the NDS/NDD/DDS concept of
identifying encoding variants. The fallout will be taken care of
subsequently, though, to not further clutter the change here.

As to the TILEZERO special case: If more instructions like this
appeared, a new attribute would likely be the way to go. But as long as
it's only a single insn, going from the mnemonic is cheaper.

Changed ld and gas BPF tests

Recent BPF patch removed and renamed the list of relocations based on
the limitations of BPF instruction set.
This patch is a correction to the tests.

Reloc howto access broken for BPF

Forgot to change the logic to access the reloc howto from
bpf_elf_relocate_section.
Problem was introduced in previous BPF commit.

Use rust_demangle to fix a crash

PR rust/30211 points out a crash caused by a particular completion.
This turns out to happen because a Rust minsym winds up in a
C++-specific path in strncmp_iw_with_mode, which ultimately causes the
completer to pass invalid arguments to string::append.

This patch fixes the bug by reordering the language constants so that
Rust comes before C++, and then using rust_demangle.  This ensures
that minsyms are correctly marked as "Rust", avoiding this code and
thus the crash.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20367
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30211
Reviewed-By: Andrew Burgess <aburgess@redhat.com>

Make ui_out::do_progress_end 'private'

I noticed that ui_out::do_progress_end is public, just to support one
use in debuginfod-support.c.  This patch makes it private, updates
progress_info to call it from its destructor, and finally changes
debuginfod-support.c to follow.

gdb: don't use the global thread-id in the saved breakpoints file

I noticed that breakpoint::print_recreate_thread was printing the
global thread-id.  This function is used to implement the 'save
breakpoints' command, and should be writing out suitable CLI commands
for recreating the current breakpoints.  The CLI does not use global
thread-ids, but instead uses the inferior specific thread-ids,
e.g. "2.1".

After some discussion on the mailing list it was suggested that the
most consistent solution would be for the saved breakpoints file to
always contain the inferior-qualified thread-id, so the file would
include "thread 1.1" instead of just "thread 1", even when there is
only a single inferior.

So, this commit adds print_full_thread_id, which is just like the
existing print_thread_id, only it always prints the inferior-qualified
thread-id.

I then update the existing print_thread_id to make use of this new
function, and finally, I update  breakpoint::print_recreate_thread to
also use this new function.

There's a multi-inferior test that confirms the saved breakpoints file
correctly includes the fully-qualified thread-id, and I've also
updated the single inferior test gdb.base/save-bp.exp to have it
validate that the saved breakpoints file includes the
inferior-qualified thread-id, even for this single inferior case.

Revert "segfault at i386-dis.c:9815"

This reverts commit 92d450c79ad321e42f9a77692b5db10d0f7b9344.

Accessing these local var structs using a volatile qualified pointer
may indeed read the object, but I don't think changed values are
guaranteed to be written back to the object unless the actual object
is declared volatile.  That would probably slow down i386 disassembly
unacceptably.

libctf: unused variable

* ctf-archive.c (arc_mmap_writeout): Delete unused variable.

gprofng: Use prototype to call libc functions

libcollector may not link against libC.
We use dlsym() to get a function from libc.
In some files, pointers to these functions do not have prototypes.
I also moved the shared definitions to libcollector/collect.h.

gprofng/ChangeLog
2023-03-15  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

libcollector/collector.c: Add prototypes.
libcollector/dispatcher.c: Likewise.
libcollector/heaptrace.c: Likewise.
libcollector/iotrace.c: Likewise.
libcollector/linetrace.c: Likewise.
libcollector/mmaptrace.c: Likewise.
libcollector/synctrace.c: Likewise.
libcollector/collector.h: Add CALL_REAL(), NULL_PTR(), and DBG_LT.

Automatic date update in version.in

Don't declare psymbol_functions::fill_psymbol_map

psymbol_functions::fill_psymbol_map was removed, but I forgot to
remove the declaration.  This patch removes it.  Tested by rebuilding.

segfault at i386-dis.c:9815

* i386-dis.c (print_insn): Access "ins" and "priv" via volatile
pointers after second sigsetjmp return.

Enable vector register visibility in core file for AIX binutils

This patch will enable vector register visibility when AIX FOLKS do
core file analysis.

Regen ld/po/BLD-POTFILES.in

XCOFF archive sanity check

XCOFF archive elements are in a linked list.  Add a little more sanity
checking.  This of course doesn't stop the fuzzers finding a way to
make a loop, but this check is cheap.

* coff-rs6000.c (_bfd_xcoff_openr_next_archived_file): Sanity
check that next element isn't pointing back to the header.

rewrite_elf_program_header and want_p_paddr_set_to_zero

Layout in rewrite_elf_program_header is really done by lma, even if
program headers are going to have their p_paddr forced to zero.  Thus
when not matching against an existing segment, don't try to use a
"vma" from elf_segment_map.

* elf.c (is_contained_by): Replace "bed" param with "use_vaddr".
(IS_SECTION_IN_INPUT_SEGMENT): Adjust is_contained_by call.
(rewrite_elf_program_header): Always match against lma in
calls to is_contained_by using new maps.

Another sanity check for read_section_stabs_debugging_info

* rddbg.c (read_section_stabs_debugging_info): Ignore invalid
stab sections with size less than 12 bytes.

ctf segfaults

PR 30228
PR 30229
* ctf-open.c (ctf_bufopen_internal): Check for NULL cts_data.
* ctf-archive.c (ctf_arc_bufpreamble, ctf_arc_bufopen): Likewise.

Automatic date update in version.in

Remove objfile_type

This removes objfile_type, in favor of always using the per-arch
builtins.

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

Add some types to struct builtin_type

This adds some types to struct builtin_type, ensuring it contains all
the types currently used by objfile_type.

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

Rename objfile_type to builtin_type

This renames objfile_type to be an overload of builtin_type, in
preparation for their unification.

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

Use builtin type when appropriate

There are a few spots that check whether a type is objfile-owned, and
then choose either the objfile- or arch-specific builtin type.  I
don't think there is a need to do this any more (if there ever was),
because it is ok for an objfile-allocated type to refer to an
arch-allocated type.

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

Use type allocator for set types

This changes the set type creation function to accept a type
allocator, and updates all the callers.  Note that symbol readers
should generally allocate on the relevant objfile, regardless of the
underlying type of the set, which is what this patch implements.

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

Use type allocator for array types

This changes the array type creation functions to accept a type
allocator, and updates all the callers.  Note that symbol readers
should generally allocate on the relevant objfile, regardless of the
placement of the index type of the array, which is what this patch
implements.

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

Use type allocator for range types

This changes the range type creation functions to accept a type
allocator, and updates all the callers.  Note that symbol readers
should generally allocate on the relevant objfile, regardless of the
underlying type of the range, which is what this patch implements.

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

Unify arch_pointer_type and init_pointer_type

This unifies arch_pointer_type and init_pointer_type by using a type
allocator.

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

Unify arch_decfloat_type and init_decfloat_type

This unifies arch_decfloat_type and init_decfloat_type by using a type
allocator.

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

Unify arch_float_type and init_float_type

This unifies arch_float_type and init_float_type by using a type
allocator.

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

Unify arch_boolean_type and init_boolean_type

This unifies arch_boolean_type and init_boolean_type by using a type
allocator.

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

Unify arch_character_type and init_character_type

This unifies arch_character_type and init_character_type by using a
type allocator.

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

Unify arch_integer_type and init_integer_type

This unifies arch_integer_type and init_integer_type by using a type
allocator.

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

Remove init_type

This removes init_type, replacing all uses with the new type
allocator.

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

Remove arch_type

This removes arch_type, replacing all uses with the new type
allocator.

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

Reuse existing builtin types

This changes a few spots to reuse the existing builting "void" type,
rather than construct a new one.

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

Remove alloc_type

This removes alloc_type, replacing all uses with the new type
allocator.

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

Remove alloc_type_copy

This removes alloc_type_copy, replacing all uses with the new type
allocator.

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

Remove alloc_type_arch

This removes alloc_type_arch, replacing all uses with the new type
allocator.

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

Introduce type_allocator

This introduces a new type_allocator class.  This class will be used
to abstract out the placement of new types, so that type-creation code
can be simplified and shared.

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

[gdb/testsuite] Handle unbuffer_output.c for remote host

Handle $srcdir/lib/unbuffer_output.c using lappend_include_file.

Tested on x86_64-linux.

[gdb/testsuite] Handle my-syscalls.h for remote host

Handle $srcdir/lib/my-syscalls.h using lappend_include_dir.

Tested on x86_64-linux.

[gdb/testsuite] Handle attributes.h for remote host

Handle $srcdir/lib/attributes.h using lappend_include_dir.

Tested on x86_64-linux.

Automatic date update in version.in

Fix line table regression

Simon pointed out a line table regression, and after a couple of false
starts, I was able to reproduce it by hand using his instructions.

The bug is that most of the code in do_mixed_source_and_assembly uses
unrelocated addresses, but one spot does:

  pc = low;

... after the text offset has been removed.

This patch fixes the problem by introducing a new type to represent
unrelocated addresses in the line table.  This prevents this sort of
bug to some degree (it's still possible to manipulate a CORE_ADDR in a
bad way, this is unavoidable).

However, this did let the compiler flag a few spots in that function,
and now it's not possible to compare an unrelocated address from a
line table with an ordinary CORE_ADDR.

Regression tested on x86-64 Fedora 36, though note this setup never
reproduced the bug in the first place.  I also tested it by hand on
the disasm-optim test program.

Update the NetBSD system call table to add eventfd(2) and timerfd(2).

Generated from sys/sys/syscall.h revision 1.321.

gdb: introduce bp_loc_tracepoint

Since commit cb1e4e32c2d9 ("catch catch/throw/rethrow", breakpoint ->
catchpoint), this simple tracing scenario does not work:

    $ gdb/gdb -nx -q --data-directory=gdb/data-directory ./test
    Reading symbols from ./test...
    (gdb) tar rem :1234
    Remote debugging using :1234
    Reading symbols from /lib64/ld-linux-x86-64.so.2...
    (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
    0x00007ffff7fe5730 in ?? () from /lib64/ld-linux-x86-64.so.2
    (gdb) trace do_something
    Tracepoint 1 at 0x555555555144: file test.c, line 5.
    (gdb) tstart
    (gdb) continue
    Continuing.
    Target returns error code '01'.

The root cause is that the bp_location::nserted flag does not transfer
anymore from an old bp_location to the new matching one.  When a shared
library gets loaded, GDB computes new breakpoint locations for each
breakpoint in update_breakpoint_locations.  The new locations are in the
breakpoint::loc chain, while the old locations are still in the
bp_locations global vector.  Later, update_global_location_list is
called.  It tries to map old locations to new locations, and if
necessary transfer some properties, like the inserted flag.

Since commit cb1e4e32c2d9, the inserted flag isn't transferred for
locations of tracepoints.  This is because bl_address_is_meaningful used
to be implemented like this:

    static int
    breakpoint_address_is_meaningful (struct breakpoint *bpt)
    {
      enum bptype type = bpt->type;

      return (type != bp_watchpoint && type != bp_catchpoint);
    }

and was changed to this:

    static bool
    bl_address_is_meaningful (bp_location *loc)
    {
      return loc->loc_type != bp_loc_other;
    }

Because locations for tracepoints have the bp_loc_other type,
bl_address_is_meaningful started to return false for them, where it
returned true before.  This made update_global_location_list skip the
part where it calls swap_insertion.

I think this can be solved by introduced a new bp_loc_tracepoint
bp_loc_type.

I don't know if it's accurate, but my understanding is that bp_loc_type
describes roughly "how do we ask the target to insert that location".
bp_loc_software_breakpoint are inserted using
target_ops::insert_breakpoint_location.  bp_loc_hardware_breakpoint are
inserted using target_ops::insert_hw_breakpoint.
bp_loc_software_watchpoint and bp_loc_hardware_watchpoint are inserted
using target_ops::insert_watchpoint.  For all these, the address is
meaningful, as we ask the target to insert the point at a specific
address.  bp_loc_other is a catch-all for "the rest", in practice for
catchpoints that don't have a specific address (hence why
bl_address_is_meaningful returns false for them).  For instance,
inserting a signal catchpoint is done by asking the target to report
that specific signal.  GDB doesn't associate an address to that.

But tracepoints do have a meaningful address to thems, so they can't be
bp_loc_other, with that logic.  They also can't be
bp_loc_software_breakpoint, because we don't want GDB to insert
breakpoints for them (even though they might be implemented using
software breakpoints by the remote side).  So, the new bp_loc_tracepoint
type describes that the way to insert these locations is with
target_ops::download_tracepoint.  It makes bl_address_is_meaningful
return true for them.  And they'll be ignored by insert_bp_location and
GDB won't try to insert a memory breakpoint for them.

With this, I see a few instances of 'Target returns error code: 01'
disappearing from gdb.log, and the results of gdb.trace/*.exp improve a
little bit:

    -# of expected passes       3765
    +# of expected passes       3781
    -# of unexpected failures   518
    +# of unexpected failures   498

Things remain quite broken in that area though.

Change-Id: Ic40935c450410f4bfaba397c9ebc7faf97320dd3

PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp

PPC64 multiple entry points, a normal entry point and an alternate entry
point.  The alternate entry point is to setup the Table of Contents (TOC)
register before continuing at the normal entry point.  When the TOC is
already valid, the normal entry point is used, this is typically the case.
The alternate entry point is typically referred to as the global entry
point (GEP) in IBM.  The normal entry point is typically referred to as
the local entry point (LEP).

When GDB is executing the finish command in reverse, the function
finish_backward currently sets the break point at the alternate entry point.
This issue is if the function, when executing in the forward direction,
entered the function via the normal entry point, execution in the reverse
direction will never sees the break point at the alternate entry point.  In
this case, the reverse execution continues until the next break point is
encountered thus stopping at the wrong place.

This patch adds a new address to struct execution_control_state to hold the
address of the alternate entry point (GEP).  The finish_backwards function
is updated, if the stopping point is between the normal entry point (LEP)
and the end of the function, a breakpoint is set at the normal entry point.
If the stopping point is between the entry points, a breakpoint is set at
the alternate entry point.  This ensures that GDB will always stop at the
normal entry point.  If the function did enter via the alternate entry
point, GDB will detect that and continue to execute backwards in the
function until the alternate entry point is reached.

The patch fixes the behavior of the reverse-finish command on PowerPC to
match the behavior of the command on other platforms, specifically X86.
The patch does not change the behavior of the command on X86.

A new test is added to verify the reverse-finish command on PowerPC
correctly stops at the instruction where the function call is made.

The patch fixes 11 regression errors in test gdb.reverse/finish-precsave.exp
and 11 regression errors in test gdb.reverse/finish-reverse.exp.

The patch has been tested on Power 10 and X86 processor with no new
regression failures.

Move step_until procedure

Procedure step_until from test gdb.reverse/step-indirect-call-thunk.exp
is moved to lib/gdb.exp and renamed repeat_cmd_until.  The existing procedure
gdb_step_until in lib/gdb.exp is simpler variant of the new repeat_cmd_until
procedure.  The existing procedure gdb_step_until is changed to just call
the new repeat_cmd_until procedure with the command set to "step" and an
optional CURRENT string.  The default CURRENT string is set to "\}" to work
with the existing uses of procedure gdb_step_until.

[gdb/testsuite] Fix regexp in gdb.arch/ftrace-insn-reloc.exp

With test-case gdb.arch/ftrace-insn-reloc.exp and host board
local-remote-host-notty and target board native-gdbserver I run into:
...
(gdb) info sharedlibrary^M
From To    Syms Read   Shared Object Library^M
$hex $hex  Yes         /lib64/ld-linux-x86-64.so.2^M
$hex $hex  Yes         /home/remote-host/libinproctrace.so^M
$hex $hex  Yes         /lib64/libm.so.6^M
$hex $hex  Yes         /lib64/libc.so.6^M
$hex $hex  Yes         /lib64/libdl.so.2^M
$hex $hex  Yes (*)     /usr/lib64/libstdc++.so.6^M
$hex $hex  Yes (*)     /lib64/libgcc_s.so.1^M
$hex $hex  Yes         /lib64/libpthread.so.0^M
(*): Shared library is missing debugging information.^M
(gdb) FAIL: gdb.arch/ftrace-insn-reloc.exp: IPA loaded
...
due to trying to match libinproctrace.so using the target path, while the
command lists it using the host path.

Fix this by making the regexp less strict.

Tested on x86_64-linux.

[gdb/testsuite] Handle remote host in gdb_load_shlib

With test-case gdb.arch/ftrace-insn-reloc.exp and host board
local-remote-host-notty and target board native-gdbserver I run into:
...
(gdb) tstart^M
Target returns error code '.In-process agent library not loaded in process.  \
  Fast and static trace points unavailable.'.^M
(gdb) FAIL: gdb.arch/ftrace-insn-reloc.exp: start trace experiment
...

Fix this by:
- handling remote host in gdb_load_shlib, and
- moving the gdb_load_shlib to after the clean_restart, such that the
  set solib-search-path can take effect.

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.arch/i386-biarch-core.exp for remote host

Fix test-case gdb.arch/i386-biarch-core.exp using gdb_download_remote host.

Tested on x86_64-linux.

[gdb/testsuite] Handle REMOTE_HOST_USERNAME in local-remote-host

Handle REMOTE_HOST_USERNAME in local-remote-host, similar to how that's done for
REMOTE_TARGET_USERNAME in remote-gdbserver-on-localhost.

This helps to keep the home dir clean.

Since the setup makes $build/gdb/testsuite on build unreadable for the remote
host, we run into permission problems for GDB and the data-directory, so fix
this (as was done for gdbserver in gdbserver-base.exp) using file normalize.

Tested on x86_64-linux.

[gdb/testsuite] Set remotedir by default in some boards

When doing a gdb_simple_compile, and downloading the resulting exec $obj
to target the result $target_obj may be a relative file path, which may give
problems when trying to do:
...
remote_exec target $target_obj
...

Fix/workaround this on some target boards by setting remotedir by default, and
add a corresponding test in gdb.testsuite/board-sanity.exp.

This doesn't work for host/target board local-remote-host-native, so xfail this.

Tested on x86_64-linux.

[gdb/testsuite] Fix have_avx for remote target

In proc have_avx we compile some source into an exec, resulting in a file $obj
on build, and then attempt to execute it on target:
...
    set result [remote_exec target $obj]
...

Fix this by using gdb_remote_download target.

Likewise in a few other procs that use "remote_exec target".

Tested on x86_64-linux.

[gdb/testsuite] Handle precise-aligned-alloc.c for remote host

With test-case gdb.arch/i386-sse.exp (and likewise gdb.arch/i386-avx.exp) and
host board local-remote-host-notty and target board native-gdbserver I run
into:
...
gdb compile failed, i386-sse.c:68:10: fatal error: \
  ../lib/precise-aligned-alloc.c: No such file or directory
 #include "../lib/precise-aligned-alloc.c"
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
...

Fix this using '#include "precise-aligned-alloc.c"' and making that work with
non-remote and remote host.

Tested on x86_64-linux.

[gdb/testsuite] Handle remote host in escape_for_host

With test-case gdb.arch/ftrace-insn-reloc.exp and host board
local-remote-host-notty and target board native-gdbserver, I run into:
...
FAIL: gdb.arch/ftrace-insn-reloc.exp: IPA loaded
...
due to having:
...
$ readelf -d ftrace-insn-reloc | grep RUNPATH
 0x000000000000001d (RUNPATH)            Library runpath: []
...
instead of:
...
$ readelf -d ftrace-insn-reloc | grep RUNPATH
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN]
...

Handle this in escape_for_host.

Tested on x86_64-linux.