Fix "finish" with range types on ARM

On ARM (I tested big-endian but it may not matter), "finish" can
sometimes print the wrong result when the return type is a range type.
Range types should really be treated as their underlying type
(normally integer, but sometimes fixed-point).  This patch implements
this.

Approved-By: Luis Machado <luis.machado@arm.com>

Fix calls with small integers on ARM

On big-endian ARM, an inferior call with a small integer will pass the
wrong value.  This patch fixes the problem.  Because the code here
works using scalar values, and not just bytes, left-shifting is
unnecessary.

Approved-By: Luis Machado <luis.machado@arm.com>

Accept and ignore the R_BPF_64_NODLYD32 relocation.

aarch64: Update aarch64-sys-regs.def header

Given the shared use of the aarch64-sys-regs.def file across Binutils
and GCC, add instructions for keeping the file synchronized across the
two codebases.

Namely, it should be made clear that all changes are first to be made
in Binutils and the updated file copied across to GCC.

opcodes/ChangeLog

* opcodes/aarch64-sys-regs.def: Update file-description header
comment.

Automatic date update in version.in

Move read_addrmap_from_aranges to new file

In the interest of shrinking dwarf2/read.c a little more, this patch
moves the code that deciphers .debug_aranges into a new file.

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

Pre-read .debug_aranges section

While working on background DWARF reading, I found a race case that I
tracked down to the handling of the .debug_aranges section.  Currently
the section data is only read in after the CUs have all been created.
However, there's no real reason to do this -- it seems fine to read it
a little earlier, when all the other necessary sections are read in.

This patch makes this change, and updates the
read_addrmap_from_aranges API to assert that the section is read in.

This patch slightly changes the read_addrmap_from_aranges API as well,
to reject an empty section.  This seems better to me than what the
current code does, which is try to read an empty section but then do
no work.

Regression tested on x86-64 Fedora 38.

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

Automatic date update in version.in

gdb/gdbsupport/gdbserver: Require c++17

This patch proposes to require a C++17 compiler to build gdb /
gdbsupport / gdbserver.  Before this patch, GDB required a C++11
compiler.

The general policy regarding bumping C++ language requirement in GDB (as
stated in [1]) is:

    Our general policy is to wait until the oldest compiler that
    supports C++NN is at least 3 years old.

    Rationale: We want to ensure reasonably widespread compiler
    availability, to lower barrier of entry to GDB contributions, and to
    make it easy for users to easily build new GDB on currently
    supported stable distributions themselves. 3 years should be
    sufficient for latest stable releases of distributions to include a
    compiler for the standard, and/or for new compilers to appear as
    easily installable optional packages. Requiring everyone to build a
    compiler first before building GDB, which would happen if we
    required a too-new compiler, would cause too much inconvenience.

    See the policy proposal and discussion
    [here](https://sourceware.org/ml/gdb-patches/2016-10/msg00616.html).

The first GCC release which with full C++17 support is GCC-9[2],
released in 2019[3], which is over 4 years ago.  Clang has had C++17
support since Clang-5[4] released in 2018[5].

A discussions with many distros showed that a C++17-able compiler is
always available, meaning that this no hard requirement preventing us to
require it going forward.

[1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F
[2] https://gcc.gnu.org/projects/cxx-status.html#cxx17
[3] https://gcc.gnu.org/gcc-9/
[4] https://clang.llvm.org/cxx_status.html
[5] https://releases.llvm.org/

Change-Id: Id596f5db17ea346e8a978668825787b3a9a443fd
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>

gdb/ax_cxx_compile_stdcxx.m4: upgrade

This patch upgrades gdb/ax_cxx_compile_stdcxx.m4 to follow changes
available in [1] and regenerates the configure script.

[1] https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html

Change-Id: I5b16adc65c9e48a13ad65202d58ab7a9d487214e
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>

gas: tc-bpf.c: fix formatting of comment

opcodes: bpf-dis.c: fix typo in comment

Automatic date update in version.in

gdb: trim trailing spaces in i386-tdep.{c,h}

Change-Id: I06c2e7c958c3451f00c70978538c1c2ad1b566df

RISC-V: Clarify the behaviors of SET/ADD/SUB relocations.

We are used to generate these kinds of relocations by data directives.
Considering the following example,
.word (A + 3) - (B + 2)
The GAS will generate a pair of ADD/SUB for this,
R_RISCV_ADD, A + 1
R_RISCV_SUB, 0

The addend of R_RISCV_SUB will always be zero, and the summary of the
constants will be stored in the addend of R_RISCV_ADD/SET.  Therefore,
we can always add the addend of these data relocations when doing relocations.

But unfortunately, I had heard that if we are using .reloc to generate
the data relocations will make the relocations failed.  Refer to this,
.reloc offset, R_RISCV_ADD32, A + 3
.reloc offset, R_RISCV_SUB32, B + 2
.word 0
Then we can get the relocations as follows,
R_RISCV_ADD, A + 3
R_RISCV_SUB, B + 2
Then...  Current LD does the relocation, B - A + 3 + 2, which is wrong
obviously...

So first of all, this patch fixes the wrong relocation behavior of
R_RISCV_SUB* relocations.

Afterwards, considering the uleb128 direcitve, we will get a pair of
SET_ULEB128/SUB_ULEB128 relocations for it for now,
.uleb128 (A + 3) - (B + 2)
R_RISCV_SET_ULEB128, A + 1
R_RISCV_SUB_ULEB128, B + 1

Which looks also wrong obviously, the summary of the constants should only
be stored into the addend of SET_ULEB128, and the addend of SUB_ULEB128 should
be zero like other SUB relocations.  But the current LD will still get the right
relocation values since we only add the addend of SUB_ULEB128 by accident...
Anyway, this patch also fixes the behaviors above, to make sure that no matter
using .uleb128 or .reloc directives, we should always get the right values.

bfd/
* elfnn-riscv.c (perform_relocation):  Clarify that SUB relocations
should substract the addend, rather than add.
(riscv_elf_relocate_section): Since SET_ULEB128 won't go into
perform_relocation, we should add it's addend here in advance.
gas/
* config/tc-riscv.c (riscv_insert_uleb128_fixes): Set the addend of
SUB_ULEB128 to zero since it should already be added into the addend
of SET_ULEB128.

Automatic date update in version.in

gdb/python: Add new gdb.Value.bytes attribute

Add a gdb.Value.bytes attribute.  This attribute contains the bytes of
the value (assuming the complete bytes of the value are available).

If the bytes of the gdb.Value are not available then accessing this
attribute raises an exception.

The bytes object returned from gdb.Value.bytes is cached within GDB so
that the same bytes object is returned each time.  The bytes object is
created on-demand though to reduce unnecessary work.

For some values we can of course obtain the same information by
reading inferior memory based on gdb.Value.address and
gdb.Value.type.sizeof, however, not every value is in memory, so we
don't always have an address.

The gdb.Value.bytes attribute will convert any value to a bytes
object, so long as the contents are available.  The value can be one
created purely in Python code, the value could be in a register,
or (of course) the value could be in memory.

The Value.bytes attribute can also be assigned too.  Assigning to this
attribute is similar to calling Value.assign, the value of the
underlying value is updated within the inferior.  The value assigned
to Value.bytes must be a buffer which contains exactly the correct
number of bytes (i.e. unlike value creation, we don't allow oversized
buffers).

To support this assignment like behaviour I've factored out the core
of valpy_assign.  I've also updated convert_buffer_and_type_to_value
so that it can (for my use case) check the exact buffer length.

The restrictions for when the Value.bytes can or cannot be written too
are exactly the same as for Value.assign.

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

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

gdb: handle main thread exiting during detach

Overview
========

Consider the following situation, GDB is in non-stop mode, the main
thread is running while a second thread is stopped.  The user has the
second thread selected as the current thread and asks GDB to detach.
At the exact moment of detach the main thread exits.

This situation currently causes crashes, assertion failures, and
unexpected errors to be reported from GDB for both native and remote
targets.

This commit addresses this situation for native and remote targets.
There are a number of different fixes, but all are required in order
to get this functionality working correct for native and remote
targets.

Native Linux Target
===================

For the native Linux target, detaching is handled in the function
linux_nat_target::detach.  In here we call stop_wait_callback for each
thread, and it is this callback that will spot that the main thread
has exited.

GDB then detaches from everything except the main thread by calling
detach_callback.

After this the first problem is this assert:

  /* Only the initial process should be left right now.  */
  gdb_assert (num_lwps (pid) == 1);

The num_lwps call will return 0 as the main thread has exited and all
of the other threads have now been detached.  I fix this by changing
the assert to allow for 0 or 1 lwps at this point.  As the 0 case can
only happen in non-stop mode, the assert becomes:

  gdb_assert (num_lwps (pid) == 1
      || (target_is_non_stop_p () && num_lwps (pid) == 0));

The next problem is that we do:

  main_lwp = find_lwp_pid (ptid_t (pid));

and then proceed assuming that main_lwp is not nullptr.  In the case
that the main thread has exited though, main_lwp will be nullptr.

However, we only need main_lwp so that GDB can detach from the
thread.  If the main thread has exited, and GDB has already detached
from every other thread, then GDB has finished detaching, GDB can skip
the calls that try to detach from the main thread, and then tell the
user that the detach was a success.

For Remote Targets
==================

On remote targets there are two problems.

First is that when the exit occurs during the early phase of the
detach, we see the stop notification arrive while GDB is removing the
breakpoints ahead of the detach.  The 'set debug remote on' trace
looks like this:

  [remote] Sending packet: $z0,7f1648fe0241,1#35
  [remote]   Notification received: Stop:W0;process:2a0ac8
  # At this point an unpatched gdbserver segfaults, and the connection
  # is broken.  A patched gdbserver continues as below...
  [remote] Packet received: E01
  [remote] Sending packet: $z0,7f1648ff00a8,1#68
  [remote] Packet received: E01
  [remote] Sending packet: $z0,7f1648ff132f,1#6b
  [remote] Packet received: E01
  [remote] Sending packet: $D;2a0ac8#3e
  [remote] Packet received: E01

I was originally running into Segmentation Faults, from within
gdbserver/mem-break.cc, in the function find_gdb_breakpoint.  This
function calls current_process() and then dereferences the result to
find the breakpoint list.

However, in our case, the current process has already exited, and so
the current_process() call returns nullptr.  At the point of failure,
the gdbserver backtrace looks like this:

  #0  0x00000000004190e4 in find_gdb_breakpoint (z_type=48 '0', addr=4198762, kind=1) at ../../src/gdbserver/mem-break.cc:982
  #1  0x000000000041930d in delete_gdb_breakpoint (z_type=48 '0', addr=4198762, kind=1) at ../../src/gdbserver/mem-break.cc:1093
  #2  0x000000000042d8db in process_serial_event () at ../../src/gdbserver/server.cc:4372
  #3  0x000000000042dcab in handle_serial_event (err=0, client_data=0x0) at ../../src/gdbserver/server.cc:4498
  ...

The problem is that, as a result non-stop being on, the process
exiting is only reported back to GDB after the request to remove a
breakpoint has been sent.  Clearly gdbserver can't actually remove
this breakpoint -- the process has already exited -- so I think the
best solution is for gdbserver just to report an error, which is what
I've done.

The second problem I ran into was on the gdb side, as the process has
already exited, but GDB has not yet acknowledged the exit event, the
detach -- the 'D' packet in the above trace -- fails.  This was being
reported to the user with a 'Can't detach process' error.  As the test
actually calls detach from Python code, this error was then becoming a
Python exception.

Though clearly the detach has returned an error, and so, maybe, having
GDB throw an error would be fine, I think in this case, there's a good
argument that the remote error can be ignored -- if GDB tries to
detach and gets back an error, and if there's a pending exit event for
the pid we tried to detach, then just ignore the error and pretend the
detach worked fine.

We could possibly check for a pending exit event before sending the
detach packet, however, I believe that it might be possible (in
non-stop mode) for the stop notification to arrive after the detach is
sent, but before gdbserver has started processing the detach.  In this
case we would still need to check for pending stop events after seeing
the detach fail, so I figure there's no point having two checks -- we
just send the detach request, and if it fails, check to see if the
process has already exited.

Testing
=======

In order to test this issue I needed to ensure that the exit event
arrives at the same time as the detach call.  The window of
opportunity for getting the exit to arrive is so small I've never
managed to trigger this in real use -- I originally spotted this issue
while working on another patch, which did manage to trigger this
issue.

However, if we trigger both the exit and the detach from a single
Python function then we never return to GDB's event loop, as such GDB
never processes the exit event, and so the first time GDB gets a
chance to see the exit is during the detach call.  And so that is the
approach I've taken for testing this patch.

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

[gdb/testsuite] Add wait-for-index-cache in gdb.dwarf2/per-bfd-sharing.exp

If we make writing an index-cache entry very slow by doing this in
index_cache::store:
...
   try
     {
+      sleep (15);
       index_cache_debug ("writing index cache for objfile %s",
   bfd_get_filename (per_bfd->obfd));
...
we run into:
...
FAIL: gdb.dwarf2/per-bfd-sharing.exp: \
  couldn't remove files in temporary cache dir
...

The FAIL happens because there is no index-cache entry in the cache dir.

The problem is that gdb is killed (by gdb_exit) before the index-cache entry
is written.

Fix this by using "maint wait-for-index-cache".

Tested on x86_64-linux.

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

gdb/nat/aarch64-scalable-linux-ptrace.h: Don't include itself

GCC doesn't complain, but it's still wrong.

Automatic date update in version.in

gdb/testsuite: add a clang XFAIL to gdb.python/py-watchpoint.exp

Clang doesn't use CFA information for variable locations. This makes it
so software breakpoints get a false hit when rbp gets popped, causing
a FAIL in gdb.python/py-watchpoint.exp. Since this is nothing wrong with
GDB itself, add an xfail to reduce noise.

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

gdb/testsuite: fix running gdb.python/py-explore-cc with clang

The test gdb.python/py-explore-cc.exp was showing one unexpected
failure. This was due to how clang mapped instructions to lines,
resulting in the inferior seemingly stopping at a different location.

This patch adds a nop line in the relevant location so we don't need to
add XFAILs for existing clang releases, if this gets solved in future
versions.

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

gdbserver: don't leak program name in handle_v_run

I noticed that in handle_v_run (gdbserver/server.cc) we leak
new_program_name (a string) each time GDB starts an inferior, in the
case where GDB passes a program name to gdbserver.

This bug was introduced with this commit:

  commit 7ab2607f97e5deaeae91018edf3ef5b4255a842c
  Date:   Wed Apr 13 17:31:02 2022 -0400

      gdbsupport: make gdb_abspath return an std::string

When gdbserver receives a program name from GDB, this is first placed
into a malloc'd buffer within handle_v_run, and this buffer is then
used in this call:

  program_path.set (new_program_name);

Prior to the above commit this call took ownership of the buffer
passed to it, but now this call uses the buffer to initialise a
std::string, which copies the buffer contents, leaving ownership with
the caller.  So now, after this call (in handle_v_run)
new_program_name still owns a buffer.

At no point in handle_v_run do we free new_program_name, as a result
we are leaking the program name each time GDB starts a remote
inferior.

I could solve this by adding a 'free' call into handle_v_run, but I'd
rather automate the memory management.

So, to this end, I have added a new function in gdbserver/server.cc,
decode_v_run_arg.  This function takes care of allocating the memory
buffer and decoding the vRun packet into the buffer, but returns a
gdb::unique_xmalloc_ptr<char> (or nullptr on error).

Back in handle_v_run I have converted new_program_name to also be a
gdb::unique_xmalloc_ptr<char>.

Now, after we call program_path.set(), the allocated buffer will be
automatically released when it is no longer needed.

It is worth highlighting that within the new decode_v_run_arg
function, I have wrapped the call to hex2bin in a try/catch block.
The hex2bin function can throw an exception if it encounters an
invalid (non-hex) character.  Back in handle_v_run, we have a local
argument new_argv, which is of type std::vector<char *>.  Each
'char *' in this vector is a malloc'd buffer.  If we allow
hex2bin to throw an exception and don't catch it in either
decode_v_run_arg or handle_v_run then we are going to leak memory from
new_argv.

I chose to catch the exception in decode_v_run_arg, this seemed
cleanest, but I'm not sure it really matters, so long as the exception
is caught before we leave handle_v_run.  I am working on a patch that
changes new_argv to automatically manage its memory, but that isn't
ready for posting yet.  I think what I have here would be fine if my
follow on patch never arrives.

Additionally, within the handle_v_run loop I have changed an
assignment of nullptr to new_program_name into an assert.  Previously,
the assignment could only trigger on the first iteration of the loop,
if we had no new program name to assign.  However, new_program_name
always starts as nullptr, so, on the first loop iteration, if we have
nothing to assign to new_program_name, its value must already be
nullptr.

There should be no user visible changes after this commit.

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

gdb: make get_symbol_address a private method of symbol

get_symbol_address is only used symbol::value_address, make it a private
helper method.

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

gdb: make get_msymbol_address a private method of minimal_symbol

get_msymbol_address is only used in minimal_symbol::value_address.  Make
it a private helper method.

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

gprofng: Fix -Wformat= warnings

Added format attribute to several gprofng functions.
Fixed -Wformat= warnings.

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

* libcollector/heaptrace.c: Fixed -Wformat= warnings.
* libcollector/hwprofile.c: Likewise.
* libcollector/iolib.c: Likewise.
* libcollector/iotrace.c: Likewise.
* libcollector/jprofile.c: Likewise.
* libcollector/profile.c: Likewise.
* libcollector/synctrace.c: Likewise.
* src/ClassFile.cc: Likewise.
* src/SourceFile.cc: Likewise.
* libcollector/libcol_util.h: Added format attribute.
* src/Emsg.h: Likewise.
* src/collector_module.h: Likewise.
* src/data_pckts.h: Define fld_sizeof.

asan: _bfd_elf_slurp_version_tables memory leak

Extends commit 6136093c0d00 to handle verdefs as well as verrefs.

PR 30886
* elf.c (_bfd_elf_slurp_version_tables): See free_contents for
verdefs too.  Use free_contents rather than elf_tdata fields.

asan: out of memory in som_set_reloc_info

Sections without SEC_HAS_CONTENTS avoid the file size checks, and of
course it doesn't make sense to read such as the contents are all
zero.

* som.c (som_set_reloc_info): Don't read sections without contents.

asan: NULL deref in alpha_ecoff_get_relocated_section_contents

This fixes some holes found by fuzzers, and removes aborts that can be
triggered by user input to objdump.  Abort should only be used within
bfd to show programming errors in bfd.

* coff-alpha.c (alpha_ecoff_get_relocated_section_contents): Handle
NULL howto.  Don't abort on stack errors or on unexpected relocs.
Show more bfd reloc status messages.

Automatic date update in version.in

[gdb/cli] Add gnu-source-highlight selftest

Add a selftest gnu-source-highlight:
...
$ gdb -q -batch -ex "maint selftest gnu-source-highlight"
Running selftest gnu-source-highlight.
Ran 1 unit tests, 0 failed
...

Tested on x86_64-linux.

[readelf] Handle unknown name of main in .gdb_index section

When compiling hello world and adding a v9 .gdb-index section:
...
$ gcc -g hello.c
$ gdb-add-index a.out
...
readelf shows it as:
...
Shortcut table:
Language of main: unknown: 0
Name of main: ^A
...

The documentation of gdb says about the "Name of main" that:
...
This value must be ignored if the value for the language of main is zero.
...

Implement this approach in display_gdb_index, such that we have instead:
...
Shortcut table:
Language of main: unknown: 0
Name of main: <unknown>
...

Tested on x86_64-linux.

Approved-By: Jan Beulich <jbeulich@suse.com>

as: fixed internal error when immediate value of relocation overflow.

The as and ld use _bfd_error_handler to output error messages when
checking relocation alignment and relocation overflow. However, the
abfd value passed by as to the function is NULL, resulting in an
internal error. The ld passes a non-null value to the function,
so it can output an error message normally.

Automatic date update in version.in

[gdb/python] Only include gdbsupport/selftest.h if GDB_SELF_TEST

I noticed that gdb/python/python.c unconditionally includes
gdbsupport/selftest.h.

Make this conditional on GDB_SELF_TEST.

Tested on x86_64-linux.

gas: make .nops output visible in listing

Due to using a different frag type (in turn due to storing data
differently), making the resulting code appear in listings requires
special handling.

x86: fold NOP testcase expectations where possible

Like done earlier for files needing adjustment anyway, also do this for
the remaining set.

x86: fold a few of the "alternative" NOP patterns

Since named objects may not overlap, the compiler is not permitted to do
this for us, to avoid wasting space and cache bandwidth/capacity.

x86: add a few more NOP patterns

First of all add f32_5[], allowing to eliminate the extra slot-is-NULL
code from i386_output_nops(). Plus then introduce f32_8[] and f16_5[]
following the same concept of adding a %cs segment override prefix.

Also re-use patterns when possible and correct comments as applicable.
Similarly re-use testcase expectations as much as possible, where they
need touching anyway.

x86: don't record full i386_cpu_flags in struct i386_tc_frag_data

We only use a single bit of this ever growing structure.

x86: i686 != PentiumPro

The two are distinct in opcodes/, distinguished precisely by CpuNOP
that's relevant in i386_generate_nops(), yet the function has the PPro
case label in the other group. Simply removing it revealed that
cpu_arch[] had a wrong entry for i686.

While there also add PROCESSOR_IAMCU to the respective comment.

x86: respect ".arch nonop" when selecting which NOPs to emit

Making GENERIC64 a special case was never correct; prior to the
generalization of ".arch .no*" to cover all ISA extensions other
processor families supporting long NOPs should have been covered as
well. When introducing ".arch .nonops" (among others) it wasn't
apparent that a hidden implication of .cpunop not being possible to
separately turn off existed here. Seeing that the two large case label
blocks in the 2nd switch() already had identical behavior, simply
collapse all of the (useful) case labels into a single "default" one.

x86: don't use operand size override with NOP in 16-bit code

Since we don't key the NOP selection to user-controlled properties, we
may not use i386 features; otherwise we would violate a possible .arch
directive restricting ISA to pre-386.

x86: don't use 32-bit LEA as NOP surrogate in 64-bit code

Except for the shared 1- and 2-byte cases, the LEA uses corrupt %rsi
(by zero-extending %esi to %rsi). Introduce separate 64-bit patterns
which keep %rsi intact.

x86: i386_generate_nops() may not derive decisions from global variables

What matters is what was in effect at the time the original directive
was issued. Later changes to global state (bitness or ISA) must not
affect what code is generated.

x86: record flag_code in tc_frag_data

The recorded value, and not the global variable, will want using in
TC_FRAG_INIT(). The so far file scope variable therefore needs to become
external, to be accessible there.

objcopy: fix typo in --heap and --stack parser

The help says that <reserve> and <commit> should be separated by a ","
but the implementation is checking for ".". Having two numbers being
separated by a "." could be confusing, thus adjust the implementation to
match the help syntax.

binutils/ChangeLog:

* objcopy.c (copy_main): Set separator to "," between <reserve>
and <commit> for --heap and --stack.
* doc/binutils.texi: Add <commit> for --heap and --stack.

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>