Remove cli_out_new

cli_out_new is just a small wrapper around 'new'.  This patch removes
it, replacing it with uses of 'new' instead.

Replace input_interactive_p with a method

This replaces the global input_interactive_p function with a new
method ui::input_interactive_p.

Remove ui_register_input_event_handler

This patch removes ui_register_input_event_handler and
ui_unregister_input_event_handler, replacing them with methods on
'ui'.  It also changes gdb to use these methods everywhere, rather
than sometimes reaching in to the ui to manage the file descriptor
directly.

opcodes/arc: Implement style support in the disassembler

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

opcodes/ChangeLog:
* disassemble.c (disassemble_init_for_target): Set
created_styled_output for ARC based targets.
* arc-dis.c (find_format_from_table): Use fprintf_styled_ftype
instead of fprintf_ftype throughout.
(find_format): Likewise.
(print_flags): Likewise.
(print_insn_arc): Likewise.

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

arc: Update missing cipher.

The ciphers 5,7, and 9 are missing when parsing an assembly
instruction leading to errors when those ciphers are
used.

gas/config
* tc-arc.c (md_assembly): Update strspn string with the
          missing ciphers.

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

[gdb/testsuite] Remove duplicate of supports_gnuc

In commit 9d9dd861e98 ("[gdb/testsuite] Fix regression in
step-indirect-call-thunk.exp with gcc 7") I accidentally committed a duplicate
of supports_gnuc, which caused:
...
DUPLICATE: gdb.base/gdb-caching-proc.exp: supports_gnuc: consistency
...

Fix this by removing the duplicate.

Tested on x86_64-linux.

gdb/python: look for python, then python 3 at configure time

It is possible that a system might have a python3 executable, but no
python executable.  For example, on my Fedora system the python2
package provides /usr/bin/python2, the python3 package provides
/usr/bin/python3, and the python-unversioned-command package provides
/usr/bin/python, which picks between python2 and python3.

It is quite possible to only have python3 available on a system.

Currently, when GDB configures, it looks for a 'python' executable.
If non is found then GDB will be built without python support.  Or the
user needs to configure using --with-python=/usr/bin/python3.

This commit updates GDB's configure.ac script to first look for
'python', and then 'python3'.  Now, on a system that only has a
python3 executable, GDB will automatically find, and use that in order
to provide python support, no user supplied configure arguments are
needed.

I've tested this on my local machine by removing the
python-unversioned-command package, confirming that there is no longer
a 'python' executable in my $PATH, and then rebuilding GDB from
scratch.  GDB with this patch has python support.

x86: correct VMOVSH attributes

Both forms were missing VexW0 (thus allowing Evex.W=1 to be encoded by
suitable means, which would cause #UD). The memory operand form further
was using the wrong Masking value, thus allowing zeroing-masking to be
encoded for the store form (which would again cause #UD).

x86: re-order insn template fields

This saves quite a number of shift instructions: The "operands" field
can now be retrieved by just masking (no shift), and extracting the
"extension_opcode" field now only requires a (signed) right shift, with
no prereq left one. (Of course there may be architectures where, in a
cross build, there might be no difference at all, e.g. when there are
suitable bitfield extraction insns.)

[gdbsupport] Improve thread scheduling in parallel_for_each

When running a task using parallel_for_each, we get the following
distribution:
...
Parallel for: n_elements: 7271
Parallel for: minimum elements per thread: 10
Parallel for: elts_per_thread: 1817
Parallel for: elements on worker thread 0       : 1817
Parallel for: elements on worker thread 1       : 1817
Parallel for: elements on worker thread 2       : 1817
Parallel for: elements on worker thread 3       : 0
Parallel for: elements on main thread           : 1820
...

Note that there are 4 active threads, and scheduling elts_per_thread on each
of those handles 4 * 1817 == 7268, leaving 3 "left over" elements.

These leftovers are currently handled in the main thread.

That doesn't seem to matter much for this example, but for say 10 threads and
99 elements, you'd have 9 threads handling 9 elements and 1 thread handling 18
elements.

Instead, distribute the left over elements over the worker threads, such that
we have:
...
Parallel for: elements on worker thread 0       : 1818
Parallel for: elements on worker thread 1       : 1818
Parallel for: elements on worker thread 2       : 1818
Parallel for: elements on worker thread 3       : 0
Parallel for: elements on main thread           : 1817
...

Tested on x86_64-linux.

[gdb/testsuite] Allow override of ASAN_OPTIONS in lib/gdb.exp

Use set_sanitizer_default for ASAN_OPTIONS in lib/gdb.exp.

This allows us to override the default detect_leaks=0 setting, by manually
doing:
...
$ export ASAN_OPTIONS=detect_leaks=1
$ make check
...

Tested on x86_64-linux, by building with -fsanitize=address and running
test-case gdb.dwarf2/gdb-add-index.exp with and without
"export ASAN_OPTIONS=detect_leaks=1".

[gdb/testsuite] Fix regression in step-indirect-call-thunk.exp with gcc 7

Since commit 43127ae5714 ("Fix gdb.base/step-indirect-call-thunk.exp") I run
into:
...
gdb compile failed, gcc: error: unrecognized command line option \
  '-fcf-protection=none'; did you mean '-flto-partition=none'?
UNTESTED: gdb.base/step-indirect-call-thunk.exp: failed to prepare
...

The problem is that -fcf-protection is supported starting gcc 8, but I'm using
system gcc 7.5.0.

Fix this by only adding -fcf-protection=none for gcc 8 and later.

Tested on x86_64-linux, with gcc 7.5.0, 8.2.1 and 12.1.1.

[gdb/testsuite] Fix gdb.arch/i386-mpx.exp

Since commit c4a3dbaf113 ("Expose current 'print' settings to Python") we
have:
...
(gdb) print /x $bnd0 = {0x10, 0x20}^M
$22 = {lbound = 0x10, ubound = 0x20} : size 0x11^M
(gdb) FAIL: gdb.arch/i386-mpx.exp: verify size for bnd0
...

The regexp in the test-case expects "size 17".

Fix this by updating the regexp.

Tested on x86_64-linux.

[gdbsupport] Add parallel_for_each_debug

Add a parallel_for_each_debug variable, set to false by default.

With an a.out compiled from hello world, we get with
parallel_for_each_debug == true:
...
$ gdb -q -batch a.out -ex start
  ...
Parallel for: n_elements: 7271
Parallel for: minimum elements per thread: 10
Parallel for: elts_per_thread: 1817
Parallel for: elements on worker thread 0       : 1817
Parallel for: elements on worker thread 1       : 1817
Parallel for: elements on worker thread 2       : 1817
Parallel for: elements on worker thread 3       : 0
Parallel for: elements on main thread           : 1820

Temporary breakpoint 1, main () at /home/vries/hello.c:6
6         printf ("hello\n");
...

Tested on x86_64-linux.

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb-add-index always generates an error when libdebuginfod wasn't compiled in

gdb-add-index runs gdb with -iex 'set debuginfod enabled off'.  If gdb
is not compiled against libdebuginfod this causes an unnecessary error
message to be printed to stderr indicating that gdb was not built with
debuginfod support.

Fix this by changing the 'set debuginfod enabled off' command to a
no-op when gdb isn't built with libdebuginfod.

gdb/testsuite: modernize gdb.base/maint.exp

gdb.base/maint.exp was using several gdb_expect statements, probably
because this test case predates the existance of gdb_test_multiple. This
commit updates the test case to use gdb_test_multiple, making it more
resilient to internal errors and such.

The only gdb_expect left in the testcase is one that specifically looks
for an internal error being triggered as a PASS.

Add 'nibbles' to gdb.print_options

When I rebased and updated the print_options patch, I forgot to update
print_options to add the new 'nibbles' feature to the result.  This
patch fixes the oversight.  I'm checking this in.

PowerPC: Add support for IEEE 128-bit format.

The test gdb.base/infcall-nested-structs-c.exp fails on a gdb assert
in function ppc64_sysv_abi_return_value in file gdb/ppc-sysv-tdep.c.  The
assert is due to the missing IEEE 128-bit support in file
gdb/ppc-sysv-tdep.c.

The IBM long double was the initial float 128-bit support added by IBM
The IEEE 128-bit support, which is similar IBM long double support, was
made the default starting with GCC 12.  The floating point format
differences include the number of bits used to encode the exponent
and significand.  Also, IBM long double values are passed in a pair of
floating point registers.  The  IEEE 128-bit value is passed in a single
vector register.

This patch fixes the gdb_assert (ok); in function
ppc64_sysv_abi_return_value in gdb/ppc-sysv-tdep.c by adding IEEE FLOAT
128-bit type support for PowerPC.

The patch has been tested on Power 10, ELFv2.  It fixes the following list
of regression failures on Power 10:

gdb.base/infcall-nested-structs-c.exp      192
gdb.base/infcall-nested-structs-c++.exp     76
gdb.base/structs.exp                         9

The patch has been tested on Power 8 BE which is ELFv1.

Add 'summary' mode to Value.format_string

This adds a 'summary' mode to Value.format_string and to
gdb.print_options.  For the former, it lets Python code format values
using this mode.  For the latter, it lets a printer potentially detect
if it is being called in a backtrace with 'set print frame-arguments'
set to 'scalars'.

I considered adding a new mode here to let a pretty-printer see
whether it was being called in a 'backtrace' context at all, but I'm
not sure if this is really desirable.

Expose current 'print' settings to Python

PR python/17291 asks for access to the current print options.  While I
think this need is largely satisfied by the existence of
Value.format_string, it seemed to me that a bit more could be done.

First, while Value.format_string uses the user's settings, it does not
react to temporary settings such as "print/x".  This patch changes
this.

Second, there is no good way to examine the current settings (in
particular the temporary ones in effect for just a single "print").
This patch adds this as well.

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

PowerPC: fix for gdb.base/eh_return.exp

Disable the Traceback Table generation on PowerPC for this test.  The
Traceback Table consists of a series of bit fields to indicate things like
the Traceback Table version, language, and specific information about the
function.  The Traceback Table is generated following the end of the code
for every function by default.  The Traceback Table is defined in the
PowerPC ELF ABI and is intended to support debuggers and exception
handlers.  The Traceback Table is displayed in the disassembly of functions
by default and is part of the function length.  The table is typically
interpreted by the disassembler as data represented by .long xxx entries.

Generation of the Traceback Table is disabled in this test using the
PowerPC specific gcc compiler option -mtraceback=no, the xlc option
additional_flags-qtable=none and the clang optons
 -mllvm -xcoff-traceback-table=false.  Disabling the Traceback Table
generation in this test results in the gdb_test_multiple statement
correctly locating the address of the bclr instruction before the statement
"End of assembler dump." in the disassembly output.

Run 'black' on gdb

Running 'black' on gdb fixed a couple of small issues.  This patch is
the result.

Automatic date update in version.in

[gdb/symtab] Fix data race in cooked_index_functions::expand_symtabs_matching

When building gdb with -fsanitize-threads and running test-case
gdb.ada/char_enum_unicode.exp, I run into:
...
WARNING: ThreadSanitizer: data race (pid=21301)^M
  Write of size 8 at 0x7b2000008080 by main thread:^M
    #0 free <null> (libtsan.so.2+0x4c5e2)^M
    #1 _dl_close_worker <null> (ld-linux-x86-64.so.2+0x4b7b)^M
    #2 convert_between_encodings() charset.c:584^M
  ...
    #21 cooked_index_functions::expand_symtabs_matching() read.c:18606
...

This is fixed by making cooked_index_functions::expand_symtabs_matching wait
for the cooked index finalization to be done.

Tested on x86_64-linux.

https://sourceware.org/bugzilla/show_bug.cgi?id=29311
https://sourceware.org/bugzilla/show_bug.cgi?id=29286

[gdbsupport] Add sequential_for_each

Add a sequential_for_each alongside the parallel_for_each, which can be used
as a drop-in replacement.

This can be useful when debugging multi-threading behaviour, and you want to
limit multi-threading in a fine-grained way.

Tested on x86_64-linux, by using it instead of the parallel_for_each in
dwarf2_build_psymtabs_hard.

gdb: Document floating-point support for LoongArch

Update NEWS and gdb.texinfo to document floating-point support
for LoongArch.

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

[gdb/build] Fix gdb build with gcc 4.8.5

When building gdb with gcc 4.8.5, we run into:
...
In file included from /usr/include/c++/4.8/future:43:0,
                 from gdbsupport/thread-pool.h:30,
                 from gdb/dwarf2/cooked-index.h:33,
                 from gdb/dwarf2/read.h:26,
                 from gdb/dwarf2/abbrev-cache.c:21:
/usr/include/c++/4.8/atomic: In instantiation of \
  ‘_Tp std::atomic<_Tp>::load(std::memory_order) const [with _Tp = \
  packed<dwarf_unit_type, 1ul>; std::memory_order = std::memory_order]’:
gdb/dwarf2/read.h:332:44:   required from here
/usr/include/c++/4.8/atomic:208:13: error: no matching function for call to \
  ‘packed<dwarf_unit_type, 1ul>::packed()’
         _Tp tmp;
             ^
...

Fix this by adding the default constructor for packed.

Tested on x86_64-linux, with gdb build with gcc 4.8.5.

[gdb/symtab] Make per_cu->m_lang atomic

When building gdb with -fsanitize=thread and running test-case
gdb.dwarf2/inlined_subroutine-inheritance.exp, we run into a data race
between:
...
  Read of size 1 at 0x7b2000003010 by thread T4:
    #0 packed<language, 1ul>::operator language() const packed.h:54
    #1 dwarf2_per_cu_data::set_lang(language) read.h:363
...
and:
...
  Previous write of size 1 at 0x7b2000003010 by main thread:
    #0 dwarf2_per_cu_data::set_lang(language) read.h:365
...

Fix this by making per_cu->m_lang atomic.

Tested on x86_64-linux.

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

[gdb/symtab] Make per_cu->unit_type atomic

With gdb with -fsanitize=thread and test-case gdb.ada/array_bounds.exp, I run
into a data race between:
...
  Read of size 1 at 0x7b2000025f0f by main thread:
    #0 packed<dwarf_unit_type, 1ul>::operator dwarf_unit_type() const packed.h:54
    #1 dwarf2_per_cu_data::set_unit_type(dwarf_unit_type) read.h:339
...
and:
...
  Previous write of size 1 at 0x7b2000025f0f by thread T3:
    #0 dwarf2_per_cu_data::set_unit_type(dwarf_unit_type) read.h:341
...

Fix this by making per_cu->unit_type atomic.

Tested on x86_64-linux.

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

[gdb/symtab] Fix data race in ~charset_vector

When doing:
...
$ gdb ./outputs/gdb.ada/char_enum_unicode/foo -batch -ex "break foo.adb:26"
...
with a gdb build with -fsanitize=thread I run into a data race:
...
WARNING: ThreadSanitizer: data race (pid=30917)
  Write of size 8 at 0x7b0400004070 by main thread:
    #0 free <null> (libtsan.so.2+0x4c5e2)
    #1 xfree<char> gdbsupport/gdb-xfree.h:37 (gdb+0x650f17)
    #2 charset_vector::clear() gdb/charset.c:703 (gdb+0x651354)
    #3 charset_vector::~charset_vector() gdb/charset.c:697 (gdb+0x6512d3)
    #4 <null> <null> (libtsan.so.2+0x32643)
    #5 captured_main_1 gdb/main.c:1310 (gdb+0xa3975a)
...

The problem is that we're freeing the charset_vector elements in the destructor,
which may still be used by a worker thread.

Fix this by not freeing the charset_vector elements in the destructor.

Tested on x86_64-linux.

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

Re: PowerPC: implement md_operand to parse register names

I meant to make this change before committing, to let compilers know
the code on the false branch of md_parse_name is dead.

* config/tc-ppc.c (ppc_parse_name): Return void.
* config/tc-ppc.h (md_parse_name): Always true.
(ppc_parse_name): Update prototype.

PowerPC: implement md_operand to parse register names

Allows register names to appear in symbol assignments, so for example
 tocp = %r2
 mr %r3,tocp
now assembles.

* gas/config/tc-ppc.c (REG_NAME_CNT): Delete, replace uses with
ARRAY_SIZE.
(register_name): Rename to..
(md_operand): ..this.  Only handle %reg.
(cr_names): Rename to..
(cr_cond): ..this.  Just keep conditions.
(ppc_parse_name): Add mode param.  Search both cr_cond and
pre_defined_registers.  Handle absolute and register symbol
values here rather than in expr.c:operand().
(md_assemble): Don't special case register name matching in
operands, except to set cr_operand as appropriate.
* gas/config/tc-ppc.h (md_operand): Don't define.
(md_parse_name, ppc_parse_name): Update.
* read.c (pseudo_set): Copy over entire O_register value.
* testsuite/gas/ppc/regsyms.d.
* testsuite/gas/ppc/regsyms.s: New test.
* testsuite/gas/ppc/ppc.exp: Run it.

Automatic date update in version.in

Tighten gdb.threads/no-unwaited-for-left.exp regexps

A WIP version of a patch
(https://sourceware.org/pipermail/gdb-patches/2022-June/190202.html)
resulted in a bug that went unnoticed by the testuite, like so:

 (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: enable scheduler-locking, for main thread
 continue
 Continuing.
 [New Thread 1251861.1251861]
 No unwaited-for children left.
 (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits
 info threads
   Id   Target Id                                Frame
   3    Thread 1251861.1251863 "no-unwaited-for" __pthread_clockjoin_ex (threadid=140737351558976, thread_return=0x0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145
   4    Thread 1251861.1251861 "no-unwaited-for" <unavailable> in ?? ()

 The current thread <Thread ID 1> has terminated.  See `help thread'.
 (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: only thread 3 left, main thread terminated

Somehow, above, GDB re-added the zombie leader back before printing
"No unwaited-for children left.".  The "only thread 3 left, main
thread terminated" test should have caught this, but didn't.  That is
because the test's regexp has a ".*" after the part that matches
thread 3.  This commit tightens that regexp to catch such a bug.  It
also tightens the "only main thread left, thread 2 terminated" test's
regexp in the same way.

Change-Id: I8744f327a0aa0e2669d1ddda88247e99b91cefff

Fix for gdb.base/stap-probe.c

On PowePC, the test fails on a compile error:

  /../binutils-gdb-current/gdb/testsuite/gdb.base/stap-probe.c:107:1: error: expected '=', ',', ';', 'asm' or 'attribute' before 'use_xmm_reg'
  107 | use_xmm_reg (int val)
  | ^~~~~~~~~~~

Where the source code for stap-probe.c is:

  static const char * __attribute__((noinline)) ATTRIBUTE_NOCLONE
  use_xmm_reg (int val)                         <-- line 107
  {
  ...

The issue is the ATTRIBUTE_NOCLONE is not defined as an attribute as
expected.  The #define for ATTRIBUTE_NOCLONE can be found in
../lib/attributes.h.

This patch adds the missing include statement for the definition of
ATTRIBUTE_NOCLONE.

The patch has been tested and verified on a Power10 system.

Add PowerPC support to gdb.cp/call-method-register.cc

This patch adds the needed define ASM_REG for PowerPC.

The patch was run on a Power 10 system.  The gdb Summary for the run lists
2 expected passes, no unexpected failures or untested testcases.

Please let me know if this patch is acceptable for mainline.

                         Carl Love

Fix gdb.base/step-indirect-call-thunk.exp

Due to recent changes in the default value of -fcf-protection for gcc, the
test gdb.base/step-indirect-call-thunk.exp fails on Intel X86-64 with the
error:

Executing on host: gcc  -fno-stack-protector  -fdiagnostics-color=never
-mindirect-branch=thunk -mfunction-return=thunk -c -g
-o /.../gdb/testsuite/outputs/gdb.base/step-indirect-call-thunk/step-indirect-call-thunk0.o
/.../gdb/testsuite/gdb.base/step-indirect-call-thunk.c
(timeout = 300) builtin_spawn -ignore SIGHUP gcc -fno-stack-protector
-fdiagnostics-color=never -mindirect-branch=thunk -mfunction-return=thunk -c
-g -o /.../gdb/testsuite/outputs/gdb.base/step-indirect-call-thunk/step-indirect-call-thunk0.o
/.../binutils-gdb-current/gdb/testsuite/gdb.base/step-indirect-call-thunk.c
/.../gdb/testsuite/gdb.base/step-indirect-call-thunk.c:
 In function 'inc': /.../gdb/testsuite/gdb.base/step-indirect-call-thunk.c:
22:1: error: '-mindirect-branch' and '-fcf-protection' are not compatible
   22 | {                /* inc.1 */

As stated in the error message the default "-fcf-protection" and
"-mindirect-branch' are in compatible.  The fcf-protection argument needs
to be "-fcf-protection=none" for the test to compile on Intel.

The gcc command line "-mindirect-branch' is an Intel specific and will give
an error on other platforms.  A check for X86 is added so the test will
only run on X86 platforms.

The patch has been tested and verified on Power 10 and Intel X86-64 systems
with no regressions.

Fix "until LINE" in main, when "until" runs into longjmp

With a test like this:

1       #include <dlfcn.h>
2       int
3       main ()
4       {
5          dlsym (RTLD_DEFAULT, "FOO");
6          return 0;
7       }

and then "start" followed by "until 6", GDB currently incorrectly
stops inside the runtime loader, instead of line 6.  Vis:

  ...
  Temporary breakpoint 1, main () at until.c:5
  4       {
  (gdb) until 6
  0x00007ffff7f0a90d in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffdb00, operate=<optimized out>, args=0x7ffff7f0a90d <__GI__dl_catch_exception+109>) at dl-error-skeleton.c:206
  206     dl-error-skeleton.c: No such file or directory.
  (gdb)

The problem is related to longjmp handling -- dlsym internally
longjmps on error.  The testcase can be reduced to this:

1       #include <setjmp.h>
2       void func () {
3         jmp_buf buf;
4         if (setjmp (buf) == 0)
5           longjmp (buf, 1);
6       }
7
8       int main () {
9         func ();
10        return 0; /* until to here */
11      }

and then with "start" followed by "until 10", GDB currently
incorrectly stops at line 4 (returning from setjmp), instead of line
10.

The problem is that the BPSTAT_WHAT_CLEAR_LONGJMP_RESUME code in
infrun.c fails to find the initiating frame, and so infrun thinks that
the longjmp jumped somewhere outer to "until"'s originating frame.

Here:

    case BPSTAT_WHAT_CLEAR_LONGJMP_RESUME:
      {
struct frame_info *init_frame;

/* There are several cases to consider.

   1. The initiating frame no longer exists.  In this case we
   must stop, because the exception or longjmp has gone too
   far.

        ...

init_frame = frame_find_by_id (ecs->event_thread->initiating_frame);

if (init_frame)   // this is NULL!
  {
     ...
  }

/* For Cases 1 and 2, remove the step-resume breakpoint, if it
   exists.  */
delete_step_resume_breakpoint (ecs->event_thread);

end_stepping_range (ecs);   // case 1., so we stop.
      }

The initiating frame is set by until_break_command ->
set_longjmp_breakpoint.  The initiating frame is supposed to be the
frame that is selected when the command was issued, but
until_break_command instead passes the frame id of the _caller_ frame
by mistake.  When the "until LINE" command is issued from main, the
caller frame is the caller of main.  When later infrun tries to find
that frame by id, it fails to find it, because frame_find_by_id
doesn't unwind past main.

The bug is that we passed the caller frame's id to
set_longjmp_breakpoint.  We should have passed the selected frame's id
instead.

Change-Id: Iaae1af7cdddf296b7c5af82c3b5b7d9b66755b1c

gdbserver: remove unused variable

When building with clang 15, I got this error:

  CXX    server.o
server.cc:2985:10: error: variable 'new_argc' set but not used [-Werror,-Wunused-but-set-variable]
  int i, new_argc;
             ^
Remove the unused variable to eliminate the error.

Tested by rebuilding on x86_64-linux with clang 15.

[gdb/symtab] Make per_cu->set_lang more strict

We have in per_cu->set_lang this comment:
...
  void set_lang (enum language lang)
  {
    /* We'd like to be more strict here, similar to what is done in
       set_unit_type,  but currently a partial unit can go from unknown to
       minimal to ada to c.  */
...

Fix this by not setting m_lang for partial units.

This requires us to move the m_unit_type initialization to ensure that
m_unit_type is initialized before per_cu->m_lang.

Tested on x86_64-linux, with native and target board cc-with-dwz-m.

Automatic date update in version.in

Improve "set scheduler-locking" documentation

This improves the "set scheduler-locking" documentation in the GDB
manual:

 - Use a table to describe the four available modes.

 - Describe "step" in terms of "on" and "off".

 - Tweak the "replay" mode's description to describe replay first
   instead of recording, and also mention how the mode behaves during
   normal execution.

 - Say what is the default mode.

Change-Id: Ie12140138b37534b7fc1d904da34f0f174aa11ce

[gdb/symtab] Add dwarf2_cu::lang ()

The cu->per_cu->lang field was added to carry information from the initial
partial symtabs phase to the symtab expansion phase, for the benefit of a
particular optimization in process_imported_unit_die.

Other uses have been added, but since the first phase now has been
parallelized, those have become problematic and sources of race conditions.

Fix this by adding dwarf2_cu::lang () and using it where we can to replace
cu->per_cu->lang () with cu->lang ().

Also assert in dwarf2_cu::lang () that we're not returning language_unknown.

Tested on x86_64-linux.

LTO plugin: sync header file with GCC

include/ChangeLog:

* plugin-api.h (enum ld_plugin_tag): Sync with GCC.

[gdb/record] Support recording of getrandom

Add missing support for recording of linux syscall getrandom.

Tested on x86_64-linux with native and target board unix/-m32.

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

gdbserver: LoongArch: Add floating-point support

This commit adds floating-point support for LoongArch gdbserver.

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

gdb: LoongArch: Add floating-point support

This commit adds floating-point support for LoongArch gdb.

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

[gdb/testsuite] Run two test-cases with ASAN_OPTIONS=verify_asan_link_order=0

When building gdb with -fsanitize=address we run into:
...
builtin_spawn gdb -nw -nx -iex set height 0 -iex set width 0 -data-directory \
  build/gdb/data-directory^M
==10637==ASan runtime does not come first in initial library list; you \
  should either link runtime to your application or manually preload it with \
  LD_PRELOAD.^M
ERROR: GDB process no longer exists
...

Prevent the ASan runtime error by using
ASAN_OPTIONS=verify_asan_link_order=0.  This makes both test-cases pass.

Tested on x86_64-linux.

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

[gdb/testsuite] Add tsan-suppressions.txt

Add a new file tsan-suppressions.txt, to suppress the "unlock unlocked mutex"
problem in ncurses, filed in PR29328.

The file is added to the TSAN_OPTIONS in lib/gdb.exp.

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

[gdb/build] Fix build with gcc 4.8.5

When building gdb with gcc 4.8.5, we run into problems due to unconditionally
using:
...
     gdb_static_assert (std::is_trivially_copyable<packed>::value);
...
in gdbsupport/packed.h.

Fix this by guarding the usage with HAVE_IS_TRIVIALLY_COPYABLE.

Tested by doing a full gdb build with gcc 4.8.5.

Fix -fsanitize=thread for per_cu fields

When building gdb with -fsanitize=thread and gcc 12, and running test-case
gdb.dwarf2/dwz.exp, we run into a data race between:
...
  Read of size 1 at 0x7b200000300d by thread T2:^M
    #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
    abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6164 \
    (gdb+0x82ec95)^M
...
and:
...
  Previous write of size 1 at 0x7b200000300d by main thread:^M
    #0 prepare_one_comp_unit gdb/dwarf2/read.c:23588 (gdb+0x86f973)^M
...

In other words, between:
...
  if (this_cu->reading_dwo_directly)
...
and:
...
    cu->per_cu->lang = pretend_language;
...

Likewise, we run into a data race between:
...
  Write of size 1 at 0x7b200000300e by thread T4:
    #0 process_psymtab_comp_unit gdb/dwarf2/read.c:6789 (gdb+0x830720)
...
and:
...
  Previous read of size 1 at 0x7b200000300e by main thread:
    #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
    abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6164 \
    (gdb+0x82edab)
...

In other words, between:
...
      this_cu->unit_type = DW_UT_partial;
...
and:
...
  if (this_cu->reading_dwo_directly)
...

Likewise for the write to addresses_seen in cooked_indexer::check_bounds and a
read from is_dwz in dwarf2_find_containing_comp_unit for test-case
gdb.dwarf2/dw2-dir-file-name.exp and target board cc-with-dwz-m.

The problem is that the written fields are part of the same memory location as
the read fields, so executing a read and write in different threads is
undefined behavour.

Making the written fields separate memory locations, using the new
struct packed template fixes this.

The set of fields has been established experimentally to be the
minimal set to get rid of this type of -fsanitize=thread errors, but
more fields might require the same treatment.

Looking at the properties of the lang field, unlike dwarf_version it's
not available in the unit header, so it will be set the first time
during the parallel cooked index reading.  The same holds for
unit_type, and likewise for addresses_seen.

dwarf2_per_cu_data::addresses_seen is moved so that the bitfields that
currently follow it can be merged in the same memory location as the
bitfields that currently precede it, for better packing.

Tested on x86_64-linux.

Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: Ifa94f0a2cebfae5e8f6ddc73265f05e7fd9e1532

Introduce struct packed template

When building gdb with -fsanitize=thread and gcc 12, and running test-case
gdb.dwarf2/dwz.exp, we run into a few data races.  For example, between:

 ...
   Write of size 1 at 0x7b200000300e by thread T4:
     #0 process_psymtab_comp_unit gdb/dwarf2/read.c:6789 (gdb+0x830720)
 ...

and:

 ...
   Previous read of size 1 at 0x7b200000300e by main thread:
     #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
     abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6164 \
     (gdb+0x82edab)
 ...

In other words, between:

 ...
       this_cu->unit_type = DW_UT_partial;
 ...

and:

 ...
   if (this_cu->reading_dwo_directly)
 ...

The problem is that the written fields are part of the same memory
location as the read fields, so executing a read and write in
different threads is undefined behavour.

Making the written fields separate memory locations, like this:

...
  struct {
    ENUM_BITFIELD (dwarf_unit_type) unit_type : 8;
  };
...

fixes it, however that also increases the size of struct
dwarf2_per_cu_data, because it introduces padding due to alignment of
these new structs, which align on the natural alignment of the
specified type of their fields.  We can fix that with
__attribute__((packed)), like so:

  struct {
    ENUM_BITFIELD (dwarf_unit_type) unit_type : 8 __attribute__((packed));
  };

but to avoid having to write that in several places and add suitable
comments explaining how that concoction works, introduce a new struct
packed template that wraps/hides this.  Instead of the above, we'll be
able to write:

    packed<dwarf_unit_type, 1> unit_type;

Note that we can't change the type of dwarf_unit_type, as that is
defined in include/, and shared with other projects, some of those
written in C.

This patch just adds the struct packed type.  Following patches will
make use of it.  One of those patches will want to wrap a struct
packed in an std::atomic, like:

  std::atomic<std::packed<language, 1>> m_lang;

so the new gdbsupport/packed.h header adds some operators to make
comparisions between that std::atomic and the type that the wrapped
struct packed wraps work, like in:

   if (m_lang == language_c)

It would be possible to implement struct packed without using
__attribute__((packed)), by having it store an array of bytes of the
appropriate size instead, however that would make it less convenient
to debug GDB.  The way it's implemented, printing a struct packed
variable just prints its field using its natural type, which is
particularly useful if the type is an enum.  I believe that
__attribute__((packed)) is supported by all compilers that are able to
build GDB.  Even a few BFD headers use on ATTRIBUTE_PACKED on external
types:

 include/coff/external.h:  } ATTRIBUTE_PACKED
 include/coff/external.h:} ATTRIBUTE_PACKED ;
 include/coff/external.h:} ATTRIBUTE_PACKED ;
 include/coff/pe.h:} ATTRIBUTE_PACKED ;
 include/coff/pe.h:} ATTRIBUTE_PACKED;
 include/elf/external.h:} ATTRIBUTE_PACKED  Elf_External_Versym;

It is not possible to build GDB with MSVC today, but if it could, that
would be one compiler that doesn't support this attribute.  However,
it supports packing via pragmas, so there's a way to cross that bridge
if we ever get to it.  I believe any compiler worth its salt supports
some way of packing.

In any case, the worse that happens without the attribute is that some
types become larger than ideal.  Regardless, I've added a couple
static assertions to catch such compilers in action:

    /* Ensure size and aligment are what we expect.  */
    gdb_static_assert (sizeof (packed) == Bytes);
    gdb_static_assert (alignof (packed) == 1);

Change-Id: Ifa94f0a2cebfae5e8f6ddc73265f05e7fd9e1532

PowerPC md_end: Don't htab_delete(NULL)

It might be possible to hit md_end before md_begin is called, don't
segfault if so.  Also, remove a useless check.

* gas/config/tc-ppc.c (insn_calloc): Remove needless overflow
check.
(ppc_md_end): Check ppc_hash before deleting.  Clear ppc_hash.

PR29355, ld segfaults with -r/-q and custom-named section .rela*

The bug testcase uses an output section named .rel or .rela which has
input .data sections mapped to it.  The input .data section has
relocations.  When counting output relocations SHT_REL and SHT_RELA
section reloc_count is ignored, with the justification that reloc
sections themselves can't have relocations and some backends use
reloc_count in reloc sections.  However, the test wrongly used the
output section type (which normally would match input section type).
Fix that.  Note that it is arguably wrong for ld to leave the output
.rel/.rela section type as SHT_REL/SHT_RELA when non-empty non-reloc
sections are written to it, but I'm not going to change that since it
might be useful to hand-craft relocs in a data section that is then
written to a SHT_REL/SHT_RELA output section.

PR 29355
* elflink.c (bfd_elf_final_link): Use input section type rather
than output section type to determine whether to exclude using
reloc_count from that section.

gdb/csky complete csky_dwarf_reg_to_regnum

For csky arch, the correspondence between Dwarf registers and GDB
registers are as follows:
dwarf regnos 0~31 ==> gdb regs r0~r31
dwarf regno  CSKY_HI_REGNUM(36) ==> gdb reg hi
dwarf regno  CSKY_LO_REGNUM(37) ==> gdb reg hi
dwarf regno  CSKY_PC_REGNUM(72) ==> gdb reg pc
dwarf regnos FV_PSEUDO_REGNO_FIRST(74)~FV_PSEUDO_REGNO_LAST(201)
==>
gdb regs s0~s127 (pseudo regs for float and vector regs)

other dwarf regnos have no corresponding gdb regs to them.

Automatic date update in version.in

Always emit =thread-exited notifications, even if silent

[Note: the testcased added by this commit depends on
https://sourceware.org/pipermail/gdb-patches/2022-June/190259.html,
otherwise GDB just crashes when detaching the core]

Currently, in MI, =thread-created are always emitted, like:

 =thread-group-started,id="i1",pid="195680"
 =thread-created,id="1",group-id="i1"
 ...

but on teardown, if the target uses exit_inferior_silent, then you'll
only see the inferior exit notification (thread-group-exited), no
notification for threads.

The core target is one of the few targets that use
exit_inferior_silent.  Here's an example session:

 -target-select core $corefile
 =thread-group-started,id="i1",pid="195680"
 =thread-created,id="1",group-id="i1"
 ...
 ^connected,frame=....
 (gdb)
 -target-detach
 =thread-group-exited,id="i1"
 ^done
 (gdb)

This imbalance of emitting =thread-created but then not =thread-exited
seems off to me.  (And, it complicates changes I want to do to
centralize emitting thread exit notifications for the CLI, which is
why I'm looking at this.)

And then, since most other targets use exit_inferior instead of
exit_inferior_silent, MI is already emitting =thread-exited
notifications when tearing down an inferior, for most targets.

This commit makes MI always emit the =thread-exited notifications,
even for exit_inferior_silent.

Afterwards, when debugging a core, MI outputs:

 (gdb)
 -target-detach
 =thread-exited,id="1",group-id="i1"    << new line
 =thread-group-exited,id="i1"
 ^done
 (gdb)

Surprisingly, there's no MI testcase debugging a core file.  This
commit adds the first.

Change-Id: I5100501a46f07b6bbad3e04d120c2562a51c93a4

Fix core-file -> detach -> crash (corefiles/29275)

After loading a core file, you're supposed to be able to use "detach"
to unload the core file.  That unfortunately regressed starting with
GDB 11, with these commits:

 1192f124a308 - gdb: generalize commit_resume, avoid commit-resuming when threads have pending statuses
 408f66864a1a - detach in all-stop with threads running

resulting in a GDB crash:

 ...
 Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
 0x0000555555e842bf in maybe_set_commit_resumed_all_targets () at ../../src/gdb/infrun.c:2899
 2899          if (proc_target->commit_resumed_state)
 (top-gdb) bt
 #0  0x0000555555e842bf in maybe_set_commit_resumed_all_targets () at ../../src/gdb/infrun.c:2899
 #1  0x0000555555e848bf in scoped_disable_commit_resumed::reset (this=0x7fffffffd440) at ../../src/gdb/infrun.c:3023
 #2  0x0000555555e84a0c in scoped_disable_commit_resumed::reset_and_commit (this=0x7fffffffd440) at ../../src/gdb/infrun.c:3049
 #3  0x0000555555e739cd in detach_command (args=0x0, from_tty=1) at ../../src/gdb/infcmd.c:2791
 #4  0x0000555555c0ba46 in do_simple_func (args=0x0, from_tty=1, c=0x55555662a600) at ../../src/gdb/cli/cli-decode.c:95
 #5  0x0000555555c112b0 in cmd_func (cmd=0x55555662a600, args=0x0, from_tty=1) at ../../src/gdb/cli/cli-decode.c:2514
 #6  0x0000555556173b1f in execute_command (p=0x5555565c5916 "", from_tty=1) at ../../src/gdb/top.c:699

The code that crashes looks like:

 static void
 maybe_set_commit_resumed_all_targets ()
 {
   scoped_restore_current_thread restore_thread;

   for (inferior *inf : all_non_exited_inferiors ())
     {
       process_stratum_target *proc_target = inf->process_target ();

       if (proc_target->commit_resumed_state)
           ^^^^^^^^^^^

With 'proc_target' above being null.  all_non_exited_inferiors filters
out inferiors that have pid==0.  We get here at the end of
detach_command, after core_target::detach has already run, at which
point the inferior _should_ have pid==0 and no process target.  It is
clear it no longer has a process target, but, it still has a pid!=0
somehow.

The reason the inferior still has pid!=0, is that core_target::detach
just unpushes, and relies on core_target::close to actually do the
getting rid of the core and exiting the inferior.  The problem with
that is that detach_command grabs an extra strong reference to the
process stratum target, so the unpush_target inside
core_target::detach doesn't actually result in a call to
core_target::close.

Fix this my moving the cleaning up the core inferior to a shared
routine called by both core_target::close and core_target::detach.  We
still need to cleanup the inferior from within core_file::close
because there are paths to it that want to get rid of the core without
going through detach.  E.g., "core-file" -> "run".

This commit includes a new test added to gdb.base/corefile.exp to
cover the "core-file core" -> "detach" scenario.

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

Change-Id: Ic42bdd03182166b19f598428b0dbc2ce6f67c893

Fix non-existent "@var{thread-id}" in stop reply descriptions

In the description of stop replies, where the "thread" register is
explained, and where the fork and vfork stop reasons are detailed,
there are references to "@var{thread-id}", but such variable does not
actually exist.  This commit fixes it.

Change-Id: If679944aaf15f6f64aabe506339a9e7667864cab

Try a couple PAuth compilation flags for gdb.arch/aarch64-pauth.exp

The -msign-return-address switch has been dropped from GCC, but some
older compiler may still support it.  Make sure we try both
-msign-return-address and -mbranch-protection before bailing out when
running gdb.arch/aarch64-pauth.exp.

gdb: add support for disassembler styling using libopcodes

This commit extends GDB to make use of libopcodes styling support
where available, currently this is just i386 based architectures, and
RISC-V.

For architectures that don't support styling using libopcodes GDB will
fall back to using the Python Pygments package, when the package is
available.

The new libopcodes based styling has the disassembler identify parts
of the disassembled instruction, e.g. registers, immediates,
mnemonics, etc, and can style these components differently.
Additionally, as the styling is now done in GDB we can add settings to
allow the user to configure which colours are used right from the GDB
CLI.

There's some new maintenance commands:

  maintenance set libopcodes-styling enabled on|off
  maintenance show libopcodes-styling

These can be used to manually disable use of libopcodes styling.  This
is a maintenance command as it's not anticipated that a user should
need to do this.  But, this could be useful for testing, or, in some
rare cases, a user might want to override the Python hook used for
disassembler styling, and then disable libopcode styling so that GDB
falls back to using Python.  Right now I would consider this second
use case a rare situation, which is why I think a maintenance command
is appropriate.

When libopcodes is being used for styling then the user can make use
of the following new styles:

  set/show style disassembler comment
  set/show style disassembler immediate
  set/show style disassembler mnemonic
  set/show style disassembler register

The disassembler also makes use of the 'address' and 'function'
styles to style some parts of the disassembler output.  I have also
added the following aliases though:

  set/show style disassembler address
  set/show style disassembler symbol

these are aliases for:

  set/show style address
  set/show style function

respectively, and exist to make it easier for users to discover
disassembler related style settings.  The 'address' style is used to
style numeric addresses in the disassembler output, while the 'symbol'
or 'function' style is used to style the names of symbols in
disassembler output.

As not every architecture supports libopcodes styling, the maintenance
setting 'libopcodes-styling enabled' has an "auto-off" type behaviour.
Consider this GDB session:

  (gdb) show architecture
  The target architecture is set to "auto" (currently "i386:x86-64").
  (gdb) maintenance show libopcodes-styling enabled
  Use of libopcodes styling support is "on".

the setting defaults to "on" for architectures that support libopcodes
based styling.

  (gdb) set architecture sparc
  The target architecture is set to "sparc".
  (gdb) maintenance show libopcodes-styling enabled
  Use of libopcodes styling support is "off" (not supported on architecture "sparc")

the setting will show as "off" if the user switches to an architecture
that doesn't support libopcodes styling.  The underlying setting is
still "on" at this point though, if the user switches back to
i386:x86-64 then the setting would go back to being "on".

  (gdb) maintenance set libopcodes-styling enabled off
  (gdb) maintenance show libopcodes-styling enabled
  Use of libopcodes styling support is "off".

now the setting is "off" for everyone, even if the user switches back
to i386:x86-64 the setting will still show as "off".

  (gdb) maintenance set libopcodes-styling enabled on
  Use of libopcodes styling not supported on architecture "sparc".
  (gdb) maintenance show libopcodes-styling enabled
  Use of libopcodes styling support is "off".

attempting to switch the setting "on" for an unsupported architecture
will give an error, and the setting will remain "off".

  (gdb) set architecture auto
  The target architecture is set to "auto" (currently "i386:x86-64").
  (gdb) maintenance show libopcodes-styling enabled
  Use of libopcodes styling support is "off".
  (gdb) maintenance set libopcodes-styling enabled on
  (gdb) maintenance show libopcodes-styling enabled
  Use of libopcodes styling support is "on".

the user will need to switch back to a supported architecture before
they can one again turn this setting "on".

gdb: have gdb_disassemble_info carry 'this' in its stream pointer

The gdb_disassemble_info class is a wrapper around the libopcodes
disassemble_info struct.  The 'stream' field of disassemble_info is
passed as an argument to the fprintf_func and fprintf_styled_func
callbacks when the disassembler wants to print anything.

Previously, GDB would store a pointer to a ui_file object in the
'stream' field, then, when the disassembler wanted to print anything,
the content would be written to the ui_file object.  An example of an
fprintf_func callback, from gdb/disasm.c is:

  int
  gdb_disassembler::dis_asm_fprintf (void *stream, const char *format, ...)
  {
    /* Write output to STREAM here.  */
  }

This is fine, but has one limitation, within the print callbacks we
only have access to STREAM, we can't access any additional state
stored within the gdb_disassemble_info object.

Right now this isn't a problem, but in a future commit this will
become an issue, how we style the output being written to STREAM will
depend on the state of the gdb_disassemble_info object, and this state
might need to be updated, depending on what is being printed.

In this commit I propose changing the 'stream' field of the
disassemble_info to carry a pointer to the gdb_disassemble_info
sub-class, rather than the stream itself.

We then have the two sub-classes of gdb_disassemble_info to consider,
the gdb_non_printing_disassembler class never cared about the stream,
previously, for this class, the stream was nullptr.  With the change
to make stream be a gdb_disassemble_info pointer, no further updates
are needed for gdb_non_printing_disassembler.

The other sub-class is gdb_printing_disassembler.  In this case the
sub-class now carries around a pointer to the stream object.  The
print callbacks are updated to cast the incoming stream object back to
a gdb_printing_disassembler, and then extract the stream.

This is purely a refactoring commit.  A later commit will add
additional state to the gdb_printing_disassembler, and update the
print callbacks to access this state.

There should be no user visible changes after this commit.

[gdb/symtab] Fix data race in per_cu->length

With gdb build with -fsanitize=thread and test-case
gdb.dwarf2/dw4-sig-types.exp and target board cc-with-dwz-m we run into a data
race between:
...
  Write of size 4 at 0x7b2800002268 by thread T4:^M
    #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
    abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6236 \
    (gdb+0x82f525)^M
...
and this read:
...
  Previous read of size 4 at 0x7b2800002268 by thread T1:^M
    #0 dwarf2_find_containing_comp_unit gdb/dwarf2/read.c:23444 \
    (gdb+0x86e22e)^M
...

In other words, between this write:
...
    this_cu->length = cu->header.get_length ();
...
and this read:
...
      && mid_cu->sect_off + mid_cu->length > sect_off))
...
of per_cu->length.

Fix this similar to the per_cu->dwarf_version case, by only setting it if
needed, and otherwise verifying that the same value is used.  [ Note that the
same code is already present in the other cutu_reader constructor. ]

Move this logic into into a member function set_length to make sure it's used
consistenly, and make the field private in order to enforce access through the
member functions, and rename it to m_length.

This exposes (running test-case gdb.dwarf2/fission-reread.exp) that in
fill_in_sig_entry_from_dwo_entry, the m_length field is overwritten.
For now, allow for that exception.

While we're at it, make sure that the length is set before read.

Tested on x86_64-linux.

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

[gdb/symtab] Use comp_unit_head::get_length

There's a spot in read_comp_units_from_section where we explictly use
initial_length_size to get the total length:
...
      this_cu->length = cu_header.length + cu_header.initial_length_size;
...

Instead, just use cu_header.get_length ().

Tested on x86_64-linux.

Automatic date update in version.in

Fix include guard naming for arch/aarch64-mte-linux.h

It should be ARCH_AARCH64_MTE_LINUX_H as opposed to ARCH_AARCH64_LINUX_H.

gdbserver: LoongArch: Add orig_a0 processing

Commit 736918239b16 ("gdb: LoongArch: add orig_a0 into register set")
introduced orig_a0, similar processing needs to be done in gdbserver.

At the same time, add orig_a0 related comments.

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

gdbserver: LoongArch: Simplify code with register number macros

Move "enum loongarch_regnum" to gdb/arch/loongarch.h so that the
macro definitions can be used in gdbserver/linux-loongarch-low.cc
to simplify the code.

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

Automatic date update in version.in

gas: tc-tic54x.c hash tables

Cleaning up the subsym_hash memory is a real pain.  Keys and values
entered into the table are quite diverse.  In some cases the key is
allocated and thus needs to be freed, in others the key is a const
string.  Values are similar, and in some cases not even a string.
Tidy this by inserting a new subsym_ent_t that describes key/value
type.  This meant the math_hash table was no longer needed.  The patch
also tidies how math functions are called, those that are supposed to
return int now no longer return their value in a float.

* config/tc-tic54x.c (math_hash): Delete.
(subsym_proc_entry): Move earlier, make proc a union, merge with..
(math_proc_entry): ..this.  Delete type.
(math_procs): Merge into subsym_procs.
(subsym_ent_t): New.  Use this type in subsym_hash..
(stag_add_field_symbols, tic54x_var, tic54x_macro_info): ..here..
(md_begin, subsym_create_or_replace, subsym_lookup): ..and here..
(subsym_substitute): ..and here.  Adjust subsym_proc_entry
function calls.  Free replacement when not returned.
(subsym_get_arg): Adjust subsym_lookup.
(free_subsym_ent, subsym_htab_create ): New functions, use when
creating subsym_hash.
(free_local_label_ent, local_label_htab_create): Similarly.
(tic54x_remove_local_label): Delete.
(tic54x_clear_local_labels): Simplify.
(tic54x_asg): Use notes obstack to dup strings.
(tic54x_eval): Likewise.
(subsym_ismember): Likewise.
(math_cvi, math_int, math_sgn): Return int.
(tic54x_macro_start): Decrement macro_level before calling as_fatal.
(tic54x_md_end): New function.
* config/tc-tic54h.c (tic54x_md_end): Declare.
(md_end): Define.

gas: use notes_calloc in string hash

Using notes_calloc means all of the string hash table memory should
now be freed before gas exits, even though htab_delete isn't called.
This also means that the hash table free_f and del_f must be NULL,
because freeing notes obstack memory results in all more recently
allocated notes memory being freed too.  So hash table resizing won't
free any memory, and will be a little faster.  Also, htab_delete won't
do anything (and be quick about it).

Since htab_traverse can also resize hash tables (to make another
traversal faster if the table is largely empty), stop that happening
when only one traversal is done.

* as.h: Reorder hash.h after symbols.h for notes_calloc decl.
* hash.h (str_htab_create): Use notes_calloc.  Do not free.
* symbols.c (resolve_local_symbol_values): Don't resize
during hash table traversal.
* config/obj-elf.c (elf_frob_file_after_relocs): Likewise.
* config/tc-ia64.c (ia64_adjust_symtab, ia64_frob_file): Likewise.
* config/tc-nds32.c (nds32_elf_analysis_relax_hint): Likewise.

gas: target string hash tables

This allocates entries added to the string hash tables on the notes
obstack, so that at least those do not leak.  A followup patch will
switch over the str_hash allocation to notes_calloc, which is why I
haven't implemented deleting all the target string hash tables.

* config/obj-coff-seh.c (get_pxdata_name, alloc_pxdata_item): Use
notes obstack for string hash table entries.
* config/tc-alpha.c (get_alpha_reloc_tag, md_begin): Likewise.
* config/tc-h8300.c (md_begin): Likewise.
* config/tc-ia64.c (dot_rot, dot_pred_rel, dot_alias): Likewise.
* config/tc-nds32.c (nds32_relax_hint): Likewise.
* config/tc-riscv.c (riscv_init_csr_hash): Likewise.
* config/tc-score.c (s3_insert_reg): Likewise.
(s3_build_score_ops_hsh, s3_build_dependency_insn_hsh): Likewise.
* config/tc-score7.c (s7_build_score_ops_hsh): Likewise.
(s7_build_dependency_insn_hsh): Likewise.
* config/tc-tic4x.c (tic4x_asg): Likewise.

arc gas: don't leak arc_opcode_hash memory

The arc opcode hash table has entries that have a realloc'd field.
This doesn't lend itself to obstack allocation, so freeing must be
done with a purpose built hashtab del_f.

* config/tc-arc.c (arc_opcode_free): New function.
(md_begin): Pass the above as del_f to htab_create_alloc.
(arc_md_end): New function.
* config/tc-arc.h (arc_md_end): Declare.
(md_end): Define.

i386 gas: don't leak op_hash or reg_hash memory

This tidies memory used by the two x86 gas string hash tables before
exiting.  I'm using a two-pronged approach, firstly the obvious call
to htab_delete plus telling the libiberty/hashtab.c infrastructure to
free tuples generated by str_hash_insert, and secondly putting the x86
core_optab memory on the notes obstack.  It would be possible to free
core_optab memory by using a custom hash table del_f on x86, as I do
for arc, but a later patch will move all the string hash memory to the
notes obstack.

* config/tc-i386.c (md_begin): Use notes_alloc for core_optab.
(386_md_end): New function.
* config/tc-i386.h (386_md_end): Declare.
(md_end): Define.
* hash.h (str_htab_create): Pass free as del_f.

ppc gas: don't leak ppc_hash memory

* config/tc-ppc.c (insn_obstack): New.
(insn_calloc): New function.
(ppc_setup_opcodes): Use insn_obstack for ppc_hash.
(ppc_md_end): New function.
* config/tc-ppc.h (ppc_md_end): Declare
(md_end): Define.

gas hash.h tidy

Only inline functions should be defined in hash.h, there's no benefit
in having multiple copies of hash_string_tuple and eq_string_tuple.
Also, use the table alloc_f when allocating tuples to be stored, so
that these functions are usable with different memory allocation
strategies.

* hash.h (struct string_tuple, string_tuple_t): Move earlier.
(string_tuple_alloc): Add table param, allocate using table alloc_f.
(str_hash_insert): Adjust to suit.  Call table->free_f when
entry is not used.
(hash_string_tuple, eq_string_tuple): Move to..
* hash.c: ..here.

gas: rename md_end to md_finish

Currently md_end is typically used for some final actions rather than
freeing memory like other *_end functions.  Rename it to md_finish,
and rename target implementation.  The renaming of target functions
makes it possible to find them all with "grep md_finish",
eg. md_mips_end is renamed to mips_md_finish, not md_mips_finish.
This patch leaves a number of md_end functions unchanged, those that
either do nothing or deallocate memory, and calls them late.

The idea here is that target maintainers implement md_end functions to
tidy memory, if anyone cares.  Freeing persistent memory in gas is
not at all important, except that it can hide more important memory
leaks, those that happen once per some frequent gas operation, amongst
these unimportant memory leaks.

* as.c (main): Rename md_end to md_finish.
* config/tc-alpha.c, * config/tc-alpha.h,
* config/tc-arc.c, * config/tc-arc.h,
* config/tc-arm.c, * config/tc-arm.h,
* config/tc-csky.c, * config/tc-csky.h,
* config/tc-ia64.c, * config/tc-ia64.h,
* config/tc-mcore.c, * config/tc-mcore.h,
* config/tc-mips.c, * config/tc-mips.h,
* config/tc-mmix.c, * config/tc-mmix.h,
* config/tc-msp430.c, * config/tc-msp430.h,
* config/tc-nds32.c, * config/tc-nds32.h,
* config/tc-ppc.c, * config/tc-ppc.h,
* config/tc-pru.c, * config/tc-pru.h,
* config/tc-riscv.c, * config/tc-riscv.h,
* config/tc-s390.c, * config/tc-s390.h,
* config/tc-sparc.c, * config/tc-sparc.h,
* config/tc-tic4x.c, * config/tc-tic4x.h,
* config/tc-tic6x.c, * config/tc-tic6x.h,
* config/tc-v850.c, * config/tc-v850.h,
* config/tc-xtensa.c, * config/tc-xtensa.h,
* config/tc-z80.c, * config/tc-z80.h: Similarly.
* output-file.c (output_file_close): Call md_end.

gas: set up notes obstack earlier

So that the notes obstack can be used for persistent storage in
parse_args.

* as.c (parse_args): Use notes_alloc and notes_strdup.
(free_notes): New function.
(main): Init notes obstack, and arrange to be freed on exit.
* read.c (read_begin): Don't init notes obstack.
(read_end): Free cond_obstack.
* subsegs.c (subsegs_end): Don't free cond_obstack or notes.

gas: itbl_files

itbl_files seems to be debug code.  Get rid of it.

* as.c (struct itbl_file_list): Delete.
(itbl_files): Delete.
(parse_args): Don't keep itbl_files list.

gas: free sy_hash, macro_hash and po_hash

* macro.c (macro_end): New function.
* macro.h (macro_end): Declare.
* read.c (read_end, poend): New functions.
* read.h (read_end): Declare.
* symbols.c (symbol_end): New function.
* symbols.h (symbol_end): Declare.
* output-file.c (output_file_close): Call new *_end functions.

dw2gencfi.c: use notes obstack

Use notes obstack for dwcfi_hash entries, and free table.  Freeing the
table makes memory checkers complain more about "definitely lost"
memory as we've moved some from the "still reachable" category.
That will be fixed with a later patch.

* dw2gencfi.c (get_debugseg_name): Allocate on notes obstack.
(alloc_debugseg_item): Likewise.
(dwcfi_hash_find_or_make): Adjust failure path free.
(cfi_finish): Delete dwfci_hash.

expr.c make_expr_symbol: use notes obstack

* expr.c (make_expr_symbol): Use notes_alloc.

read.c assign_symbol: use notes obstack for dummy listing frag

* read.c (assign_symbol): Use notes_calloc for dummy_frag.

read.c s_include: use notes obstack for path

* read.c (s_include): Use notes obstack for path mem.

macro.c: use string hash from hash.h for macro_hash

Another case of duplicated hash.h code, the only minor difference
being that macro->format_hash was created with 7 entries vs. str_hash
with 16 entries.

* macro.c (macro_init, define_macro): Use str_htab_create.
(do_formals, define_macro, macro_expand_body): Use str_hash_insert
(macro_expand_body): Use str_hash_find and str_hash_delete.
(delete_macro): Likewise.
(sub_actual, macro_expand, check_macro): Use str_hash_find.
(expand_irp): Use str_htab_create and str_hash_insert.
* macro.h (struct macro_struct): Tidy.
(struct macro_hash_entry, macro_hash_entry_t, hash_macro_entry),
(eq_macro_entry, macro_entry_alloc, macro_entry_find),
(struct formal_hash_entry, formal_hash_entry_t),
(hash_formal_entry, eq_formal_entry, formal_entry_alloc),
(formal_entry_find): Delete.
* config/tc-iq2000.c (iq2000_add_macro): Use str_htab_create
and str_hash_insert.

read.c: use string hash from hash.h for po_hash

po_hash code duplicates the str_hash code in hash.h for no good reason.

* read.c (struct po_entry, po_entry_t): Delete.
(hash_po_entry, eq_po_entry, po_entry_alloc, po_entry_find): Delete.
(pop_insert): Use str_hash_insert.
(pobegin): Use str_htab_create.
(read_a_source_file, s_macro): Use str_hash_find.

free read_symbol_name string

read_symbol_name mallocs the string it returns.  Free it when done.

* read.c (read_symbol_name): Free name on error path.
* config/tc-ppc.c (ppc_GNU_visibility): Free name returned from
read_symbol_name.
(ppc_extern, ppc_globl, ppc_weak): Likewise.

gas: output_file_close

This is mostly a tidy with the aim of being able to free
out_file_name, but it does fix a possible attempt to unlink the output
file twice (not that that matters).

* as.h (keep_it): New global.
* as.c (keep_it): Delete.
(close_output_file): Delete, merged into..
* output-file.c (output_file_close): ..here.  Delete parameter.
* output-file.h (output_file_close): Update prototype.

gas: utility notes memory alloc functions

Makes it a little easier to use the notes obstack for persistent
storage.

* as.h (gas_mul_overflow): Define.
* symbols.h (notes_alloc, notes_calloc, notes_memdup),
(notes_strdup, notes_concat, notes_free): Declare.
* symbols.c (notes_alloc, notes_calloc, notes_memdup),
(notes_strdup, notes_concat, notes_free): New functions.
(save_symbol_name): Use notes_strdup.
(symbol_create, local_symbol_make, local_symbol_convert),
(symbol_clone, decode_local_label_name): Use notes_alloc.

gas: arm -mwarn-syms duplicates

arm gas is only supposed to warn once per symbol for -mwarn-syms, but
doesn't because the str_hash_find added with commit 629310abec88
always returns NULL.  That's so because the str_hash_insert inserts a
NULL value for the key,value pair.  Let str_hash_insert do the job
instead.

* config/tc-arm.c (arm_tc_equal_in_insn): Correct already_warned
logic.
* testsuite/gas/arm/pr18347.s: Modify to generate duplicate
warning without this patch.

Regenerate with automake-1.15.1

Until we update the recommended versions of autoconf/automake, files
should be regenerated with automake-1.15.1 and autoconf-2.69.  That's
not because we think those versions are golden, and newer versions are
bad.  It's simply because maintainers want to be able to update
configury files without trouble, and if someone regenerates files with
automake-1.16.5 then --enable-maintainer-mode builds will hit errors:

checking that generated files are newer than configure... configure.ac:26: error: version mismatch.  This is Automake 1.15.1,
configure.ac:26: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:26: comes from Automake 1.16.5.  You should recreate
configure.ac:26: aclocal.m4 with aclocal and run automake again.
WARNING: 'automake-1.15' is probably too old.

Correcting this requires regenerating the files by hand.

Automatic date update in version.in

Accept gdb.Value in more Python APIs

PR python/27000 points out that gdb.block_for_pc will accept a Python
integer, but not a gdb.Value.  This patch corrects this oversight.

I looked at all uses of GDB_PY_LLU_ARG and fixed these up to use
get_addr_from_python instead.  I also looked at uses of GDB_PY_LL_ARG,
but those seemed relatively unlikely to be useful with a gdb.Value, so
I didn't change them.  My thinking here is that a Value will typically
come from inferior memory, and something like a line number is not too
likely to be found this way.

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

Handle bool specially in gdb.set_parameter

PR python/29217 points out that gdb.parameter will return bool values,
but gdb.set_parameter will not properly accept them.  This patch fixes
the problem by adding a special case to set_parameter.

I looked at a fix involving rewriting set_parameter in C++.  However,
this one is simpler.

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

[gdb/build] Handle deprecation of scm_install_gmp_memory_functions

When building gdb with guile 3.0.8, we run into:
...
gdb/guile/guile.c: In function \
  'void gdbscm_initialize(const extension_language_defn*)':
gdb/guile/guile.c:680:5: error: 'scm_install_gmp_memory_functions' is \
  deprecated [-Werror=deprecated-declarations]
  680 |     scm_install_gmp_memory_functions = 0;
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/guile/3.0/libguile.h:128,
                 from gdb/guile/guile-internal.h:30,
                 from gdb/guile/guile.c:36:
/usr/include/guile/3.0/libguile/deprecated.h:164:20: note: declared here
  164 | SCM_DEPRECATED int scm_install_gmp_memory_functions;
      |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:1896: guile/guile.o] Error 1
...

The variable has been deprecated because it no longer has any effect.

Fix this by disabling the specific deprecation warning.

Also handle upcoming guile versions > 3.0, in which the variable will be
removed, by limiting the usage of the variable to guile versions <= 3.0.

This does not break anything.  The variable was merely used to address a
problem present in guile versions <= v3.0.5.

Note that we don't limit the usage of the variable to guile versions <= 3.0.5,
because we want to support f.i. building against 3.0.6 and then using a shared
lib with 3.0.5.

Tested on x86_64-linux.

Co-Authored-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28994

[gdb/symtab] Fix assert in process_imported_unit_die

When running test-case gdb.dwarf2/dw2-symtab-includes.exp with target board
cc-with-debug-names, I run into:
...
(gdb) maint expand-symtab dw2-symtab-includes.h^M
src/gdb/dwarf2/read.h:311: internal-error: unit_type: \
  Assertion `m_unit_type != 0' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
----- Backtrace -----^M
FAIL: gdb.dwarf2/dw2-symtab-includes.exp: maint expand-symtab \
  dw2-symtab-includes.h (GDB internal error)
...

The assert was recently added in commit 2c474c46943 ("[gdb/symtab] Add get/set
functions for per_cu->lang/unit_type").

The assert is triggered here:
...
    /* We're importing a C++ compilation unit with tag DW_TAG_compile_unit
       into another compilation unit, at root level.  Regard this as a hint,
       and ignore it.  */
    if (die->parent && die->parent->parent == NULL
        && per_cu->unit_type () == DW_UT_compile
        && per_cu->lang () == language_cplus)
      return;
...

We're trying to access unit_type / lang which hasn't been set yet.

Normally, these are set during cooked index creation, but that's not the case
when using an index (or using -readnow).

In other words, this lto binary reading speed optimization only works in the
normal use case.

IWBN to have this working in all use cases, but for now, allow lang () and
unit_type () to return language_unknown and 0 here.

Tested on x86_64-linux.

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

[gdb/symtab] Fix segfault in dwarf2_per_objfile::symtab_set_p

When running test-case gdb.cp/cpexprs-debug-types.exp with target board
cc-with-debug-names, I run into:
...
(gdb) print base::operator new^M
^M
^M
Fatal signal: Segmentation fault^M
----- Backtrace -----^M
0x57ea46 gdb_internal_backtrace_1^M
        /home/vries/gdb_versions/devel/src/gdb/bt-utils.c:122^M
0x57eae9 _Z22gdb_internal_backtracev^M
        /home/vries/gdb_versions/devel/src/gdb/bt-utils.c:168^M
0x75b8ad handle_fatal_signal^M
        /home/vries/gdb_versions/devel/src/gdb/event-top.c:946^M
0x75ba19 handle_sigsegv^M
        /home/vries/gdb_versions/devel/src/gdb/event-top.c:1019^M
0x7f795f46a8bf ???^M
0x6d3cb1 _ZNK18dwarf2_per_objfile12symtab_set_pEPK18dwarf2_per_cu_data^M
        /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:1515^M
...

The problem is in this piece of code in dw2_debug_names_iterator::next:
...
        case DW_IDX_type_unit:
          /* Don't crash on bad data.  */
          if (ull >= per_bfd->tu_stats.nr_tus)
            {
              complaint (_(".debug_names entry has bad TU index %s"
                           " [in module %s]"),
                         pulongest (ull),
                         objfile_name (objfile));
              continue;
            }
          per_cu = per_bfd->get_cu (ull + per_bfd->tu_stats.nr_tus);
          break;
...

The all_comp_units vector (which get_cu accesses) contains both CUs and TUs,
with CUs first.

So to get the nth TU we need the element at "nr_cus + n", but
the code uses "nr_tus + n" instead.

Fix this by using "nr_cus + n".

Tested on x86_64-linux.

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