Remove eval_op_ternop

eval_op_ternop is only used by the implementation of
ternop_slice_operation.  While working on another series, it was
convenient for me to merge this function into its only caller.

Reviewed-by: Kevin Buettner <kevinb@redhat.com>

[symtab/27831] New test case: gdb.base/add-symbol-file-attach.exp

This commit adds a new test case for bug 27831.  See the contents
of the .exp file for a description of what it's about.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831
Approved-By: Tom Tromey <tom@tromey.com>

[symtab/27831] Fix OBJF_MAINLINE assert

This commit fixes a bug mentioned by Florian Weimer during the
libpthread/ld.so load order discussion from 2021.  Florian provided
instructions for reproducing the bug here:

https://sourceware.org/pipermail/gdb-patches/2021-April/177923.html

That particular test does some interesting things involving forks,
threads, and thread local storage.  Fortunately, none of that is
needed to reproduce the problem.

I've made a new test case (which is now found in a separate commit)
contained in the files gdb.base/add-symbol-file-attach.{c,exp}.  The
.c file is fairly simple as is the recipe for reproducing the problem.

After separately starting the test case and noting the process id,
start gdb (w/ no arguments), and do the following to reproduce the
assertion failure - for this run, the process id of the separately
started add-symbol-file-attach process is 4103218:

(gdb) add-symbol-file add-symbol-file-attach
add symbol table from file "add-symbol-file-attach"
(y or n) y
Reading symbols from add-symbol-file-attach...
(gdb) attach 4103218
Attaching to process 4103218
Load new symbol table from "/tmp/add-symbol-file-attach"? (y or n) y
Reading symbols from /tmp/add-symbol-file-attach...
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007f502130bf27 in pause () from /lib64/libc.so.6
(gdb) p foo
symtab.c:6417: internal-error: CORE_ADDR get_msymbol_address(objfile*,
  const minimal_symbol*): Assertion `(objf->flags & OBJF_MAINLINE) == 0'
  failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

The add-symbol-file command causes the symbols to be loaded without
the SYMFILE_MAINLINE (and hence the OBJFILE_MAINLINE) flags being
set.  This, in turn, causes the "maybe_copied" flag to be set for
the global symbol (named "foo" in the provided test case).

The attach command will cause another objfile to be created, but
it will reuse the symtabs from the objfile created by add-symbol-file,
leading to a situation in which the OBJFILE_MAINLINE flag will be set
for the new (attach-created) objfile, however the "maybe_copied"
flag will still be set for the global symbol.  Had it been loaded
anew, this flag would not be set due to OBJFILE_MAINLINE being set
for the objfile.

At present, minimal_symbol::value_address looks like this:

CORE_ADDR
minimal_symbol::value_address (objfile *objfile) const
{
  if (this->maybe_copied (objfile))
    return get_msymbol_address (objfile, this);
  else
    return (CORE_ADDR (this->unrelocated_address ())
    + objfile->section_offsets[this->section_index ()]);
}

So, we can now see the problem: When the "maybe_copied" flag is set,
get_msymbol_address() will be called.  However, get_msymbol_address()
assumes that it won't be called with the OBF_MAINLINE flag set for
the objfile in question.  It, in fact, contains an assert() which
makes sure that this is the case:

  gdb_assert ((objf->flags & OBJF_MAINLINE) == 0);

(If this assert is removed, then get_msymbol_address() recurses
infinitely for the case under consideration.)

So, the problem here is that the maybe_copied flag is set for the
symbol AND the OBJF_MAINLINE flag is set for the objfile.  As noted
earlier, this happens due to add-symbol-file being used; this causes
the maybe_copied flag to be set.  Later, when the attach is performed,
OBJF_MAINLINE will be set for that objfile, leading to this
unfortunate situation.

My first cut at a solution involved adjusting the
MSYMBOL_VALUE_ADDRESS macro (which has since been changed to be the
method noted above) to include a test of the OBJFILE_MAINLINE flag.
However, Simon Marchi, in his review of my patch, suggested a better
solution.  Simon observed that the 'maybe_copied' flag is (was, after
this commit) being set/initialized in record_minimal_symbol() using
using the objfile in the context in which the symbol was created.

Simon further observed:

  Today, a single copy is created, as symtabs are shared between
  objfiles.  This means that everything that we store into a symbol
  must be independent of any objfile.  However, the value of the
  maybe_copied field is dependent on the objfile in the context of
  which the symbol was created.  Meaning that when the symbol is
  re-used in the context of another objfile, the maybe_copied value is
  not right in the context of that objfile.

  So I think it means there isn't a single "is this symbol maybe
  copied" value, but instead "is this symbol maybe copied, in the
  context of this given objfile".  And the answer is yes or no,
  depending on whether the objfile is mainline.  So maybe_copied
  should become a method that takes an objfile and returns an answer
  based on that.

Simon's full review can be found here:

  https://sourceware.org/pipermail/gdb-patches/2021-May/178855.html

Simon also provided a patch which implements this suggestion.  The
current patch is mostly his work, though I did make some adjustments
during a rebase in addition to making some changes to account for a
concern from Tom Tromey.

During his review of the v3 series, Tom noted, "The old approach was
specific to ELF, while the new approach will be used by any object
format." Tom further observed, "...it seems like it could result in an
incorrect evaluation in some scenario."  This seemed plausible to me,
so I introduced the flag 'object_format_has_copy_relocs' to struct
objfile.  It is set at the end of elf_symfile_read() in elfread.c.
The minimal_symbol::maybe_copied method tests this new flag, forcing
this method to return false when the flag is not set.  If we find that
other object file formats use the same copy reloc mechanism as ELF,
then 'object_format_has_copy_relocs' should be set for objfiles using
those formats.

Lastly, I'll note that this is a strange use case.  It's far more
common to either let gdb figure out which file to load by itself when
attaching, i.e.

(gdb) attach 4104360
Attaching to process 4104360
Reading symbols from /tmp/add-symbol-file-attach...
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6
(gdb) p foo
$1 = 42

...or to use the "file" command prior to the attach, like this:

(gdb) file add-symbol-file-attach
Reading symbols from add-symbol-file-attach...
(gdb) attach 4104360
Attaching to program: /tmp/add-symbol-file-attach, process 4104360
Reading symbols from /lib64/libc.so.6...
(No debugging symbols found in /lib64/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6

Both of these more common scenarios work perfectly fine; using
"add-symbol-file" to load the program to which you will attach
isn't recommended as a normal use case.  That said, it's bad for
gdb to assert, hence this fix.

Reviewed-by: Simon Marchi <simon.marchi@polymtl.ca>
Co-Authored-by: Simon Marchi <simon.marchi@polymtl.ca>
Approved-by: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831

Unify DW_TAG_typedef case in new_symbol

This patch merges the DW_TAG_typedef case in new_symbol with some
other type-related cases.  These all have identical code.

Reviewed-By: Guinevere Larsen <blarsen@redhat.com>

Revert "Simplify @node use in BFD documentation"

This reverts commit 8bb23cdbb498ff645bb0937bc8c0cb89e9e5ebd8.

My earlier patch to simplifify the @node uses in the BFD manual didn't
take into account (1) that BFD doesn't use the ordinary texinfo
sectioning commands, and (2) that some users are stuck on very ancient
versions of makeinfo.

This patch reverts the change.

I went through the entire manual using the spacebar, trying to find
the original problem I reported in the change, but couldn't.  I don't
know why.  Anyway, all this means is that, with this reversion,
editing the node structure will be slightly less convenient.

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

2023-08-30  Tom Tromey  <tom@tromey.com>

PR binutils/30703
* doc/webassembly.texi, doc/bfd.texi: Revert 8bb23cdb, adding
parameters back to @node.

[gdb/contrib] Require minimal dwz version in cc-with-tweaks.sh

I usually run target boards cc-with-dwz and cc-with-dwz-m using a dwz build
from current trunk, but the pathname to the build dir changed and I forgot to
update my test scripts, so the test scripts reverted to using system dwz,
version 0.12.

Consequently, I ran into:
...
(gdb) p ZERO^M
No symbol "ZERO" in current context.^M
(gdb) FAIL: gdb.base/enumval.exp: p ZERO
...
which is due to PR dwz/24468, which was fixed in version 0.13.

Fix this by minimally requiring dwz version 0.13 in cc-with-tweaks.sh, such
that this situation is detected and we get instead:
...
gdb compile failed, cc-with-tweaks.sh: dwz version 0.12 detected, version \
  0.13 or higher required
...

Tested on x86_64-linux, verified with shellcheck.

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

vms-alpha: Free memory on failure path

* vms-alpha.c (evax_bfd_print_eobj): Free rec on failure.

gas init_stab_section and get_stab_string_offset

get_stab_string_offset currently creates the stabstr section if not
already present, in the process keeping a reference to the malloc'd
section name string.  Really, the name belongs in bfd_alloc'd memory
or some obstack so that it doesn't show as a memory leak on exit.
s_stab_generic at least does allocate the name for the stab section on
an obstack, but doesn't tidy that as well as it could.  Return paths
after issuing a warning don't release the memory, nor the memory for
the "string" copy.

This patch fixes these problems.  s_stab_generic is rearranged so that
creation of the sections occurs earlier, before any potential uses of
the note obstack during expression parsing.  That makes it possible to
always free the section name strings unless used to create new
sections.  I've also avoided get_absolute_expression_and_terminator
as I see that function might skip over end-of-line, and lack of a
--input_line_pointer might have caused the following source line to be
ignored.  (Other uses of this function in gas are OK.)

* config/obj-coff.c (obj_coff_init_stab_section): Add stabstr
param.  Pass to get_stab_string_offset rather than name of
section.
* config/obj-som.c (obj_som_init_stab_section): Likewise.
* config/obj-elf.c (obj_elf_init_stab_section): Likewise.
(elf_init_stab_section): Adjust.
* config/obj-coff.h (INIT_STAB_SECTION): Update.
(obj_coff_init_stab_section): Update prototype.
* config/obj-som.h: Similarly.
* config/obj-elf.h: Similarly.
* config/obj-multi.h (INIT_STAB_SECTION): Update.
* obj.h (struct format_ops <init_stab_section>): Update.
* read.h (get_stab_string_offset): Update prototype.
* stabs.c (cached_sec): Delete.
(stabs_begin): Adjust to suit.
(get_stab_string_offset): Add stabstr param, delete stabstr_name
and free_stabstr_secname params.  Don't make stabstr section
here.
(eat_comma): New function.
(s_stab_generic): Replace stab_secname_obstack_end param with
bool freenames.  Move creation of stab and stabstr sections
earlier, so the names can be freed earlier before possible use
of notes obstack during expression parsing.  Tidy error paths
ensuring "string" is freed.  Use get_absolute_expression in
place of get_absolute_expression_and_terminator.
(s_stab): Adjust.
(s_xstab): Use notes_concat to make stabstr section name.

gas OBJ_PROCESS_STAB

This macro and the supporting functions have an unused "seg" first
argument.  Tidy that.

* config/obj-aout.c (obj_aout_process_stab): Delete first param.
* config/obj-ecoff.h (OBJ_PROCESS_STAB): Likewise.
* config/obj-elf.c (elf_process_stab): Likewise.
* config/obj-elf.h (OBJ_PROCESS_STAB): Likewise.
* config/obj-macho.h (OBJ_PROCESS_STAB): Likewise.
* config/obj-multi.h (OBJ_PROCESS_STAB): Likewise.
* ecoff.c (ecoff_stab): Likewise.
* ecoff.h (ecoff_stab): Likewise.
* obj.h (struct format_ops <process_stab>): Likewise.
* stabs.c (OBJ_PROCESS_STAB): Likewise.

[gdb/symtab] Replace TYPE_ALLOC with TYPE_ZALLOC where required

Handle the remaining uses of TYPE_ALLOC, either by:
- replacing with TYPE_ZALLOC, or
- adding a comment explaining why zero-initialization is not necessary.

Tested on x86_64-linux.

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

[gdb/symtab] Replace TYPE_ALLOC + B_CLRALL with TYPE_ZALLOC

I noticed some cases of TYPE_ALLOC followed by B_CLRALL.

Replace these with TYPE_ZALLOC.

Tested on x86_64-linux.

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

[gdb/symtab] Replace TYPE_ALLOC + memset with TYPE_ZALLOC

I noticed a case of TYPE_ALLOC followed by memset.

Replace this with TYPE_ZALLOC.

Tested on x86_64-linux.

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

[gdb/symtab] Do more zero-initialization of type::fields

Now that we've introduced type::{alloc_fields,copy_fields}, the places where
no zero-initialization of allocated fields is done are easy to spot:
...
$ find gdb* -type f | grep -v ChangeLog | xargs grep alloc_fields | grep false
gdb/coffread.c:  type->alloc_fields (nfields, false);
gdb/coffread.c:  type->alloc_fields (nsyms, false);
gdb/stabsread.c:   ftype->alloc_fields (nsemi, false);
gdb/gdbtypes.c:  resolved_type->alloc_fields (nfields, false);
gdb/gdbtypes.c:  alloc_fields (nfields, false);
gdb/gdbtypes.c:  alloc_fields (nfields, false);
gdb/mdebugread.c: t->alloc_fields (nfields, false);
gdb/mdebugread.c:   ftype->alloc_fields (nparams, false);
...

All hits in gdbtypes.c are ok.  There are two hits in the two variants of
copy_fields, and there's already a comment for the third.

AFAICT, the other ones are not ok, so fix those by dropping the "false"
argument.

Tested on x86_64-linux.

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

[gdb/symtab] Factor out type::{alloc_fields,copy_fields}

After finding this code in buildsym_compunit::finish_block_internal:
...
              ftype->set_fields
                ((struct field *)
                 TYPE_ALLOC (ftype, nparams * sizeof (struct field)));
...
and fixing PR30810 by using TYPE_ZALLOC, I wondered if there were more
locations that needed fixing.

I decided to make things easier to spot by factoring out a new function
alloc_fields:
...
 /* Allocate the fields array of this type, with NFIELDS elements.  If INIT,
     zero-initialize the allocated memory.  */
  void
  type::alloc_fields (unsigned int nfields, bool init = true);
...
where:
- a regular use would be "alloc_fields (nfields)", and
- an exceptional use that needed no initialization would be
  "alloc_fields (nfields, false)".

Pretty soon I discovered that most of the latter cases are due to
initialization by memcpy, so I added two variants of copy_fields as well.

After this rewrite there are 8 uses of set_fields left:
...
gdb/coffread.c:   type->set_fields (nullptr);
gdb/coffread.c:   type->set_fields (nullptr);
gdb/coffread.c:   type->set_fields (nullptr);
gdb/eval.c:  type->set_fields
gdb/gdbtypes.c:  type->set_fields (args);
gdb/gdbtypes.c:  t->set_fields (XRESIZEVEC (struct field, t->fields (),
gdb/dwarf2/read.c:      type->set_fields (new_fields);
gdb/dwarf2/read.c:       sub_type->set_fields (sub_type->fields () + 1);
...

These fall into the following categories:
- set to nullptr (coffread.c),
- type not owned by objfile or gdbarch (eval.c), and
- modifying an existing fields array, like adding an element at the end or
  dropping an element at the start (the rest).

Tested on x86_64-linux.

[gdb/symtab] Fix uninitialized memory in buildsym_compunit::finish_block_internal

When running test-case gdb.dwarf2/per-bfd-sharing.exp with target board stabs,
gdb either segfaults or asserts due to reading uninitialized memory, allocated
here in buildsym_compunit::finish_block_internal:
...
      ftype->set_fields
((struct field *)
 TYPE_ALLOC (ftype, nparams * sizeof (struct field)));
...

Fix this by using TYPE_ZALLOC instead.

Tested on x86_64-linux.

Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30810
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30810

arc: Update elfarcv2 script template

Update ARC's elfarcv2 script template with:

- The .ivt section (Interrupt Vector Table) is mapped at the begining
  of STARTUP_MEMORY when ivtbase_addr is not defined. Previously, it
  was pointing to 0x00.

- MEMORY_FILE is a new emulation paramter and sets the name for the
  linker script file which holds the MEMORY commands required by
  arcv2elfx emulation.

- Four new linker variables are introduced available when arcv2elf emulation is used:
  * __TEXT_REGION_ORIGIN__ Once defined it is setting the text region origin. By default it points to zero.
  * __TEXT_REGION_LENGTH__ Once defined it is setting the text region length. By default it is set to 2M.
  * __DATA_REGION_ORIGIN__ Once defined it is setting the data region origin. By default it is set to 0x80000000.
  * __DATA_REGION_LENGTH__ Once defined it is setting the data region length. By default it is set to 2M.

ld/ChangeLog:

* scripttempl/elfarcv2.sc: Update script template.

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

elf: Don't merge sections with different SHF_LINK_ORDER

For relocatable link, don't merge 2 SHF_LINK_ORDER sections if output
sections of their linked to sections are different.

* ldelf.c (elf_orphan_compatible): Don't merge sections with
different SHF_LINK_ORDER.
* testsuite/ld-elf/pr30791a.d: New file.
* testsuite/ld-elf/pr30791a.s: Likewise.
* testsuite/ld-elf/pr30791b.d: Likewise.
* testsuite/ld-elf/pr30791b.s: Likewise.
* testsuite/ld-elf/pr30791c.s: Likewise.
* testsuite/ld-elf/pr30791d.s: Likewise.

elf: Check DT_SYMTAB only on non-IR object

Check DT_SYMTAB only on non-IR object of archive member to avoid crash
on LLVM IR object with NULL elf_tdata.

PR ld/30811
* elflink.c (elf_link_is_defined_archive_symbol): Check
DT_SYMTAB only on non-IR object.

Automatic date update in version.in

libbfd.texi zero size

Pattern rules in doc/local.mk exist that specify how to make
libbfd.texi from libfd.h or libbfd.c.  Since both files exist and the
libbfd.h rule is first, libbfd.h is used.  libbfd.h doesn't contain
the documentation..

* doc/local.mk (doc/%stamp): Put rule making this from %.c
before %.h rule.
* Makefile.in: Regenerate.
* libbfd.c (Byte swapping routines): Don't omit description.

DEFAULT_BUFFERSIZE

There isn't any reason to think that a particular buffer size is
ideal in bfd, so let's just not define it.

* libbfd-in.h (DEFAULT_BUFFERSIZE): Don't define.
* libbfd.h: Regenerate.
* archive.c (AR_WRITE_BUFFERSIZE): Substitute value.
* vms-lib.c (_bfd_vms_lib_write_archive_contents): Likewise.
* coff-rs6000.c (do_copy): Likewise, and use sizeof.

[gdb/testsuite] Fix gdb.dwarf2/nullptr_t.exp with cc-with-dwz-m

When running test-case gdb.dwarf2/nullptr_t.exp with target board
cc-with-dwz-m, I run into:
...
FAIL: gdb.dwarf2/nullptr_t.exp: decltype(nullptr) symbol
...

The problem is that were looking for "typedef void decltype\\(nullptr\\)"
using "maint print symbols -source $srcfile", but dwz has moved the typedef to
a PU, so it's shown by "maint print symbols -source <unknown>" instead.

Fix this by dropping the "-source $srcfile" bit.

Tested on x86_64-linux, with make-check-all.sh.

gdb: simplify vector construction in eval_op_rust_array

Replace the manual fill of the vector with the appropriate std::vector
constructor that makes N copies of the provided value.

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

Revert "Gold: Add targ_extra_little_endian to configure.ac"

This reverts commit cf8565fb2ea42579c50722cbaeafdf71c3d58c66.  It was
applied unapproved.

Revert "Gold/MIPS: Use EM_MIPS instead of EM_MIPS_RS3_LE for little endian"

This reverts commit 39834263784567c306fbccb8230ddd1badca53fe.  It was
applied unapproved.

Revert "Gold/MIPS: Drop mips*le/mips*el* triple pattern"

This reverts commit adb3ae2eba78b4b84d7b94342f6774b250190a98.  It was
applied unapproved.

Revert "Gold/MIPS: Add targ_extra_size=64 for mips32 triples"

This reverts commit d6cdc0af2b880bb48dd16055f4cb3509c7a2da70.  It was
applied unapproved.

Revert "Gold/MIPS: Add mips64*/mips64*el triple support"

This reverts commit 5c4cdba100b66e2924a25dad9b12d8e5b84d527f.  It was
applied unapproved.

Revert "MIPS: Use 64-bit a ABI by default for `mipsisa64*-*-linux*' targets"

This reverts commit 025e84f93566c8ced594ef48ddee1dec7e5b4cdd.  It was
applied unapproved.

gdbserver, linux-low: add a couple of nullptr assertions.

This safeguards a couple of places that may theoretically return NULL but
must not in this specific context.  These were found by a static analysis tool.

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

RISC-V: Make XVentanaCondOps RV64 only

Although XVentanaCondOps instructions are XLEN-agonistic, Ventana's manual
only defines them only for RV64 (because all Ventana's processors implement
RV64).

This commit limits XVentanaCondOps instructions RV64-only to match the
behavior of the manual and LLVM.

Note that this commit alone will not make XVentanaCondOps extension with
RV32 invalid (it just makes XVentanaCondOps on RV32 empty).

opcodes/ChangeLog:

* riscv-opc.c (riscv_opcodes): Restrict "vt.maskc" and "vt.maskcn"
to XLEN=64.

gas/ChangeLog:

* testsuite/gas/riscv/x-ventana-condops-32.d: New failure test.
* testsuite/gas/riscv/x-ventana-condops-32.l: Likewise.

objdump: Free sorted_syms on error path

* objdump.c (disassemble_data): Free sorted_syms before returning.

binutils/dwarf.c abbrev list leak

* dwarf.c (process_debug_info): Call free_abrev_list on
return paths.

Re: readelf/objdump: Handle DWARF info with mixed types of range section

PR 30791
* dwarf.c (free_debug_information): Free range_versions.

Automatic date update in version.in

[gdb/build] Fix C inclusion of nat/x86-cpuid.h

When running test-case gdb.arch/i386-avx512.exp, I run into:
...
 gdb compile failed, In file included from gdb.arch/i386-avx512.c:20:0:
 src/gdb/nat/x86-cpuid.h: In function 'x86_cpuid_count':
 src/gdb/nat/x86-cpuid.h:63:16: error: \
   'nullptr' undeclared (first use in this function)
    if (__eax == nullptr)
                 ^~~~~~~
 src/gdb/nat/x86-cpuid.h:63:16: note: each \
   undeclared identifier is reported only once for each function it appears in

                  === gdb Summary ===

 # of untested testcases         1
...

This is due to commit e85aad4ae76 ("nat/x86-cpuid.h: Add x86_cpuid_count
wrapper around __get_cpuid_count"), which introduced the nullptr check.

The header file gdb/nat/x86-cpuid.h is a file that is included in the build
and compiled as a C++ file, but also in the testsuite and compiled as a C
file.

Fix this by replacing nullptr with (void *)0.

Tested on x86_64-linux.

Co-Authored-By: Kevin Buettner <kevinb@redhat.com>
Approved-by: Kevin Buettner <kevinb@redhat.com>

More renames in array_operation::evaluate

array_operation::evaluate has variables named "tem2" and "tem3".  This
patch replaces one with a better name, and entirely removes the other.

Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

Remove "highbound" parameter from value_array

value_array requires the passed-in bounds to match the length of the
array_view it is given.  This patch removes the redundant "highbound"
parameter.

Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

Remove another redundant variable from array_operation::evaluate

This removes yet another redundant variable from
array_operation::evaluate -- only one index is needed.

Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

Remove redundant variable from array_operation::evaluate

In array_operation::evaluate, 'idx' and 'tem' are redundant in one
branch.  This patch merges them, using the clearer name.

Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

Hoist array bounds check in array_operation::evaluate

This hoists the array bounds check in array_operation::evaluate to
before the loop.

Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

Declare 'tem' in loop header in array_operation::evaluate

This changes array_operation::evaluate to declare the 'tem' variable
in the loop header, rather than at the top of the function.  This is
cleaner and easier to reason about.  I also changed 'nargs' to be
'const'.

Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

Use gdb::array_view for value_array

This changes value_array to accept an array view.  I also replaced an
alloca with a std::vector in array_operation::evaluate.  This function
can work on any size of array, so it seems bad to use alloca.

Reviewed-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb/testsuite: recognize one more unsupported instruction in gdb.reverse/step-precsave.exp

When running this test on a processor that supports AVX512 (AMD EPYC
9634) on Debian 12 bookwork (system compiler is gcc 12.2.0), I see:

    continue^M
    Continuing.^M
    Process record does not support instruction bound.^M
    Process record does not support instruction 0x62 at address 0x7ffff7f49b40.^M
    Process record: failed to record execution log.^M
    ^M
    Program stopped.^M
    0x00007ffff7f49b40 in ?? () from /lib/x86_64-linux-gnu/libc.so.6^M
    (gdb) FAIL: gdb.reverse/step-precsave.exp: run to end of main

The instruction at this address is:

   0x00007ffff7f49b40: 62 e2 7d 48 7a c6   vpbroadcastb %esi,%zmm16

This seems like an AVX512 instruction (given the use of zmm16).  Match
this byte value in order to produce a KFAIL.

Change-Id: I1d20357fa538ba60b9c537160acf511a37d751ee
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30807
Approved-By: Tom Tromey <tom@tromey.com>

[gdb/testsuite] Require have_compile_flag -mavx512f in gdb.arch/i386-avx512.exp

When running test-case gdb.arch/i386-avx512.exp with gcc 4.8.4, I run into:
...
Running gdb.arch/i386-avx512.exp ...
gdb compile failed, gcc: error: unrecognized command line option '-mavx512f'
...

Fix this by requiring have_compile_flag -mavx512f.

Tested on x86_64-linux.

[gdb/testsuite] Require gcc >= 5 in gdb.linespec/cpls-abi-tag.exp

When running test-case gdb.linespec/cpls-abi-tag.exp with gcc 4.8.4, we run
into:
...
cpls-abi-tag.cc:71:26: error: ‘abi_tag’ attribute applied to non-function ‘s’
 ABI3 test_abi_tag_struct s;
                          ^
...

The test-case is supported starting gcc 5.

Fix this by requiring gcc >= 5, if a gcc compiler is used.

Tested on x86_64-linux.

[gdb/testsuite] Handle some test-cases with older compiler

When running test-case gdb.mi/print-simple-values.exp with gcc 4.8.4, I run
into a compilation failure due to the test-case requiring c++11 and the
compiler defaulting to less than that.

Fix this by compiling with -std=c++11.

Likewise in a few other test-cases.

Tested on x86_64-linux.

[gdb/testsuite] Fix false negative in have_host_locale

In test-case gdb.tui/pr30056.exp we check for:
...
require {have_host_locale C.UTF-8}
...

The "C.UTF-8" is normalized by have_host_locale to "c.utf8", before trying to
find it in the list returned by host_locales.

On my development platform, "locale -a" lists C.utf8, which is normalized to
"c.utf8" by host_locales, so there's a match and have_host_locale returns true.

On another platform however, "locale -a" lists C.UTF-8, which is normalized to
"c.utf-8" by host_locales, so there's no match and have_host_locale returns false.

Fix this by also dropping the dash in host_locales.

Tested on x86_64-linux.

readelf: typos in user messages

Default getpkt 'forever' parameter to 'false'

This patch changes remote.c so that the getpkt 'forever' parameter now
defaults to 'false' and fixes up all the callers.

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

Unify getpkt and getpkt_or_notif_sane

getpkt and getpkt_or_notif_sane are just wrappers for
getpkt_or_notif_sane_1.  This patch adds the is_notif parameter to
getpkt, with a suitable default, and removes the wrappers.

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

Use bool in getpkt

This changes getpkt and related functions to use bool rather than int.

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

Remove expecting_notif parameter from getpkt_or_notif_sane_1

For getpkt_or_notif_sane_1, expecting_notif is redundant, because it
always reflects whether the is_notif parameter is non-NULL.  This
patch removes the redundant parameter.

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

Remove getpkt_sane

I noticed that getpkt is just a wrapper around getpk_sane, so this
patch unifies the two of them.

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

[gdb/testsuite] Check for sys/random.h in gdb.reverse/getrandom.exp

When running test-case gdb.reverse/getrandom.exp on a system with eglibc 2.19,
we run into:
...
 gdb compile failed, gdb.reverse/getrandom.c:18:24: fatal error: \
   sys/random.h: No such file or directory
  #include <sys/random.h>
                         ^
 compilation terminated.

                 === gdb Summary ===

 # of untested testcases        1
...
and:
...
UNTESTED: gdb.reverse/getrandom.exp: failed to prepare
...

Fix this by testing for the presence of the header, such that we have instead:
...
UNSUPPORTED: gdb.reverse/getrandom.exp: require failed: \
  have_system_header sys/random.h
...

Tested on x86_64-linux and i686-linux.

Automatic date update in version.in

[gdb/testsuite] Improve xfail in gdb.cp/nsusing.exp

In test-case gdb.cp/nsusing.exp I came across these xfails without PRMS
mentioned:
...
XFAIL: gdb.cp/nsusing.exp: print x, before using statement
XFAIL: gdb.cp/nsusing.exp: print x, only using M
...

Add the missing PRMS, such that we have:
...
XFAIL: gdb.cp/nsusing.exp: print x, before using statement (PRMS gcc/108716)
XFAIL: gdb.cp/nsusing.exp: print x, only using M (PRMS gcc/108716)
...
and limit the xfail to unfixed versions.

The PR is fixed starting gcc 13, but it has been backported to release
branches stretching back to gcc 10.  For simplicity we just stick to testing
for the major version and ignore the backported fixes.

Tested on x86_64-linux.

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

gdbserver: Fix style of struct declarations in i387-fp.cc

gdbserver: Simplify handling of ZMM registers.

- Reuse num_xmm_registers directly for the count of ZMM0-15 registers
  as is already done for the YMM registers for AVX rather than using
  a new variable that is always the same.

- Replace 3 identical variables for the count of upper ZMM16-31
  registers with a single variable.  Make use of this to merge
  various loops working on the ZMM XSAVE region so that all of the
  handling for the various sub-registers in this region are always
  handled in a single loop.

- While here, fix some bugs in i387_cache_to_xsave where if
  X86_XSTATE_ZMM was set on i386 (e.g. a 32-bit process on a 64-bit
  kernel), the -1 register nums would wrap around and store the value
  of GPRs in the XSAVE area.  This should be harmless, but is
  definitely odd.  Instead, check num_zmm_high_registers directly when
  checking X86_XSTATE_ZMM and skip the ZMM region handling entirely if
  the register count is 0.

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

x86: Remove X86_XSTATE_SIZE and related constants.

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

gdbserver: Use x86_xstate_layout to parse the XSAVE extended state area.

Replace the extended state area fields of i387_xsave with methods which
return an offset into the XSAVE buffer.

The two changed functions are called within all tests which runs
gdbserver.

Signed-off-by: Aleksandar Paunovic <aleksandar.paunovic@intel.com>
Co-authored-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdbserver: Refactor the legacy region within the xsave struct

Legacy fields of the XSAVE area are already defined within fx_save
struct.  Use class inheritance to remove code duplication.

The two changed functions are called within all tests which run
gdbserver.

Signed-off-by: Aleksandar Paunovic <aleksandar.paunovic@intel.com>
Co-authored-by: John Baldwin <jhb@FreeBSD.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdbserver: Add a function to set the XSAVE mask and size.

Make x86_xcr0 private to i387-fp.cc and use i387_set_xsave_mask to set
the value instead.  Add a static global instance of x86_xsave_layout
and initialize it in the new function as well to be used in a future
commit to parse XSAVE extended state regions.

Update the Linux port to use this function rather than setting
x86_xcr0 directly.  In the case that XML is not supported, don't
bother setting x86_xcr0 to the default value but just omit the call to
i387_set_xsave_mask as i387-fp.cc defaults to the SSE case used for
non-XML.

In addition, use x86_xsave_length to determine the size of the XSAVE
register set via CPUID.

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

gdb: Use x86_xstate_layout to parse the XSAVE extended state area.

All of the tables describing the offsets of individual registers for
XSAVE state components now hold relative offsets rather than absolute
offsets.  Some tables (those for MPX registers and ZMMH registers) had
to be split into separate tables as they held entries that spanned
multiple state components.

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

gdb: Support XSAVE layouts for the current host in the Linux x86 targets.

Note that this uses the CPUID instruction to determine the total size
of the XSAVE register set.  If there is a way to fetch the register set
size using ptrace that would probably be better.

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

gdb: Update x86 Linux architectures to support XSAVE layouts.

Refactor i386_linux_core_read_xcr0 to fetch and return a corresponding
x86_xsave_layout as well as xcr0 using the size of an existing
NT_X86_XSTATE core dump to determine the offsets via
i387_guess_xsave_layout.  Use this to add an implementation of
gdbarch_core_xfer_x86_xsave_layout.

Use tdep->xsave_layout.sizeof_xsave as the size of the XSTATE register
set.

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

gdb: Support XSAVE layouts for the current host in the FreeBSD x86 targets.

Use the CPUID instruction to fetch the offsets of supported state
components.

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

gdb: Update x86 FreeBSD architectures to support XSAVE layouts.

Refactor i386fbsd_core_read_xcr0 to fetch and return a corresponding
x86_xsave_layout as well as xcr0 using the size of an existing
NT_X86_XSTATE core dump to determine the offsets via
i387_guess_xsave_layout.  Use this to add an implementation of
gdbarch_core_xfer_x86_xsave_layout.

Use tdep->xsave_layout.sizeof_xsave as the size of the XSTATE register
set and only fetch/store the register set if this size is non-zero.

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

x86 nat: Add helper functions to save the XSAVE layout for the host.

x86_xsave_length returns the total length of the XSAVE state area
standard format as queried from CPUID.

x86_fetch_xsave_layout uses CPUID to query the offsets of XSAVE
extended regions from the running host.  The total length of the XSAVE
state area can either be supplied by the caller if known (e.g. from
FreeBSD's PT_GETXSTATEINFO) or it can be queried from the running host
using x86_xsave_length.

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

nat/x86-cpuid.h: Add x86_cpuid_count wrapper around __get_cpuid_count.

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

core: Support fetching x86 XSAVE layout from architectures.

Add gdbarch_core_read_x86_xsave_layout to fetch the x86 XSAVE layout
structure from a core file.

Current OS's do not export the offsets of XSAVE state components in
core dumps, so provide an i387_guess_xsave_layout helper function to
set offsets based on known combinations of XCR0 masks and total state
sizes.  Eventually when core dumps do contain this information this
function should only be used as a fall back for older core dumps.

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

gdb: Store an x86_xsave_layout in i386_gdbarch_tdep.

This structure is fetched from the current target in i386_gdbarch_init
via a new "fetch_x86_xsave_layout" target method.

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

x86: Add an x86_xsave_layout structure to handle variable XSAVE layouts.

The standard layout of the XSAVE extended state area consists of three
regions.  The first 512 bytes (legacy region) match the layout of the
FXSAVE instruction including floating point registers, MMX registers,
and SSE registers.  The next 64 bytes (XSAVE header) contains a header
with a fixed layout.  The final region (extended region) contains zero
or more optional state components.  Examples of these include the
upper 128 bits of YMM registers for AVX.

These optional state components generally have an
architecturally-fixed size, but they are not assigned architectural
offsets in the extended region.  Instead, processors provide
additional CPUID leafs describing the size and offset of each
component in the "standard" layout for a given CPU.  (There is also a
"compact" format which uses an alternate layout, but existing OS's
currently export the "standard" layout when exporting XSAVE data via
ptrace() and core dumps.)

To date, GDB has assumed the layout used on current Intel processors
for state components in the extended region and hardcoded those
offsets in the tables in i387-tdep.c and i387-fp.cc.  However, this
fails on recent AMD processors which use a different layout.
Specifically, AMD Zen3 and later processors do not leave space for the
MPX register set in between the AVX and AVX512 register sets.

To rectify this, add an x86_xsave_layout structure which contains the
total size of the XSAVE extended state area as well as the offset of
each known optional state component.

Subsequent commits will modify XSAVE parsing in both gdb and gdbserver
to use x86_xsave_layout.

Co-authored-by: Aleksandar Paunovic <aleksandar.paunovic@intel.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

Use sect_offset_str in cooked_index::dump

Mark Wielaard pointed out that cooked_index::dump uses PRIx64, and
Andreas Schwab pointed out that gdb already has sect_offset_str.  This
patch applies both these observations.

Use hex_string in gdb/coffread.c instead of PRIxPTR

The getsymname function uses PRIxPTR to print and uintptr_t value in
an error message. Use hex_string instead.

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

[gdb/symtab] Handle self-reference in inherit_abstract_dies

Building gdb with gcc 7.5.0 and -flto -O2 -flto-partition=one generates a
self-referencing DIE:
...
 <2><91dace>: Abbrev Number: 405 (DW_TAG_label)
    <91dad0>   DW_AT_abstract_origin: <0x91dace>
...

When encountering the self-reference DIE in inherit_abstract_dies we loop
following the abstract origin, effectively hanging gdb.

Fix this by handling self-referencing DIEs in the loop in
inherit_abstract_dies.

Tested on x86_64-linux.

Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30799
https://sourceware.org/bugzilla/show_bug.cgi?id=30799

COFF swap_aux_in

A low level function like coff_swap_aux_in really has no business
concatenating multiple auxents for the old PE multi-aux scheme of
handling long file names.  In doing so, it assumes multiple internal
auxent buffers are available, which they are not in most calls to
bfd_coff_swap_aux_in, both inside BFD and outside, eg. GDB.  Buffer
overflow fun.  Concatenating multiple auxents belongs at a higher
level.

This required some changes to coff_get_normalized_symtab, which now
uses the external auxents to access the concatenated file name.
(Internal auxents are larger than the x_fname array, so the pieces of
the file name are not adjacent as they are in the external auxents.)

* coffswap.h (coff_swap_aux_in): Do not write more than one
internal auxent.
* coffcode.h (coff_bigobj_swap_aux_in): Likewise.
* coffgen.c (coff_get_normalized_symtab): Normalize strings
after swapping in each symbol so that external auxents are
available.  Use external auxents for multi-aux long file
names.  Formatting.  Wrap long lines.  Remove excess parens
and unnecessary casts.  Don't zalloc when only the string
terminator needs zeroing, and memcpy rather than strncpy.
Delete unnecessary sanity check with unsigned _n_offset.
Return with failure if debug section can't be read, to avoid
trying to read it multiple times.  Correct sanity check
against debug section size.

Re: comdat_hash memory leaks

I missed another field that needs freeing.  Also, oss-fuzz found a
case with a C_FILE sym using multiple auxents for a long file name
which overflowed the single auxent buffer.  I'm going to fix that
problem in swap_aux_in too, but we may as well avoid it here too,
saving unnecessary work.

* coffcode.h (comdat_delf): Free comdat_name.
(fill_comdat_hash): Only look at symbols with one auxent.

[gdb/testsuite] Add xfail in gdb.cp/subtypes.exp

When running test-case gdb.cp/subtypes.exp with gcc 4.8.4, we run into:
...
FAIL: gdb.cp/subtypes.exp: ptype main::Foo
FAIL: gdb.cp/subtypes.exp: ptype main::Bar
FAIL: gdb.cp/subtypes.exp: ptype main::Baz
FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Foo
FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Bar
FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Baz
FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Foo
FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Bar
FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Baz
...

The problem is gcc PR debug/55541, which generates a superfluous
DW_TAG_lexical_block.

Add a corresponding xfail.

Tested on x86_64-linux.

[gdb/testsuite] Refactor gdb.cp/subtypes.exp

Make test-case gdb.cp/subtypes.exp less repetitive by using foreach.

Tested on x86_64-linux.

[gdb/testsuite] Handle gdb.cp/*.exp with older compiler

When running test-cases gdb.cp/*.exp with gcc 4.8.4, I run into compilation
failures due to the test-cases requiring c++11 and the compiler defaulting
to less than that.

Fix this by compiling with -std=c++11.

This exposes two FAILs in gdb/testsuite/gdb.cp/empty-enum.exp due to
gcc PR debug/16063, so xfail those.

Also require have_compile_flag -std=c++17 in gdb.cp/constexpr-field.exp to
prevent compilation failure.

Tested on x86_64-linux.

MIPS: Use 64-bit a ABI by default for `mipsisa64*-*-linux*' targets

Following the arrangement in GCC select a 64-bit ABI by default, either
n32 or n64, rather than o32 for `mipsisa64*-*-linux*' targets, just as
with the corresponding `mips64*-*-linux*' targets.

Gold/MIPS: Add mips64*/mips64*el triple support

Use targ_size=64 and targ_extra_size=32

Gold/MIPS: Add targ_extra_size=64 for mips32 triples

So we can enable 64bit ELF support for MIPS32 toolchain.

Gold/MIPS: Drop mips*le/mips*el* triple pattern

Only mips*el triples are supported by binutils.  The mips*le
or mips*el* may cause some problem with other components of
binutils, since they will consider them as big endian.

Gold/MIPS: Use EM_MIPS instead of EM_MIPS_RS3_LE for little endian

EM_MIPS_RS3_LE has been deprecated quite long ago, and in fact
most of current LE ELF files are using EM_MIPS.

This problem didn't make some trouble for us, is due to that
gold is a linker, and all of the inputs to it has right EM values.

Gold: Add targ_extra_little_endian to configure.ac

This option will be used by architectures which is big endian
by default, while little-endian support is also needed.

Mips(eb) ports are the examples.

Automatic date update in version.in

PE dos_message

I was looking at dos_message and wondering why we have H_PUT_32
in _bfd_XXi_only_swap_filehdr_out but no H_GET_32 in pe_bfd_object_p.
On a big-endian machine this would result in scrambling the code and
strings constained in dos_message.  Rather than fix the lack of
H_GET_32 in pe_bfd_object_p, I decided it doesn't make sense to store
dos_message internally as an array of ints.

include/
* coff/internal.h (struct internal_extra_pe_filehdr): Make
dos_message a char array.
* coff/msdos.h (struct external_DOS_hdr): Flatten dos_message.
* coff/pe.h (struct external_PEI_filehdr): Likewise.
bfd/
* libcoff-in.h (struct pe_tdata): Make dos_message a char array.
* libcoff.h: Regenerate.
* peXXigen.c (_bfd_XXi_only_swap_filehdr_out): memcpy dos_message
to output.
* peicode.h (pe_mkobject): Don't memset already zeroed pe_opthdr.
Tidy allocation of tdata.pe_obj_data.  Set up dos_message from..
(default_dos_message): ..this.  New static array.

comdat_hash memory leaks

Entries added to the hash table with bfd_malloc ought to be freed when
the hash table is deleted.  This patch adds the necessary del_f to the
htab_create call, and delays creating the table until an
IMAGE_SCN_LNK_COMDAT symbol is read.

* peicode.h (pe_mkobject): Move comdat_hash creation..
(htab_hash_flags, htab_eq_flags): ..and these support functions..
* coffcode.h (handle_COMDAT): ..to here, renaming support to
(comdat_hashf, comdat_eqf): ..this and adding..
(comdat_delf): ..this new function.

Confusion in coff_object_cleanup

A bfd_cleanup function needs to run when only tdata is correct for the
bfd.  The xvec may have changed during bfd_check_format and thus the
flavour may be incorrect.  The format won't have changed but checking
is superfluous.  (In contrast to _bfd_free_cached_info or
_close_and_cleanup where we do need to check things.)

Not getting this correct leaked comdat_hash.

Also, pe_ILF_cleanup ought to call coff_object_cleanup as do all PE
files.

* coffgen.c (coff_object_cleanup): Don't check bfd flavour or
format.
* peicode.h (pe_ILF_cleanup): Call coff_object_cleanup.

sanity check n_numaux

Sanity check aux entries used by PE to extend a C_FILE name.  See
coffswap.h:coff_swap_aux_in.  The existing check only catered for
n_numaux == 1.

* coffcode.h (fill_comdat_hash): Properly sanity check n_numaux.
Formatting.
(handle_COMDAT): Formatting.

Re: ld STRINGIFY

Oops there was a reference to the old name.

* emultempl/aix.em: Use stringify.sed.

Automatic date update in version.in

Simplify definition of GUILE

This patch sets GUILE to just plain 'guile'.

In the distant ("devo") past, the top-level build did support building
Guile in-tree.  However, I don't think this really works any more.
For one thing, there are no build dependencies on it, so there's no
guarantee it would actually be built before the uses.

This patch also removes the use of "-s" as an option to cgen scheme
scripts.  With my latest patch upstream, this is no longer needed.

After the upstream changes, either Guile 2 or Guile 3 will work, with
or without the compiler enabled.

2023-08-24  Tom Tromey  <tom@tromey.com>

* cgen.sh: Don't pass "-s" to cgen.
* Makefile.in: Rebuild.
* Makefile.am (GUILE): Simplify.

Use get_frame_address_in_block in print_frame

The author of 'mold' pointed out that with a certain shared library,
gdb would fail to find the shared library's name in 'bt'.

The function in question appeared at the end of the .so's .text
segment and ended with a call to 'abort'.

This turned out to be a classic case of calling get_frame_pc when
get_frame_address_in_block is needed -- the former will be off-by-one
for purposes of finding the enclosing function or shared library.

The included test fails without the patch on my system.  However, I
imagine it can't be assumed to reliably fail.  Nevertheless it seemed
worth doing.

Regression tested on x86-64 Fedora 38.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29074
Reviewed-by: Kevin Buettner <kevinb@redhat.com>

opcodes i386 and ia64 gen file warnings

i386: warning: format ‘%u’ expects argument of type ‘unsigned int’,
but argument 4 has type ‘size_t’ {aka ‘long unsigned int’} [-Wformat=]
ia64: warning: ignoring return value of ‘fgets’

* i386-gen.c (process_i386_opcodes): Correct format string.
* ia64-gen.c (load_insn_classes, load_depfile): Don't ignore
fgets return value.

ld STRINGIFY

Delete support for old compilers that don't support string
concatentation.

* Makefile.am (stringify.sed): Delete rule.
(GEN_DEPENDS, DISTCLEANFILES): Adjust.
* configure.ac (STRINGIFY): Delete.
* emultempl/beos.em: Use stringify.sed from srcdir.
* emultempl/elf.em: Likewise.
* emultempl/generic.em: Likewise.
* emultempl/msp430.em: Likewise.
* emultempl/pdp11.em: Likewise.
* emultempl/pe.em: Likewise.
* emultempl/pep.em: Likewise.
* emultempl/stringify.sed: Renamed from..
* emultempl/astring.sed: ..this.
* emultempl/ostring.sed: Delete.
* Makefile.in: Regenerate.
* configure: Regenerate.

Automatic date update in version.in

ld .deps/*.Pc files

This patch gets rid of the individual rules including the .Pc
dependency files made while generating e*.c files, replacing them with
a fancy GNU make pattern include.  I've also moved creation of
ldscripts to the makefile since it is possible to run more than one
genscripts at once, resulting in "ldscripts: File exists" messages.

* Makefile.am: Replace individual include of *.Pc dependency
files with one pattern rule.
(.Pc): New dummy rule.
(ldscripts/stamp): New rule.
(GEN_DEPENDS): Add ldscripts/stamp.
(install-data-local): Exclude ldscripts/stamp from install.
* genscripts.sh: Don't make ldscripts dir.
* Makefile.in: Regenerate.