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.

Re: elf: Check symbol version without any symbols

* testsuite/ld-elf/pr24718-1.d: Don't xfail for hppa64.

gdb: remove tailing newlines from index_cache_debug calls

I noticed that most of the calls to index_cache_debug include a
trailing newline.  As the new debug mechanism already adds a newline,
that means all of these debug calls result in a blank line being
printed, which I think is a mistake.

Remove all the trailing newlines.

I also reformatted one of the index_cache_debug where a string will
now fit onto a single line.

Unless 'set debug index-cache on' is used, there should be no visible
change in output after this commit.

i386: Allow GOT32 relocations against ABS symbols

GOT32 relocations are allowed since absolute value + addend is stored in
the GOT slot.

Tested on glibc 2.35 build with GCC 11.2 and -Os.

bfd/

PR ld/28870
* elfxx-x86.c (_bfd_elf_x86_valid_reloc_p): Also allow GOT32
relocations.

ld/

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

Automatic date update in version.in

gdb/python: allow Value.format_string to return styled output

Add a new argument to the gdb.Value.format_string method, 'styling'.
This argument is False by default.

When this argument is True, then the returned string can contain output
styling escape sequences.

When this argument is False, then the returned string will not contain
any styling escape sequences.

If the returned string is going to be printed to the user, then it is
often nice to retain the GDB styling.

For the testing, we need to adjust the TERM environment variable, as
we do for all the styling tests.  I'm now running all of the C tests
in gdb.python/py-format-string.exp in an environment where styling
could be generated, but only my new test should actually produce
styled output, hopefully this will catch the case where a bug might
cause format_string to always produce styled output.

gdb: make thread_info::m_thread_fsm a std::unique_ptr

While working on function calls, I realized that the thread_fsm member
of struct thread_info is a raw pointer to a resource it owns.  This
commit changes the type of the thread_fsm member to a std::unique_ptr in
order to signify this ownership relationship and slightly ease resource
management (no need to manually call delete).

To ensure consistent use, the field is made a private member
(m_thread_fsm).  The setter method (set_thread_fsm) can then check
that it is incorrect to associate a FSM to a thread_info object if
another one is already in place.  This is ensured by an assertion.

The function run_inferior_call takes an argument as a pointer to a
call_thread_fsm and installs it in it in a thread_info instance.  Also
change this function's signature to accept a unique_ptr in order to
signify that the ownership of the call_thread_fsm is transferred during
the call.

No user visible change expected after this commit.

Tested on x86_64-linux with no regression observed.

Change-Id: Ia1224f72a4afa247801ce6650ce82f90224a9ae8

gdb: unbuffer all input streams when not using readline

This commit should fix PR gdb/28711.  What's actually going on is
pretty involved, and there's still a bit of the story that I don't
understand completely, however, from my observed results, I think that
the change I propose making here (or something very similar) is going
to be needed.

The original bug report involves using eclipse to drive gdb using mi
commands.  A separate tty is spun off in which to send gdb the mi
commands, this tty is created using the new-ui command.

The behaviour observed is that, given a particular set of mi commands
being sent to gdb, we sometimes see an ESPIPE error from a lseek
call, which ultimately results in gdb terminating.

The problems all originate from gdb_readline_no_editing_callback in
gdb/event-top.c, where we can (sometimes) perform calls to fgetc, and
allow glibc to perform buffering on the FILE object being used.

I say sometime, because, gdb_readline_no_editing_callback already
includes a call to disable the glibc buffering, but this is only done
if the input stream is not a tty.  In our case the input stream is a
tty, so the buffering is left in place.

The first step to understanding why this problem occurs is to
understand that eclipse sends multiple commands to gdb very quickly
without waiting for and answer to each command, eclipse plans to
collect all of the command results after sending all the commands to
gdb.  In fact, eclipse sends the commands to gdb that they appear to
arrive in the gdb process as a single block of data.  When reproducing
this issue within the testsuite I find it necessary to send multiple
commands using a single write call.

The next bit of the story gets a little involved, and this is where my
understanding is not complete.  I can describe the behaviour that I
observe, and (for me at least) I'm happy that what I'm seeing, if a
little strange, is consistent.  In order to fully understand what's
going on I think I would likely need to dive into kernel code, which
currently seems unnecessary given that I'm happy with the solution I'm
proposing.

The following description all relates to input from a tty in which I'm
not using readline.  I see the same problems either when using a
new-ui tty, or with gdb's standard, non-readline, mi tty.

Here's what I observe happening when I send multiple commands to gdb
using a single write, if I send gdb this:

  command_1\ncommand_2\ncommand_3

then gdb's event loop will wake up (from its select) as it sees there
is input available.  We call into gdb_readline_no_editing_callback,
where we call fgetc, glibc will do a single big read, and get back
just:

  command_1\n

that is, despite there being multiple lines of input available, I
consistently get just a single line.  From glibc a single character is
returned from the fgetc call, and within gdb we accumulate characters,
one at a time, into our own buffer.  Eventually gdb sees the '\n'
character, and dispatches the whole 'command_1' into gdb's command
handler, which processes the command and prints the result.  We then
return to gdb_readline_no_editing_callback, which in turn returns to
gdb's event loop where we re-enter the select.

Inside the select we immediately see that there is more input waiting
on the input stream, drop out of the select, and call back into
gdb_readline_no_editing_callback.  In this function we again call
fgetc where glibc performs another big read.  This time glibc gets:

  command_2\n

that is, we once again get just a single line, despite there being a
third line available.  Just like the first command we copy the whole
string, character by character into gdb's buffer, then handle the
command.  After handling the command we go to the event loop, enter,
and then exit the select, and call back to the function
gdb_readline_no_editing_callback.

In gdb_readline_no_editing_callback we again call fgetc, this time
glibc gets the string:

  command_3\n

like before, we copy this to gdb's buffer and handle the command, then
we return to the event loop.  At this point the select blocks while we
wait for more input to arrive.

The important bit of this is that someone, somewhere is, it appears,
taking care to split the incoming write into lines.

My next experiment is to try something like:

  this_is_a_very_long_command\nshort_command\n

However, I actually make 'this_is_a_very_long_command' very long, as
in many hundreds of characters long.  One way to do this is:

  echo xxxxxx.....xxxxx

and just adding more and more 'x' characters as needed.  What I'm
aiming for is to have the first command be longer than glibc's
internal read buffer, which, on my machine, is 1024 characters.

However, for this discussion, lets imagine that glibc's buffer is just
8 characters (we can create just this situation by adding a suitable
setbuf call into gdb_readline_no_editing_callback).

Now, if I send gdb this data:

  abcdefghij\nkl\n

The first read from glibc will get 'abcdefgh', that is a full 8
character buffer.  Once gdb has copied these to its buffer we call
fgetc again, and now glibc will get 'ij\n', that is, just like before,
multiple lines are split at the '\n' character.  The full command,
which is now in gdb's buffer can be handled 'abcdefghij', after which
we go (via the event loop) back to gdb_readline_no_editing_callback.
Now we call fgetc, and glibc will get 'kl\n', which is then handled in
the normal way.

So far, so good.  However, there is, apparently, one edge case where
the above rules don't apply.

If the '\n' character is the first character read from the kernel,
then the incoming lines are not split up.  So, given glibc's 8
character buffer, if I send gdb this:

  abcdefgh\nkl\n

that is the first command is 8 characters plus a newline, then, on the
first read (from within glibc) we get 'abcdefgh' in a single buffer.
As there's no newline gdb calls fgetc again, and glibc does another
large read, now we get:

  \nkl\n

which doesn't follow the above pattern - the lines are not split into
separate buffers!

So, gdb reads the first character from glibc using fgetc, this is the
newline.  Now gdb has a complete command, and so the command is
handled.  We then return to the event loop and enter the select.

The problem is that, as far as the kernel is concerned, there is no
more input pending, it's all been read into glibc's buffer, and so the
select doesn't return.  The second command is basically stuck in
glibc's buffer.

If I send another command to gdb, or even just send an empty
command (a lone newline) then the select returns, we call into
gdb_readline_no_editing_callback, and now gdb sees the second
command.

OK, so the above is interesting, but it doesn't explain the ESPIPE
error.

Well, that's a slightly different, but related issue.  The ESPIPE
case will _only_ show up when using new-ui to create the separate tty
for mi commands, and is a consequence of this commit:

  commit afe09f0b6311a4dd1a7e2dc6491550bb228734f8
  Date:   Thu Jul 18 17:20:04 2019 +0100

      Fix for using named pipes on Windows

Prior to this commit, the new-ui command would open the tty three
times, once each for stdin, stderr, and stdout.  After this commit we
open the tty just once and reuse the FILE object for all three roles.

Consider the problem case, where glibc has (unexpectedly) read the
second command into its internal buffer.  When we handle the first
command we usually end up having to write something to the mi output
stream.

After the above commit the same FILE object represents both the input
and output streams, so, when gdb tries to write to the FILE object,
glibc spots that there is input pending within the input buffer, and
so assumes that we have read ahead of where we should be in the input
file.  To correct for this glibc tries to do an lseek call to
reposition the file offset of the output stream prior to writing to
it.  However, as the output stream is a tty, and seeking is not
supported on a tty, this lseek call fails, this results in the ESPIPE,
which ultimately causes gdb to terminate.

So, now we understand why the ESPIPE triggers (which was what caused
the gdb crash in the original bug report), and we also understand that
sometime gdb will not handle the second command in a timely
fashion (if the first command is just the wrong length). So, what to
do about all this?

We could revert the commit mentioned above (and implement its
functionality another way).  This would certainly resolve the ESPIPE
issue, the buffered input would now only be on the input stream, the
output stream would have no buffered input, and so glibc would never
try to lseek, and so we'd never get the ESPIPE error.

However, this only solves one of the two problems.  We would still
suffer from the problem where, if the first command is just the wrong
length, the second command will not (immediately) get handled.

The only solution I can see to this problem is to unbuffer the input
stream.  If glibc is not buffering the input, but instead, we read
incoming data character by character from the kernel, then everything
will be fine.  As soon as we see the newline at the end of the first
command we will handle the first command.  As glibc will have no
buffered input it will not be tempted to lseek, so no ESPIPE error.
When we go have to the event loop there will be more data pending in
the kernel, so the select will immediately return, and the second
command will be processed.

I'm tempted to suggest that we should move the unbuffering of the
input stream out of gdb_readline_no_editing_callback and do it
somewhere earlier, more like when we create the input streams.
However, I've not done that in this commit for a couple of reasons:

  1. By keeping the unbuffering in gdb_readline_no_editing_callback
  I'm making the smallest possible change that fixes the bug.  Moving
  the unbuffering somewhere better can be done as a refactor later, if
  that 's felt to be important,

  2. I don't think making repeated calls to unbuffer the input will
  have that much performance impact.  We only make the unbuffer call
  once per call to gdb_readline_no_editing_callback, and, if the input
  stream is already unbuffered we'll return pretty quickly, so I don't
  see this as being massively costly,

  3. Tom is currently doing lots of gdb stream management changes and
  I want to minimise the chances we'll conflict.

So, this commit just changes gdb_readline_no_editing_callback to
always unbuffer the input stream.

The test for this issue sends two commands in a loop, with the first
command growing bigger each time around the loop.  I actually make the
first command bigger by just adding whitespace to the front, as gdb
still has to read the complete command (including whitespace) via
glibc, so this is enough to trigger the bug.

The original bug was reported when using a virtual machine, and in
this situation we see this in the strace output:

  read(9, "70-var-info-path-expression var1.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa", 1024) = 64
  read(9, "\n71-var-info-path-expression var1.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\n", 1024) = 67

I'm not completely sure what's going on here, but it appears that the
kernel on the virtual machine is delivering the input to glibc slower
than I see on my real hardware; glibc asks for 1024 bytes, but only
gets 64 bytes the first time.  In the second read we see the problem
case, the first character is the newline, but then the entire second
command is included.

If I run this exact example on my real hardware then the first command
would not be truncated at 64 bytes, instead, I'd expect to see the
newline included in the first read, with the second command split into
a second read.

So, for testing, I check cases where the first command is just a few
characters (starting at 8 character), all the way up to 2048
characters.  Hopefully, this should mean we hit the problem case for
most machine setups.

The only last question relates to commit afe09f0b6311a4d that I
mentioned earlier.  That commit was intended to provide support for
Microsoft named pipes:

  https://docs.microsoft.com/en-us/windows/win32/ipc/named-pipes

I know next to nothing about this topic beyond a brief scan of the
above link, but I think these windows named pipe are closer in
behaviour to unix sockets than to unix named fifos.

I am a little nervous that, after the above commit, we now use the
same FILE for in, err, and out streams.  In contrast, in a vanilla C
program, I would expect different FILE objects for each stream.

Still, I'm reluctant to revert the above commit (and provide the same
functionality a different way) without a specific bug to point at,
and, now that the streams are unbuffered, I expect a lot of the read
and write calls are going straight to the kernel with minimal glibc
involvement, so maybe it doesn't really matter.  Anyway, I haven't
touched the above patch, but it is something to keep in mind when
working in this area.

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

gdb/disasm: combine the no printing disassembler setup code

We have three places in gdb where we initialise a disassembler that
will not print anything (used for figuring out the length of
instructions, or collecting other information from the disassembler).

Each of these places has its own stub function to act as a print like
callback, the stub function is identical in each case, and just does
nothing.

In this commit I create a new function to initialise a disassembler
that doesn't print anything, and have all three locations use this new
function.  There's now only one non-printing stub function.

There should be no user visible changes after this commit.