Remove the local symbol ldh definitions with hidden visibility from the
relax-call36-*.s tests. The hidden visibility is meaningless for local
defined symbols and makes the test cases error.

Allow people to build GCC with multilib support even without
--enable-targets=all in binutils configuration.

This fixes a potential problem with merging non-visibility bits in
st_other. Non-visibilty bits in st_other have an architecture
dependent meaning, so they cannot just be copied from a foreign ELF
object file. I think the safest thing to do in this situation is
ignore non-visibility st_other bits. That's what this patch does.

PR 34062
* elflink.c (elf_merge_st_other): Replace abfd param with
obfd and ibfd parameters. Do not call
elf_backend_merge_symbol_attribute when input xvec differs
from output xvec.
(_bfd_elf_merge_symbol, _bfd_elf_add_default_symbol),
(elf_link_add_object_symbols),
(_bfd_elf_copy_link_hash_symbol_type): Pass both output bfd
and input bfd to elf_merge_st_other.

This renames "abfd" function parameters to "obfd" when that parameter
is always the output bfd, and to "dynobj" when it is always the input
object used to attach dynamic sections. "bed" variables which are set
to the output bfd or dynobj backend data are renamed to "obed". (The
dynobj xvec must be the same as the output xvec, or bad things
happen.) The idea is to make the use of bfd* parameter a little more
obvious when reading the source.

This fixes a bug with the .note.spu_name section flags, which were
made SEC_LOAD without SEC_ALLOC. That combination doesn't really make
sense and led to odd layout behaviour. In addition .note.spu_name
now uses the normal note alignment, with some tweaks to keep its file
offset 16 byte aligned. This tends to work better in the testsuite
when the standard scripts are not used and the note is merged with
other notes.

bfd/
* elf32-spu.c (spu_elf_create_sections): Remove SEC_LOAD from
.note.spu_name, and align to 4 bytes.
(spu_elf_fake_sections): Tweak .note.spu_name output section
alignment for layout.
(spu_elf_final_write_processing): New function.
(elf_backend_final_write_processing): Define.
binutils/
* testsuite/binutils-all/objcopy.exp (pr25662): Don't xfail spu.
ld/
* testsuite/ld-elf/orphan-region.d: Don't xfail spu.
* testsuite/ld-elf/pr23658-1e.d: Likewise.
* testsuite/ld-scripts/provide-8.d: Likewise.
* testsuite/ld-spu/ovl.d: Remove commented out old matches.
Adjust expected overlay file offset.
* testsuite/ld-spu/ovl2.d: Likewise.

I noticed that the 'maint test-remote-args' command, implemented by
the test_remote_args_command function in remote.c, contains this code:

static void
test_remote_args_command (const char *args, int from_tty)
{
std::vector<std::string> split_args = gdb::remote_args::split (args);
... etc ...

The problem here is that gdb::remote_args::split expects a std::string,
and so ends up creating a std::string from ARGS. However, ARGS can be
NULL, e.g. if a user does this:

(gdb) maint test-remote-args

This ends up creating a std::string from a NULL pointer, which is
undefined behaviour.

Fix this by adding a check to test_remote_args_command, and throwing
an error if ARGS is NULL. Add a new test to verify this case.

Additionally, fix a typo in the header comment for
test_remote_args_command.

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

FEAT_LRCPC3 introduces various load/store instructions with release
consistency for cases where ordering is required. This patch teaches GDB
to decode these instructions for recording and reversing.

The gdb.reverse/aarch64-lrcpc3.exp testcase verifies that the
instructions are recorded and correctly reversed. In particular, there
are some interesting cases to note:
* ldapur/stlur are SIMD instructions, but are not decoded in the simd
function.
* There are writeback cases to cover too. These were taken from the
binutils testcases: gas/testsuite/gas/aarch64/rcpc3.s.

The full testsuite was done on aarch64-none-linux-gnu without LRCPC3.
The gdb.arch and gdb.reverse tests were run on Shrinkwrap with LRCPC3
support.

Please note:
1) There is no support for LRCPC and LRCPC2 instructions
2) LRCPC3 is gated with +rcpc3 in GCC/binutils and LLVM.

Approved-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

Another comment marker doxygen supports is "/**<". Replace it with "/*".

Suggested-By: Kevin Buettner <kevinb@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>

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

Remove doxygen \page marker in gdb/gdbtypes.h.

Approved-By: Kevin Buettner <kevinb@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>

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

Doxygen supports a multi-line comment marker '/**'. In GDB we're using
something slightly similar: '/* *' [1].

Drop this and just use '/*'.

Result of:
...
$ find gdb* -type f -name "*.[ch]" -o -name "*.def" \
| egrep -v /testsuite/ \
| xargs sed -i 's%/\* \* %/* %'
...
and manually reverting the change in the comment for BINOP_MUL in
gdb/std-operator.def.

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

Approved-By: Kevin Buettner <kevinb@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>

[1] https://sourceware.org/gdb/wiki/DoxygenForGDB

We have some form of doxygen support, allowing to run "make doxy" in
build/gdb/doc, but in the result I didn't find any references to gdbsupport
(moved to top-level in 2019), so I'm assuming this is unmaintained for a long
time now.

Remove it.

Reviewed-by: Kevin Buettner <kevinb@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>

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

This patch converts dw2-const.exp to use the DWARF assembler rather
than a .S file. The conversion was largely done using the script from
contrib.

Following a suggestion from Tom de Vries, this version sets addr_size
to 8. This makes the test pass with -m32 as well.

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

I found a few files in gdb/contrib that were missing a copyright notice.

In codespell-ignore-words.txt, it was trivial to add, but I found a
codespell issue stating that it's not explicitly support, so I added a note
about that.

In codespell-dictionary.txt, I had to resort to a hack, using an "empty word"
rewrite rule:
...
-># Comment here.
...

Also, I found that empty lines are not allowed in codespell-dictionary.txt. I
filed an issue about these two problems [1].

Since these two files were added in 2025, I've used 2025-2026 as copyright
years.

Tested by running "pre-commit run --all-files".

[1] https://github.com/codespell-project/codespell/issues/3901

Fix typos in gdb/doc and replace "SME" with "sme" in
gdb/contrib/codespell-ignore-words.txt, and add "wither" and "stap".

Fix typos in gdb/stubs, and add "parm" to
gdb/contrib/codespell-ignore-words.txt.

Fix typos in gdb/features.

Fix typos in gdb/nat, and add "fpr" to gdb/contrib/codespell-ignore-words.txt.

Fix typos in gdb/contrib.

The codespell settings are currently in gdb/contrib/setup.cfg.

There's a goal to move settings of Python tools used for gdb to
gdb/pyproject.toml.

Do so, and update the args entries in .pre-commit-config.yaml:
...
- args: [--config, gdb/contrib/setup.cfg]
+ args: [--toml, gdb/pyproject.toml]
...

It's necessary to point codespell as used in pre-commit to the pyproject.toml
file, because:
- pre-commit uses codespell with the repository root as working directory
- codespell currently only supports discovery of configuration files in the
working directory. There's an issue open to support hierarchical
pyproject.toml files [1].

Likewise, it's necessary to point codespell on the CLI to the pyproject.toml
file:
...
$ codespell --toml gdb/pyproject.toml
...

Now that the codespell settings are in gdb/pyproject.toml, codespell will
automatically discover it when running codespell in the gdb directory.
However, that's not useful, because the paths in gdb/pyproject.toml are
relative to the repository root. Hopefully, that will be fixed once codespell
supports hierarchical toml files.

In the mean time, we could fix this by moving the settings to a pyproject.toml
file in the repository root. But we have been avoiding this sofar (to keep
project-related things out of the repository root as much as possible), so we
continue having this pre-existing issue.

[1] https://github.com/codespell-project/codespell/issues/3737

The current definition of codespell:ignore-begin/end is greedy and
consequently in this example:
...
/* codespell:ignore-begin */
/* Ignore this: usuable. */
/* codespell:ignore-end */

/* Don't ignore this: usuable. */

/* codespell:ignore-begin */
/* Ignore that: usuable. */
/* codespell:ignore-end */
...
the "Don't ignore this" line will be ignored.

Fix this by making the definition non-greedy.

This patch is aimed at fixing "FAIL: eqv involving dot" and any
similar problems in real code when generating DWARF.

* config/obj-macho.c (obj_mach_o_frob_label),
(obj_mach_o_frob_symbol): Ignore more debug symbols.
(obj_mach_o_set_subsections): Ignore SEC_DEBUGGING sections.
(obj_mach_o_force_reloc_sub_same),
(obj_mach_o_force_reloc_sub_local),
(obj_mach_o_force_reloc): Add seg param. Return false when
processing debug sections.
* config/obj-macho.h: Update prototypes.
* config/tc-i386.h <OBJ_MACHO>: Smuggle section being
processed by TC_FORCE_RELOCATION* to obj_macho_o functions.

The macho gas support starts a new frag at non-local labels,
identifying the frag with the label symbol as a "subsection". Relocs
are needed when referencing labels in a different subsection, to
support relaxation. There is a problem when reloc symbols are reduced
to a section symbol plus offset (see write.c:adjust_reloc_syms), as
this loses the subsection. Not reducing symbols like this is not a
good option as it results in a large number of symbols, some with
weird internal gas names. So instead this patch finds the original
frag for any fx_addsy reduced to a section symbol.

Test results are:
+FAIL: .org test 1
-FAIL: i386 opcodes
-FAIL: i386 opcodes (Intel disassembly)
-FAIL: i386 opcodes (w/ suffix)
-FAIL: i386 intel (AT&T disassembly)
-FAIL: i386 intel
-FAIL: Check -madd-bnd-prefix
-FAIL: x86-64 RTM insns
-FAIL: x86-64 RTM insns (Intel disassembly)
-FAIL: Check -madd-bnd-prefix (x86-64)

The reason ".org test 1" fails is the -gdwarf2 .debug_aranges
generates two temp symbols and uses them for the start and size of
each range, the size being calculated by "end" - "beg" (see
out_debug_aranges). For the test, "beg" is before any source symbol
is emitted so has subsection NULL. "end" has a subsection but lost
that when the fixup was converted to a section symbol plus offset.
So prior to this change obj_mach_o_in_different_subsection returned
false. Now that the lost subsection is recovered for "end" it returns
true, and results in "Error: can't resolve .text - L0^A$".

* config/obj-macho.c (obj_mach_o_in_different_subsection):
Add parameters. Get frag containing section sym plus offset.
(obj_mach_o_force_reloc_sub_same): Adjust to suit
obj_mach_o_in_different_subsection change.
(obj_mach_o_force_reloc_sub_local): Likewise.
(obj_mach_o_force_reloc): Likewise.
* testsuite/gas/i386/insn-32.d: Don't xfail darwin.
* write.c (get_frag_for_address): New function, extracted from..
(get_frag_for_reloc): ..here.
* write.h (get_frag_for_address): Declare.

Commit cc28c46227cd caused testsuite regressions on i386-darwin:
i386-darwin +FAIL: i386 intel-ok (directive)
i386-darwin +FAIL: i386 intel-ok (cmdline option)

Reduced testcase:
.intel_syntax noprefix
mov eax, [offset x] - [1]
This triggers an obj_mach_o_check_before_writing error, because x
is indeed undefined. However, the error is nonsense because fx_subsy
is the absolute value 1, and that should just result in a relocation
against x with an addend of -1.

What's more, obj_mach_o_check_before_writing runs before symbols
are resolved. At that point undefined symbols may be wrapped in an
expression symbol. Expression symbols are S_IS_DEFINED, which is
why the error did not trigger until commit cc28c46227cd simplified
away the expression symbol wrapper. So obj_mach_o_check_before_writing
is ineffective in some cases and overly restrictive in others. If
something like it is necessary the correct place to do so is after
fixups have been simplified. In fact there is a sufficient check in
write.c:fixup_segment but the macho support disables it by defining
TC_VALIDATE_FIX_SUB to 1.

This patch reverts commit 16a87420985f (see
https://sourceware.org/pipermail/binutils/2012-February/075591.html),
and removes the define of TC_VALIDATE_FIX_SUB for macho. I'm sure it
is wrong to whitewash fixups by using TC_VALIDATE_FIX_SUB in this way.
Any fx_subsy that is left at that point will be ignored by the x86
md_apply_fix and tc_gen_reloc functions, except for a few special
cases. That will result in incorrect relocations.

The patch also corrects obj_mach_o_force_reloc_sub_local. Since this
is a predicate testing whether fx_subsy can be eliminated (and the
fixup made pc-relative) it ought to be testing for fx_subsy in the
same subsection as the fixup frag. This cures "FAIL: i386 sub".

* config/obj-macho.c (obj_mach_o_check_before_writing): Delete.
(obj_mach_o_pre_output_hook): Delete.
(obj_mach_o_in_different_subsection): Make static. Return bool.
(obj_mach_o_force_reloc_sub_same): Return bool.
(obj_mach_o_force_reloc_sub_local): Rewrite to check fx_subsy.
(obj_mach_o_force_reloc): Return bool.
* config/obj-macho.h (md_pre_output_hook): Don't define.
(obj_mach_o_in_different_subsection): Delete.
(obj_mach_o_force_reloc, obj_mach_o_force_reloc_sub_same),
(obj_mach_o_force_reloc_sub_local): Update.
* config/tc-i386.h (TC_VALIDATE_FIX_SUB <OBJ_MACH_O>): Likewise.

Fix oss-fuzz induced damage.

stabs.c (parse_stab_type): Don't access beyond end of stab
with bad type.
(parse_stab_array_type): Don't duplicate "bad stab" message.

This reverts commit b083976272bd663ed036692e54796870b3bf6c89.

The new assert triggers in test-cases gdb.ada/uninitialized-variable-record.exp and
gdb.ada/uninitialized_vars.exp on x86_64-linux.

With gcc 16 and test-case gdb.cp/classes.exp I run into:
...
classes.cc:440:15: warning: anonymous non-C-compatible type given name for linkage purposes by 'typedef' declaration [-Wnon-c-typedef-for-linkage]^M
440 | typedef class {^M
| ^^M
| DynamicBase2^M
classes.cc:443:15: note: type is not C-compatible because it contains 'virtual int DynamicBase2::get_x()' declaration^M
443 | virtual int get_x () { return x; }^M
| ^~~~~^M
...

Fix this by applying Wno-non-c-typedef-for-linkage, which is already done for
clang.

Likewise for gdb.cp/class2.exp.

Reviewed-By: Keith Seitz <keiths@redhat.com>

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

With gcc 16, defaulting to c++20, and test-case gdb.cp/cmpd-minsyms.exp I run
into:
...
cmpd-minsyms.cc: In function 'int main(int, char**)':^M
cmpd-minsyms.cc:39:13: warning: C++20 says that these are ambiguous, even \
though the second is reversed:^M
39 | if (a == b)^M
| ^^M
cmpd-minsyms.cc:26:8: note: candidate 1: 'int GDB<T>::operator==(const GDB<T>&) [with T = int]'^M
26 | int operator == (GDB const& other)^M
| ^~~~~~~~^M
cmpd-minsyms.cc:26:8: note: candidate 2: 'int GDB<T>::operator==(const GDB<T>&) [with T = int]' (reversed)^M
cmpd-minsyms.cc:26:8: note: try making the operator a 'const' member function^M
...

Fix this by following the advice:
...
- int operator == (GDB const& other)
+ int operator == (GDB const& other) const
{ return 1; }
...

Likewise in gdb.cp/many-args.exp.

Reviewed-By: Keith Seitz <keiths@redhat.com>

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

This commit is for the benefit of GDB, but as the binutils-gdb
repository shares the contrib/ directory with GCC, this commit
must first be applied to GCC and then copied back to binutils-gdb.

When running GDB tests in parallel (make check -j$(nproc)), the
consolidated gdb.sum and gdb.log files are produced by
contrib/dg-extract-results.py, which merges per-test output files.

If any single per-test output file is malformed (e.g., due to a
DejaGnu EILSEQ crash, which is how I encountered this problem), the
script aborts via self.fatal(). Because this script is invoked via a
Makefile command using shell redirection, this causes the top-level
output files to be left as empty, zero-byte files, discarding valid
results from all other tests.

Fix by making the script tolerant of unparseable input files. Wrap
each file's parsing in a try/except block. When a file cannot be
parsed, emit a warning to stderr and continue processing remaining
files. This ensures that crashing tests do not destroy the
consolidated output for the entire parallel build.

Tested on Fedora 44 using the GCC testsuite (make check-gcc
-j$(nproc)). The consolidated results are produced correctly with
no regressions.

This commit fixes this GDB bug:

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

contrib/ChangeLog:

* dg-extract-results.py: Show warnings instead of erroring out
when encountering an unparseable file.

On Fedora 44 and Rawhide (Fedora 45), these tests...

gdb.ada/non-ascii-utf-8.exp
gdb.base/utf8-identifiers.exp
gdb.rust/unicode.exp

...all die due to these errors:

Running ...gdb/testsuite/gdb.base/utf8-identifiers.exp ...
ERROR: tcl error sourcing .../gdb/testsuite/gdb.base/utf8-identifiers.exp.
ERROR: tcl error code POSIX EILSEQ {invalid or incomplete multibyte or wide character}
error writing "file6": invalid or incomplete multibyte or wide character
...

(I've shortened some of the pathnames for brevity.)

These Fedora systems are using Tcl 9 and also an updated version of
dejagnu with this change applied:

* Thu Apr 16 2026 Jakub Jelinek <jakub@redhat.com> - 1:1.6.3-17
- Apply full set of Tcl 9 compatibility fixes from upstream PR80674 branch
(#2448542)

That runtest change is responsible for the POSIX EILSEQ errors on
machines with that change. The change to runtest causing the change
in behavior for GDB is the addition of these lines near the top of
the runtest script:

# Ensure that DejaGnu will be run in the POSIX locale
LC_ALL=C
export LC_ALL

Tcl 8 used a permissive encoding strategy: bytes that could not be
represented in the current encoding were silently mangled or
substituted. Tcl 9 changed this default to a strict profile, which
means that any attempt to write a character that cannot be expressed
in the channel's encoding raises a POSIX EILSEQ error ("invalid or
incomplete multibyte or wide character").

So, together, this Tcl 9 behavior combined with the dejagnu change
to runtest causes the EILSEQ error for the tests mentioned earlier.

Fix it by using "fconfigure $handle -encoding utf-8 -profile replace"
in proc spawn_capture_tty_name, and proc gdb_stdin_log_init. Also,
the open_logs wrapper has been changed to invoke fconfigure using only
"-encoding utf-8". Testing showed that "-profile replace" wasn't
necessary there.

Tested on Fedora 28 (Tcl 8.6.8), Fedora 43 (Tcl 9.0.2 / 8.6.16; expect
uses 8.6.16), Fedora 44 (Tcl 9.0.2 / 8.6.17; expect uses 9.0.2), and
Rawhide / Fedora 45 (Tcl 9.0.3 / 8.6.18; expect uses 9.0.3).

With regard to the Bug noted below, I haven't been able to reproduce
the failures in gdb.ada/lazy-string.exp, but I've been informed that
this commit fixes it.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34146
Reviewed-By: Tom de Vries <tdevries@suse.de>

C++ always allows enum bitfields, so gdb no longer needs to use the
ENUM_BITFIELD macro.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32821
Approved-By: Andrew Burgess <aburgess@redhat.com>
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

Andrew pointed out that the use of is_convertible in gdb::ref_ptr is
incorrect, and that it should instead check the value. This can
easily be done using gdb::Requires.

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

ada-lang.c:eval_ternop_in_range is only used in a single spot. This
patch merges it into its sole caller. Helper functions like this are
still sometimes left over from the big expression rewrite.

I'm checking this in as obvious.

I wrote a patch containing:
...
dw2_instantiate_symtab (cu->per_cu, ...);
...
and ran into a use-after-free at a following use of cu.

The problem is that dw2_instantiate_symtab contains:
...
free_cached_comp_units freer (per_objfile);
...
and that the destructor does:
...
~free_cached_comp_units ()
{
m_per_objfile->remove_all_cus ();
}
...
which also frees the cu we used in the cu->per_cu argument to
dw2_instantiate_symtab.

Detect this situation using an assert in the free_cached_comp_units
constructor.

Tested on aarch64-linux.

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

The call to bfd_check_format in try_open_dwop_file:
...
/* The operations below are not thread-safe, use a lock to synchronize
concurrent accesses. */
static gdb::mutex mutex;
gdb::lock_guard<gdb::mutex> lock (mutex);

if (!bfd_check_format (sym_bfd.get (), bfd_object))
return NULL;
...
accesses the sym_bfd.get () BFD, so it should be guarded by the global BFD
lock.

Fix this by:
- using the global BFD lock in gdb_bfd_check_format, and
- removing the local lock.

Likewise, use the global BFD lock in gdb_bfd_check_format_matches.

The local lock also guarded a call to gdb_bfd_record_inclusion, which doesn't
do any locking, so likewise use the global BFD lock in
gdb_bfd_record_inclusion.

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

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

Add new bfd wrappers:
- gdb_bfd_check_format for bfd_check_format, and
- gdb_bfd_check_format_matches for bfd_check_format_matches.
and run this command to use them:
...
$ sed -i 's/bfd_check_format/gdb_bfd_check_format/' \
$(find gdb* -type f | egrep -v "/testsuite/|ChangeLog")
...

No functional changes.

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

Rename the Arm AEABI CPU architecture tag constants and macro definitions to include the
profile suffix for A-profile architectures. This makes the naming
consistent with existing v8-R and v8-M tag names, while preserving the
existing numeric tag values.

Update BFD, GAS and Gold usage accordingly, including attribute combination
tables, architecture checks, and mach selection.

commit eb4031cb20aa710834be891f8638e04dbba81edc
Author: Jan Beulich <jbeulich@suse.com>
Date: Tue Jul 4 17:07:26 2023 +0200

x86: optimize 128-bit VPBROADCASTQ to VPUNPCKLQDQ

was supposed to optimize

vpbroadcastq %xmmN, %xmmM -> vpunpcklqdq %xmmN, %xmmN, %xmmM (N < 8)

But it didn't check if the destination operand is XMM. As the result, it
turned:

vpbroadcastq %xmmN, %ymmM

into

vpunpcklqdq %xmmN, %xmmN, %xmmM

Fixing it by checking XMM destination.

PR gas/34171
* config/tc-i386.c (optimize_encoding): Check XMM destination
when optimizing 128-bit VPBROADCASTQ.
* testsuite/gas/i386/optimize-2.d: Updated.
* testsuite/gas/i386/optimize-2.s: Add 256-bit vpbroadcastq.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

FEAT_LSE128 introduces support for 128-bit atomic instructions. This
patch teaches GDB to decode these instructions for recording and
reversing.

Regression tested on aarch64-none-linux-gnu on QEMU with LSE128 support.

Approved-By: Guinevere Larsen <guinevere@redhat.com>

GDB can handle AArch64's CSSC instructions but there were no tests
ensuring that and ensuring no regressions would creep in. This commit
adds some tests for these instructions. This was tested on
aarch64-none-linux-gnu on QEMU with CSSC support.

Approved-By: Guinevere Larsen <guinevere@redhat.com>

asan complains "runtime error: member access within null pointer"
for &h->root with NULL h, which is annoying since &h->root is the
same address as h, causing
alpha-linux-gnu +FAIL: TLS -fpic -shared
alpha-linux-gnu +FAIL: TLS -fpic and -fno-pic exec
alpha-linux-gnu +FAIL: TLS -fpic and -fno-pic exec -relax

* elf64-alpha.c (elf64_alpha_relocate_section): Fix asan
complaint.

For processes using the ROCm runtime, GPU code objects are reported to
the debugger in the form of a URI (those are available to GDB using the
amd_dbgapi_process_code_object_list function and query the
AMD_DBGAPI_CODE_OBJECT_INFO_URI_NAME property). Each URI can be of 2
forms:
- "memory://$PID/mem#offset=$ADDR&size=$SIZE"
- "file://$PATH#offset=$OFFSET&size=$SIZE"

On the Windows platform, only the "memory" URI form is used at the
moment, but future runtime changes might make it report code objects
using the "file" form. When using the "file" form, when the runtime
reports an absolute path, the URI will look something like this:

file:///C:/foo/bar/file.exe#offset=0x123&size=0x321

The decoding scheme currently implemented in
gdb/solib-rocm:rocm_bfd_iovec_open would extract the file path as
"/C:/foo/bar/file.exe", and will eventually hand this path to
solib_open.

Surprisingly enough, solib_open still manages to locate the file
properly. This is due to the following of code which effectively drops
the leading "/" turning the path into a valid absolute path which can
eventually be opened.

/* If the search in gdb_sysroot failed, and the path name is
absolute at this point, make it relative. (openp will try and open the
file according to its absolute path otherwise, which is not what we want.)
Affects subsequent searches for this solib. */
if (found_file < 0 && IS_TARGET_ABSOLUTE_PATH (fskind, in_pathname))
{
/* First, get rid of any drive letters etc. */
while (!IS_TARGET_DIR_SEPARATOR (fskind, *in_pathname))
in_pathname++;

/* Next, get rid of all leading dir separators. */
while (IS_TARGET_DIR_SEPARATOR (fskind, *in_pathname))
in_pathname++;
}

This patch proposes to fix rocm_solib so we properly decode the file
path and give a valid path to solib_open to properly support this
scheme.

Note that this patch only looks for forward slashes "/" in the pattern
matching and not the traditional backslashes (as IS_TARGET_DIR_SEPARATOR
would) as URIs use forward slashes, not backslashes.

Current GDB does not really AMDGPU debugging on Windows (there are still
a couple of missing necessary pieces), but this patch can still be
applied upstream and will eventually be needed. I have tested this
patch on top of the downstream ROCgdb windows branch[1]. I have also
tested this patch on Linux + gfx1031 on top of master to ensure this
causes no regression.

[1] https://github.com/ROCm/ROCgdb/tree/amd-temp-windows

Approved-By: Pedro Alves <pedro@palves.net>
Change-Id: I10a1a32167007d5613e5a8696918bad5438285f3

Fixes PR binutils/34168: build failure with -Werror=format-security.

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

Signed-off-by: Will Hawkins <hawkinsw@obs.cr>

Commit 519774805a1 ("Don't pretend infcalls don't set the inferior
running (PR gdb/34082)") removed the special case in proceed that
skipped set_state(THREAD_RUNNING) for infcalls. That fixed
gdb.threads/hand-call-new-thread.exp, but introduced a regression in
gdb.compile/compile.exp:

...
set unwind-on-signal on
(gdb) PASS: gdb.compile/compile.exp: set unwind-on-signal on
compile code *(volatile int *) 0 = 0;
The program being debugged received signal SIGSEGV, Segmentation fault
while in a function called from GDB. GDB has restored the context
to what it was before the call. To change this behavior use
"set unwind-on-signal off". Evaluation of the expression containing
the function (_gdb_expr) will be abandoned.
(gdb) PASS: gdb.compile/compile.exp: compile code segfault second
break 132
Breakpoint 2 at 0x555555555262: file .../compile.c, line 132.
(gdb) continue
Cannot execute this command while the selected thread is running.
(gdb) FAIL: gdb.compile/compile.exp: continue to breakpoint: break-here

The "compile code" command before the FAIL is an infcall under the
hood. That hits SIGSEGV with "set unwind-on-signal on" in effect, so
GDB unwinds and abandons the call. After that, "continue" is rejected
because the thread is still marked THREAD_RUNNING from the proceed
that started the infcall.

When an infcall is unwound due to a signal, timeout, or terminating
exception, call_thread_fsm::should_notify_stop returns false, and so
normal_stop is not called from fetch_inferior_event. normal_stop is
what would normally call finish_thread_state to sync the public thread
state back to THREAD_STOPPED. run_inferior_call has a fallback
finish_thread_state call for that purpose, but it is gated on
stop_stack_dummy == STOP_STACK_DUMMY, which is only true for
successful calls.

Before the commit mentioned above, proceed never marked an infcall's
thread as THREAD_RUNNING, so the missing RUNNING => STOPPED transition
was harmless. The old comment in infcall.c about the
finish_thread_state call claimed "If the infcall does NOT succeed,
normal_stop will have already finished the thread states", but that
was already incorrect for the unwind paths. It just happened to not
matter.

Fix this by dropping the STOP_STACK_DUMMY guard and updating the
comment to describe the actual rule: sync regardless of how the call
ended. The !was_running check is kept since it is there to exclude
the in-cond-eval case, where the thread is meant to stay marked
running. finish_thread_state is idempotent, so the call is harmless
on paths where normal_stop also ran.

Extend gdb.base/unwindonsignal.exp to exercise the "set
unwind-on-signal on" path without having to rely on the "compile code"
feature. Without the fix, the test fails like so:

info threads
Id Target Id Frame
* 1 Thread 0x7ffff7f8f740 (LWP 239019) "unwindonsignal" (running)
(gdb) FAIL: gdb.base/unwindonsignal.exp: thread is stopped
continue
Cannot execute this command while the selected thread is running.
(gdb) FAIL: gdb.base/unwindonsignal.exp: continue until exit at after unwound infcall

Similarly, extend gdb.cp/gdb2495.exp for "set
unwind-on-terminating-exception on", and gdb.base/infcall-timeout.exp
for "set unwind-on-timeout on". Both would fail without the code fix,
too.

With the fix, gdb.compile/compile.exp now passes cleanly.

Tested on x86_64-unknown-linux-gnu.

Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34148
Change-Id: Idef0dcd4dd751b501869c58b752f77d4dadb6c72

nds32_elf_lo12_reloc reads the lo reloc word when processing stashed
hi relocs.

* elf32-nds32.c: Replace bfd_octets_per_byte with OCTETS_PER_BYTE
throughout file.
(nds32_elf_lo12_reloc): Sanity check reloc offset.

Commit d0ff5ca959df adding PT_AARCH64_MEMTAG_MTE support, creates
a section that stores "p_memsz" from the program header in "rawsize"
and "p_filesz" in "size". p_memsz is the memory range, usually 32
times p_filesz. This can be a problem when bfd reads the section, for
example to display it with objdump -s, as the usual (linker) meaning
for input section "rawsize" is the original size on disk. Memory is
allocated to read the larger of "size" and "rawsize". So 32 times the
memory is allocated than what is really needed.

With fuzzed input "rawsize" can be smaller than "size" since the
header values are not sanity checked. This results in section
contents with only the first "rawsize" bytes read from disk, the rest
being uninitialised. Of course fuzzed input can also have very large
"rawsize" which might result in OOM.

One way of fixing this is to move the p_memsz value somewhere else
(output_offset would work, I think). Another might be to qualify use
of rawsize by is_linker_input, but I haven't checked over all the bfd
code using rawsize. And then there is this approach:

* bfd.c (bfd_get_section_limit_octets),
(bfd_get_section_alloc_size): Ignore rawsize in bfd_core.
* bfd-in32.h: Regenerate.