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

gdb: initialize the data_head variable to eliminate compilation warnings

On a machine with gcc 12, I get this warning:

  CXX    nat/linux-btrace.o
In function ‘btrace_error linux_read_bts(btrace_data_bts*, btrace_target_info*, btrace_read_type)’,
    inlined from ‘btrace_error linux_read_btrace(btrace_data*, btrace_target_info*, btrace_read_type)’ at ../gdb/nat/linux-btrace.c:935:29:
../gdb/nat/linux-btrace.c:865:21: warning: ‘data_head’ may be used uninitialized [-Wmaybe-uninitialized]
  865 |   pevent->last_head = data_head;
      |   ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~
../gdb/nat/linux-btrace.c: In function ‘btrace_error linux_read_btrace(btrace_data*, btrace_target_info*, btrace_read_type)’:
../gdb/nat/linux-btrace.c:792:9: note: ‘data_head’ was declared here
  792 |   __u64 data_head, data_tail;
      |         ^~~~~~~~~

Fix this by initializing the 'data_head' variable.

Tested by rebuilding on x86_64 openSUSE Tumbleweed with gcc 12.

libopcodes/s390: add support for disassembler styling

This commit adds disassembler style to the libopcodes s390
disassembler.  This conversion was pretty straight forward, I just
converted the fprintf_func calls to fprintf_styled_func calls and
added an appropriate style.

For testing the new styling I just assembled then disassembled the
source files in gas/testsuite/gas/s390 and manually checked that the
styling looked reasonable.

If the user does not request styled output from objdump, then there
should be no change in the disassembler output after this commit.

Fix regeneration of ld configure and makefiles

Update release README with new version numbers

Update version to 2.39.50 and regenerate files

Add markers for 2.39 branch

Automatic date update in version.in

gprofng: fix regression in testing for not yet installed version

gprofng/ChangeLog
2022-07-07  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

* src/Settings.cc (Settings::read_rc): Read environment variable
GPROFNG_SYSCONFDIR.
* testsuite/lib/Makefile.skel: Export GPROFNG_SYSCONFDIR.
* testsuite/gprofng.display/display.exp: Shorten the list of tests.

gdb: fix {rs6000_nat_target,aix_thread_target}::wait to not use inferior_ptid

Trying to run a simple program (empty main) on AIX, I get:

    (gdb) run
    Starting program: /scratch/simark/build/gdb/a.out
    Child process unexpectedly missing: There are no child processes..
    ../../src/binutils-gdb/gdb/inferior.c:304: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    ----- Backtrace -----
    0x10ef12a8 gdb_internal_backtrace_1()
            ../../src/binutils-gdb/gdb/bt-utils.c:122
    0x10ef1470 gdb_internal_backtrace()
            ../../src/binutils-gdb/gdb/bt-utils.c:168
    0x1004d368 internal_vproblem(internal_problem*, char const*, int, char const*, char*)
            ../../src/binutils-gdb/gdb/utils.c:396
    0x1004d8a8 internal_verror(char const*, int, char const*, char*)
            ../../src/binutils-gdb/gdb/utils.c:476
    0x1004c424 internal_error(char const*, int, char const*, ...)
            ../../src/binutils-gdb/gdbsupport/errors.cc:55
    0x102ab344 find_inferior_pid(process_stratum_target*, int)
            ../../src/binutils-gdb/gdb/inferior.c:304
    0x102ab4a4 find_inferior_ptid(process_stratum_target*, ptid_t)
            ../../src/binutils-gdb/gdb/inferior.c:318
    0x1061bae8 find_thread_ptid(process_stratum_target*, ptid_t)
            ../../src/binutils-gdb/gdb/thread.c:519
    0x10319e98 handle_inferior_event(execution_control_state*)
            ../../src/binutils-gdb/gdb/infrun.c:5532
    0x10315544 fetch_inferior_event()
            ../../src/binutils-gdb/gdb/infrun.c:4221
    0x10952e34 inferior_event_handler(inferior_event_type)
            ../../src/binutils-gdb/gdb/inf-loop.c:41
    0x1032640c infrun_async_inferior_event_handler(void*)
            ../../src/binutils-gdb/gdb/infrun.c:9548
    0x10673188 check_async_event_handlers()
            ../../src/binutils-gdb/gdb/async-event.c:335
    0x1066fce4 gdb_do_one_event()
            ../../src/binutils-gdb/gdbsupport/event-loop.cc:214
    0x10001a94 start_event_loop()
            ../../src/binutils-gdb/gdb/main.c:411
    0x10001ca0 captured_command_loop()
            ../../src/binutils-gdb/gdb/main.c:471
    0x10003d74 captured_main(void*)
            ../../src/binutils-gdb/gdb/main.c:1329
    0x10003e48 gdb_main(captured_main_args*)
            ../../src/binutils-gdb/gdb/main.c:1344
    0x10000744 main
            ../../src/binutils-gdb/gdb/gdb.c:32
    ---------------------
    ../../src/binutils-gdb/gdb/inferior.c:304: internal-error: find_inferior_pid: Assertion `pid != 0' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    Quit this debugging session? (y or n)

This is due to some bit-rot in the AIX port, still relying on the entry
value of inferior_ptid in the wait methods.

Problem #1 is in rs6000_nat_target::wait, here:

      /* Ignore terminated detached child processes.  */
      if (!WIFSTOPPED (status) && pid != inferior_ptid.pid ())
pid = -1;

At this point, waitpid has returned an "exited" status for some pid, so
pid is non-zero.  Since inferior_ptid is set to null_ptid on entry, the
pid returned by wait is not equal to `inferior_ptid.pid ()`, so we reset
pid to -1 and go to waiting again.  Since there are not more children to
wait for, waitpid then returns -1 so we get here:

      if (pid == -1)
{
  gdb_printf (gdb_stderr,
      _("Child process unexpectedly missing: %s.\n"),
      safe_strerror (save_errno));

  /* Claim it exited with unknown signal.  */
  ourstatus->set_signalled (GDB_SIGNAL_UNKNOWN);
  return inferior_ptid;
}

We therefore return a "signalled" status with a null_ptid (again,
inferior_ptid is null_ptid).  This confuses infrun, because if the
target returns a "signalled" status, it should be coupled with a ptid
for an inferior that exists.

So, the first step is to fix the snippets above to not use
inferior_ptid.  In the first snippet, use find_inferior_pid to see if
we know the event process.  If there is no inferior with that pid, we
assume it's a detached child process to we ignore the event.  That
should be enough to fix the problem, because it should make it so we
won't go into the second snippet.  But still, fix the second snippet to
return an "ignore" status.  This is copied from inf_ptrace_target::wait,
which is where rs6000_nat_target::wait appears to be copied from in the
first place.

These changes, are not sufficient, as the aix_thread_target, which sits
on top of rs6000_nat_target, also relies on inferior_ptid.
aix_thread_target::wait, by calling pd_update, assumes that
rs6000_nat_target has set inferior_ptid to the appropriate value (the
ptid of the event thread), but that's not the case.  pd_update
returns inferior_ptid - null_ptid - and therefore
aix_thread_target::wait returns null_ptid too, and we still hit the
assert shown above.

Fix this by changing pd_activate, pd_update, sync_threadlists and
get_signaled_thread to all avoid using inferior_ptid.  Instead, they
accept as a parameter the pid of the process we are working on.

With this patch, I am able to run the program to completion:

    (gdb) r
    Starting program: /scratch/simark/build/gdb/a.out
    [Inferior 1 (process 11010794) exited normally]

As well as break on main:

    (gdb) b main
    Breakpoint 1 at 0x1000036c
    (gdb) r
    Starting program: /scratch/simark/build/gdb/a.out

    Breakpoint 1, 0x1000036c in main ()
    (gdb) c
    Continuing.
    [Inferior 1 (process 26083688) exited normally]

Change-Id: I7c2613bbefe487d75fa1a0c0994423471d961ee9

Fix pedantically invalid DWARF in gdb.trace/unavailable-dwarf-piece.exp

The DWARF spec says:

  Any debugging information entry representing the declaration of an object,
  module, subprogram or type may have DW_AT_decl_file, DW_AT_decl_line and
  DW_AT_decl_column attributes, each of whose value is an unsigned integer
  ^^^^^^^^
  constant.

Grepping around the DWARF-assembler-based testcases, I noticed that
gdb.trace/unavailable-dwarf-piece.exp emits decl_line with
DW_FORM_sdata, a signed integer form.  This commit tweaks it to use
DW_FORM_udata instead.

Unsurprisingly, this:

  $ make check \
      TESTS="gdb.trace/unavailable-dwarf-piece.exp" \
      RUNTESTFLAGS="--target_board=native-gdbserver"

... still passes cleanly for me after this change.

I've noticed this because current llvm-dwarfdump crashed on an
ROCm-internal DWARF-assembler-based testcase that incorrectly used
signed forms for DW_AT_decl_file/DW_AT_decl_line.

The older llvm-dwarfdump found on Ubuntu 20.04 (LLVM 10) reads the
line numbers with signed forms as "0" instead of crashing.  Here's the
before/after fix for gdb.trace/unavailable-dwarf-piece.exp with that
llvm-dwarfdump version:

  $ diff -up before.txt after.txt
  --- before.txt    2022-07-07 13:21:28.387690334 +0100
  +++ after.txt     2022-07-07 13:21:39.379801092 +0100
  @@ -18,7 +18,7 @@
   DW_AT_name     ("s")
   DW_AT_byte_size        (3)
   DW_AT_decl_file        (0)
  -                DW_AT_decl_line        (0)
  +                DW_AT_decl_line        (1)

   0x0000002f:     DW_TAG_member
     DW_AT_name   ("a")
  @@ -41,7 +41,7 @@
   DW_AT_name     ("t")
   DW_AT_byte_size        (3)
   DW_AT_decl_file        (0)
  -                DW_AT_decl_line        (0)
  +                DW_AT_decl_line        (1)

   0x00000054:     DW_TAG_member
     DW_AT_name   ("a")

Change-Id: I5c866946356da421ff944019d0eca2607b2b738f

gdb: LoongArch: Fix typos in code comments

"it’s" should be "it's".

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

GDB/testsuite: Add coverage for `print -elements' command

We currently have no coverage for the `print -elements ...' command (or
`p -elements ...' in the shortened form), so add a couple of test cases
mimicking ones using corresponding `set print elements ...' values.

gdb: LoongArch: Implement the push_dummy_call gdbarch method

According to "Procedure Calling Convention" in "LoongArch ELF ABI
specification" [1], implement the push_dummy_call gdbarch method
as clear as possible.

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

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

RISC-V: Added Zfhmin and Zhinxmin.

This commit adds Zfhmin and Zhinxmin extensions (subsets of Zfh and
Zhinx extensions, respectively).  In the process supporting Zfhmin and
Zhinxmin extension, this commit also changes how instructions are
categorized considering Zfhmin, Zhinx and Zhinxmin extensions.

Detailed changes,

* From INSN_CLASS_ZFH to INSN_CLASS_ZFHMIN:

flh, fsh, fmv.x.h and fmv.h.x.

* From INSN_CLASS_ZFH to INSN_CLASS_ZFH_OR_ZHINX:

fmv.h.

* From INSN_CLASS_ZFH_OR_ZHINX to INSN_CLASS_ZFH_OR_ZHINX:

fneg.h, fabs.h, fsgnj.h, fsgnjn.h, fsgnjx.h,
fadd.h, fsub.h, fmul.h, fdiv.h, fsqrt.h, fmin.h, fmax.h,
fmadd.h, fnmadd.h, fmsub.h, fnmsub.h,
fcvt.w.h, fcvt.wu.h, fcvt.h.w, fcvt.h.wu,
fcvt.l.h, fcvt.lu.h, fcvt.h.l, fcvt.h.lu,
feq.h, flt.h, fle.h, fgt.h, fge.h,
fclass.h.

* From INSN_CLASS_ZFH_OR_ZHINX to INSN_CLASS_ZFHMIN_OR_ZHINXMIN:

fcvt.s.h and fcvt.h.s.

* From INSN_CLASS_D_AND_ZFH_INX to INSN_CLASS_ZFHMIN_AND_D:

fcvt.d.h and fcvt.h.d.

* From INSN_CLASS_Q_AND_ZFH_INX to INSN_CLASS_ZFHMIN_AND_Q:

fcvt.q.h and fcvt.h.q.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_implicit_subsets): Change implicit
subsets.  Zfh->Zicsr is not needed and Zfh->F is replaced with
Zfh->Zfhmin and Zfhmin->F.  Zhinx->Zicsr is not needed and
Zhinx->Zfinx is replaced with Zhinx->Zhinxmin and
Zhinxmin->Zfinx.
(riscv_supported_std_z_ext): Added zfhmin and zhinxmin.
(riscv_multi_subset_supports):  Rewrite handling for new
instruction classes.
(riscv_multi_subset_supports_ext): Updated.
(riscv_parse_check_conflicts): Change error message to include
zfh and zfhmin extensions.

gas/ChangeLog:

* testsuite/gas/riscv/zfhmin-d-insn-class-fail.s: New complex
error handling test.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-1.d: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-1.l: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-2.d: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-2.l: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-3.d: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-3.l: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-4.d: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-4.l: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-5.d: Likewise.
* testsuite/gas/riscv/zfhmin-d-insn-class-fail-5.l: Likewise.
* testsuite/gas/riscv/zhinx.d: Renamed from fp-zhinx-insns.d
and refactored.
* testsuite/gas/riscv/zhinx.s: Likewise.

include/ChangeLog:

* opcode/riscv.h (enum riscv_insn_class): Removed INSN_CLASS_ZFH,
INSN_CLASS_D_AND_ZFH_INX and INSN_CLASS_Q_AND_ZFH_INX.  Added
INSN_CLASS_ZFHMIN, INSN_CLASS_ZFHMIN_OR_ZHINXMIN,
INSN_CLASS_ZFHMIN_AND_D and INSN_CLASS_ZFHMIN_AND_Q.

opcodes/ChangeLog:

* riscv-opc.c (riscv_opcodes): Change instruction classes for
Zfh and Zfhmin instructions.  Fix `fcvt.h.lu' instruction
(two operand variant) mask.

gprofng: adjust GPROFNG_VARIANT

GPROFNG_VARIANT depends on compiler options, not on $(host).

gprofng/ChangeLog
2022-07-06  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29116
* libcollector/configure.ac: Adjust GPROFNG_VARIANT.
* libcollector/configure: Rebuild.

RISC-V: Fix disassembling Zfinx with -M numeric

This commit fixes floating point operand register names from ABI ones
to dynamically set ones.

gas/ChangeLog:

* testsuite/gas/riscv/zfinx-dis-numeric.s: Test new behavior of
Zfinx extension and -M numeric disassembler option.
* testsuite/gas/riscv/zfinx-dis-numeric.d: Likewise.

opcodes/ChangeLog:

* riscv-dis.c (riscv_disassemble_insn): Use dynamically set GPR
names to disassemble Zfinx instructions.

RISC-V: Fix requirement handling on Zhinx+{D,Q}

This commit fixes how instructions are masked on Zhinx+Z{d,q}inx.
fcvt.h.d and fcvt.d.h require ((D&&Zfh)||(Zdinx&&Zhinx)) and
fcvt.h.q and fcvt.q.h require ((Q&&Zfh)||(Zqinx&&Zhinx)).

bfd/ChangeLog:

* elfxx-riscv.c (riscv_multi_subset_supports): Fix feature gate
on INSN_CLASS_{D,Q}_AND_ZFH_INX.
(riscv_multi_subset_supports_ext): Fix feature gate diagnostics
on INSN_CLASS_{D,Q}_AND_ZFH_INX.

gas/ChangeLog:

* testsuite/gas/riscv/fp-zhinx-insns.d: Add Zqinx to -march
for proper testing.

PR29320, 'struct obstack' declared inside parameter list

PR 29320
* frags.h: Move declaration of struct obstack..
* as.h: ..to here.

Automatic date update in version.in

gprofng: implement a functional gp-display-html

This patch enables the first support for the "gprofng display html" command.
This command works for C/C++ applications on x86_64. Using one or more gprofng
experiment directories as input, a new directory with html files is created.
Through the index.html file in this directory, the performance results may be
viewed in a browser.

gprofng/Changelog:
2022-06-28  Ruud van der Pas  <ruud.vanderpas@oracle.com>

* gp-display-html/gp-display-html.in: implement first support for x86_64 and C/C++

elf: Copy p_align of PT_GNU_STACK for stack alignment

commit 74e315dbfe5200c473b226e937935fb8ce391489
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Mon Dec 13 19:46:04 2021 -0800

    elf: Set p_align to the minimum page size if possible

may ignore p_align of PT_GNU_STACK when copying ELF program header if
the maximum page size is larger than p_align of PT_LOAD segments.  Copy
p_align of PT_GNU_STACK since p_align of PT_GNU_STACK describes stack
alignment, not page size,

PR binutils/29319
* elf.c (copy_elf_program_header): Copy p_align of PT_GNU_STACK
for stack alignment.

x86: make D attribute usable for XOP and FMA4 insns

This once again allows to reduce redundancy in (and size of) the opcode
table.

Don't go as far as also making D work on the two 5-operand XOP insns:
This would significantly complicate the code, as there the first
(immediate) operand would need special treatment in several places.

Note that the .s suffix isn't being enabled to have any effect, for
being deprecated. Whereas neither {load} nor {store} pseudo prefixes
make sense here, as the respective operands are inputs (loads) only
anyway, regardless of order. Hence there is (as before) no way for the
programmer to request the alternative encoding to be used for register-
only insns.

Note further that it is always the first original template which is
retained (and altered), to make sure the same encoding as before is
used for register-only insns. This has the slightly odd (but pre-
existing) effect of XOP register-only insns having XOP.W clear, but FMA4
ones having VEX.W set.

x86: fold two switch() statements in match_template()

I don't see why two of them were introduced (very long ago) using
similar fall-through logic.

x86: fix 3-operand insn reverse-matching

The middle operand would have gone entirely unchecked, allowing e.g.

vmovss %xmm0, %esp, %xmm2

to assemble successfully, or e.g.

vmovss %xmm0, $4, %xmm2

causing an internal error. Alongside dealing with this also drop a
related comment, which hasn't been applicable anymore since the
introduction of 3-operand patterns with D set (and which perhaps never
had been logical to be there, as reverse-matched insns don't make it
there in the first place).

Descriptive DWARF operations dump support for DW_AT_rank

DW_AT_rank is a dwarf-5 feature.

x86: introduce a state stack for .arch

When using just slightly non-trivial combinations of .arch, it can be
quite useful to be able to go back to prior state without needing to
re-invoke perhaps many earlier directives and without needing to invoke
perhaps many "negative" ones. Like some other architectures allow
saving (pushing) and restoring (popping) present/prior state.

For now require the same .code<N> to be in effect for ".arch pop" that
was in effect for the corresponding ".arch push".

Also change the global "no_cond_jump_promotion" to be bool, to match the
new struct field.

x86: generalize disabling of sub-architectures

I never really understood upon what basis ".arch .no*" options were made
available. Let's not have any "criteria" at all, and simply allow
disabling of all of them. Then we also have all data for a sub-arch in
a single place, as we now only need a single table.

x86: permit "default" with .arch

So far there was no way to reset the architecture to that assembly would
start with in the absence of any overrides (command line or directives).
Note that for Intel MCU "default" is merely an alias of "iamcu".

While there also zap a stray @item from the doc section, as noticed
when inspecting the generated output (which still has some quirks, but
those aren't easy to address without re-flowing almost the entire
section).

x86: don't leak sub-architecture accumulated strings

While it may not be necessary in i386_target_format() (but then setting
the variable to NULL also wouldn't be necessary), at least in the other
cases strings may already have accumulated.

Automatic date update in version.in

[gdb/exp] Fix internal error when printing C++ pointer-to-member

When running the test-case included with this patch, we run into:
...
(gdb) print ptm^M
$1 = gdb/gdbtypes.h:695: internal-error: loc_bitpos: \
  Assertion `m_loc_kind == FIELD_LOC_KIND_BITPOS' failed.^M
...
while printing a c++ pointer-to-member.

Fix this by skipping static fields in cp_find_class_member, such that we have:
...
(gdb) print ptm^M
$1 = &A::i^M
...

Tested on x86_64-linux.

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

Add gdb.Objfile.is_file attribute

Sometimes an objfile comes from memory and not from a file.  It can be
useful to be able to check this from Python, so this patch adds a new
"is_file" attribute.

Make 'import gdb.events' work

Pierre-Marie noticed that, while gdb.events is a Python module, it
can't be imported.  This patch changes how this module is created, so
that it can be imported, while also ensuring that the module is always
visible, just as it was in the past.

This new approach required one non-obvious change -- when running
gdb.base/warning.exp, where --data-directory is intentionally not
found, the event registries can now be nullptr.  Consequently, this
patch probably also requires

    https://sourceware.org/pipermail/gdb-patches/2022-June/189796.html

Note that this patch obsoletes

    https://sourceware.org/pipermail/gdb-patches/2022-June/189797.html

gdb: LoongArch: add orig_a0 into register set

The basic support for LoongArch has been merged into the upstream Linux
kernel since 5.19-rc1 on June 5, 2022.  This commit adds orig_a0 which
is added into struct user_pt_regs [1] to match the upstream kernel, and
then the upstream GDB will work with the upstream kernel.

Note that orig_a0 was added into struct user_pt_regs in the development
cycle for merging LoongArch port into the upstream Linux kernel, so
earlier kernels (notably, the product kernel with version 4.19 used in
distros like UOS and Loongnix) don't have it.  Inspect
arch/loongarch/include/uapi/asm/ptrace.h in the kernel tree to make sure.
To build upstream GDB for a kernel lacking orig_a0, it's necessary to
revert this commit locally.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/uapi/asm/ptrace.h#n24

Signed-off-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

Support for location and range lists for split-dwarf and dwarf-5.

Adding support for location and range lists for split-dwarf and dwarf-5.
Following issues are taken care.
1. Display of the index values for DW_FORM_loclistx and DW_FORM_rnglistx.
2. Display of .debug_loclists.dwo and .debug_rnglists.dwo sections.

        * dwarf.c(read_and_display_attr_value): Handle DW_FORM_loclistx
        and DW_FORM_rnglistx for .dwo files.
        (process_debug_info): Load .debug_loclists.dwo and
        .debug_rnglists.dwo if exists.
        (load_separate_debug_files): Load .debug_loclists and
        .debug_rnglists if exists.
        Include 2 entries in debug_displays table.
        * dwarf.h (enum dwarf_section_display_enum): Include 2 entries.

x86: introduce fake processor type to mark sub-arch entries in cpu_arch[]

This is in preparation of dropping the leading . from the strings.

While there also move PROCESSOR_GENERIC{32,64} from the middle of AMD
entries to near the top.

x86: macro-ize cpu_arch[] entries

Putting individual elements behind macros, besides (imo) improving
readability, will make subsequent (and likely also future) changes less
intrusive.

Utilize this right away to pack the table a little more tightly, by
converting "skip" to bool and putting it earlier in a group of bitfields
together with "len".

x86: de-duplicate sub-architecture strings accumulation

Introduce a helper function to replace 4 instances of similar code. Use
reconcat() to cover the previously explicit free().

Automatic date update in version.in

Fix snafu in rust demangler recursion limit code

alloc gas seginfo on notes obstack

Lots of memory used in gas should go on this obstack.  The patch also
frees all the gas obstacks on exit, which isn't a completely trivial
task.

* subsegs.c (alloc_seginfo): New function.
(subseg_change, subseg_get): Use it.
(subsegs_end): New function.
* as.h (subsegs_end): Declare.
* output-file.c: Include subsegs.h
(stash_frchain_obs): New function.
(output_file_close): Save obstacks attached to output bfd before
closing.  Call subsegs_end with the array of obstacks.

objcopy: bfd_alloc orelocation

This fixes an inconsequential objcopy memory leak.  I'd normally
ignore reports of leaks like this one, that are merely one block or
fewer per section processed, since objcopy soon exits and frees all
memory.  However I thought it worth providing support for allocating
memory on a bfd objalloc in objcopy and other utils.

PR 29233
* bucomm.c (bfd_xalloc): New function.
* bucomm.h (bfd_xalloc): Declare.
* objcopy.c (copy_relocations_in_section): Use it to allocate
array of reloc pointers.  Rewrite code stripping relocs to do
without extra memory allocation.

Synchronize libbierty sources with gcc.

Modified changes for split-dwarf and dwarf-5.

        * dwarf.c(process_debug_info): Include DW_TAG_skeleton_unit.
        (display_debug_str_offsets): While dumping .debug_str_offsets.dwo,
        pass proper str_offsets_base to fetch_indexed_string().
        (load_separate_debug_files): Skip DWO ID dump for dwarf-5.

opcodes/avr: Implement style support in the disassembler

* disassemble.c: (disassemble_init_for_target): Set
created_styled_output for AVR based targets.
* avr-dis.c: (print_insn_avr): Use fprintf_styled_ftype
instead of fprintf_ftype throughout.
(avr_operand): Pass in and fill disassembler_style when
parsing operands.

[gdb/symtab] Add get/set functions for per_cu->lang/unit_type

The dwarf2_per_cu_data fields lang and unit_type both have a dont-know
initial value (respectively language_unknown and (dwarf_unit_type)0), which
allows us to add certain checks, f.i. checking that that a field is not read
before written.

Add get/set member functions for the two fields as a convenient location to
add such checks, make the fields private to enforce using the member
functions, and add the m_ prefix.

Tested on x86_64-linux.

gas/testsuite: properly exclude aout in all/weakref1u

Use the (wider) predicate rather than a triplet. This eliminates the sole
i386-msdos failure in the testsuite.

x86: fold Disp32S and Disp32

The only case where 64-bit code uses non-sign-extended (can also be
considered zero-extended) displacements is when an address size override
is in place for a memory operand (i.e. particularly excluding
displacements of direct branches, which - if at all - are controlled by
operand size, and then are still sign-extended, just from 16 bits).
Hence the distinction in templates is unnecessary, allowing code to be
simplified in a number of places. The only place where logic becomes
more complicated is when signed-ness of relocations is determined in
output_disp().

The other caveat is that Disp64 cannot be specified anymore in an insn
template at the same time as Disp32. Unlike for non-64-bit mode,
templates don't specify displacements for both possible addressing
modes; the necessary adjustment to the expected ones has already been
done in match_template() anyway (but of course the logic there needs
tweaking now). Hence the single template so far doing so is split.

x86: restore masking of displacement kinds

Commit 7d5e4556a375 rendered the check near the end of what is now
i386_finalize_displacement() entirely dead for AT&T mode, since for
operands involving a displacement .unspecified will always be set. But
the logic there is bogus anyway - Intel syntax operand size specifiers
are of no interest there either. The only thing which matters in the
"displacement only" determination is .baseindex.

Of course when masking displacement kinds we should not at the same time
also mask off other attributes.

Furthermore the type mask returned by lex_got() also needs to be
adjusted: The only case where we want Disp32 (rather than Disp32S) is
when dealing with 32-bit addressing mode in 64-bit code.

x86-64: improve handling of branches to absolute addresses

There are two related problems here: The use of "addr32" on a direct
branch would, besides causing a warning, result in operands to be
permitted which mistakenly are refused without "addr32". Plus at some
point not too long ago I'm afraid it may have been me who regressed the
relocation addends emitted for such branches. Correct both problems,
adding a testcase to guard against regressing this again.

RISC-V: Update Zihintpause extension version

Because ratified Zihintpause extension has a version number of 2.0
(not 1.0), we should update the number.

bfd/ChangeLog:

* elfxx-riscv.c (riscv_supported_std_z_ext): Update version
number of Zihintpause extension.

Automatic date update in version.in

Automatic date update in version.in

[gdb/symtab] Fix data race on per_cu->dwarf_version

When building gdb with -fsanitize=thread and gcc 12, and running test-case
gdb.dwarf2/dwz.exp, we run into a data race between thread T2 and the main
thread in the same write:
...
Write of size 1 at 0x7b200000300c:^M
    #0 cutu_reader::cutu_reader(dwarf2_per_cu_data*, dwarf2_per_objfile*, \
    abbrev_table*, dwarf2_cu*, bool, abbrev_cache*) gdb/dwarf2/read.c:6252 \
    (gdb+0x82f3b3)^M
...
which is here:
...
         this_cu->dwarf_version = cu->header.version;
...

Both writes are called from the parallel for in dwarf2_build_psymtabs_hard,
this one directly:
...
    #1 process_psymtab_comp_unit gdb/dwarf2/read.c:6774 (gdb+0x8304d7)^M
    #2 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M
    #3 operator() gdbsupport/parallel-for.h:163 (gdb+0x872380)^M
...
and this via the PU import:
...
    #1 cooked_indexer::ensure_cu_exists(cutu_reader*, dwarf2_per_objfile*, \
    sect_offset, bool,  bool) gdb/dwarf2/read.c:17964 (gdb+0x85c43b)^M
    #2 cooked_indexer::index_imported_unit(cutu_reader*, unsigned char const*, \
    abbrev_info const*) gdb/dwarf2/read.c:18248 (gdb+0x85d8ff)^M
    #3 cooked_indexer::index_dies(cutu_reader*, unsigned char const*, \
    cooked_index_entry const*, bool) gdb/dwarf2/read.c:18302 (gdb+0x85dcdb)^M
    #4 cooked_indexer::make_index(cutu_reader*) gdb/dwarf2/read.c:18443 \
    (gdb+0x85e68a)^M
    #5 process_psymtab_comp_unit gdb/dwarf2/read.c:6812 (gdb+0x830879)^M
    #6 operator() gdb/dwarf2/read.c:7098 (gdb+0x8317be)^M
    #7 operator() gdbsupport/parallel-for.h:171 (gdb+0x8723e2)^M
...

Fix this by setting the field earlier, in read_comp_units_from_section.

The write in cutu_reader::cutu_reader() is still needed, in case
read_comp_units_from_section is not used (run the test-case with say, target
board cc-with-gdb-index).

Make the write conditional, such that it doesn't trigger if the field is
already set by read_comp_units_from_section.  Instead, verify that the
field already has the value that we're trying to set it to.

Move this logic into into a member function set_version (in analogy to the
already present member function version) 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_dwarf_version.

While we're at it, make sure that the version is set before read, to avoid
say returning true for "per_cu.version () < 5" if "per_cu.version () == 0".

Tested on x86_64-linux.

[gdb/testsuite] Fix gdb.base/early-init-file.exp with -fsanitize=thread

When building gdb with -fsanitize=thread, I run into:
...
FAIL: gdb.base/early-init-file.exp: check startup version string has style \
  version
...
due to this:
...
warning: Found custom handler for signal 7 (Bus error) preinstalled.^M
warning: Found custom handler for signal 8 (Floating point exception) \
  preinstalled.^M
warning: Found custom handler for signal 11 (Segmentation fault) \
  preinstalled.^M
Some signal dispositions inherited from the environment (SIG_DFL/SIG_IGN)^M
won't be propagated to spawned programs.^M
...
appearing before the "GNU gdb (GDB) $version" line.

This is similar to the problem fixed by commit f0bbba7886f
("gdb.debuginfod/fetch_src_and_symbols.exp: fix when GDB is built with
AddressSanitizer").

In that commit, the problem was fixed by starting gdb with -quiet, but using
that would mean the "GNU gdb (GDB) $version" line that we're trying to check
would disappear.

Fix this instead by updating the regexp to allow the message.

Tested on x86_64-linux.

Automatic date update in version.in

GDB/doc: Remove indentation from `print -elements' completion example

Remove indentation from the text of the manual after the example here:

"  Completion will in some cases guide you with a suggestion of what
kind of argument an option expects.  For example:

     (gdb) print -elements <TAB><TAB>
     NUMBER     unlimited

   Here, the option expects a number (e.g., '100'), not literal
'NUMBER'.  Such metasyntactical arguments are always presented in
uppercase."

as this is a continuation of the same paragraph.

GDB/doc: Remove extraneous spaces from completion examples

Completion results are usually different when the operation is applied
to a word that is or is not followed by a space.  In some cases they are
equivalent, however a space would not be produced if completion was used
earlier on in the word processed.

However in the manual we have completion examples given using a space
that actually prevents the example from working.  E.g.:

(gdb) info bre <TAB>

(nothing) and:

(gdb) info bre <TAB><TAB>
Display all 200 possibilities? (y or n)

as it now goes on to propose the entire symbol table, while:

(gdb) info bre<TAB>
(gdb) info breakpoints

does the right thing, but is not what is shown in the manual.

In other cases an extraneous space is used that does not correspond to
the actual completion pattern shown, which gives an impression of
sloppiness.

Remove extraneous spaces then from completion examples as appropriate.

Add newline to the end of the rnglists displsy.

Automatic date update in version.in

GDB: Add `NUMBER' completion to `set' integer commands

Fix a completion consistency issue with `set' commands accepting integer
values and the special `unlimited' keyword:

(gdb) complete print -elements
print -elements NUMBER
print -elements unlimited
(gdb)

vs:

(gdb) complete set print elements
set print elements unlimited
(gdb)

(there is a space entered at the end of both commands, not shown here)
which also means if you strike <Tab> with `set print elements ' input,
it will, annoyingly, complete to `set print elements unlimited' right
away rather than showing a choice between `NUMBER' and `unlimited'.

Add `NUMBER' then as an available completion for such `set' commands:

(gdb) complete set print elements
set print elements NUMBER
set print elements unlimited
(gdb)

Adjust the testsuite accordingly.  Also document the feature in the
Completion section of the manual in addition to the Command Options
section already there.

gdb/testsuite: Expand gdb.cp/mb-ctor.exp to test dynamic allocation

When testing GDB's ability to stop in constructors, gdb.cp/mb-ctor.exp
only tested objects allocated on the stack. This commit adds a couple of
dynamic allocations and tests if GDB can stop in it as well.

Fix implementation of readelf's -wE and -wN options,

* dwarf.c (dwarf_select_sections_by_name): If the entry's value is
zero then clear the corresponding variable.
(dwarf_select_sections_by_letters): Likewise.
* testsuite/binutils-all/debuginfo.exp: Expect -WE and -wE
debuginfod tests to fail.

[gdb] Block SIGTERM in worker threads

With gdb build with gcc-12 and -fsanitize=thread, and test-case
gdb.base/gdb-sigterm.exp, I run into:
...
WARNING: ThreadSanitizer: data race (pid=9722)^M
  Write of size 4 at 0x00000325bc68 by thread T1:^M
  #0 handle_sigterm(int) src/gdb/event-top.c:1211 (gdb+0x8ec01f)^M
  ...
  Previous read of size 4 at 0x00000325bc68 by main thread:^M
    [failed to restore the stack]^M
^M
  Location is global 'sync_quit_force_run' of size 4 at \
  0x00000325bc68 (gdb+0x325bc68)^M
  ...
SUMMARY: ThreadSanitizer: data race gdb/event-top.c:1211 in \
  handle_sigterm(int)^M
...
and 3 more data races involving handle_sigterm and locations:
- active_ext_lang
- quit_flag
- heap block of size 40
  (XNEW (async_signal_handler) in create_async_signal_handler)

This was reported in PR29297.

The testcase executes a "kill -TERM $gdb_pid", which generates a
process-directed signal.

A process-directed signal can be delivered to any thread, and what we see
here is the fallout of the signal being delivered to a worker thread rather
than the main thread.

Fix this by blocking SIGTERM in the worker threads.

[ I have not been able to reproduce this after it occurred for the first time,
so unfortunately I cannot confirm that the patch fixes the problem. ]

Tested on x86_64-linux, with and without -fsanitize=thread.

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

gdb/doc: fix column widths in MI compatibility table

In passing I noticed that the column headings for the table of MI
compatibility and breaking changes, were overlapping, at least when
the PDF is generated on my machine.

I propose giving slightly more space to the two version number
columns, this prevents the headers overlapping for me.

Automatic date update in version.in

Fix GDBserver regression due to change to avoid reading shell registers

Simon reported that the recent change to make GDB and GDBserver avoid
reading shell registers caused a GDBserver regression, caught with
ASan while running gdb.server/non-existing-program.exp:

 $ /home/smarchi/build/binutils-gdb/gdb/testsuite/../../gdb/../gdbserver/gdbserver stdio non-existing-program
 =================================================================
 ==127719==ERROR: AddressSanitizer: heap-use-after-free on address 0x60f0000000e9 at pc 0x55bcbfa301f4 bp 0x7ffd238a7320 sp 0x7ffd238a7310
 WRITE of size 1 at 0x60f0000000e9 thread T0
     #0 0x55bcbfa301f3 in scoped_restore_tmpl<bool>::~scoped_restore_tmpl() /home/smarchi/src/binutils-gdb/gdbserver/../gdbsupport/scoped_restore.h:86
     #1 0x55bcbfa2ffe9 in post_fork_inferior(int, char const*) /home/smarchi/src/binutils-gdb/gdbserver/fork-child.cc:120
     #2 0x55bcbf9c9199 in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:991
     #3 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
     #4 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
     #5 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)
     #6 0x55bcbf8ef2bd in _start (/home/smarchi/build/binutils-gdb/gdbserver/gdbserver+0x1352bd)

 0x60f0000000e9 is located 169 bytes inside of 176-byte region [0x60f000000040,0x60f0000000f0)
 freed by thread T0 here:
     #0 0x7ff9d6c6f0c7 in operator delete(void*) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:160
     #1 0x55bcbf910d00 in remove_process(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/inferiors.cc:164
     #2 0x55bcbf9c4ac7 in linux_process_target::remove_linux_process(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:454
     #3 0x55bcbf9cdaa6 in linux_process_target::mourn(process_info*) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:1599
     #4 0x55bcbf988dc4 in target_mourn_inferior(ptid_t) /home/smarchi/src/binutils-gdb/gdbserver/target.cc:205
     #5 0x55bcbfa32020 in startup_inferior(process_stratum_target*, int, int, target_waitstatus*, ptid_t*) /home/smarchi/src/binutils-gdb/gdbserver/../gdb/nat/fork-inferior.c:515
     #6 0x55bcbfa2fdeb in post_fork_inferior(int, char const*) /home/smarchi/src/binutils-gdb/gdbserver/fork-child.cc:111
     #7 0x55bcbf9c9199 in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:991
     #8 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
     #9 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
     #10 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)

 previously allocated by thread T0 here:
     #0 0x7ff9d6c6e5a7 in operator new(unsigned long) ../../../../src/libsanitizer/asan/asan_new_delete.cpp:99
     #1 0x55bcbf910ad0 in add_process(int, int) /home/smarchi/src/binutils-gdb/gdbserver/inferiors.cc:144
     #2 0x55bcbf9c477d in linux_process_target::add_linux_process_no_mem_file(int, int) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:425
     #3 0x55bcbf9c8f4c in linux_process_target::create_inferior(char const*, std::__debug::vector<char*, std::allocator<char*> > const&) /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:985
     #4 0x55bcbf954549 in captured_main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:3941
     #5 0x55bcbf9552f0 in main /home/smarchi/src/binutils-gdb/gdbserver/server.cc:4084
     #6 0x7ff9d663b0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x240b2)

Above we see that in the non-existing-program case, the process gets
deleted before the starting_up flag gets restored to false.

This happens because startup_inferior calls target_mourn_inferior
before throwing an error, and in GDBserver, unlike in GDB, mourning
deletes the process.

Fix this by not using a scoped_restore to manage the starting_up flag,
since we should only clear it when startup_inferior doesn't throw.

Change-Id: I67325d6f81c64de4e89e20e4ec4556f57eac7f6c

GDB/testsuite: Tighten `set print elements' error check

Match the whole error message expected to be given rather than omitting
the part about the "unlimited" keyword.  There's no point in omitting
the missing part first, and second with an upcoming change the part in
parentheses will no longer be a fixed string, so doing a full match will
ensure the algorithm correctly builds the message expected here.  Also
avoid any wildcard matches.

GDB: Remove extraneous full stops from `set' command error messages

With errors given for bad commands such as `set annotate' or `set width'
we produce an extraneous full stop within parentheses:

(gdb) set annotate
Argument required (integer to set it to.).
(gdb) set width
Argument required (integer to set it to, or "unlimited".).
(gdb)

This is grammatically incorrect, so remove the full stop and adjust the
testsuite accordingly.

gdb/doc: improve description of --data-disassemble opcodes output

Extend the description of the MI command --data-disassemble.
Specifically, expand the description of the 'opcodes' field to explain
how the bytes are formatted.

gdb/arm: Only stack S16..S31 when FPU registers are secure

The FPCCR.TS bit is used to identify if FPU registers are considered
non-secure or secure.  If they are secure, then callee saved registers
(S16 to S31) are stacked on exception entry or otherwise skipped.

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

opcodes/aarch64: split off creation of comment text in disassembler

The function aarch64_print_operand (aarch64-opc.c) is responsible for
converting an instruction operand into the textual representation of
that operand.

In some cases, a comment is included in the operand representation,
though this (currently) only happens for the last operand of the
instruction.

In a future commit I would like to enable the new libopcodes styling
for AArch64, this will allow objdump and GDB[1] to syntax highlight
the disassembler output, however, having operands and comments
combined in a single string like this makes such styling harder.

In this commit, I propose to extend aarch64_print_operand to take a
second buffer.  Any comments for the instruction are written into this
extra buffer.  The two callers of aarch64_print_operand are then
updated to pass an extra buffer, and print any resulting comment.

In this commit no styling is added, that will come later.  However, I
have adjusted the output slightly.  Before this commit some comments
would be separated from the instruction operands with a tab character,
while in other cases the comment was separated with two single spaces.

After this commit I use a single tab character in all cases.  This
means a few test cases needed updated.  If people would prefer me to
move everyone to use the two spaces, then just let me know.  Or maybe
there was a good reason why we used a mix of styles, I could probably
figure out a way to maintain the old output exactly if that is
critical.

Other than that, there should be no user visible changes after this
commit.

[1] GDB patches have not been merged yet, but have been posted to the
GDB mailing list:
https://sourceware.org/pipermail/gdb-patches/2022-June/190142.html

gdb/testsuite: fix gdb.base/break-idempotent.exp on ppc

When running the gdb.base/break-idempotent.exp test on ppc, I was
seeing some test failures (or rather errors), that looked like this:

  (gdb) watch local
  Hardware watchpoint 2: local

  has_hw_wp_support: Hardware watchpoint detected
  ERROR: no fileid for gcc2-power8
  ERROR: Couldn't send delete breakpoints to GDB.
  ERROR OCCURED: can't read "gdb_spawn_id": no such variable
      while executing
  "expect {
  -i 1000 -timeout 100
          -re ".*A problem internal to GDB has been detected" {
              fail "$message (GDB internal error)"
              gdb_internal_erro..."
      ("uplevel" body line 1)
      invoked from within

What happens is that in break-idempotent.exp we basically do this:

    if {[prepare_for_testing "failed to prepare" $binfile $srcfile $opts]} {
        continue
    }

    # ....

    if {![skip_hw_watchpoint_tests]} {
        test_break $always_inserted "watch"
    }

The problem with this is that skip_hw_watchpoint_tests, includes this:

    if { [istarget "i?86-*-*"]
 || [istarget "x86_64-*-*"]
 || [istarget "ia64-*-*"]
 || [istarget "arm*-*-*"]
 || [istarget "aarch64*-*-*"]
 || ([istarget "powerpc*-*-linux*"] && [has_hw_wp_support])
 || [istarget "s390*-*-*"] } {
return 0
    }

For powerpc only we call has_hw_wp_support.  This is a caching proc
that runs a test within GDB to detect if we have hardware watchpoint
support or not.

Unfortunately, to run this test we restart GDB, and when the test has
completed, we exit GDB.  This means that in break-idempotent.exp, when
we call skip_hw_watchpoint_tests for the first time on powerpc, GDB
will unexpectedly be exited.  When we later call delete_breakpoints we
see the errors I reported above.

The fix is to call skip_hw_watchpoint_tests early, before we start GDB
as part of the break-idempotent.exp script, and store the result in a
variable, we can then check this variable in the script as needed.

After this change break-idempotent.exp runs fine on powerpc.

Co-authored-by: Andrew Burgess <aburgess@redhat.com>

x86: drop stray NoRex64 from XBEGIN

Presumably this being there was a result of taking CALL as a reference
when adding the RTM insns. But with No_qSuf the attribute has no effect.

gprofng: fix build when BUILD_MAN is false

gprofng/ChangeLog
2022-06-28  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29131
* gp-display-html/Makefile.am: Set man_MANS only when BUILD_MAN is true.
* src/Makefile.am: Likewise.
* gp-display-html/Makefile.in: Rebuild.
* src/Makefile.in: Rebuild.

gprofng: use $(sysconfdir) instead $(prefix)/etc

gprofng/ChangeLog
2022-06-28  Vladimir Mezentsev  <vladimir.mezentsev@oracle.com>

PR gprofng/29191
* src/Makefile.am: Use $(sysconfdir) instead $(prefix)/etc.
* src/Settings.cc: Likewise.
* src/Makefile.in: Rebuild.

Re: ld/x86: skip p_align-1 tests with unsuitable compiler

commit d0e0f9c87a3e results "ERROR: i586-linux-cc does not exist" if
cross-building an i586-linux target without a target compiler
installed.

* testsuite/ld-elf/linux-x86.exp (compiler_honours_aligned): New.
Use it after first testing check_compiler_available.

Automatic date update in version.in

gdb+gdbserver/Linux: avoid reading registers while going through shell

For every stop, Linux GDB and GDBserver save the stopped thread's PC,
in lwp->stop_pc.  This is done in save_stop_reason, in both
gdb/linux-nat.c and gdbserver/linux-low.cc.  However, while we're
going through the shell after "run", in startup_inferior, we shouldn't
be reading registers, as we haven't yet determined the target's
architecture -- the shell's architecture may not even be the same as
the final inferior's.

In gdb/linux-nat.c, lwp->stop_pc is only needed when the thread has
stopped for a breakpoint, and since when going through the shell, no
breakpoint is going to hit, we could simply teach save_stop_reason to
only record the stop pc when the thread stopped for a breakpoint.

However, in gdbserver/linux-low.cc, lwp->stop_pc is used in more cases
than breakpoint hits (e.g., it's used in tracepoints & the
"while-stepping" feature).

So to avoid GDB vs GDBserver divergence, we apply the same approach to
both implementations.

We set a flag in the inferior (process in GDBserver) whenever it is
being nursed through the shell, and when that flag is set,
save_stop_reason bails out early.  While going through the shell,
we'll only ever get process exits (normal or signalled), random
signals, and exec events, so nothing is lost.

Change-Id: If0f01831514d3a74d17efd102875de7d2c6401ad

[gdb/build] Fix gdb build with -fsanitize=thread and gcc 7

When building gdb with system gcc 7.5.0, I run into:
...
gdb/ia64-tdep.c: In function ‘int is_float_or_hfa_type_recurse(type*, type**)’:
gdb/ia64-tdep.c:3362:1: error: control reaches end of non-void function \
  [-Werror=return-type]
...

This is due to PR gcc/81275 - "-fsanitize=thread produce incorrect
-Wreturn-type warning", which has been fixed in gcc-8.

Work around this by moving the default return outside the switch.

Tested on x86_64-linux.

bfd: handle codepage when opening files on MinGW

Even if MS docs say that CP_UTF8 should always be used on newer
applications, forcing it might produce undefined filename if the
encoding isn't UTF-8.
MinGW seems to call ___lc_codepage_func() in order to retrieve the
current thread codepage.

bfd/ChangeLog:

        * bfdio.c (_bfd_real_fopen): Retrieve codepage with
        ___lc_codepage_func() on MinGW.

windres: add quotes around preprocessor cmd if needed

This patch ensures that the gcc binary called by windres is quoted if
needed. Otherwise, errors can occur if the gcc is under a folder having
a name containing a space (eg "Program Files").

binutils/
* resrc.c (DEFAULT_PREPROCESSOR): Split into...
(DEFAULT_PREPROCESSOR_CMD): that...
(DEFAULT_PREPROCESSOR_ARGS): and that.
(look_for_default): Add quotes around the command if needed.
(read_rc_file): Adapt to new defines.

Fix the display of the idnex values for DW_FORM_loclistx and DW_FORM_rnglistx.  Correct the display of .debug.loclists sections.

PR 29267
* dwarf.c (display_debug_rnglists): New function, broken out of..
(display_debug_ranges): ... here.
(read_and_display_attr_value): Correct calculation of index
displayed for DW_FORM_loclistx and DW_FORM_rnglistx.
* testsuite/binutils-all/x86-64/pr26808.dump: Update expected
output.

ld/x86: skip p_align-1 tests with unsuitable compiler

When the compiler doesn't properly arrange for foo's alignment, there's
no point even trying these tests. Report the situation as a single
"unsupported" test.

PowerPC64: align plt_branch stubs

plt_branch stubs are similar to plt_call stubs in that they branch
via bctr.  Align them too.

bfd/
* elf64-ppc.c (ppc_size_one_stub): Align plt_branch stubs as for
plt_call stubs.
ld/
* testsuite/ld-powerpc/elfv2exe.d: Adjust for plt_branch changes.
* testsuite/ld-powerpc/notoc.d: Likewise.
* testsuite/ld-powerpc/notoc.wf: Likewise.
* testsuite/ld-powerpc/notoc3.d: Likewise.
* testsuite/ld-powerpc/pr23937.d: Likewise.