Automatic date update in version.in

Fix result of DAP setExpression

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

This patch fixes the problems.

Remove unchecked casts to mi_interp

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

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

This patch replaces all such casts with safer variants.

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

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

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

Regression tested on x86-64 Fedora 36.

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

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

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

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

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

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

gdb: remove last alloca call from printcmd.c

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

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

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

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

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

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

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

There should be no user visible differences after this commit.

gdb: remove two uses of alloca from printcmd.c

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

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

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

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

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

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

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

There should be no user visible changes after this commit.

gdb: fix printf of wchar_t early in a gdb session

Given this test program:

  #include <wchar.h>

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

  int
  main (void)
  {
    return 0;
  }

I observed this GDB behaviour:

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

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

  (gdb)

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

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

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

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

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

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

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

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

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

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

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

ld: fix build with old glibc / gcc

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

arc: Update/Add ARCv3 support.

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

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

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

gdb/testsuite: fix license on recently added file

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

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

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

The problems were:

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

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

Udated Freach and Romainian translations for various sub-directories

Minor updates to release readme

Automatic date update in version.in

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

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

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

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

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

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

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

Fix this in both native GDB and GDBserver.

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

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

riscv: Ensure LE instruction fetching

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

Fix Solaris regression (PR tdep/30252)

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

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

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

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

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

The target_resume interface is:

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

Thus calling target_resume with inferior_ptid == null_ptid is bogus.

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

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

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

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

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

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

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

ld: fix plugin tests for MIPS PIC

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

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

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

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

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

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

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

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

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

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

ld/ChangeLog:

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

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

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

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

ld/ChangeLog:

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

Automatic date update in version.in

Align linkerscript symbols according to ABI

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

Automatic date update in version.in

x86: optimize 128-bit VPBROADCASTQ to VPUNPCKLQDQ

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

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

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

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

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

x86: flag bad EVEX masking for miscellaneous insns

Masking is not permitted for certain further insns, not falling in any
of the earlier categories. Introduce the Y macro (not expanding to any
output) to flag such cases.

Note that in a few cases entries already covered otherwise are converted
as well, to continue to allow sharing of the string literals.

x86: flag EVEX masking when destination is GPR(-like)

Masking is not permitted in this case. See the code comment for how this
is being dealt with.

To avoid excess special casing of modes, have OP_M() call OP_E_memory()
directly.

x86: flag EVEX.z set when destination is memory

Zeroing-masking is not permitted in this case. See the code comment for
how this is being dealt with.

x86: flag EVEX.z set when destination is a mask register

While only zeroing-masking is possible in this case, this still requires
EVEX.z to be clear. Introduce a "global" flag right here, to be re-used
by checks which need to live in specific operand handlers.

x86: re-work EVEX-z-without-masking check

Rather than corrupting disassmbly altogether, flag EVEX.z set as bad
when masking isn't in effect in the first place at the time the
destination operand is actually processed.

gdb: add __repr__() implementation to a few Python types

Only a few types in the Python API currently have __repr__()
implementations.  This patch adds a few more of them. specifically: it
adds __repr__() implementations to gdb.Symbol, gdb.Architecture,
gdb.Block, gdb.Breakpoint, gdb.BreakpointLocation, and gdb.Type.

This makes it easier to play around the GDB Python API in the Python
interpreter session invoked with the 'pi' command in GDB, giving more
easily accessible tipe information to users.

An example of how this would look like:

  (gdb) pi
  >> gdb.lookup_type("char")
  <gdb.Type code=TYPE_CODE_INT name=char>
  >> gdb.lookup_global_symbol("main")
  <gdb.Symbol print_name=main>

The gdb.Block.__repr__() method shows the first 5 symbols from the
block, and then a message to show how many more were elided (if any).

gdb: have mdict_size always return a symbol count

In the next commit we would like to have mdict_size return the number
of symbols in the dictionary, currently mdict_size is just a
heuristic, sometimes it returns the number of symbols, and sometimes
the number of buckets in a hashing dictionary (see size_hashed in
dictionary.c).

Currently this vague notion of size is good enough, the only place
mdict_size is used is in a maintenance command in order to print a
message containing the size of the dictionary ... so we don't really
care that the value isn't correct.

However, in the next commit we do want the size returned to be the
number of symbols in the dictionary, so this commit makes mdict_size
return the symbol count in all cases.

The new use is still not on a hot path -- it's going to be a Python
__repr__ method, so all I do in this commit is have size_hashed walk
the dictionary and count the entries, obviously this could be slow if
we have a large number of symbols, but for now I'm not worrying about
that case.  We could always store the symbol count if we wanted, but
that would increase the size of every dictionary for a use case that
isn't going to be hit that often.

I've updated the text in 'maint print symbols' so that we don't talk
about the size being 'syms/buckets', but just 'symbols' now.

Updated Ukranian, Romanian and German translations for various sub-directories

arc: Update default target CPU to match GCC defaults

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

arc: Update neg<.f> 0,b encoding

Wrong encoding for null destination NEG instruction. Fix it.

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

Automatic date update in version.in

IBM Z: Fix pcrel relocs for symA-symB expressions

The code in md_apply_fix which tries to deduce from the operand type
which reloc to apply currently does the wrong thing for absolute
relocs which have been re-written by fixup_segment as pc-relative to
implement a subtraction of a local and an external symbol.

In all these cases we wrongly emit an absolute reloc because we ignore
the fx_pcrel flag in md_apply_fix. However, only for the last one we
actually support a pc relative relocation of the proper size and can
implement it accordingly. For the other 3 we have to issue an error.

foo:
  cli 0(%r2),undef-foo
  la %r2,undef-foo(%r2)
  lay %r2,undef-foo(%r2)
  lhi %r2,undef-foo

Fix two Python calls that don't check for errors

PyModule_AddObject steals a reference on success, but not on error,
which is why we have gdb_pymodule_addobject.  I found one spot still
calling the former, which could in theory leak memory on failure.
This patch fixes this.

In the same function I found an unchecked call to
PyDict_SetItemString.  This patch fixes this as well.

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

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

The previous commit added the test gdb.arch/core-file-pid0.exp which
tests GDB's ability to load a core file containing threads with an
lwpid of 0, which is something we GDB can encounter when loading a
vmcore file -- a core file generated by the Linux kernel.  The threads
with an lwpid of 0 represents idle cores.

While the previous commit added the test, which confirms GDB doesn't
crash when confronted with such a core file, there are still some
problems with GDB's handling of these core files.  These problems all
originate from the fact that the core file (once opened by bfd)
contains multiple sections called .reg/0, these sections all
represents different threads (cpu cores in the original vmcore dump),
but GDB gets confused and thinks all of these .reg/0 sections are all
referencing the same thread.

Here is a GDB session on an x86-64 machine which loads the core file
from the gdb.arch/core-file-pid0.exp, this core file contains two
threads, both of which have a pid of 0:

  $ ./gdb/gdb --data-directory ./gdb/data-directory/ -q
  (gdb) core-file /tmp/x86_64-pid0-core.core
  [New process 1]
  [New process 1]
  Failed to read a valid object file image from memory.
  Core was generated by `./segv-mt'.
  Program terminated with signal SIGSEGV, Segmentation fault.
  The current thread has terminated
  (gdb) info threads
    Id   Target Id         Frame
    2    process 1         0x00000000004017c2 in ?? ()

  The current thread <Thread ID 1> has terminated.  See `help thread'.
  (gdb) maintenance info sections
  Core file: `/tmp/x86_64-pid0-core.core', file type elf64-x86-64.
   [0]      0x00000000->0x000012d4 at 0x00000318: note0 READONLY HAS_CONTENTS
   [1]      0x00000000->0x000000d8 at 0x0000039c: .reg/0 HAS_CONTENTS
   [2]      0x00000000->0x000000d8 at 0x0000039c: .reg HAS_CONTENTS
   [3]      0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo/0 HAS_CONTENTS
   [4]      0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo HAS_CONTENTS
   [5]      0x00000000->0x00000140 at 0x000005c0: .auxv HAS_CONTENTS
   [6]      0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file/0 HAS_CONTENTS
   [7]      0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file HAS_CONTENTS
   [8]      0x00000000->0x00000200 at 0x000007cc: .reg2/0 HAS_CONTENTS
   [9]      0x00000000->0x00000200 at 0x000007cc: .reg2 HAS_CONTENTS
   [10]     0x00000000->0x00000440 at 0x000009e0: .reg-xstate/0 HAS_CONTENTS
   [11]     0x00000000->0x00000440 at 0x000009e0: .reg-xstate HAS_CONTENTS
   [12]     0x00000000->0x000000d8 at 0x00000ea4: .reg/0 HAS_CONTENTS
   [13]     0x00000000->0x00000200 at 0x00000f98: .reg2/0 HAS_CONTENTS
   [14]     0x00000000->0x00000440 at 0x000011ac: .reg-xstate/0 HAS_CONTENTS
   [15]     0x00400000->0x00401000 at 0x00002000: load1 ALLOC LOAD READONLY HAS_CONTENTS
   [16]     0x00401000->0x004b9000 at 0x00003000: load2 ALLOC READONLY CODE
   [17]     0x004b9000->0x004e5000 at 0x00003000: load3 ALLOC READONLY
   [18]     0x004e6000->0x004ec000 at 0x00003000: load4 ALLOC LOAD HAS_CONTENTS
   [19]     0x004ec000->0x004f2000 at 0x00009000: load5 ALLOC LOAD HAS_CONTENTS
   [20]     0x012a8000->0x012cb000 at 0x0000f000: load6 ALLOC LOAD HAS_CONTENTS
   [21]     0x7fda77736000->0x7fda77737000 at 0x00032000: load7 ALLOC READONLY
   [22]     0x7fda77737000->0x7fda77f37000 at 0x00032000: load8 ALLOC LOAD HAS_CONTENTS
   [23]     0x7ffd55f65000->0x7ffd55f86000 at 0x00832000: load9 ALLOC LOAD HAS_CONTENTS
   [24]     0x7ffd55fc3000->0x7ffd55fc7000 at 0x00853000: load10 ALLOC LOAD READONLY HAS_CONTENTS
   [25]     0x7ffd55fc7000->0x7ffd55fc9000 at 0x00857000: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS
   [26]     0xffffffffff600000->0xffffffffff601000 at 0x00859000: load12 ALLOC LOAD READONLY CODE HAS_CONTENTS
  (gdb)

Notice when the core file is first loaded we see two lines like:

  [New process 1]

And GDB reports:

  The current thread has terminated

Which isn't what we'd expect from a core file -- the core file should
only contain threads that are live at the point of the crash, one of
which should be the current thread.  The above message is reported
because GDB has deleted what we think is the current thread!

And in the 'info threads' output we are only seeing a single thread,
again, this is because GDB has deleted one of the threads.

Finally, the 'maintenance info sections' output shows the cause of all
our problems, two sections named .reg/0.  When GDB sees the first of
these it creates a new thread.  But, when we see the second .reg/0 GDB
tries to create another new thread, but this thread has the same
ptid_t as the first thread, so GDB deletes the first thread and
creates the second thread in its place.

Because both these threads are created with an lwpid of 0 GDB reports
these are 'New process NN' rather than 'New LWP NN' which is what we
would normally expect.

The previous commit includes a little more of the history of GDB
support in this area, but these problems were discussed on the mailing
list a while ago in this thread:

  https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/

In this commit I propose a solution to these problems.

What I propose is that GDB should spot when we have .reg/0 sections
and, when these are found, should rename these sections using some
unique non-zero lwpid.

Note in the above output we also have sections like .reg2/0 and
.reg-xstate/0, these are additional register sets, this commit also
renumbers these sections inline with their .reg section.

The user is warned that some section renumbering has been performed.

GDB takes care to ensure that the new numbers assigned are unique and
don't clash with any of the pid's that might already be in use --
remember, in a real vmcore file, 0 is used to indicate an idle core,
non-idle cores will have the pid of whichever process was running on
that core, so we don't want GDB to assign an lwpid that clashes with
an actual pid that is in use in the core file.

After this commit here's the updated GDB session output:

  $ ./gdb/gdb --data-directory ./gdb/data-directory/ -q
  (gdb) core-file /tmp/x86_64-pid0-core.core
  warning: found threads with pid 0, assigned replacement Target Ids: LWP 1, LWP 2
  [New LWP 1]
  [New LWP 2]
  Failed to read a valid object file image from memory.
  Core was generated by `./segv-mt'.
  Program terminated with signal SIGSEGV, Segmentation fault.
  #0  0x00000000004017c2 in ?? ()
  [Current thread is 1 (LWP 1)]
  (gdb) info threads
    Id   Target Id         Frame
  * 1    LWP 1             0x00000000004017c2 in ?? ()
    2    LWP 2             0x000000000040dda5 in ?? ()
  (gdb) maintenance info sections
  Core file: `/tmp/x86_64-pid0-core.core', file type elf64-x86-64.
   [0]      0x00000000->0x000012d4 at 0x00000318: note0 READONLY HAS_CONTENTS
   [1]      0x00000000->0x000000d8 at 0x0000039c: .reg/1 HAS_CONTENTS
   [2]      0x00000000->0x000000d8 at 0x0000039c: .reg HAS_CONTENTS
   [3]      0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo/1 HAS_CONTENTS
   [4]      0x00000000->0x00000080 at 0x0000052c: .note.linuxcore.siginfo HAS_CONTENTS
   [5]      0x00000000->0x00000140 at 0x000005c0: .auxv HAS_CONTENTS
   [6]      0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file/1 HAS_CONTENTS
   [7]      0x00000000->0x000000a4 at 0x00000714: .note.linuxcore.file HAS_CONTENTS
   [8]      0x00000000->0x00000200 at 0x000007cc: .reg2/1 HAS_CONTENTS
   [9]      0x00000000->0x00000200 at 0x000007cc: .reg2 HAS_CONTENTS
   [10]     0x00000000->0x00000440 at 0x000009e0: .reg-xstate/1 HAS_CONTENTS
   [11]     0x00000000->0x00000440 at 0x000009e0: .reg-xstate HAS_CONTENTS
   [12]     0x00000000->0x000000d8 at 0x00000ea4: .reg/2 HAS_CONTENTS
   [13]     0x00000000->0x00000200 at 0x00000f98: .reg2/2 HAS_CONTENTS
   [14]     0x00000000->0x00000440 at 0x000011ac: .reg-xstate/2 HAS_CONTENTS
   [15]     0x00400000->0x00401000 at 0x00002000: load1 ALLOC LOAD READONLY HAS_CONTENTS
   [16]     0x00401000->0x004b9000 at 0x00003000: load2 ALLOC READONLY CODE
   [17]     0x004b9000->0x004e5000 at 0x00003000: load3 ALLOC READONLY
   [18]     0x004e6000->0x004ec000 at 0x00003000: load4 ALLOC LOAD HAS_CONTENTS
   [19]     0x004ec000->0x004f2000 at 0x00009000: load5 ALLOC LOAD HAS_CONTENTS
   [20]     0x012a8000->0x012cb000 at 0x0000f000: load6 ALLOC LOAD HAS_CONTENTS
   [21]     0x7fda77736000->0x7fda77737000 at 0x00032000: load7 ALLOC READONLY
   [22]     0x7fda77737000->0x7fda77f37000 at 0x00032000: load8 ALLOC LOAD HAS_CONTENTS
   [23]     0x7ffd55f65000->0x7ffd55f86000 at 0x00832000: load9 ALLOC LOAD HAS_CONTENTS
   [24]     0x7ffd55fc3000->0x7ffd55fc7000 at 0x00853000: load10 ALLOC LOAD READONLY HAS_CONTENTS
   [25]     0x7ffd55fc7000->0x7ffd55fc9000 at 0x00857000: load11 ALLOC LOAD READONLY CODE HAS_CONTENTS
   [26]     0xffffffffff600000->0xffffffffff601000 at 0x00859000: load12 ALLOC LOAD READONLY CODE HAS_CONTENTS
  (gdb)

Notice the new warning which is issued when the core file is being
loaded.  The threads are announced as '[New LWP NN]', and we see two
threads in the 'info threads' output.  The 'maintenance info sections'
output shows the result of the section renaming.

The gdb.arch/core-file-pid0.exp test has been update to check for the
improved GDB output.

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

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

This patch contains a test for this commit:

  commit c820c52a914cc9d7c63cb41ad396f4ddffff2196
  Date:   Fri Aug 6 19:45:58 2010 +0000

              * thread.c (add_thread_silent): Use null_ptid instead of
              minus_one_ptid while getting rid of stale inferior_ptid.

This is another test that has been carried in the Fedora GDB tree for
some time, and I thought that it would be worth merging to master.  I
don't believe there is any test like this currently in the testsuite.

The original issue was reported in this thread:

  https://inbox.sourceware.org/gdb-patches/AANLkTi=zuEDw6qiZ1jRatkdwHO99xF2Qu+WZ7i0EQjef@mail.gmail.com/

The problem was that when GDB was used to open a vmcore (core file)
image generated by the Linux kernel GDB would (sometimes) crash with
an assertion failure:

  thread.c:884: internal-error: switch_to_thread: Assertion `inf != NULL' failed.

To understand what's going on we need some background; a vmcore file
represents each processor core in the same way that a standard
application core file represents threads.  Thus, we might say, a
vmcore file represents cores as threads.

When writing a vmcore file, the kernel will store the pid of the
process currently running on that core as the thread's lwpid.

However, if a core is idle, with no process currently running on it,
then the lwpid for that thread is stored as 0 in the vmcore file.  If
multiple cores are idle then multiple threads will have a lwpid of 0.

Back in 2010, the original issue reported tried to change the kernel's
behaviour in this thread:

  https://lkml.org/lkml/2010/8/3/75

This change was rejected by the kernel team, the current
behaviour (lwpid of 0) was considered correct.  I've checked the
source of a recent kernel.  The code mentioned in the lkml.org posting
has moved, it's now in the function crash_save_cpu in the file
kernel/kexec_core.c, but the general behaviour is unchanged, an idle
core will have an lwpid of 0, so I think GDB still needs to be able to
handle this case.

When GDB loads a vmcore file (which is handled just like any other
core file) the sections are processed in core_open to generate the
threads for the core file.  The processing is done by calling
add_to_thread_list, a function which looks for sections named .reg/NN
where NN is the lwpid of the thread, GDB then builds a ptid_t for the
new thread and calls add_thread.

Remember, in our case the lwpid is 0.  Now for the first thread this
is fine, if a little weird, 0 isn't usually a valid lwpid, but that's
OK, GDB creates a thread with lwpid of 0 and carries on.

When we find the next thread (core) with lwpid of 0, we attempt to
create another thread with an lwpid of 0.  This of course clashes with
the previously created thread, they have the same ptid_t, so GDB tries
to delete the first thread.

And it was within this thread delete code that we triggered a bug
which would then cause GDB to assert -- when deleting we tried to
switch to a thread with minus_one_ptid, this resulted in a call to
find_inferior_pid (passing in minus_one_ptid's pid, which is -1), the
find_inferior_pid call fails and returns NULL, which then triggered an
assert in switch_to_thread.

The actual details of the why the assert triggered are really not
important.  What's important (I think) is that a vmcore file might
have this interesting lwpid of 0 characteristic, which isn't something
we see in "normal" application core files, and it is this that I think
we should be testing.

Now, you might be thinking: isn't deleting the first thread the wrong
thing to do?  If the vmcore file has two threads that represent two
cores, and both have an lwpid of 0 (indicating both cores are idle),
then surely GDB should still represent this as two threads?  You're
not wrong.  This was mentioned by Pedro in the original GDB mailing
list thread here:

  https://inbox.sourceware.org/gdb-patches/201008061057.03037.pedro@codesourcery.com/

This is indeed a problem, and this problem is still present in GDB
today.  I plan to try and address this in a later commit, however,
this first commit is about getting a test in place to confirm that GDB
at a minimum doesn't crash when loading such a vmcore file.

And so, finally, what's in this commit?

This commit contains a new test.  The test doesn't actually contain a
vmcore file.  Instead I've created a standard application core file
that contains two threads, and then manually edited the core file to
set the lwpid of each thread to 0.

To further reduce the size of the core file (as it will be stored in
git), I've zeroed all of the LOAD-able segments in the core file.
This test really doesn't care about that part of the core file, we
only really care about loading the register's, this is enough to
confirm that the GDB doesn't crash.

Obviously as the core file is pre-generated, this test is architecture
specific.  There are already a few tests in gdb.arch/ that include
pre-generate core files.  Just as those existing tests do, I've
compressed the core file with bzip2, which reduces it to just 750
bytes.  I have structured the test so that if/when this patch is
merged I can add some additional core files for other architectures,
however, these are not included in this commit.

The test simply expands the core file, and then loads it into GDB.
One interesting thing to note is that GDB reports the core file
loading like this:

  (gdb) core-file ./gdb/testsuite/outputs/gdb.arch/core-file-pid0/core-file-pid0.x86-64.core
  [New process 1]
  [New process 1]
  Failed to read a valid object file image from memory.
  Core was generated by `./segv-mt'.
  Program terminated with signal SIGSEGV, Segmentation fault.
  The current thread has terminated
  (gdb)

There's two interesting things here: first, the repeated "New process
1" message.  This is caused because linux_core_pid_to_str reports
anything with an lwpid of 0 as a process, rather than an LWP.  And
second, the "The current thread has terminated" message.  This is
because the first thread in the core file is the current thread, but
when GDB loads the second thread (which also has lwpid 0) this causes
the first thread to be deleted, as a result GDB thinks that the
current (first) thread has terminated.

As I said previously, both of these problems are a result of the lwpid
0 aliasing, which is not being fixed in this commit -- this commit is
just confirming that GDB doesn't crash when loading this core file.

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

gdb: split inferior and thread setup when opening a core file

I noticed that in corelow.c, when a core file is opened, both the
thread and inferior setup is done in add_to_thread_list.  In this
patch I propose hoisting the inferior setup out of add_to_thread_list
into core_target_open.

The only thing about this change that gave me cause for concern is
that in add_to_thread_list, we only setup the inferior after finding
the first section with a name like ".reg/NN".  If we find no such
section then the inferior will never be setup.

Is this important?

Well, I don't think so.  Back in core_target_open, if there is no
current thread (which there will not be if no ".reg/NN" section was
found), then we look for a thread in the current inferior.  If there
are no threads (which there will not be if no ".reg/NN" is found),
then we once again setup the current inferior.

What I think this means, is that, in all cases, the current inferior
will end up being setup.  By moving the inferior setup code earlier in
core_target_open and making it non-conditional, we can remove the
later code that sets up the inferior, we now know this will always
have been done.

There should be no user visible changes after this commit.

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

Update after creating 2.41 branch

Change version number to 2.41.50 and regenerate files

RISC-V: Zvkh[a,b]: Remove individual instruction class

Currently we have three instruction classes defined for Zvkh[a,b]:
- INSN_CLASS_ZVKNHA
- INSN_CLASS_ZVKNHB
- INSN_CLASS_ZVKNHA_OR_ZVKNHB

The encodings of all instructions in Zvknh[a,b] are identical.
Therefore, we don't need the individual instruction classes
and can remove them.

This patch also adds the missing support of the combined instruction
class in riscv_multi_subset_supports_ext().

Fixes: 62edb233ef5 ("RISC-V: Add support for the Zvknh[a,b] ISA extensions")
Reported-By: Nelson Chu <nelson@rivosinc.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

Add markers for the 2.41 branch

gas: NEWS: Announce LoongArch changes in the 2.41 cycle

gas/ChangeLog:

* NEWS: Mention LoongArch changes for 2.41.

Signed-off-by: WANG Xuerui <git@xen0n.name>

binutils: NEWS: Announce LoongArch changes in the 2.41 cycle

binutils/ChangeLog:

* NEWS: Mention LoongArch changes for 2.41.

Signed-off-by: WANG Xuerui <git@xen0n.name>

LoongArch: gas: Fix shared builds

Formerly an include of libbfd.h was added in commit 56576f4a722
("LoongArch: gas: Add support for linker relaxation."), in order to
allow calling _bfd_read_unsigned_leb128 from gas, but doing so broke
shared builds. Commit d2fddb6d783 fixed this reference but did not
remove the now unnecessary inclusion of libbfd.h. The gas_assert macro
expands into a conditional call to abort(), but "abort" is re-defined to
_bfd_abort in libbfd.h, so the extra include breaks any gas_assert
usage, and should be removed.

gas/ChangeLog:

* config/tc-loongarch.c: Don't include libbfd.h.

Fixes: d2fddb6d783 ("LoongArch: Fix ld "undefined reference" error with --enable-shared")
Signed-off-by: WANG Xuerui <git@xen0n.name>

opcodes/loongarch: Mark address offset operands of LVZ/LBT insns as such

opcodes/ChangeLog:

* loongarch-opc.c: Mark the offset operands as "so" for
{,x}v{ld,st}, {,x}v{ldrepl,stelm}.[bhwd], and {ld,st}[lr].[wd].

Signed-off-by: WANG Xuerui <git@xen0n.name>

Automatic date update in version.in

Automatic date update in version.in

gprofng: fix data race

In our GUI project (https://savannah.gnu.org/projects/gprofng-gui), we use
the output of gprofng to display the data. Sometimes this data is corrupted.

gprofng/ChangeLog
2023-06-29  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* src/ipc.cc (ipc_doWork): Fix data race.
* src/ipcio.cc (IPCresponse::print): Fix data race.
Remove unused variables and functions.
* src/ipcio.h: Declare two variables.
* src/StringBuilder.cc (StringBuilder::write): New function.
* src/StringBuilder.h: Likewise.

binutils: NEWS: Announce new RISC-V vector crypto extensions

This commit adds the recently added support of the RISC-V vector crypto
extensions to the NEWS file.

binutils/ChangeLog:

* NEWS: Announce new RISC-V vector crypto extensions.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add support for the Zvksc ISA extension

Zvksc is part of the vector crypto extensions.

Zvksc is shorthand for the following set of extensions:
- Zvks
- Zvbc

bfd/ChangeLog:

* elfxx-riscv.c: Define Zvksc extension.

gas/ChangeLog:

* testsuite/gas/riscv/zvksc.d: New test.
* testsuite/gas/riscv/zvksc.s: New test.

Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add support for the Zvknc ISA extension

Zvknc is part of the vector crypto extensions.

Zvknc is shorthand for the following set of extensxions:
- Zvkn
- Zvbc

bfd/ChangeLog:

* elfxx-riscv.c: Define Zvknc extension.

gas/ChangeLog:

* testsuite/gas/riscv/zvknc.d: New test.
* testsuite/gas/riscv/zvknc.s: New test.

Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add support for the Zvksg ISA extension

Zvksg is part of the vector crypto extensions.

Zvksg is shorthand for the following set of extensions:
- Zvks
- Zvkg

bfd/ChangeLog:

* elfxx-riscv.c: Define Zvksg extension.

gas/ChangeLog:

* testsuite/gas/riscv/zvksg.d: New test.
* testsuite/gas/riscv/zvksg.s: New test.

Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add support for the Zvks ISA extension

Zvks is part of the vector crypto extensions.

Zvks is shorthand for the following set of extensions:
- Zvksed
- Zvksh
- Zvbb
- Zvkt

bfd/ChangeLog:

* elfxx-riscv.c: Define Zvks extension.

gas/ChangeLog:

* testsuite/gas/riscv/zvks.d: New test.
* testsuite/gas/riscv/zvks.s: New test.

Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add support for the Zvkng ISA extension

Zvkng is part of the vector crypto extensions.

Zvkng is shorthand for the following set of extensions:
- Zvkn
- Zvkg

bfd/ChangeLog:

* elfxx-riscv.c: Define Zvkng extension.

gas/ChangeLog:

* testsuite/gas/riscv/zvkng.d: New test.
* testsuite/gas/riscv/zvkng.s: New test.

Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Allow nested implications for extensions

Certain extensions require two levels of implications.  For example,
zvkng implies zvkn and zvkn implies zvkned.  Enabling zvkng should also
enable zvkned.

This patch fixes this behavior.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_parse_add_implicit_subsets): Allow nested
implications for extensions.

Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add support for the Zvkn ISA extension

Zvkn is part of the vector crypto extensions.

Zvkn is shorthand for the following set of extensions:
- Zvkned
- Zvknhb
- Zvbb
- Zvkt

bfd/ChangeLog:

* elfxx-riscv.c: Define Zvkn extension.

gas/ChangeLog:

* testsuite/gas/riscv/zvkn.d: New test.
* testsuite/gas/riscv/zvkn.s: New test.

Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add support for the Zvksh ISA extension

Zvksh is part of the vector crypto extensions.

This extension adds the following instructions:
- vsm3me.vv
- vsm3c.vi

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
class support for Zvksh.
(riscv_multi_subset_supports_ext): Likewise.

gas/ChangeLog:

* testsuite/gas/riscv/zvksh.d: New test.
* testsuite/gas/riscv/zvksh.s: New test.

include/ChangeLog:

* opcode/riscv-opc.h (MATCH_VSM3C_VI): New.
(MASK_VSM3C_VI): New.
(MATCH_VSM3ME_VV): New.
(MASK_VSM3ME_VV): New.
(DECLARE_INSN): New.
* opcode/riscv.h (enum riscv_insn_class): Add instruction class
support for Zvksh.

opcodes/ChangeLog:

* riscv-opc.c: Add Zvksh instructions.

Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add support for the Zvksed ISA extension

Zvksed is part of the vector crypto extensions.

This extension adds the following instructions:
- vsm4k.vi
- vsm4r.[vv,vs]

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
class support for Zvksed.
(riscv_multi_subset_supports_ext): Likewise.

gas/ChangeLog:

* testsuite/gas/riscv/zvksed.d: New test.
* testsuite/gas/riscv/zvksed.s: New test.

include/ChangeLog:

* opcode/riscv-opc.h (MATCH_VSM4K_VI): New.
(MASK_VSM4K_VI): New.
(MATCH_VSM4R_VS): New.
(MASK_VSM4R_VS): New.
(MATCH_VSM4R_VV): New.
(MASK_VSM4R_VV): New.
(DECLARE_INSN): New.
* opcode/riscv.h (enum riscv_insn_class): Add instruction class
support for Zvksed.

opcodes/ChangeLog:

* riscv-opc.c: Add Zvksed instructions.

Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add support for the Zvknh[a,b] ISA extensions

Zvknh[a,b] are parts of the vector crypto extensions.

This extension adds the following instructions:
- vsha2ms.vv
- vsha2c[hl].vv

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
class support for Zvknh[a,b].
(riscv_multi_subset_supports_ext): Likewise.

gas/ChangeLog:

* testsuite/gas/riscv/zvknha.d: New test.
* testsuite/gas/riscv/zvknha_zvknhb.s: New test.
* testsuite/gas/riscv/zvknhb.d: New test.

include/ChangeLog:

* opcode/riscv-opc.h (MATCH_VSHA2CH_VV): New.
(MASK_VSHA2CH_VV): New.
(MATCH_VSHA2CL_VV): New.
(MASK_VSHA2CL_VV): New.
(MATCH_VSHA2MS_VV): New.
(MASK_VSHA2MS_VV): New.
(DECLARE_INSN): New.
* opcode/riscv.h (enum riscv_insn_class): Add instruction class
support for Zvknh[a,b].

opcodes/ChangeLog:

* riscv-opc.c: Add Zvknh[a,b] instructions.

Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add support for the Zvkned ISA extension

Zvkned is part of the vector crypto extensions.

This extension adds the following instructions:
- vaesef.[vv,vs]
- vaesem.[vv,vs]
- vaesdf.[vv,vs]
- vaesdm.[vv,vs]
- vaeskf1.vi
- vaeskf2.vi
- vaesz.vs

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
class support for Zvkned.
(riscv_multi_subset_supports_ext): Likewise.

gas/ChangeLog:

* testsuite/gas/riscv/zvkned.d: New test.
* testsuite/gas/riscv/zvkned.s: New test.

include/ChangeLog:

* opcode/riscv-opc.h (MATCH_VAESDF_VS): New.
(MASK_VAESDF_VS): New.
(MATCH_VAESDF_VV): New.
(MASK_VAESDF_VV): New.
(MATCH_VAESDM_VS): New.
(MASK_VAESDM_VS): New.
(MATCH_VAESDM_VV): New.
(MASK_VAESDM_VV): New.
(MATCH_VAESEF_VS): New.
(MASK_VAESEF_VS): New.
(MATCH_VAESEF_VV): New.
(MASK_VAESEF_VV): New.
(MATCH_VAESEM_VS): New.
(MASK_VAESEM_VS): New.
(MATCH_VAESEM_VV): New.
(MASK_VAESEM_VV): New.
(MATCH_VAESKF1_VI): New.
(MASK_VAESKF1_VI): New.
(MATCH_VAESKF2_VI): New.
(MASK_VAESKF2_VI): New.
(MATCH_VAESZ_VS): New.
(MASK_VAESZ_VS): New.
(DECLARE_INSN): New.
* opcode/riscv.h (enum riscv_insn_class): Add instruction class
support for Zvkned.

opcodes/ChangeLog:

* riscv-opc.c: Add Zvkned instructions.

Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add support for the Zvkg ISA extension

Zvkg is part of the vector crypto extensions.

This extension adds the following instructions:
- vghsh.vv
- vgmul.vv

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
class support for Zvkg.
(riscv_multi_subset_supports_ext): Likewise.

gas/ChangeLog:

* testsuite/gas/riscv/zvkg.d: New test.
* testsuite/gas/riscv/zvkg.s: New test.

include/ChangeLog:

* opcode/riscv-opc.h (MATCH_VGHSH_VV): New.
(MASK_VGHSH_VV): New.
(MATCH_VGMUL_VV): New.
(MASK_VGMUL_VV): New.
(DECLARE_INSN): New.
* opcode/riscv.h (enum riscv_insn_class): Add instruction class
support for Zvkg.

opcodes/ChangeLog:

* riscv-opc.c: Add Zvkg instructions.

Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add support for the Zvbc extension

Zvbc is part of the crypto vector extensions.

This extension adds the following instructions:
- vclmul.[vv,vx]
- vclmulh.[vv,vx]

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
class support for Zvbc.
(riscv_multi_subset_supports_ext): Likewise.

gas/ChangeLog:

* testsuite/gas/riscv/zvbc.d: New test.
* testsuite/gas/riscv/zvbc.s: New test.

include/ChangeLog:

* opcode/riscv-opc.h (MATCH_VCLMUL_VV): New.
(MASK_VCLMUL_VV): New.
(MATCH_VCLMUL_VX): New.
(MASK_VCLMUL_VX): New.
(MATCH_VCLMULH_VV): New.
(MASK_VCLMULH_VV): New.
(MATCH_VCLMULH_VX): New.
(MASK_VCLMULH_VX): New.
(DECLARE_INSN): New.
* opcode/riscv.h (enum riscv_insn_class): Add instruction class
  support for Zvbc.

opcodes/ChangeLog:

* riscv-opc.c: Add Zvbc instruction.

Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

RISC-V: Add support for the Zvbb ISA extension

Zvbb is part of the vector crypto extensions.

This extension adds the following instructions:
- vandn.[vv,vx]
- vbrev.v
- vbrev8.v
- vrev8.v
- vclz.v
- vctz.v
- vcpop.v
- vrol.[vv,vx]
- vror.[vv,vx,vi]
- vwsll.[vv,vx,vi]

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
class support for Zvbb.
(riscv_multi_subset_supports_ext): Likewise.

gas/ChangeLog:

* config/tc-riscv.c (validate_riscv_insn): Add 'l' as new format
string directive.
(riscv_ip): Likewise.
* testsuite/gas/riscv/zvbb.d: New test.
* testsuite/gas/riscv/zvbb.s: New test.

include/ChangeLog:

* opcode/riscv-opc.h (MATCH_VANDN_VV): New.
(MASK_VANDN_VV): New.
(MATCH_VANDN_VX): New.
(MASK_VANDN_VX): New.
(MATCH_VBREV8_V): New.
(MASK_VBREV8_V): New.
(MATCH_VBREV_V): New.
(MASK_VBREV_V): New.
(MATCH_VCLZ_V): New.
(MASK_VCLZ_V): New.
(MATCH_VCPOP_V): New.
(MASK_VCPOP_V): New.
(MATCH_VCTZ_V): New.
(MASK_VCTZ_V): New.
(MATCH_VREV8_V): New.
(MASK_VREV8_V): New.
(MATCH_VROL_VV): New.
(MASK_VROL_VV): New.
(MATCH_VROL_VX): New.
(MASK_VROL_VX): New.
(MATCH_VROR_VI): New.
(MASK_VROR_VI): New.
(MATCH_VROR_VV): New.
(MASK_VROR_VV): New.
(MATCH_VROR_VX): New.
(MASK_VROR_VX): New.
(MATCH_VWSLL_VI): New.
(MASK_VWSLL_VI): New.
(MATCH_VWSLL_VV): New.
(MASK_VWSLL_VV): New.
(MATCH_VWSLL_VX): New.
(MASK_VWSLL_VX): New.
(DECLARE_INSN): New.
* opcode/riscv.h (EXTRACT_RVV_VI_UIMM6): New.
(ENCODE_RVV_VI_UIMM6): New.
(enum riscv_insn_class): Add instruction class for Zvbb.

opcodes/ChangeLog:

* riscv-dis.c (print_insn_args): Add 'l' as new format string
directive.
* riscv-opc.c: Add Zvbb instructions.

Signed-off-by: Nathan Huckleberry <nhuck@google.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

Automatic date update in version.in

Fix regressions caused by agent expression C++-ification

Simon pointed out that my agent expression C++-ification patches
caused a regression with the native-gdbserver target board.  The bug
is that append_const is supposed to write in big-endian order, but I
switched this by mistake.

binutils: NEWS: announce new RISC-V extensions

We picked up support for a few new extensions over the last weeks
(this may need further updating prior to the next release), list them
in the NEWS file.

binutils/ChangeLog:

* binutils/NEWS: announce suuport for the new RISC-V
          extensions (Zicond, Zfa, XVentanaCondOps).

Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>

RISC-V: Add support for the Zfa extension

This patch adds support for the RISC-V Zfa extension,
which introduces additional floating-point instructions:
* fli (load-immediate) with pre-defined immediates
* fminm/fmaxm (like fmin/fmax but with different NaN behaviour)
* fround/froundmx (round to integer)
* fcvtmod.w.d (Modular Convert-to-Integer)
* fmv* to access high bits of FP registers in case XLEN < FLEN
* fleq/fltq (quiet comparison instructions)

Zfa defines its instructions in combination with the following
extensions:
* single-precision floating-point (F)
* double-precision floating-point (D)
* quad-precision floating-point (Q)
* half-precision floating-point (Zfh)

This patch is based on an earlier version from Tsukasa OI:
  https://sourceware.org/pipermail/binutils/2022-September/122939.html
Most significant change to that commit is the switch from the rs1-field
value to the actual floating-point value in the last operand of the fli*
instructions. Everything that strtof() can parse is accepted and
the '%a' printf specifier is used to output hex floating-point literals
in the disassembly.

The Zfa specification is frozen (and has passed public review).  It is
available as a chapter in "The RISC-V Instruction Set Manual: Volume 1":
  https://github.com/riscv/riscv-isa-manual/releases

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Add instruction
class support for 'Zfa' extension.
(riscv_multi_subset_supports_ext): Likewise.
(riscv_implicit_subsets): Add 'Zfa' -> 'F' dependency.

gas/ChangeLog:

* config/tc-riscv.c (flt_lookup): New helper to lookup a float value
in an array.
(validate_riscv_insn): Add 'Wfv' as new format string directive.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Add floating-point chapter and describe
limiations of the Zfa FP literal parsing.
* testsuite/gas/riscv/zfa-32.d: New test.
* testsuite/gas/riscv/zfa-32.s: New test.
* testsuite/gas/riscv/zfa-64.d: New test.
* testsuite/gas/riscv/zfa-64.s: New test.
* testsuite/gas/riscv/zfa-fail.d: New test.
* testsuite/gas/riscv/zfa-fail.l: New test.
* testsuite/gas/riscv/zfa-fail.s: New test.
* testsuite/gas/riscv/zfa.d: New test.
* testsuite/gas/riscv/zfa.s: New test.
* testsuite/gas/riscv/zfa.s: New test.

* opcode/riscv-opc.h (MATCH_FLI_H): New.
(MASK_FLI_H): New.
(MATCH_FMINM_H): New.
(MASK_FMINM_H): New.
(MATCH_FMAXM_H): New.
(MASK_FMAXM_H): New.
(MATCH_FROUND_H): New.
(MASK_FROUND_H): New.
(MATCH_FROUNDNX_H): New.
(MASK_FROUNDNX_H): New.
(MATCH_FLTQ_H): New.
(MASK_FLTQ_H): New.
(MATCH_FLEQ_H): New.
(MASK_FLEQ_H): New.
(MATCH_FLI_S): New.
(MASK_FLI_S): New.
(MATCH_FMINM_S): New.
(MASK_FMINM_S): New.
(MATCH_FMAXM_S): New.
(MASK_FMAXM_S): New.
(MATCH_FROUND_S): New.
(MASK_FROUND_S): New.
(MATCH_FROUNDNX_S): New.
(MASK_FROUNDNX_S): New.
(MATCH_FLTQ_S): New.
(MASK_FLTQ_S): New.
(MATCH_FLEQ_S): New.
(MASK_FLEQ_S): New.
(MATCH_FLI_D): New.
(MASK_FLI_D): New.
(MATCH_FMINM_D): New.
(MASK_FMINM_D): New.
(MATCH_FMAXM_D): New.
(MASK_FMAXM_D): New.
(MATCH_FROUND_D): New.
(MASK_FROUND_D): New.
(MATCH_FROUNDNX_D): New.
(MASK_FROUNDNX_D): New.
(MATCH_FLTQ_D): New.
(MASK_FLTQ_D): New.
(MATCH_FLEQ_D): New.
(MASK_FLEQ_D): New.
(MATCH_FLI_Q): New.
(MASK_FLI_Q): New.
(MATCH_FMINM_Q): New.
(MASK_FMINM_Q): New.
(MATCH_FMAXM_Q): New.
(MASK_FMAXM_Q): New.
(MATCH_FROUND_Q): New.
(MASK_FROUND_Q): New.
(MATCH_FROUNDNX_Q): New.
(MASK_FROUNDNX_Q): New.
(MATCH_FLTQ_Q): New.
(MASK_FLTQ_Q): New.
(MATCH_FLEQ_Q): New.
(MASK_FLEQ_Q): New.
(MATCH_FCVTMOD_W_D): New.
(MASK_FCVTMOD_W_D): New.
(MATCH_FMVH_X_D): New.
(MASK_FMVH_X_D): New.
(MATCH_FMVH_X_Q): New.
(MASK_FMVH_X_Q): New.
(MATCH_FMVP_D_X): New.
(MASK_FMVP_D_X): New.
(MATCH_FMVP_Q_X): New.
(MASK_FMVP_Q_X): New.
(DECLARE_INSN): New.
* opcode/riscv.h (enum riscv_insn_class): Add instruction
classes for the Zfa extension.

opcodes/ChangeLog:

* riscv-dis.c (print_insn_args): Add support for
new format string directive 'Wfv'.
* riscv-opc.c: Add Zfa instructions.

Co-Developed-by: Tsukasa OI <research_trasio@irq.a4lg.com>
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
Co-Developed-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
Acked-by: Palmer Dabbelt <palmer@rivosinc.com>

strings: Improve code to detect excessively large minimum string lengths.

  PR 30598
  * strings.c (set_string_min): New function. (main): Use it. (print_unicode_stream): Calculate buffer size using a size_t.

Prevent an illegal memory access when running the strings program with an excessively lerge minimum string length.

  PR 30595
  * strings.c (main): Check for an excessively large minimum string length.

Fix used-before-initialized warnings when compiling elf.c with Clang-16.

LoongArch: gas: Fix code style issues

  Blocks of 8 spaces be replaced with tabs.
  Fix alignment issues.

LoongArch: gas: Add LVZ and LBT instructions support

gas/ChangeLog:
* config/tc-loongarch.c (md_parse_option): Add LARCH_opts.ase_lvz and
LARCH_opts.ase_lbt.
* testsuite/gas/loongarch/uleb128.d: Regenerated.
* testsuite/gas/loongarch/lvz-lbt.d: New test.
* testsuite/gas/loongarch/lvz-lbt.s: New test.

include/ChangeLog:
* opcode/loongarch.h (ase_lvz): New.
(ase_lbt): New.

opcodes/ChangeLog:
* loongarch-dis.c (set_default_loongarch_dis_options): Add
LARCH_opts.ase_lvz and LARCH_opts.ase_lbt.
* loongarch-opc.c (struct loongarch_ase): Add LVZ and LBT instructions.

LoongArch: Deprecate $v[01], $fv[01] and $x names per spec

As outlined in the LoongArch ELF psABI spec [1], it is actually already
2 versions after the initial LoongArch support, and the $v[01] and
$fv[01] names should really get sunset by now.

In addition, the "$x" name for $r21 was never included in any released
version of the ABI spec, and such usages are all fixed to say just $r21
for every project I could think of that accepted a LoongArch port.

Plus, the upcoming LSX/LASX support makes use of registers named
"$vrNN" and "$xrNN", so having "$vN" and "$x" alongside would almost
certainly create confusion for developers.

Issue warnings for such usages per the deprecation procedure detailed
in the spec, so we can finally remove support in the next release cycle
after this.

[1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html

gas/ChangeLog:

* config/tc-loongarch.c: Init canonical register ABI name
mappings and deprecated register names.
(loongarch_args_parser_can_match_arg_helper): Warn in case of
deprecated register name usage.
* testsuite/gas/loongarch/deprecated_reg_aliases.d: New test.
* testsuite/gas/loongarch/deprecated_reg_aliases.l: Likewise.
* testsuite/gas/loongarch/deprecated_reg_aliases.s: Likewise.

include/ChangeLog:

* opcode/loongarch.h: Rename global variables.

opcodes/ChangeLog:

* loongarch-opc.c: Rename the alternate/deprecated register name
mappings, and move $x to the deprecated name map.

Signed-off-by: WANG Xuerui <git@xen0n.name>

opcodes/loongarch: print unrecognized insn words with the .word directive

For better round-trip fidelity and readability in general.

gas/ChangeLog:

* testsuite/gas/loongarch/uleb128.d: Update test case.
* testsuite/gas/loongarch/raw-insn.d: New test.
* testsuite/gas/loongarch/raw-insn.s: Likewise.

opcodes/ChangeLog:

* loongarch-dis.c (disassemble_one): Print ".word" if !opc.

Signed-off-by: WANG Xuerui <git@xen0n.name>

opcodes/loongarch: do not print hex notation for signed immediates

The additional hex notation was minimally useful when one had to
inspect code with heavy bit manipulation, or of unclear signedness, but
it clutters the output, and the style is not regular assembly language
syntax either.

Precisely how one approaches the original use case is not taken care of
in this patch (maybe we want a disassembler option forcing a certain
style for immediates, like for example printing every immediate in
decimal or hexadecimal notation), but at least let's stop the current
practice.

ChangeLog:

* testsuite/gas/loongarch/imm_ins.d: Update test case.
* testsuite/gas/loongarch/imm_ins_32.d: Likewise.
* testsuite/gas/loongarch/imm_op.d: Likewise.
* testsuite/gas/loongarch/jmp_op.d: Likewise.
* testsuite/gas/loongarch/load_store_op.d: Likewise.
* testsuite/gas/loongarch/macro_op.d: Likewise.
* testsuite/gas/loongarch/macro_op_32.d: Likewise.
* testsuite/gas/loongarch/privilege_op.d: Likewise.
* testsuite/gas/loongarch/uleb128.d: Likewise.
* testsuite/gas/loongarch/vector.d: Likewise.

ld/ChangeLog:

* testsuite/ld-loongarch-elf/jmp_op.d: Update test case.
* testsuite/ld-loongarch-elf/macro_op.d: Likewise.
* testsuite/ld-loongarch-elf/macro_op_32.d: Likewise.

opcodes/ChangeLog:

* loongarch-dis.c (dis_one_arg): Remove the "(0x%x)" part from
disassembly output of signed immediate operands.

Signed-off-by: WANG Xuerui <git@xen0n.name>

opcodes/loongarch: style disassembled address offsets as such

Add a modifier char 'o' telling the disassembler to print the immediate
using the address offset style, and mark the memory access instructions'
offset operands as such.

opcodes/ChangeLog:

* loongarch-dis.c (dis_one_arg): Style disassembled address
offsets as such when the operand has a modifier char 'o'.
* loongarch-opc.c: Add 'o' to operands that represent address
offsets.

Signed-off-by: WANG Xuerui <git@xen0n.name>

opcodes/loongarch: implement style support in the disassembler

Update the LoongArch disassembler to supply style information to the
disassembler output. The output formatting remains unchanged.

opcodes/ChangeLog:

* disassemble.c: Mark LoongArch as created_styled_output=true.
* loongarch-dis.c (dis_one_arg): Use fprintf_styled_func
throughout with proper styles.

Signed-off-by: WANG Xuerui <git@xen0n.name>

opcodes/loongarch: remove unused code

Remove some unused declarations and code.

include/ChangeLog:

* opcode/loongarch.h: Remove unused declarations.

opcodes/ChangeLog:

* loongarch-dis.c (loongarch_parse_dis_options): Remove.
(my_print_address_func): Likewise.
(loongarch_disassemble_one): Likewise.

Signed-off-by: WANG Xuerui <git@xen0n.name>

LoongArch: support disassembling certain pseudo-instructions

Add a flag in the pinfo field for being able to mark certain specialized
matchers as disassembler-only, so some degree of isolation between
assembler-side and disassembler-side can be achieved.

This isolation is necessary, firstly because some pseudo-instructions
cannot be fully described in the opcode table, like `li.[wd]`, so the
corresponding opcode entry cannot have meaningful match/mask values.
Secondly, some of these pseudo-instructions can be realized in more than
one plausible ways; e.g. `li.w rd, <something between 0 and 0x7ff>` can
be realized on LA64 with any of `addi.w`, `addi.d` or `ori`. If we tie
disassembly of such aliases with the corresponding GAS support, only one
canonical form among the above would be recognized as `li.w`, and it
would mildly impact the readability of disassembly output.
People wanting the exact disassembly can always set `-M no-aliases` to
get the original behavior back.

In addition, in certain cases, information is irreversibly lost after
assembling, so perfect round-trip would not be possible in such cases.
For example, `li.w` and `li.d` of immediates within int32_t range
produce the same code; in this patch, `addi.d rd, $zero, imm` is treated
as `li.d`, while `addi.w` and `ori` immediate loads are shown as `li.w`,
due to the expressible value range well within 32 bits.

gas/ChangeLog:

* config/tc-loongarch.c (get_loongarch_opcode): Ignore
disassembler-only aliases.
* testsuite/gas/loongarch/64_pcrel.d: Update test case.
* testsuite/gas/loongarch/imm_ins.d: Likewise.
* testsuite/gas/loongarch/imm_ins_32.d: Likewise.
* testsuite/gas/loongarch/jmp_op.d: Likewise.
* testsuite/gas/loongarch/li.d: Likewise.
* testsuite/gas/loongarch/macro_op.d: Likewise.
* testsuite/gas/loongarch/macro_op_32.d: Likewise.
* testsuite/gas/loongarch/macro_op_large_abs.d: Likewise.
* testsuite/gas/loongarch/macro_op_large_pc.d: Likewise.
* testsuite/gas/loongarch/nop.d: Likewise.
* testsuite/gas/loongarch/relax_align.d: Likewise.
* testsuite/gas/loongarch/reloc.d: Likewise.

include/ChangeLog:

* opcode/loongarch.h (INSN_DIS_ALIAS): Add.

ld/ChangeLog:

* testsuite/ld-loongarch-elf/jmp_op.d: Update test case.
* testsuite/ld-loongarch-elf/macro_op.d: Likewise.
* testsuite/ld-loongarch-elf/macro_op_32.d: Likewise.
* testsuite/ld-loongarch-elf/relax-align.dd: Likewise.

opcodes/ChangeLog:

* loongarch-dis.c: Move register name map declarations to top.
(get_loongarch_opcode_by_binfmt): Consider aliases when
disassembling without the no-aliases option.
(parse_loongarch_dis_option): Support the no-aliases option.
* loongarch-opc.c: Collect pseudo instructions into a new
dedicated table.

Signed-off-by: WANG Xuerui <git@xen0n.name>

Automatic date update in version.in

binutils/NEWS: announce SFrame version 2 as the new default

doc: sframe: update specification for SFRAME_VERSION_2

Add details for the changes made from Version 1 to Version 2 of the format.

Also add details about alignment in the SFrame format.  A portion of the
SFrame stack trace format has an unaligned on-disk representation.  Add
description at relevant points in the specificatin to clarify the
alignment related details.

sframe: bfd: gas: ld: format bump to SFrame version 2

SFrame version 2 encodes the size of repetitive insn block explicitly
in the format.  Add information in the SFrame FDE to convey the size
of the block of repeating instructions.  This information is used only
for SFrame FDEs of type SFRAME_FDE_TYPE_PCMASK.

Introduce two extra bytes for padding: this ensures that the memory
accesses to the members of the SFrame Frame Descriptor Entry (FDE) are
naturally aligned.

gas generates SFrame section with version SFRAME_VERSION_2 by default.

libsframe provides two new APIs to:
  - get an SFrame FDE data from the decoder context, and
  - add an SFrame FDE to the encoder context.
The additional argument (for rep_block_size) is useful for SFrame FDEs
where FDE type is SFRAME_FDE_TYPE_PCMASK.

The linker will generate the output SFrame sections in the
SFRAME_VERSION_2 format.  If the input sections offered to the linker
are not all in the SFRAME_VERSION_2 format, the linker issues an error
to the user.

objdump/readelf will show the following message to the user if .sframe
section in SFRAME_VERSION_1 format is seen:

 "No further information can be displayed.  SFrame version not
 supported."

In other words, like the rest of the binutils, only the current SFrame
format version, i.e., SFRAME_VERSION_2 is supported by the textual dump
facilities.

bfd/
* elf-sframe.c (_bfd_elf_merge_section_sframe): Generate an
output SFrame section with version SFRAME_VERSION_2.  Also,
error out if the SFrame sections do not all have
SFRAME_VERSION_2.
* elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Generate SFrame
section for plt entries with version SFRAME_VERSION_2.
gas/
* gen-sframe.c (sframe_set_version): Update to SFRAME_VERSION_2.
(output_sframe): Likewise.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe-aarch64-1.d: Use SFRAME_VERSION_2.
* gas/cfi-sframe/cfi-sframe-aarch64-2.d: Likewise.
* gas/cfi-sframe/cfi-sframe-aarch64-pac-ab-key-1.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-1.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-2.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-3.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-4.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-5.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-6.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-7.d: Likewise.
* gas/cfi-sframe/cfi-sframe-common-8.d: Likewise.
* gas/cfi-sframe/cfi-sframe-x86_64-1.d: Likewise.
* gas/cfi-sframe/common-empty-1.d: Likewise.
* gas/cfi-sframe/common-empty-2.d: Likewise.
* gas/cfi-sframe/common-empty-3.d: Likewise.
ld/testsuite/
* ld-aarch64/sframe-simple-1.d: Adjust for SFRAME_VERSION_2.
* ld-x86-64/sframe-plt-1.d: Likewise.
* ld-x86-64/sframe-simple-1.d: Likewise.
libsframe/
* libsframe.ver: Add the new APIs.
* sframe.c (sframe_decoder_get_funcdesc_v2): New definition.
(sframe_encoder_add_funcdesc_v2): Likewise.
(sframe_header_sanity_check_p): Include SFRAME_VERSION_2.
(sframe_fre_check_range_p): Get rep_block_size info from SFrame
FDE.
* sframe-dump.c (dump_sframe_header): Add support for
SFRAME_VERSION_2.
(dump_sframe): Inform user if SFrame section in SFRAME_VERSION_1
format is seen.
libsframe/testsuite/
* libsframe.decode/DATA-BE: Regenerated data file.
* libsframe.decode/DATA1: Likewise.
* libsframe.decode/DATA2: Likewise.
* libsframe.find/plt-findfre-1.c: Use new API in the testcase.
include/
* sframe.h: Add member to encode size of the code block of
repeating instructions.  Add 2 bytes of padding.
* sframe-api.h (sframe_decoder_get_funcdesc_v2): New
declaration.
(sframe_encoder_add_funcdesc_v2): Likewise.

libsframe: add new APIs to get SFrame version

While the SFrame preamble is guaranteed to not change between versions,
providing these access APIs from the SFrame decoder and encoder APIs is
for convenience only.  The linker may want to use these APIs as the
format evolves.

include/
* sframe-api.h (sframe_decoder_get_version): New declaration.
(sframe_encoder_get_version): Likewise.

libsframe/
* libsframe/libsframe.ver: Add new APIs.
* libsframe/sframe.c (sframe_decoder_get_version): New
definition.
(sframe_encoder_get_version): Likewise.

libsframe: fix sframe_find_fre for pltN entries

For a toy application on x86_64, for example, following is the SFrame
stack trace information for the 3 pltN entries of 16 bytes each:

   func idx [1]: pc = 0x401030, size = 48 bytes
   STARTPC[m]      CFA       FP        RA
   0000000000000000  sp+8      u         u
   000000000000000b  sp+16     u         u

The data in first column is the start_ip_offset.  Also note that the FDE
is of type SFRAME_FDE_TYPE_PCMASK (denoted by the [m] on LHS).

Where each pltN (note: excluding plt0 entry) entry looks like:

  401030: jmp    *0x2fca(%rip)
  401036: push   $0x0
  40103b: jmp    401020<_init+0x20>

  401040: jmp    *0x2fc2(%rip)
  401046: push   $0x1
  40104b: jmp    401020<_init+0x20>

  401050: jmp    *0x2fba(%rip)
  401056: push   $0x2
  40105b: jmp    401020<_init+0x20>

Now, to find SFrame stack trace information from an FDE of type
SFRAME_FDE_TYPE_PCMASK, sframe_find_fre () was doing an operation
like,
  (start_ip_offset & 0xf) >= (pc & 0xf)

This works for pltN entry of size, say, less than 16 bytes.  But if the
pltN entries or similar code stubs (for which SFrame FDE of type
SFRAME_FDE_TYPE_PCMASK may be used), evolve to be of size > 16 bytes,
this will cease to work.

To match the range covered by the SFrame FRE, one should instead perform
a modulo operation.  The constant for the modulo operation must be the
size of the pltN entry.  Further, this constant should ideally be
encoded in the format, as it may be different for each ABI.

In SFrame Version 2 of the format, we will move towards encoding it
explicitly in the SFrame FDE.  For now, fix up the logic to at least
move towards modulo operation.

libsframe/
* sframe.c (sframe_fre_check_range_p): New definition.
(sframe_find_fre): Refactor a bit and use the new definition
above.
include/
* sframe.h (SFRAME_FDE_TYPE_PCMASK): Update comment.
libsframe/doc/
* sframe-spec.texi: Fix the text for SFRAME_FDE_TYPE_PCMASK FDE
type.

ld: Add -z nosectionheader test to bootstrap.exp

PR ld/25617
* testsuite/ld-bootstrap/bootstrap.exp: Add -z nosectionheader
test.

ld: Add tests for -z nosectionheader and --strip-section-headers

Add tests to verify that the linker option, -z nosectionheader and
objcopy and strip option, --strip-section-headers, work correctly as well
as linker issues an error when dynamic symbol table from PT_DYNAMIC
segment is used.

PR ld/25617
* testsuite/ld-elf/hash-2.d: New file.
* testsuite/ld-elf/no-section-header.exp: Likewise.
* testsuite/ld-elf/pr25617-1-no-sec-hdr.nd: Likewise.
* testsuite/ld-elf/pr25617-1-no-sec-hdr.rd: Likewise.
* testsuite/ld-elf/pr25617-1-static-no-sec-hdr.rd: Likewise.
* testsuite/ld-elf/pr25617-1a-no-sec-hdr.nd: Likewise.
* testsuite/ld-elf/pr25617-1a-no-sec-hdr.rd: Likewise.
* testsuite/ld-elf/pr25617-1a-sec-hdr.rd: Likewise.
* testsuite/ld-elf/pr25617-1a.c: Likewise.
* testsuite/ld-elf/pr25617-1b.c: Likewise.
* testsuite/ld-elf/start-noheader.rd: Likewise.
* testsuite/ld-elf/start-shared-noheader-gnu.rd: Likewise.
* testsuite/ld-elf/start-shared-noheader-sysv.rd: Likewise.
* testsuite/ld-elf/start-shared-noheader.nd: Likewise.

binutils: Add a --strip-section-headers test

PR ld/25617
* testsuite/binutils-all/objcopy.exp: Run strip-section-headers-1.
* testsuite/binutils-all/strip-section-headers-1.d: New file.

ld: Add simple tests for -z nosectionheader

2020-06-06  Kaylee Blake  <klkblake@gmail.com>
    H.J. Lu  <hongjiu.lu@intel.com>

PR ld/25617
* testsuite/ld-elf/nosectionheader-1.d: New file.
* testsuite/ld-elf/nosectionheader-2.d: Likewise.

bfd: Improve nm and objdump without section header

When there is no section header in an executable or shared library, we
reconstruct dynamic symbol table from the PT_DYNAMIC segment, which
contains DT_HASH/DT_GNU_HASH/DT_MIPS_XHASH, DT_STRTAB, DT_SYMTAB,
DT_STRSZ, and DT_SYMENT entries, to improve nm and objdump.  For DT_HASH,
the number of dynamic symbol table entries equals the number of chains.
For DT_GNU_HASH/DT_MIPS_XHASH, only defined symbols with non-STB_LOCAL
indings are in hash table.  Since DT_GNU_HASH/DT_MIPS_XHASH place all
symbols with STB_LOCAL binding before symbols with other bindings and
all undefined symbols defined ones in dynamic symbol table, the highest
symbol index in DT_GNU_HASH/DT_MIPS_XHASH is the highest dynamic symbol
table index.  We can also get symbol version from DT_VERSYM, DT_VERDEF
and DT_VERNEED entries.

dt_symtab, dt_versym, dt_verdef, dt_verneed, dt_symtab_count,
dt_verdef_count, dt_verneed_count and dt_strtab are added to
elf_obj_tdata to store dynamic symbol table information.

PR ld/25617
* elf-bfd.h (elf_obj_tdata): Add dt_symtab, dt_verdef, dt_verneed,
dt_symtab_count, dt_verdef_count, dt_verneed_count and dt_strtab.
(elf_use_dt_symtab_p): New.
(_bfd_elf_get_dynamic_symbols): Likewise.
(_bfd_elf_get_section_from_dynamic_symbol): Likewise.
* elf.c (bfd_elf_get_elf_syms): Use dynamic symbol table if
neeeded.
(_bfd_elf_get_dynamic_symtab_upper_bound): Likewise.
(_bfd_elf_slurp_version_tables): Likewise.
(offset_from_vma): New function.
(get_hash_table_data): Likewise.
(_bfd_elf_get_dynamic_symbols): Likewise.
(_bfd_elf_get_section_from_dynamic_symbol): Likewise.
(_bfd_elf_get_symbol_version_name): Likewise.
* elfcode.h (elf_object_p): Call _bfd_elf_get_dynamic_symbols
to reconstruct dynamic symbol table from PT_DYNAMIC segment if
there is no section header.
(elf_slurp_symbol_table): Use dynamic symbol table if neeeded.
Don't free isymbuf when dynamic symbol table is used.
* elflink.c (elf_link_is_defined_archive_symbol): Return wrong
format error when dynamic symbol table is used.
(elf_link_add_object_symbols): Likewise.

ELF: Discard non-alloc sections without section header

Discard non-alloc sections when section headers are stripped.

bfd/

PR ld/25617
* elf.c (_bfd_elf_assign_file_positions_for_non_load): Skip
non-load sections without section header.
(_bfd_elf_write_object_contents): Don't set the sh_name field
without section header.  Write out the .shstrtab section only
if its sh_offset field isn't -1.

binutils/

PR ld/25617
* objcopy.c (is_strip_section_1): Remove non-alloc sections for
--strip-section-headers.

ld/

PR ld/25617
* ldlang.c (lang_discard_section_p): Discard non-alloc sections
if we are stripping section headers.

ELF: Strip section header in ELF objects

Section header isn't mandatory on ELF executable nor shared library.
This patch adds a new linker option, -z nosectionheader, to omit ELF
section header, a new objcopy and strip option, --strip-section-headers,
to remove ELF section headers.

bfd/

2023-06-06  H.J. Lu  <hongjiu.lu@intel.com>
    Kaylee Blake  <klkblake@gmail.com>

PR ld/25617
* bfd.c (BFD_NO_SECTION_HEADER): New.
(BFD_FLAGS_SAVED): Add BFD_NO_SECTION_HEADER.
(BFD_FLAGS_FOR_BFD_USE_MASK): Likewise.
* elfcode.h (elf_swap_ehdr_out): Omit section header with
BFD_NO_SECTION_HEADER.
(elf_write_shdrs_and_ehdr): Likewise.
* elfxx-target.h (TARGET_BIG_SYM): Add BFD_NO_SECTION_HEADER
to object_flags.
(TARGET_LITTLE_SYM): Likewise.
* bfd-in2.h: Regenerated.

binutils/

2023-06-06  H.J. Lu  <hongjiu.lu@intel.com>

PR ld/25617
* NEWS: Mention --strip-section-headers for objcopy and strip.
* objcopy.c (strip_section_headers): New.
(command_line_switch): Add OPTION_STRIP_SECTION_HEADERS.
(strip_options): Add --strip-section-headers.
(copy_options): Likewise.
(copy_usage): Add --strip-section-headers.
(strip_usage): Likewise.
(copy_object): Handle --strip-section-headers for ELF files.
(strip_main): Handle OPTION_STRIP_SECTION_HEADERS.
(copy_main): Likewise.
* doc/binutils.texi: Document --strip-section-headers for objcopy
and strip.

ld/

2023-06-06  H.J. Lu  <hongjiu.lu@intel.com>
    Kaylee Blake  <klkblake@gmail.com>

PR ld/25617
* NEWS: Mention -z nosectionheader.
* emultempl/elf.em: Support -z sectionheader and
-z nosectionheader.
* ld.h (ld_config_type): Add no_section_header.
* ld.texi: Document -z sectionheader and -z nosectionheader.
* ldlang.c (ldlang_open_output): Handle
config.no_section_header.
* lexsup.c (parse_args): Enable --strip-all with
-z nosectionheader.  Disallow -r with -z nosectionheader.
(elf_static_list_options): Add -z sectionheader and
-z nosectionheader.

Ignore --prefix-file-map compiler option whist running testsuite.

ignore lto-wrapper warnings for lto builds.

  I see these warnings from time to time, when configuring a build with  --enable-pgo-build=lto, I haven't yet found out why I see these sometime, and  why not. E.g. https://gcc.gnu.org/PR109241. Just ignore these when they appear  in test cases. lto-wrapper: warning: using serial compilation of N LTRANS jobs