Automatic date update in version.in

bfd-in2.h BFD_RELOC_* comments

I noticed the regenerated BFD_RELOC_MICROBLAZE_32_NONE comment didn't
match that committed to bfd-in2.h, and was just going to regen
bfd-in2.h but then decided to do something about the silly formatting
of these comments in bfd-in2.h.  eg. the BFD_RELOC_MICROBLAZE_32_NONE
comment:

-/* This is a 32 bit reloc that stores the 32 bit pc relative
-value in two words (with an imm instruction).No relocation is
-done here - only used for relaxing  */
+  /* This is a 32 bit reloc that stores the 32 bit pc relative value in
+     two words (with an imm instruction).  No relocation is done here -
+     only used for relaxing.  */
   BFD_RELOC_MICROBLAZE_32_NONE,

You'll notice how the second and third line of the original comment
aren't indented properly relative to the first line, and the whole
comment needs to be indented to match the code.

I've also edited reloc.c ENUMDOC paragraphs.  Some of these had excess
indentation, presumably in an attempt to properly indent bfd-in2.h
comments but that fails due to chew.c removing leading whitespace
early by skip_white_and_stars.  COMMENT was used in reloc.c to add
extra blank lines in bfd-in2.h.  I've removed them too as I don't
think they add anything to readability of that file.  (Perhaps more
usefully, they also add blank lines to libbfd.h separating relocs for
one target from others, but this isn't done consistently.)

* doc/chew.c (drop, idrop): Move earlier.
(strip_trailing_newlines): Check index before accessing array,
not after.
(wrap_comment): New function.
(main): Add "wrap_comment" intrinsic.
* doc/proto.str (ENUMDOC): Use wrap_comment.
(make_enum_header, ENDSENUM): Put start and end braces on
separate lines.
* reloc.c: Remove uses of COMMENT and edit ENUMDOC paragraphs.
* libbfd.h: Regenerate.
* bfd-in2.h: Regenerate.

Style history variable output

When printing a value, I think the history reference -- the "$1" in
the output -- should be styled using the "variable" style.  This patch
implements this.

Automatic date update in version.in

gdb: fix owner passed to remove_target_sections in clear_solib

Commit 8971d2788e7 ("gdb: link so_list using intrusive_list") introduced
a bug in clear_solib.  Instead of passing an `so_list *` to
remove_target_sections, it passed an `so_list **`.  This was not caught
by the compiler, because remove_target_sections takes a `void *` as the
"owner", so you can pass it any pointer and it won't complain.

This happened because I previously had a patch to change the type of the
disposer parameter to be a reference rather than a pointer, so had to
change `so` to `&so`.  When dropping that patch, I forgot to revert this
bit and / or it got re-introduced when handling subsequent merge
conflicts.  And I didn't properly retest.

Fix that, but try to make things less error prone.  Add a union to
represent the possible owner kinds for a target_section.  Trying to pass
a pointer to another type than those will not compile.

Change-Id: I600cab5ea0408ccc5638467b760768161ca3036c

Automatic date update in version.in

[gdb/cli] Allow source-highlight to autodetect language

Currently when gdb asks the source-highlight library to highlight a file, it
tells it what language file to use.

For instance, if gdb learns from the debug info that the file is language_c,
the language file "c.lang" is used.  This mapping is hardcoded in
get_language_name.

However, if gdb doesn't know what language file to use, it falls back to using
python pygments, and in absence of that, unhighlighted source text.

In the case of python pygments, it autodetects which language to use based on
the file name.

Add the same capability when using the source-highlight library.

Tested on x86_64-linux.

Verified that it works by:
- making get_language_name return nullptr for language_c, and
- checking that source-highlight still manages to highlight a hello world.

Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR cli/30966
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30966

Don't include cooked-index.h from dwarf2/read.h

dwarf2/read.h includes cooked-index.h, but it doesn't need to.  This
patch removes the inclusion from this header, and adds one to
index-write.c to make up for the absence.

gas: testsuite: microblaze: cosmetic fix

This patch makes a cosmetic change to the reloc_weaksym.s
by making the bneid instruction all lower case like all of
the other instructions in the example.

Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>

libctf: fix creation-time parent/child dict confusions

The fixes applied a few years ago to resolve confusions between parent and
child dicts at lookup time also apply in various forms to creation.  In
general, if you have a type in a parent dict ctf_imported into a child and
you do something to it, and the parent dict is writable (created via
ctf_create, not opened via ctf_open*) it should work just the same to make
changes to that type via a child dict as it does to make the change
to the parent dict directly -- and nothing you're prohibited from doing
to the parent dict when done directly should be allowed just because
you're doing it via a child.

Specifically, the following don't work when doing things from the child, but
should:

 - adding a member of a type in the parent to a struct or union in the
   parent via ctf_add_member or ctf_add_member_offset: this yields
   ECTF_BADID

 - adding a member of a type in the parent to a struct or union in the
   parent via ctf_add_member_encoded: this dumps core (!).

 - adding an enumerand to an enumerator in the parent: this yields
   ECTF_BADID

 - setting the properties of an array in the parent via ctf_set_array;
   this yields ECTF_BADID

Relatedly, some things work when doing things via a child that should fail,
yielding a CTF dictionary with invalid content (readable, but meaningless):
in particular, you can add a child type to a struct in the parent via
any of the ctf_add_member* family and nothing complains at all, even though
you should never be able to add references to children to parents (since any
given parent can be associated with many different children).

A family of tests is added to check each of these cases independently, since
some can result in coredumps and it would be nice to test the other cases
even if some dump core.  They use a common library to do all the actual
work.  The set of affected API calls was determined by code inspection
(auditing all calls to ctf_dtd_lookup): it's possible that I missed a few,
but I doubt it, since other cases use ctf_lookup* functions, which already
climb to the parent where appropriate.

libctf/ChangeLog:

PR libctf/30985
* ctf-create.c (ctf_dtd_lookup): Traverse to parents if necessary.
(ctf_set_array): Likewise.  Report errors on the child; require
both parent and child to be writable.
(ctf_add_enumerator): Likewise.
(ctf_add_member_offset): Likewise.  Prohibit addition of child types
to structs in the parent.
(ctf_add_member_encoded): Do not dereference a NULL dtd: report
ECTF_BADID instead.
* ctf-string.c (ctf_str_add_ref_internal): Report ENOMEM on the
dict if addition of a string ref fails.
* testsuite/libctf-writable/parent-child-dtd-crash-lib.c: New library.
* testsuite/libctf-writable/parent-child-dtd-enum.*: New test.
* testsuite/libctf-writable/parent-child-dtd-enumerator.*: New test.
* testsuite/libctf-writable/parent-child-dtd-member-encoded.*: New test.
* testsuite/libctf-writable/parent-child-dtd-member-offset.*: New test.
* testsuite/libctf-writable/parent-child-dtd-set-array.*: New test.
* testsuite/libctf-writable/parent-child-dtd-struct.*: New test.
* testsuite/libctf-writable/parent-child-dtd-union.*: New test.

bfd: microblaze: Add 32_NONE reloc type

This patch adds the R_MICROBLAZE_32_NONE relocation type.
This is a 32-bit reloc that stores the 32-bit pc relative
value in two words (with an imm instruction).

Add test case to gas test suite.

Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>

[gdb/symtab] Fix more style issues in v9 .gdb_index section support

I noticed a few more style issues in commit 8b9c08eddac ("[gdb/symtab] Add
name_of_main and language_of_main to the DWARF index"), after checking it
with gcc's check_GNU_style.{sh,py}.

Fix these.

Build on x86_64-linux.

opcodes: microblaze: Fix bit masking bug

There is currently a bug in the bit masking for the barrel shift
instructions because the bit mask is not including all of the
register bits which must be zero.  With this patch, the disassembler
can be sure that the 32-bit value is indeed a barrel shift instruction
and not a data value in memory.

This fix can be verified by assembling and disassembling the following:

.text
.long 0x65005f5f

With this patch, the bug is fixed, and the objdump will know that
0x65005f5f is not a barrel shift instruction.

Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>

Automatic date update in version.in

Fix race in DWARF reader

The recent change to record the DWARF language in the per-CU data
yielded a race warning in my testing:

ThreadSanitizer: data race ../../binutils-gdb/gdb/dwarf2/read.c:21779 in prepare_one_comp_unit

This patch fixes the bug by applying the same style of fix that was
done for the ordinary (gdb) language.

I wonder if this code could be improved.  Requiring an atomic for the
language in particular seems unfortunate, as it is often consulted
during index finalization.  However, I haven't investigated this.

Regression tested on x86-64 Fedora 38.

Reviewed-by: Tom de Vries <tdevries@suse.de>

PR30984, assertion fail elf.c:8485

PR 30984
* ldelf.c (ldelf_place_orphan): Don't allow bfd_abs_section as
a potential output section.

gdb: fix no-expat build of solib-target.c

Fixes:

      CXX    solib-target.o
    /home/smarchi/src/binutils-gdb/gdb/solib-target.c:57:8: error: ‘lm_info_vector’ does not name a type
       57 | static lm_info_vector
          |        ^~~~~~~~~~~~~~
    /home/smarchi/src/binutils-gdb/gdb/solib-target.c: In function ‘intrusive_list<shobj> solib_target_current_sos()’:
    /home/smarchi/src/binutils-gdb/gdb/solib-target.c:244:7: error: ‘solib_target_parse_libraries’ was not declared in this scope
      244 |     = solib_target_parse_libraries (library_document->data ());
          |       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~

Change-Id: Ib477d3343b401017d79729118242143bc95f24b2

ld: fix typo in ld.texi metdata->metadata

gdb: rename struct so_list to shobj

Now that so_list lists are implemented using intrusive_list, it doesn't
really make sense for the element type to be named "_list".  Rename to
just `struct shobj` (`struct so` was deemed to be not greppable enough).

Change-Id: I1063061901298bb40fee73bf0cce44cd12154c0e
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: remove free_so function

Remove this function, replace it with deleting the so_list in callers.

Change-Id: Idbd0cb84674ade1d8e17af471550dbd388264f60
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: don't call so_list::clear in free_so

I think this `so.clear ()` call is not useful.

 - so_list::clear deletes some things that now get automatically deleted
   when the so_list gets deleted right after in free_so.
 - so_list::clear resets some scalar fields of so_list, which we don't
   really care about since the so_list gets deleted right after.
 - so_list::clear calls target_so_ops::clear_so, of which there is a
   single implementation, svr4_clear_so.  That implementation just
   resets a field in lm_info_svr4, which we don't care about, as it will
   get deleted when the so_list gets deleted right after.

Change-Id: Ie4d72f2a04a4129e55c460bb5c69bc0af0d12b32
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: link so_list using intrusive_list

Replace the hand-made linked list implementation with intrusive_list,
simplying management of list items.

Change-Id: I7f55fd88325bb197cc655c9be5a2ec966d8cc48d
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: make so_list::{so_original_name,so_name} std::strings

Change these two fields, simplifying memory management and copying.

Change-Id: If2559284c515721e71e1ef56ada8b64667eebe55
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: make so_list::abfd a gdb_bfd_ref_ptr

Change the field from a `bfd *` to a gdb_bfd_ref_ptr to automatically
manage the reference.

Change-Id: I3ace18bea985bc194c5e67bb559eec567e258950
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: make so_list::sections not a pointer

Make the field a vector directly, instead of a pointer to a vector.
This was needed when so_list had to be a trivial type, which is not the
case anymore.

Change-Id: I79a8378ce0d0d1e2206ca08a273ebf332cb3ba14
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: remove target_section_table typedef

Remove this typedef.  I think that hiding the real type (std::vector)
behind a typedef just hinders readability.

Change-Id: I80949da3392f60a2826c56c268e0ec6f503ad79f
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: make clear_so a method of struct so_list

... just because it seems to make sense to do so.

Change-Id: Ie283c92d9b90c54e3deee96a43c6a942d8b5910b
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: make so_list::lm_info a unique_ptr

Make it a unique_ptr, so it gets automatically deleted when the so_list
is deleted.

Change-Id: Ib62d60ae2a80656239860b80e4359121c93da13d
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: remove lm_info_vector typedef

I think this typedef hinders readability.  First, it's not well named
(it's not clear it contains lm_info_target objects).  And hiding the
fact that it contains unique pointers is not very useful either.  I was
looking at the code in solib_target_current_sos where the unique
pointers get moved from the vector, and it wasn't obvious at all what
the source of the move was.

Change-Id: I4a5cda7c90554f018b7c466b1535b41d69cbcbe7
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: make solib-rocm not use so_list internally

Same rationale as the previous patch, but for solib-rocm.

 - Introduce rocm_so, which is a name a unique_name (see comment in
   rocm_update_solib_list for that) and a unique_ptr to the
   lm_info_svr4.
 - Change the internal lists from so_list lists to vectors of rocm_so.
 - Remove rocm_free_solib_list, as everything is automatic now.
 - Replace rocm_solib_copy_list with so_list_from_rocm_sos.

Change-Id: I71e06e3ea22d6420c9e4e500501c06e9a13398a8
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: make solib-svr4 not use so_list internally

A subsequent patch makes use of non-trivial types in struct so_list.
This trips on the fact that svr4_copy_library_list uses memcpy to copy
so_list objects:

      so_list *newobj = new so_list;
      memcpy (newobj, src, sizeof (struct so_list));

solib-svr4 maintains lists of so_list objects in its own internal data
structures.  When requested to return a list of so_list objects (through
target_so_ops::current_sos), it duplicates the internal so_list lists,
using memcpy.  When changing so_list to make it non-trivial, we would
need to replace this use of memcpy somehow.  That would mean making
so_list copyable, with all the complexity that entails, just to satisfy
this internal usage of solib-svr4 (and solib-rocm, which does the same).

Change solib-svr4 to use its own data type for its internal lists.  The
use of so_list is a bit overkill anyway, as most fields of so_list are
irrelevant for this internal use.

 - Introduce svr4_so, which contains just an std::string for the name
   and a unique_ptr for the lm_info.
 - Change the internal so_list lists to be std::vector<svr4_so>.  Vector
   seems like a good choice for this, we don't need to insert/remove
   elements in the middle of these internal lists.
 - Remove svr4_free_library_list, free_solib_lists and ~svr4_info, as
   everything is managed automatically now.
 - Replace svr4_copy_library_list (which duplicated internal lists in
   order to return them to the core) with so_list_from_svr4_sos, which
   creates an so_list list from a vector of svr4_so.
 - Generalize svr4_same a bit, because find_debug_base_for_solib now
   needs to compare an so_list and an svr4_so to see if they are the
   same.

Change-Id: I6012e48e07aace2a8172b74b389f9547ce777877
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: use gdb::checked_static_cast when casting lm_info

Now that the lm_info class hierarchy has a virtual destructor and
therefore a vtable, use checked_static_cast instead of C-style cases to
ensure (when building in dev mode) that we're casting to the right kind
of lm_info.

Change-Id: I9a99b7d6aa9a44edbe76377d57a7008cfb75a744
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: remove target_so_ops::free_so

target_so_ops::free_so is responsible for freeing the specific lm_info
object.  All implementations basically just call delete.  Remove that
method, make the destructor of lm_info virtual, and call delete directly
from the free_so function.  Make the sub-classes final, just because
it's good practice.

Change-Id: Iee1fd4861c75034a9e41a656add8ed8dfd8964ee
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: rename lm_info_base to lm_info

The base class doesn't need to have "_base" in its name, all the
sub-classes have a specific suffix.

Change-Id: I87652105cfedd87898770a81f0eda343ff7f2bdb
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: allocate so_list with new, deallocate with delete

Initialize all fields in the class declaration, change allocations to
use "new", change deallocations to use "delete".  This is needed by a
subsequent patches that use C++ stuff in so_list.

Change-Id: I4b140d9f1ec9ff809554a056f76e3eb2b9e23222
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: make get_cbfd_soname_build_id static

It is only used in solib.c.

Change-Id: I43461d13d84d65c4f6913d4033678d8983b9910b
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdbsupport: use "reference" and "pointer" type aliases in intrusive_list

It seems to me like the code should used the defined type aliases, for
consistency.

Change-Id: Ib52493ff18ad29464405275bc10a0c6704ed39e9
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: replace some so_list parameters to use references

A subsequent patch changes so_list to be linked using
intrusive_list.  Iterating an intrusive_list yields some references to
the list elements.  Convert some functions accepting so_list objects to
take references, to make things easier and more natural.  Add const
where possible and convenient.

Change-Id: Id5ab5339c3eb6432e809ad14782952d6a45806f3
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: make interps_notify work with references

A subsequent patch changes the interp::on_solib_loaded and
interp::on_solib_unloaded methods to take references.  This highlighted
that interps_notify did not work with reference parameters.

Fix that by changing interps_notify's `args` arg to be a universal
reference (&&).  Change the type of the method to be auto-deduced as an
additional template parameter, otherwise the signature of the callback
function would never match:

      CXX    interps.o
    /home/simark/src/binutils-gdb/gdb/interps.c: In function ‘void interps_notify_signal_received(gdb_signal)’:
    /home/simark/src/binutils-gdb/gdb/interps.c:378:18: error: no matching function for call to ‘interps_notify(void (interp::*)(gdb_signal), gdb_signal&)’
      378 |   interps_notify (&interp::on_signal_received, sig);
          |   ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    /home/simark/src/binutils-gdb/gdb/interps.c:363:1: note: candidate: ‘template<class ... Args> void interps_notify(void (interp::*)(Args ...), Args&& ...)’
      363 | interps_notify (void (interp::*method) (Args...), Args&&... args)
          | ^~~~~~~~~~~~~~
    /home/simark/src/binutils-gdb/gdb/interps.c:363:1: note:   template argument deduction/substitution failed:
    /home/simark/src/binutils-gdb/gdb/interps.c:378:18: note:   inconsistent parameter pack deduction with ‘gdb_signal’ and ‘gdb_signal&’
      378 |   interps_notify (&interp::on_signal_received, sig);
          |   ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Change-Id: I0cd9378e24ef039f30f8e14f054f8d7fb539c838
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: add program_space parameter to target_so_ops::clear_solib

The clear_solib is implicitly meant to clear the resources associated to
the current program space (that's what the solib implementations that
actually support multi-program-space / multi-inferior do).  Make that
explicit by adding a program_space parameter and pass down
current_program_space in call sites.  The implementation of the
clear_solib callbacks is fairly simple, I don't think any of them rely
on global state other than accessing current_program_space.

Change-Id: I8d0cc4db7b4f8db8d7452879c0c62db03269bf46
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

gdb: remove empty clear_solib functions

Make the target_so_ops::clear_solib method optional, remove two empty
implementations.

Change-Id: Ifda297d50c74327d337091c58cdb5b3b60382591
Approved-By: Pedro Alves <pedro@palves.net>
Reviewed-By: Reviewed-By: Lancelot Six <lancelot.six@amd.com>

RISC-V: Don't do undefweak relaxations for the linker_def symbols.

I get the following truncated errors recently when running riscv-gnu-toolchain
regressions,

/scratch/riscv-gnu-toolchain/regression/build/linux-rv32imafdc-ilp32d-medlow/build-glibc-linux-rv32imafdc-ilp32d/libc.a(libc-start.o): in function `elf_irela':
/scratch/riscv-gnu-toolchain/glibc/csu/../sysdeps/riscv/dl-irel.h:47:(.text+0x88): relocation truncated to fit: R_RISCV_GPREL_I against symbol `__ehdr_start' defined in .note.ABI-tag section in /scratch/riscv-gnu-toolchain/regression/build/linux-rv32imafdc-ilp32d-medlow/build-glibc-linux-rv32imafdc-ilp32d/elf/sln

The linker_def symbols like __ehdr_start that may be undefweak in early stages
of linking, including relax stage, but are guaranteed to be defined later.
Therefore, it seems like we shouldn't do the undefweak relaxations for these
kinds of symbols since they may be defined after relaxations.

bfd/
* elfnn-riscv.c (_bfd_riscv_relax_section): Don't do undefweak
relaxations for the linker_def symbols.

RISC-V: Remove semicolons from DECLARE_INSN

This is for consistency and to prevent possible unnecessary errors due
to this inconsistency.

include/ChangeLog:

* opcode/riscv-opc.h (DECLARE_INSN): Remove semicolons from the
end of each entry.

Automatic date update in version.in

gdb/testsuite/gdb.rocm: Fix incorrect use of continue N in multi-inferior-gpu.exp

The gdb.rocm/multi-inferior-gpu.exp testcase uses a "continue $thread"
command, but this is incorrect.  If "continue" is given an argument, it
sets the ignore count of the breakpoint the thread stopped at.

For this testcase it does not really matter since the breakpoint is not
meant to be hit anymore, so whatever the ignore count is won't influence
the outcome of the test.  It is worth fixing nevertheless.

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

sim/riscv: fix JALR instruction simulation

Fix 32bit 'jalr rd,ra,imm' integer instruction, where RD was written
before using it to calculate destination address.

This commit also improves testutils.inc for riscv; make use of
pushsection and popsection when adding things to .data, and setup the
%gp global pointer register within the 'start' macro.

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

libctf: check for problems with error returns

We do this as a writable test because the only known-affected platforms
(with ssize_t longer than unsigned long) use PE, and we do not have support
for CTF linkage in the PE linker yet.

PR libctf/30836
* libctf/testsuite/libctf-writable/libctf-errors.*: New test.

gdb/testsuite/gdb.rocm: Check value returned by hipDeviceSynchronize

Functions of the hip runtime returning a hipError_t can be marked
nodiscard depending on the configuration[1] (when compiled with C++17).

This patch makes sure that we always check the value returned by
hipDeviceSynchronize and friends, and print an error message when
appropriate.  This avoid a wall of warnings when running the testsuite
if the compiler defaults to using C++17.

It is always a good practice to check the return values anyway.

[1] https://github.com/ROCm-Developer-Tools/HIP/blob/docs/5.7.1/include/hip/hip_runtime_api.h#L203-L218

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

libctf: Return CTF_ERR in ctf_type_resolve_unsliced PR 30836

In commit 998a4f589d68503f79695f180fdf1742eeb0a39d, all but one return
statement was updated to return the error proper value. This commit
rectifies that missed return statement.

libctf/
ctf-types.c (ctf_type_resolve_unsliced): Return CTF_ERR on error.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

[gdb/testsuite] Fix gdb.base/jit-bfd-name.exp

When running test-case gdb.base/jit-bfd-name.exp, I run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.base/jit-bfd-name.exp.
ERROR: can't read "start": no such variable
...

The problem is that commit c96ceed9dce ("gdb: include the end address in
in-memory bfd filenames") introduced a use of variable start, but not a
definition.

Fix this by adding the missing definition.

Tested on x86_64-linux.

[gdb/symtab] Fix two style issues in gdb/dwarf2/index-write.c

While reviewing gdb/dwarf2/index-write.c I noticed two style issues.

Fix these.

Tested on x86_64-linux.

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

[gdb/symtab] Fix style issues in v9 .gdb_index section support

Post-commit review pointed out a few style issues in commit 8b9c08eddac
("[gdb/symtab] Add name_of_main and language_of_main to the DWARF index").

Fix these.

Tested on x86_64-linux.

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

RISC-V: Make sure rv32q conflict won't affect the zfa gas testcases.

According to the commit 51498ab9abc6, the q extension was no longer allowed
for rv32 since version 2.2.  Therefore, make sure the version of q is larger
than 2.2, in case the new extension conflict breaks the toolchain regressions,
which built with the old -misa-spec.

gas/
* testsuite/gas/riscv/zfa-zvfh.d: Set q to v2.2.
* testsuite/gas/riscv/zfa.d: Likewise.

LoongArch: Correct comments.

Automatic date update in version.in

gas: testsuite: microblaze: Add new bit-field tests

This patch adds new gas tests for the
microblaze bsefi and bsifi instructions.

Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>

gdb: include the end address in in-memory bfd filenames

Commit

    66984afd29e gdb: include the base address in in-memory bfd filenames

added the base address to in-memory bfd filenames.  Also add the end
address to allow dumping the in-memory bfd using the 'dump memory'
command.

libctf: Sanitize error types for PR 30836

Made sure there is no implicit conversion between signed and unsigned
return value for functions setting the ctf_errno value.
An example of the problem is that in ctf_member_next, the "offset" value
is either 0L or (ctf_id_t)-1L, but it should have been 0L or -1L.
The issue was discovered while building a 64 bit ld binary to be
executed on the Windows platform.
Example object file that demonstrates the issue is attached in the PR.

libctf/
Affected functions adjusted.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Co-Authored-By: Yvan ROUX <yvan.roux@foss.st.com>

Update the documentation of the LINKER_VERSIOn script command to actually mention the name of the command.

[gdb/cli] Keep track of styling failures in source_cache

In source_cache::ensure, keep track of which files failed to be styled, and
don't attempt to style them again in case the file dropped out of the cache.

Tested on x86_64-linux.

Reviewed-By: Lancelot Six <lancelot.six@amd.com>

[gdb/cli] Factor out try_source_highlight

Function source_cache::ensure contains some code using the GNU
source-highlight library.

The code is a sizable part of the function, and contains conditional
compilation in a slightly convoluted way:
...
       if (!already_styled)
 #endif /* HAVE_SOURCE_HIGHLIGHT */
       {
...

Fix this by factoring out the code into new function try_source_highlight,
such that:
- source_cache::ensure is easier to read, and
- the conditional compilation is at the level of the function body.

Tested on x86_64-linux.

Reviewed-By: Lancelot Six <lancelot.six@amd.com>

[gdb/cli] Skip string copy in source_cache::ensure

In function source_cache::ensure we have:
...
        std::ostringstream output;
      ...
      contents = output.str ();
...
The last line causes an unnecessary string copy.

C++20 allows us to skip it, like this:
...
      contents = std::move (output).str ();
...

Use the more efficient solution.

Tested on x86_64-linux.

Reviewed-By: Lancelot Six <lancelot.six@amd.com>

LoongArch: readelf -d RELASZ excludes .rela.plt size

Before, readelf -d RELASZ is the sum of .rela.dyn size and .rela.plt size.
To consistent with LoongArch lld, RELASZ chang to only the size of .rela.dyn.

asan: Invalid free in alpha_ecoff_get_relocated_section_contents

This fixes an ancient bug in commit a3a33af390 (which makes me think
this code has never been used).

* coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Iterate
through reloc_vector using a temp.

RISC-V: Fix typo

include/ChangeLog:

* opcode/riscv-opc.h: Fix typo.

nat/x86-cpuid.h: Remove non-x86 fallbacks

This header is only suitable for use on x86 hosts and is only included
there, so these fallbacks should not be needed.

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

Automatic date update in version.in

gdb: remove unnecessary declarations in target.c

I found that these local declarations were not needed, remove them.
Tested by rebuilding.

Change-Id: I8d4fd0839ee1063b91dc002216d683aee0d4be22

Have DAP handle non-Value results from 'children'

A pretty-printer's 'children' method may return values other than a
gdb.Value -- it may return any value that can be converted to a
gdb.Value.

I noticed that this case did not work for DAP.  This patch fixes the
problem.

Handle gdb.LazyString in DAP

Andry pointed out that the DAP code did not properly handle
gdb.LazyString results from a pretty-printer, yielding:

    TypeError: Object of type LazyString is not JSON serializable

This patch fixes the problem, partly with a small patch in varref.py,
but mainly by implementing tp_str for LazyString.

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

Fix register-setting response from DAP

Andry noticed that given a DAP setExpression request, where the
expression to set is a register, DAP will return the wrong value -- it
will return the old value, not the updated one.

This happens because gdb.Value.assign (which was recently added for
DAP) does not update the value.

In this patch, I chose to have the assign method update the Value
in-place.  It's also possible to have it return a new value, but this
didn't seem very useful to me.

Fix: GNU-ld: ARM: Issues when trying to set target output architecture

  PR 28910
  * elf32-arm.c (elf32_arm_merge_private_bfd_data): Do not set output flags if the input flags have not been set.

Fix: GNU-ld: ARM: Issues when trying to set target output architecture

  PR 28910
  * lexsup.c (ld_options): Require that the --architecture option is given exactly two dashes, so that it does not become confused with the -a option.

Add DAP scope cache

Andry Ogorodnik, a co-worker, noticed that multiple "scopes" requests
with the same frame would yield different variableReference values in
the response.

This patch adds a regression test for this, and adds a scope cache in
scopes.py, ensuring that multiple identical requests will get the same
response.

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

[gdb/symtab] Work around PR gas/29517

When using glibc debuginfo generated with gas 2.39, we run into PR gas/29517:
...
$ gdb -q -batch a.out -ex start -ex "p (char *)strstr (\"haha\", \"ah\")"
Temporary breakpoint 1 at 0x40051b: file hello.c, line 6.

Temporary breakpoint 1, main () at hello.c:6
6   printf ("hello\n");
Invalid cast.
...
while without glibc debuginfo installed we get the expected result:
...
$n = 0x7ffff7daa1b1 "aha"
...
and likewise with glibc debuginfo generated with gas 2.40.

The strstr ifunc resolves to __strstr_sse2_unaligned.  The problem is that gas
generates dwarf that states that the return type is void:
...
<1><3e1e58>: Abbrev Number: 2 (DW_TAG_subprogram)
    <3e1e59>   DW_AT_name        : __strstr_sse2_unaligned
    <3e1e5d>   DW_AT_external    : 1
    <3e1e5e>   DW_AT_low_pc      : 0xbbd2e
    <3e1e66>   DW_AT_high_pc     : 0xbc1c3
...
while the return type should be a DW_TAG_unspecified_type, as is the case
with gas 2.40.

We can still use the workaround of casting to another function type for both
__strstr_sse2_unaligned:
...
(gdb) p ((char * (*) (const char *, const char *))__strstr_sse2_unaligned) \
  ("haha", "ah")
$n = 0x7ffff7daa211 "aha"
...
and strstr (which requires using *strstr to dereference the ifunc before we
cast):
...
gdb) p ((char * (*) (const char *, const char *))*strstr) ("haha", "ah")
$n = 0x7ffff7daa251 "aha"
...
but that's a bit cumbersome to use.

Work around this in the dwarf reader, such that we have instead:
...
(gdb) p (char *)strstr ("haha", "ah")
$n = 0x7ffff7daa1b1 "aha"
...

This also requires fixing producer_is_gcc to stop returning true for
producer "GNU AS 2.39.0".

Tested on x86_64-linux.

Approved-By: Andrew Burgess <aburgess@redhat.com>
PR symtab/30911
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30911

Only allow closure lookup by address if there are threads displaced-stepping

Since commit 1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, we have an assertion in
displaced_step_buffers::copy_insn_closure_by_addr that makes sure a closure
is available whenever we have a match between the provided address argument and
the buffer address.

That is fine, but the report in PR30872 shows this assertion triggering when
it really shouldn't. After some investigation, here's what I found out.

The 32-bit Arm architecture is the only one that calls
gdbarch_displaced_step_copy_insn_closure_by_addr directly, and that's because
32-bit Arm needs to figure out the thumb state of the original instruction
that we displaced-stepped through the displaced-step buffer.

Before the assertion was put in place by commit
1e5ccb9c5ff4fd8ade4a8694676f99f4abf2d679, there was the possibility of
getting nullptr back, which meant we were not doing a displaced-stepping
operation.

Now, with the assertion in place, this is running into issues.

It looks like displaced_step_buffers::copy_insn_closure_by_addr is
being used to return a couple different answers depending on the
state we're in:

1 - If we are actively displaced-stepping, then copy_insn_closure_by_addr
is supposed to return a valid closure for us, so we can determine the
thumb mode.

2 - If we are not actively displaced-stepping, then copy_insn_closure_by_addr
should return nullptr to signal that there isn't any displaced-step buffers
in use, because we don't have a valid closure (but we should always have
this).

Since the displaced-step buffers are always allocated, but not always used,
that means the buffers will always contain data. In particular, the buffer
addr field cannot be used to determine if the buffer is active or not.

For instance, we cannot set the buffer addr field to 0x0, as that can be a
valid PC in some cases.

My understanding is that the current_thread field should be a good candidate
to signal that a particular displaced-step buffer is active or not. If it is
nullptr, we have no threads using that buffer to displaced-step.  Otherwise,
it is an active buffer in use by a particular thread.

The following fix modifies the displaced_step_buffers::copy_insn_closure_by_addr
function so we only attempt to return a closure if the buffer has an assigned
current_thread and if the buffer address matches the address argument.

Alternatively, I think we could use a function to answer the question of
whether we're actively displaced-stepping (so we have an active buffer) or
not.

I've also added a testcase that exercises the problem. It should reproduce
reliably on Arm, as that is the only architecture that faces this problem
at the moment.

Regression-tested on Ubuntu 20.04. OK?

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

gdb: replace architecture_changed with new_architecture observer

This commit replaces the architecture_changed observer with a
new_architecture observer.

Currently the only user of the architecture_changed observer is the
Python code, which uses this observer to register the Python unwinder
with the architecture.

The problem is that the architecture_changed observer is triggered
from inferior::set_arch(), which only sees the inferior-wide gdbarch
value.  For targets that use thread-specific architectures, these
never trigger the architecture_changed observer, and so never have the
Python unwinder registered with them.

When it comes to unwinding GDB makes use of the frame's gdbarch, which
is based on the thread's regcache gdbarch, which is set in
get_thread_regcache to the value returned from
target_thread_architecture, which is not always the inferiors gdbarch
value, it might be a thread-specific gdbarch which has not passed
through inferior::set_arch().

The new_architecture observer will be triggered from
gdbarch_find_by_info, whenever a new gdbarch is created and
initialised.  As GDB caches and reuses gdbarch values, we should
expect to see each new architecture trigger the new_architecture
observer just once.

After this commit, targets that make use of thread-specific
architectures should be able to make use of Python unwinders.

As I don't have access to a machine that makes use of thread-specific
architectures right now, I asked Luis to confirm that an AArch64
target that uses SVE/SME can't use the Python unwinders in threads
that are using a thread-specific architectures, and he confirmed that
this is indeed the case, see this discussion:

  https://inbox.sourceware.org/gdb/87wmvsat8i.fsf@redhat.com

Tested-By: Lancelot Six <lancelot.six@amd.com>
Tested-By: Luis Machado <luis.machado@arm.com>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

objcopy: Fix name of the field modified by pe_stack_reserve.

RISC-V: Add "lp64e" ABI support

Since RV32E and RV64E are now ratified, this commit prepares the ABI
support for LP64E (LP64 with reduced GPRs).

gas/ChangeLog:

* config/tc-riscv.c (riscv_set_abi_by_arch): Update the error
message.  (md_parse_option): Accept "lp64e".
* doc/c-riscv.texi: Update the documentation to allow "lp64e".
* testsuite/gas/riscv/mabi-fail-rv32e-lp64f.l:
Change error message.
* testsuite/gas/riscv/mabi-fail-rv32e-lp64d.l: Likewise.
* testsuite/gas/riscv/mabi-fail-rv32e-lp64q.l: Likewise.

RISC-V: Remove RV64E conflict

Since RV32E *and* RV64E are ratified, RV64E is no longer invalid.

This commit removes a restriction that prevents making base ISA with
reduced GPRs with XLEN > 32.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_parse_check_conflicts): Remove RV64E
conflict since the ratified 'E' base ISAs include RV64E.

gas/ChangeLog:

* testsuite/gas/riscv/march-fail-base-02.d: Removed.
* testsuite/gas/riscv/march-fail-base-02.l: Removed.

Automatic date update in version.in

sim: add distclean dep for gnulib

opcodes: microblaze: Add new bit-field instructions

This patches adds new bsefi and bsifi instructions.
BSEFI- The instruction shall extract a bit field from a
register and place it right-adjusted in the destination register.
The other bits in the destination register shall be set to zero.
BSIFI- The instruction shall insert a right-adjusted bit field
from a register at another position in the destination register.
The rest of the bits in the destination register shall be unchanged.

Further documentation of these instructions can be found here:
https://docs.xilinx.com/v/u/en-US/ug984-vivado-microblaze-ref

With version 6 of the patch, no new relocation types are added as
this was unnecessary for adding the bsefi and bsifi instructions.

FIXED: Segfault caused by incorrect termination of microblaze_opcodes.

Signed-off-by: nagaraju <nagaraju.mekala@amd.com>
Signed-off-by: Ibai Erkiaga <ibai.erkiaga-elorza@amd.com>
Signed-off-by: Neal Frager <neal.frager@amd.com>
Signed-off-by: Michael J. Eager <eager@eagercon.com>

sim: mips: fix printf string

Automatic date update in version.in

Automatic date update in version.in

[aarch64] Use SVE_VQ_BYTES instead of __SVE_VQ_BYTES

__SVE_VQ_BYTES is only available if SVE definitions are available in
the system's headers, and this is not true for all systems.

For this purpose, we define SVE_VQ_BYTES.  This patch fixes the
name of the constant being used.

ld: replace wrong bfd_malloc in nto.em

xmalloc should be called in ld instead of bfd_malloc.

ld/ChangeLog:

* emultempl/nto.em (nto_lookup_QNX_note_section): Replace
bfd_malloc by xmalloc.

ld: warn when duplicated QNX stack note are detected

This warning is triggered only when a stack parameter is given to
the linker.

ld/ChangeLog:

        * emultempl/nto.em: Add warning when several QNX .note are
        detected.

ld: correctly handle QNX --lazy-stack without -zstack-size

The warning was skipped if -zstack-size is not provided.

ld/ChangeLog:

        * emultempl/nto.em: Move --lazy-stack warning before missing
        -zstack-size skip.

ld: allow update of existing QNX stack note

Up to now, the linker would always create a QNX stack note from scratch.
However, object files could already have such note, ending up into
duplicates. QNX loader doesn't handle that.

Update the mechanism to first search through the input files for a .note
section holding a QNX stack note. If none are found, then a new section
is created into the stub file as before. This requires this search to be
done once the file have been opened, moving the whole logic a bit later
in the emulation process.

As part for this update, also allow to request an executable stack
without necessarily having to provide its size as well.  In this case, s
etup a default lazy stack of 0x1000.

ld/ChangeLog:

        * emultempl/nto.em (nto_create_QNX_note_section): New Function.
        (nto_lookup_QNX_note_section): New Function.
        (nto_add_note_section): Move the creation of the note section
        in the above new functions.
        (nto_create_output_section_statements): rename nto_after_open
        * testsuite/ld-aarch64/aarch64-nto.exp: add new test.
        * testsuite/ld-aarch64/nto-stack-note-3.d: New test.
        * testsuite/ld-aarch64/nto-stack-note.s: New test.

RISC-V: Add support for numbered ISA mapping strings

The elf psabi allows for mapping symbols to be of the form $x<ISA>.<any>

opcodes/
* riscv-dis.c (riscv_get_map_state): allow mapping symbol to
be suffixed by a unique identifier .<any>

Move -lsocket check to common.m4

A user pointed out that the -lsocket check in gdb should also apply to
gdbserver -- otherwise it can't find the Solaris socketpair.  This
patch makes the change.  It also removes a couple of redundant
function checks from gdb's configure.ac.

This was tested by the person who reported the bug.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30927
Approved-By: Pedro Alves <pedro@palves.net>

Automatic date update in version.in

Fix test suite failure in file-then-restart.exp

Simon pointed out that the new file-then-restart.exp test fails with
the extended-remote target board.

The problem is that the test suite doesn't use gdb_file_cmd -- which
handles things like "set remote exec-file".  This patch changes
gdb_file_cmd to make the "kill" command optional, and then switches
the test case to use it.

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

bfd: add new bfd_cache_size() function

In GDB we have a problem with the BFD cache.

As GDB runs for a potentially extended period of time, if the BFD
cache holds a file descriptor for an open on-disk file, this can, on
some targets (e.g. Win32) prevent the OS writing to the file.

This might, for example, prevent a user from recompiling their
executable as GDB is (via the BFD cache) holding an open reference to
that file.

Another problem, relates to bfd_stat, for BFDs that are using the BFD
cache (i.e. they call cache_bstat to implement bfd_stat).  The
cache_bstat function finds the BFD in the cache, opening the file if
needed, and then uses fstat on the open file descriptor.

What this means is that, if the on-disk file changes, but the cache
was holding an open reference to the file, the bfd_stat will return
the 'struct stat' for the old file, not the new file.

Now, for this second problem, we might be tempted to make use of an
actual stat call, instead of calling bfd_stat, however, this isn't
ideal as we have some BFDs that use a custom iovec, and implement the
various functions over GDB's remote protocol.  By using bfd_stat we
can have a single call that should work for both local files, and for
remote files.

To solve both of these problems GDB has calls to bfd_cache_close_all
sprinkled around its code base.  And in theory this should work fine.

However, I recently ran into a case where we had missed a
bfd_cache_close_all call, and as a result some BFDs were held open.
This caused a bfd_stat call to return an unexpected result (old file
vs new file).

What I'd like is some way within GDB that I can do:

  gdb_assert ( /* Nothing is held open in the cache.  */ );

As this would allow GDB to quickly identify when we've missed some
bfd_cache_close_all calls.

And so, to support this, I would like to add a new bfd_cache_size
function.  This function returns an integer, which is the number of
open files in the cache.  I can then start adding:

  gdb_assert (bfd_cache_size() == 0);

to GDB in some strategic spots, and start fixing all of the missing
bfd_cache_close_all calls that crop up as a result.

bfd/cache: change type used to track cached BFDs from int to unsigned

Within bfd/cache.c change the type for max_open_files and open_files
variables from int to unsigned.  As a consequence of this, the return
type for bfd_cache_max_open() is also changed from int to unsigned.

Within bfd_cache_max_open I've left the local 'max' variable as an
int, this should ensure that if the sysconf call fails, and returns
-1, then the computed max value will be less than 10, which means
max_open_files will be set to 10.  If 'max' was changed to unsigned
then, should the sysconf call fail, we'd end up with max becoming a
very large positive number ... which is clearly not what we want.

And, while I was auditing how open_files is used, I added an assert
within bfd_cache_delete to ensure that we don't try to reduce
open_files below zero.

There should be no user visible change with this commit.

Automatic date update in version.in

[RFA] Fix for mcore simulator

I was looking for cases where a GCC patch under evaluation would cause test
results to change.  Quite surprisingly the mcore-elf port showed test
differences.   After a fair amount of digging my conclusion was the sequences
before/after the patch should have been semantically the same.

Of course if the code is supposed to behave the same, then that points to
problems elsewhere (assembler, linker, simulator).  Sure enough the mcore
simulator was mis-handling the sign extension instructions.  The simulator
implementation of sextb is via paired shift-by-24 operations. Similarly the
simulator implements sexth via paired shift-by-16 operations.

The temporary holding the value was declared as a "long" thus this approach
worked fine for hosts with a 32 bit wide long and failed miserably for hosts
with a 64 bit wide long.

This patch makes the shift count automatically adjust based on the size of the
temporary.  It includes a simple test for sextb and sexth.  I have _not_ done a
full audit of the mcore simulator for more 32->64 bit issues.

This also fixes 443 execution tests in the GCC testsuite

gprofng: Use the correct application name in error messages

The old application name (er_archive) is used in many places.

gprofng/ChangeLog
2023-10-09  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* src/Experiment.cc: Replace er_archive with gp-archive.
* src/Experiment.cc: Likewise.