x86: Warn .insn instruction with length > 15 bytes

Change .insn instruction with length > 15 bytes from error to warning.

PR gas/31323
* config/tc-i386.c (output_insn): Issue a warning when .insn
instruction length exceeds the limit of 15 bytes.
* testsuite/gas/i386/oversized64.s: Add a test for .insn
* testsuite/gas/i386/oversized64.l: Updated.

gdb: LoongArch: Implement the get_syscall_number gdbarch method

In the current code, the feature 'catch syscall' is not supported
on LoongArch, implement the "get_syscall_number" gdbarch method to
get the system call number from the register a7.

Without this patch:

(gdb) catch syscall
The feature 'catch syscall' is not supported on this architecture yet.

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

gdb: LoongArch: Add LBT extension support

Loongson Binary Translation (LBT) is used to accelerate binary
translation, which contains 4 scratch registers (scr0 to scr3),
x86/ARM eflags (eflags) and x87 fpu stack pointer (ftop). This
patch support gdb to fetch/store these registers.

Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn> # Framework
Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> # Detail Optimizes
Signed-off-by: Hui Li <lihui@loongson.cn> # Error Fixes
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

gdb: LoongArch: Add vector extensions support

Add LoongArch's vector extensions support, which including
128bit LSX (i.e., Loongson SIMD eXtension) and 256bit LASX
(i.e., Loongson Advanced SIMD eXtension). This patch support
gdb to fetch/store vector registers.

Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

Link x86-64 mark-plt-1.so with --no-as-needed

Fixes
FAIL: Build mark-plt-1.so
where gcc is built with default --as-needed.

* testsuite/ld-x86-64/x86-64.exp (Build mark-plt-1.so): Pass
--no-as-needed.

Automatic date update in version.in

gdb: rename target_so_ops to solib_ops

I don't like the name `target_so_ops`, because:

 - The name `target` is so overloaded, and in this case it's not even
   related to target_ops or anything else called "target".
 - We do have an implementation that actually fetches solibs from the
   target (solib_target_so_op in solib-target.c), so it's confusing for
   the "base class" to be called target_something as well.

Rename to solib_ops.

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

gdb: rename struct shobj -> struct solib

`struct so_list` was recently renamed to `struct shobj` (in 3fe0dfd1604f
("gdb: rename struct so_list to shobj")).  In hindsight, `solib` would
have been a better name.  We have solib.c, the implementations in
solib-*.c, many functions with solib in their name, the solib_loaded /
solib_unloaded observables, etc.

Rename shobj to solib.

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

Remove remnants of partial DIEs from DWARF reader

When rewriting the DWARF scanner, I forgot to remove
dwarf2_cu::load_all_dies and dwarf2_cu::partial_dies.  This patch
corrects the oversight and fixes up a couple other spots that mention
partial DIEs, which no longer exist.

Approved-By: Tom de Vries <tdevries@suse.de>

Avoid an allocation in attr_to_dynamic_prop

I noticed that attr_to_dynamic_prop allocates a dwarf_block, when no
allocation is required.  This patch stack-allocates the object
instead.

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

Fix disabling of year 2038 support on 32-bit hosts by default

Commit e5f2f7d901ee ("Disable year 2038 support on 32-bit hosts by
default") fixed a mismatch between 64-bit time_t in GDB and system headers
and 32-bit time_t in BFD.

However, since commit 862776f26a59 ("Finalized intl-update patches")
gnulib's year 2038 support has been accidentally re-enabled — causing
problems for 32-bit hosts again.  The commit split baseargs into
{h,b}baseargs, but this hasn't been done for the code that handles
--disable-year2038.

This patch restores the intended behaviour.  With this change, the number
of unexpected core files goes from 18 to 4.

Tested on armv8l-linux-gnueabihf.

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

Handling of arrays with optimized-out bounds

In Ada, sometimes the compiler must emit array bounds by referencing
an artificial variable that's created for this purpose.  However, with
optimization enabled, these variables can be optimized away.

Currently this can result in displays like:

    (gdb) print mumble
    $1 = (warning: unable to get bounds of array, assuming null array
    )

This patch changes this to report that the array is optimized-out,
instead, which is closer to the truth, and more generally useful.  For
example, Python pretty-printers can now recognize this situation.

In order to accomplish this, I introduced a new PROP_OPTIMIZED_OUT
enumerator and changed one place to use it.  Reusing the "unknown"
state wouldn't work properly, because in C it is normal for array
bounds to be unknown.

[gdb/tdep] Fix use-after-free in arm_exidx_fill_cache

On arm-linux the linaro CI occasionally reports:
...
 (gdb) up 10
 #4  0x0001b864 in pthread_join ()
 (gdb) FAIL: gdb.threads/staticthreads.exp: up 10
...
while this is expected:
...
 (gdb) up 10
 #3  0x00010568 in main (argc=1, argv=0xfffeede4) at staticthreads.c:76
 76          pthread_join (thread, NULL);
 (gdb) PASS: gdb.threads/staticthreads.exp: up 10
...

Thiago investigated the problem, and using valgrind found an invalid read in
arm_exidx_fill_cache.

The problem happens as follows:
- an objfile and corresponding per_bfd are allocated
- some memory is allocated in arm_exidx_new_objfile using
  objfile->objfile_obstack, for the "exception table entry cache".
- a symbol reread is triggered, and the objfile, including the
  objfile_obstack, is destroyed
- a new objfile is allocated, using the same per_bfd
- again arm_exidx_new_objfile is called, but since the same per_bfd is used,
  it doesn't allocate any new memory for the "exception table entry cache".
- the "exception table entry cache" is accessed by arm_exidx_fill_cache,
  and we have a use-after-free.

This is a regression since commit a2726d4ff80 ("[ARM] Store exception handling
information per-bfd instead of per-objfile"), which changed the "exception
table entry cache" from per-objfile to per-bfd, but failed to update the
obstack_alloc.

Fix this by using objfile->per_bfd->storage_obstack instead of
objfile->objfile_obstack.

I couldn't reproduce the FAIL myself, but Thiago confirmed that the patch
fixes it.

Tested on arm-linux.

Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/31254
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31254

Automatic date update in version.in

Use reference result of emplace_back

Starting with C++17, emplace_back returns a reference to the new
object.  This patch changes code that uses emplace_back followed by a
call to back() to simply use this reference instead.

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

LoongArch: gas: Fix the types of symbols referred with %le_*_r in the symtab

When a symbol is referred with %le_{hi20,lo12,add}_r, it's definitely a
TLS symbol and we should set its type to TLS in the symtab.  Otherwise
when building Perl with gcc-14 -flto, we get:

/usr/bin/ld: PL_current_context: TLS definition in
./miniperl.ltrans0.ltrans.o section .tbss mismatches non-TLS reference
in ./miniperl.ltrans1.ltrans.o

A minimal reproducer:

    $ cat t1.s
    .section .tbss
    .globl x
    x: .word 0
    $ cat t2.s
    f:
      lu12i.w $a0, %le_hi20_r(x)
      add.d   $a0, $a0, $tp, %le_add_r(x)
      li.w    $a1, 1
      st.w    $a1, $a0, %le_lo12_r(x)
    $ gas/as-new t1.s -o t1.o
    $ gas/as-new t2.s -o t2.o
    $ ld/ld-new t1.o t2.o
    ld/ld-new: x: TLS definition in t1.o section .tbss mismatches
    non-TLS reference in t2.o

Unfortunately this was undetected before Binutils-2.42 release because
GCC < 14 does not use %le_*_r, and without LTO it's very rare to have a
TLS LE definition and its reference in two different translation units.
So this fix should be backported to Binutils-2.42 branch too.

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

Automatic date update in version.in

Automatic date update in version.in

gdb: attach to a process when the executable has been deleted

Bug PR gdb/28313 describes attaching to a process when the executable
has been deleted.  The bug is for S390 and describes how a user sees a
message 'PC not saved'.

On x86-64 (GNU/Linux) I don't see a 'PC not saved' message, but
instead I see this:

  (gdb) attach 901877
  Attaching to process 901877
  No executable file now.
  warning: Could not load vsyscall page because no executable was specified
  0x00007fa9d9c121e7 in ?? ()
  (gdb) bt
  #0  0x00007fa9d9c121e7 in ?? ()
  #1  0x00007fa9d9c1211e in ?? ()
  #2  0x0000000000000007 in ?? ()
  #3  0x000000002dc8b18d in ?? ()
  #4  0x0000000000000000 in ?? ()
  (gdb)

Notice that the addresses in the backtrace don't seem right, quickly
heading to 0x7 and finally ending at 0x0.

What's going on, in both the s390 case and the x86-64 case is that the
architecture's prologue scanner is going wrong and causing the stack
unwinding to fail.

The prologue scanner goes wrong because GDB has no unwind information.

And GDB has no unwind information because, of course, the executable
has been deleted.

Notice in the example session above we get this line in the output:

  No executable file now.

which indicates that GDB failed to find an executable to debug.

For GNU/Linux when GDB tries to find an executable for a given pid we
end up calling linux_proc_pid_to_exec_file in gdb/nat/linux-procfs.c.
Within this function we call `readlink` on /proc/PID/exe to find the
path of the actual executable.

If the `readlink` call fails then we already fallback on using
/proc/PID/exe as the path to the executable to debug.

However, when the executable has been deleted the `readlink` call
doesn't fail, but the path that is returned points to a non-existent
file.

I propose that we add an `access` call to linux_proc_pid_to_exec_file
to check that the target file exists and can be read.  If the target
can't be read then we should fall back to /proc/PID/exe (assuming that
/proc/PID/exe can be read).

Now on x86-64 the output looks like this:

  (gdb) attach 901877
  Attaching to process 901877
  Reading symbols from /proc/901877/exe...
  Reading symbols from /lib64/libc.so.6...
  (No debugging symbols found in /lib64/libc.so.6)
  Reading symbols from /lib64/ld-linux-x86-64.so.2...
  (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
  0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6
  (gdb) bt
  #0  0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6
  #1  0x00007fa9d9c1211e in sleep () from /lib64/libc.so.6
  #2  0x000000000040117e in spin_forever () at attach-test.c:17
  #3  0x0000000000401198 in main () at attach-test.c:24
  (gdb)

which is much better.

I've also tagged the bug PR gdb/29782 which concerns the test
gdb.server/connect-with-no-symbol-file.exp.  After making this change,
when running gdb.server/connect-with-no-symbol-file.exp GDB would now
pick up the /proc/PID/exe file as the executable in some cases.

As GDB is not restarted for the multiple iterations of this test
GDB (or rather BFD) would given a warning/error like:

  (gdb) PASS: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: setup: disconnect
  set sysroot target:
  BFD: reopening /proc/3283001/exe: No such file or directory
  (gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: setup: adjust sysroot

What's happening is that an executable found for an earlier iteration
of the test is still registered for the inferior when we are setting
up for a second iteration of the test.  When the sysroot changes, if
there's an executable registered GDB tries to reopen it, but in this
case the file has disappeared (the previous inferior has exited by
this point).

I did think about maybe, when the executable is /proc/PID/exe, we
should auto-delete the file from the inferior.  But in the end I
thought this was a bad idea.  Not only would this require a lot of
special code in GDB just to support this edge case: we'd need to track
if the exe file name came from /proc and should be auto-deleted, or
we'd need target specific code to check if a path should be
auto-deleted.....

... in addition, we'd still want to warn the user when we auto-deleted
the file from the inferior, otherwise they might be surprised to find
their inferior suddenly has no executable attached, so we wouldn't
actually reduce the number of warnings the user sees.

So in the end I figured that the best solution is to just update the
test to avoid the warning.  This is easily done by manually removing
the executable from the inferior once each iteration of the test has
completed.

Now, in bug PR gdb/29782 GDB is clearly managing to pick up an
executable from the NFS cache somehow.  I guess what's happening is
that when the original file is deleted /proc/PID/exe is actually
pointing to a file in the NFS cache which is only deleted at some
later point, and so when GDB starts up we do manage to associate a
file with the inferior, this results in the same message being emitted
from BFD as I was seeing.  The fix included in this commit should also
fix that bug.

One final note:  On x86-64 GNU/Linux, the
gdb.server/connect-with-no-symbol-file.exp test will produce 2 core
files.  This is due to a bug in gdbserver that is nothing to do with
this test.  These core files are created before and after this
commit.  I am working on a fix for the gdbserver issue, but will post
that separately.

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

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

x86: Disallow instructions with length > 15 bytes

It is a hard error when an instruction length exceeds the limit of 15
bytes:

[hjl@gnu-cfl-3 tmp]$ cat x.s
.text
xacquire lock addq $0x11223344, %fs:(,%eax)
[hjl@gnu-cfl-3 tmp]$ gcc -c x.s
x.s: Assembler messages:
x.s:2: Warning: instruction length of 16 bytes exceeds the limit of 15
[hjl@gnu-cfl-3 tmp]$ objdump -dw x.o

x.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <.text>:
   0: 64 67 f2 f0 48 81 04 05 00 00 00 00 44 33 22  xacquire lock (bad)
   f: 11                    .byte 0x11
[hjl@gnu-cfl-3 tmp]$

and

[hjl@gnu-cfl-3 tmp]$ cat z.s
addq $0xe0, %fs:0, %rdx
[hjl@gnu-cfl-3 tmp]$ as -o z.o z.s
z.s: Assembler messages:
z.s:1: Warning: instruction length of 16 bytes exceeds the limit of 15
[hjl@gnu-cfl-3 tmp]$ objdump -dw z.o

z.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <.text>:
   0: 64 62 f4 ec 18 81 04 25 00 00 00 00 e0 00 00  (bad)
...
[hjl@gnu-cfl-3 pr31323]$

Instructions with length > 15 bytes are always invalid.  It is quite easy
to generate invalid instructions with AVX now.  We should issue an error
when instruction length exceeds the limit of 15 bytes.

PR gas/31323
* config/tc-i386.c (output_insn): Issue an error when instruction
length exceeds the limit of 15 bytes.
* testsuite/gas/i386/oversized16.l: Updated.
* testsuite/gas/i386/oversized64.l: Likewise.
* testsuite/gas/i386/x86-64-apx-inval.l: New file.
* testsuite/gas/i386/x86-64-apx-inval.s: Likewise.

gdb, testsuite, fortran: Fix sizeof intrinsic for Fortran pointers

For Fortran pointers gfortran/ifx emits DW_TAG_pointer_types like

<2><17d>: Abbrev Number: 22 (DW_TAG_variable)
   <180>   DW_AT_name        : (indirect string, offset: 0x1f1): fptr
   <184>   DW_AT_type        : <0x214>
...
<1><219>: Abbrev Number: 27 (DW_TAG_array_type)
   <21a>   DW_AT_type        : <0x10e>
   <216>   DW_AT_associated  : ...

The 'pointer property' in Fortran is implicitly modeled by adding a
DW_AT_associated to the type of the variable (see also the
DW_AT_associated description in DWARF 5).  A Fortran pointer is more
than an address and thus different from a C pointer.  It is a
self contained type having additional fields such as, e.g., the rank of
its underlying array.  This motivates the intended DWARF modeling of
Fortran pointers via the DW_AT_associated attribute.

This patch adds support for the sizeof intrinsic by simply dereferencing
pointer types when encountered during a sizeof evaluation.

The patch also adds a test for the sizeof intrinsic which was not tested
before.

Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb, types: Resolve pointer types dynamically

This commit allows pointers to be dynamic types (on the outmost
level).  Similar to references, a pointer is considered a dynamic type
if its target type is a dynamic type and it is on the outmost level.
Also this commit removes the redundant code inside function
"value_check_printable" for handling of DW_AT_associated type.

The pointer resolution follows the one of references.

This change generally makes the GDB output more verbose.  We are able to
print more details about a pointer's target like the dimension of an array.

In Fortran, if we have a pointer to a dynamic type

  type buffer
    real, dimension(:), pointer :: ptr
  end type buffer
  type(buffer), pointer :: buffer_ptr
  allocate (buffer_ptr)
  allocate (buffer_ptr%ptr (5))

which then gets allocated, we now resolve the dynamic type before
printing the pointer's type:

Before:

  (gdb) ptype buffer_ptr
  type = PTR TO -> ( Type buffer
    real(kind=4) :: alpha(:)
  End Type buffer )

After:

  (gdb) ptype buffer_ptr
  type = PTR TO -> ( Type buffer
    real(kind=4) :: alpha(5)
  End Type buffer )

Similarly in C++ we can dynamically resolve e.g. pointers to arrays:

  int len = 3;
  int arr[len];
  int (*ptr)[len];
  int ptr = &arr;

Once the pointer is assigned one gets:

Before:

  (gdb) p ptr
  $1 = (int (*)[variable length]) 0x123456
  (gdb) ptype ptr
  type = int (*)[variable length]

After:

  (gdb) p ptr
  $1 = (int (*)[3]) 0x123456
  (gdb) ptype ptr
  type = int (*)[3]

For more examples see the modified/added test cases.

Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb/testsuite: Fix indentation issues in gdb.dwarf2/dynarr-ptr.exp

Improve indentation in the test file by replacing 10 spaces at second level
with 4 spaces.  This helps to update the test using the right indentation
in future.

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

x86: move Q-suffix-to-REX.W translation logic

By pulling it ahead of the SHORT_MNEM_SUFFIX case label we can drop a
part of another conditional there. While moving, also drop a pointless
check: With QWORD_MNEM_SUFFIX, register operands of XCHG necessarily
have both been 64-bit ones.

x86: actually implement .noopt

For quite some time we've had support for -O command line options. With
that ignoring at least .noopt isn't really a good idea.

Re-purpose the optimize-3 test for testing this directive's effect as
well.

As to the doc addition - this uses the same text as is there for the
{nooptimize} pseudo-prefix, despite me not being convinced of the "size"
part being fully accurate there (and hence also here).

MAINTAINERS: Update my e-mail address.

Automatic date update in version.in

gas: x86: ginsn: adjust ginsns for certain lea ops

A review comment on the SCFI V4 series was to handle ginsn creation for
certain lea opcodes more precisely.

Specifically, we should preferably handle the following two cases of lea
opcodes similarly:
  - #1 lea with "index register and scale factor of 1, but no base
    register",
  - #2 lea with "no index register, but base register present".

Currently, a ginsn of type GINSN_TYPE_OTHER is generated for the
case of #1 above.  For #2, however, the lea insn is translated to either
a GINSN_TYPE_ADD or GINSN_TYPE_MOV depending on whether the immediate
for displacement is non-zero or not respectively.

Change the handling in x86_ginsn_lea so that both of the above lea
manifestations are handled similarly.

While at it, remove the code paths creating GINSN_TYPE_OTHER altogether
from the function.  It makes sense to piggy back on the
x86_ginsn_unhandled code path to create GINSN_TYPE_OTHER if the
destination register is interesting.  This was also suggested in one of
the previous review rounds;  the other functions already follow that
model, so this keeps functions symmetrical looking.

gas/
* gas/config/tc-i386.c (x86_ginsn_lea): Handle select lea ops with
no base register similar to the case of no index register.  Remove
creation of GINSN_TYPE_OTHER from the function.

gas/testsuite/
* gas/scfi/x86_64/ginsn-lea-1.l: New test.
* gas/scfi/x86_64/ginsn-lea-1.s: Likewise.
* gas/scfi/x86_64/scfi-x86-64.exp: Add new test.

gprofng: Remove unused macros

gprofng/ChangeLog
2024-02-01  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* common/gp-experiment.h: Remove SP_REMOTE_PROTOCOL_VERSION.
* common/hwctable.c: Remove DBG_LT* macros.
* libcollector/envmgmt.c: Likewise.
* libcollector/hwprofile.c: Likewise.
* libcollector/iolib.c: Likewise.
* libcollector/jprofile.c: Likewise.
* libcollector/memmgr.c: Likewise.
* libcollector/profile.c: Likewise.
* libcollector/tsd.c: Likewise.
* libcollector/unwind.c: Likewise.

Fix "objstack" typo

I noticed some comments that mentions "objstack".  The type is
actually "obstack".  This patch fixes the typos.

Rename SEARCH_ALL

The constant SEARCH_ALL conflicts with a define in a Windows header.
This patch renames the constant to SEARCH_ALL_DOMAINS to avoid the
conflict.

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

gdb/testsuite: fix some duplicate test names in gdb.trace/

This commit fixes some of the easier duplicate test names in the
gdb.trace/ directory.

All of these duplicates are resolved by either given tests a name, or
by extended the existing name to make it more descriptive.

There should be no change in what is tested after this commit.

gdb/testsuite: fix duplicate test names in gdb.base/cond-eval-mode.exp

Fix some duplicate test names in gdb.base/cond-eval-mode.exp when
running with native-gdbserver or native-extended-gdbserver board
files.

I've just added some 'with_test_prefix' blocks to make the test names
unique, there should be no change in what is tested after this commit.

Fix AIX build break.

A recent commit broke AIX build. The thread_local type defined functions
were being considered a weak symbol and hence while creating the binary these
symbols were not visible.

This patch is a fix for the same.

Automatic date update in version.in

gdb: remove some unnecessary frame_info_ptr resets

This code was probably needed before we had reinflatable
frame_info_ptrs, it's not necessary anymore.

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

Mention support for AMD/znver5 in GAS

PR31124: Addendum: Remove PROVIDE of __flmap_init_label, __flmap.

Supply these symbols as computed by the linker scripts, even when there are weak definitions.
PR 31124
  * scripttempl/avr.sc (__flmap, __flmap_init_label): Remove PROVIDE.

Automatic date update in version.in

Really fix Windows gdbserver segment registers

My earlier attempt to mask the segment registers in gdbserver for
Windows introduced some bugs.  That patch is here:

https://sourceware.org/pipermail/gdb-patches/2023-December/205306.html

The problem turned out to be that these fields in the Windows
'CONTEXT' type are just 16 bits, so while masking the values on read
is fine, writing the truncated values back then causes zeros to be
written to some subsequent field.

This patch cleans this up by arranging never to write too much data to
a field.

I also noticed that two register numbers here were never updated for
the 64-bit port.  This patch fixes this as well, and renames the "FCS"
register to follow gdb.

Finally, this patch applies the same treatment to windows-nat.c.

Reviewed-by: John Baldwin <jhb@FreeBSD.org>

Automatic date update in version.in

PR31314, chew crashing on use of uninitialized value

The "drop" call in wrap_comment already increments pc.  Defining DOCDD
in proto.str is a warning fix.

PR 31314
* chew.c (wrap_comment): Don't increment pc.
* proto.str (DOCDD): Define.

sim: bpf: remove support for ldinddw and ldabsdw instructions

This patch removes support for the two instructions above from the GNU
simulator, including the corresponding tests.  These instructions do
not really exist in BPF and are not recognized as such by the kernel
verifier.  This has now been pointed out during the standardization of
the BPF ISA.

Signed-off-by: Jose E. Marchesi <jose.marchesi@oracle.com>

gdb: Use SYM_DOMAIN instead of DOMAIN when calling sym-domains.def

Since commit 6771fc6f1d9 "Use a .def file for domain_enum", the
sym-domains.def file has been introduced, and requires the user to
define the DOMAIN(x) macro.

On older systems (centos-7 with glibc-2.17 for example), this DOMAIN
macro conflicts with another macro defined in /usr/include/math.h.

Fix this conflict by changing sym-domains.def to use a macro named
SYM_DOMAIN instead of DOMAIN.

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

bfd: restore Threading menu entry in bfd.texi

I mistakenly vandalized bfd.texi in the commit
0c45feb159a14ca4cb50cfbf45eacaf5a6cecf2b by removing an entry in the
manual menu.  This commit reverts that thunk.

bpf: there is no ldinddw nor ldabsdw instructions

There are no legacy ldind nor ldabs BPF instructions with BPF_SIZE_DW.
For some reason we were (incorrectly) supporting these.  This patch
updates the opcodes so the instructions get removed and modifies the
GAS manual and testsuite accordingly.

See discussion at
https://lore.kernel.org/bpf/110aad7a-f8a3-46ed-9fda-2f8ee54dcb89@linux.dev

Tested in bpf-uknonwn-none target, x86-64-linux-gnu host.

include/ChangeLog:

2024-01-29  Jose E. Marchesi  <jose.marchesi@oracle.com>

* opcode/bpf.h (enum bpf_insn_id): Remove BPF_INSN_LDINDDW and
BPF_INSN_LDABSDW instructions.

opcodes/ChangeLog:

2024-01-29  Jose E. Marchesi  <jose.marchesi@oracle.com>

* bpf-opc.c (bpf_opcodes): Remove BPF_INSN_LDINDDW and
BPF_INSN_LDABSDW instructions.

gas/ChangeLog:

2024-01-29  Jose E. Marchesi  <jose.marchesi@oracle.com>

* doc/c-bpf.texi (BPF Instructions): There is no indirect 64-bit
load instruction.
(BPF Instructions): There is no absolute 64-bit load instruction.
* testsuite/gas/bpf/mem.s: Update test accordingly.
* testsuite/gas/bpf/mem-be-pseudoc.d: Likewise.
* testsuite/gas/bpf/mem-be.d: Likewise.
* testsuite/gas/bpf/mem-pseudoc.d: Likewise.
* testsuite/gas/bpf/mem-pseudoc.s: Likewise.
* testsuite/gas/bpf/mem.d: Likewise.
* testsuite/gas/bpf/mem.s: Likewise.

Update release making documentation after 2.42 release

Remove support for the beos file format

Fix backtrace limit stopping on inline frame

If you have set up a backtrace limit, and the backtrace stops
because of this in an inline frame with arguments, you get an
assertion failure:
```
(gdb) bt
(gdb) set backtrace limit 2
(gdb) bt
C:/src/repos/binutils-gdb.git/gdb/frame.c:3346: internal-error: reinflate: Assertion `m_cached_level >= -1' failed.
```

And if this one is fixed, there is another one as well:
```
(gdb) bt
C:/src/repos/binutils-gdb.git/gdb/dwarf2/loc.c:1160: internal-error: dwarf_expr_reg_to_entry_parameter: Assertion `frame != NULL' failed.
```

The reason for both of them is this kind of loop:
```
  while (get_frame_type (frame) == INLINE_FRAME)
    frame = get_prev_frame (frame);
```
Since get_prev_frame respects the backtrace limit, it will return
NULL, and from there on you can't continue.
This changes these loops to use get_prev_frame_always instead, so
you always get a non-inline frame in the end.

With this backtrace works:
```
(gdb) bt
(gdb)
```

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

Updated French translations for GOLD and LD

Automatic date update in version.in

Document new Python and Guile constants

This documents the new Python and Guile constants introduced earlier
in this series.

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

Refine search in cp_search_static_and_baseclasses

This changes cp_search_static_and_baseclasses to only search for
types, functions, and modules.  The latter two cases were discovered
by regression testing.  I found it somewhat surprising the Fortran
name lookup ends up in this code, but did not attempt to change this.

Only search for functions in rust_structop::evaluate_funcall

This changes rust_structop::evaluate_funcall to only search for
functions.

Only search types in lookup_typename

This changes lookup_typename to only look for types.  The check for
LOC_TYPEDEF can now also be removed, because only types will appear in
TYPE_DOMAIN.

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

Only search types in cp_lookup_rtti_type

This changes cp_lookup_rtti_type to only search for types -- not
functions or variables.  Due to the symbol-matching hack, this could
just use SEARCH_TYPE_DOMAIN, but I think it's better to be clear; also
I hold on to some hope that perhaps the hack can someday be removed.

Use a function-domain search in inside_main_func

This changes inside_main_func to search only for functions.

Only look for functions in expand_symtabs_for_function

This changes expand_symtabs_for_function to only look in the function
domain.

Only search for "main" as a function

This changes find_main_name to restrict its search to the function
domain.

Simplify some symbol searches in linespec.c

This simplifies some symbol searches in linespec.c.  In particular,
two separate searches here can now be combined into one, due to the
new use of flags.

Arguably the STRUCT_DOMAIN searches should perhaps not even be done.
Only C really has these, and C doesn't have member functions.
However, it seems relatively harmless -- and clearly compatible -- to
leave this in.

Simplify some symbol searches in Ada code

This changes some of the Ada code to simplify symbol searches.  For
example, if a function is being looked for, the search is narrowed to
use SEARCH_FUNCTION_DOMAIN rather than SEARCH_VFT.  In one spot, a
search of the "struct" domain is removed, because Ada does not have a
tag domain.

Use the new symbol domains

This patch changes the DWARF reader to use the new symbol domains.  It
also adjusts many bits of associated code to adapt to this change.

The non-DWARF readers are updated on a best-effort basis.  This is
somewhat simpler since most of them only support C and C++.  I have no
way to test a few of these.

I went back and forth a few times on how to handle the "tag"
situation.  The basic problem is that C has a special namespace for
tags, which is separate from the type namespace.  Other languages
don't do this.  So, the question is, should a DW_TAG_structure_type
end up in the tag domain, or the type domain, or should it be
language-dependent?

I settled on making it language-dependent using a thought experiment.
Suppose there was a Rust compiler that only emitted nameless
DW_TAG_structure_type objects, and specified all structure type names
using DW_TAG_typedef.  This DWARF would be correct, in that it
faithfully represents the source language -- but would not work with a
purely struct-domain implementation in gdb.  Therefore gdb would be
wrong.

Now, this approach is a little tricky for C++, which uses tags but
also enters a typedef for them.  I notice that some other readers --
like stabsread -- actually emit a typedef symbol as well.  And, I
think this is a reasonable approach.  It uses more memory, but it
makes the internals simpler.  However, DWARF never did this for
whatever reason, and so in the interest of keeping the series slightly
shorter, I've left some C++-specific hacks in place here.

Note that this patch includes language_minimal as a language that uses
tags.  I did this to avoid regressing gdb.dwarf2/debug-names-tu.exp,
which doesn't specify the language for a type unit.  Arguably this
test case is wrong.

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

Remove old symbol_matches_domain

Nothing calls the variant of symbol_matches_domain that accepts a
domain_enum for searching, so this patch removes it and the
corresponding symbol::matches.

Remove some obsolete Python constants

The Python code has exported some constants, but they are no longer
documented, and were never useful.  This patch removes them.

Use domain_search_flags in lookup_symbol et al

This changes lookup_symbol and associated APIs to accept
domain_search_flags rather than a domain_enum.

Note that this introduces some new constants to Python and Guile.  I
chose to break out the documentation patch for this, because the
internals here do not change until a later patch, and it seemed
simpler to patch the docs just once, rather than twice.

Use domain_search_flags in lookup_global_symbol_language

This changes quick_symbol_functions::lookup_global_symbol_language to
accept domain_search_flags rather than just a domain_enum, and fixes
up the fallout.

To avoid introducing any regressions, any code passing VAR_DOMAIN now
uses SEARCH_VFT.

That is, no visible changes should result from this patch.  However,
it sets the stage to refine some searches later on.

Introduce "scripting" domains

The Python and Guile code exposed the internal domain constants both
as attributes of symbols and as values to pass to lookup functions.

Now, perfect backward compatibility here can't be achieved: some
symbols are going to have domain changes by the end of this series.
However, it seemed to me that we can preserve lookups using the basic
domain values.

This patch implements this by exporting the "or"-able search constants
with an extra bit set.  Then it introduces some functions to convert
such constants to domain_search_flags.  This will be used by the
Python and Guile code, so that both old- and new-style lookups will
work properly; and while preserving the idea that the domain constants
can be compared to a symbol's domain.

Remove a check of VAR_DOMAIN

completion_list_add_symbol checks that the returned symbol has
VAR_DOMAIN, but also checks that its address class is LOC_BLOCK.  The
domain check is redundant -- only functions can possibly be LOC_BLOCK
-- and leaving this in place will cause a regression when combined
with a later patch in this series.  This patch preemptively removes
the redundant check.

Replace search_domain with domain_search_flags

This patch changes gdb to replace search_domain with
domain_search_flags everywhere.  search_domain is removed.

Add domain_search_flags

This adds a new flag enum type, domain_search_flags, which is the flag
version of domain_enum.  Nothing uses this yet, but the goal here is
to have all symbol searches and lookups use these flags.  The new
names are chosen to exactly parallel domain_enum.

Add two new symbol domains

This adds two new symbol domain constants, TYPE_DOMAIN and
FUNCTION_DOMAIN.

Historically, gdb was a C debugger, and the symbol tables continue to
reflect this.  In particular, symbol domains match the C language,
with VAR_DOMAIN including variables, functions, and types.

However, other languages have other approaches to namespacing.  And,
in any case, it is often useful for other parts of gdb to be able to
distinguish between some domains at lookup time, without resorting to
examining a symbol's location -- in some situations, this sort of
filtering happens too late.

Nothing uses these new domains yet, but the idea behind the patch is
to separate symbols into more domains and then let the
language-specific parts of gdb implement their semantics in terms of
these categories.

Use a .def file for domain_enum

Future patches will change and reuse the names from domain_enum.  This
patch makes this less error-prone by having a single point to define
these names, using the typical gdb ".def" file.

Split up a big 'if' in symtab.c

global_symbol_searcher::add_matching_symbols in symtab.c has a
gigantic 'if' statement -- 33 lines of conditional expression.  This
patch splits it up into a series of separate 'if's.

Simplify symbol_to_info_string

Thi simplifies symbol_to_info_string, removing the 'kind' parameter
and instead having it use the symbol's domain.

Remove NR_DOMAINS

NR_DOMAINS is only used for a static assert, but we no longer need it
now.  If we add too many constants to this enum, GCC will warn about
the bitfield overflow:

    error: ‘symbol::m_domain’ is too small to hold all values of ‘enum domain_enum’

Give names to unspecified types

A patch later in this series will change check_typedef to also look in
the type domain.  This change by itself caused a regression, but one
that revealed some peculiar behavior.

The regression is in nullptr_t.exp, where examining a std::nullptr_t
will change from the correct:

    typedef decltype(nullptr) std::nullptr_t;

to

    typedef void std::nullptr_t;

Right now, the DWARF reader marks all unspecified types as stub types.
However, this interacts weirdly with check_typedef, which currently
does not try to resolve types -- only struct-domain objects.

My first attempt here was to fix this by changing void types not to be
stub types, as I didn't see what value that provided.  However, this
caused another regression, because call_function_by_hand_dummy checks
for stub-ness:

  if (values_type == NULL || values_type->is_stub ())
    values_type = default_return_type;

I'm not really sure why it does this rather than check for
TYPE_CODE_VOID.

While looking into this, I found another oddity: the DWARF reader
correctly creates a type named 'decltype(nullptr)' when it seems a
DW_TAG_unspecified_type -- but it creates a symbol named "void"
instead.

This patch changes the DWARF reader to give the symbol the correct
name.  This avoids the regression.

Fix latent bug in mdebugread.c

mdebugread.c makes a label symbol but puts it into VAR_DOMAIN.  I
think LABEL_DOMAIN is more appropriate.

I don't have a way to test this.

Make nsalias.exp more reliable

nsalias.exp tries to detect a complaint that is issued when expanding
a CU.  However, the test is a bit funny in that, while gdb does
currently expand the CU and issue the complaint, it also emits this
error:

    No symbol "N100" in current context.

This series will change gdb such that this CU is not expanded -- which
makes sense, the symbol in question doesn't actually match the lookups
that are done.

So, to make the test more robust, a direct request to expand symtabs
is done instead.

Fix latent bug in DW_TAG_entry_point handling

A DW_TAG_entry_point symbol inherits its extern/static property from
the enclosing subroutine.  This is encoded in new_symbol -- but the
cooked indexer does not agree.

Small cleanup in DWARF reader

I noticed a couple of spots in dwarf/read.c:new_symbol that call
add_symbol_to_list.  However, this function is generally written to
set list_to_add, and then have a single call to add_symbol_to_list at
the end.  This patch cleans up this discrepancy.

Note that new_symbol is overlong and should probably be split up.

Fix bug in cooked index scanner

Testing this entire series pointed out that the cooked index scanner
disagrees with new_symbol about certain symbols.  In particular,
new_symbol has this comment:

    Ada and Fortran subprograms, whether marked external or
    not, are always stored as a global symbol, because we want

This patch updates the scanner to match.

I don't know why the current code does not cause failures.

It's maybe worth noting that incremental CU expansion -- creating
symtabs directly from the index -- would eliminate this sort of bug.

Automatic date update in version.in

Automatic date update in version.in

gas: scfi: untraceable control flow should be a hard error

PR gas/31284

Currently, if an indirect jump is seen, GCFG (a CFG of ginsns) cannot be
created, and the SCFI machinery bails out with a warning:
  "Warning: Untraceable control flow for func 'foo'; Skipping SCFI"

It is, however, better suited if this is a hard error.  Change it to a
hard error.  Also change the message to skip mentioning "SCFI", because
the error itself may also useful when ginsns are used for other passes
(distinct from SCFI) involving GCFG, like a pass to detect if there is
unreachable code.  Hence, simply say:
  "Error: untraceable control flow for func 'foo'"

gas/
PR gas/31284
* ginsn.c (ginsn_data_end): Use as_bad instead of as_warn.

gas/testsuite/
PR gas/31284
* gas/scfi/x86_64/ginsn-cofi-1.l: Adjust to the expected output
in case of errors.
* gas/scfi/x86_64/scfi-unsupported-cfg-1.l: Error not Warning.

x86: testsuite: scfi: adjust COFI testcase

The testcase for change of flow instructions in its current shape is not
doing much: it checks that SCFI issues an appropriate warning.  The same
warning is covered by another testcase (scfi-unsupported-cfg-1); It is
better to test the ginsn translation instead, for these 'change of flow
instructions'.

gas/testsuite/
* gas/scfi/x86_64/scfi-cofi-1.s: Moved to...
* gas/scfi/x86_64/ginsn-cofi-1.s: ...here.
* gas/scfi/x86_64/scfi-x86-64.exp: Adjust tests.
* gas/scfi/x86_64/scfi-cofi-1.d: Removed.
* gas/scfi/x86_64/scfi-cofi-1.l: Removed.
* gas/scfi/x86_64/ginsn-cofi-1.l: New test.

elf: Rename is_standard_elf to uses_elf_em

Rename is_standard_elf to uses_elf_em for targets which use elf.em.

binutils/

PR ld/31289
* testsuite/lib/binutils-common.exp (is_standard_elf): Renamed
to ...
(uses_elf_em): This.

ld/

PR ld/31289
* testsuite/ld-elf/fatal-warnings-2a.d: Replace is_standard_elf
with uses_elf_em.
* testsuite/ld-elf/fatal-warnings-2b.d: Likewise.
* testsuite/ld-elf/fatal-warnings-3a.d: Likewise.
* testsuite/ld-elf/fatal-warnings-3b.d: Likewise.
* testsuite/ld-elf/fatal-warnings-4a.d: Likewise.
* testsuite/ld-elf/fatal-warnings-4b.d: Likewise.

aarch64: move SHA512 instructions to +sha3

SHA512 instructions were added to the architecture at the same time as SHA3
instructions, but later than the SHA1 and SHA256 instructions.  Furthermore,
implementations must support either both or neither of the SHA512 and SHA3
instruction sets.  However, SHA512 instructions were originally (and
incorrectly) added to Binutils under the +sha2 flag.

This patch moves SHA512 instructions under the +sha3 flag, which matches the
architecture constraints and existing GCC and LLVM behaviour.

Fix: Stripping Rust static libraries fails because of overly zealous illegal path check

  PR 31250
  * objcopy.c (copy_archive): Improve the handling of archives that contain elements with invalid pathnames.

Remove -pie from command line of fatal-warnings 1a and 1b tests.

x86/APX: TILE{RELEASE,ZERO} have no EVEX encodings

Re-using the entire VEX decode hierarchy for the respective major opcode
has led to those two also being decoded as-if valid. Follow the earlier
USE_X86_64_EVEX_{PFX,W}_TABLE approach to avoid this happening.

x86/APX: no need to have decode go through x86_64_table[]

As suggested during review already, all such entries have their first
slot as Bad_Opcode, so by adding two more enumerators we can avoid doing
that decode step altogether.

x86: make "-msyntax=intel -mnaked-reg" match ".intel_syntax noprefix"

Adjustments made for the directive (by set_intel_syntax()) need also
making for the command line option. Break out respective code into a new
helper function, to also be invoked during command line processing.
Further also set register_prefix when processing -mnaked-reg.

x86/APX: optimize MOVBE

With identical source and destination it can be covered by the NDD-to-
legacy conversion logic as well, even if in this case the original insn
doesn't use an NDD encoding. The size savings are even better here, for
the replacement (BSWAP) not having a ModR/M byte.

LoongArch: Fix a bug of getting relocation type

The old code works because R_LARCH_RELAX has no symbol index. It causes
'(rel + 1)->r_info == R_LARCH_RELAX' is 1 and ELFNN_R_TYPE (1) is 1.

LoongArch: gas: Add support for s9 register

In LoongArch ABI, r22 register can be used as frame pointer or
static register(s9).

Link: https://github.com/loongson/la-abi-specs/blob/release/lapcs.adoc#general-purpose-registers

LoongArch: ld: Add support for TLS LE symbol with addend

Add support for TLS LE symbol with addend, such as:
  lu12i.w $t0, %le_hi20(a + 0x8)
  ori   $t0, $t0, %le_lo12(a + 0x8)

Assertion failure dumping .eh_frame_hdr

dwarf.c can hit "Assertion '(start) <= (end)' failed" on truncated
sections, due to get_encoded_eh_value wrongly returning a full count
for truncated words.

* dwarf.c (get_encoded_eh_value): Return zero for truncated words.

Automatic date update in version.in

gdb: remove get_gdb_program_name

Nothing uses it.

Change-Id: I7a3fbf38e290a5147fbcbf175bc34f01dfb335c7

elf: Add is_standard_elf

PR ld/31289 tests failed for fr30-elf, frv-elf, ft32-elf, iq2000-elf,
mn10200-elf, ms1-elf and msp430-elf targets:

FAIL: ld-elf/fatal-warnings-2a
FAIL: ld-elf/fatal-warnings-2b
FAIL: ld-elf/fatal-warnings-3a
FAIL: ld-elf/fatal-warnings-3b
FAIL: ld-elf/fatal-warnings-4a
FAIL: ld-elf/fatal-warnings-4b

even though PR ld/31289 targets xfail for [is_generic] targets.  These
targets not only don't use the generic_link_hash_table linker, but also
don't use the standard ELF emulation.  Add is_standard_elf for ELF
targets which use the standard ELF emulation and replace [is_generic]
with ![is_standard_elf] in PR ld/31289 tests.

binutils/

PR ld/31289
* testsuite/lib/binutils-common.exp (is_standard_elf): New.

ld/

PR ld/31289
* testsuite/lib/binutils-common.exp (is_generic): Return 1 for
fr30-*-*, frv-*-elf, ft32-*-*, iq2000-*-*, mn10200-*-*,
moxie-*-moxiebox*, msp430-*-* and mt-*-*.
* testsuite/ld-elf/fatal-warnings-2a.d: Replace [is_generic]
with ![is_standard_elf].
* testsuite/ld-elf/fatal-warnings-2b.d: Likewise.
* testsuite/ld-elf/fatal-warnings-3a.d: Likewise.
* testsuite/ld-elf/fatal-warnings-3b.d: Likewise.
* testsuite/ld-elf/fatal-warnings-4a.d: Likewise.
* testsuite/ld-elf/fatal-warnings-4b.d: Likewise.