gdb/testsuite: give binaries distinct names in Ada tests

Some Ada tests repeat their test sequence with different gnat-encodings,
typically "all" and "minimal".  However, they give the same name to both
binaries, meaning the second run overwrites the binary of the first run.
This makes it difficult and confusing when trying to reproduce problems
manually with the test artifacts.  Change those tests to use unique
names for each pass.

Change-Id: Iaa3c9f041241249a7d67392e785c31aa189dcc88

Change target_ops::async to accept bool

This changes the parameter of target_ops::async from int to bool.
Regression tested on x86-64 Fedora 34.

Fix typo in windows-nat.c

I noticed a typo in a printf in windows-nat.c.  This fixes it.

[gdb] Add empty range unit test for gdb::parallel_for_each

Add a unit test that verifies that we can call gdb::parallel_for_each with an
empty range.

Tested on x86_64-linux.

PR17122, OSX 10.9 build failure

sbrk hasn't been used in binutils/ or ld/ for quite some time (so the
PR was fixed a while ago).  Tidy up configury.

PR 17122
binutils/
* configure.ac: Don't check for sbrk.
* sysdep.h (sbrk): Don't supply fallback declaration.
* config.in: Regenerate.
* configure: Regenerate.
ld/
* configure.ac: Don't check for sbrk.
* config.in: Regenerate.
* configure: Regenerate.

gdb/csky modify registers list for general_reggroup

There are two modification points here:
1. For the debugging of csky architecture, after executing "info register",
   we hope to print out GPRs, PC and the registers related to exceptions.
2. With tdesc-xml, users can view the register groups described in XML.

PR15951, binutils testsuite builds status wrapper unconditionally

PR 15951
* testsuite/binutils-all/objcopy.exp: Build testglue.o when
needs_status_wrapper.

Automatic date update in version.in

Add ChangeLog entry from previous commit

PowerPC: Create new MMA instruction masks and use them

The MMA instructions use XX3_MASK|3<<21 as an instruction mask, but that
misses the RC bit/bit 31, so if we disassemble a .long that represents an
MMA instruction except that it also has bit 31 set, we will erroneously
disassemble it to that MMA instruction.  We create new masks defines that
contain bit 31 so that doesn't happen anymore.

opcodes/
* ppc-opc.c (XACC_MASK, XX3ACC_MASK): New defines.
(P_GER_MASK, xxmfacc, xxmtacc, xxsetaccz, xvi8ger4pp, xvi8ger4,
xvf16ger2pp, xvf16ger2, xvf32gerpp, xvf32ger, xvi4ger8pp, xvi4ger8,
xvi16ger2spp, xvi16ger2s, xvbf16ger2pp, xvbf16ger2, xvf64gerpp,
xvf64ger, xvi16ger2, xvf16ger2np, xvf32gernp, xvi8ger4spp, xvi16ger2pp,
xvbf16ger2np, xvf64gernp, xvf16ger2pn, xvf32gerpn, xvbf16ger2pn,
xvf64gerpn, xvf16ger2nn, xvf32gernn, xvbf16ger2nn, xvf64gernn: Use them.

i386: Don't allow GOTOFF relocation against IFUNC symbol for PIC

We can't use the PLT entry as the function address for PIC since the PIC
register may not be set up properly for indirect call.

bfd/

PR ld/27998
* elf32-i386.c (elf_i386_relocate_section): Don't allow GOTOFF
relocation against IFUNC symbol for PIC.

ld/

PR ld/27998
* testsuite/ld-i386/pr27998a.d: Replace -shared with -e bar.
* testsuite/ld-i386/pr27998b.d: Expect a linker error.
* testsuite/ld-ifunc/ifunc-2-i386-now.d: Updated.
* testsuite/ld-ifunc/ifunc-2-local-i386-now.d: Likewise.
* testsuite/ld-ifunc/ifunc-2-i386.s: Replace @GOTOFF with @GOT.
* testsuite/ld-ifunc/ifunc-2-local-i386.s: Likewise.

gdb: ensure the cast in gdbarch_tdep is valid

This commit makes use of gdb::checked_static_cast when casting the
generic gdbarch_tdep pointer to a specific sub-class type.  This means
that, when compiled in developer mode, GDB will validate that the cast
is correct.

In order to use gdb::checked_static_cast the types involved must have
RTTI, which is why the gdbarch_tdep base class now has a virtual
destructor.

Assuming there are no bugs in GDB where we cast a gdbarch_tdep pointer
to the wrong type, then there should be no changes after this commit.

If any bugs do exist, then GDB will now assert (in a developer build).

gdbsupport: add checked_static_cast

This commit was inspired by these mailing list posts:

  https://sourceware.org/pipermail/gdb-patches/2022-June/190323.html
  https://sourceware.org/pipermail/gdb-patches/2022-April/188098.html

The idea is to add a new function gdb::checked_static_cast, which can,
in some cases, be used as a drop-in replacement for static_cast.  And
so, if I previously wrote this:

  BaseClass *base = get_base_class_pointer ();
  DerivedClass *derived = static_cast<DerivedClass *> (base);

I can now write:

  BaseClass *base = get_base_class_pointer ();
  DerivedClass *derived = gdb::checked_static_cast<DerivedClass *> (base);

The requirement is that BaseClass and DerivedClass must be
polymorphic.

The benefit of making this change is that, when GDB is built in
developer mode, a run-time check will be made to ensure that `base`
really is of type DerivedClass before the cast is performed.  If
`base` is not of type DerivedClass then GDB will assert.

In a non-developer build gdb::checked_static_cast is equivalent to a
static_cast, and there should be no performance difference.

This commit adds the support function, but does not make use of this
function, a use will be added in the next commit.

Co-Authored-By: Pedro Alves <pedro@palves.net>
Co-Authored-By: Tom Tromey <tom@tromey.com>

gdb: move the type cast into gdbarch_tdep

I built GDB for all targets on a x86-64/GNU-Linux system, and
then (accidentally) passed GDB a RISC-V binary, and asked GDB to "run"
the binary on the native target.  I got this error:

  (gdb) show architecture
  The target architecture is set to "auto" (currently "i386").
  (gdb) file /tmp/hello.rv32.exe
  Reading symbols from /tmp/hello.rv32.exe...
  (gdb) show architecture
  The target architecture is set to "auto" (currently "riscv:rv32").
  (gdb) run
  Starting program: /tmp/hello.rv32.exe
  ../../src/gdb/i387-tdep.c:596: internal-error: i387_supply_fxsave: Assertion `tdep->st0_regnum >= I386_ST0_REGNUM' failed.

What's going on here is this; initially the architecture is i386, this
is based on the default architecture, which is set based on the native
target.  After loading the RISC-V executable the architecture of the
current inferior is updated based on the architecture of the
executable.

When we "run", GDB does a fork & exec, with the inferior being
controlled through ptrace.  GDB sees an initial stop from the inferior
as soon as the inferior comes to life.  In response to this stop GDB
ends up calling save_stop_reason (linux-nat.c), which ends up trying
to read register from the inferior, to do this we end up calling
target_ops::fetch_registers, which, for the x86-64 native target,
calls amd64_linux_nat_target::fetch_registers.

After this I eventually end up in i387_supply_fxsave, different x86
based targets will end in different functions to fetch registers, but
it doesn't really matter which function we end up in, the problem is
this line, which is repeated in many places:

  i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch);

The problem here is that the ARCH in this line comes from the current
inferior, which, as we discussed above, will be a RISC-V gdbarch, the
tdep field will actually be of type riscv_gdbarch_tdep, not
i386_gdbarch_tdep.  After this cast we are relying on undefined
behaviour, in my case I happen to trigger an assert, but this might
not always be the case.

The thing I tried that exposed this problem was of course, trying to
start an executable of the wrong architecture on a native target.  I
don't think that the correct solution for this problem is to detect,
at the point of cast, that the gdbarch_tdep object is of the wrong
type, but, I did wonder, is there a way that we could protect
ourselves from incorrectly casting the gdbarch_tdep object?

I think that there is something we can do here, and this commit is the
first step in that direction, though no actual check is added by this
commit.

This commit can be split into two parts:

 (1) In gdbarch.h and arch-utils.c.  In these files I have modified
 gdbarch_tdep (the function) so that it now takes a template argument,
 like this:

    template<typename TDepType>
    static inline TDepType *
    gdbarch_tdep (struct gdbarch *gdbarch)
    {
      struct gdbarch_tdep *tdep = gdbarch_tdep_1 (gdbarch);
      return static_cast<TDepType *> (tdep);
    }

  After this change we are no better protected, but the cast is now
  done within the gdbarch_tdep function rather than at the call sites,
  this leads to the second, much larger change in this commit,

  (2) Everywhere gdbarch_tdep is called, we make changes like this:

    -  i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch);
    +  i386_gdbarch_tdep *tdep = gdbarch_tdep<i386_gdbarch_tdep> (arch);

There should be no functional change after this commit.

In the next commit I will build on this change to add an assertion in
gdbarch_tdep that checks we are casting to the correct type.

gdb: select suitable thread for gdbarch_adjust_breakpoint_address

The three targets that implement gdbarch_adjust_breakpoint_address are
arm, frv, and mips.  In each of these targets the adjust breakpoint
address function does some combination of reading the symbol table, or
reading memory at the location the breakpoint could be placed.

The problem is that performing these actions requires that the current
inferior and program space be the one in which the breakpoint will be
placed, and this is not currently always the case.

Consider a GDB session with multiple inferiors.  One inferior might be
a native target while another could be a remote target of a completely
different architecture.  Alternatively, if we consider ARM and
AArch64, one native inferior might be AArch64, while a second native
inferior could be ARM.

In these cases it is possible, and valid, for a user to have one
inferior selected, and place a breakpoint in the other inferior by
placing a breakpoint on a particular symbol.

If this happens, then currently, when
gdbarch_adjust_breakpoint_address is called, the wrong inferior (and
program space) will be selected, and memory reads, and symbol look
ups, will not return the expected results, this could lead to
breakpoints being placed in the wrong location.

There are currently two places where gdbarch_adjust_breakpoint_address
is called:

  1. In infrun.c, in the function handle_step_into_function.  In this
  case, I believe that the correct inferior and program space will
  already be selected as this is called as part of the stop event
  handling, so I don't think we need to worry about this case, and

  2. In breakpoint.c, in the function adjust_breakpoint_address, which
  is itself called from code_breakpoint::add_location and
  watch_command_1.

  The watch_command_1 case I don't think we need to worry about, this
  is for when a local watch expression is created, which can only be
  in the currently selected inferior, so this case should be fine.

  The code_breakpoint::add_location case is the one that needs fixing,
  this is what allows a breakpoint to be created between inferiors.

To fix the code_breakpoint::add_location case, I propose that we pass
the "correct" program_space (i.e. the program space in which the
breakpoint will be created) to the adjust_breakpoint_address function.
Then in adjust_breakpoint_address we can make use of
switch_to_program_space_and_thread to switch program_space and
inferior before calling gdbarch_adjust_breakpoint_address.

I discovered this issue while working on a later patch in this
series.  This later patch will detect when we cast the result of
gdbarch_tdep to the wrong type.

With this later patch in place I ran gdb.multi/multi-arch.exp on an
AArch64 target.  In this situation, two inferiors are created, an
AArch64 inferior, and an ARM inferior.  The test selected the AArch64
inferior and tries to create a breakpoint in the ARM inferior.

As a result of this we end up in arm_adjust_breakpoint_address, which
calls arm_pc_is_thumb.  Before this commit the AArch64 inferior would
be current.  As a result, all of the checks in arm_pc_is_thumb would
fail (they rely on reading symbols from the current program space),
and so, at the end of arm_pc_is_thumb we would call
arm_frame_is_thumb.  However, remember, at this point the current
inferior is the AArch64 inferior, so the current frame is an AArch64
frame.

In arm_frame_is_thumb we call arm_psr_thumb_bit, which calls
gdbarch_tdep and casts the result to arm_gdbarch_tdep.  This is wrong,
the tdep field is of type aarch64_gdbarch_tdep.  After this we have
undefined behaviour.

With this patch in place, we will have switched to a thread in the ARM
program space before calling arm_adjust_breakpoint_address.  As a
result, we now succeed in looking up the required symbols in
arm_pc_is_thumb, and so we never call arm_frame_is_thumb.

However, in the worst case scenario, if we did end up calling
arm_frame_is_thumb, as the current inferior should now be the ARM
inferior, the current frame should be an ARM frame, so we still should
not hit undefined behaviour.

I have added an assert to arm_frame_is_thumb.

gdb/mips: rewrite show_mask_address

This commit is similar to the previous commit, but in this case GDB is
actually relying on undefined behaviour.

Consider building GDB for all targets on x86-64/GNU-Linux, then doing
this:

  (gdb) show mips mask-address
  Zeroing of upper 32 bits of 64-bit addresses is auto.
  The 32 bit address mask is set automatically.  Currently disabled
  (gdb)

The 'show mips mask-address' command ends up in show_mask_address in
mips-tdep.c, and this function does this:

  mips_gdbarch_tdep *tdep
    = (mips_gdbarch_tdep *) gdbarch_tdep (target_gdbarch ());

Later we might pass TDEP to mips_mask_address_p.  However, in my
example above, on an x86-64 native target, the current target
architecture will be an x86-64 gdbarch, and the tdep field within the
gdbarch will be of type i386_gdbarch_tdep, not of type
mips_gdbarch_tdep, as a result the cast above was incorrect, and TDEP
is not pointing at what it thinks it is.

I also think the current output is a little confusing, we appear to
have two lines that show the same information, but using different
words.

The first line comes from calling deprecated_show_value_hack, while
the second line is printed directly from show_mask_address.  However,
both of these lines are printing the same mask_address_var value.  I
don't think the two lines actually adds any value here.

Finally, none of the text in this function is passed through the
internationalisation mechanism.

It would be nice to remove another use of deprecated_show_value_hack
if possible, so this commit does a complete rewrite of
show_mask_address.

After this commit the output of the above example command, still on my
x86-64 native target is:

    (gdb) show mips mask-address
    Zeroing of upper 32 bits of 64-bit addresses is "auto" (current architecture is not MIPS).

The 'current architecture is not MIPS' text is only displayed when the
current architecture is not MIPS.  If the architecture is mips then we
get the more commonly seen 'currently "on"' or 'currently "off"', like
this:

  (gdb) set architecture mips
  The target architecture is set to "mips".
  (gdb) show mips mask-address
  Zeroing of upper 32 bits of 64-bit addresses is "auto" (currently "off").
  (gdb)

All the text is passed through the internationalisation mechanism, and
we only call gdbarch_tdep when we know the gdbarch architecture is
bfd_arch_mips.

gdb/arm: move fetch of arm_gdbarch_tdep to a more inner scope

This is a small refactor to resolve an issue before it becomes a
problem in a later commit.

Move the fetching of an arm_gdbarch_tdep into a more inner scope
within two functions in arm-tdep.c.

The problem with the current code is that the functions in question
are used as the callbacks for two set/show parameters.  These set/show
parameters are available no matter the current architecture, but are
really about controlling an ARM architecture specific setting.  And
so, if I build GDB for all targets on an x86-64/GNU-Linux system, I
can still do this:

  (gdb) show arm fpu
  (gdb) show arm abi

After these calls we end up in show_fp_model and arm_show_abi
respectively, where we unconditionally do this:

  arm_gdbarch_tdep *tdep
    = (arm_gdbarch_tdep *) gdbarch_tdep (target_gdbarch ());

However, the gdbarch_tdep() result will only be a arm_gdbarch_tdep if
the current architecture is ARM, otherwise the result will actually be
of some other type.

This isn't actually a problem, as in both cases the use of tdep is
guarded by a later check that the gdbarch architecture is
bfd_arch_arm.

This commit just moves the call to gdbarch_tdep() after the
architecture check.

In a later commit gdbarch_tdep() will be able to spot when we are
casting the result to the wrong type, and this function will trigger
assertion failures if things are not fixed.

There should be not user visible changes after this commit.

[arm] Rename arm_cache_is_sp_register to arm_is_alternative_sp_register

All usages of this helper are really made to check if the register is
one of the alternative SP registers (MSP/MSP_S/MSP_NS/PSP/PSP_S/PSP_NS)
with the ARM_SP_REGNUM case being handled separately.

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

[gdb/python] Fix typo in test_python

Fix typo in ref_output_0 variable in test_python.

Tested by running the selftest on x86_64-linux with python 3.11.

[gdb/python] Fix python selftest with python 3.11

With python 3.11 I noticed:
...
$ gdb -q -batch -ex "maint selftest python"
Running selftest python.
Self test failed: self-test failed at gdb/python/python.c:2246
Ran 1 unit tests, 1 failed
...

In more detail:
...
(gdb) p output
$5 = "Traceback (most recent call last):\n  File \"<string>\", line 0, \
  in <module>\nKeyboardInterrupt\n"
(gdb) p ref_output
$6 = "Traceback (most recent call last):\n  File \"<string>\", line 1, \
  in <module>\nKeyboardInterrupt\n"
...

Fix this by also allowing line number 0.

Tested on x86_64-linux.

This should hopefully fix buildbot builder gdb-rawhide-x86_64.

[gdbsupport] Fix type of parallel_for_each_debug

When I changed the initialization of parallel_for_each_debug from 0 to false,
I forgot to change the type from int to bool.  Fix this.

Tested by rebuilding on x86_64-linux.

[gdb/symtab] Fix bad compile unit index complaint

I noticed this code in dw2_debug_names_iterator::next:
...
        case DW_IDX_compile_unit:
          /* Don't crash on bad data.  */
          if (ull >= per_bfd->all_comp_units.size ())
            {
              complaint (_(".debug_names entry has bad CU index %s"
                           " [in module %s]"),
                         pulongest (ull),
                         objfile_name (objfile));
              continue;
            }
          per_cu = per_bfd->get_cu (ull);
          break;
...

This code used to DTRT, before we started keeping both CUs and TUs in
all_comp_units.

Fix by using "per_bfd->all_comp_units.size () - per_bfd->tu_stats.nr_tus"
instead.

It's hard to produce a test-case for this, but let's try at least to trigger
the complaint somehow.  We start out by creating an exec with .debug_types and
.debug_names:
...
$ gcc -g ~/hello.c -fdebug-types-section
$ gdb-add-index -dwarf-5 a.out
...
and verify that we don't see any complaints:
...
$ gdb -q -batch -iex "set complaints 100" ./a.out
...

We look at the CU and TU table using readelf -w and conclude that we have
nr_cus == 6 and nr_tus == 1.

Now override ull in dw2_debug_names_iterator::next for the DW_IDX_compile_unit
case to 6, and we have:
...
$ gdb -q -batch -iex "set complaints 100" ./a.out
During symbol reading: .debug_names entry has bad CU index 6 [in module a.out]
...

After this, it still crashes because this code in
dw2_debug_names_iterator::next:
...
  /* Skip if already read in.  */
  if (m_per_objfile->symtab_set_p (per_cu))
    goto again;
...
is called with per_cu == nullptr.

Fix this by skipping the entry if per_cu == nullptr.

Now revert the fix and observe that the complaint disappears, so we've
confirmed that the fix is required.

A somewhat similar issue for .gdb_index in dw2_symtab_iter_next has been filed
as PR29367.

Tested on x86_64-linux, with native and target board cc-with-debug-names.

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

x86: replace wrong attributes on VCVTDQ2PH{X,Y}

A standalone (without SAE) StaticRounding attribute is meaningless, and
indeed all other similar insns have ATTSyntax there instead. I can only
assume this was some strange copy-and-paste mistake.

x86/Intel: correct AVX512F scatter insn element sizes

I clearly screwed up in 6ff00b5e12e7 ("x86/Intel: correct permitted
operand sizes for AVX512 scatter/gather") giving all AVX512F scatter
insns Dword element size. Update testcases (also their gather parts),
utilizing that there previously were two identical lines each (for no
apparent reason).

PR29390, DW_CFA_AARCH64_negate_ra_state vs. DW_CFA_GNU_window_save

PR 29390
binutils/
* dwarf.c (is_aarch64, DW_CFA_GNU_window_save_name): New.
(display_debug_frames): Use them.
(init_dwarf_regnames_aarch64): Set is_aarch64.
(init_dwarf_regnames_by_elf_machine_code): Clear is_aarch64.
(init_dwarf_regnames_by_bfd_arch_and_mach): Likewise.
gas/
* testsuite/gas/aarch64/pac_ab_key.d: Adjust expected output.
* testsuite/gas/aarch64/pac_negate_ra_state.d: Likewise.

PR29337, readelf CU/TU mixup in .gdb_index

Commit 244e19c79111 changed a number of variables in display_gdb_index
to count entries rather than words.

PR 29337
* dwarf.c (display_gdb_index): Correct use of cu_list_elements.

PR29370, infinite loop in display_debug_abbrev

The PR29370 testcase is a fuzzed object file with multiple
.trace_abbrev sections.  Multiple .trace_abbrev or .debug_abbrev
sections are not a violation of the DWARF standard.  The DWARF5
standard even gives an example of multiple .debug_abbrev sections
contained in groups.  Caching and lookup of processed abbrevs thus
needs to be done by section and offset rather than base and offset.
(Why base anyway?)  Or, since section contents are kept, by a pointer
into the contents.

PR 29370
* dwarf.c (struct abbrev_list): Replace abbrev_base and
abbrev_offset with raw field.
(find_abbrev_list_by_abbrev_offset): Delete.
(find_abbrev_list_by_raw_abbrev): New function.
(process_abbrev_set): Set list->raw and list->next.
(find_and_process_abbrev_set): Replace abbrev list lookup with
new function.  Don't set list abbrev_base, abbrev_offset or next.

binutils/dwarf.c: abbrev caching

I'm inclined to think that abbrev caching is counter-productive.  The
time taken to search the list of abbrevs converted to internal form is
non-zero, and it's easy to decode the raw abbrevs.  It's especially
silly to cache empty lists of decoded abbrevs (happens with zero
padding in .debug_abbrev), or abbrevs as they are displayed when there
is no further use of those abbrevs.  This patch stops caching in those
cases.

* dwarf.c (record_abbrev_list_for_cu): Add free_list param.
Put abbrevs on abbrev_lists here.
(new_abbrev_list): Delete function.
(process_abbrev_set): Return newly allocated list.  Move
abbrev base, offset and size checking to..
(find_and_process_abbrev_set): ..here, new function.  Handle
lookup of cached abbrevs here, and calculate start and end
for process_abbrev_set.  Return free_list if newly alloc'd.
(process_debug_info): Consolidate cached list lookup, new list
alloc and processing into find_and_process_abbrev_set call.
Free list when not cached.
(display_debug_abbrev): Similarly.

miscellaneous dwarf.c tidies

* dwarf.c: Leading and trailing whitespace fixes.
(free_abbrev_list): New function.
(free_all_abbrevs): Use the above.  Free cu_abbrev_map here too.
(process_abbrev_set): Print actual section name on error.
(get_type_abbrev_from_form): Add overflow check.
(free_debug_memory): Don't free cu_abbrev_map here..
(process_debug_info): ..or here.  Warn on another case of not
finding a neeeded abbrev.

PowerPC64: fix build error on 32-bit hosts

elf64-ppc.c:11673:33: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 3 has type ‘bfd_vma’ {aka ‘long long unsigned int’} [-Werror=format=]
11673 |   fprintf (stderr, "offset = %#lx:", stub_entry->stub_offset);
      |                              ~~~^    ~~~~~~~~~~~~~~~~~~~~~~~
      |                                 |              |
      |                                 |              bfd_vma {aka long long unsigned int}
      |                                 long unsigned int
      |                              %#llx

* elf64-ppc.c (dump_stub): Use BFD_VMA_FMT.

Wrap python_write_bytecode with HAVE_PYTHON ifdef

This commit fixes a build error on machines lacking python headers
and/or libraries.

Automatic date update in version.in

Handle Python 3.11 deprecation of PySys_SetPath and Py_SetProgramName

Python 3.11 deprecates PySys_SetPath and Py_SetProgramName.  The
PyConfig API replaces these and other functions.  This commit uses the
PyConfig API to provide equivalent functionality while also preserving
support for older versions of Python, i.e. those before Python 3.8.

A beta version of Python 3.11 is available in Fedora Rawhide.  Both
Fedora 35 and Fedora 36 use Python 3.10, while Fedora 34 still used
Python 3.9.  I've tested these changes on Fedora 34, Fedora 36, and
rawhide, though complete testing was not possible on rawhide due to
a kernel bug.  That being the case, I decided to enable the newer
PyConfig API by testing PY_VERSION_HEX against 0x030a0000.  This
corresponds to Python 3.10.

We could try to use the PyConfig API for Python versions as early as 3.8,
but I'm reluctant to do this as there may have been PyConfig related
bugs in earlier versions which have since been fixed.  Recent linux
distributions should have support for Python 3.10.  This should be
more than adequate for testing the new Python initialization code in
GDB.

Information about the PyConfig API as well as the motivation behind
deprecating the old interface can be found at these links:

https://github.com/python/cpython/issues/88279
https://peps.python.org/pep-0587/
https://docs.python.org/3.11/c-api/init_config.html

The v2 commit also addresses several problems that Simon found in
the v1 version.

In v1, I had used Py_DontWriteBytecodeFlag in the new initialization
code, but Simon pointed out that this global configuration variable
will be deprecated in Python 3.12.  This version of the patch no longer
uses Py_DontWriteBytecodeFlag in the new initialization code.
Additionally, both Py_DontWriteBytecodeFlag and Py_IgnoreEnvironmentFlag
will no longer be used when building GDB against Python 3.10 or higher.
While it's true that both of these global configuration variables are
deprecated in Python 3.12, it makes sense to disable their use for
gdb builds against 3.10 and higher since those are the versions for
which the PyConfig API is now being used by GDB.  (The PyConfig API
includes different mechanisms for making the same settings afforded
by use of the soon-to-be deprecated global configuration variables.)

Simon also noted that PyConfig_Clear() would not have be called for
one of the failure paths.  I've fixed that problem and also made the
rest of the "bail out" code more direct.  In particular,
PyConfig_Clear() will always be called, both for success and failure.

The v3 patch addresses some rebase conflicts related to module
initialization .  Commit 3acd9a692dd ("Make 'import gdb.events' work")
uses PyImport_ExtendInittab instead of PyImport_AppendInittab.  That
commit also initializes a struct for each module to import.  Both the
initialization and the call to were moved ahead of the ifdefs to avoid
having to replicate (at least some of) the code three times in various
portions of the ifdefs.

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

gdb/value.c: add several headers to the include list

Building GDB currently fails to build with libc++, because libc++ is
stricter about which headers "leak" entities they're not guaranteed
to support. The following headers have been added:

* `<iterator>`, to support `std::back_inserter`
* `<utility>`, to support `std::move` and `std::swap`
* `<vector>`, to support `std::vector`

Change-Id: Iaeb15057c5fbb43217df77ce34d4e54446dbcf3d

Don't stop all threads prematurely after first step of "step N"

In all-stop mode, when the target is itself in non-stop mode (like
GNU/Linux), if you use the "step N" (or "stepi/next/nexti N") to step
a thread a number of times:

 (gdb) help step
 step, s
 Step program until it reaches a different source line.
 Usage: step [N]
 Argument N means step N times (or till program stops for another reason).

... GDB prematurely stops all threads after the first step, and
doesn't re-resume them for the subsequent N-1 steps.  It's as if for
the 2nd and subsequent steps, the command was running with
scheduler-locking enabled.

This can be observed with the testcase added by this commit, which
looks like this:

 static pthread_barrier_t barrier;

 static void *
 thread_func (void *arg)
 {
   pthread_barrier_wait (&barrier);
   return NULL;
 }

 int
 main ()
 {
   pthread_t thread;
   int ret;

   pthread_barrier_init (&barrier, NULL, 2);

   /* We run to this line below, and then issue "next 3".  That should
      step over the 3 lines below and land on the return statement.  If
      GDB prematurely stops the thread_func thread after the first of
      the 3 nexts (and never resumes it again), then the join won't
      ever return.  */
   pthread_create (&thread, NULL, thread_func, NULL); /* set break here */
   pthread_barrier_wait (&barrier);
   pthread_join (thread, NULL);

   return 0;
 }

The test hangs and times out without the GDB fix:

 (gdb) next 3
 [New Thread 0x7ffff7d89700 (LWP 525772)]
 FAIL: gdb.threads/step-N-all-progress.exp: non-stop=off: target-non-stop=on: next 3 (timeout)

The problem is a core gdb bug.

When you do "step/stepi/next/nexti N", GDB internally creates a
thread_fsm object and associates it with the stepping thread.  For the
stepping commands, the FSM's class is step_command_fsm.  That object
is what keeps track of how many steps are left to make.  When one step
finishes, handle_inferior_event calls stop_waiting and returns, and
then fetch_inferior_event calls the "should_stop" method of the event
thread's FSM.  The implementation of that method decrements the
steps-left counter.  If the counter is 0, it returns true and we
proceed to presenting the stop to the user.  If it isn't 0 yet, then
the method returns false, indicating to fetch_inferior_event to "keep
going".

Focusing now on when the first step finishes -- we're in "all-stop"
mode, with the target in non-stop mode.  When a step finishes,
handle_inferior_event calls stop_waiting, which itself calls
stop_all_threads to stop everything.  I.e., after the first step
completes, all threads are stopped, before handle_inferior_event
returns.  And after that, now in fetch_inferior_event, we consult the
thread's thread_fsm::should_stop, which as we've seen, for the first
step returns false -- i.e., we need to keep_going for another step.
However, since the target is in non-stop mode, keep_going resumes
_only_ the current thread.  All the other threads remain stopped,
inadvertently.

If the target is in non-stop mode, we don't actually need to stop all
threads right after each step finishes, and then re-resume them again.
We can instead defer stopping all threads until all the steps are
completed.

So fix this by delaying the stopping of all threads until after we
called the FSM's "should_stop" method.  I.e., move it from
stop_waiting, to handle_inferior_events's callers,
fetch_inferior_event and wait_for_inferior.

New test included.  Tested on x86-64 GNU/Linux native and gdbserver.

Change-Id: Iaad50dcfea4464c84bdbac853a89df92ade6ae01

Re: opcodes/arc: Implement style support in the disassembler

* arc-dis.c (print_insn_arc): Fix thinko.

gas/symbols: introduce md_resolve_symbol

Assuming GMSD is a special operand, marked as O_md1, the code:

    .set VREG, GMSD
    .set REG, VREG
    extsw REG, 2

...fails upon attempts to resolve the value of the symbol. This happens
since machine-dependent values are not handled in the giant op switch.
We introduce a custom md_resolve_symbol macro; the ports can use this
macro to customize the behavior when resolve_symbol_value hits O_md
operand.

Automatic date update in version.in

x86: Disallow invalid relocations against protected symbols

Since glibc 2.36 will issue warnings for copy relocation against
protected symbols and non-canonical reference to canonical protected
functions, change the linker to always disallow such relocations.

bfd/

* elf32-i386.c (elf_i386_scan_relocs): Remove check for
elf_has_indirect_extern_access.
* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
(elf_x86_64_relocate_section): Remove check for
elf_has_no_copy_on_protected.
* elfxx-x86.c (elf_x86_allocate_dynrelocs): Check for building
executable instead of elf_has_no_copy_on_protected.
(_bfd_x86_elf_adjust_dynamic_symbol): Disallow copy relocation
against non-copyable protected symbol.
* elfxx-x86.h (SYMBOL_NO_COPYRELOC): Remove check for
elf_has_no_copy_on_protected.

ld/

* testsuite/ld-i386/i386.exp: Expect linker error for PR ld/17709
test.
* testsuite/ld-i386/pr17709.rd: Removed.
* testsuite/ld-i386/pr17709.err: New file.
* testsuite/ld-x86-64/pr17709.rd: Removed.
* testsuite/ld-x86-64/pr17709.err: New file.
* testsuite/ld-x86-64/pr28875-func.err: Updated.
* testsuite/ld-x86-64/x86-64.exp: Expect linker error for PR
ld/17709 test.  Add tests for function pointer against protected
function.

x86: Make protected symbols local for -shared

Call _bfd_elf_symbol_refs_local_p with local_protected==true.  This has
2 noticeable effects for -shared:

* GOT-generating relocations referencing a protected data symbol no
  longer lead to a GLOB_DAT (similar to a hidden symbol).
* Direct access relocations (e.g. R_X86_64_PC32) no longer has the
  confusing diagnostic below.

    __attribute__((visibility("protected"))) void *foo() {
      return (void *)foo;
    }

    // gcc -fpic -shared -fuse-ld=bfd
    relocation R_X86_64_PC32 against protected symbol `foo' can not be used when making a shared object

The new behavior matches arm, aarch64 (commit
83c325007c5599fa9b60b8d5f7b84842160e1d1b), and powerpc ports, and other
linkers: gold and ld.lld.

Note: if some code tries to use direct access relocations to take the
address of foo, the pointer equality will break, but the error should be
reported on the executable link, not on the innocent shared object link.
glibc 2.36 will give a warning at relocation resolving time.

With this change, `#define elf_backend_extern_protected_data 1` is no
longer effective.  Just remove it.

Remove the test "Run protected-func-1 without PIE" since -fno-pic
address taken operation in the executable doesn't work with protected
symbol in a shared object by default.  Similarly, remove
protected-data-1a and protected-data-1b.  protected-data-1b can be made
working by removing HAVE_LD_PIE_COPYRELOC from GCC
(https://sourceware.org/pipermail/gcc-patches/2022-June/596678.html).

Reformat gdbarch-components.py to fix deviations

Reformat to make sure we have a clean file with no deviations
from the expected python code format.

[AArch64] MTE corefile support

Teach GDB how to dump memory tags for AArch64 when using the gcore command
and how to read memory tag data back from a core file generated by GDB
(via gcore) or by the Linux kernel.

The format is documented in the Linux Kernel documentation [1].

Each tagged memory range (listed in /proc/<pid>/smaps) gets dumped to its
own PT_AARCH64_MEMTAG_MTE segment. A section named ".memtag" is created for each
of those segments when reading the core file back.

To save a little bit of space, given MTE tags only take 4 bits, the memory tags
are stored packed as 2 tags per byte.

When reading the data back, the tags are unpacked.

I've added a new testcase to exercise the feature.

Build-tested with --enable-targets=all and regression tested on aarch64-linux
Ubuntu 20.04.

[1] Documentation/arm64/memory-tagging-extension.rst (Core Dump Support)

[AArch64] Support AArch64 MTE memory tag dumps in core files

The Linux kernel can dump memory tag segments to a core file, one segment
per mapped range. The format and documentation can be found in the Linux
kernel tree [1].

The following patch adjusts bfd and binutils so they can handle this new
segment type and display it accordingly. It also adds code required so GDB
can properly read/dump core file data containing memory tags.

Upon reading, each segment that contains memory tags gets mapped to a
section named "memtag". These sections will be used by GDB to lookup the tag
data. There can be multiple such sections with the same name, and they are not
numbered to simplify GDB's handling and lookup.

There is another patch for GDB that enables both reading
and dumping of memory tag segments.

Tested on aarch64-linux Ubuntu 20.04.

[1] Documentation/arm64/memory-tagging-extension.rst (Core Dump Support)

[AArch64] Fix testcase compilation failure

Newer distros carry newer headers that contains MTE definitions.  Account
for that fact in the MTE testcases (gdb.arch/aarch64-mte.exp) and define
constants conditionally to prevent compilation failures.

ld: Pass -nostdlib to compiler with -r

Pass -nostdlib to compiler with -r to avoid unnecessary .o file and
libraries.

PR ld/29377
* testsuite/ld-elf/linux-x86.exp: Pass -nostdlib with -r.

x86: Properly check invalid relocation against protected symbol

Only check invalid relocation against protected symbol defined in shared
object.

bfd/

PR ld/29377
* elf32-i386.c (elf_i386_scan_relocs): Only check invalid
relocation against protected symbol defined in shared object.
* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.

ld/

PR ld/29377
* testsuite/ld-elf/linux-x86.exp: Run PR ld/29377 tests.
* testsuite/ld-elf/pr29377a.c: New file.
* testsuite/ld-elf/pr29377b.c: Likewise.

Automatic date update in version.in

gprofng: link libgprofng.so against -lpthread

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

PR gprofng/29364
* src/Makefile.am (libgprofng_la_LIBADD): Add -lpthread.
* src/Makefile.in: Rebuild.

gprofng: fix regression in build and a race condition in autoreconf

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

PR gprofng/29338
* libcollector/configure.ac (AC_CONFIG_HEADERS): Fix a race condition.
* libcollector/configure: Rebuild.
* libcollector/Makefile.in: Rebuild.
* common/config.h.in: Rebuild.
* common/lib-config.h.in: Created by autoreconf.

Add gdb.free_objfile event registry

Currently, Python code can use event registries to detect when gdb
loads a new objfile, and when gdb clears the objfile list.  However,
there's no way to detect the removal of an objfile, say when the
inferior calls dlclose.

This patch adds a gdb.free_objfile event registry and arranges for an
event to be emitted in this case.

Put gdb.base/bt-on-fatal-signal.exp GDB cores in output dir

I noticed that gdb.base/bt-on-fatal-signal.exp was contributing four
core files to the count of unexpected core files:

 $ make check TESTS="gdb.base/bt-on-fatal-signal.exp"

 === gdb Summary ===

 # of unexpected core files      4
 # of expected passes            21

These are GDB core dumps.  They are expected, however, because the
whole point of the testcase is to crash GDB with a signal.

Make GDB change its current directory to the output dir just before
crashing, so that the core files end up there.  The result is now:

 === gdb Summary ===

 # of expected passes            25

and:

 $ find . -name "core.*"
 ./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1676506.nelson.1657727692
 ./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1672585.nelson.1657727671
 ./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1674833.nelson.1657727683
 ./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1673709.nelson.1657727676

(Note the test is skipped at the top if on a remote host.)

Change-Id: I79e4fb2e91330279c7a509930b1952194a72e85a

Remove array typedef assumption for Ada

Currently the Ada code assumes that it can distinguish between a
multi-dimensional array and an array of arrays by looking for an
intervening typedef -- that is, for an array of arrays, there will be
a typedef wrapping the innermost array type.

A recent compiler change removes this typedef, which causes a gdb
failure in the internal AdaCore test suite.

This patch handles this case by checking whether the array type in
question has a name.

Remove manual lifetime management from cli_interp

cli_interp manually manages its cli_out object.  This patch changes it
to use a unique_ptr, and also changes cli_uiout to be a private
member.

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.