Fix ARM_CC_FOR_TARGET handling

The previous patch that introduced the arm_cc_for_target procedure
moved the ARM_CC_FOR_TARGET global check to that procedure, but forgot
to tell tcl that ARM_CC_FOR_TARGET is a global.  As a result,
specifying ARM_CC_FOR_TARGET on the command line actually does
nothing.  This fixes it.

Change-Id: I4e33b7633fa665e2f7b8f8c9592a949d74a19153

gdb/arm: Terminate unwinding when LR is 0xffffffff

ARMv7-M Architecture Reference "A2.3.1 Arm core registers" states
that LR is set to 0xffffffff on reset.

ARMv8-M Architecture Reference "B3.3 Registers" states that LR is set
to 0xffffffff on warm reset if Main Extension is implemented,
otherwise the value is unknown.

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

gdb/testsuite: solve problems with compiler_info caching

After this commit:

  commit 44d469c5f85a4243462b8966722dafa62b602bf5
  Date:   Tue May 31 16:43:44 2022 +0200

      gdb/testsuite: add Fortran compiler identification to GDB

Some regressions were noticed:

  https://sourceware.org/pipermail/gdb-patches/2022-May/189673.html

The problem is associated with how compiler_info variable is cached
between calls to get_compiler_info.

Even before the above commit, get_compiler_info supported two
language, C and C++.  Calling get_compiler_info would set the global
compiler_info based on the language passed as an argument to
get_compiler_info, and, in theory, compiler_info would not be updated
for the rest of the dejagnu run.

This obviously is slightly broken behaviour.  If the first call to
get_compiler_info was for the C++ language then compiler_info would be
set based on the C++ compiler in use, while if the first call to
get_compiler_info was for the C language then compiler_info would be
set based on the C compiler.

This probably wasn't very noticable, assuming a GCC based test
environment then in most cases the C and C++ compiler would be the
same version.

However, if the user starting playing with CC_FOR_TARGET or
CXX_FOR_TARGET, then they might not get the behaviour they expect.

Except, to make matters worse, most of the time, the user probably
would get the behaviour they expected .... except when they didn't!
I'll explain:

In gdb.exp we try to avoid global variables leaking between test
scripts, this is done with the help of the two procs
gdb_setup_known_globals and gdb_cleanup_globals.  All known globals
are recorded before a test script starts, and then, when the test
script ends, any new globals are deleted.

Normally, compiler_info is only set as a result of a test script
calling get_compiler_info or test_compiler_info.  This means that the
compiler_info global will not exist when the test script starts, but
will exist when the test script end, and so, the compiler_info
variable is deleted at the end of each test.

This means that, in reality, the compiler_info is recalculated once
for each test script, hence, if a test script just checks on the C
compiler, or just checks on the C++ compiler, then compiler_info will
be correct and the user will get the behaviour they expect.

However, if a single test script tries to check both the C and C++
compiler versions then this will not work (even before the above
commit).

The situation is made worse be the behaviour or the load_lib proc.
This proc (provided by dejagnu) will only load each library once.
This means that if a library defines a global, then this global would
normally be deleted at the end of the first test script that includes
the library.

As future attempts to load the library will not actually reload it,
then the global will not be redefined and would be missing for later
test scripts that also tried to load that library.

To work around this issue we override load_lib in gdb.exp, this new
version adds all globals from the newly loaded library to the list of
globals that should be preserved (not deleted).

And this is where things get interesting for us.  The library
trace-support.exp includes calls, at the file scope, to things like
is_amd64_regs_target, which cause get_compiler_info to be called.
This means that after loading the library the compiler_info global is
defined.

Our override of load_lib then decides that this new global has to be
preserved, and adds it to the gdb_persistent_globals array.

From that point on compiler_info will never be recomputed!

This commit addresses all the caching problems by doing the following:

Change the compiler_info global into compiler_info_cache global.  This
new global is an array, the keys of this array will be each of the
supported languages, and the values will be the compiler version for
that language.

Now, when we call get_compiler_info, if the compiler information for
the specific language has not been computed, then we do that, and add
it to the cache.

Next, compiler_info_cache is defined by calling
gdb_persistent_global.  This automatically adds the global to the list
of persistent globals.  Now the cache will not be deleted at the end
of each test script.

This means that, for a single test run, we will compute the compiler
version just once for each language, this result will then be cached
between test scripts.

Finally, the legacy 'gcc_compiled' flag is now only set when we call
get_compiler_info with the language 'c'.  Without making this change
the value of 'gcc_compiled' would change each time a new language is
passed to get_compiler_info.  If the last language was e.g. Fortran,
then gcc_compiled might be left false.

gdb/testsuite: handle errors better in test_compiler_info

Now that get_compiler_info might actually fail (if the language is not
handled), then we should try to handle this failure better in
test_compiler_info.

After this commit, if get_compiler_info fails then we will return a
suitable result depending on how the user called test_compiler_info.

If the user does something like:

  set version [test_compiler_info "" "unknown-language"]

Then test_compiler_info will return an empty string.  My assumption is
that the user will be trying to match 'version' against something, and
the empty string hopefully will not match.

If the user does something like:

  if { [test_compiler_info "some_pattern" "unknown-language"] } {
    ....
  }

Then test_compiler_info will return false which seems the obvious
choice.

There should be no change in the test results after this commit.

gdb/testsuite: make 'c' default language for get/test compiler info

This commit is a minor cleanup for the two functions (in gdb.exp)
get_compiler_info and test_compiler_info.

Instead of using the empty string as the default language, and just
"knowing" that this means the C language.  Make this explicit.  The
language argument now defaults to "c" if not specified, and the if
chain in get_compiler_info that checks the language not explicitly
handles "c" and gives an error for unknown languages.

This is a good thing, now that the API appears to take a language, if
somebody does:

  test_compiler_info "xxxx" "rust"

to check the version of the rust compiler then we will now give an
error rather than just using the C compiler and leaving the user
having to figure out why they are not getting the results they
expect.

After a little grepping, I think the only place we were explicitly
passing the empty string to either get_compiler_info or
test_compiler_info was in gdb_compile_shlib_1, this is now changed to
pass "c" as the default language.

There should be no changes to the test results after this commit.

gdb/testsuite: remove get_compiler_info calls from gdb.exp and dwarf.exp

We don't need to call get_compiler_info before calling
test_compiler_info; test_compiler_info includes a call to
get_compiler_info.

This commit cleans up lib/gdb.exp and lib/dwarf.exp a little by
removing some unneeded calls to get_compiler_info.  We could do the
same cleanup throughout the testsuite, but I'm leaving that for
another day.

There should be no change in the test results after this commit.

gdb/testsuite: use test_compiler_info in gcc_major_version

The procedure gcc_major_version was earlier using the global variable
compiler_info to retrieve gcc's major version.  This is discouraged and
(as can be read in a comment in compiler.c) compiler_info should be
local to get_compiler_info and test_compiler_info.

The preferred way of getting the compiler string is via calling
test_compiler_info without arguments.  Gcc_major_version was changed to
do that.

gdb: add Yvan Roux to gdb/MAINTAINERS

gdb/testsuite: resolve duplicate test names in gdb.threads/tls.exp

While running the gdb.threads/tls.exp test with a GDB configured
without Python, I noticed some duplicate test names.

This is caused by a call to skip_python_tests that is within a proc
that is called multiple times by the test script.  Each call to
skip_python_tests results in a call to 'unsupported', and this causes
the duplicate test names.

After this commit we now call skip_python_tests just once and place
the result into a variable.  Now, instead of calling skip_python_tests
multiple times, we just check the variable.

There should be no change in what is tested after this commit.

gdb/testsuite: resolve duplicate test name in gnu_vector.exp

While testing on AArch64 I spotted a duplicate test name in the
gdb.base/gnu_vector.exp test.

This commit adds a 'with_test_prefix' to resolve the duplicate.

While I was in the area I updated a 'gdb_test_multiple' call to make
use of $gdb_test_name.

There should be no change in what is tested after this commit.

Automatic date update in version.in

gdb: make throw_perror_with_name static

The throw_perror_with_name function is not used outside of utils.c
right now.  And as perror_with_name is just a wrapper around
throw_perror_with_name, then any future calls would be to
perror_with_name.

Lets make throw_perror_with_name static.

There should be no user visible changes after this commit.

gdb: remove trailing '.' from perror_with_name calls

I ran into this error while working on AArch64 GDB:

  Unable to fetch VFP registers.: Invalid argument.

Notice the '.:' in the middle of this error message.

This is because of this call in aarch64-linux-nat.c:

  perror_with_name (_("Unable to fetch VFP registers."));

The perror_with_name function take a string, and adds ': <message>' to
the end the string, so I don't think the string that we pass to
perror_with_name should end in '.'.

This commit removes all of the trailing '.' characters from
perror_with_name calls, which give more readable error messages.

I don't believe that any of these errors are tested in the
testsuite (after a little grepping).

Move CU queue to dwarf2_per_objfile

The CU queue is a member of dwarf2_per_bfd, but it is only used when
expanding CUs.  Also, the dwarf2_per_objfile destructor checks the
queue -- however, if the per-BFD object is destroyed first, this will
not work.  This was pointed out Lancelot as fallout from the patch to
rewrite the registry system.

This patch avoids this problem by moving the queue to the per-objfile
object.

Change allocation of m_dwarf2_cus

m_dwarf2_cus manually manages the 'dwarf2_cu' pointers it owns.  This
patch simplifies the code by changing it to use unique_ptr.

libopcodes: extend the styling within the i386 disassembler

The i386 disassembler is pretty complex.  Most disassembly is done
indirectly; operands are built into buffers within a struct instr_info
instance, before finally being printed later in the disassembly
process.

Sometimes the operand buffers are built in a different order to the
order in which they will eventually be printed.

Each operand can contain multiple components, e.g. multiple registers,
immediates, other textual elements (commas, brackets, etc).

When looking for how to apply styling I guess the ideal solution would
be to move away from the operands being a single string that is built
up, and instead have each operand be a list of "parts", where each
part is some text and a style.  Then, when we eventually print the
operand we would loop over the parts and print each part with the
correct style.

But it feels like a huge amount of work to move from where we are
now to that potentially ideal solution.  Plus, the above solution
would be pretty complex.

So, instead I propose a .... different solution here, one that works
with the existing infrastructure.

As each operand is built up, piece be piece, we pass through style
information.  This style information is then encoded into the operand
buffer (see below for details).  After this the code can continue to
operate as it does right now in order to manage the set of operand
buffers.

Then, as each operand is printed we can split the operand buffer into
chunks at the style marker boundaries, with each chunk being printed
with the correct style.

For encoding the style information I use a single character, currently
\002, followed by the style encoded as a single hex digit, followed
again by the \002 character.

This of course relies on there not being more than 16 styles, but that
is currently true, and hopefully will remain true for the foreseeable
future.

The other major concern that has arisen around this work is whether
the escape character could ever be encountered in output naturally
generated by the disassembler.  If this did happen then the escape
characters would be stripped from the output, and the wrong styling
would be applied.

However, I don't believe that this is currently a problem.
Disassembler content comes from a number of sources.  First there's
content that copied directly from the i386-dis.c file, this is things
like register names, and other syntax elements (brackets, commas,
etc).  We can easily check that the i386-dis.c file doesn't contain
our special character.

The next source of content are immediate operands.  The text for these
operands is generated by calls into libc.  By selecting a
non-printable character we can be confident that this is not something
that libc will generate as part of an immediate representation.

The other output that appears to be from the disassembler is operands
that contain addresses and (possibly) symbol names.  It is quite
possible that a symbol name might contain any special character we
could imagine, so is this a problem?

I don't think it is, we don't actually print address and symbol
operands through the disassembler, instead, the disassembler calls
back to the user (objdump, gdb, etc) to print the address and symbol
on its behalf.  This content is printed directly to the output stream,
it does not pass through the i386 disassembler output buffers.  As a
result, we never check this particular output for styling escape
characters.

In some (not very scientific) benchmarking on my machine,
disassembling a reasonably large (142M) shared library, I'm not seeing
any significant slow down in disassembler speed with this change.

Most instructions are now being fully syntax highlighted when I
disassemble using the --disassembler-color=extended-color option.  I'm
sure that there are probably still a few corner cases that need fixing
up, but we can come back to them later I think.

When disassembler syntax highlighting is not being used, then there
should be no user visible changes after this commit.

Fix gdb.arch/powerpc-power7.exp isel disassembly output.

The following commit changes the output format for the isel instruction on
PowerPC.

   commit dd4832bf3efc1bd1797a6b9188260692b8b0db52     Introduces error in test
   Author: Dmitry Selyutin <ghostmansd@gmail.com>
   Date:   Tue May 24 13:46:35 2022 +0000

       opcodes: introduce BC field; fix isel

       Per Power ISA Version 3.1B 3.3.12, isel uses BC field rather than CRB
       field present in binutils sources. Also, per 1.6.2, BC has the same
       semantics as BA and BB fields, so this should keep the same flags and
       mask, only with the different offset.

       opcodes/
               * ppc-opc.c
               (BC): Define new field, with the same definition as CRB field,
               but with the PPC_OPERAND_CR_BIT flag present.
       gas/
               * testsuite/gas/ppc/476.d: Update.
               * testsuite/gas/ppc/a2.d: Update.
               * testsuite/gas/ppc/e500.d: Update.
               * testsuite/gas/ppc/power7.d: Update.
  <snip>
   --- a/gas/testsuite/gas/ppc/476.d
   +++ b/gas/testsuite/gas/ppc/476.d
   @@ -209,7 +209,7 @@ Disassembly of section \.text:
    .*:    (7c 20 07 8c|8c 07 20 7c)       ici     1
    .*:    (7c 03 27 cc|cc 27 03 7c)       icread  r3,r4
    .*:    (50 83 65 36|36 65 83 50)       rlwimi  r3,r4,12,20,27
    -.*:    (7c 43 27 1e|1e 27 43 7c)       isel    r2,r3,r4,28
    +.*:    (7c 43 27 1e|1e 27 43 7c)       isel    r2,r3,r4,4\*cr7\+lt

The above change breaks the gdb regression test gdb.arch/powerpc-power7.exp
on Power 7, Power 8, Power 9 and Power 10.

This patch updates the regression test gdb.arch/powerpc-power7.exp with
the new expected output for the isel instruction.

The patch has been tested on Power 7 and Power 10 to verify the patch fixes
the test.

aarch64: Add fallback if ARM_CC_FOR_TARGET not set

On Aarch64, you can set ARM_CC_FOR_TARGET to point to the 32-bit
compiler to use when testing gdb.multi/multi-arch.exp and
gdb.multi/multi-arch-exec.exp.  If you don't set it, then those
testcases don't run.

I guess that approximately nobody remembers to set ARM_CC_FOR_TARGET.

This commit adds a fallback.  If ARM_CC_FOR_TARGET is not set, and
testing for Linux, try arm-linux-gnueabi-gcc,
arm-none-linux-gnueabi-gcc, arm-linux-gnueabihf-gcc as 32-bit
compilers, making sure that the produced executable runs on the target
machine before claiming that the compiler produces useful executables.

Change-Id: Iefe5865d5fc84b4032eaff7f4c5c61582bf75c39

Don't encode reloc.size

I expect the encoded reloc.size field originally came from aout
r_length ecoding, but somehow went wrong for 64-bit relocs (which
should have been encoded as 3).  Toss all that out, just use a byte
size instead.  The changes outside of reloc.c in this patch should
make the code independent of how reloc.size is encoded.

* reloc.c (struct reloc_howto_struct): Increase size field by
one bit.  Comment.
(HOWTO_RSIZE): Don't encode size.
(bfd_get_reloc_size): Adjust, and make it an inline function.
(read_reloc, write_reloc): Adjust.
* bfd-in2.h: Regenerate.
* aout-ns32k.c: Include libbfd.h.
(put_reloc): Don't use howto->size directly.  Calculate r_length
using bfd_log2 and bfd_get_reloc_size.
* aoutx.h (swap_std_reloc_out): Likewise.
(aout_link_reloc_link_order): Likewise.
* i386lynx.c (swap_std_reloc_out
* mach-o-i386.c (bfd_mach_o_i386_swap_reloc_out
* pdp11.c (aout_link_reloc_link_order
* coff-arm.c (coff_arm_reloc): Don't use howto->size directly,
use bfd_get_reloc_size instead and adjust switch cases.
* coff-i386.c (coff_i386_reloc): Similarly.
* coff-x86_64.c (coff_amd64_reloc): Likewise.
* cpu-ns32k.c (do_ns32k_reloc): Likewise.
* elf32-arc.c (arc_do_relocation): Likewise.
* elf32-arm.c (elf32_arm_final_link_relocate): Likewise.
* elf32-bfin.c (bfin_bfd_reloc): Likewise.
* elf32-cr16.c (cr16_elf_final_link_relocate): Likewise.
* elf32-cris.c (cris_elf_pcrel_reloc): Likewise.
* elf32-crx.c (crx_elf_final_link_relocate): Likewise.
* elf32-csky.c (csky_elf_relocate_section): Likewise.
* elf32-d10v.c (extract_rel_addend, insert_rel_addend): Likewise.
* elf32-i386.c (elf_i386_relocate_section): Likewise.
* elf32-m32r.c (m32r_elf_generic_reloc): Likewise.
* elf32-nds32.c (nds32_elf_generic_reloc): Likewise.
* syms.c (_bfd_stab_section_find_nearest_line): Likewise.
* coff-rs6000.c (xcoff_ppc_relocate_section): Adjust howto.size.
* coff64-rs6000.c (xcoff64_ppc_relocate_section): Likewise.

bfin reloc offset checks

These all ought to use bfd_reloc_offset_in_range.  In particular, replace
the check using howto->size + 1u.

* elf32-bfin.c (bfin_pcrel24_reloc): Use bfd_reloc_offset_in_range.
(bfin_imm16_reloc, bfin_byte4_reloc, bfin_bfd_reloc),
(bfin_final_link_relocate): Likewise.

Revert reloc howto nits

The "HOWTO size encoding" patch put 1 as the HOWTO size arg for
numerous howtos that are unused, describe dynamic relocs, are markers,
or otherwise are special purpose reloc howtos that don't care about
the size.  The idea was to ensure no howto changed by inspecting
object files.  Revert those changes, making them zero size.

* coff-alpha.c: Give special purpose reloc howtos a size of zero.
* coff-mcore.c, * elf-hppa.h, * elf-m10300.c, * elf32-arm.c,
* elf32-csky.c, * elf32-m32c.c, * elf32-m68k.c, * elf32-mep.c,
* elf32-mips.c, * elf32-ppc.c, * elf32-rx.c, * elf32-s390.c,
* elf32-spu.c, * elf32-tic6x.c, * elf32-tilepro.c, *elf32-vax.c,
* elf32-xtensa.c, * elf64-alpha.c, * elf64-mips.c,
* elf64-mmix.c, * elf64-ppc.c, * elf64-s390.c, * elfn32-mips.c,
* elfxx-loongarch.c, * elfxx-riscv.c, * elfxx-sparc.c,
* elfxx-tilegx.c, * som.c, * vms-alpha.c: Likewise.

HOWTO size encoding

This changes the HOWTO macro to encode the howto.size field from a
value given in bytes.  This of course requires editing all target
uses of HOWTO, a major pain, but makes it a little nicer to specify
new target HOWTOs.  Object files before/after this patch are
unchanged in .data and .rodata.

bfd/
* reloc.c (HOWTO_RSIZE): Encode size in bytes.
(EMPTY_HOWTO): Adjust to keep it all zero.
* aout-ns32k.c, * aoutx.h, * coff-alpha.c, * coff-arm.c,
* coff-i386.c, * coff-mcore.c, * coff-mips.c, * coff-rs6000.c,
* coff-sh.c, * coff-tic30.c, * coff-tic4x.c, * coff-tic54x.c,
* coff-x86_64.c, * coff-z80.c, * coff-z8k.c, * coff64-rs6000.c,
* elf-hppa.h, * elf-m10200.c, * elf-m10300.c, * elf32-arc.c,
* elf32-arm.c, * elf32-avr.c, * elf32-bfin.c, * elf32-cr16.c,
* elf32-cris.c, * elf32-crx.c, * elf32-csky.c, * elf32-d10v.c,
* elf32-d30v.c, * elf32-dlx.c, * elf32-epiphany.c,
* elf32-fr30.c, * elf32-frv.c, * elf32-ft32.c, * elf32-gen.c,
* elf32-h8300.c, * elf32-i386.c, * elf32-ip2k.c, * elf32-iq2000.c,
* elf32-lm32.c, * elf32-m32c.c, * elf32-m32r.c, * elf32-m68hc11.c,
* elf32-m68hc12.c, * elf32-m68k.c, * elf32-mcore.c, * elf32-mep.c,
* elf32-metag.c, * elf32-microblaze.c, * elf32-mips.c,
* elf32-moxie.c, * elf32-msp430.c, * elf32-mt.c, * elf32-nds32.c,
* elf32-nios2.c, * elf32-or1k.c, * elf32-pj.c, * elf32-ppc.c,
* elf32-pru.c, * elf32-rl78.c, * elf32-rx.c, * elf32-s12z.c,
* elf32-s390.c, * elf32-score.c, * elf32-score7.c,
* elf32-sh-relocs.h, * elf32-spu.c, * elf32-tic6x.c,
* elf32-tilepro.c, * elf32-v850.c, * elf32-vax.c,
* elf32-visium.c, * elf32-wasm32.c, * elf32-xc16x.c,
* elf32-xgate.c, * elf32-xstormy16.c, * elf32-xtensa.c,
* elf32-z80.c, * elf64-alpha.c, * elf64-bpf.c, * elf64-gen.c,
* elf64-mips.c, * elf64-mmix.c, * elf64-nfp.c, * elf64-ppc.c,
* elf64-s390.c, * elf64-x86-64.c, * elfn32-mips.c,
* elfnn-aarch64.c, * elfxx-ia64.c, * elfxx-loongarch.c,
* elfxx-mips.c, * elfxx-riscv.c, * elfxx-sparc.c,
* elfxx-tilegx.c, * mach-o-aarch64.c, * mach-o-arm.c,
* mach-o-i386.c, * mach-o-x86-64.c, * pdp11.c, * reloc.c,
* som.c, * vms-alpha.c: Adjust all uses of HOWTO.
* bfd-in2.h: Regenerate.
include/
* elf/arc-reloc.def: Adjust all uses of HOWTO.

HOWTO_RSIZE

Define a helper macro for HOWTO.

       * reloc.c (HOWTO_RSIZE): Define.
       (HOWTO): Use it.
       * bfd-in2.h: Regenerate.

elf64-nfp reloc fix

These are all dummy howtos, there is no reason one of them should
have partial_inplace true.

* elf64-nfp.c (elf_nfp_howto_table <R_NFP_IMMED_LO16_I_B>): Don't
set partial_inplace.

coff-z80 reloc howto fixes

Mostly cosmetic unless attempting to link coff-z80 into another output
format.

* coff-z80.c (howto_table <R_IMM24, R_WORD0, R_WORD1>): Correct size.
(extra_case): Use bfd_{get,put}_24 when applying R_IMM24.

NONE reloc fixes

Make them all zero size standard do-nothing howtos.

* elf32-csky.c (csky_elf_howto_table <R_CKCORE_NONE>): Correct howto.
* elf32-ft32.c (ft32_elf_howto_table <R_FT32_NONE>): Likewise.
* elf32-gen.c (dummy): Likewise.
* elf32-nds32.c (none_howto): Likewise.
* elf32-nios2.c (elf_nios2_r2_howto_table_rel <R_NIOS2_NONE>):
Likewise.
* elf32-pru.c (elf_pru_howto_table_rel <R_PRU_NONE>): Likewise.
* elf32-v850.c (v800_elf_howto_table <R_V810_NONE>): Likewise.
* elf64-gen.c (dummy): Likewise.
* elfn32-mips.c (elf_mips_howto_table_rela <R_MIPS_NONE): Likewise.
* elfxx-mips.c (none_howto): Likewise.
* reloc.c (none_howto): Likewise.

asan: double free sb_kill

oss-fuzz hits a flaky crash with a double-free.  I think this is due
to gas static state not being reinitialised between testcases, a bug
with oss-fuzz not gas.  Anyway, this patch should avoid the problem.

* input-scrub.c (input_scrub_push): Move init of sb_index..
(input_scrub_reinit): ..to here.

Automatic date update in version.in

Use subclasses of windows_process_info

This changes windows_process_info to use virtual methods for its
callbacks, and then changes the two clients of this code to subclass
this class to implement the methods.

I considered using CRTP here, but that would require making the new
structures visible to the compilation of of nat/windows-nat.c.  This
seemed like a bit of a pain, so I didn't do it.

This change then lets us change all the per-inferior globals to be
members of the new subclass.  Note that there can still only be a
single inferior -- currently there's a single global of the new type.
This is just another step toward possibly implementing multi-inferior
for Windows.

It's possible this could be cleaned up further... ideally I'd like to
move more of the data into the base class.  However, because gdb
supports Cygwin and gdbserver does not, and because I don't have a way
to build or test Cygwin, larger refactorings are difficult.

Turn some windows-nat.c static functions into methods

This patch turns some windows-nat.c static functions into methods on
windows_nat_target.  This avoids having to reference the
windows_nat_target singleton in some more spots -- a minor code
cleanup.

Allow ASLR to be disabled on Windows

On Windows, it is possible to disable ASLR when creating a process.
This patch adds code to do this, and hooks it up to gdb's existing
disable-randomization feature.  Because the Windows documentation
cautions that this isn't available on all versions of Windows, the
CreateProcess wrapper function is updated to make the attempt, and
then fall back to the current approach if it fails.

Introduce wrapper for CreateProcess

This is a small refactoring that introduces a wrapper for the Windows
CreateProcess function.  This is done to make the next patch a bit
simpler.

Update my email address in gdb/MAINTAINERS

Constify solib_name_from_address

I noticed that solib_name_from_address returned a non-const string,
but it's more appropriate to return const.  This patch implements
this.  Tested by rebuilding.

[gdb/rust] Add missing _() for error call

In commit 1390b65a1b9 ("[gdb/rust] Fix literal truncation") I forgot to add
_() around a string using in an error call.

Fix this by adding the missing _().

Tested on x86_64-linux.

[gdb] Allow frv::fr300 in selftests

In skip_arch in gdb/selftest-arch.c we skip architecture fr300 because of
PR20946, but the PR has been fixed by commit 0ae60c3ef45 ("Prevent an abort in
the FRV disassembler if the target bfd name is unknown.") in Januari 2017.

Remove the skipping of frv::fr300.

Tested on x86_64-linux.

Automatic date update in version.in

Consolidate "Python API" sections in NEWS

I noticed that the gdb NEWS file had two "Python API" sections in
"Changes since GDB 12".  This patch consolidates the two.  I chose to
preserve the second one, first because it is longer, and second
because I felt that user command changes should come before API
changes.

Simplify varobj "change" logic

varobj used to store 'print_value' as a C string, where NULL was a
valid value, and so it had logic to handle this situation.  However,
at some point this was changed to be a std::string, and so the code
can be simplified in this spot.

Remove "-break-insert -r" tests

PR mi/14270 points out that mi-break.exp has some tests for an
unimplemented "-r" switch for "-break-insert".  This switch was never
implemented, and is not documented -- though it is mentioned in a
comment in the documentation.  This patch removes the test and the doc
comment.

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

[gdb] Name arch selftests more clearly

When running some all archs selftest I get:
...
$ gdb -q -batch -ex "maint selftest unpack_field_as_long"
Running selftest unpack_field_as_long::A6.
...

By now I know that A6 is an arc architecture, but for others that's less
clear.

Fix this by using unpack_field_as_long::arc::A6 instead.

This then introduces redundant names like arm::arm, so try to avoid those,
though I'm not entirely convinced that that's worth the trouble.

This introduces the following new names:
...
+Running selftest unpack_field_as_long::am33_2::am33-2.
+Running selftest unpack_field_as_long::arc::A6.
+Running selftest unpack_field_as_long::arc::A7.
+Running selftest unpack_field_as_long::arc::EM.
+Running selftest unpack_field_as_long::arc::HS.
+Running selftest unpack_field_as_long::arm::ep9312.
+Running selftest unpack_field_as_long::arm::iwmmxt.
+Running selftest unpack_field_as_long::arm::iwmmxt2.
+Running selftest unpack_field_as_long::arm::xscale.
+Running selftest unpack_field_as_long::bpf::xbpf.
+Running selftest unpack_field_as_long::frv::fr400.
+Running selftest unpack_field_as_long::frv::fr450.
+Running selftest unpack_field_as_long::frv::fr500.
+Running selftest unpack_field_as_long::frv::fr550.
+Running selftest unpack_field_as_long::frv::simple.
+Running selftest unpack_field_as_long::frv::tomcat.
+Running selftest unpack_field_as_long::iq2000::iq10.
+Running selftest unpack_field_as_long::m32c::m16c.
+Running selftest unpack_field_as_long::mep::c5.
+Running selftest unpack_field_as_long::mep::h1.
+Running selftest unpack_field_as_long::nds32::n1.
+Running selftest unpack_field_as_long::nds32::n1h.
+Running selftest unpack_field_as_long::nds32::n1h_v2.
+Running selftest unpack_field_as_long::nds32::n1h_v3.
+Running selftest unpack_field_as_long::nds32::n1h_v3m.
+Running selftest unpack_field_as_long::z80::ez80-adl.
+Running selftest unpack_field_as_long::z80::ez80-z80.
+Running selftest unpack_field_as_long::z80::gbz80.
+Running selftest unpack_field_as_long::z80::r800.
+Running selftest unpack_field_as_long::z80::z180.
...

Tested on x86_64-linux.

[gdb] Enable some more print_one_insn selftests

In print_one_insn_test we have this cluster of skipped tests:
...
    case bfd_arch_ia64:
    case bfd_arch_mep:
    case bfd_arch_mips:
    case bfd_arch_tic6x:
    case bfd_arch_xtensa:
      return;
...

Enable some of these, and document in more detail why they're enabled or
skipped.

Likewise, document bfd_arch_or1k because it's an odd case.

Tested on x86_64-linux.

[gdb] Fix maint selftest -v print_one_insn

When running the print_one_insn selftests with -v, I get:
...
$ gdb -q -batch -ex "maint selftest -v print_one_insn"
Running selftest print_one_insn::A6.
.shor   0x783eRunning selftest print_one_insn::A7.
trap_s  0x1Running selftest print_one_insn::ARC600.
.shor   0x783eRunning selftest print_one_insn::ARC601.
Running selftest print_one_insn::ARC700.
trap_s  0x1Running selftest print_one_insn::ARCv2.
trap_s  0x1Running selftest print_one_insn::EM.
trap_s  0x1Running selftest print_one_insn::HS.
trap_s  0x1Running selftest print_one_insn::Loongarch32.
...

The insn is written to gdb_stdout, and there is code in the selftest to add a
newline after the insn, which writes to stream().

The stream() ui_file points into a string buffer, which the disassembler uses
before writing to gdb_stdout, so writing into it after the disassembler has
finished has no effect.

Fix this by using gdb_stdlog and debug_printf (which is what the unit test
infrastructure itself uses) instead, such that we have:
...
Running selftest print_one_insn::A6.
.shor   0x783e
Running selftest print_one_insn::A7.
trap_s  0x1
Running selftest print_one_insn::ARC600.
.shor   0x783e
Running selftest print_one_insn::ARC601.
Running selftest print_one_insn::ARC700.
trap_s  0x1
Running selftest print_one_insn::ARCv2.
trap_s  0x1
Running selftest print_one_insn::Loongarch32.
...

Note: I've also removed the printing of arch_name, which would give
us otherwise the redundant:
...
Running selftest print_one_insn::A6.
arc .shor       0x783e
Running selftest print_one_insn::A7.
arc trap_s      0x1
...

Tested on x86_64-linux.

gdb/testsuite: add missing skip_python_tests call in py-doc-reformat.exp

In commit:

  commit 51e8dbe1fbe7d8955589703140ca5eba7b4f1bd7
  Date:   Mon May 16 19:26:54 2022 +0100

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

the test that was added (gdb.python/py-doc-reformat.exp) was missing a
call to skip_python_tests.  As a result, this test would fail for any
GDB built within Python support.

This commit adds a call to skip_python_tests.

Automatic date update in version.in

Remove obsolete Python 2 comment

I found a comment that referred to Python 2, but that is now obsolete
-- the code it refers to is gone.  I'm checking in this patch to
remove the comment.

There's a similar comment elsewhere, but I plan to remove that one in
another patch I'm going to submit shortly.

Automatic date update in version.in

asan: null dereference in coff_count_linenumbers

* coffgen.c (coff_count_linenumbers): Don't segfault when asymbol
the_bfd is NULL.

asan: uninitialised write in bfd_mach_o_write_contents

* mach-o.c (bfd_mach_o_write_contents): Always set
bfd_mach_o_dyld_info_command *_off fields.

[gdb/ada] Fix literal truncation

Make sure we error out on overflow instead of truncating in all cases.

Tested on x86_64-linux, with a build with --enable-targets=all.

[gdb/m2] Fix UB and literal truncation

Rewrite parse_number to use ULONGEST instead of LONGEST, to fix UB errors as
mentioned in PR29163.

Furthermore, make sure we error out on overflow instead of truncating in all
cases.

Tested on x86_64-linux, with a build with --enable-targets=all.

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

[gdb/rust] Fix literal truncation

Make sure we error out on overflow instead of truncating in all cases.

I've used as overflow string: "Integer literal is too large", based
on what I found at
<rust-lang/rust>/src/test/ui/parser/int-literal-too-large-span.rs
but perhaps someone has a better idea.

Tested on x86_64-linux, with a build with --enable-targets=all.

[gdb/pascal] Fix literal truncation

Make sure we error out on overflow instead of truncating in all cases.

The current implementation of parse_number contains a comment about PR16377,
but that's related to C-like languages.  In absence of information of whether
the same fix is needed for pascal, take the conservative approach and keep
behaviour for decimals unchanged.

Tested on x86_64-linux, with a build with --enable-targets=all.

[gdb/go] Fix literal truncation

Make sure we error out on overflow instead of truncating in all cases.

The current implementation of parse_number contains a comment about PR16377,
but that's related to C-like languages.  In absence of information of whether
the same fix is needed for go, take the conservative approach and keep
behaviour for decimals unchanged.

Tested on x86_64-linux, with a build with --enable-targets=all.

[gdb/fortran] Fix literal truncation

As mentioned in commit 5b758627a18 ("Make gdb.base/parse_number.exp test all
architectures"):
...
    There might be a bug that 32-bit fortran truncates 64-bit values to
    32-bit, given "p/x 0xffffffffffffffff" returns "0xffffffff".
...

More concretely, we have:
...
$ for arch in i386:x86-64 i386; do \
    gdb -q -batch -ex "set arch $arch" -ex "set lang fortran" \
      -ex "p /x 0xffffffffffffffff"; \
  done
The target architecture is set to "i386:x86-64".
$1 = 0xffffffffffffffff
The target architecture is set to "i386".
$1 = 0xffffffff
...

Fix this by adding a range check in parse_number in gdb/f-exp.y.

Furthermore, make sure we error out on overflow instead of truncating in all
other cases.

Tested on x86_64-linux.

[gdb/c] Fix type of 2147483648 and literal truncation

[ Assuming arch i386:x86-64, sizeof (int) == 4,
sizeof (long) == sizeof (long long) == 8. ]

Currently we have (decimal for 0x80000000):
...
(gdb) ptype 2147483648
type = unsigned int
...

According to C language rules, unsigned types cannot be used for decimal
constants, so the type should be long instead (reported in PR16377).

Fix this by making sure the type of 2147483648 is long.

The next interesting case is (decimal for 0x8000000000000000):
...
(gdb) ptype 9223372036854775808
type = unsigned long
...

According to the same rules, unsigned long is incorrect.

Current gcc uses __int128 as type, which is allowed, but we don't have that
available in gdb, so the strict response here would be erroring out with
overflow.

Older gcc without __int128 support, as well as clang use an unsigned type, but with
a warning.  Interestingly, clang uses "unsigned long long" while gcc uses
"unsigned long", which seems the better choice.

Given that the compilers allow this as a convience, do the same in gdb
and keep type "unsigned long", and make this explicit in parser and test-case.

Furthermore, make sure we error out on overflow instead of truncating in all
cases.

Tested on x86_64-linux with --enable-targets=all.

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

[gdb/testsuite] Test more values in gdb.base/parse_numbers.exp

Currently we only test value 0xffffffffffffffff in test-case
gdb.base/parse_numbers.exp.

Test more interesting values, both in decimal and hex format, as well as
negative decimals for language modula-2.

This results in an increase in total tests from 15572 to 847448 (55 times
more tests).

Balance out the increase in runtime by reducing the number of architectures
tested: only test one architecture per sizeof longlong/long/int/short
combination, while keeping the possibility intact to run with all
architectures (through setting a variable in the test-case)

Results in slight reduction of total tests: 15572 -> 13853.

Document interesting cases in the expected results:
- wrapping from unsigned to signed
- truncation
- PR16377: using unsigned types to represent decimal constants in C

Running the test-case with a gdb build with -fsanitize=undefined, we trigger
two UB errors in the modula-2 parser, filed as PR29163.

Tested on x86_64-linux with --enable-targets=all.

[gdb/testsuite] Fix ERROR in gdb.ctf/funcreturn.exp

On openSUSE Tumbleweed (with gcc-12, enabling ctf tests) I run into:
...
ERROR: tcl error sourcing src/gdb/testsuite/gdb.ctf/funcreturn.exp.
ERROR: tcl error code NONE
ERROR: Unexpected arguments: \
  {print v_double_func} \
  {[0-9]+ = {double \(\)} 0x[0-9a-z]+.*} \
  {print double function} \
  }
...

The problem is a curly brace as fourth argument to gdb_test, which errors out
due to recently introduced more strict argument checking in gdb_test.

Fix the error by removing the brace.

Though this fixes the error for me, due to PR29160 I get only FAILs, so I can't
claim proper testing on x86_64-linux.

[gdb/testsuite] Fix gdb.threads/manythreads.exp with check-read1

When running test-case gdb.threads/manythreads.exp with check-read1, I ran
into this hard-to-reproduce FAIL:
...
[New Thread 0x7ffff7318700 (LWP 31125)]^M
[Thread 0x7ffff7321700 (LWP 31124) exited]^M
[New T^C^M
^M
Thread 769 "manythreads" received signal SIGINT, Interrupt.^M
[Switching to Thread 0x7ffff6d66700 (LWP 31287)]^M
0x00007ffff7586a81 in clone () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1
...

The matching in the failing gdb_test_multiple is done in an intricate way,
trying to pass on some order and fail on another order.

Fix this by rewriting the regexps to match one line at most, and detecting
invalid order by setting and checking state variables.

Tested on x86_64-linux.

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

[gdb] Fix warning in print_one_insn::ez80-adl

When running selftest print_one_insn::ez80-adl we run into this warning:
...
Running selftest print_one_insn::ez80-adl.
warning: Unable to determine inferior's software breakpoint type: couldn't
  find `_break_handler' function in inferior. Will be used default software \
  breakpoint instruction RST 0x08.
...

Fix this by explicitly handling bfd_arch_z80 in print_one_insn_test.

Tested on x86_64-linux.

Automatic date update in version.in

Use bool for evregpy_no_listeners_p

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

asan: heap buffer overflow in _bfd_mips_elf_section_from_shdr

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

Re: ubsan: undefined shift in frag_align_code

This one needs the same fix too.

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

[gdb] Fix warning in foreach_arch selftests

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

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

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

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

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

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

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

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

Tested on x86_64-linux.

Revert "[gdb] Fix warning in foreach_arch selftests"

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

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

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

Tested on x86_64-linux.

x86: exclude certain ISA extensions from v3/v4 ISA

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

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

gdb: LoongArch: Remove nonportable #include

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

Re: asan: mips_gprel_reloc segfault

Similarly for the elf mips support.

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

asan: mips_gprel_reloc segfault

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

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

Automatic date update in version.in

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

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

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

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

Tested on x86_64-linux.

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

Rearrange and slightly reword the "Location Specification" section

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

ODR warning for "main"

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

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

ODR warnings for "struct coff_symbol"

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

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

ODR warnings for "struct insn_decode_record_t"

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

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

ODR warnings for "struct insn_info"

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

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

ODR warnings from overlay constants

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

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

ODR warning for "enum string_repr_result"

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

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

ODR warning for "struct find_targ_sec_arg"

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

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

ODR warning for "struct stack_item"

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

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

ODR warning for "struct instruction_type"

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

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

ODR warning for struct ext_link_map

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

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

ODR warning for struct field_info

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

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

ODR warnings for struct nextfield

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

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

ODR warnings for struct symloc

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

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

Fix ODR warning in observable.h

observable.h triggers an ODR warning because this line:

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

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

This patch fixes the problem by adding a forward declaration.

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

gdb: LoongArch: Implement the software_single_step gdbarch method

When execute the following command on LoongArch:

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

there exist the following failed testcases:

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

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

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

gdb: Do not add empty sections to the section map

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

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

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

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

Fix a new warning on Cygwin

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

Fix Cygwin build after 85b25bd9

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

Fix Cygwin build after 0578e87f

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

Fix Cygwin build after fcab5839

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

Re: ubsan: signed integer overflow in atof_generic

Oops.

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

ubsan: signed integer overflow in atof_generic

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

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

asan: uninit write _bfd_ecoff_write_object_contents

* ecoff.c (_bfd_ecoff_write_object_contents): zalloc reloc_buff.

asan: null deref in coff_write_relocs

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

ubsan: undefined shift in frag_align_code

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

gas read_a_source_file #APP processing

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

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

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

sb_scrub_and_add_sb not draining input string buffer

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

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