Rename tui-stack -> tui-status

The TUI status line is called the "status" window in the
documentation, but not in the source.  There, the relevant files are
named "tui-stack", which to me makes it sound like they have something
to do with backtraces.  This patch renames them to "tui-status".

ld: Add lib32 directories for 32-bit emulation on FreeBSD/amd64

GNU ld currently fails to link 32-bit executables on FreeBSD/amd64 when
the linked libraries have dependencies on shared objects themselves:

$ gcc -m32 -o ei ei.c -lexecinfo
/var/gcc/binutils/amd64/lib/gcc/amd64-pc-freebsd14.0/13.2.0/../../../../amd64-pc-freebsd14.0/bin/ld:
warning: libelf.so.2, needed by /usr/lib/../lib32/libexecinfo.so, not found
(try using -rpath or -rpath-link)
/var/gcc/binutils/amd64/lib/gcc/amd64-pc-freebsd14.0/13.2.0/../../../../amd64-pc-freebsd14.0/bin/ld:
/usr/lib/../lib32/libexecinfo.so: undefined reference to `elf_begin@R1.0'
[...]

Fixed by handling FreeBSD/amd64 like Linux/x86.

Tested on amd64-pc-freebsd14.0.

Fix Clang build issue with flexible array member and non-trivial dtor

Commit d5cebea18e7a ("Make cached_reg_t own its data") added a
destructor to cached_reg_t.

That caused a build problem with Clang, which errors out like so:

 > CXX    python/py-unwind.o
 > gdb/python/py-unwind.c:126:16: error: flexible array member 'reg' of type 'cached_reg_t[]' with non-trivial destruction
 >   126 |   cached_reg_t reg[];
 >       |                ^

This is is not really a problem for our code, which allocates the
whole structure with xmalloc, and then initializes the array elements
with in-place new, and then takes care to call the destructor
manually.  Like, commit d5cebea18e7a did:

 @@ -928,7 +927,7 @@ pyuw_dealloc_cache (frame_info *this_frame, void *cache)
    cached_frame_info *cached_frame = (cached_frame_info *) cache;

    for (int i = 0; i < cached_frame->reg_count; i++)
 -    xfree (cached_frame->reg[i].data);
 +    cached_frame->reg[i].~cached_reg_t ();

Maybe we should get rid of the flexible array member and use a bog
standard std::vector.  I doubt this would cause any visible
performance issue.

Meanwhile, to unbreak the build, this commit switches from C99-style
flexible array member to 0-length array.  It behaves the same, and
Clang doesn't complain.  I got the idea from here:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932#c11

GCC 9, our oldest support version, already supported this:

  https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Zero-Length.html

but the extension is actually much older than that.  Note that
C99-style flexible array members are not standard C++ either.

Change-Id: I37dda18f367e238a41d610619935b2a0f2acacce

sim: warnings: enable -Wimplicit-fallthrough=5

It caught some legitimate bugs, so clearly it's helpful.

sim: sh: fix -Wimplicit-fallthrough warnings

These generate conditional insns where it tests, then fallsthru.

sim: rx: fix -Wimplicit-fallthrough warnings

Replace some fall through comments with the attribute.

sim: rl78: fix -Wimplicit-fallthrough warnings

Seems like this code was meant to fallthru.

sim: riscv: fix -Wimplicit-fallthrough warnings

sim: ppc: fix -Wimplicit-fallthrough warnings

Replace some fall through comments with the attribute.

sim: or1k: fix -Wimplicit-fallthrough warnings

Replace some fall through comments with the attribute.

sim: mips: fix -Wimplicit-fallthrough warnings

Seems like these cases were meant to fallthru.

sim: mcore: fix Wimplicit-fallthrough warnings

Seems like these decodes were intended to fallthru.

sim: m68hc11: fix -Wimplicit-fallthrough warnings

Seems like these register operations intended on falling thru.

sim: frv: fix -Wimplicit-fallthrough warnings

Replace some fall through comments with the attribute.

sim: erc32: fix -Wimplicit-fallthrough warnings

Add the attribute where it seems to make sense.

sim: cris: fix -Wimplicit-fallthrough warnings

Replace some fall through comments with the attribute.

sim: bfin: fix -Wimplicit-fallthrough warnings

Add the attribute to places where we want to fall thru.

sim: avr: fix -Wimplicit-fallthrough warnings

Replace some fall through comments with the attribute.

sim: arm: fix -Wimplicit-fallthrough warnings

Replace some fall through comments with the attribute.

sim: aarch64: fix -Wimplicit-fallthrough warnings

Replace some fall through comments with the attribute, and add some
default abort calls when the compiler can't figure out that the set
of values were already fully enumerated in the switch statement.

sim: common: fix -Wimplicit-fallthrough warnings

Replace some fall through comments with the attribute.

sim: add ATTRIBUTE_FALLTHROUGH for local code

We'll replace various /* fall through */ comments so compilers can
actually understand what the code is doing.

sim: signal: mark signal callback funcs as noreturn since they don't return

All funcs already call other funcs that don't return.  The mips port is
the only exception because its generic exception handler can return in
the case of normal exceptions.  So while the exceptions its signal handler
triggers doesn't return, we can't express that conditional logic.  So add
some useless abort calls to make the compiler happy.

sim: sh: add missing breaks to bit processing

Doesn't seem like we want to cascade in this section when bit processing.

sim: rx: mark abort func as noreturn since it doesn't

sim: rx: add missing break to memory write

It doesn't seem like we want to keep executing the next block of code
after processing the request.

sim: iq2000: add fallback for exit syscall

Make sure this syscall always exits regardless of the exit code.

sim: cr16: add missing break statement

Doesn't seem to make sense for this to fall through
(although I'm not an expert in this ISA).

sim: arm: add missing breaks to SWI processing

Seems unlikely we want the remove syscall to fallthrough into the
rename syscall since we can't rename files that have been removed.

sim: common: mark engine restart as noreturn

This helps the compiler with optimization and fixes fallthru warnings.

sim: ppc: phb: add missing break to address decoder

I don't know what this emulation does exactly, but it missing a break
statement seems kind of obvious based on the 32-bit case above it.

sim: ppc: mark halt & restart funcs as noreturn

This helps the compiler with optimization and fixes fallthru warnings.

sim: warnings: enable -Wduplicated-cond

sim: mn10300: fix LAST_TIMER_REG typo

The compiler pointed out that we're testing LAST_TIMER_REG and
LAST_COUNTER which are the same value ... and that's because we
set LAST_TIMER_REG to the wrong register.  Fix the typo.

sim: bfin: clean up astat reg name decode a little

The compiler pointed out we checked AZ twice.  Sort by name to avoid
that in the future, and to make it clearer that we have coverage of
all the bits.  And add the bits we were missing.

The order here doesn't matter as it's just turning a pointer into a
human readable string when store tracing is enabled.

sim: common: delete unused scache in some mloop paths

The scache vars aren't used by ports in the pbb & fast codepaths,
nor are they documented as inputs to the callbacks, so delete them
to avoid unused variable compiler warnings.

sim: cgen: unify the genmloop logic a bit

Pull out the common parts of the genmloop invocation into the common
code.  This will make it easier to add more, and make the per-port
differences a little more obvious.

Automatic date update in version.in

gprofng: 31169 Source code locations can not be found in a C++ application

gprofng incorrectly reads the form of the DW_FORM_ref_addr attribute for DWARF
Version 3 or later.
From DWARF specification:
  References that use the attribute form DW_FORM_ref_addr are specified to
  be four bytes in the DWARF 32-bit format and eight bytes in the DWARF
  64-bit format, while DWARF Version 2 specifies that such references have
  the same size as an address on the target system.

2023-12-18  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/31169
* src/DwarfLib.cc: Fix the reader for DW_FORM_ref_addr.

Fix handling of vanishing threads that were stepping/stopping

Downstream, AMD is carrying a testcase
(gdb.rocm/continue-over-kernel-exit.exp) that exposes a couple issues
with the amd-dbgapi target's handling of exited threads.  The test
can't be added upstream yet, unfortunately, due to dependency on DWARF
extensions that can't be upstreamed yet.  However, it can be found on
the mailing list on the same series as this patch.

The test spawns a kernel with a number of waves.  The waves do nothing
but exit.  There is a breakpoint on the s_endpgm instruction.  Once
that breakpoint is hit, the test issues a "continue" command.  We
should see one breakpoint hit per wave, and then the whole program
exiting.  We do see that, however we also see this:

 [New AMDGPU Wave ?:?:?:1 (?,?,?)/?]
 [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited]
 *repeat for other waves*
 ...
 [Thread 0x7ffff626f640 (LWP 3048491) exited]
 [Thread 0x7fffeb7ff640 (LWP 3048488) exited]
 [Inferior 1 (process 3048475) exited normally]

That "New AMDGPU Wave" output comes from infrun.c itself adding the
thread to the GDB thread list, because it got an event for a thread
not on the thread list yet.  The output shows "?"s instead of proper
coordinates, because the event was a TARGET_WAITKIND_THREAD_EXITED,
i.e., the wave was already gone when infrun.c added the thread to the
thread list.

That shouldn't ever happen for the amd-dbgapi target, threads should
only ever be added by the backend.

Note "New AMDGPU Wave ?:?:?:1" is for wave 1.  What happened was that
wave 1 terminated previously, and a previous call to
amd_dbgapi_target::update_thread_list() noticed the wave had vanished
and removed it from the GDB thread list.  However, because the wave
was stepping when it terminated (due to the displaced step over the
s_endpgm) instruction, it is guaranteed that the amd-dbgapi library
queues a WAVE_COMMAND_TERMINATED event for the exit.

When we process that WAVE_COMMAND_TERMINATED event, in
amd-dbgapi-target.c:process_one_event, we return it to the core as a
TARGET_WAITKIND_THREAD_EXITED event:

 static void
 process_one_event (amd_dbgapi_event_id_t event_id,
    amd_dbgapi_event_kind_t event_kind)
 {
 ...
 if (status == AMD_DBGAPI_STATUS_ERROR_INVALID_WAVE_ID
     && event_kind == AMD_DBGAPI_EVENT_KIND_WAVE_COMMAND_TERMINATED)
   ws.set_thread_exited (0);
 ...
 }

Recall the wave is already gone from the GDB thread list.  So when GDB
sees that TARGET_WAITKIND_THREAD_EXITED event for a thread it doesn't
know about, it adds the thread to the thread list, resulting in that:

 [New AMDGPU Wave ?:?:?:1 (?,?,?)/?]

and then, because it was a TARGET_WAITKIND_THREAD_EXITED event, GDB
marks the thread exited right afterwards:

 [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited]

The fix is to make amd_dbgapi_target::update_thread_list() _not_
delete vanishing waves iff they were stepping or in progress of being
stopped.  These two cases are the ones dbgapi guarantees will result
in a WAVE_COMMAND_TERMINATED event if the wave terminates:

  /**
   * A command for a wave was not able to complete because the wave has
   * terminated.
   *
   * Commands that can result in this event are ::amd_dbgapi_wave_stop and
   * ::amd_dbgapi_wave_resume in single step mode.  Since the wave terminated
   * before stopping, this event will be reported instead of
   * ::AMD_DBGAPI_EVENT_KIND_WAVE_STOP.
   *
   * The wave that terminated is available by the ::AMD_DBGAPI_EVENT_INFO_WAVE
   * query.  However, the wave will be invalid since it has already terminated.
   * It is the client's responsibility to know what command was being performed
   * and was unable to complete due to the wave terminating.
   */
  AMD_DBGAPI_EVENT_KIND_WAVE_COMMAND_TERMINATED = 2,

As the comment says, it's GDB's responsability to know whether the
wave was stepping or being stopped.  Since we now have a wave_info map
with one entry for each wave, that seems like the place to store that
information.  However, I still decided to put all the coordinate
information in its own structure.  I.e., basically renamed the
existing wave_info to wave_coordinates, and then added a new wave_info
structure that holds the new state, plus a wave_coordinates object.
This seemed cleaner as there are places where we only need to
instantiate a wave_coordinates object.

There's an extra twist.  The testcase also exercises stopping at a new
kernel right after the first kernel fully exits.  In that scenario, we
were hitting this assertion after the first kernel fully exits and the
hit of the breakpoint at the second kernel is handled:

 [amd-dbgapi] process_event_queue: Pulled event from dbgapi: event_id.handle = 26, event_kind = WAVE_STOP
 [amd-dbgapi-lib] suspending queue_3, queue_2, queue_1 (refresh wave list)
 ../../src/gdb/amd-dbgapi-target.c:1625: internal-error: amd_dbgapi_thread_deleted: Assertion `it != info->wave_info_map.end ()' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.

This is the exact same problem as above, just a different
manifestation.  In this scenario, we end up in update_thread_list
successfully deleting the exited thread (because it was no longer the
current thread) that was incorrectly added by infrun.c.  Because it
was added by infrun.c and not by amd-dbgapi-target.c:add_gpu_thread,
it doesn't have an entry in the wave_info map, so
amd_dbgapi_thread_deleted trips on this assertion:

      gdb_assert (it != info->wave_info_map.end ());

here:

  ...
  -> stop_all_threads
   -> update_thread_list
    -> target_update_thread_list
     -> amd_dbgapi_target::update_thread_list
      -> thread_db_target::update_thread_list
       -> linux_nat_target::update_thread_list
-> delete_exited_threads
 -> delete_thread
  -> delete_thread_1
   -> gdb::observers::observable<thread_info*>::notify
    -> amd_dbgapi_thread_deleted
     -> internal_error_loc

The testcase thus tries both running to exit after the first kernel
exits, and running to a breakpoint in a second kernel after the first
kernel exits.

Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Change-Id: I43a66f060c35aad1fe0d9ff022ce2afd0537f028

Fix thread target ID of exited waves

Currently, if you step over kernel exit, you see:

 stepi
 [AMDGPU Wave ?:?:?:1 (?,?,?)/? exited]
 Command aborted, thread exited.
 (gdb)

Those '?' are because the thread/wave is already gone by the time GDB
prints the "exited" notification, we can't ask dbgapi for any info
about the wave anymore.

This commit fixes it by caching the wave's coordinates as soon as GDB
sees the wave for the first time, and making
amd_dbgapi_target::pid_to_str use the cached info.

At first I thought of clearing the wave_info object from a
thread_exited observer.  However, that is too soon, resulting in this:

 (gdb) si
 [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited]
 Command aborted, thread exited.
 (gdb) thread
 [Current thread is 6 (AMDGPU Wave ?:?:?:0 (?,?,?)/?) (exited)]

We need instead to clear the wave info when the thread is ultimately
deleted, so we get:

 (gdb) si
 [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited]
 Command aborted, thread exited.
 (gdb) thread
 [Current thread is 6 (AMDGPU Wave 1:4:1:1 (0,0,0)/0) (exited)]

And for that, we need a new thread_deleted observable.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Change-Id: I6c3e22541f051e1205f75eb657b04dc15e547580

Step over thread exit, always delete the thread non-silently

With AMD GPU debugging, I noticed that when stepping over a breakpoint
placed on top of the s_endpgm instruction inline (displaced=off), GDB
would behave differently -- it wouldn't print the wave exit.  E.g:

With displaced stepping, or no breakpoint at all:

 stepi
 [AMDGPU Wave 1:4:1:1 (0,0,0)/0 exited]
 Command aborted, thread exited.
 (gdb)

With inline stepping:

 stepi
 Command aborted, thread exited.
 (gdb)

In the cases we see the "exited" notification, handle_thread_exit is
what first called delete_thread on the exiting thread, which is
non-silent.

With inline stepping, however, handle_thread_exit ends up in
update_thread_list (via restart_threads) before any delete_thread
call.  Thus, amd_dbgapi_target::update_thread_list notices that the
wave is gone and deletes it with delete_thread_silent.

This commit fixes it, by making handle_thread_exited call
set_thread_exited (with the default silent=false) early, which emits
the user-visible notification.

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

displaced_step_finish: Don't fetch the regcache of exited threads

displaced_step_finish can be called with event_status.kind ==
TARGET_WAITKIND_THREAD_EXITED, and in that case it is not possible to
get at the already-exited thread's registers.

This patch moves the get_thread_regcache calls to branches that
actually need it, where we know the thread is still alive.

It also adds an assertion to get_thread_regcache, to help catching
these broken cases sooner.

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

Ensure selected thread after thread exit stop

While making step over thread exit work properly on AMDGPU, I noticed
that if there's a breakpoint on top of the exit syscall, and,
displaced stepping is off, then when GDB reports "Command aborted,
thread exited.", GDB also switches focus to a random thread, instead
of leaving the exited thread as selected:

 (gdb) thread
 [Current thread is 6, lane 0 (AMDGPU Lane 1:4:1:1/0 (0,0,0)[0,0,0])]
 (gdb) si
 Command aborted, thread exited.
 (gdb) thread
 [Current thread is 5 (Thread 0x7ffff626f640 (LWP 3248392))]
 (gdb)

The previous patch extended gdb.threads/step-over-thread-exit.exp to
exercise this on GNU/Linux (on the CPU side), and there, after that
"si", we always end up with the exiting thread as selected even
without this fix, but that's just a concidence, there's a code path
that happens to select the exiting thread for an unrelated reason.

This commit add the explict switch, fixing the latent problem for
GNU/Linux, and the actual problem on AMDGPU.  I wrote a gdb.rocm/
testcase for this, but it can't be upstreamed yet, until more pieces
of the DWARF machinery are upstream as well.

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

gdb.threads/step-over-thread-exit.exp improvements

This commit makes the following improvements to
gdb.threads/step-over-thread-exit.exp:

- Add a third axis to stepping over the breakpoint with displaced vs
  inline stepping -- also test with no breakpoint at all.

- Check that when GDB reports "Command aborted, thread exited.", the
  selected thread is the thread that exited.  This is always true
  currently on GNU/Linux by coincidence, but a similar testcase on AMD
  GPU exposed a problem here.  Better make the testcase catch any
  potential regression.

- Fixes a race that Simon ran into with GDBserver testing.

    (gdb) next
    [New Thread 2143071.2143438]

    Thread 3 "step-over-threa" hit Breakpoint 2, 0x000055555555524e in my_exit_syscall () at .../testsuite/lib/my-syscalls.S:74
    74      SYSCALL (my_exit, __NR_exit)
    (gdb) FAIL: gdb.threads/step-over-thread-exit.exp: displaced-stepping=auto: non-stop=on: target-non-stop=on: schedlock=off: cmd=next: ns_stop_all=0: command aborts when thread exits

  I was not able to reproduce it, but I believe that what happens is
  the following:

  Once we continue, the thread 2 exits, and the main thread thus
  unblocks from its pthread_join, and spawns a new thread.  That new
  thread may hit the breakpoint at my_exit_syscall very quickly.  GDB
  could then see/process that breakpoint event before the thread exit
  event for the thread we care about, which would result in the
  failure seen above.

  The fix here is to not loop and start a new thread at all in the
  scenario where the race can happen.  We only need to loop and spawn
  new threads when testing with "cmd=continue" and schedlock off, in
  which case GDB doesn't abort the command when the thread exits.

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

Fix bug in previous remote unique_ptr change

By inspection, I noticed that the previous patch went too far, here:

 @@ -7705,7 +7713,8 @@ remote_target::discard_pending_stop_replies (struct inferior *inf)
    if (rs->remote_desc == NULL)
      return;

 -  reply = (struct stop_reply *) rns->pending_event[notif_client_stop.id];
 +  stop_reply_up reply
 +    = as_stop_reply_up (std::move (rns->pending_event[notif_client_stop.id]));

    /* Discard the in-flight notification.  */
    if (reply != NULL && reply->ptid.pid () == inf->pid)

That is always moving the stop reply from pending_event, when we only
really want to peek into it.  The code further below that even says:

  /* Discard the in-flight notification.  */
  if (reply != NULL && reply->ptid.pid () == inf->pid)
    {
      /* Leave the notification pending, since the server expects that
 we acknowledge it with vStopped.  But clear its contents, so
 that later on when we acknowledge it, we also discard it.  */

This commit reverts that hunk back, adjusted to use unique_ptr::get().

Change-Id: Ifc809d1a8225150a4656889f056d51267100ee24

Complete use of unique_ptr with notif_event and stop_reply

We already use unique_ptr with notif_event and stop_reply in some
places around the remote target, but not fully.  There are several
code paths that still use raw pointers.  This commit makes all of the
ownership of these objects tracked by unique pointers, making the
lifetime flow much more obvious, IMHO.

I notice that it fixes a leak -- in remote_notif_stop_ack, We weren't
destroying the stop_reply object if it was of TARGET_WAITKIND_IGNORE
kind.

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

Make cached_reg_t own its data

struct cached_reg_t owns its data buffer, but currently that is
managed manually.  Convert it to use a unique_xmalloc_ptr.

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

gdb: remove stale comment and ctor in gdbarch_info

tdesc_data is not part of a union, since commit 4f3681cc3361 ("Fix thread's
gdbarch when SVE vector length changes").  Remove the stale comment and
constructor.

Change-Id: Ie895ce36614930e8bd9c4967174c8bf1b321c503

s390: Add suffix to conditional branch instruction descriptions

Suffix the instruction description of conditional branch extended
mnemonics with their condition (e.g. "on A high"). This complements
the optional printing of instruction descriptions as comments in the
disassembly.

Due to the added text the maximum description length is increased from
80 to 128 characters (including the trailing '\0' character).

opcodes/
* s390-mkopc.c: Add suffix to conditional branch extended
  mnemonic instruction descriptions.

gas/
* testsuite/gas/s390/zarch-insndesc.s: Add test cases for
  printing of suffixed instruction description of conditional
  branch extended mnemonics.
* testsuite/gas/s390/zarch-insndesc.d: Likewise.

Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

s390: Optionally print instruction description in disassembly

Print instruction description as comment in disassembly with s390
architecture specific option "insndesc":

- For objdump it can be enabled with option "-M insndesc"
- In gdb it can be enabled with "set disassembler-options insndesc"

Since comments are not column aligned the output can enhanced for
readability by postprocessing using a filter such as "expand":

... | expand -t 8,16,24,32,40,80

Or when using in combination with objdump option --visualize-jumps:

... | expand | sed -e 's/ *#/\t#/' | expand -t 1,80

Note that the instruction descriptions add about 128 KB to s390-opc.o:

s390-opc.o without instruction descriptions: 216368 bytes
s390-opc.o with instruction descriptions   : 348432 bytes

binutils/
* NEWS: Mention new s390-specific disassembler option
  "insndesc".

include/
* opcode/s390.h (struct s390_opcode): Add field to hold
  instruction description.

opcodes/
* s390-mkopc.c: Copy instruction description from s390-opc.txt
  into generated operation code table s390-opc.tab.
* s390-opc.c (s390_opformats): Provide NULL as description in
  .insn pseudo-mnemonics opcode table.
* s390-dis.c: Add s390-specific disassembler option "insndesc"
  and optionally print the instruction description as comment in
  the disassembly when it is specified.

gas/
* testsuite/gas/s390/s390.exp: Add new test disassembly test
  case "zarch-insndesc".
* testsuite/gas/s390/zarch-insndesc.s: New test case for s390-
  specific disassembler option "insndesc".
* testsuite/gas/s390/zarch-insndesc.d: Likewise.

Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

s390: Use safe string functions and length macros in s390-mkopc

Use strncpy() and snprintf() instead of strcpy() and strcat(). Define
and use macros for string lengths, such as mnemonic, instruction
format, and instruction description.

This is a mechanical change, although some buffers have increased in
length by one character. This has been confirmed by verifying that the
generated opcode/s390-opc.tab is unchanged.

opcodes/
* s390-mkopc.c: Use strncpy() and strncat().

Suggested-by: Nick Clifton <nickc@redhat.com>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

s390: Enhance error handling in s390-mkopc

When the s390-mkopc utility detects an error it prints an error message
to strerr and either continues processing or exists with a non-zero
return code. If it continues without detecting any further error the
final return code was zero, potentially hiding the detected error.

Introduce a global variable to hold the final return code and initialize
it to EXIT_SUCCESS. Introduce a helper function print_error() that
prints an error message to stderr and sets the final return code to
EXIT_FAILURE. Use it to print all error messages. Return the final
return code at the end of the processing.

While at it enhance error messages to state more clearly which mnemonic
an error was detected for. Also continue processing for cases where
subsequent mnemonics can be processed.

opcodes/
* s390-mkopc.c: Enhance error handling. Return EXIT_FAILURE
  in case of an error, otherwise EXIT_SUCCESS.

Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

s390: Provide IBM z16 (arch14) instruction descriptions

Provide descriptions for instructions introduced with commit ba2b480f103
("IBM Z: Implement instruction set extensions"). This complements commit
69341966def ("IBM zSystems: Add support for z16 as CPU name."). Use
instruction names from IBM z/Architecture Principles of Operation [1] as
instruction description.

[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
     https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf

opcodes/
* s390-opc.txt: Add descriptions for IBM z16 (arch14)
  instructions.

Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

s390: Align letter case of instruction descriptions

Change the bitwise operations names "and" and "or" to lower case. Change
the register name abbreviations "FPR", "GR", and "VR" to upper case.

opcodes/
* s390-opc.txt: Align letter case of instruction descriptions.

Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

s390: Fix build when using EXEEXT_FOR_BUILD

Suffix the s390-mkopc build utility executable file name with
EXEEXT_FOR_BUILD. Otherwise it cannot be located when building with
EXEEXT_FOR_BUILD. Use pattern used for other architecture build
utilities and compile and link s390-mkopc in two steps.

While at it also specify the dependencies of s390-mkopc.c.

opcodes/
* Makefile.am: Add target to build s390-mkopc.o. Correct
  target to build s390-mkopc$(EXEEXT_FOR_BUILD).
* Makefile.in: Regenerate.

Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>

sim: frv: enable warnings in memory.c

Fix one minor pointer-sign warning to enable warnings in general
for this file.  Reading the data as signed and then returning it
as unsigned should be functionally the same in this case.

Automatic date update in version.in

Re: PR31145, potential memory leak in binutils/ld

Revert most of this patch, it isn't correct to free the BFD_IN_MEMORY
iostream in io_reinit.

PR 31145
* format.c (io_reinit): Revert last change.  Comment.
* opncls.c (_bfd_delete_bfd): Likewise.

gdb: use put_frame_register instead of put_frame_register_bytes in pseudo_to_concat_raw

Here, we write single complete registers, we don't need the
functionality of put_frame_register_bytes, use put_frame_register
instead.

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

gdb: remove stale comment in value_assign

This comment is no longer relevant, put_frame_register_bytes now accepts
the "next frame".

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

aarch64: Add FEAT_ITE support

This patch add support for FEAT_ITE "Instrumentation Extension" adding
the "trcit" instruction.

This is enabled by the +ite march flag.

aarch64: Add FEAT_ECBHB support

This patch add support for FEAT_ECBHB "Exploitative control using
branch history information" adding the "clrbhb" instruction.  AFAIU
the same alias was originally added as "clearbhb" before the
architecture was finalized (Mandatory v8.9-a/v9.4-a; Optional
v8.0-a+/v9.0-a+).

aarch64: Add FEAT_SPECRES2 support

This patch add supports for FEAT_SPECRES2 "Enhanced speculation
restriction instructions" adding the "cosp" instruction.

This is mandatory v8.9-a/v9.4-a and optional v8.0-a+/v9.0-a+.  It is
enabled by the +predres2 march flag.

gdb: register frame_destroyed function for amd64 gdbarch

gdbarches usually register functions to check when a frame is destroyed
which is used with software watchpoints, since the expression of the
watchpoint is no longer vlaid at this point.  On amd64, this wasn't done
anymore because GCC started using CFA for variable locations instead.

However, clang doesn't use the CFA and instead relies on specifying when
an epilogue has started, meaning software watchpoints get a spurious hit
when a frame is destroyed. This patch re-adds the code to register the
function that detects when a frame is destroyed, but only uses this when
the producer is LLVM, so gcc code isn't affected. The logic that
identifies the epilogue has been factored out into the new function
amd64_stack_frame_destroyed_p_1, so the frame sniffer can call it
directly, and its behavior isn't changed.

This can also remove the XFAIL added to gdb.python/pq-watchpoint tests
that handled this exact flaw in clang.

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

sim: common: delete unused argbuf in generated mloop code

This function only uses prev_abuf, not abuf, and doesn't inline code
from the various ports on the fly, so abuf will never be used.

sim: v850: fix -Wunused-variable warnings

sim: sh: fix -Wunused-variable warnings

sim: moxie: fix -Wunused-variable warnings

sim: msp430: fix -Wunused-variable warnings

sim: mn10300: fix -Wunused-variable warnings

sim: mips: fix -Wunused-variable warnings

sim: microblaze: fix -Wunused-variable warnings

sim: mcore: fix -Wunused-variable warnings

sim: m32r: fix -Wunused-variable warnings

sim: lm32: fix -Wunused-variable warnings

sim: iq2000: fix -Wunused-variable warnings

sim: h8300: fix -Wunused-variable warnings

sim: ft32: fix -Wunused-variable warnings

sim: frv: fix -Wunused-variable warnings

sim: erc32: fix -Wunused-variable warnings

sim: cris: fix -Wunused-variable warnings

sim: cr16: fix -Wunused-variable warnings

sim: bpf: fix -Wunused-variable warnings

sim: bfin: fix -Wunused-variable warnings

sim: aarch64: fix -Wunused-variable warnings

sim: common: fix -Wunused-variable warnings

cpu: cris: drop some unused vars

These fix unused variable warnings in the generated sim.

x86: Remove the restriction for size of the mask register in AVX10

Since AVX10.1/256 will also allow 64 bit mask register, we will
remove the restriction for size of the mask register in AVX10.

gas/ChangeLog:

* config/tc-i386.c (VSZ128, VSZ256, VSZ512): New.
(VEX_check_encoding): Remove opcode_modifier check for vsz.
* testsuite/gas/i386/avx10-vsz.l: Remove testcases for mask
registers since they are not needed.
* testsuite/gas/i386/avx10-vsz.s: Ditto.

opcodes/ChangeLog:

* i386-gen.c: Remove Vsz.
* i386-opc.h: Ditto.
* i386-opc.tbl: Remove kvsz.
* i386-tbl.h: Regenerated.

LoongArch: Allow la.got -> la.pcrel relaxation for shared object

Even in shared objects, la.got -> la.pcrel relaxation can still be
performed for symbols with hidden visibility. For example, if a.c is:

    extern int x;
    int f() { return x++; }

and b.c is:

    int x = 114514;

If compiling and linking with:

    gcc -shared -fPIC -O2 -fvisibility=hidden a.c b.c

Then the la.got in a.o should be relaxed to la.pcrel, and the resulted f
should be like:

    pcaddi  $t0, x
    ldptr.w $a0, $t0, 0
    addi.w  $t1, $a0, 1
    stptr.w $t1, $t0, 0
    ret

Remove bfd_link_executable from the condition of la.got -> la.pcrel
relaxation so this will really happen.  The SYMBOL_REFERENCES_LOCAL
check is enough not to wrongly relax preemptable symbols (for e.g.
when -fvisibility=hidden is not used).

Note that on x86_64 this is also relaxed and the produced code is like:

    lea x(%rip), %rdx
    mov (%rdx), %rax
    lea 1(%rax), %ecx
    mov %ecx, (%rdx)
    ret

Tested by running ld test suite, bootstrapping and regtesting GCC with
the patched ld, and building and testing Glibc with the patched ld.  No
regression is observed.

Signed-off-by: Xi Ruoyao <xry111@xry111.site>

Yet another fix for mcore-sim (rotli)

This came up testing the CRC optimization work from Mariam@RAU.
Basically to optimize some CRC loops into table lookups or carryless
multiplies, we may need to do a bit reflection, which on the mcore
processor is done using a rotate instruction.

Unfortunately the simulator implementation of rotates has the exact same
problem as we saw with right shifts.  The input value may have been sign
extended from 32 to 64 bits.  When we rotate the extended value, we get
those sign extension bits and thus the wrong result.

The fix is the same.  Rather than using a "long", use a uint32_t for the
type of the temporary.  This fixes a handful of tests in the GCC testsuite:

Automatic date update in version.in

gettext: disable install, docs targets, libasprintf, threads

This fixes issues reported by David Edelsohn <dje.gcc@gmail.com>, and by
Eric Gallager <egallager@gcc.gnu.org>.

ChangeLog:

* Makefile.def (gettext): Disable (via missing)
{install-,}{pdf,html,info,dvi} and TAGS targets.  Set no_install
to true.  Add --disable-threads --disable-libasprintf.
* Makefile.in: Regenerate.

ld: Print 0 size in B and not in GB

When using --print-memory-usage, the printed size can be zero and in
that case, the unit should be B and not GB.

ld/
* ldlang.c (lang_print_memory_size) Print 0 B instead of 0 GB.
* testsuite/ld-scripts/print-memory-usage-1.l: Validate emplty region.
* testsuite/ld-scripts/print-memory-usage-1.t: Define empty region.

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

PR31162, Memory Leak in ldwrite.c

This isn't a particularly worrying memory leak, but fix it anyway.

PR 31162
* ldwrite.c (build_link_order): Use bfd_alloc rather than xmalloc.
Add %E to error messages.

gdb/testsuite: another attempt to fix gdb.threads/thread-specific-bp.exp

The gdb.threads/thread-specific-bp.exp test has been a little
problematic, see commits:

  commit 89702edd933a5595557bcd9cc4a0dcc3262226d4
  Date:   Thu Mar 9 12:31:26 2023 +0100

      [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp on native-gdbserver

and

  commit 2e5843d87c4050bf1109921481fb29e1c470827f
  Date:   Fri Nov 19 14:33:39 2021 +0100

      [gdb/testsuite] Fix gdb.threads/thread-specific-bp.exp

But I recently saw a test failure for that test, which looked like
this:

  ...
  (gdb) PASS: gdb.threads/thread-specific-bp.exp: non_stop=on: thread 1 selected
  continue -a
  Continuing.

  Thread 1 "thread-specific" hit Breakpoint 4, end () at /tmp/binutils-gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/thread-specific-bp.c:29
  29      }
  (gdb) [Thread 0x7ffff7c5c700 (LWP 1552086) exited]
  Thread-specific breakpoint 3 deleted - thread 2 no longer in the thread list.
  FAIL: gdb.threads/thread-specific-bp.exp: non_stop=on: continue to end (timeout)
  ...

This only crops up (for me) when running on a loaded machine, and
still only occurs sometimes.  I've had to leave the test running in a
loop for 10+ minutes sometimes in order to see the failure.

The problem is that we use gdb_test_multiple to try and match two
patterns:

  (1) The 'Thread-specific breakpoint 3 deleted ....' message, and
  (2) The GDB prompt.

As written in the test, we understand that these patterns can occur in
any order, and we have a flag for each pattern.  Once both patterns
have been seen then we PASS the test.

The problem is that once expect has matched a pattern, everything up
to, and including the matched text is discarded from the input
buffer.  Thus, if the input buffer contains:

  <PATTERN 2><PATTERN 1>

Then expect will first try to match <PATTERN 1>, which succeeds, and
then expect discards the entire input buffer up to the end of the
<PATTERN 1>.  As a result, we will never spot <PATTERN 2>.

Obviously we can't just reorder the patterns within the
gdb_test_multiple, as the output can legitimately (and most often
does) occur in the other order, in which case the test would mostly
fail, and only occasionally pass!

I think the easiest solution here is just to have the
gdb_test_multiple contain two patterns, each pattern consists of the
two parts, but in the alternative orders, thus, for a particular
output configuration, only one regexp will match.  With this change in
place, I no longer see the intermittent failure.

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

LoongArch: Add call36 and tail36 pseudo instructions for medium code model

  For tail36, it is necessary to explicitly indicate the temporary register.
  Therefore, the compiler and users will know that the tail will use a register.

  call36 func
    pcalau18i $ra, %call36(func)
    jirl      $ra, $ra, 0;

  tail36 $t0, func
    pcalau18i $t0, %call36(func)
    jirl      $zero, $t0, 0;

LoongArch: Add new relocation R_LARCH_CALL36

R_LARCH_CALL36 is used for medium code model function call pcaddu18i+jirl, and
these two instructions must adjacent.

The LoongArch ABI v2.20 at here: https://github.com/loongson/la-abi-specs.

PR31177: Let region text start at __TEXT_REGION_ORIGIN___

The start of MEMORY region text currently starts hard-coded at 0.

The linker can produce more exact diagnostics when it knows the exact placements of the memory regions.

For some old devices, program memory starts at 0x8000, so allow to specify program memory start at __TEXT_REGION_ORIGIN__ similar to how the data region is described.

If ok, please apply to master.
This one is also fine to back-port.

Johann

--

AVR: Use __TEXT_REGION_ORIGIN__ as start for MEMORY region text.

ld/
PR 31177
* scripttempl/avr.sc (__TEXT_REGION_ORIGIN__): New symbol.
(MEMORY): Use as start address for the text region.

Automatic date update in version.in