Automatic date update in version.in

Use bool for evregpy_no_listeners_p

I noticed that evregpy_no_listeners_p should return a bool.  This
patch makes this change.  I'm checking it in.

asan: heap buffer overflow in _bfd_mips_elf_section_from_shdr

* elfxx-mips.c (_bfd_mips_elf_section_from_shdr): Sanity check
intopt.size and remaining bytes in section for reginfo.

Re: ubsan: undefined shift in frag_align_code

This one needs the same fix too.

* config/tc-i386.h (MAX_MEM_FOR_RS_ALIGN_CODE): Avoid signed
integer overflow.

[gdb] Fix warning in foreach_arch selftests

When running the selftests, I run into:
...
$ gdb -q -batch -ex "maint selftest"
  ...
Running selftest execute_cfa_program::aarch64:ilp32.
warning: A handler for the OS ABI "GNU/Linux" is not built into this
configuration of GDB.  Attempting to continue with the default aarch64:ilp32
settings.
...
and likewise for execute_cfa_program::i8086 and
execute_cfa_program::ia64-elf32.

The warning can easily be reproduced outside the selftests by doing:
...
$ gdb -q -batch -ex "set arch aarch64:ilp32"
...
and can be prevented by first doing "set osabi none".

Fix the warning by setting osabi to none while doing selftests that iterate
over all architectures.

This causes a regression in the print_one_insn selftests for the ARC
architecture.

The problem is pre-existing, and can be demonstrated (already without this
patch) using:
...
$ gdb -q -batch -ex "set osabi none" -ex "maint selftest print_one_insn::A6"
Running selftest print_one_insn::A6.
Self test failed: Cannot access memory at address 0x0
Ran 1 unit tests, 1 failed
$
...

For ARC, we use the generic case in print_one_insn_test, containing this code:
...
       int kind = gdbarch_breakpoint_kind_from_pc (gdbarch, &pc);
       ...
       insn = gdbarch_sw_breakpoint_from_kind (gdbarch, kind, &bplen);
...

The problem is that with osabi linux we trigger:
...
static int
arc_linux_breakpoint_kind_from_pc (struct gdbarch *gdbarch, CORE_ADDR *pcptr)
{
  return trap_size;
}
...
but with osabi none:
...
arc_breakpoint_kind_from_pc (struct gdbarch *gdbarch, CORE_ADDR *pcptr)
{
  size_t length_with_limm = gdb_insn_length (gdbarch, *pcptr);
...
which needs access to memory, and will consequently fail.

Fix this in print_one_insn_test, in the default case, by iterating over
supported osabi's to makes sure we trigger arc_linux_breakpoint_kind_from_pc
which will give us a usable instruction to disassemble.

Tested on x86_64-linux.

Revert "[gdb] Fix warning in foreach_arch selftests"

This reverts commit fc18b1c5afd ("[gdb] Fix warning in foreach_arch
selftests").

The commit introduced regressions for an --enable-targets=all build:
...
Running selftest print_one_insn::A6.^M
Self test failed: Cannot access memory at address 0x0^M
...
and while investigating those I realized that the commit fc18b1c5afd
complicates things by trying to set the current osabi.

So, revert the patch in preparation for a simpler solution.

Tested on x86_64-linux.

x86: exclude certain ISA extensions from v3/v4 ISA

Like TBM and LWP, XOP and FMA4 also shouldn't be included in v3.

Like AVX512-4VNNIW, AVX512-4FMAPS also shouldn't be included in v4.

gdb: LoongArch: Remove nonportable #include

Don't use gregset.h in *-tdep.c since it's not usable on
hosts that don't have <sys/procfs.h>.  It's not needed by
this file, and should only be needed by *-nat.c files.

Re: asan: mips_gprel_reloc segfault

Similarly for the elf mips support.

* elf32-mips.c (mips_elf_final_gp): Don't segfault on symbols
in any of the bfd_is_const_section sections.
* elf64-mips.c (mips_elf64_final_gp): Likewise.
* elfn32-mips.c (mips_elf_final_gp): Likewise.

asan: mips_gprel_reloc segfault

Not just the undefined section has a NULL owner, the absolute section
has too.  Which means we can't find output_bfd for __gp.  Also, may as
well test directly for output_bfd == NULL.

* coff-mips.c (mips_gprel_reloc): Don't segfault on any of
bfd_is_const_section sections.

Automatic date update in version.in

[gdb/testsuite] Detect change instead of init in gdb.mi/mi-var-block.exp

On openSUSE Tumbleweed with target board unix/-m32, I run into:
...
PASS: gdb.mi/mi-var-block.exp: step at do_block_test 2
Expecting: ^(-var-update \*[^M
]+)?(\^done,changelist=\[{name="foo",in_scope="true",type_changed="false",has_more="0"},
{name="cb",in_scope="true",type_changed="false",has_more="0"}\][^M
]+[(]gdb[)] ^M
[ ]*)
-var-update *^M
^done,changelist=[{name="foo",in_scope="true",type_changed="false",has_more="0"}]^M
(gdb) ^M
FAIL: gdb.mi/mi-var-block.exp: update all vars: cb foo changed (unexpected output)
...

The problem is that the test-case attempts to detect a change in the cb
variable caused by this initialization:
...
void
do_block_tests ()
{
  int cb = 12;
...
but that only works if the stack location happens to be unequal to 12 before
the initialization.

Fix this by first initializing to 0, and then changing the value to 12:
...
-  int cb = 12;
+  int cb = 0;
+  cb = 12;
...
and detecting that change.

Tested on x86_64-linux.

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

Rearrange and slightly reword the "Location Specification" section

This rearranges and changes the wording of the "Location
Specification" section of the GDB manual in minor ways.

ODR warning for "main"

"main" is redeclared with a different type in maint.c.  I think this
might have come from my first gdb patch, many many years ago.  While I
wonder if this profiling code is actually useful at all any more, in
the meantime it's simple to fix the declaration.

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

ODR warnings for "struct coff_symbol"

"struct coff_symbol" is defined in multiple .c files, causing ODR
warnings.  This patch renames just the xcoffread.c type.

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

ODR warnings for "struct insn_decode_record_t"

"struct insn_decode_record_t" is defined in multiple .c files, causing
ODR warnings.  This patch renames the types, and removes the use of
"typedef" here -- this is a C-ism that's no longer needed.

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

ODR warnings for "struct insn_info"

"struct insn_info" is defined in multiple .c files, causing ODR
warnings.  This patch renames the type in z80-tdep.c, leaving the
other one alone.

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

ODR warnings from overlay constants

Some overlay-related constants are duplicated in z80-tdep.c, causing
ODR warnings.  This patch renames just the z80-specific ones.

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

ODR warning for "enum string_repr_result"

"enum string_repr_result" is defined in multiple .c files, causing ODR
warnings.  This patch renames the types.

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

ODR warning for "struct find_targ_sec_arg"

"struct find_targ_sec_arg" is defined in multiple .c files, causing
ODR warnings.  This patch renames the types.

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

ODR warning for "struct stack_item"

"struct stack_item" is defined in multiple .c files, causing ODR
warnings.  This patch renames these types.

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

ODR warning for "struct instruction_type"

"struct instruction_type" is defined in multiple .c files, causing an
ODR warning.  This patch renames the types.

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

ODR warning for struct ext_link_map

This renames the solib-dsbt.c copy of "struct ext_link_map" to avoid
an ODR warning.

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

ODR warning for struct field_info

This renames one of the instance of "struct field_info" to avoid an
ODR warning.

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

ODR warnings for struct nextfield

"struct nextfield" is defined in multiple places in GDB.  This patch
renames just the stabs one, leaving the DWARF one untouched.

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

ODR warnings for struct symloc

"struct symloc" is defined in multiple spots in gdb, causing ODR
warnings.  This patch renames these.

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

Fix ODR warning in observable.h

observable.h triggers an ODR warning because this line:

    extern observable<struct target_ops */* target */> target_changed;

... may be the only declaration of "struct target_ops" in scope
(depending on the particular .c file) -- and this declares it in a
namespace, resulting in confusion.

This patch fixes the problem by adding a forward declaration.

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

gdb: LoongArch: Implement the software_single_step gdbarch method

When execute the following command on LoongArch:

  make check-gdb TESTS="gdb.base/branch-to-self.exp"

there exist the following failed testcases:

  FAIL: gdb.base/branch-to-self.exp: single-step: si (timeout)
  FAIL: gdb.base/branch-to-self.exp: break-cond: side=host: continue to breakpoint: continue to break (timeout)
  FAIL: gdb.base/branch-to-self.exp: break-cond: side=host: p counter (timeout)

Implement the software_single_step gdbarch method to decode the current
branch instruction and determine the address of the next instruction on
LoongArch to fix the above failed testcases.

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

gdb: Do not add empty sections to the section map

From: Ulrich Weigand <ulrich.weigand@de.ibm.com>

build_objfile_section_table () creates four synthetic sections per
objfile, which are collected by update_section_map () and passed to
std::sort ().  When there are a lot of objfiles, for example, when
debugging JITs, the presence of these sections slows down the sorting
significantly.

The output of update_section_map () is used by find_pc_section (),
which can never return any of these sections: their size is 0, so they
cannot be accepted by bsearch_cmp ().

Filter them (and all the other empty sections) out in
insert_section_p (), which is used only by update_section_map ().

Fix a new warning on Cygwin

> ../../gdb/windows-nat.c: In function ‘windows_solib* windows_make_so(const char*, LPVOID)’:
> ../../gdb/windows-nat.c:714:12: error: declaration of ‘char name [512]’ shadows a parameter [-Werror=shadow=compatible-local]
>   714 |       char name[SO_NAME_MAX_PATH_SIZE];
>       |            ^~~~
> ../../gdb/windows-nat.c:655:30: note: shadowed declaration is here
>   655 | windows_make_so (const char *name, LPVOID load_addr)
>       |                  ~~~~~~~~~~~~^~~~

Fix Cygwin build after 85b25bd9

Fix Cygwin build after 85b25bd9 ("Simplify windows-nat.c solib handling").

Fix Cygwin build after 0578e87f

Fix Cygwin build after 0578e87f ("Remove some globals from
nat/windows-nat.c").  Update code under ifdef __CYGWIN__ for globals
moved to members of struct windows_process_info.

Fix Cygwin build after fcab5839

Fix Cygwin build after fcab5839 ("Implement pid_to_exec_file for Windows
in gdbserver"). That change moves code from gdb/windows-nat.c to
gdb/nat/windows-nat.c, but doesn't add the required typedefs and
includes for parts of that code under ifdef __CYGWIN__.

Re: ubsan: signed integer overflow in atof_generic

Oops.

* atof-generic.c: Include limits.h.

ubsan: signed integer overflow in atof_generic

Fix the signed overflows by using unsigned variables and detect
overflow at BUG! comment.

* atof-generic.c (atof_generic): Avoid signed integer overflow.
Return ERROR_EXPONENT_OVERFLOW if exponent overflows a long.

asan: uninit write _bfd_ecoff_write_object_contents

* ecoff.c (_bfd_ecoff_write_object_contents): zalloc reloc_buff.

asan: null deref in coff_write_relocs

* coffcode.h (coff_write_relocs): Don't deref NULL howto.

ubsan: undefined shift in frag_align_code

* frags.c (MAX_MEM_FOR_RS_ALIGN_CODE): Avoid signed integer
overflow.

gas read_a_source_file #APP processing

This fixes some horrible code using do_scrub_chars.  What we had ran
text through do_scrub_chars twice, directly in read_a_source_file and
again via the input_scrub_include_sb call.  That's silly, and since
do_scrub_chars is a state machine, possibly wrong.  More silliness is
evident in the temporary malloc'd buffer for do_scrub_chars output,
which should have been written directly to sbuf.

So, get rid of the do_scrub_chars call and support functions, leaving
scrubbing to input_scrub_include_sb.  I did wonder about #NO_APP
overlapping input_scrub_next_buffer buffers, but that should only
happen if the string starts in one file and finishes in another.

* read.c (scrub_string, scrub_string_end): Delete.
(scrub_from_string): Delete.
(read_a_source_file): Rewrite #APP processing.

sb_scrub_and_add_sb not draining input string buffer

It is possible for sb_scrub_and_add_sb to not consume all of the input
string buffer.  If this happens for reasons explained in the comment,
do_scrub_chars can leave pointers to the string buffer for the next
call.  This patch fixes that by ensuring the input is drained.  Note
that the behaviour for an empty string buffer is also changed,
avoiding another do_scrub_chars bug where empty input and single char
sized output buffers could result in a write past the end of the
output.

sb.c (sb_scrub_and_add_sb): Loop until all of input sb is
consumed.

asan: heap buffer overflow in dwarf2_directive_filename

Seen with .file 4294967289 "xxx.c"

* dwarf2dbg.c (assign_file_to_slot): Catch more cases of integer
overflow.  Make param i an unsigned int.

asan: NULL deref in scan_unit_for_symbols

Since commit b43771b045 it has been possible to look up addresses
that match a unit with errors, since ranges are added to a trie while
the unit is being parsed.  On error, parse_comp_unit leaves
first_child_die_ptr NULL which results in a NULL info_ptr being passed
to scan_unit_for_symbols.  Fix this by setting unit->error.

Also wrap some overlong lines, and fix some formatting errors.

* dwarf2.c: Formatting.
(parse_comp_unit): Set unit->error on err_exit path.

Automatic date update in version.in

[gdb] Fix warning in foreach_arch selftests

When running the selftests, I run into:
...
$ gdb -q -batch -ex "maint selftest"
  ...
Running selftest execute_cfa_program::aarch64:ilp32.
warning: A handler for the OS ABI "GNU/Linux" is not built into this
configuration of GDB.  Attempting to continue with the default aarch64:ilp32
settings.
...
and likewise for execute_cfa_program::i8086 and
execute_cfa_program::ia64-elf32.

The warning can easily be reproduced outside the selftests by doing:
...
$ gdb -q -batch -ex "set arch aarch64:ilp32"
...
and can be prevented by first doing "set osabi none".

Fix the warning by setting osabi to none while doing selftests that iterate
over all architectures.

Tested on x86_64-linux.

Add gdb.current_language and gdb.Frame.language

This adds the gdb.current_language function, which can be used to find
the current language without (1) ever having the value "auto" or (2)
having to parse the output of "show language".

It also adds the gdb.Frame.language, which can be used to find the
language of a given frame.  This is normally preferable if one has a
Frame object handy.

[arm] Don't use special treatment for PC

In an exception frame the PC register is extracted from the stack
just like other base registers, so there is no need for a special
treatment.

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

[arm] Add support for FPU registers in prologue unwinder

The prologue unwinder had support for FPU registers, but only to
calculate the correct offset on the stack, the values were not saved.

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

[arm] d0..d15 are 64-bit each, not 32-bit

When unwinding the stack, the floating point registers d0 to d15
need to be handled as double words, not words.

Only the first 8 registers have been confirmed fixed with this patch
on a STM32F407-DISC0 board, but the upper 8 registers on Cortex-M33
should be handled in the same way.

The test consisted of running a program compiled with float-abi=hard.
In the main function, a function taking a double as an argument was
called. After the function call, a hardware timer was used to
trigger an interrupt.

In the debug session, a breakpoint was set in the function called
from main to verify the content of the registers using "info float"
and another breakpoint in the interrupt handler was used to check
the same registers using "info float" on frame 2 (the frame just
before the dummy frame created for the signal handler in gdb).

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

[arm] Cleanup: use hex for offsets

Changed offset from decimal to hex to match architecture reference
manual terminology and keep coherency with the rest of the code.

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

gdb:csky save fpu and vdsp info to struct csky_gdbarch_tdep

First, add three variables fpu_abi, fpu_hardfp and vdsp_version
to csky_gdbarch_tdep. They will be initialized from info.abfd in
cskg_gdbarch_init.

Now, they are just used to find a candidate among the list of pre-declared
architectures

Later, they will be used in gdbarch_return_value and gdbarch_push_dummy_call
for funtions described below:
fpu_abi: to check if the bfd is using VAL_CSKY_FPU_ABI_HARD or
VAL_CSKY_FPU_ABI_SOFT
fpu_hardfp: to check if the bfd is using VAL_CSKY_FPU_HARDFP_SINGLE
or VAL_CSKY_FPU_HARDFP_DOUBLE
vdsp_version: to check if a function is returned with CSKY_VRET_REGNUM

Re: use libiberty xmalloc in bfd/doc/chew.c

We can't use libiberty.a in chew.  libiberty is a host library, chew
a build program.  Partly revert commit 7273d78f3f7a, instead define
local versions of the libiberty functions.  ansidecl.h also isn't
needed.

* doc/chew.c: Don't include libiberty.h or ansidecl.h.
(xmalloc, xrealloc, xstrdup): New functions.
* doc/local.mk (LIBIBERTY): Don't define or use.
* Makefile.in: Regenerate.

Automatic date update in version.in

x86: Properly handle IFUNC function pointer reference

Update

commit 68c4956b1401de70173848a6bdf620cb42fa9358
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Apr 26 09:08:54 2022 -0700

    x86: Properly handle function pointer reference

to properly handle IFUNC function pointer reference.  Since IFUNC symbol
value is only known at run-time, set pointer_equality_needed for IFUNC
function pointer reference in PDE so that it will be resolved to its PLT
entry directly.

bfd/

PR ld/29216
* elf32-i386.c (elf_i386_scan_relocs): Set pointer_equality_needed
for IFUNC function pointer reference in PDE.
* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.

ld/

PR ld/29216
* testsuite/ld-ifunc/ifunc.exp: Run PR ld/29216 test.
* testsuite/ld-ifunc/pr29216.c: New file.

i386: Ajdust more tests for opcodes/i386: remove trailing whitespace

This fixes:

FAIL: Build ifunc-1a with -z ibtplt
FAIL: Build ifunc-1a with PIE -z ibtplt
FAIL: Build libno-plt-1b.so
FAIL: No PLT (dynamic 1a)
FAIL: No PLT (dynamic 1b)
FAIL: No PLT (dynamic 1c)
FAIL: No PLT (static 1d)
FAIL: No PLT (PIE 1e)
FAIL: No PLT (PIE 1f)
FAIL: No PLT (PIE 1g)
FAIL: No PLT (dynamic 1h)
FAIL: No PLT (dynamic 1i)
FAIL: No PLT (static 1j)

* ld-i386/libno-plt-1b.dd: Remove trailing whitespaces.
* ld-i386/no-plt-1a.dd: Likewise.
* ld-i386/no-plt-1b.dd: Likewise.
* ld-i386/no-plt-1c.dd: Likewise.
* ld-i386/no-plt-1d.dd: Likewise.
* ld-i386/no-plt-1e.dd: Likewise.
* ld-i386/no-plt-1f.dd: Likewise.
* ld-i386/no-plt-1g.dd: Likewise.
* ld-i386/no-plt-1h.dd: Likewise.
* ld-i386/no-plt-1i.dd: Likewise.
* ld-i386/no-plt-1j.dd: Likewise.
* ld-i386/plt-main-ibt.dd: Likewise.
* ld-i386/plt-pie-ibt.dd: Likewise.

Use unique_ptr for objfiles

A while back, I changed objfiles to be held via a shared_ptr.  The
idea at the time was that this was a step toward writing to the index
cache in the background, and this would let gdb keep a reference alive
to do so.  However, since then we've rewritten the DWARF reader, and
the new index can do this without requiring a shared pointer -- in
fact there are patches pending to implement this.

This patch switches objfile management to unique_ptr, which makes more
sense now.

Regression tested on x86-64 Fedora 34.

gdb/testsuite: fixup common-block.exp for intel compilers

The order in which the variables in info common and info locals are
displayed is compiler (and dwarf) dependent.  While all symbols should
be displayed the order is not fixed.

I added a gdb_test_multiple that lets ifx and ifort pass in cases where
only the order differs.

gdb, testsuite, fortran: fixup mixed-lang-stack for Intel/LLVM compilers

When value-printing a pointer within GDB by default GDB will look for
defined symbols residing at the address of the pointer.  For the given
test the Intel/LLVM compiler stacks both display a symbol associated
with a printed pointer while the gnu stack does not.  This leads to
failures in the test when running the test with CC_FOR_TARGET='clang'
CXX_FOR_TARGET='clang' F90_FOR_TARGET='flang'"

  (gdb) b 37
  (gdb) r
  (gdb) f 6
  (gdb) info args
  a = 1
  b = 2
  c = 3
  d = 4 + 5i
  f = 0x419ed0 "abcdef"
  g = 0x4041a0 <.BSS4>

or CC_FOR_TARGET='icx' CXX_FOR_TARGET='icpx' F90_FOR_TARGET='ifx'"

  (gdb) b 37
  (gdb) r
  (gdb) f 6
  (gdb) info args
  a = 1
  b = 2
  c = 3
  d = 4 + 5i
  f = 0x52eee0 "abcdef"
  g = 0x4ca210 <mixed_func_1a_$OBJ>

For the compiled binary the Intel/LLVM compilers both decide to move the
local variable g into the .bss section of their executable.  The gnu
stack will keep the variable locally on the stack and not define a
symbol for it.

Since the behavior for Intel/LLVM is actually expected I adapted the
testcase at this point to be a bit more allowing for other outputs.
I added the optional "<SYMBOLNAME>" to the regex testing for g.

The given changes reduce the test fails for Intel/LLVM stack by 4 each.

gdb, testsuite, fortran: fix double free in mixed-lang-stack.exp

While testing mixed-lang-stack I realized that valgrind actually
complained about a double free in the test.

   All done
  ==2503051==
  ==2503051== HEAP SUMMARY:
  ==2503051==     in use at exit: 0 bytes in 0 blocks
  ==2503051==   total heap usage: 26 allocs, 27 frees, 87,343 bytes allocated
  ==2503051==
  ==2503051== All heap blocks were freed -- no leaks are possible
  ==2503051==
  ==2503051== For lists of detected and suppressed errors, rerun with: -s
  ==2503051== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

Reason for this is that in mixed-lang-stack.cpp in mixed_func_1f an
object "derived_type obj" goes on the stack which is then passed-by-value
(so copied) to mixed_func_1g.  The default copy-ctor will be called but,
since derived_type contains a heap allocated string and the copy
constructor is not implemented it will only be able to shallow copy the
object.  Right after each of the functions the object gets freed - on the
other hand the d'tor of derived_type actually is implemented and calls
free on the heap allocated string which leads to a double free.  Instead
of obeying the rule of 3/5 I just got rid of all that since it does not
serve the test.  The string is now just a const char* = ".." object
member.

testsuite, fortran: allow additional completions in module.exp

For ifort, ifx, and flang the tests "complete modm" and "complete
modmany" fail.  This is because all three emit additional completion
suggestions.  These additional suggestions have their origin in symbols
emitted by the compilers which can also be completed from the respective
incomplete word (modm or modmany).  For this specific example gfortran
does not emit any additional symbols.

For example, in this test the linkage name for var_a in ifx is
"modmany_mp_var_a_" while gfortran uses "__modmany_MOD_var_a" instead.
Since modmany_mp_var_a can be completed from modm and also modmany they
will get displayed, while gfortran's symbol starts with "__" and thus will
be ignored (it cannot be a completion of a word starting with "m").

Similar things happen in flang and ifort.  Some example output is shown
below:

FLANG
  (gdb) complete p modm
  p modmany
  p modmany::var_a
  p modmany::var_b
  p modmany::var_c
  p modmany::var_i
  p modmany_

IFX/IFORT
  (gdb) complete p modm
  p modmany
  p modmany._
  p modmany::var_a
  p modmany::var_b
  p modmany::var_c
  p modmany::var_i
  p modmany_mp_var_a_
  p modmany_mp_var_b_
  p modmany_mp_var_c_
  p modmany_mp_var_i_

GFORTRAN
  (gdb) complete p modm
  p modmany
  p modmany::var_a
  p modmany::var_b
  p modmany::var_c
  p modmany::var_i

I want to emphasize: for Fortran (and also C/C++) the complete command
does not actually check whether its suggestions make sense - all it does
is look for any symbol (in the minimal symbols, partial symbols etc.)
that a given substring can be completed to (meaning that the given substring
is the beginning of the symbol).  One can easily produce a similar
output for the gfortran compiled executable.  For this look at the
slightly modified "complete p mod" in gfortran:

  (gdb) complete p mod
  p mod1
  p mod1::var_const
  ...
  p mod_1.c
  p modcounter
  p mode_t
  p modf
  ...
  p modify_ldt
  p modmany
  p modmany::var_a
  p modmany::var_b
  p modmany::var_c
  p modmany::var_i
  p module
  p module.f90
  p module_entry
  p moduse
  p moduse::var_x
  p moduse::var_y

Many of the displayed symbols do not actually work with print:

  (gdb) p mode_t
  Attempt to use a type name as an expression
  (gdb) p mod_1.c
  No symbol "mod_1" in current context.
  (gdb)

I think that in the given test the output for gfortran only looks nice
"by chance" rather than is actually expected.  Expected is any output
that also contains the completions

  p modmany

  p modmany::var_a
  p modmany::var_b
  p modmany::var_c
  p modmany::var_i

while anythings else can be displayed as well (depending on the
compiler and its emitted symbols).

This, I'd consider all three outputs as valid and expected - one is just
somewhat lucky that gfortran does not produce any additional symbols that
got matched.

The given patch improves test performance for all three compilers
by allowing additional suggested completions inbetween and after
the two given blocks in the test.  I did not allow additional print
within the modmany_list block since the output is ordered alphabetically
and there should normally not appear any additional symbols there.

For flang/ifx/ifort I each see 2 failures less (which are exactly the two
complete tests).

As a side note and since I mentioned C++ in the beginning: I also tried
the gdb.cp/completion.exp.  The output seems a bit more reasonable,
mainly since C++ actually has a demangler in place and linkage symbols
do not appear in the output of complete.  Still, with a poor enough
to-be-completed string one can easily produce similar results:

  (gdb) complete p t
  ...
  p typeinfo name for void
  p typeinfo name for void const*
  p typeinfo name for void*
  p typeinfo name for wchar_t
  p typeinfo name for wchar_t const*
  p typeinfo name for wchar_t*
  p t *** List may be truncated, max-completions reached. ***
  (gdb) p typeinfo name for void*
  No symbol "typeinfo" in current context.
  (gdb) complete p B
  p BACK_SLASH
  p BUF_FIRST
  p BUF_LAST
  ...
  p Base
  p Base::Base()
  p Base::get_foo()
  p bad_key_err
  p buf
  p buffer
  p buffer_size
  p buflen
  p bufsize
  p build_charclass.isra
  (gdb) p bad_key_err
  No symbol "bad_key_err" in current context.

(compiled with gcc/g++ and breaking at main).

This patch is only about making the referenced test more 'fair' for the
other compilers.  Generally, I find the behavior of complete a bit
confusing and maybe one wants to change this at some point but this
would be a bigger task.

testsuite, fortran: fix info-types for intel compilers

This info-types.exp test case had a few issues that this patch fixes.

First, the emitted symbol character(kind=1)/character*1 (different
compilers use different naming converntions here) which is checkedin the
test is not actually expected given the test program.  There is no
variable of that type in the test.  Still, gfortran emits it for every
Fortran program there is.  The reason is the way gfortran handles Fortran's
named main program.  It generates a wrapper around the Fortran program
that is quite similar to a C main function.  This C-like wrapper has
argc and argv arguments for command line argument passing and the argv
pointer type has a base type character(kind=1) DIE emitted at CU scope.

Given the program

  program prog
  end program prog

the degbug info gfortran emits looks somewhat like

   <0><c>: Abbrev Number: 3 (DW_TAG_compile_unit)
      ...
   <1><2f>: Abbrev Number: 4 (DW_TAG_subprogram)
      <30>   DW_AT_external    : 1
      <30>   DW_AT_name        : (indirect string, ...): main
      ...
   <2><51>: Abbrev Number: 1 (DW_TAG_formal_parameter)
      <52>   DW_AT_name        : (indirect string, ...): argc
      ...
   <2><5d>: Abbrev Number: 1 (DW_TAG_formal_parameter)
      <5e>   DW_AT_name        : (indirect string, ...): argv
      ...
      <62>   DW_AT_type        : <0x77>
      ...
   <2><6a>: Abbrev Number: 0
   ...
   <1><77>: Abbrev Number: 6 (DW_TAG_pointer_type)
      <78>   DW_AT_byte_size   : 8
      <79>   DW_AT_type        : <0x7d>
   <1><7d>: Abbrev Number: 2 (DW_TAG_base_type)
      <7e>   DW_AT_byte_size   : 1
      <7f>   DW_AT_encoding    : 8        (unsigned char)
      <80>   DW_AT_name        : (indirect string, ...): character(kind=1)
   <1><84>: Abbrev Number: 7 (DW_TAG_subprogram)
      <85>   DW_AT_name        : (indirect string, ...): prog
   ...

Ifx and flang do not emit any debug info for a wrapper main method so
the type is missing here.  There was the possibility of actually adding
a character*1 type variable to the Fortran executable, but both, ifx and
gfortran chose to emit this variable's type as a DW_TAG_string_type of
length one (instead of a character(kind=1), or whatever the respective
compiler naming convention is).  While string types are printed as
character*LENGHT in the fortran language part (e.g. when issuing a
'ptype') they do not generate any symbols inside GDB.  In read.c it says

   /* These dies have a type, but processing them does not create
      a symbol or recurse to process the children.  Therefore we can
      read them on-demand through read_type_die.  */

So they did not add any output to 'info types'.  Only flang did emit a
character type here.
As adding a type would have a) not solved the problem for ifx and would
have b) somehow hidden the curious behavior of gfortran, instead, the
check for this character type was chagened to optional with the
check_optional_entry to allow for the symbols's absence and to allow
flang and ifx to pass this test as well.

Second, the line checked for s1 was hardcoded as 37 in the test.  Given
that the type is actually defined on line 41 (which is what is emitted by
ifx) it even seems wrong.  The line check for s1 was changed to actually
check for 41 and a gfortran bug has been filed here

   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105454

The test is now marked as xfail for gfortran.

Third, the whole test of checking for the 'Type s1' in info types seemed
questionable.  The type s1 is declared iside the scope of the Fortran
program info_types_test.  Its DIE however is emitted as a child of the
whole compilation unit making it visible outside of the program's scope.
The 'info types' command checks for types stored in the GLOBAL_BLOCK,
or STATIC_BLOCKm wgucm according to block.h

   The GLOBAL_BLOCK contains all the symbols defined in this compilation
   whose scope is the entire program linked together.
   The STATIC_BLOCK contains all the symbols whose scope is the
   entire compilation excluding other separate compilations.

so for gfortran, the type shows up in the output of 'info types'.  For
flang and ifx on the other hand this is not the case.  The two compilers
emit the type (correctly) as a child of the Fortran program, thus not
adding it to either, the GLOBAL_BLOCK nor the LOCAL_BLOCK.  A bug has
been opened for the gfortran scoping issue:

   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105454

While the most correct change might have been removing the check for s1,
the change made here was to only check for this type in case of gfortran
being used as the compiler, as this check also covers the declaration
line issue mentioned above.  A comment was added to maybe remove this
check once the scoping issue is resolved (and it starts to fail with
newer gfortran versions).  The one used to test these changes was 13.0.

testsuite/lib: add check_optional_entry for GDBInfoSymbols

There was already a similar functionality for the GDBInfoModuleSymbols.
This just extends the GDBInfoSymbols.  We will use this feature in a
later commit to make a testcase less GNU specific and more flexible for
other compilers.

Namely, in gdb.fortran/info-types.exp currenlty
GDBInfoSymbols::check_entry is used to verify and test the output of the
info symbols command.  The test, however was written with gfortran as a
basis and some of the tests are not fair with e.g. ifx and ifort as
they test for symbols that are not actually required to be emitted.  The
lines
   GDBInfoSymbols::check_entry "${srcfile}" "" "${character1}"
and
   GDBInfoSymbols::check_entry "${srcfile}" "37" "Type s1;"

check for types that are either not used in the source file (character1)
or should not be emitted by the compiler at global scope (s1) thus no
appearing in the info symbols command.  In order to fix this we will
later use the newly introduced check_optional_entry over check_entry.

testsuite, fortran: Add '-debug-parameters all' when using ifx/ifort

In order for ifx and ifort to emit all debug entries, even for unused
parameters in modules we have to define the '-debug-parameters all' flag.

This commit adds it to the ifx-*/ifort-* specific flags in gdb.exp.

testsuite, fortran: add compiler dependent types to dynamic-ptype-whatis

The test was earlier not using the compiler dependent type print system
in fortran.exp.  I changed this.  It should generally improve the test
performance for different compilers.  For ifx and gfortran I do not see
any failures.

testsuite, fortran: add required external keyword

Currenlty, ifx/ifort cannot compile the given executable as it is not
valid Fortran.  It is missing the external keyword on the
no_arg_subroutine.  Gfortran compiles the example but this is actually
a bug and there is an open gcc ticket for this here:

   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50377

Adding the keyword does not change the gfortran compiling of the example.
It will, however, prevent a future fail once 50377 has been addressed.

gdb/testsuite: disable charset.exp for intel compilers

The test specifically tests for the Fortran CHARACTER(KIND=4) which is
not available in ifx/ifort.

Since the other characters are also printed elsewhere, we disable this
test for the unsupported compilers.

gdb/testsuite: rename intel next gen c/cpp compilers

The name for icx and icpx in the testsuite was earlier set to 'intel-*'
by the compiler identification.  This commit changes this to 'icx-*'.

Note, that currently these names are not used within the testsuite so no
tests have to be adapted here.

gdb/testsuite: add Fortran compiler identification to GDB

This commit adds a separate Fortran compiler identification mechanism to
the testsuite, similar to the existing one for C/C++.  Before this
change, the options and version for the Fortran compiler specified when
running the testsuite with F90_FOR_TARGET set, was detected via its
respective C compiler.  So running the testsuite as

  make check TEST=gdb.fortran/*.exp CC_FOR_TARGET=gcc F90_FOR_TARGET=ifx

or even

  make check TEST=gdb.fortran/*.exp F90_FOR_TARGET=ifx

would use the gcc compiler inside the procedures get_compiler_info and
test_compiler_info to identify compiler flags and the compiler version.
This could sometimes lead to unpredictable outputs.  It also limited
testsuite execution to combinations where C and Fortran compiler would
come from the same family of compiers (gcc/gfortran, icc/ifort, icx/ifx,
clang/flang ..).  This commit enables GDB to detect C and Fortran
compilers independently of each other.

As most/nearly all Fortran compilers have a mechanism for preprocessing
files in a C like fashion we added the exact same meachnism that already
existed for C/CXX.  We let GDB preprocess a file with the compilers
Fortran preprocessor and evaluate the preprocessor defined macros in that
file.

This enables GDB to properly run heterogeneous combinations of C and
Fortran compilers such as

  CC_FOR_TARGET='gcc' and F90_FOR_TARGET='ifort'

or enables one to run the testsuite without specifying a C compiler as in

  make check TESTS=gdb.fortran/*.exp F90_FOR_TARGET='ifx'
  make check TESTS=gdb.fortran/*.exp F90_FOR_TARGET='flang'

On the other hand this also requires one to always specify a
identification mechanism for Fortran compilers in the compiler.F90 file.

We added identification for GFORTRAN, FLANG (CLASSIC and LLVM) IFX,
IFORT, and ARMFLANG for now.

Classic and LLVM flang were each tested with their latest releases on
their respective release pages.  Both get recognized by the new compiler
identification and we introduced the two names flang-classic and
flang-llvm to distinguish the two.  While LLVM flang is not quite mature
enough yet for running the testsuite we still thought it would be a good
idea to include it already.  For this we added a case for the fortran_main
procedure.  LLVM flang uses 'MAIN__' as opposed to classic flang which
uses 'MAIN_' here.

We did not have the possibility to test ARMFLANG - the versioning scheme
here was extracted from its latest online documentation.

We changed the test_compiler_info procedure to take another optional
argument, the language string, which will be passed though to the
get_compiler_info procedure.  Passing 'f90' or 'c++' here will then
trigger the C++/Fortran compiler identification within
get_compiler_info.  The latter procedure was extended to also handle
the 'f90' argument (similarly to the already existing 'c++' one).

Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>

gdb/testsuite: move getting_compiler_info to front of gdb_compile

The procedure gdb_compile queries its options via

   [lsearch -exact $options getting_compiler_info]

to check whether or not it was called in with the option
getting_compiler_info.  If it was called with this option it would
preprocess some test input to try and figure out the actual compiler
version of the compiler used.  While doing this we cannot again try to
figure out the current compiler version via the 'getting_compiler_info'
option as this would cause infinite recursion.  As some parts of the
procedure do recursively test for the compiler version to e.g. set
certain flags, at several places gdb_compile there are checks for the
getting_compiler_info option needed.

In the procedure, there was already a variable 'getting_compiler_info'
which was set to the result of the 'lsearch' query and used instead of
again and again looking for getting_compiler_info in the procedure
options.  But, this variable was actually set too late within the code.
This lead to a mixture of querying 'getting_compiler_info' or
doing an lserach on the options passed to the procedure.

I found this inconsistent and instead moved the variable
getting_compiler_info to the front of the procedure.  It is set to true
or false depending on whether or not the argument is found in the
procedure's options (just as before) and queried instead of doing an
lsearch on the procedure options in the rest of the procedure.

gdb/testsuite: Fix fortran types for Intel compilers.

Newer Intel compilers emit their dwarf type name in a slightly different
format.  Therefore, this needs adjustment to make more tests pass in the
Fortran testsuite.

Co-authored-by: Abdul Basit Ijaz <abdul.b.ijaz@intel.com>
Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>

gdb/testsuite: Use -module option for Intel Fortran compilers

The '-J' option is not supported in Intel compilers (ifx and ifort).
The Intel version of the flag is '-module' which serves the same purpose.

gdb/testsuite: remove F77_FOR_TARGET support

The last uses of the F77_FOR_TARGET via passing f77 to GDB's compile
procedure were removed in this commit

   commit 0ecee54cfd04a60e7ca61ae07c72b20e21390257
   Author: Tom Tromey <tromey@redhat.com>
   Date:   Wed Jun 29 17:50:47 2011 +0000

over 10 years ago.  The last .f files in the testsuite by now are all
being compiled by passing 'f90' to the GDB compile, thus only actually
using F90_FOR_TARGET (array-element.f, block-data.f, subarray.f).
Gfortran in this case is backwards compatible with most f77 code as
claimed on gcc.gnu.org/fortran.

The reason we'd like to get rid of this now is, that we'll be
implementing a Fortran compiler identification mechanism, similar to the
C/Cpp existing ones.  It would be using the Fortran preprocessor macro
defines to identify the Fortran compiler version at hand.  We found it
inconsequent to only implement this for f90 but, on the other hand, f77
seems deprecated.  So, with this commit we remove the remaining lines for
its support.

Improve clear command's documentation

Co-Authored-By: Eli Zaretskii <eliz@gnu.org>
Change-Id: I9440052fd28f795d6f7c93a4576beadd21f28885

Clarify why we unit test matching symbol names with 0xff characters

In the name matching unit tests in gdb/dwarf2/read.c, explain better
why we test symbols with \377 / 0xff characters (Latin1 'ÿ').

Change-Id: I517f13adfff2e4d3cd783fec1d744e2b26e18b8e

Improve break-range's documentation

Change-Id: Iac26e1d2e7d8dc8a7d9516e6bdcc5c3fc4af45c8

Explicitly mention yet-unloaded shared libraries in location spec examples

Change-Id: I05639ddb3bf620c7297b57ed286adc3aa926b7b6

sparc64 segfault in finish_dynamic_symbol

SYMBOL_REFERENCES_LOCAL can return true for undefined symbols.  This
can result in a segfault when running sparc64 ld/testsuite/ld-vsb
tests that expect a failure.

* elfxx-sparc.c (_bfd_sparc_elf_finish_dynamic_symbol): Don't
access u.def.section on non-default visibility undefined symbol.

ia64 gas: Remove unnecessary init

The whole struct is cleared by alloc_record.

* config/tc-ia64.c (output_prologue, output_prologue_gr): Don't
zero r.record.r.mask.

v850_elf_set_note prototype

v850_elf_set_note is declared using an unsigned int note param in
elf32-v850.h but defined with enum c850_notes note in elf32-v850.c.
Current mainline gcc is warning about this.  Huh.

* elf32-v850.c (v850_elf_set_note): Make "note" param an
unsigned int.

Import libiberty from gcc

PR 29200
include/
* ansidecl.h,
* demangle.h: Import from gcc.
libiberty/
* cp-demangle.c,
* testsuite/demangle-expected: Import from gcc.

gdb/testsuite: resolve duplicate test name in gdb.trace/signal.exp

Spotted a duplicate test name in gdb.trace/signal.exp, resolved in
this commit by making use of 'with_test_prefix'.

Ajdust more tests for opcodes/i386: remove trailing whitespace

git commit 202be274a4 also missed adjusting a few testsuite files.
This fixes
i686-vxworks  +FAIL: VxWorks shared library test 1
i686-vxworks  +FAIL: VxWorks executable test 1 (dynamic)

Trailing spaces in objdump -r header

git commit 202be274a4 went a little wild in removing trailing spaces
in gas/testsuite/gas/i386/{secidx.d,secrel.d}, causing
x86_64-w64-mingw32  +FAIL: i386 secrel reloc
x86_64-w64-mingw32  +FAIL: i386 secidx reloc

I could have just replaced the trailing space, but let's fix the
objdump output instead.  Touches lots of testsuite files.

Automatic date update in version.in

gdb/testsuite: fix gdb.trace/signal.exp on x86

Patch

  202be274a41a ("opcodes/i386: remove trailing whitespace from insns with zero operands")

causes this regression:

  FAIL: gdb.trace/signal.exp: find syscall insn in kill

It's because the test still expects to match a whitespace after the
instruction, which the patch mentioned above removed.  Remove the
whitespaces for the regexp.

Change-Id: Ie194273cc942bfd91332d4035f6eec55b7d3a428

gdb/manual: Introduce location specs

The current "Specify Location" section of the GDB manual starts with:

 "Several @value{GDBN} commands accept arguments that specify a location
 of your program's code."

And then, such commands are documented as taking a "location"
argument.  For example, here's a representative subset:

 @item break @var{location}
 @item clear @var{location}
 @item until @var{location}
 @item list @var{location}
 @item edit @var{location}
 @itemx info line @var{location}
 @item info macros @var{location}
 @item trace @var{location}
 @item info scope @var{location}
 @item maint agent @r{[}-at @var{location}@r{,}@r{]} @var{expression}

The issue here is that "location" isn't really correct for most of
these commands.  Instead, the "location" argument is really a
placeholder that represent an umbrella term for all of the
"linespecs", "explicit location", and "address location" input
formats.  GDB parses these and then finds the actual code locations
(plural) in the program that match.  For example, a "location"
specified like "-function func" will actually match all the code
locations in the program that correspond to the address/file/lineno of
all the functions named "func" in all the loaded programs and shared
libraries of all the inferiors.  A location specified like "-function
func -label lab" matches all the addresses of C labels named "lab" in
all functions named "func".  Etc.

This means that several of the commands that claim they accept a
"location", actually end up working with multiple locations, and the
manual doesn't explain that all that well.  In some cases, the command
will work with all the resolved locations.  In other cases, the
command aborts with an error if the location specification resolves to
multiple locations in the program.  In other cases, GDB just
arbitrarily and silently picks whatever is the first resolved code
location (which sounds like should be improved).

To clarify this, I propose we use the term "Location Specification",
with shorthand "locaction spec", when we're talking about the user
input, the argument or arguments that is/are passed to commands to
instruct GDB how to find locations of interest.  This is distinct from
the actual code locations in the program, which are what GDB finds
based on the user-specified location spec.  Then use "location
specification or the shorter "location spec" thoughout instead of
"location" when we're talking about the user input.

Thus, this commit does the following:

- renames the "Specify Location" section of the manual to "Location
  Specifications".

- It then introduces the term "Location Specification", with
  corresponding shorthand "location spec", as something distinct from
  an actual code location in the program.  It explains what a concrete
  code location is.  It explains that a location specification may be
  incomplete, and that may match multiple code locations in the
  program, or no code location at all.  It gives examples.  Some
  pre-existing examples were moved from the "Set Breaks" section, and
  a few new ones that didn't exist yet were added.  I think it is
  better to have these centralized in this "Location Specification"
  section, since all the other commands that accept a location spec
  have an xref that points there.

- Goes through the manual, and where "@var{location}" was used for a
  command argument, updated it to say "@var{locspec}" instead.  At the
  same time, tweaks the description of the affected commands to
  describe what happens when the location spec resolves to more than
  one location.  Most commands just did not say anything about that.

  One command -- "maint agent -at @var{location}" -- currently says it
  accepts a "location", suggesting it can accept address and explicit
  locations too, but that's incorrect.  In reality, it only accepts
  linespecs, so fix it accordingly.

  One MI command -- "-trace-find line" -- currently says it accepts a
  "line specification", but it can accept address and explicit
  locations too, so fix it accordingly.

Special thanks goes to Eli Zaretskii for reviews and rewording
suggestions.

Change-Id: Ic42ad8565e79ca67bfebb22cbb4794ea816fd08b

Move 64-bit BFD files from ALL_TARGET_OBS to ALL_64_TARGET_OBS

Doing a 32-bit build with "--enable-targets=all --disable-sim" fails to link
properly.

--

loongarch-tdep.o: In function `loongarch_gdbarch_init':
binutils-gdb/gdb/loongarch-tdep.c:443: undefined reference to `loongarch_r_normal_name'
loongarch-tdep.o: In function `loongarch_fetch_instruction':
binutils-gdb/gdb/loongarch-tdep.c:37: undefined reference to `loongarch_insn_length'
loongarch-tdep.o: In function `loongarch_scan_prologue(gdbarch*, unsigned long long, unsigned long long, frame_info*, trad_frame_cache*) [clone .isra.4]':
binutils-gdb/gdb/loongarch-tdep.c:87: undefined reference to `loongarch_insn_length'
binutils-gdb/gdb/loongarch-tdep.c:88: undefined reference to `loongarch_decode_imm'
binutils-gdb/gdb/loongarch-tdep.c:89: undefined reference to `loongarch_decode_imm'
binutils-gdb/gdb/loongarch-tdep.c:90: undefined reference to `loongarch_decode_imm'
binutils-gdb/gdb/loongarch-tdep.c:91: undefined reference to `loongarch_decode_imm'
binutils-gdb/gdb/loongarch-tdep.c:92: undefined reference to `loongarch_decode_imm'

--

Given the list of 64-bit BFD files in
opcodes/Makefile.am:TARGET64_LIBOPCODES_CFILES, it looks like GDB's
ALL_TARGET_OBS list is including files that should be included in
ALL_64_TARGET_OBS instead.

This patch accomplishes this and enables a 32-bit build with
"--enable-targets=all --disable-sim" to complete.

Moving the bpf, tilegx and loongarch files to the correct list means GDB can
find the correct disassembler function instead of finding a null pointer.

We still need the "--disable-sim" switch (or "--enable-64-bit-bfd") to
make a 32-bit build with "--enable-targets=all" complete correctly

Fix failing test for armeb-gnu-eabi

The following test fails on the armeb-gnu-eabi target:

FAIL: Unwind information for Armv8.1-M.Mainline PACBTI extension

This patch adjusts the expected output for big endian.

Use a union to avoid casts in bfd/doc/chew.c

This fixes -Wpedantic warnings in chew.c.  Conversion between function
and object pointers is not guaranteed.  They can even be different
sizes, not that we're likely to encounter build machines like that
nowadays.

PR 29194
* doc/chew.c (pcu): New union typedef.
(dict_type, pc): Use it here.  Adjust uses of pc.
(add_to_definition): Make "word" param a pcu.  Adjust all uses
of function.
(stinst_type): Delete.

use libiberty xmalloc in bfd/doc/chew.c

Catch out of memory.

* doc/chew.c: Include libibery.h.
(init_string_with_size, nextword): Replace malloc with xmalloc.
(newentry, add_to_definition): Likewise.
(catchar, catbuf): Replace realloc with xrealloc.
(add_intrinsic): Replace strdup with xstrdup.
* doc/local.mk (LIBIBERTY): Define.
(chew): Link against libiberty.
* Makefile.in: Regenerate.

Update K&R functions in bfd/doc/chew.c

* doc/chew.c: Update function definitions to ISO C, remove
now unnecessary prototypes.

Reorganise bfd/doc/chew.c a little

This also removes some unused variables, and deletes support for the
"var" keyword which isn't used and was broken.  (No means to set
variables, and add_var used push_number inconsistent with its use
elsewhere.)

* doc/chew.c: Move typedefs before variables, variables before
functions.
(die): Move earlier.
(word_type, sstack, ssp): Delete.
(dict_type): Delete var field.
(add_var): Delete.
(compile): Remove "var" support.

RISC-V: Add zhinx extension supports.

The zhinx extension is a sub-extension in zfinx, corresponding to
zfh extension but use GPRs instead of FPRs.

This patch expanded the zfh insn class define, since zfh and zhinx
use the same opcodes, thanks for Nelson's works.

changelog in V2: Add missing classes of 'zfh' and 'zhinx' in
"riscv_multi_subset_supports_ext".

bfd/ChangeLog:

        * elfxx-riscv.c (riscv_multi_subset_supports): New extensions.
        (riscv_multi_subset_supports_ext): New extensions.

gas/ChangeLog:

        * testsuite/gas/riscv/fp-zhinx-insns.d: New test.
        * testsuite/gas/riscv/fp-zhinx-insns.s: New test.

include/ChangeLog:

        * opcode/riscv.h (enum riscv_insn_class): New INSN classes.

opcodes/ChangeLog:

        * riscv-opc.c: Modify INSN_CLASS.

Automatic date update in version.in

Automatic date update in version.in

gdb/python: improve formatting of help text for user defined commands

Consider this command defined in Python (in the file test-cmd.py):

  class test_cmd (gdb.Command):
    """
    This is the first line.
      Indented second line.
    This is the third line.
    """

    def __init__ (self):
      super ().__init__ ("test-cmd", gdb.COMMAND_OBSCURE)

    def invoke (self, arg, from_tty):
      print ("In test-cmd")

  test_cmd()

Now, within a GDB session:

  (gdb) source test-cmd.py
  (gdb) help test-cmd

    This is the first line.
      Indented second line.
    This is the third line.

  (gdb)

I think there's three things wrong here:

  1. The leading blank line,
  2. The trailing blank line, and
  3. Every line is indented from the left edge slightly.

The problem of course, is that GDB is using the Python doc string
verbatim as its help text.  While the user has formatted the help text
so that it appears clear within the .py file, this means that the text
appear less well formatted when displayed in the "help" output.

The same problem can be observed for gdb.Parameter objects in their
set/show output.

In this commit I aim to improve the "help" output for commands and
parameters.

To do this I have added gdbpy_fix_doc_string_indentation, a new
function that rewrites the doc string text following the following
rules:

  1. Leading blank lines are removed,
  2. Trailing blank lines are removed, and
  3. Leading whitespace is removed in a "smart" way such that the
  relative indentation of lines is retained.

With this commit in place the above example now looks like this:

  (gdb) source ~/tmp/test-cmd.py
  (gdb) help test-cmd
  This is the first line.
    Indented second line.
  This is the third line.
  (gdb)

Which I think is much neater.  Notice that the indentation of the
second line is retained.  Any blank lines within the help text (not
leading or trailing) will be retained.

I've added a NEWS entry to note that there has been a change in
behaviour, but I didn't update the manual.  The existing manual is
suitably vague about how the doc string is used, so I think the new
behaviour is covered just as well by the existing text.

gdb: use gdb::unique_xmalloc_ptr<char> for docs in cmdpy_init

Make use of gdb::unique_xmalloc_ptr<char> to hold the documentation
string in cmdpy_init (when creating a custom GDB command in Python).
I think this is all pretty straight forward, the only slight weirdness
is the removal of the call to free toward the end of this function.

Prior to this commit, if an exception was thrown after the GDB command
was created then we would (I think) end up freeing the documentation
string even though the command would remain registered with GDB, which
would surely lead to undefined behaviour.

After this commit we release the doc string at the point that we hand
it over to the command creation routines.  If we throw _after_ the
command has been created within GDB then the doc string will be left
live.  If we throw during the command creation itself (either from
add_prefix_cmd or add_cmd) then it is up to those functions to free
the doc string (I suspect we don't, but I think in general the
commands are pretty bad at cleaning up after themselves, so I don't
think this is a huge problem).

gprofng: fix build with -mx32

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

PR gprofng/28983
PR gprofng/29143
* src/Experiment.cc (write_header): Fix argument for ctime.
Fix -Wformat= warnings.
* src/Dbe.cc: Likewise.
* src/DwarfLib.h: Fix [-Wsign-compare] warnings.
* src/Experiment.h: Likewise.
* src/ipc.cc: Fix -Wformat= warnings.

Automatic date update in version.in

Fix crash with "maint print arc"

Luis noticed that "maint print arc" would crash, because the command
handler did not find "show" in the command name, violating an
invariant.  This patch fixes the bug by changing the registration to
use add_basic_prefix_cmd instead.

opcodes/i386: remove trailing whitespace from insns with zero operands

While working on another patch[1] I had need to touch this code in
i386-dis.c:

  ins->obufp = ins->mnemonicendp;
  for (i = strlen (ins->obuf) + prefix_length; i < 6; i++)
    oappend (ins, " ");
  oappend (ins, " ");
  (*ins->info->fprintf_styled_func)
    (ins->info->stream, dis_style_mnemonic, "%s", ins->obuf);

What this code does is add whitespace after the instruction mnemonic
and before the instruction operands.

The problem I ran into when working on this code can be seen by
assembling this input file:

    .text
    nop
    retq

Now, when I disassemble, here's the output.  I've replaced trailing
whitespace with '_' so that the issue is clearer:

    Disassembly of section .text:

    0000000000000000 <.text>:
       0: 90                    nop
       1: c3                    retq___

Notice that there's no trailing whitespace after 'nop', but there are
three spaces after 'retq'!

What happens is that instruction mnemonics are emitted into a buffer
instr_info::obuf, then instr_info::mnemonicendp is setup to point to
the '\0' character at the end of the mnemonic.

When we emit the whitespace, this is then added starting at the
mnemonicendp position.  Lets consider 'retq', first the buffer is
setup like this:

  'r' 'e' 't' 'q' '\0'

Then we add whitespace characters at the '\0', converting the buffer
to this:

  'r' 'e' 't' 'q' ' ' ' ' ' ' '\0'

However, 'nop' is actually an alias for 'xchg %rax,%rax', so,
initially, the buffer is setup like this:

  'x' 'c' 'h' 'g' '\0'

Then in NOP_Fixup we spot that we have an instruction that is an alias
for 'nop', and adjust the buffer to this:

  'n' 'o' 'p' '\0' '\0'

The second '\0' is left over from the original buffer contents.
However, when we rewrite the buffer, we don't afjust mnemonicendp,
which still points at the second '\0' character.

Now, when we insert whitespace we get:

  'n' 'o' 'p' '\0' ' ' ' ' ' ' ' ' '\0'

Notice the whitespace is inserted after the first '\0', so, when we
print the buffer, the whitespace is not printed.

The fix for this is pretty easy, I can change NOP_Fixup to adjust
mnemonicendp, but now a bunch of tests start failing, we now produce
whitespace after the 'nop', which the tests don't expect.

So, I could update the tests to expect the whitespace....

...except I'm not a fan of trailing whitespace, so I'd really rather
not.

Turns out, I can pretty easily update the whitespace emitting code to
spot instructions that have zero operands and just not emit any
whitespace in this case.  So this is what I've done.

I've left in the fix for NOP_Fixup, I think updating mnemonicendp is
probably a good thing, though this is not really required any more.

I've then updated all the tests that I saw failing to adjust the
expected patterns to account for the change in whitespace.

[1] https://sourceware.org/pipermail/binutils/2022-April/120610.html