sim: msp430: move arch-specific file compilation to top-level

sim: moxie: move arch-specific file compilation to top-level

The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.

sim: mn10300: move arch-specific file compilation to top-level

The arch-specific compiler flags are duplicated, but they'll be cleaned
up once we move all subdir compiles to the top-level.

sim: mips: move arch-specific file compilation to top-level

The arch-specific compiler flags are duplicated, but they'll be cleaned
up once we move all subdir compiles to the top-level.

sim: microblaze: move arch-specific file compilation to top-level

sim: mcore: move arch-specific file compilation to top-level

sim: m68hc11: move arch-specific file compilation to top-level

The arch-specific compiler flags are duplicated, but they'll be cleaned
up once we move all subdir compiles to the top-level.

sim: m32r: move arch-specific file compilation to top-level

sim: m32c: move arch-specific file compilation to top-level

The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.

sim: lm32: move arch-specific file compilation to top-level

sim: iq2000: move arch-specific file compilation to top-level

sim: h8300: move arch-specific file compilation to top-level

sim: ft32: move arch-specific file compilation to top-level

sim: frv: move arch-specific file compilation to top-level

The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.

sim: example-synacor: move arch-specific file compilation to top-level

sim: erc32: move arch-specific file compilation to top-level

The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.

sim: d10v: move arch-specific file compilation to top-level

sim: cris: move arch-specific file compilation to top-level

sim: cr16: move arch-specific file compilation to top-level

sim: bfin: move arch-specific file compilation to top-level

The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.

sim: bpf: move arch-specific file compilation to top-level

We can drop the arch-specific rules from the subdir as they're no
longer used.

sim: avr: move arch-specific file compilation to top-level

sim: arm: move arch-specific file compilation to top-level

The arch-specific flags are only used by the arch-specific modules,
not the common/ files, so we can delete them too.

sim: aarch64: move arch-specific file compilation to top-level

sim: build: add basic framework for compiling arch objects in top-level

The code so far has been assuming that we only compile common/ objects.
Now that we're ready to compile arch-specific objects, refactor some of
the flags & checks a bit to support both.

sim: modules.c: move generation to top-level

Now that all arches create libsim.a from the top-level, we have full
access to their inputs, and can move the actual generation from the
subdir up to the top-level.  This avoids recursive makes and will
help simplify state passing between the two.

sim: build: drop common/nrun.o subdir hack

Now that all the subdirs handle their own builds, we can drop this
common rule as it's unused, and we don't want to use it anymore.

sim: build: drop support for creating libsim.a in subdirs

Now that all ports have moved to creating libsim.a in the top-level,
drop all the support code to create it in a subdir.

sim: v850: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: sh: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: rx: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: rl78: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: riscv: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: pru: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: or1k: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: msp430: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: moxie: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: mn10300: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: mips: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

The mips code is a little more tricky than others because, for multi-run
targets, it generates the list of sources & objects on the fly in the
configure script.

sim: microblaze: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: mcore: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: m68hc11: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: m32r: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: m32c: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: lm32: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: iq2000: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: h8300: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: ft32: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: frv: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: example-synacor: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: erc32: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: d10v: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: cris: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: cr16: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: bpf: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: bfin: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: avr: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: arm: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: aarch64: move libsim.a creation to top-level

The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level.  This is a required step before we
can move compilation itself up, and makes it easier to review.

The downside is that each object compile is a recursive make instead of
a single one.  On my 4 core system, it adds ~100msec to the build per
port, so it's not great, but it shouldn't be a big deal.  This will go
away of course once the top-level compiles objects.

sim: build: drop support for subdir extra deps

Nothing uses this hook anymore, so punt it.  It was largely used to
track generated files (which we do in the top-level now) and extra
header files (which we use automake depgen for now).

sim: modules: trigger generation from top-level

Add rules for tracking generated subdir modules.c files.  This doesn't
actually generate the file from the top-level, but allows us to add
rules that need to be ordered wrt it.  Once those changes land, we can
rework this to actually generate from the top-level.

This currently builds off of the objects that go into the libsim.a as
we don't build those from the top-level either.  Once we migrate that
up, we can switch this to the source files directly.  It's a bit hacky
overall, but makes it easier to migrate things in smaller chunks, and
we aren't going to keep this logic long term.

gdb/linespec.c: Fix missing source file during breakpoint re-set

During breakpoint re-setting, the source_filename of an
explicit_location_spec is used to lookup the symtabs associated with
the breakpoint being re-set.  This source_filename is compared with each
known symtab filename in order to retrieve the breakpoint's symtabs.

However the source_filename may have been originally copied from a
symtab's fullname (the path where GDB found the source file) when the
breakpoint was first created.  If a breakpoint symtab's filename and
fullname differ and there is no substitute-path rule that converts the
fullname to the filename, this will cause a NOT_FOUND_ERROR to be thrown
during re-setting.

Fix this by using a symtab's filename to set the explicit_location_spec
source_filename instead of the symtab's fullname.

gdb/linespec.c: Fix -Wmaybe-uninitialized warning

Although the bool want_start_sal isn't actually used without being assigned
a value, initialize it to be false in order to prevent the following
-Wmaybe-uninitialized warning:

    linespec.c: In function ‘void minsym_found(linespec_state*, objfile*, minimal_symbol*, std::vector<symtab_and_line>*)’:
    linespec.c:4150:19: warning: ‘want_start_sal’ may be used uninitialized [-Wmaybe-uninitialized]
     4150 |   if (is_function && want_start_sal)

Automatic date update in version.in

Set dwarf2 stash pointer earlier

This fixes a memory leak in the vanishingly rare cases (found by
fuzzers of course) when something goes wrong in the save_section_vma,
htab_create_alloc or alloc_trie_leaf calls before *pinfo is written.
If *pinfo is not written, _bfd_dwarf2_cleanup_debug_info won't be able
to free that memory.

* dwarf2.c (_bfd_dwarf2_slurp_debug_info): Save stash pointer
on setting up stash.

peXXigen.c sanity checks

Also fix a memory leak, and make some style changes.  I tend to read
(sizeof * x) as a multiplication of two variables, which I would not
do if binutils followed the gcc coding conventions consistently (see
https://gcc.gnu.org/codingconventions.html#Expressions).  (sizeof *x)
looks a lot better to me, or even (sizeof (*x)) which I've used here.

* peXXigen.c (get_contents_sanity_check): New function.
(pe_print_idata): Use it here..
(pe_print_edata): ..and here.  Free data on error return.
(rsrc_parse_entry): Check entry size read from file.
(rsrc_parse_entries): Style fixes.
(rsrc_process_section): Use bfd_malloc_and_get_section.
(_bfd_XXi_final_link_postscript): Likewise.

Move mips_refhi_list to bfd tdata

Similar to commit c799eddb3512, but for mips-ecoff.  mips-ecoff is
marked obsolete, but we still allow reading of these object files in
a number of mips targets.

* coff-mips.c (struct mips_hi, mips_refhi_list): Delete.
(mips_refhi_reloc, mips_reflo_reloc): Access mips_refhi_list
in ecoff_data.
* ecoff.c (_bfd_ecoff_close_and_cleanup): New function.
* libecoff.h (struct mips_hi): Moved from coff-mips.c.
(struct ecoff_tdata): Add mips_refhi_list.
(_bfd_ecoff_close_and_cleanup): Declare.

Move bfd_init to bfd.c

init.c contains just one function that doesn't do much.  Move it to
bfd.c and give it something to do, initialising static state.  So far
the only initialisation is for bfd.c static variables.

The idea behind reinitialising state is to see whether some set of
flaky oss-fuzz crashes go away.  oss-fuzz stresses binutils in ways
that can't occur in reality, feeding multiple testcases into the
internals of binutils.  So one testcase may affect the result of the
next testcase.

* init.c: Delete file.  Move bfd_init to..
* bfd.c (bfd_init): ..here.  Init static variables.
* Makefile.am (BFD32_LIBS): Remove init.lo.
(BFD32_LIBS_CFILES, BFD_H_FILES): Remove init.c.
* doc/local.mk: Remove mention of init.texi and init.c.
* Makefile.in: Regenerate.
* bfd-in2.h: Regenerate.
* po/SRC-POTFILES.in: Regenerate.

Fix crash with C++ qualified names

PR c++/29503 points out that something like "b->Base::member" will
crash when 'b' does not have pointer type.  This seems to be a simple
oversight in eval_op_member.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29503
Reviewed-By: Bruno Larsen <blarsen@redhat.com>

gdb/doc: fix @code{GDBN} -> @value{GDBN}

Change-Id: I928d6f8d6e6bc41d8c7ddbfae8f6ae0614f4993e

Skip ld/pr23169 test on arm.

The test is already skipped on several targets (including AArch64)
because it's invalid.

* testsuite/ld-ifunc/ifunc.exp: Skip pr23169 on arm.

Fix PR18841 ifunc relocation ordering

In order to get the ifunc relocs properly sorted the correct class
needs to be returned.  The code mimics what has been done for AArch64.

Fixes:
FAIL: Run pr18841 with libpr18841b.so
FAIL: Run pr18841 with libpr18841c.so
FAIL: Run pr18841 with libpr18841bn.so (-z now)
FAIL: Run pr18841 with libpr18841cn.so (-z now)

bfd/
PR ld/18841
* elf32-arm.c (elf32_arm_reloc_type_class): Return
reloc_class_ifunc for ifunc symbols.

ld/testsuite/
* ld-arm/ifunc-12.rd: Update relocations order.
* ld-arm/ifunc-3.rd: Likewise.
* ld-arm/ifunc-4.rd: Likewise.

Updated transaltions for the gprof and binutils sub-directories

testsuite: add -O0 to Intel compilers if no 'optimize' option is given

icpx/icx give the following warning if '-g' is used without '-O'.

   icpx: remark: Note that use of '-g' without any optimization-level
   option will turn off most compiler optimizations similar to use of
   '-O0'; use '-Rno-debug-disables-optimization' to disable this
   remark [-Rdebug-disables-optimization]

The warning makes dejagnu think that compilation has failed.  E.g.:

  $ make check TESTS="gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
  ...
  gdb compile failed, icpx: remark: Note that use of '-g' without any optimization-level option will turn off most compiler optimizations similar to use of '-O0'; use '-Rno-debug-disables-optimization' to disable this remark [-Rdebug-disables-optimization]

                  === gdb Summary ===

  # of untested testcases         1

Furthermore, if no -O flag is passed, icx/icc optimize
the code by default.  This breaks assumptions in many GDB tests
that the code is unoptimized by default.  E.g.:

  $ make check TESTS="gdb.cp/cmpd-minsyms.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
  ...
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::a() const'
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::b() volatile'
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at 'GDB<int>::c() const volatile'
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator ==
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::operator==(GDB<int> const&)
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<char>::harder(char)
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::harder(int)
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at "int GDB<char>::even_harder<int>(char)"
  FAIL: gdb.cp/cmpd-minsyms.exp: gdb_breakpoint: set breakpoint at GDB<int>::simple()

                  === gdb Summary ===

  # of expected passes            1
  # of unexpected failures        9

To fix both problems, pass the -O0 flag explicitly, if no optimization
option is given.

With this patch we get, e.g.:

  $ make check TESTS="gdb.cp/cmpd-minsyms.exp gdb.cp/local.exp" RUNTESTFLAGS="CXX_FOR_TARGET='icpx' CC_FOR_TARGET=icx"
  ...
                  === gdb Summary ===

  # of expected passes            19
  # of known failures             1

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

testsuite: handle icc and icpc deprecated remarks

Starting with icc/icpc version 2021.7.0 and higher both compilers emit a
deprecation remark when used.  E.g.

  >> icc --version
  icc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is
  deprecated and will be removed from product release in the second half
  of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended
  compiler moving forward. Please transition to use this compiler. Use
  '-diag-disable=10441' to disable this message.
  icc (ICC) 2021.7.0 20220713
  Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

  >> icpc --version
  icpc: remark #10441: The Intel(R) C++ Compiler Classic (ICC) is
  deprecated ...
  icpc (ICC) 2021.7.0 20220720
  Copyright (C) 1985-2022 Intel Corporation.  All rights reserved.

As the testsuite compile fails when unexpected output by the compiler is
seen this change in the compiler breaks all existing icc and icpc tests.
This patch makes the gdb testsuite more forgiving by a) allowing the
output of the remark when trying to figure out the compiler version
and by b) adding '-diag-disable=10441' to the compile command whenever
gdb_compile is called without the intention to detect the compiler.

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

Automatic date update in version.in

PR29972, inconsistent format specification in singular form

PR 29972
* readelf.c (process_dynamic_section): Correct format string.

Automatic date update in version.in

Automatic date update in version.in

sframe: fix the defined SFRAME_FRE_TYPE_*_LIMIT constants

An earlier commit 3f107464 defined the SFRAME_FRE_TYPE_*_LIMIT
constants.  These constants are used (by gas and libsframe) to pick an
SFrame FRE type based on the function size.  Those constants, however,
were buggy, causing the generated SFrame sections to be bloated as
SFRAME_FRE_TYPE_ADDR2/SFRAME_FRE_TYPE_ADDR4 got chosen more often than
necessary.

gas/
* sframe-opt.c (sframe_estimate_size_before_relax): Use
typecast.
(sframe_convert_frag): Likewise.

libsframe/
* sframe.c (sframe_calc_fre_type): Use a more appropriate type
for argument.  Adjust the check for SFRAME_FRE_TYPE_ADDR4_LIMIT
to keep it warning-free but meaningful.

include/
* sframe-api.h (sframe_calc_fre_type): Use a more appropriate
type for the argument.
* sframe.h (SFRAME_FRE_TYPE_ADDR1_LIMIT): Correct the constant.
(SFRAME_FRE_TYPE_ADDR2_LIMIT): Likewise.
(SFRAME_FRE_TYPE_ADDR4_LIMIT): Likewise.

libsframe: adjust an incorrect check in flip_sframe

When sframe_encoder_write needs to flip the buffer containing the SFrame
section before writing, it is not necessary that the SFrame FDES are in
the order of their sfde_func_start_fre_off.  On the contrary, SFrame
FDEs will be sorted in the order of their start address.  So, remove
this incorrect assumption which is basically assuming that the last
sfde_func_start_fre_off seen will help determine the end of the flipped
buffer.

The function now keeps track of the bytes_flipped and then compares it with
the expected value.  Also, added two more checks at appropriate places:
 - check that the SFrame FDE read is within bounds
 - check that the SFrame FRE read is within bounds

libsframe/

* sframe.c (flip_sframe): Adjust an incorrect check.
Add other checks to ensure reads are within the buffer size.

ld: yet another PDB build fix (or workaround)

Older bash looks to improperly deal with backslashes in here-documents,
leaving them in place on the escaped double quotes inside the parameter
expansion. Convert to a model without using such a construct, by simply
splitting the here-documents into three ones.

Updated Bulgarian and Russian translations for LD and BFD respectively

Fix an aout memory leak

* aoutx.h (aout_bfd_free_cached_info): Free line_buf.

Tidy pe flag in coff_data

Make it a bool, use obj_pe accessor everywhere.

Make coff backend data read-only

The bfd_coff_backend_data struct should be read-only, the only thing
preventing this is that objcopy writes to one of the fields,
_bfd_coff_long_section_names.  This patch creates a copy of the field
in bfd coff_obj_tdata, which makes more sense anyway.  When enabling
long section names the intent is to do so for a particular bfd, not
for all bfds that might happen to be using the target xvec.

bfd/
* coffcode.h: Update coff long section name comment.
(bfd_coff_set_long_section_names_allowed): Use macro accessor
to set flag.
(bfd_coff_set_long_section_names_disallowed): Tidy.
(coff_backend_info): Return a const pointer.
(bfd_coff_std_swap_table, ticoff0_swap_table, ticoff1_swap_table),
(bigobj_swap_table): Make const.
(bfd_coff_long_section_names): Use tdata copy.
(coff_mkobject): Set long_section_names from coff_backend_info.
* coff-go32.c (_bfd_go32_mkobject): Likewise.
* peicode.h (pe_mkobject): Likewise.
* coff-sh.c (bfd_coff_small_swap_table): Make const.
* libcoff-in.h (struct coff_tdata): Add long_section_names,
reorder fields.
* libcoff.h: Regenerate.
binutils/
* objcopy.c (set_long_section_mode): Move earlier in file.
(copy_object): Call set_long_section_mode here, after setting
output format.
(copy_file): Don't call set_long_section_mode.

gdb/c++: Detect ambiguous variables in imported namespaces

When running gdb.cp/nsusing.cc and stopping at line 17, we can ask GDB
to print x and get a compiler-dependent answer. Using gcc 12.2.1, GDB
will print M::x, and using clang 16.0.0 prints N::x. Not only is this
behavior confusing to users, it is also not consistent with compiler
behaviors, which would warn that using x is ambiguous at this point.

This commit makes GDB behavior consistent with compilers. it achieves
this by making it so instead of exiting early when finding any symbol
with the correct name, GDB continues searching through all include
directives, storing all matching symbols in a relational map betwen the
mangled name and the found symbols.

If the resulting map has more than one entry, GDB says that the
reference is ambiguous and lists all possibilities. Otherwise it returns
the block_symbol structure for the desired symbol, or an empty struct if
nothing was found.

The commit also changes gdb.cp/nsusing.exp to test the ambiguous
detection.

gdb/mi: add no-history stop reason

When executing in reverse and runs out of recorded history, GDB prints
a warning to the user, but does not add a reason in the stopped record,
for example:

*stopped,frame={addr="0x000000000040113e",func="main",args=[],file="/home/blarsen/Documents/fsf_build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.reverse/solib-reverse.c",fullname="/home/blarsen/Documents/binutils-gdb/gdb/testsuite/gdb.reverse/solib-reverse.c",line="27",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="1"

This problem was reported as record/29260.

This commit adds the reason no-history to the record, making it easier
for interfaces using the mi interpreter to report the result.  It also
changes the test gdb.mi/mi-reverse.exp to test that the reason shows up
correctly.

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

gdb/testsuite: Fix FAILs in gdb.linespec/cpcompletion.exp when using clang

When using clang 16.0.0 to test gdb.linespec/cpcompletion.exp, I get 99
unexpected failures.  They all fail to produce a complete list of
completion options for a function, either overload2_function,
overload3_function or anon_ns_function.  This happens because clang is
optimizing them away, since they are never used.

Fix this by adding __attribute__((used)) to all declarations to the
aforementioned functions.

configure: remove dependencies on gmp and mpfr when gdb is disabled

Since 991180627851801f1999d1ebbc0e569a17e47c74, the configure checks
about GMP and MPFR for gdb builds have been moved to the toplevel
configure.
However, it doesn't take into account the --disable-gdb option. Meaning
that a build without gdb will require these libraries even if not
needed.

ChangeLog:

* configure.ac: Skip GMP and MPFR when --disable-gdb is
provided.
* configure: Regenerate.

Automatic date update in version.in

gdbsupport: fix scoped_debug_start_end's move constructor

I spotted a problem with scoped_debug_start_end's move constructor.
When constructing a scoped_debug_start_end through it, it doesn't
disable the moved-from object, meaning there are now two objects that
will do the side-effects of decrementing the debug_print_depth global
and printing the "end" message.  Decrementing the debug_print_depth
global twice is actually problematic, because the increments and
decrements get out of sync, meaning we should hit this assertion, in
theory:

    gdb_assert (debug_print_depth > 0);

However, in practice, we don't see that.  This is because despite the
move constructor being required for this to compile:

    template<typename PT>
    static inline scoped_debug_start_end<PT &> ATTRIBUTE_NULL_PRINTF (6, 7)
    make_scoped_debug_start_end (PT &&pred, const char *module, const char *func,
          const char *start_prefix,
          const char *end_prefix, const char *fmt, ...)
    {
      va_list args;
      va_start (args, fmt);
      auto res = scoped_debug_start_end<PT &> (pred, module, func, start_prefix,
        end_prefix, fmt, args);
      va_end (args);

      return res;
    }

... it is never actually called, because compilers elide the move
constructors all the way (the scoped_debug_start_end gets constructed
directly in the instance of the top-level caller).  To confirm this, I
built GDB with -fno-elide-constructors, and now I see it:

    /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:147: internal-error: ~scoped_debug_start_end: Assertion `debug_print_depth > 0' failed.

    #9  0x00005614ba5f17c3 in internal_error_loc (file=0x5614b8749960 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h", line=147, fmt=0x5614b8733fa0 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:58
    #10 0x00005614b8e1b2e5 in scoped_debug_start_end<bool&>::~scoped_debug_start_end (this=0x7ffc6c5e7b40, __in_chrg=<optimized out>) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:147
    #11 0x00005614b96dbe34 in make_scoped_debug_start_end<bool&> (pred=@0x5614baad7200: true, module=0x5614b891d840 "infrun", func=0x5614b891d800 "infrun_debug_show_threads", start_prefix=0x5614b891d7c0 "enter", end_prefix=0x5614b891d780 "exit", fmt=0x0) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/common-debug.h:235

Fix this by adding an m_disabled field to scoped_debug_start_end, and
setting it in the move constructor.

Change-Id: Ie5213269c584837f751d2d11de831f45ae4a899f

gdbsupport: add gdb::string_view_hash

Add the string_view_hash type, which will be useful to be able to use
gdb::string_view as std::unordered_map keys.

Use it in gdb/symtab.c, to exercise it.

Change-Id: Id69a466ab19a9f6620b5df8a2dd29b5cddd94c00
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdbsupport: move fast_hash to gdbsupport/common-utils.h

The following patch adds a hash type for gdb::string_view in gdbsupport,
which will use the fast_hash function.  Move the latter to gdbsupport.

Change-Id: Id74510e17801e775bd5ffa5f443713d79adf14ad
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdbsupport: move libxxhash configure check to gdbsupport

The following patch moves the fast_hash function, which uses libxxhash,
to gdbsupport.  Move the libxxhash configure check to gdbsupport (and
transitively to gdbserver).

Change-Id: I242499e50c8cd6fe9f51e6e92dc53a1b3daaa96e
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb: make gdbarch_alloc take ownership of the tdep

It's currently not clear how the ownership of gdbarch_tdep objects
works.  In fact, nothing ever takes ownership of it.  This is mostly
fine because we never free gdbarch objects, and thus we never free
gdbarch_tdep objects.  There is an exception to that however: when
initialization fails, we do free the gdbarch object that is not going to
be used, and we free the tdep too.  Currently, i386 and s390 do it.

To make things clearer, change gdbarch_alloc so that it takes ownership
of the tdep.  The tdep is thus automatically freed if the gdbarch is
freed.

Change all gdbarch initialization functions to pass a new gdbarch_tdep
object to gdbarch_alloc and then retrieve a non-owning reference from
the gdbarch object.

Before this patch, the xtensa architecture had a single global instance
of xtensa_gdbarch_tdep.  Since we need to pass a dynamically allocated
gdbarch_tdep_base instance to gdbarch_alloc, remove this global
instance, and dynamically allocate one as needed, like we do for all
other architectures.  Make the `rmap` array externally visible and
rename it to the less collision-prone `xtensa_rmap` name.

Change-Id: Id3d70493ef80ce4bdff701c57636f4c79ed8aea2
Approved-By: Andrew Burgess <aburgess@redhat.com>

gdb/testsuite: add back needed -re clause in gdb_breakpoint

Commit 4b9728be ("gdb: use gdb_test_multiple in gdb_breakpoint") caused,
amongst others:

   (gdb) break 1^M
   No line 1 in the current file.^M
   Make breakpoint pending on future shared library load? (y or [n]) n^M
   (gdb) FAIL: gdb.dwarf2/dw2-main-no-line-number.exp: gdb_breakpoint: set breakpoint at 1
   FAIL: gdb.dwarf2/dw2-main-no-line-number.exp: !$breakpoint_at_missing_lineno_set

This is because it removed one empty -re clause (matching just the
prompt) that is necessary after replying "n" to the pending breakpoint
question.  Add this clause back.

Change-Id: Ibfaa059d58bbea660bc29f0547e2f75c323fcbc6
Approved-By: Tom de Vries <tdevries@suse.de>

[gdb/python] Avoid queue.SimpleQueue for python 3.6

On openSUSE Leap 15.4 with python 3.6, the gdb.dap/basic-dap.exp test-case
fails as follows:
...
ERROR: eof reading json header
    while executing
"error "eof reading json header""
    invoked from within
"expect {
-i exp19 -timeout 10
        -re "^Content-Length: (\[0-9\]+)\r\n" {
            set length $expect_out(1,string)
            exp_continue
        }
        -re "^(\[^\r\n\]+)..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $body" NONE eof reading json header
UNRESOLVED: gdb.dap/basic-dap.exp: startup - initialize
...

Investigation using a "catch throw" shows that:
...
(gdb)
    at gdb/python/py-utils.c:396
396             error (_("Error occurred in Python: %s"), msg.get ());
(gdb) p msg.get ()
$1 = 0x2b91d10 "module 'queue' has no attribute 'SimpleQueue'"
...

The python class queue.SimpleQueue was introduced in python 3.7.

Fix this by falling back to queue.Queue for python <= 3.6.

Tested on x86_64-linux, by successfully running the test-case:
...
 # of expected passes            47
...

Add type to expression dump of symbol

I recently had cause to dump some expressions from gdb.  I got output
like this:

 Operation: BINOP_GTR
  Operation: OP_VAR_VALUE
   Block symbol:
    Symbol: small_value
    Block: 0x39b4c20
  Operation: OP_LONG
   Operation: OP_LONG
    Type: int
    Constant: 0x0000000000000014

This is ok, but it would have been handy to see the type of the
symbol.  This patch adds this information.

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

Remove Stephen Casner as the PDP11 maintainer.