inf-ptrace: Return an IGNORE event if waitpid() fails.

Previously this returned a TARGET_WAITKIND_SIGNALLED event for
inferior_ptid.  However, inferior_ptid is invalid during ::wait()
methods after the multi-target changes, so this was triggering an
assertion further up the stack.

do_target_wait_1: Clear TARGET_WNOHANG if the target isn't async.

Previously, TARGET_WNOHANG was cleared if a target supported async
mode even if async mode wasn't currently enabled.  This change only
permits TARGET_WNOHANG if async mode is enabled.

Don't enable async mode at the end of target ::resume methods.

Now that target_resume always enables async mode after target::resume
returns, these calls are redundant.

The other place that target resume methods are invoked outside of
target_resume are as the beneath target in record_full_wait_1.  In
this case, async mode should already be enabled when supported by the
target before the resume method is invoked due to the following:

  In general, targets which support async mode run as async until
  ::wait returns TARGET_WAITKIND_NO_RESUMED to indicate that there are
  no unwaited for children (either they have exited or are stopped).
  When that occurs, the loop in wait_one disables async mode.  Later
  if a stopped child is resumed, async mode is re-enabled in
  do_target_resume before waiting for the next event.

  In the case of record_full_wait_1, this function is invoked from the
  ::wait target method when fetching an event.  If the underlying
  target supports async mode, then an earlier call to do_target_resume
  to resume the child reporting an event in the loop in
  record_full_wait_1 would have already enabled async mode before
  ::wait was invoked.  In addition, nothing in the code executed in
  the loop in record_full_wait_1 disables async mode.  Async mode is
  only disabled higher in the call stack in wait_one after ::wait
  returns.

  It is also true that async mode can be disabled by an
  INF_EXEC_COMPLETE event passed to inferior_event_handle, but all of
  the places that invoke that are in the gdb core which is "above" a
  target ::wait method.

Note that there is an earlier call to enable async mode in
linux_nat_target::resume.  That call also marks the async event pipe
to report an existing event after enabling async mode, so it needs to
stay.

Enable async mode on supported targets in target_resume.

Enabling async mode above the target layer removes duplicate code in
::resume methods of async-capable targets.  Commit 5b6d1e4fa4f
("Multi-target support") enabled async mode in do_target_resume after
target_resume returns which is a step in this direction.  However,
other callers of target_resume such as target_continue do not enable
async mode.  Rather than enabling async mode in each of the callers
after target_resume returns, enable async mode at the end of
target_resume.

gdbserver linux-low: Convert linux_event_pipe to the event_pipe class.

Use event_pipe from gdbsupport in place of the existing file
descriptor array.

gdb linux-nat: Convert linux_nat_event_pipe to the event_pipe class.

Use event_pipe from gdbsupport in place of the existing file
descriptor array.

gdbsupport: Add an event-pipe class.

This pulls out the implementation of an event pipe used to implement
target async support in both linux-low.cc (gdbserver) and linux-nat.c
(gdb).

This will be used to replace the existing event pipe in linux-low.cc
and linux-nat.c in future commits.

Co-Authored-By: Lancelot SIX <lsix@lancelotsix.com>

gdb: fix detection of compilation and linking flags for source-highlight

Currently there are two problems with the detection of
source-highlight via pkg-config in GDB's configure script:

1. The LDFLAGS variable is used to pass the 'pkg-config --libs' output
to AC_LINK_IFELSE, which results in the "-L/some/path
-lsource-highlight" preceding the conftest.cpp, which can result in a
failure to find symbols referenced in conftest.cpp, if the linker is
using --as-needed by default.

2. The CFLAGS variable is used to pass the 'pkg-config --cflags'
output to AC_LINK_IFELSE.  However, as the current language is C++,
AC_LINK_IFELSE will actuall use CXXFLAGS, not CFLAGS, so any flags
returned from pkg-config will not be seen.

This patch fixes both of these mistakes, allowing GDB to correctly
configure and build using source-highlight installed into a custom
prefix, e.g. ~/opt/gdb-git (because the system version of
source-highlight is too old).

gdb/testsuite/README: point to default value of INTERNAL_GDBFLAGS

The INTERNAL_GDBFLAGS runtest variable was updated in 55c3ad88013
([gdb/testsuite] Prevent pagination in GDB_INTERNALFLAGS, 2020-10-26) to
disable pagination, and in aae1c79a03a (PR python/12227..., 2010-12-07)
to point to the data directory, but its default value mentioned in the
testsuite's README was not kept up to date.

To avoid it getting out of sync even more, point the reader to the
definition of the variable in lib/gdb.exp, and move the explanation of
the different flags there. Also adjust the example in the README
so it follows the flags added in 55c3ad88013.

Change-Id: I3533608a7d6ae5198af09c7dc7743bde24c19ed7

RISC-V: Maintain a string to hold the canonical order

Using dummy entry in riscv_supported_std_ext cause confusing and wrongly
support `b` and `k` extensions.

bfd/
* elfxx-riscv.c (riscv_supported_std_ext): Drop unsupported
extensions.
(riscv_ext_canonical_order): New.
(riscv_init_ext_order): Use riscv_ext_canonical_order rather
than riscv_supported_std_ext to compute canonical order.

V2 Changes:

- Use `*ext` rather than `*ext != NULL` for checking is reach end of
  string.

Automatic date update in version.in

Re: ld: Support customized output section type

"DO NOT EDIT!" says the comment at the top of bfd-in2.h.  Move the new
type field where it belongs.

PR ld/28841
* section.c (struct bfd_section): Add type.  Formatting.
(BFD_FAKE_SECTION): Formatting.
* bfd-in2.h: Regenerate.

sim: gdbinit: hoist setup to common code

This was left in subdirs because of the dynamic cgen usage.  However,
we can move this breakpoint call to runtime and let gdb detect whether
the symbol exists.

gdb/testsuite: relax pattern in new gdb.mi/mi-multi-commands.exp test

I saw some failures in the test gdb.mi/mi-multi-commands.exp that I
added recently.  This test was added in commit:

  commit d08cbc5d3203118da5583296e49273cf82378042
  Date:   Wed Dec 22 12:57:44 2021 +0000

      gdb: unbuffer all input streams when not using readline

The failures I see only occurred when my machine was very heavily
loaded.

In this test I send multiple commands from dejagnu to gdb with a
single send_gdb call.  In a well behaving world what I want to happen
is that the gdb console sees both commands arrive and echos the text
of those commands.  Then gdb starts processing the first command,
prints the result, and then processes the second command, and prints
the result.

However, what I saw in my loaded environment was that only after
sending the two commands, only the first command was echoed to gdb's
terminal.  Then gdb started processing the first command, and started
to write the output.  Now, mixed in with the first command output, the
second command was echoed to gdb's terminal.  Finally, gdb would
finish printing the first command output, and would read and handle
the second command.

This mixing of command echoing with the first command output was
causing the test matching patterns to fail.

In this commit I change the command I use in the test from a CLI
command to an MI command, this reduces the number of lines of output
that come from the test, CLI commands sent through the MI interpreter
are echoed back like this:

  (gdb)
  set $a = "FIRST COMMAND"
  &"set $a = \"FIRST COMMAND\"\n"
  ^done
  (gdb)

While this is not the case for true MI command:

  (gdb)
  -data-evaluate-expression $a
  ^done,value="\"FIRST COMMAND\""
  (gdb)

Less output makes for simpler patterns to match against.

Next, when sending two command to gdb I was previously trying to spot
the output of the first command followed by the prompt with nothing
between.  This is not really needed, for the first command I can look
for just the ^done,value="\"FIRST COMMAND\"" string, then I can start
looking for the output of the second command.

So long as the second pattern matches up to the gdb prompt, then I can
be sure than nothing is left over in the expect buffer to muck up
later matches.

As to see the second command output gdb must have read in the second
command, the second command output never suffers from the corruption
that the first command output does.

Since making this change, I've not seen a failure in this test.

gdb: avoid nullptr access in dbxread.c from read_dbx_symtab

This fixes a GDB crash reported in bug pr/28900, related to reading in
some stabs debug information.

In this commit my goal is to stop GDB crashing.  I am not trying to
ensure that GDB makes the best possible use of the available stabs
debug information.  At this point I consider stabs a legacy debug
format, with only limited support in GDB.

So, the problem appears to be that, when reading in the stabs data, we
need to find a N_SO entry, this is the entry that defines the start of
a compilation unit (or at least the location of a corresponding source
file).

It is while handling an N_SO that GDB creates a psymtab to hold the
incoming debug information (symbols, etc).

The problem we hit in the bug is that we encounter some symbol
information (an N_PC entry) outside of an N_SO entry - that is we find
some symbol information that is not associated with any source file.

We already have some protection for this case, look (in
read_dbx_symtab) at the handling of N_PC entries of type 'F' and 'f',
if we have no psymtab (the pst variable is nullptr) then we issue a
complaint.  However, for whatever reason, in both 'f' and 'F'
handling, there is one place where we assume that the pst
variable (the psymtab) is not nullptr.  This is a mistake.

In this commit, I guard these two locations (in 'f' and 'F' handling)
so we no longer assume pst is not nullptr.

While I was at it, I audited all the other uses of pst in
read_dbx_symtab, and in every potentially dangerous case I added a
nullptr check, and issue a suitable complaint if pst is found to be
nullptr.

It might well be true that we could/should do something smarter if we
see a debug symbol outside of an N_SO entry, and if anyone wanted to
do that work, they're welcome too.  But this commit is just about
preventing the nullptr access, and the subsequent GDB crash.

I don't have any tests for this change, I have no idea how to generate
weird stabs data for testing.  The original binary from the bug report
now loads just fine without GDB crashing.

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

gdb: make use of std::string in dbxread.c and xcoffread.c

While taking a look through dbxread.c I spotted a couple of places
where making use of std::string would remove the need for manual
memory allocation and memcpy.

During review Simon pointed out that the same code exists in
xcoffread.c, so I've applied the same fix there too.

There should be no user visible changes after this commit.

Automatic date update in version.in

gdb: Only paginate for filtered output in fputs_maybe_filtered

A have had situation where a unfiltered output (done using
fputs_unfiltered) ended up triggering pagination.  The backtrace for this was:

    ...
    #24 0x000055839377ee4e in check_async_event_handlers () at ../../gdb/async-event.c:335
    #25 0x0000558394b67b57 in gdb_do_one_event () at ../../gdbsupport/event-loop.cc:216
    #26 0x0000558394587454 in gdb_readline_wrapper (prompt=0x7ffd907712d0 "--Type <RET> for more, q to quit, c to continue without paging--") at ../../gdb/top.c:1148
    #27 0x0000558394707270 in prompt_for_continue () at ../../gdb/utils.c:1438
    #28 0x00005583947088b3 in fputs_maybe_filtered (linebuffer=0x60c0000f4000 "   [...quite big message...]", stream=0x60300028e9d0, filter=0) at ../../gdb/utils.c:1752
    #29 0x0000558394708e57 in fputs_unfiltered (linebuffer=0x60c0000f4000 "   [...quite big message...]", stream=0x60300028e9d0) at ../../gdb/utils.c:1811
    ...

This comes from what appears to be a oversight in fputs_maybe_filtered.  This
function has a FILTER parameter which if true makes the function pause after
every screenful (i.e. triggers pagination).

The filter parameter is correctly used to guard the first place where
prompt_for_continue.  There is a second place in the function which can call
prompt_for_continue, but is currently unguarded.  I believe that this is an
oversight, this patch fixes that.

Tested on Linux-x86_64, no regression observed.

Change-Id: Iad8ffd50a87cf20077500878e2564b5a7dc81ece

Automatic date update in version.in

gdb/darwin: remove not-so-harmless spurious call to `wait4`

As seen in https://sourceware.org/bugzilla/show_bug.cgi?id=24069 this
code will typically wait4() a second time on the same process that was
already wait4()'d a few lines above. While this used to be
harmless/idempotent (when we assumed that the process already exited),
this now causes a deadlock in the WIFSTOPPED case.

The early (~2019) history of bug #24069 cautiously suggests to use
WNOHANG instead of outright deleting the call. However, tests on the
current version of Darwin (Big Sur) demonstrate that gdb runs just fine
without a redundant call to wait4(), as would be expected.
Notwithstanding the debatable value of conserving bug compatibility with
an OS release that is more than a decade old, there is scant evidence of
what that double-wait4() was supposed to achieve in the first place - A
cursory investigation with `git blame` pinpoints commits bb00b29d7802
and a80b95ba67e2 from the 2008-2009 era, but fails to answer the
"why" question conclusively.

Co-Authored-By: Philippe Blain <levraiphilippeblain@gmail.com>
Change-Id: Id4e4415d66d6ff6b3552b60d761693f17015e4a0

Automatic date update in version.in

Add constructor to bound_minimal_symbol

This adds a constructor to bound_minimal_symbol, to avoid a build
failure with clang that Simon pointed out.

I also took the opportunity to remove some redundant initializations,
and to change one use of push_back to emplace_back, as suggested by
Simon.

Fix typo in ld.texi

ld/
* ld.texi (Output Section Type): Fix typo in @code syntax.

gdb: remove newlines from some linux_nat_debug_printf calls

Change-Id: I80328fab7096221356864b5a4fb30858b48d2c10

Automatic date update in version.in

Updated Serbian translations for the bfd, gold, ld and opcodes directories

Automatic date update in version.in

ld: Support customized output section type

bfd/
    PR ld/28841
    * bfd-in2.h (struct bfd_section): Add type.
    (discarded_section): Add field.
    * elf.c (elf_fake_sections): Handle bfd_section::type.
    * section.c (BFD_FAKE_SECTION): Add field.
    * mri.c (mri_draw_tree): Update function call.

ld/
    PR ld/28841
    * ld.texi: Document new output section type.
    * ldlex.l: Add new token TYPE.
    * ldgram.y: Handle TYPE=exp.
    * ldlang.h: Add type_section to list of section types.
    * ldlang.c (lang_add_section): Handle type_section.
    (map_input_to_output_sections): Handle type_section.
    * testsuite/ld-scripts/output-section-types.t: Add tests.
    * testsuite/ld-scripts/output-section-types.d: Update.

gdb/tui: add a missing white space character

Just adds a missing space.  There should be no user visible changes
after this commit.

gdb: convert callback_handler_installed from int to bool

Simple int to bool conversion on callback_handler_installed in
event-top.c.  There should be no user visible changes after this
commit.

gas local label and dollar label handling

Much of the gas source and older BFD source use "long" for function
parameters and variables, when other types would be more appropriate.
This patch fixes one of those cases.  Dollar labels and numeric local
labels do not need large numbers.  Small positive itegers are usually
all that is required.  Due to allowing longs, it was possible for
fb_label_name and dollar_label_name to overflow their buffers.

* symbols.c: Delete unnecessary forward declarations.
(dollar_labels, dollar_label_instances): Use unsigned int.
(dollar_label_defined, dollar_label_instance): Likewise.
(define_dollar_label): Likewise.
(fb_low_counter, fb_labels, fb_label_instances): Likewise.
(fb_label_instance_inc, fb_label_instance): Likewise.
(fb_label_count, fb_label_max): Make them size_t.
(dollar_label_name, fb_label_name): Rewrite using sprintf.
* symbols.h (dollar_label_defined): Update prototype.
(define_dollar_label, dollar_label_name): Likewise.
(fb_label_instance_inc, fb_label_name): Likewise.
* config/bfin-lex.l (yylex): Remove unnecessary casts.
* expr.c (integer_constant): Likewise.
* read.c (read_a_source_file): Limit numeric label range to int.

ubsan: s_app_line integer overflow

There are quite a few ubsan warnings in gas.  This one disappears with
a code tidy.

* read.c (s_app_line): Rename 'l' to 'linenum'.  Avoid ubsan
warning.

pe_ILF_make_a_symbol_reloc segfault

pei-aarch64-little apparently lacks support for BFD_RELOC_RVA.

* peicode.h (pe_ILF_make_a_symbol_reloc): Don't segfault on
NULL howto.

What to do when sh_addralign isn't a power of two

BFD generally doesn't handle anything but a power of two section
alignment, and ELF sh_addralign is required to be an integral power of
two (or zero) by the ELF spec.  Of course this is ignored by fuzzers,
and because bfd_log2 rounds up, we can end up with alignment_power
being 32 on a 32-bit object or 64 on a 64-bit object.  That then
triggers ubsan warnings in places like bfd_update_compression_header
where we want to convert from alignment_power back to an alignment.
I suppose we could reject object files that have non-compliant
sh_addralign, but I think it's also reasonable to use the greatest
power of two divisor of sh_addralign, ie. the rightmost 1 bit.

* elf.c (_bfd_elf_make_section_from_shdr): Use greatest power
of two divisor of sh_addralign.
(_bfd_elf_assign_file_position_for_section): Likewise.
(assign_file_positions_for_non_load_sections): Likewise.

asan: buffer overflow in vms-alpha.c

* vms-alpha.c (evax_bfd_print_dst): Sanity check another place
printing strings.

asan : use of uninitialized value in buffer_and_nest

* macro.c (buffer_and_nest): Don't read past end of string buffer.

asan: buffer overflow in peXXigen.c

* peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Properly
sanity check DataDirectory[PE_DEBUG_DATA].Size.

sim/common: Improve sim_dump_memory head comment

As requested by Mike.

* sim-memopt.c: Improve head comment.

sim/testsuite/cris/c/stat3.c: Fix formatting nit

* c/stat3.c (main): Fix formatting nit.

sim: testsuite: cleanup the istarget * logic

Now that the multitarget testing has settled, clean up the cases where
istarget * is used.  This ends up being mostly style unindenting.

Automatic date update in version.in

i386: Update I386_NEED_DYNAMIC_RELOC_TYPE_P for DT_TEXTREL

Update I386_NEED_DYNAMIC_RELOC_TYPE_P to allow R_386_TLS_IE for relocation
in read-only section.

bfd/

PR ld/28894
* elfxx-x86.h (I386_NEED_DYNAMIC_RELOC_TYPE_P): Allow
R_386_TLS_IE.

ld/
PR ld/28894
* testsuite/ld-i386/i386.exp: Run pr28894.
* testsuite/ld-i386/pr28894.d: New file.
* testsuite/ld-i386/pr28894.s: Likewise.

sim/testsuite: Default global_cc_os and global_cc_works properly

There was an omission on 3e6dc39ed7a8 "sim/testsuite: Set
global_cc_os also when no compiler is found"; global_cc_os
wasn't set for other than the primary target, which means
that the "unguarded" use of global_cc_os in
testsuite/cris/c/c.exp caused the dreaded "ERROR: can't read
"global_cc_os": no such variable" when e.g. configuring for
pru-elf and doing "make check-sim".  Better initializing
both variables at the top to default values, rather than
adding another single 'set global_cc_os ""', to reduce the
risk of not setting them properly if or when that
if-statement-chain is made longer.

sim/testsuite:
* lib/sim-defs.exp (sim_init_toolchain): Default
global_cc_os and global_cc_works properly, before if-chain.

x86: Add has_sib to struct instr_info

Add has_sib to struct instr_info and use SIB info only if ins->has_sib
is true.

PR binutils/28892
* i386-dis.c (instr_info): Add has_sib.
(get_sib): Set has_sib.
(OP_E_memory): Replace havesib with ins->has_sib.
(OP_VEX): Use ins->sib.index only if ins->has_sib is true.

gdb: Respect the DW_CC_nocall attribute

It is possible for a compiler to optimize a function in a such ways that
the function does not follow the calling convention of the target.  In
such situation, the compiler can use the DW_AT_calling_convention
attribute with the value DW_CC_nocall to tell the debugger that it is
unsafe to call the function.  The DWARF5 standard states, in 3.3.1.1:

  > If the value of the calling convention attribute is the constant
  > DW_CC_nocall, the subroutine does not obey standard calling
  > conventions, and it may not be safe for the debugger to call this
  > subroutine.

Non standard calling convention can affect GDB's assumptions in multiple
ways, including how arguments are passed to the function, how values are
returned, and so on.  For this reason, it is unsafe for GDB to try to do
the following operations on a function with marked with DW_CC_nocall:

- call / print an expression requiring the function to be evaluated,
- inspect the value a function returns using the 'finish' command,
- force the value returned by a function using the 'return' command.

This patch ensures that if a command which relies on GDB's knowledge of
the target's calling convention is used on a function marked nocall, GDB
prints an appropriate message to the user and does not proceed with the
operation which is unreliable.

Note that it is still possible for someone to use a vendor specific
value for the DW_AT_calling_convention attribute for example to indicate
the use of an alternative calling convention.  This commit does not
prevent this, and target dependent code can be adjusted if one wanted to
support multiple calling conventions.

Tested on x86_64-Linux, with no regression observed.

Change-Id: I72970dae68234cb83edbc0cf71aa3d6002a4a540

gdb: add a symbol* argument to get_return_value

Add an argument to the get_return_value function to indicate the symbol
of the function the debuggee is returning from.  This will be used by
the following patch.

Since the function return type can be deduced from the symbol remove the
value_type argument which becomes redundant.

No user visible change after this patch.

Tested on x86_64-linux.

Change-Id: Idf1279f1f7199f5022738a6679e0fa63fbd22edc
Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca>

x86-64: Use MAXPAGESIZE for the relro segment alignment

Adjust x86-64 linker tests after reverting

commit 31b4d3a16f200bf04db8439a63b72bba7af4e1be
Author: Alan Modra <amodra@gmail.com>
Date:   Thu Feb 3 08:57:47 2022 +1030

    PR28824, relro security issues, x86 keep COMMONPAGESIZE relro

to use MAXPAGESIZE for the end of the relro segment alignment, like other
ELF targets.

* testsuite/ld-x86-64/plt-main-bnd.dd: Updated.
* testsuite/ld-x86-64/plt-main-ibt-x32.dd: Likewise.
* testsuite/ld-x86-64/plt-main-ibt.dd: Likewise.
* testsuite/ld-x86-64/pr14207.d: Likewise.
* testsuite/ld-x86-64/pr18176.d: Likewise.
* testsuite/ld-x86-64/pr20830a-now.d: Likewise.
* testsuite/ld-x86-64/pr20830a.d: Likewise.
* testsuite/ld-x86-64/pr20830b-now.d: Likewise.
* testsuite/ld-x86-64/pr20830b.d: Likewise.
* testsuite/ld-x86-64/pr21038a-now.d: Likewise.
* testsuite/ld-x86-64/pr21038a.d: Likewise.
* testsuite/ld-x86-64/pr21038b-now.d: Likewise.
* testsuite/ld-x86-64/pr21038b.d: Likewise.
* testsuite/ld-x86-64/pr21038c-now.d: Likewise.
* testsuite/ld-x86-64/pr21038c.d: Likewise.

Revert "PR28824, relro security issues, x86 keep COMMONPAGESIZE relro"

This reverts commit 31b4d3a16f200bf04db8439a63b72bba7af4e1be.

Automatic date update in version.in

sim/testsuite/cris: If failing compilation, mark C tests as errors

...when we know we have a working compiler.  This will reduce
the risk of faulty edits by exposing them rather than hiding
them as "unresolved".  It also harmonizes behavior with that of
run_sim_test.

* c/c.exp: Mark C tests failing compilation test errors.

sim/testsuite/cris: Remove faulty use of basename in C tests

Calls to basename were added here as part of commit
e1e1ae6e9b5e "sim: testsuite: fix objdir handling", but that
commit missed adding "#include <libgen.h>" or the equivalent
GNU extension, see basename(3).  Fixing that shows a logical
error in the change to openpf1.c; the non-/-prefixed
code-path was changed instead of the "/"-prefixed code-path,
which is the one executed after that commit.

For "newlib" these tests failed linking after that commit.
Recent newlib has the (asm-renamed) GNU-extension-variant of
basename, but we're better off not using it at all.

Unfortunately, compilation failures for C tests run by the
machinery in c.exp are currently just marked "unresolved",
in contrast to C and assembler tests run by calling
run_sim_test.

The interaction of calling with the full program-path vs.
use of --sysroot exposes a consistency problem: when
--sysroot is used, argv[0] isn't the path by which the
program can find itself.  It's undecided whether argv[0] for
the program running in the simulator should be edited
(related to the naked argument to the simulator before
passing on to the simulated program) to remove a leading
--sysroot.  Either way, such a change would be out of scope
for this commit.

* c/stat3.c (mybasename): New macro.  Use it instead of basename.
* c/openpf1.c: Correct basename-related change and update related
comment.

sim: Add sim_dump_memory for debugging

Intended to be called from the debugger tool.

sim/common:
* sim-memopt.c (sim_dump_memory): New function.

sim: Fix use of out-of-tree assembler and linker when testing

With commit 7a259895bb2d "sim: testsuite: expand arch specific
toolchain settings", trying to use out-of-tree ld and as at test-time
broke for the "primary target", like when testing a release-tarball.

Subsequent to that commit, all assembler tests without in-tree-built
tools FAIL, getting errors when trying to call
$(abs_builddir)/../gas/as-new.  But, that isn't the actual culprint;
it's actually it's its immediate predecessor, commit 8996c21067373
"sim: testsuite: setup per-port toolchain settings for multitarget
build", which hardcodes in-tree-paths to those tools instead of
considering e.g. $(<X>_FOR_TARGET), the preferred overridable variable
for single-target builds, as set up by the toplevel Makefile.

This commit calls GCC_TARGET_TOOL (a deceptive name; gcc-specific
features aren't used) from toplev/config/acx.m4, somewhat like calls
in toplev/configure.ac but without the NCN_STRICT_CHECK_TARGET_TOOLS
step, for each X to find a value for $(<X>_FOR_TARGET).  N.B.: in-tree
tools still override any ${target}-${tool} found in $PATH, i.e. only
previously broken builds are affected.

The variables $(<X>_FOR_TARGET) are usually overridden by the toplevel
Makefile to the same value or better, but has to be set here too, as
automake "wants" Makefiles to be self-contained (you get an error
pointing out that the variable may be empty).  If it hadn't been for
that, SIM_AC_CHECK_TOOLCHAIN_FOR_PRIMARY_TARGET would not be needed.
This detail should only (positively) affect users invoking "make
check" in sim/ instead of "make check-sim" (or "make check") at the
toplevel.  Now the output from "configure" matches the target tools
actually used by sim at test-time, for the "primary target".

Using $(CC) for "example-" targets CC_FOR_TARGET is not changed, as
that appears to be a deliberate special-case.

Note that all tools still have to be installed and present in
$PATH at configure-time to be properly used at test-time.

sim:
* m4/sim_ac_toolchain.m4 (SIM_AC_CHECK_TOOLCHAIN_FOR_PRIMARY_TARGET):
New defun.
(SIM_TOOLCHAIN_VARS): Call it using AC_REQUIRE, and use variables
AS_FOR_TARGET, LD_FOR_TARGET and CC_FOR_TARGET instead of hard-coded
values.
* Makefile.in, configure: Regenerate.

sim cris: Unbreak --disable-sim-hardware builds

With --disable-sim-hardware (--enable-sim-hardware=no),
whose default was changed to --enable-sim-hardware(=yes) in
commit 34cf51120683, building for cris-elf fails as
sim_hw_parse then doesn't exist.

A cris-elf simulator configured for --enable-sim-hardware
(or the default after to the mentioned commit) runs about
2.5x slower than one configured --disable-sim-hardware.
A further 2-5% performance regression was not investigated.

When sim_hw_parse doesn't exist, --cris-900000xx can't be
supported.  The best action here is to remove it completely,
so its absence can be identified through --help, but
avoiding littering the code with "#if WITH_HW".

sim/cris:
* sim-if.c (cris_options) [WITH_HW]: Conditionalize
support of option --cris-900000xx.
(sim_open) [WITH_HW]: Conditionalize sim_hw_parse
call.

sim/testsuite/cris: As applicable, require simoption --cris-900000xx

Apply the new run_sim_test option "require" as in "#require
simoption --cris-900000xx" for all tests using that option.
This allows a clean test-suite-run for a build with
--disable-sim-hardware, where that option is not supported,
by skipping those tests as "untested".

sim/testsuite/cris:
* asm/io1.ms, asm/io2.ms, asm/io3.ms, asm/io6.ms,
asm/io7.ms: Call "#require: simoption --cris-900000xx".

sim/testsuite: Support "requires: simoption <--name-of-option>"

Simulator features can be present or not, typically
depending on different-valued configure options, like
--enable-sim-hardware[=off|=on].  To avoid failures in
test-suite-runs when testing such configurations, a new
predicate is needed, as neither "target", "progos" nor
"mach" fits cleanly.

The immediate need was to check for presence of a simulator
option, but rather than a specialized "requires-simoption:"
predicate I thought I'd handle the general (parametrized)
need, so here's a generic predicate machinery and a (first)
predicate to use together with it; checking whether a
particular option is supported, by looking at "run --help"
output.  This was inspired by the check_effective_target_
machinery in the gcc test-suite.

Multiple "requires: <requirement> <parameter>" form a list of
predicates (with parameters), to be used as a conjunction.

sim/testsuite:
* lib/sim-defs.exp (sim_check_requires_simoption): New function.
(run_sim_test): Support "requires: <requirement> <parameter>".

sim/testsuite/cris/hw/rv-n-cris/irq1.ms: Disable due to randomness

For reasons that remain largely to be investigated (besides
the apparent lack of synchronization between two processes),
this test fails randomly, with two different sets of common
outputs.  Curiously, that doesn't happen for the other
similar tests.  There's a comment that mentions this, though
that doesn't make it a sustainable part of a test-suite.
(Known-blinking tests should be disabled until fixed.)

sim/testsuite/cris:
* hw/rv-n-cris/irq1.ms: Disable by use of a never-matched
"progos" value.

sim/testsuite/cris/c: Use -sim3 but only for newlib targets

Commit a39487c6685f "sim: cris: use -sim with C tests for cris-elf
targets" caused " -sim" to be appended to CFLAGS_FOR_TARGET for
cris*-*-elf, where testing had until then relied on
"RUNTESTFLAGS=--target_board=cris-sim" being passed when running "make
check-sim", adding the right options.  While "-sim" happens to work,
the baseboard-file cris-sim.exp uses "-sim3" so for consistency use
that instead.

Then commit b42f20d2ac72 "sim: testsuite: drop most specific istarget
checks" caused " -sim" to be appended for *all* targets, which just
doesn't work.  For example, for crisv32-linux-gnu, that's not a
recognized option and will cause a dejagnu error and further testing
in c.exp will be aborted.

While cris-sim.exp appends "-static" for *-linux-gnu, further changes
in the test-suite have caused "linux"-specific tests to break, so that
part will be tended to separately.

But, save and restore CFLAGS_FOR_TARGET around the modification and
use where needed, to not have the CRIS-specific modification affect a
continuing test-run (possibly for other targets).

sim/testsuite/cris:
* c/c.exp (CFLAGS_FOR_TARGET): Replace appended option " -sim"
with " -sim3", but do it conditionally for newlib targets.  Save
and restore CFLAGS_FOR_TARGET in saved_CFLAGS_FOR_TARGET such
that it doesn't affect the value of CFLAGS_FOR_TARGET outside
c.exp.

sim/testsuite: Set global_cc_os also when no compiler is found

If we don't set this variable, it doesn't exist, and using "#progos:"
in an assembler-file will cause an error rather than just skipping the
test, viz:

Running /src/sim/testsuite/cris/hw/rv-n-cris/rvc.exp ...
ERROR: tcl error sourcing /src/sim/testsuite/cris/hw/rv-n-cris/rvc.exp.
ERROR: can't read "global_cc_os": no such variable
    while executing
"if { $opts(progos) != "" && $opts(progos) != $global_cc_os } {
untested $subdir/$name
return
    }"
    (procedure "run_sim_test" line 102)

Neither the commit introducing progos, nor the top comment
in run_sim_test, mentions progos as intended only for C
tests, or that its use must be gated on $global_cc_works !=
0, so (not) setting it in the no-working-compiler path seems
just overlooked.

Allowing it to be used for assembler tests makes it usable
for e.g. an always-false predicate and in expressions in
.exp files without gating on $global_cc_works != 0.

With this patch, global_cc_os is set to "", just as for "unknown OS".

    sim/testsuite:
* lib/sim-defs.exp (sim_init_toolchain): Set global_cc_os also when
no working target C compiler is found.

sim/testsuite/cris: Assembler testcase for PRIx32 usage bug

Several C test-cases exposed the bug, but let's have one for
people who test using just the assembler and linker.

* asm/endmem1.ms: New test.

sim cris: Correct PRIu32 to PRIx32

In 5ee0bc23a68f "sim: clean up bfd_vma printing" there was
an additional introduction of PRIx32 and PRIu32 but just in
sim/cris/sim-if.c.  One type of bug was fixed in commit
d16ce6e4d581 "sim: cris: fix memory setup typos" but one
remained; the PRIu32 usage is wrong, as hex output is
desired; note the 0x prefix.

Without this fix, you'll see output like:
 memory map 0:0x4000..0x5fff (8192 bytes) overlaps 0:0x0..0x16383 (91012 bytes)
 program stopped with signal 6 (Aborted).
for some C programs, like some of the ones in the sim/cris/c
testsuite from where the example is taken (freopen2.c).

The bug behavior was with memory allocation.  With an
attempt to allocate memory using the brk syscall such that
the room up to the next 8192-byte "page boundary" wasn't
sufficient, the simulator memory allocation machinery horked
on a consistency error when trying to allocate a memory
block to raise the "end of the data segment": there was
already memory allocated at that address.

Unfortunately, none of the programs in sim/cris/asm exposed
this bug at the time, but an assembler test-case is
committed after this fix.

sim/cris:
* sim-if.c (sim_open): Correct PRIu32 to PRIx32.

microblaze: fix fsqrt collicion to build on glibc-2.35

* microblaze-opcm.h: Renamed 'fsqrt' to 'microblaze_fsqrt'.
* microblaze-opc.h: Follow 'fsqrt' rename.

Remove LA_PRINT_STRING

This removes the LA_PRINT_STRING macro, in favor of using ordinary
method calls.

Remove LA_PRINT_CHAR

This removes the LA_PRINT_CHAR macro, in favor of using ordinary
method calls.

Remove LA_PRINT_TYPE

This removes the LA_PRINT_TYPE macro, in favor of using ordinary
method calls.

gdb/python: move styling support to gdb.styling

This commit moves the two Python functions that are used for styling
into a new module, gdb.styling, there's then a small update in
python.c so GDB can find the functions in their new location.

The motivation for this change is purely to try and reduce the clutter
in the top-level gdb module, and encapsulate related functions into
modules.  I did ponder documenting these functions as part of the
Python API, however, doing so would effectively "fix" the API, and I'm
still wondering if there's improvements that could be made, also, the
colorize function is only called in some cases now that GDB prefers
libsource-highlight, so it's not entirely sure how this would work as
part of a user facing API.

Still, despite these functions never having been part of a documented
API, it is possible that a user out there has overridden these to, in
some way, customize how GDB performs styling.  Moving the function as
I propose in this patch could break things for that user, however,
fixing this breakage is trivial, and, as these functions were never
documented, I don't think we should be obliged to not break user code
that relies on them.

gdb: use python to colorize disassembler output

This commit adds styling support to the disassembler output, as such
two new commands are added to GDB:

  set style disassembler enabled on|off
  show style disassembler enabled

In this commit I make use of the Python Pygments package to provide
the styling.  I did investigate making use of libsource-highlight,
however, I found the highlighting results to be inferior to those of
Pygments; only some mnemonics were highlighted, and highlighting of
register names such as r9d and r8d (on x86-64) was incorrect.

To enable disassembler highlighting via Pygments, I've added a new
extension language hook, which is then implemented for Python.  This
hook is very similar to the existing hook for source code
colorization.

One possibly odd choice I made with the new hook is to pass a
gdb.Architecture through, even though this is currently unused.  The
reason this argument is not used is that, currently, styling is
performed identically for all architectures.

However, even though the Python function used to perform styling of
disassembly output is not part of any documented API, I don't want
to close the door on a user overriding this function to provide
architecture specific styling.  To do this, the user would inevitably
require access to the gdb.Architecture, and so I decided to add this
field now.

The styling is applied within gdb_disassembler::print_insn, to achieve
this, gdb_disassembler now writes its output into a temporary buffer,
styling is then applied to the contents of this buffer.  Finally the
gdb_disassembler buffer is copied out to its final destination stream.

There's a new test to check that the disassembler output includes some
escape sequences, though I don't check for specific colours; the
precise colors will depend on which instructions are in the
disassembler output, and, I guess, how pygments is configured.

The only negative change with this commit is how we currently style
addresses in GDB.

Currently, when the disassembler wants to print an address, we call
back into GDB, and GDB prints the address value using the `address`
styling, and the symbol name using `function` styling.  After this
commit, if pygments is used, then all disassembler styling is done
through pygments, and this include the address and symbol name parts
of the disassembler output.

I don't know how much of an issue this will be for people.  There's
already some precedent for this in GDB when we look at source styling.
For example, function names in styled source listings are not styled
using the `function` style, but instead, either GNU Source Highlight,
or pygments gets to decide how the function name should be styled.

If the Python pygments library is not present then GDB will continue
to behave as it always has, the disassembler output is mostly
unstyled, but the address and symbols are styled using the `address`
and `function` styles, as they are today.

However, if the user does `set style disassembler enabled off`, then
all disassembler styling is switched off.  This obviously covers the
use of pygments, but also includes the minimal styling done by GDB
when pygments is not available.

ld: Keep indirect symbol from IR if referenced from shared object

Don't change indirect symbol defined in IR to undefined if it is
referenced from shared object.

bfd/

PR ld/28879
* elflink.c (_bfd_elf_merge_symbol): Don't change indirect
symbol defined in IR to undefined if it is referenced from
shared object.

ld/

PR ld/28879
* testsuite/ld-plugin/lto.exp: Run PR ld/28879 tests.
* testsuite/ld-plugin/pr28879a.cc: New file.
* testsuite/ld-plugin/pr28879b.cc: Likewise.

Automatic date update in version.in

PR28882, build failure with gcc-4.2 due to use of 0b literals

PR 28882
* elf/loongarch.h: Replace binary literals with hex.

Don't pass around expld.dataseg pointer

The better to see any code that accesses expld.dataseg.

* ldexp.c (fold_segment_end): Remove seg parameter.  Adjust calls.
(fold_segment_align, fold_segment_relro_end): Likewise.
* ldlang.c (lang_size_segment): Likewise.
(lang_size_relro_segment_1, lang_find_relro_sections_1): Likewise.

Remove bfd ELF_RELROPAGESIZE

Now that ld properly aligns the end of the relro segment, the hack to
make relro work on powerpc can disappear.

bfd/
* bfd.c (bfd_emul_get_commonpagesize): Remove relro param.
Don't return bed->relropagesize.
* elf-bfd.h (struct elf_backend_data): Remove relropagesize.
* elfxx-target.h (ELF_RELROPAGESIZE): Remove.
* elf32-ppc.c (ELF_RELROPAGESIZE): Don't define.
* elf64-ppc.c: Likewise.
* bfd-in2.h: Regenerate.
ld/
* ldemul.c (after_parse_default): Adjust
bfd_emul_get_commonpagesize call.

PR28824, relro security issues, x86 keep COMMONPAGESIZE relro

x86 treats MAXPAGESIZE as a memory optimisation parameter, actual
hardware paging is always COMMPAGESIZE of 4k.  Use COMMONPAGESIZE for
the end of the relro segment alignment.

The previous patch regresses pr18176, increasing the testcase file
size from 322208 to 2099872 bytes.  Fixing this on x86 will require
introducing a gap after the end of the relro segment (of up to
relropagesize-1 bytes).

PR 28824
PR 18176
* ld.h (ld_config_type): Add relro_use_commonpagesize field.
* ldexp.c (fold_segment_align): Set relropagesize depending on
relro_use_commonpagesize.
* emultempl/elf-x86.em (elf_x86_create_output_section_statements):
Set relro_use_commonpagesize.
* testsuite/ld-x86-64/pr18176.d: xfail.

PR28824, relro security issues

Background
==========
There are constraints on layout of binaries to meet demand paging and
memory protection requirements.  Demand paged binaries must have file
offset mod pagesize equal to vma mod pagesize.  Memory protection
(executable, read, write status) can only change at page boundaries.
The linker's MAXPAGESIZE variable gives the page size for these layout
constraints.

In a typical basic executable with two memory segments, text (RE) and
data (RW), the data segment must start on a different page to the
last text segment page.  For example, with 64k pages and a small
executable of 48k text and 1k data, the text segment might start at
address 0x10000 and data at 0x20000 for a total of two 64k memory
pages.  Demand paging would require the image on disk to be 64k+1k
in size.  We can do better than that.  If the data segment instead
starts at 0x2c000 (the end of the text segment plus one 64k page) then
there are still only two memory pages, but the disk image is now
smaller, 48k+1k in size.  This is why the linker normally starts the
data segment at the end of the text segment plus one page.  That
simple heuristic isn't ideal in all cases.  Changing our simple
example to one with 64k-1 text size, following that heuristic would
result in data starting at 0x2ffff.  Now we have two 64k memory data
pages for a data segment of 1k!  If the data segment instead started
at 0x30000 we'd get a single data segment page at the cost of 1 byte
extra in the disk image, which is likely a good trade-off.  So the
linker does adjust the simple heuristic.  Just how much disk image
size increase is allowed is controlled by the linker's COMMONPAGESIZE
variable.

A PT_GNU_RELRO segment overlays the initial part of the data segment,
saying that those pages should be made read-only after relocation by
the dynamic loader.  Page granularity for memory protection means that
the end of the relro segment must be at a page boundary.

The problem
===========
Unfortunately most targets currently only align the end of the relro
segment to COMMONPAGESIZE.  That results in only partial relro
protection if an executable is running with MAXPAGESIZE pages, since
any part of the relro segment past the last MAXPAGESIZE boundary can't
be made read-only without also affecting sections past the end of the
relro segment.  I believe this problem arose because x86 always runs
with 4k (COMMPAGESIZE) memory pages, and therefore using a larger
MAXPAGESIZE on x86 is for reasons other than the demand paging and
memory page protection boundary requirements.

The solution
============
Always end the relro segment on a MAXPAGESIZE boundary, except for
x86.  Note that the relro segment, comprising of sections at the start
of the data segment, is sized according to how those sections are laid
out.  That means the start of the relro segment is fixed relative to
its end.  Which also means the start of the data segment must be at a
fixed address mod MAXPAGESIZE.  So for relro the linker can't play
games with the start of the data segment to save disk space.  At
least, not without introducing gaps between the relro sections.  In
fact, because the linker was starting layout using its simple
heuristic of starting the data segment at the end of the text segment
plus one page, it was sometimes introducing page gaps for no reason.
See pr28743.

PR 28824
PR 28734
* ldexp.c (fold_segment_align): When relro, don't adjust up by
offset within page.  Set relropagesize.
(fold_segment_relro_end): Align to relropagesize.
* ldexp.h (seg_align_type): Rename pagesize to commonpagesize.
Add relropagesize.  Comment.
* ldlang.c (lang_size_segment): Adjust to suit field renaming.
(lang_size_relro_segment_1): Align relro_end using relropagesize.

Automatic date update in version.in

Automatic date update in version.in

x86: Disallow invalid relocation against protected symbol

I am checking this into master and will backport it to 2.38 branch.

H.J
----
On x86, GCC 12 supports -mno-direct-extern-access to enable canonical
reference to protected function and disable copy relocation.  With
-mno-direct-extern-access, the canonical protected function symbols must
be accessed via canonical reference and the protected data symbols in
shared libraries are non-copyable. Under glibc 2.35, non-canonical
reference to the canonical protected function will get the run-time error:

./y: internal_f: ./libfoo.so: non-canonical reference to canonical protected function

and copy relocations against the non-copyable protected symbols will get
the run-time error:

./x: internal_i: ./libfoo.so: copy relocation against non-copyable protected symbol

Update x86 linker to disallow non-canonical reference to the canonical
protected function:

ld: plt.o: non-canonical reference to canonical protected function `internal_f' in libfoo.so
ld: failed to set dynamic section sizes: bad value

and copy relocation against the non-copyable protected symbol:

ld: main.o: copy relocation against non-copyable protected symbol `internal_i' in libfoo.so

at link-time.

bfd/

PR ld/28875
* elf-properties.c (_bfd_elf_parse_gnu_properties): Don't skip
shared libraries for GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS.
* elf32-i386.c (elf_i386_scan_relocs): Disallow non-canonical
reference to canonical protected function.
* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
* elfxx-x86.c (elf_x86_allocate_dynrelocs): Don't allow copy
relocation against non-copyable protected symbol.

ld/

PR ld/28875
* testsuite/ld-i386/i386.exp: Check non-canonical reference to
canonical protected function and check copy relocation against
non-copyable protected symbol.
* testsuite/ld-i386/pr21997-1.err: New file.
* testsuite/ld-i386/pr28875.err: Likewise.
* testsuite/ld-i386/pr28875a.c: Likewise.
* testsuite/ld-i386/pr28875b.c: Likewise.
* testsuite/ld-x86-64/pr21997-1a.err: Updated.
* testsuite/ld-x86-64/pr21997-1b.err: Likewise.
* testsuite/ld-x86-64/pr28875-data.err: New file.
* testsuite/ld-x86-64/pr28875-func.err: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Check non-canonical reference
to canonical protected function and check copy relocation against
non-copyable protected symbol.

Add initializers to bound_minimal_symbol

This adds initializers to bound_minimal_symbol, allowing for the
removal of some calls to memset.

gdb/fortran: support ptype and print commands for namelist variables

Gfortran supports namelists (a Fortran feature); it emits
DW_TAG_namelist and DW_TAG_namelist_item dies. But gdb does not
process these dies and does not support 'print' or 'ptype' commands on
namelist variables.

An attempt to print namelist variables results in gdb bailing out with
the error message as shown below.

  (gdb) print nml
  No symbol "nml" in current context.

This commit is to make the print and ptype commands work for namelist
variables and its items. Sample output of these commands is shared
below, with fixed gdb.

  (gdb) ptype nml
  type = Type nml
      integer(kind=4) :: a
      integer(kind=4) :: b
  End Type nml
  (gdb) print nml
  $1 = ( a = 10, b = 20 )

gdb: fix until behavior with trailing !is_stmt lines

When using the command "until", it is expected that GDB will exit a
loop if the current instruction is the last one related to that loop.
However, if there were trailing non-statement instructions, "until"
would just behave as "next".  This was noticeable in clang-compiled
code, but might happen with gcc-compiled as well.  PR gdb/17315 relates
to this problem, as running gdb.base/watchpoint.exp with clang
would fail for this reason.

To better understand this issue, consider the following source code,
with line numbers marked on the left:

  10: for (i = 0; i < 10; ++i)
  11:     loop_body ();
  12:   other_stuff ();

If we transform this to pseudo-assembler, and generate a line table,
we could end up with something like this:

  Address | Pseudo-Assembler | Line | Is-Statement?

  0x100   | i = 0            | 10   | Yes
  0x104   | loop_body ()     | 11   | Yes
  0x108   | i = i + 1        | 10   | Yes
  0x10c   | if (i < 10):     | 10   | No
  0x110   |     goto 0x104   | 10   | No
  0x114   | other_stuff ()   | 12   | Yes

Notice the two non-statement instructions at the end of the loop.

The problem is that when we reach address 0x108 and use 'until',
hoping to leave the loop, GDB sets up a stepping range that runs from
the start of the function (0x100 in our example) to the end of the
current line table entry, that is 0x10c in our example.  GDB then
starts stepping forward.

When 0x10c is reached GDB spots that we have left the stepping range,
that the new location is not a statement, and that the new location is
associated with the same source line number as the previous stepping
range.  GDB then sets up a new stepping range that runs from 0x10c to
0x114, and continues stepping forward.

Within that stepping range the inferior hits the goto (at 0x110) and
loops back to address 0x104.

At 0x104 GDB spots that we have left the previous stepping range, that
the new address is marked as a statement, and that the new address is
for a different source line.  As a result, GDB stops and returns
control to the user.  This is not what the user was expecting, they
expected GDB to exit the loop.

The fix proposed in this patch, is that, when the user issues the
'until' command, and GDB sets up the initial stepping range, GDB will
check subsequent SALs (symtab_and_lines) to see if they are
non-statements associated with the same line number.  If they are then
the end of the initial stepping range is extended to the end of the
non-statement SALs.

In our example above, the user is at 0x108 and uses 'until', GDB now
sets up a stepping range from the start of the function 0x100 to
0x114, the first address associated with a different line.

Now as GDB steps around the loop it never leaves the initial stepping
range.  It is only when GDB exits the loop that we leave the stepping
range, and the stepping finishes at address 0x114.

This patch also adds a test case that can be run with gcc to test that
this functionality is not broken in the future.

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

gas/doc: Fix "a true results" typo

gdb: extend the information printed by 'maint info jit'

This commit updates the output of 'maint info jit' to print not just
the jit_code_entry address, but also the symfile address, and the
symfile size.

The new information could be obtained by looking into target memory at
the contents of the jit_code_entry, but, by storing this information
within gdb at the time the jit object is loaded, it is now possible to
check if the jit_code_entry has been modified in target memory behind
gdb's back.

Additionally, the symfile address is the same address that is now used
in the objfile names after commit 4a620b7e.

One test that relies on the output of 'maint info jit' was updated to
allow for the new output format.

bfd: Remove return with expression in void function

      * bfd.c (bfd_set_gp_value): Remove return with expression
        in void function.

gdb: LoongArch: Add Makefile, configure and NEWS

This commit adds Makefile, configure and NEWS for LoongArch.

Signed-off-by: Zhensong Liu <liuzhensong@loongson.cn>
Signed-off-by: Qing zhang <zhangqing@loongson.cn>
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

gdb: LoongArch: Add initial native Linux support

This commit adds initial native Linux support for LoongArch.

Signed-off-by: Zhensong Liu <liuzhensong@loongson.cn>
Signed-off-by: Qing zhang <zhangqing@loongson.cn>
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

gdb: LoongArch: Add initial Linux target support

This commit adds initial Linux target support for LoongArch.

Signed-off-by: Zhensong Liu <liuzhensong@loongson.cn>
Signed-off-by: Qing zhang <zhangqing@loongson.cn>
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

gdb: LoongArch: Add initial baremetal support

This commit adds initial baremetal support for LoongArch.

Signed-off-by: Zhensong Liu <liuzhensong@loongson.cn>
Signed-off-by: Qing zhang <zhangqing@loongson.cn>
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

gdb: LoongArch: Add initial target description support

This commit adds initial target description support for LoongArch.

Signed-off-by: Zhensong Liu <liuzhensong@loongson.cn>
Signed-off-by: Qing zhang <zhangqing@loongson.cn>
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>

libctf: delete unused libctf_TEXINFOS

It's not clear what this was meant for, but it's not used by anything,
and the info pages still generate fine without it.

gdb/linux: remove ptrace support check for exec, fork, vfork, vforkdone, clone, sysgood

I think it's safe to remove checking support for these ptrace features,
they have all been added in what is now ancient times (around the
beginning of Linux 2.6).  This allows removing a bit of complexity in
linux-nat.c and nat/linux-ptrace.c.

It also allows saving one extra fork every time we start debugging on
Linux: linux_check_ptrace_features forks a child process to test if some
ptrace features are supported.  That child process forks a grand-child,
to test whether ptrace reports an event for the fork by the child.  This
is no longer needed, if we assume the kernel supports reporting forks.

PTRACE_O_TRACEVFORKDONE was introduced in Linux in this change, in 2003:

  https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=45c1a159b85b3b30afd26a77b4be312226bba416

PTRACE_O_TRACESYSGOOD was supported at least as of this change, in 2002:

  https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=acc7088569c8eef04eeed0eff51d23bb5bcff964

PTRACE_O_TRACEFORK, PTRACE_O_TRACEVFORK, PTRACE_O_TRACEEXEC and
PTRACE_O_TRACECLONE were introduced in this change, in 2002:

  https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=a0691b116f6a4473f0fa264210ab9b95771a2b46

Change-Id: Iffb906549a89cc6b619427f976ec044706ab1e8d

Automatic date update in version.in

gdb/infrun: some extra infrun debug print statements

While reviewing a different patch I wanted to know more about what was
going on during GDB's stepping.  I added some extra infrun debug print
calls, and I thought these might be useful to others.

Automatic date update in version.in

Update the obsolete list and how-to-make-a-release documentation now that the 2.38 release is out.

PR28763, SIGSEGV during processing of program headers via readelf

PR 28763
* readelf.c (process_file_header): Discard any cached program
headers if there is an extension field for e_phnum in first
section header.

Work around gcc-4 warnings in elf64-ppc.c

elf64-ppc.c: In function 'ppc64_elf_size_dynamic_sections':
elf64-ppc.c:10309:45: error: value computed is not used [-Werror=unused-value]
     ++lgot_ents, ++lgot_masks, isym != NULL && isym++)

It is of course a silly warning, fixed in later versions of gcc.  I
wrote "isym != NULL && isym++" rather than the simpler "isym++" to
stop sanitisers complaining about incrementing a NULL pointer.  isym
is of course unused in any code path where it might start off as
NULL.  Sometimes you can't win.  So don't try to be clever in reading
local symbols only when needed.  99 times out of 100 they will be
cached anyway.

* elf64-ppc.c (ppc64_elf_size_dynamic_sections): Avoid annoying
warnings by always reading local syms.
(ppc64_elf_layout_multitoc): Likewise.

Test --only-keep-debug on ELF relocatables

Add a test for commit 7c4643efe7be, which fixed --only-keep-debug for ELF
relocatables.

* testsuite/binutils-all/objcopy.exp
(keep_debug_symbols_for_elf_relocatable): New test.

Automatic date update in version.in

RISC-V: Stop reporting warnings for mismatched extension versions

The extension version checking logic is really just too complicated to
encode into the linker, trying to do so causes more harm than good.
This removes the checks and the associated tests, leaving the logic to
keep the largest version of each extension linked into the target.

bfd/

* elfnn-riscv.c (riscv_version_mismatch): Rename to
riscv_update_subset_version, and stop reporting warnings on
version mismatches.
(riscv_merge_std_ext): Adjust calls to riscv_version_mismatch.
(riscv_merge_multi_letter_ext): Likewise.

ld/
* testsuite/ld-riscv-elf/attr-merge-arch-failed-01.d: Remove
* testsuite/ld-riscv-elf/attr-merge-arch-failed-01a.s: Likewise
* testsuite/ld-riscv-elf/attr-merge-arch-failed-01b.s: Likewise
* testsuite/ld-riscv-elf/attr-merge-arch-failed-02.d: Likewise
* testsuite/ld-riscv-elf/attr-merge-arch-failed-02a.s: Likewise
* testsuite/ld-riscv-elf/attr-merge-arch-failed-02b.s: Likewise
* testsuite/ld-riscv-elf/attr-merge-arch-failed-02c.s: Likewise
* testsuite/ld-riscv-elf/attr-merge-arch-failed-02d.s: Likewise
* testsuite/ld-riscv-elf/attr-merge-user-ext-01.d: New test.
* testsuite/ld-riscv-elf/attr-merge-user-ext-rv32i21_m2p0.s:
Likewise.
* testsuite/ld-riscv-elf/attr-merge-user-ext-rv32i21_m2p1.s:
Likewise.
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Remove obselete
attr-merge-arch-failed-{01,02}, replace with
attr-merge-user-ext-01.

Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>

PR28862, heap-buffer-overflow in parse_stab_string

I have no info on the format of a "SUNPRO C++ Namespace" stab, so am
relying on the previous code being correct in parsing these stabs.
Just don't allow NULs anywhere in the stab.

PR 28862
* stabs.c (parse_stab_string): Don't overrun buffer when parsing
'Y' stab.