Add wrapped_file::write

This adds an implementation of wrapped_file::write.  With this change,
a wrapped_file can be used as-is, without requiring a subclass.  This
is convenient for a subsequent patch.

An existing subclass is simplified due to this change.

Remove PRINT_LITERAL_FORM

The PRINT_LITERAL_FORM macro is unused.  This patch removes it.

Use 'true' when assigning to sevenbit_strings

MI assigns '1' to sevenbit_strings but should use 'true' instead.

gdb/python: allow Architecture.disassemble to give styled output

Extend the Architecture.disassemble API to allow the user to request
styled disassembler output via a new styling argument.  A user can now
write:

  insn = arch.disassemble(address, styling = True)

The instruction strings returned within INSN will contain ANSI escape
sequences so long as 'set style enabled on' is in effect.  This means
that the user's personal settings (disabling styling) will override a
GDB extension that requests styled disassembler output.  I think this
makes sense.

The default for the styling argument is False, this maintains the
current unstyled output as default.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>

m32r_hi16_list

This patch moves m32r_hi16_list to an m32r extension of elf_section_data.

* elf32-m32r.c (m32r_hi16_list): Delete.
(struct _m32r_elf_section_data): New.
(m32r_elf_section_data): Define.
(m32r_elf_new_section_hook, m32r_elf_free_hi16_list),
(m32r_elf_free_cached_info): New functions.
(m32r_elf_hi16_reloc, m32r_elf_lo16_reloc): Use new sdata.
(bfd_elf32_new_section_hook): Define.
(bfd_elf32_bfd_free_cached_info): Define.

Automatic date update in version.in

[gdb/tdep] Eliminate ostringstream use from arc_check_tdesc_feature

We generally avoid C++ streams in GDB sources [1].

Remove an instance of std::ostringstream in arc_check_tdesc_feature.

While we're at it, fix an array index bug:
...
- reg_names << " or '" << reg.names[0] << "'";
+ string_appendf (reg_names, " or '%s'", reg.names[i]);
...

Tested on x86_64-linux, using a trigger patch:
...
-      if (!found && reg.required_p)
+      if (true || (!found && reg.required_p))
...
and doing "maint selftest" and observing the output:
...
Running selftest unpack_field_as_long::ARC600.
Error: Cannot find required register(s) 'r0' in feature 'org.gnu.gdb.arc.core'.
Error: Cannot find required register(s) 'pc' in feature 'org.gnu.gdb.arc.aux'.
...

Approved-By: Simon Marchi <simon.marchi@efficios.com>
[1] https://sourceware.org/pipermail/gdb-patches/2026-March/226117.html

null dereference in csky opcodes support

section->relocation will remain NULL on an error reading the relocs.

* csky-dis.c (is_extern_symbol): Delete section flag check.
Instead check that section->relocation is non-NULL.  Make addr
param a bfd_vma.

Automatic date update in version.in

Automatic date update in version.in

Add lock_guard to thread_pool::thread_count

I think there's a possible race when calling thread_pool::thread_count
from a worker thread, if the main thread changes the number of threads
at the same time.

When this code was initially written, we didn't worry about this,
because this was only accessed from the main thread.  This is no
longer the case, though.

This patch fixes any potential problem by adding a lock_guard to the
method.  This doesn't seem too harmful because this is not called very
much and because I doubt this lock is highly contended.

While doing this I noticed that thread_pool::do_post_task could access
m_sized_at_least_once and m_thread_count without holding the lock.
This patch changes this method as well.

Approved-by: Kevin Buettner <kevinb@redhat.com>

Remove 'fd' argument from exec_file_find

All callers of exec_file_find pass nullptr as the 'fd' argument, so
this can be removed.

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

gdb: fix edge case assertion from get_selected_frame

A cut down version of get_selected_frame looks like this:

  get_selected_frame (const char *message)
  {
    if (selected_frame == NULL)
      lookup_selected_frame (selected_frame_id, selected_frame_level);

    gdb_assert (selected_frame != NULL);
    return selected_frame;
  }

What this tells us is that lookup_selected_frame MUST ensure that
selected_frame is not NULL before it returns.  I ran into a case where
this guarantee is broken, lookup_selected_frame can leave selected_frame
as NULL, and the assertion in get_selected_frame triggers.

I started looking at this code while reviewing the debuginfod patches that
can be found here:

  https://inbox.sourceware.org/gdb-patches/20250124152858.2085187-3-amerey@redhat.com

This patch changes get_selected_frame to be:

  get_selected_frame (const char *message)
  {
    if (selected_frame == NULL)
      {
        lookup_selected_frame (selected_frame_id, selected_frame_level);
if (selected_frame == NULL)
          lookup_selected_frame (selected_frame_id, selected_frame_level);
      }

    gdb_assert (selected_frame != NULL);
    return selected_frame;
  }

[ NOTE: The patch isn't exactly like that, but that's basically the idea,
    I've just simplified things here as the details are not important. ]

The problem that was encountered with the debuginfod patches is that, with
the changes in that series, it becomes more likely that
lookup_selected_frame can fail to set selected_frame, but, due to details
specific to that patch, the failure can only happen the first time
lookup_selected_frame is called.

It occurred to me during review, that, if I could find a way to replicate
that problem outside the specifics of debuginfod, then I could submit that
part of the patch separately, and this would reduce the size of the
debuginfod patch set, and make that patch easier to review.

So I looked for other ways that I could cause lookup_selected_frame to
fail.

In the end I wasn't able to truly reproduce the same issue that the
debuginfod patch has, which means I cannot post the above fix here.  But I
did find some bugs that I then fixed, and I though it would be worth
posting them anyway.

I'm aware that I'm really getting into some nasty edge cases here, doing
things that most users will never do, so these fixes are unlikely to ever
be of real value, but they aren't huge, and I figure it doesn't hurt to
cover these edge cases.

So, with that all said, what's the problem?  The selected frame is stored
as a frame level and frame-id.  The job of lookup_selected_frame is to
lookup the actual frame_info_ptr and call select_frame to set the global
selected_frame variable.

If the frame described by the level and frame-id cannot be found then
lookup_selected_frame should (if level > 0) give a warning and select the
innermost frame.  We don't give a warning if the frame we're trying to
select is #0 as the default action, selecting frame #0 is close enough,
even if it's a different frame #0 than the one we're expecting.

This fall back case, and the associated warning is not currently tested,
so this patch adds a test that triggers this case.  To do this we setup a
call stack, select a frame other than #0, then within a 'thread apply',
pop frames from the stack using 'return'.  When the 'thread apply'
completes GDB tries to restore the previously selected frame, but that
frame has now been popped from the stack and no longer exists.  GDB will
print the warning and select frame #0 instead.

This tests the warning, but still isn't enough to trigger the assertion.
To do that we have to go a little further.  The fall back code in
lookup_selected_frame looks like this (I've simplified this a little):

  /* Select the innermost stack frame.  */
  select_frame (get_current_frame ());

  /* Warn the user.  */
  if (frame_level > 0)
    {
      warning (_("Couldn't restore frame #%d in "
                 "current thread.  Bottom (innermost) frame selected:"),
               frame_level);

      print_stack_frame (get_selected_frame (NULL), 1, SRC_AND_LOC, 1);
    }
  }

It is the select_frame call which sets the selected_frame global.  If we
can find a way to set the back to NULL after the select_frame call then we
will trigger the assertion.

We already have a mechanism for setting selected_frame to NULL from Python
code, the gdb.invalidate_cached_frames function.  So the only remaining
question is, can we invoke a Python callback after the select_frame call?

And yes, we can.  Printing a frame will trigger the pretty printers.  Now,
in real code there's no reason at all that a pretty printer should ever
need to call gdb.invalidate_cached_frames, or call anything that needs to
then call gdb.invalidate_cached_frames, which is why I started off by
saying that this really is an edge case.  But, for a moment, lets just run
with it.

So we setup a pretty printer which invalidates the frame cache, setting
selected_frame back to NULL.  We ensure this is run when GDB prints the
fall back frame, and now we leave lookup_selected_frame with
selected_frame set to NULL, and the assertion triggers.

The fix is really easy.  Move the select_frame call after the
print_stack_frame call (outside the 'if' block).  The print_stack_frame
call needs to be updated to print the current frame rather than the
selected frame, as the current frame is no longer selected at the point we
are printing the frame now.

With this done the assertion is fixed.  There is just one theoretical bug
that I haven't tried to fix; if the pretty printer changed the machine
state then it is possible that the current frame that's selected is not
the current frame that was printed.  This could be confusing, but not I
think fatal.  Trying to fix this felt like taking things too far, so I've
left this for now.

While I was here I changed the wording of the warning message.  The old
warning included the words "Bottom (innermost) frame selected", but our
manual doesn't really use the word "bottom" to describe the innermost
frame, we just say innermost.  So I updated the text to say "Innermost
frame selected".  Given we then print the stack frame, which includes the
"#0" tag, I think this is all perfectly clear, and lines up with the
wording in our documentation.

Having written all of the above I realised I could extend the test to
cover an additional, but related case.  Using the same setup, I run
the inferior to a point where the stack has 5 frames in it.  I select
frame #2 just as before, but now, instead of popping all frames
including frame #2, I just pop frames #0 and #1.  The logic in
lookup_selected_frame first tries to find the frame at the expected
level, in this case #2.  But after popping the frames, the frame at
level 2 will not be the expected frame.  But lookup_selected_frame
already handles this, and if the find frame by level logic fails, we
instead search for the frame by frame-id.  And this is what allows
this additional test to pass, the previous frame #2 has now become
frame #0, and this frame is selected as expected.

Approved-By: Kevin Buettner <kevinb@redhat.com>

aarch64: add aarch64-phoenix target

Adds aarch64-phoenix target from downstream Phoenix-RTOS patches.

Co-authored-by: Hubert Badocha <hubert.badocha@phoenix-rtos.com>
Signed-off-by: Michal Lach <michal.lach@phoenix-rtos.com>

sparc: add sparc-phoenix target

Adds sparc-phoenix target from downstream Phoenix-RTOS patches.

Co-authored-by: Hubert Badocha <hubert.badocha@phoenix-rtos.com>
Signed-off-by: Michal Lach <michal.lach@phoenix-rtos.com>

i386: add i386-phoenix target

Adds i386-phoenix target from downstream Phoenix-RTOS patches.

Co-authored-by: Hubert Badocha <hubert.badocha@phoenix-rtos.com>
Signed-off-by: Michal Lach <michal.lach@phoenix-rtos.com>

ld: use armelf_phoenix emul for arm-*-phoenix targets

armelf_phoenix emulation includes redundant definitions which were
previously in defined armelf.

Additionally, armelf_phoenix was unused before this commit in upstream
binutils, and we've been using it for some time already downstream.

Co-authored-by: Hubert Badocha <hubert.badocha@phoenix-rtos.com>
Signed-off-by: Michal Lach <michal.lach@phoenix-rtos.com>

Adjust pdata function table entries sorting for AArch64

The .pdata section contains an array of function table entries that
are used for exception handling. The entries should be sorted by
begin address, which is usually the first 4 bytes RVA in the entry.
Entry sizes are different for x64 and AArch64.
This difference is addressed in this patch.

This is the first patch in the patch series implementing
Structured Exception Handling (SEH) for aarch64-w64-mingw32.

Co-authored-by: Zac Walker <zacwalker@microsoft.com>
Co-authored-by: Ron Riddle <ron.riddle@microsoft.com>
Signed-off-by: Evgeny Karpov <evgeny@kmaps.co>
bfd/

* peXXigen.c (sort_x64_pdata): Rename from this ...
(sort_pdata): ... to this.
(defined): Use function_table_entry_size.

bfd: fold kvx-*-linux* entry

It's identical to the more generic kvx-*-*. Similarly its entry in the
${targ_cpu} case statement is redundant with the "*" one at the bottom.

bfd/x86: minor re-work of Solaris targ*_selvec

targ64_selvec is useful as a separate enumeration from targ_selvec only
when want64 isn't set to true.

x86: drop iamcu as default secondary target

It's not clear why this would have been forced onto about everyone
x86-ish. People wanting this as secondary target can specify it via the
--enable-targets= configure option.

Obviously a few tests cannot be run then anymore by default, but only when
IAMCU is actually the/a configured target.

While there also consolidate bfd/config.bfd entries doing identical
selections.

bfd: re-order main case command's entries in config.bfd

They once were meant to be at least roughly alphabetically sorted, at
least as far as the first component of the triplet goes.

gdb/riscv: use register number for 'info reg' output format choice

On RISC-V the 'info register' format for floating point registers
includes the raw register value printed as hex.  While reviewing an
upstream patch[1] I realised that this raw hex output was no longer
working, but no tests had started to fail.

Here's an example of the expected output:

  (gdb) info registers $ft0
  ft0            {float = 0, double = 0}  (raw 0x0000000000000000)

It's the '(raw 0x0000000000000000)' part that was missing once I had
applied series[1].

This commit does a few things.  First, I've extended an existing test
to check that the raw register value is printed.  I've updated the
same test to use to '-wrap' option to gdb_test_multiple.  And in
addition, in the case where the register type is a union (as in the
above example), I've relaxed the test so we no longer assume that the
field named 'float' is the first field of the union, a similar change
was part of the upstream series I was reviewing[2], so I figured I
might as well throw this in here.

The reason that patch series[1] broke the raw output, is that in
riscv_print_one_register_info, in order to identify a floating point
register, we currently inspect the register's type.  If the register
is of type float, or is a 2 or 3 element union, where each element is
a float, then we consider the register a floating point register, and
print it with the additional raw format.

In this commit I've switched to just checking the register number.  If
we're in the FP register range then we handle this as a floating point
register.

The code being changed here was introduced in commit:

  commit 270b9329b713fdc166f95dfa3a0a2f72f3a49608
  Date:   Mon Oct 22 14:10:13 2018 -0700

       RISC-V: Print FP regs as union of float types.

The commit message seems to indicate that this code was only ever
intended to identify the standard floating point registers, and I'm
not aware of any other RISC-V registers that would need printing with
the additional raw format, so I think the register number check should
be fine.

As such, there should be no user visible changes after this commit.

[1] https://inbox.sourceware.org/gdb-patches/20251105085121.1019759-1-jerry.zhangjian@sifive.com
[2] https://inbox.sourceware.org/gdb-patches/20251105085121.1019759-5-jerry.zhangjian@sifive.com

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

[gdb/testsuite, Tcl 9.0] Avoid non-UTF-8 GDB IO (part 2)

With Tcl 9.0 and test-cases gdb.ada/non-ascii-latin-{1,3}.exp we run into
similar problems as reported in the previous patch.

Work around this by avoiding non-UTF-8 chars in:
- gdb input by using a command file, and
- gdb output by not printing a source line containing such chars

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948

[gdb/testsuite, Tcl 9.0] Avoid non-UTF-8 GDB IO (part 1)

When running test-case gdb.python/py-source-styling.exp with Tcl 9.0, I get:
...
python gdb.execute('list 26')^M
<SNIP>/* The following line contains a character that is non-utf-8.  This is a
<SNIP>   critical part of the test as Python 3 can't convert this into a string
<SNIIP>  using its default mechanism.  */
<SNIP>FAIL: $exp: test_source_cache_style_tracking: \
  python gdb.execute('list 26') (timeout)
ERROR: i_read(spawn_id fd=9): invalid or incomplete multibyte or wide character
    while executing
"expect {
-i exp9 -timeout 10
        -re ".*A problem internal to GDB has been detected" {
            fail "$message (GDB internal error)"
            gdb_internal_error..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $body" POSIX EILSEQ {invalid or incomplete multibyte or wide \
  character} i_read(spawn_id fd=9)
: invalid or incomplete multibyte or wide character
Couldn't send python gdb.execute('list 26', to_string=False, styling=True) to GDB.
...

I have tried a fix similar to the previous commit in default_gdb_spawn:
...
+    if {[tcl_version_at_least 9 0 0]} {
+ set fd [exp_open -leaveopen -i $res]
+ fconfigure $fd -encoding utf-8 -profile replace
+    }
+
...
but that doesn't seem to work.

Work around this by skipping the part that runs into this problem.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948

[gdb/testsuite, Tcl 9.0] Fix error: invalid or incomplete multibyte or wide character

With Tcl 9.0 and test-case gdb.python/py-source-styling.exp, I run into:
...
ERROR: tcl error sourcing gdb.python/py-source-styling.exp.
ERROR: tcl error code POSIX EILSEQ {invalid or incomplete multibyte or wide character}
ERROR: error reading "file8": invalid or incomplete multibyte or wide character
    while executing
"read $fh"
    (procedure "auto_lappend_include_files_1" line 14)
...

Fix this by using "fconfigure $fh -encoding utf-8 -profile replace" [1] in
auto_lappend_include_files_1.  Likewise in gdb_get_line_number.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948

[1] https://core.tcl-lang.org/tcl/wiki?name=Migrating+scripts+to+Tcl+9

[gdb/testsuite, Tcl 9.0] Fix uninitialized string in gdb.fortran/function-calls.f90

With Tcl 9.0 and test-case gdb.fortran/function-calls.f90 I run into:
...
(gdb) run ^M
Starting program: function-calls ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
             (2.09999990,3.29999995)^M
           4           5^M
          23^M
             (2.09999990,3.29999995)^M
   3.40000010    ^M
           6^M
 ^K^@^@^@^@^@^@^@ERROR: i_read(spawn_id fd=9): invalid or incomplete multibyte or wide character
...

The problem seems to be the printing of an uninitialized string.

Fix this by initializing the string.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948

[gdb/testsuite, Tcl 9.0] Fix clipping by format %x

With test-case gdb.fortran/logical.exp and Tcl 9.0, I ran into:
...
(gdb) set *((character *) 0x7fffffffd8ec) = 0xff^M
(gdb) PASS: $exp: var=l: byte 0: set contents of byte at offset 0
p l^M
$8 = .TRUE.^M
(gdb) PASS: gdb.fortran/logical.exp: var=l: byte 0: p l
set *((character *) 0xffffd8ed) = 0xff^M
Cannot access memory at address 0xffffd8ed^M
(gdb) FAIL: $exp: var=l: byte 1: set contents of byte at offset 1
...

So there are two writes:
- for the first write at offset 0, we use address:  0x7fffffffd8ec
- for the second write at offset 1, we use address:     0xffffd8ed.

The address got clipped by using %x with command format:
...
    incr addr
    set addr [format "0x%x" $addr]
...

Fix this by using "%lx" instead.

Likewise in two other test-cases.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948

[gdb/testsuite, Tcl 9.0] Fix error: invalid character in array index

With test-case gdb.cp/inherit.exp and Tcl 9.0, I run into:
...
ERROR: tcl error sourcing gdb.cp/inherit.exp.
ERROR: tcl error code NONE
ERROR: invalid character in array index
    while executing
"set in_class_table $cp_class_table_history("
    invoked from within
"if {$in_class_table == "ibid"} {
if {![info exists cp_class_table_history("$in_key,$in_tag")]} {
...

Fix this by dropping the double quotes in
'cp_class_table_history("$in_key,$in_tag")'.

Likewise in gdb.cp/ovldbreak.exp.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948

[gdb/testsuite, Tcl 9.0] Namespace fixes

A few test-cases wrap code in namespaces.

Since Tcl 9.0, globals are no longer directly available inside namespaces.

Fix this by redeclaring using upvar.

Also, referring to variables in namespaces needs to be done using fully
qualified names.  Fix this by adding a :: prefix.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948

[gdb/testsuite, Tcl 9.0] Fix error: no such variable: Dwarf::_line_unit_version

With test-case gdb.base/until-trailing-insns.exp and Tcl 9.0, I run into:
...
ERROR: tcl error sourcing gdb.base/until-trailing-insns.exp.
ERROR: tcl error code TCL LOOKUP VARNAME Dwarf::_line_unit_version
ERROR: can't read "Dwarf::_line_unit_version": no such variable
    while executing
"if { $Dwarf::_line_unit_version >= 5 } {
                return [expr {[llength $_line_include_dirs] - 1}]
            } else {
                return [llength $_line_include_dirs]
           ..."
    (procedure "include_dir" line 5)
...

Fix this by dropping the Dwarf prefix.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948

[gdb/testsuite, Tcl 9.0] Fix error: no such variable: Term::_TERM

With test-case gdb.base/color-prompt.exp and Tcl 9.0, I run into:
...
Running gdb.base/color-prompt.exp ...
ERROR: tcl error sourcing gdb.base/color-prompt.exp.
ERROR: tcl error code TCL LOOKUP VARNAME Term::_TERM
ERROR: can't read "Term::_TERM": no such variable
    while executing
"if { $Term::_TERM != "" } {
    setenv TERM $Term::_TERM
} elseif { [ishost *-*-*bsd*] } {
    setenv TERM ansiw
} else {
    setenv TERM ansi
}"
...

Fix this by dropping the Term prefix in Term::with_tuiterm.

Likewise in Term::with_term and Term::_have_bw, fixing gdb.tui/tui-mode-switch.exp.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948

[gdb/testsuite, Tcl 9.0] Fix Tcl version check

With Tcl 9.0, we get:
...
ERROR: tcl error sourcing tool init file lib/gdb.exp.
version conflict for package "Tcl": have 9.0.2, need 8.6.2
version conflict for package "Tcl": have 9.0.2, need 8.6.2
    while executing
"package require Tcl 8.6.2"
    (file "lib/gdb.exp" line 20)
...

Fix this by using tcl_version_at_least.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948

[gdb/testsuite, Tcl 9.0] Fix use of deprecated trace variable subcommand

With Tcl 9.0, we get:
...
bad option "variable": must be add, info, or remove
    while executing
"trace variable "boards_dir" w append_gdb_boards_dir"
    (file "lib/append_gdb_boards_dir.exp" line 48)
...

The trace subcommand "trace variable <name> <ops> <command>" [1]:
- is equivalent to "trace add variable <name> <ops> <command>"
- is for backwards compatibility,
- uses "an older syntax in which array, read, write, unset are replaced by a,
  r, w and u respectively",
- has an ops argument which is "not a list, but simply a string concatenation
  of the operations", and
- is "deprecated and will likely be removed in a future version of Tcl".

Fix this by using "trace add variable":
...
-trace variable "boards_dir" w append_gdb_boards_dir
+trace add variable "boards_dir" {write} append_gdb_boards_dir
...

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33948

[1] https://www.tcl-lang.org/man/tcl8.6/TclCmd/trace.htm#M27

[gdb/testsuite] Clean up globals saving in gdb.tui/tuiterm.exp

In test-case gdb.tui/tuiterm.exp, I came across this proc:
...
proc setup_terminal { cols rows } {
    setenv TERM ansi
    Term::_setup $rows $cols
}
...
and I wondered why we're not using save_vars ::env(TERM) in here.

Then I found out that this happens via run_one_test_small, which calls
setup_small, which calls setup_terminal:
...
proc setup_small {} {
    setup_terminal 8 4
    ...
}
  ...
proc run_one_test_small { test_proc_name } {
    save_vars { env(TERM) stty_init } {
setup_small
$test_proc_name
    }
}
...

There are a couple of problems here:
- the proc test_attrs calls setup_terminal, but doesn't do any
  saving/restoring
- the saving/restoring in run_one_test_small doesn't work, because the
  variable names don't have global scope
- both env(TERM) and stty_init aren't actually used in the test.

Fix this by:
- dropping the setting of env(TERM)
- moving the saving/restoring of stty_init to setup_terminal

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

[gdb/testsuite] Fix Term::_TERM setting leak in Term::with_tuiterm

Add a test for proc Term::with_tuiterm in gdb.tui/tuiterm.exp, and fix that a
local Term::_TERM setting leaks out of the proc.

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

[gdb/testsuite] Add test for Term::with_term

Add a test for proc Term::with_term in gdb.tui/tuiterm.exp

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

Automatic date update in version.in

[gdb/tdep] Fix unrelocated pc in i386_displaced_step_fixup

With test-case gdb.threads/next-fork-other-thread.exp and target board
unix/-m32 I run into:
...
(gdb) next
[Switching to Thread 0xf643ab40 (LWP 3267939)]

Thread 5 "next-fork-other" hit Breakpoint 1, main () at \
  next-fork-other-thread.c:73
73        alarm (60);
(gdb) FAIL: $exp: fork_func=fork: target-non-stop=off: non-stop=off: \
  displaced-stepping=on: i=$n: next to break here
...

Before we go into how this happens, let's first look at the inferior.

In main, 4 threads are started with the same thread function, leaving all 5
threads in a loop:
- the main thread is stuck in a loop calling sleep, and gdb steps through this
  loop using next
- the other, non-main threads are stuck in a loop where each thread:
  - forks off a child process that exits immediately
  - waits for the child process to exit
  - calls sleep

The FAIL happens as follows (following snippets from this gdb.log [1]).

One of the non-main threads enters __syscall_cancel_arch to do a sycall (
either to sleep, or to wait).

Then the non-main thread stops:
...
  [infrun] handle_signal_stop: [2937316.2937324.0] hit another thread's \
    single-step breakpoint
  [infrun] handle_signal_stop: delayed software breakpoint trap, ignoring
  [infrun] switch_back_to_stepped_thread: need to step [2937316.2937324.0] \
    over single-step breakpoint
...
because we "hit another thread's single-step breakpoint".

AFAIU, this is because of the main thread stepping through
__syscall_cancel_arch.

To handle this, we're going to try displaced stepping.

The syscall instruction is copied:
...
  [displaced] displaced_step_prepare_throw: original insn 0xf7cdce69: \
    cd 80      int    $0x80
  [displaced] prepare: selected buffer at 0x80490d2
...
to a buffer at _start+2:
...
080490d0 <_start>:
 80490d0:       31 ed                   xor    %ebp,%ebp
 80490d2:       5e                      pop    %esi
...
and we're going to resume execution there.

However, right after resuming we get a GDB_SIGNAL_CHLD for the same thread.

Part of handling that is finalizing the displaced stepping:
...
  [displaced] finish: restored 2937316.2937324.0 0x80490d2
  [displaced] i386_displaced_step_fixup: fixup (0xf7cdce69, 0x80490d2), \
    insn = 0xcd 0x80 ...
  [displaced] i386_displaced_step_fixup: syscall changed %eip; not relocating
  [infrun] handle_signal_stop: stop_pc=0x80490d2
...

The stop pc is 0x80490d2, the address of the copied instruction.  In other
words, we've stopped without making progress.

The problem is that the address is in the displaced stepping buffer, and needs
relocating, but instead we have "syscall changed %eip; not relocating".

The code in i386_displaced_step_fixup doesn't recognize this situation:
...
      if (i386_syscall_p (insn, &insn_len)
  && pc != to + (insn - insn_start) + insn_len
  /* GDB can get control back after the insn after the syscall.
     Presumably this is a kernel bug.
     i386_displaced_step_copy_insn ensures it's a nop,
     we add one to the length for it.  */
  && pc != to + (insn - insn_start) + insn_len + 1)
  displaced_debug_printf ("syscall changed %%eip; not relocating");
...

It only handles the cases where the stop pc is:
- the address after the syscall insn, or
- the address after the nop after the syscall insn

So, instead of relocating the stop pc back to the original 0xf7cdce69, it
stays 0x80490d2.  After resuming at that address, the thread:
- executes the syscall,
- executes the rest of _start,
- enters main, and
- runs into the breakpoint at the start of main.

Since commit cf141dd8ccd ("gdb: fix reg corruption from displaced stepping on
amd64"), we do handle the "pc == to" case in amd64_displaced_step_fixup:
...
       if (amd64_syscall_p (insn_details, &insn_len)
    /* GDB can get control back after the insn after the syscall.
     Presumably this is a kernel bug.  Fixup ensures its a nop, we
     add one to the length for it.  */
  && (pc < to || pc > (to + insn_len + 1)))
  displaced_debug_printf ("syscall changed %%rip; not relocating");
...

Fix this in the same way.

Tested on x86_64-linux, with target board unix/-m32.

On openSUSE Tumbleweed (kernel version 6.19.7), this patch fixes the test-case.

On openSUSE Leap 16.0 (kernel version 6.12.0), we still run into PR29040.

Approved-By: Andrew Burgess <aburgess@redhat.com>
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33997

[1] https://sourceware.org/bugzilla/attachment.cgi?id=16660

gdb: change new_objfile observer to take an objfile reference

I was looking at the new_objfile observer and noticed a comment in
reread_symbols (symfile.c) that seemed out of date, it talked about
calling the new objfile observer with a NULL objfile argument.

A little digging indicates that the comment is indeed out of date, and
that we never call the new_objfile observer with a NULL argument any
more.

So in this commit I have:

  1. Updated the out of date comment in reread_symbols.

  2. Changed the argument type for the new_objfile observer from
     'objfile *' to 'objfile &'.  Passing a NULL pointer is no longer
     an option.

  3. Updated the existing new_objfile observers to take 'objfile &'
     and updated their implementations as needed.

There should be no user visible changes after this commit.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb: make find_memory_region_ftype a function_view

Make it a function_view and remove the `void *` parameter.  Convert the
callers (in gcore.c) to use lambda functions that capture `obfd`.

The target_debug_print_find_memory_region_ftype debug printer isn't
terribly useful, but I don't see a good way to print a function_view
with what we have right now.

Since find_memory_region_ftype needs to be seen by both gdbarch.h and
target.h, I chose to move the typedef to a new file
(find-memory-region.h), that is included by both.

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

Re: ld/ELF: Fix small issue with orphan sections and NOLOAD output section

Correct the testcase.

* orphan-13.d: Don't xfail anything.

[gdb/testsuite] Handle too many watchpoints in gdb.base/watchpoint-adjacent.exp

On i686-linux, with test-case gdb.base/watchpoint-adjacent.exp I run into:
...
(gdb) watch obj.b^M
Hardware watchpoint 5: obj.b^M
Warning:^M
Could not insert hardware watchpoint 5.^M
Could not insert hardware breakpoints:^M
You may have requested too many hardware breakpoints/watchpoints.^M
^M
(gdb) FAIL: $exp: var_type=type_ll: test= a {a b} : rwatch_first=true: \
  watch obj.b
...

The CPU supports 4 hardware watchpoints of 4 bytes, and the test-case attempts
to set 3 hardware watchpoints of 8 bytes.

Fix this by making the test unsupported.

Tested on i686-linux and x86_64-linux.

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

[gdb/tui] Always check for tui_try_activate result

There are two functions in which we call tui_try_activate, but don't check for
the result.

If it's not a bug, then it's an inconsistency.

Fix this in both functions.

Tested on x86_64-linux.

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

[gdb/tui] Add tui_try_activate

In tui/tui.c, there this type of pattern related to activating TUI:
...
static int
tui_rl_delete_other_windows (int notused1, int notused2)
{
  if (!tui_active)
    tui_rl_switch_mode ();

  if (tui_active)
    tui_remove_some_windows ();

  return 0;
}
...

Add a new function tui_try_activate that allows us to write the shorter:
...
static int
tui_rl_delete_other_windows (int notused1, int notused2)
{
  if (tui_try_activate ())
    tui_remove_some_windows ();

  return 0;
}
...

Tested on x86_64-linux.

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

[gdb/tui] Add default arguments to tui_rl_switch_mode

Add default arguments for tui_rl_switch_mode, to allow:
...
-tui_rl_switch_mode (0 /* notused */, 0 /* notused */);
+tui_rl_switch_mode ();
...

Tested on x86_64-linux.

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

[gdb/tui] Remove unnecessary nullptr check in tui_rl_other_window

In tui_rl_other_window, we check for win_info != nullptr:
...
  win_info = tui_next_win (tui_win_with_focus ());
  if (win_info)
    tui_set_win_focus_to (win_info);
...
but that's also done in tui_set_win_focus_to, so drop it here.

Tested on x86_64-linux.

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

xtensa: properly check reloc address

The existing check didn't take the reloc size into account.

* elf32-xtensa.c (bfd_elf_xtensa_reloc): Use bfd_reloc_offset_in_range.

mips64*-linux-gnuabi64 ld tests

I noticed recently that my mips64-linux-gnuabi64 binutils build was
not doing compiled ld tests due to check_compiler_available returning
false, despite having a cross-compiler installed.  My compiler fails
to build the test executable when both -mabi=n32 and -L options with
the lib64 dir first are passed, complaining
ld-new: .../lib64/libgcc_s.so.1: error adding symbols: file in wrong format

The -mabi=n32 comes from config/default.exp, the -L options from
genscripts.sh via libpath.exp.  The -mabi=n32 is wrong because
contrary to the comment in default.exp, the abi64 compiler does not
default to N32.  And the -L options interfere with the correct -L
passed by the compiler for -mabi=n32.

* testsuite/config/default.exp (mips64*-*-linux*): Do not
supply -mabi=n32 for abi64 configuration.

Automatic date update in version.in

ld/ELF: Fix small issue with orphan sections and NOLOAD output section

What happens is that the effect of the command:

  .foo (NOLOAD) : {}

is not equivalent to that of:

  .foo (NOLOAD) : { *(.foo) }

when there is more than 1 object file containing a .foo section: the former
will output two .foo sections, the first with PROGBITS and the second with
NOBITS, where the latter will output only one with NOBITS.

Given that the commands are essentially equivalent, the linker ought to
yield the same outcome, namely the single output section with NOBITS.

Automatic date update in version.in

infcall: Add support for integer literals as reference function parameters

This patch attempts to mitigate the shortcomings of passing literals
to inferior function calls requiring references.  The specific use case here
is std::map's operator[]:

std::map int_map<int, int>;
int_map[1] = 10;
(gdb) print int_map[1]
Attempt to take address of value not located in memory.

This is occurring because while value_coerce_to_target understands
that some values need to be allocated and copied to the inferior's
memory, it only considers the actual parsed type of the argument value,
ignoring the actual type of the function parameter. That is,
in this specific case, the value's parsed type is TYPE_CODE_INT, but
the function requires TYPE_CODE_REF. We need to account for the
reference.

In value_arg_coerce, we have special handling for references, but it
has not specifically dealt with this case. It now checks if the
reference is in memory, and if it isn't, it copies it, if the type
is trivially copyable.

As a result of this patch, the last remaining failure in c++/15372 is now
fixed, and that bug can be closed.

With this patch, we can now print map entries with integer keys:

(gdb) print int_map[1]
$1 = (std::map<int, int, std::less<int>, std::allocator<std::pair<int const, int> > >::mapped_type &) @0x41f2d4: 10

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

sim/sh: check PFSCR.PR setting for fldi0 and fldi1 insns

On SH variants with double-precision FPU the insns fli0 and flid1 are only
defined when FPSCR.PR = 0.  The hardware does not necessarily trap but might
quietly load undefined values.  However, qemu traps in that case, so do the
same.

GDB: aarch64-linux: Fix build failure on musl systems

When building against musl (e.g. on Alpine Linux), the following error
happens:

    CXX    linux-aarch64-low.o
  In file included from /home/bauermann/src/binutils-gdb/gdbserver/linux-aarch64-low.cc:48:
  /home/bauermann/src/binutils-gdb/gdbserver/../gdb/nat/aarch64-gcs-linux.h:36:8: error: redefinition of 'struct user_gcs'
     36 | struct user_gcs
        |        ^~~~~~~~
  In file included from /home/bauermann/src/binutils-gdb/gdbserver/linux-aarch64-low.cc:36:
  /usr/include/asm/ptrace.h:329:8: note: previous definition of 'struct user_gcs'
    329 | struct user_gcs {
        |        ^~~~~~~~
  make[2]: *** [Makefile:565: linux-aarch64-low.o] Error 1

aarch64-linux-tdep.c fails to build in the same way.  This happens because
aarch64-gcs-linux-ptrace.h uses GCS_MAGIC to see whether the system headers
have GCS-related definitions.  The problem is that GCS_MAGIC is defined in
<asm/sigcontext.h> while struct gcs_user is defined in <asm/ptrace.h>.
It's fine on glibc systems because in the set of system headers that
linux-aarch64-low.cc and aarch64-linux-tdep.c include, <asm/sigcontext.h>
ends up being included implicitly as well.  This doesn't happen when using
musl's headers though.

There isn't a macro in <asm/ptrace.h> whose presence is correlated with
the presence of the struct user_gcs definition, so a configure check is
needed to detect it and conditionally define the struct.

Note that there's another build issue with musl, described in
PR gdb/33747 affecting compilation of gdb/ser-unix.c.  In order to be
able to test this patch, I applied the patch in comment 11 there.

Tested with a native build on an Alpine Linux aarch64 system, and also
verified that all gdb.arch/aarch64-gcs*.exp tests pass on it.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33926
Co-authored-by: Chris Packham <judge.packham@gmail.com>
Approved-By: Luis Machado <luis.machado.foss@gmail.com>

GDB: aarch64-linux: Reorganize GCS-related definitions

Only native code should use struct user_gcs, so its definition should be
in a native-specific file and not in a file under gdb/arch/.

To fix this problem, create gdb/nat/aarch64-gcs-linux.h and move the
struct user_gcs definition to it, as suggested by Luis.

To fix the use of struct user_gcs in gdb/aarch64-linuxt-dep.c, define a
macro with the size of the GCS regset in gdb/arch/aarch64-gcs-linux.h
and use it in aarch64-linux-tdep.c, as is done for other regsets and
following a suggestion from Simon Marchi.

Also, move the HWCAP_GCS definition to gdb/nat/aarch64-gcs-linux.h and
create an AARCH64_HWCAP_GCS definition in gdb/arch/aarch64-gcs-linux.h
for use by target-dependent code.

Similarly, move the SEGV_CPERR and PR_SHADOW_STACK_{ENABLE,WRITE,PUSH}
definitions, which were added by the GCS patches and are only used by
aarch64-linux target-dependent code, to gdb/arch/aarch64-gcs-linux.h
with an AARCH64_ prefix and adjust users.

Finally, I noticed that gdb/aarch64-linux-nat.c and
gdbserver/linux-aarch64-low.cc don't need anything from the
arch/aarch64-gcs-linux.h header, so make them not include it.

Suggested-by: Luis <luis.machado.foss@gmail.com>
Suggested-by: Simon Marchi <simark@simark.ca>
Approved-By: Luis Machado <luis.machado.foss@gmail.com>

GDB: aarch64-linux: Reorganize SME-related definitions

The HWCAP2_SME, HWCAP2_SME2 and HWCAP2_SME2P1 definitions should be in a
file under gdb/nat/, so move them to aarch64-scalable-linux-ptrace.h.

Also, I noticed that gdb/aarch64-linux-nat.c and
gdbserver/linux-aarch64-low.cc don't need anything from the
arch/aarch64-scalable-linux.h header, so make them not include it.

Approved-By: Luis Machado <luis.machado.foss@gmail.com>

GDB: aarch64-linux: Reorganize MTE-related definitions

GDB conditionally defines HWCAP2_MTE in gdb/arch/aarch64-mte-linux.h, but
that's not the best place for it since it's a definition that should be
used only in native code so move it to gdb/nat/aarch64-mte-linux-ptrace.h.

Introduce an AARCH64_HWCAP2_MTE in gdb/arch/aarch64-mte-linux.h to be used
by target-dependant code.

Similarly, add AARCH64_ prefix to the SEGV_MTEAERR and SEGV_MTESERR
definitions in gdb/arch/aarch64-mte-linux.h.

I noticed that enum class aarch64_memtag_type is only used in native code,
so move its definition to gdb/nat/aarch64-mte-linux-ptrace.h as well.

I also noticed that gdb/aarch64-linux-tdep.h defines
AARCH64_LINUX_SIZEOF_MTE_REGSET which is redundant with
AARCH64_LINUX_SIZEOF_MTE, already defined in gdb/arch/aarch64-mte-linux.h
so consolidate both definitions.

Finally, the include of arch/aarch64-mte-linux.h isn't used in
gdb/aarch64-linux-nat.c nor in gdb/nat/aarch64-mte-linux-ptrace.c so
remove it from them.

Suggested-by: Luis <luis.machado.foss@gmail.com>
Suggested-by: Simon Marchi <simark@simark.ca>
Approved-By: Luis Machado <luis.machado.foss@gmail.com>

GDB: Add aarch64-fpmr-linux.h to gdb/arch/ and gdb/nat/

GDB conditionally defines HWCAP2_FPMR in gdb/arch/aarch64.h, but that's
not the best place for it since it's a Linux-specific definition.

Add new Linux- and feature-specific headers to contain it, one for
target-dependent code and the other for native code.

The target-dependant code should use AARCH64_HWCAP2_FPMR in
gdb/arch/aarch64-fpmr-linux.h while native code should use HWCAP2_FPMR,
which will hopefully be defined by the system headers but with a backup
definition in gdb/nat/aarch64-fpmr-linux.h if it isn't.

Suggested-by: Luis <luis.machado.foss@gmail.com>
Suggested-by: Simon Marchi <simark@simark.ca>
Approved-By: Luis Machado <luis.machado.foss@gmail.com>

GDB: Add aarch64-pauth-linux.h to gdb/arch/ and gdb/nat/

The code supporting Pointer Authentication duplicates the definition of
AARCH64_HWCAP_PACA and of AARCH64_LINUX_SIZEOF_PAUTH between GDB and
gdbserver, so add two new headers to host those definitions.

The target-dependant code should use AARCH64_HWCAP_PACA in
gdb/arch/aarch64-pauth-linux.h while native code should use HWCAP_PACA,
which will hopefully be defined by the system headers but with a backup
definition in gdb/nat/aarch64-pauth-linux.h if it isn't.

Suggested-by: Luis <luis.machado.foss@gmail.com>
Suggested-by: Simon Marchi <simark@simark.ca>
Approved-By: Luis Machado <luis.machado.foss@gmail.com>

PR 33995 compile failure on DEC Alpha OpenBSD 7.8

The args are only used inside #ifdef TLS.

PR 33995
* bfd.c (bfd_thread_init): Add ATTRIBUTE_UNUSED on args.

Automatic date update in version.in

gdb: remove TYPE_CHAIN

IMO, there is no point in keeping this macro.  Remove it and access the
field directly.  If we ever want some kind of abstraction in front of
the field, then we'll add a method.

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

gdb: remove TYPE_RVALUE_REFERENCE_TYPE

IMO, there is no point in keeping this macro.  Remove it and access the
field directly.  If we ever want some kind of abstraction in front of
the field, then we'll add a method.

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

gdb: remove TYPE_REFERENCE_TYPE

IMO, there is no point in keeping this macro.  Remove it and access the
field directly.  If we ever want some kind of abstraction in front of
the field, then we'll add a method.

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

gdb: remove TYPE_POINTER_TYPE

IMO, there is no point in keeping this macro.  Remove it and access the
field directly.  If we ever want some kind of abstraction in front of
the field, then we'll add a method.

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

gdb: remove TYPE_MAIN_TYPE

IMO, there is no point in keeping this macro.  Remove it and access the
field directly.  If we ever want some kind of abstraction in front of
the field, then we'll add a method.

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

gdb: remove INIT_NONE_SPECIFIC

This macro seems unnecessary.  It is only used right after allocating a
new type, and it only sets some fields to 0, which is the default state
of a struct type anyway.

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

gdb, gdbserver, gdbsupport: replace many uses of strcmp with streq

Replace all occurrences of:

  strcmp (...) == 0
  strcmp (...) != 0
  !strcmp (...)
  0 == strcmp (...)
  strcmp (...) directly used as a boolean predicate

with the equivalent expression using streq.

This is for consistency (we already use streq as some places in the
testsuite) but also for clarity.  I think that streq is clearer on the
intent than strcmp.  It's also a bit shorter.

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

gdb/dwarf: fix build error with older gcc

With gcc 7.5.0, we get:

      CXX    dwarf2/read.o
    /home/simark/src/binutils-gdb/gdb/dwarf2/read.c: In function ‘void decode_line_header_for_cu(die_info*, dwarf2_cu*, const file_and_directory&)’:
    /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:5796:25: error: unused variable ‘_’ [-Werror=unused-variable]
           auto [_, inserted_]
                             ^

That version of gcc (and earlier) apparently produces unused variable
warnings for unused structured bindings.  Fix it by accessing `.second`
directly to get the "inserted" boolean value.

Change-Id: I6e78c8c317623f3d830fef8d043f85ff789133d4
Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81767

Automatic date update in version.in

PR33919 Out-of-bounds read in XCOFF relocation processing

PR 33919
* coff-rs6000.c (xcoff_calculate_relocation): Don't use explicit
array size.
(xcoff_complain_overflow): Likewise.
(xcoff_rtype2howto): Return a NULL howto rather than aborting.
(_bfd_xcoff_reloc_name_lookup): Use ARRAY_SIZE.
(xcoff_ppc_relocate_section): Sanity check reloc r_type before
accessing xcoff_howto_table.  Print r_type using %#x.  Remove
now redundant later reloc r_type sanity check.
* coff64-rs6000.c: Similarly.
* libxcoff.h (XCOFF_MAX_CALCULATE_RELOCATION): Don't define.
(XCOFF_MAX_COMPLAIN_OVERFLOW): Don't define.

hppa64: Improve compatibility with HP ld on HP-UX

Provided symbols are revised to match those provided by HP ld.
This fixes startup issues caused by defining __FPU_MODEL,
__libdl_jmp_tbl and __systab.

This change adds the emultempl/hppa64elf.em file.  We now always
link against /lib/pa20_64/milli.a on HP-UX.

HP-UX shared libraries have some unresolved symbols.  So, we also
need to ignore unresolved symbols in shared libraries.

We adjust TEXT_START_ADDR and SHLIB_TEXT_START_ADDR to match the
values used by HP ld.

The .data section is moved to the start of the data segment.

2026-03-15  John David Anglin  <danglin@gcc.gnu.org>

ld/ChangeLog:

* emulparams/elf64hppa.sh (TEXT_START_ADDR): Revise value to match
HP ld value.
(SHLIB_TEXT_START_ADDR): Likewise.
(EXTRA_EM_FILE): Define.
(OTHER_SYMBOLS): Revise to match symbols provided by HP ld.
* emultempl/hppa64elf.em: New file.
* scripttempl/elf64hppa.sc: Move .data to start of segment.

gas: pru: Add flag to select core revision

Add new command line option to select PRU core revision to assemble for.
This new option is used to limit the available opcodes to what the
selected revision supports.

References:
  - https://www.ti.com/lit/ug/spruij2/spruij2.pdf
    Table 3. PRU Core Revision Comparison
  - https://github.com/TexasInstruments/open-pru/blob/3cffcaae73c708ce15337a9880ec91dc9b03aaa5/docs/PRU%20Assembly%20Instruction%20Cheat%20Sheet.md#core-revision-differences
    Core Revision Differences

Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>

gdb/linux-tdep: remove linux_get_siginfo_type_with_fields

It is unused since the removal of MPX, commit fc14343205d3 ("gdb,
gdbserver, python, testsuite: Remove MPX").

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

gdb/fbsd-tdep: use builtin integer types

Same as the previous patch, but for FreeBSD.

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

gdb/linux-tdep: use builtin integer types

I noticed some spots creating new integer types, where I think we could
use the builtin types created by create_gdbtypes_data instead.

The old code to initialize `short_type` was actually passing the wrong
bit length value, so I think this actually fixes a latent bug, although
it goes away in a subsequent patch.

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

hppa64: Improve HP-UX support and fix some relocation issues

With this patch, gcc-16 test results are now similar to those
using the HP ld.

The change fixes dynamic symbol handling.  At the moment, we
only have a single stub section and no support for long pc-relative
calls.  So, we only need to redirect pc-relative branches through
the PLT when the call is to a dynamic function.

The change to elf64_hppa_finalize_dynreloc() fixes C++ VTT support.
This fixed many tests in the gcc g++ and libstdc++ testsuites.

The next step is to add support for long pc-relative branches via
the PLT.

2026-03-14  John David Anglin  <danglin@gcc.gnu.org>

bfd/ChangeLog:

* elf64-hppa.c (elf64_hppa_check_relocs): Only set NEED_PLT
and NEED_STUB for symbols with function types.
(elf64_hppa_dynamic_symbol_p): Return false for millicode
symbols.
(allocate_global_data_dlt): Only allocate DLT entries for
symbols that are dynamic or defined.  Clear hh->want_dlt
if we don't want a DLT entry.
(allocate_global_data_plt): Only allocate PLT entries for
dynamic symbols.
(allocate_global_data_stub): Likewise, Only allocate stubs
for dynamic symbols.
(elf64_hppa_create_dynamic_sections): Fix flags for .dynamic
section and remove duplicated flags for other dynamic
sections.
(allocate_dynrel_entries): Fix DLT and PLT allocations.
(elf64_hppa_late_size_sections): Don't sort relocations.
Tweak code to set section used to set __text_seg.
(elf64_hppa_finish_dynamic_symbol): Use eh->dynindx instead
of hh->eh.dynindx.  Don't call elf64_hppa_dynamic_symbol_p
to determine whether PLT entries and stubs need initialization.
(elf64_hppa_finalize_dynreloc): Add rent->addend to value
calculation.
(elf_hppa_remark_useless_dynamic_symbols): Revise symbols
checked.
(elf_hppa_final_link_relocate): Revise code to redirect
pc-relative calls to stubs.
(elf_backend_want_p_paddr_set_to_zero): Define to 1 on HP-UX
target.

Automatic date update in version.in

gdb/linux-tdep: remove linux_collect_thread_registers_ftype typedef

It is unused.

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

gdb/linux-tdep: make linux_find_memory_region_ftype a function_view

Make it a function_view and eliminate the `void *` callback data.
Change the callback functions to lambda functions where they are used.

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

gdb/gcore: check return values of some find_memory_region_ftype calls

This fixes some spots that didn't check the return value of a
find_memory_region_ftype callback.

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

gdb/linux-tdep: check return value of linux_find_memory_region_ftype callback

I noticed that linux_find_memory_regions_full did not check the return
value of the linux_find_memory_region_ftype callback.  I think this is a
mistake.  When called from linux_find_memory_regions, the
find_memory_region_ftype callback could return false, in which case we
should stop iterating.

This probably didn't matter in practice, as these callbacks generally
don't return false (only in error cases that never happen).

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

gdb/dwarf: rename low_set variable in dwarf2_ranges_read

Rename low_set to low_high_set, to reflect what it really means.

Also, change some manual min/max so use std::min/std::max, I think it
makes the intent clearer.

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

gdb/dwarf: don't pass lowpc/highpc to dwarf2_ranges_read in cooked_indexer::scan_attributes

It's not necessary to pass pointers to those variables
(dwarf2_ranges_read checks then for nullptr), and they are not used.
Remove them.

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

gdb/python: add accessor helpers for __dict__ in Python extension objects

Python extension objects that support __dict__ must inherit from
gdbpy_dict_wrapper, a wrapper class that stores the PyObject
corresponding to the __dict__ attribute. Because this dictionary
is not managed directly by Python, each extension objects must
provide appropriate accessors so that attributes stored in __dict__
are looked up correctly.

Currently, management of this dictionary is not centralized, and
each Python extension object implements its own logic to create,
access, and destroy it.

A previous patch centralized the creation logic; this patch focuses
on centralizing the access to the dictionary. It introduces two new
macros:
- gdbpy_dict_wrapper_cfg_dict_getter, which defines a getter for
  __dict__.
- gdbpy_dict_wrapper_getsetattro, which sets tp_getattro and
  tp_setattro in PyTypeObject to gdb_py_generic_getattro and
  gdb_py_generic_setattro, respectively. These helpers already
  centralizes attribute access for Python extension objects having
  a __dict__.
  Note: this macro will eventually be removed once Python extension
  types are migrated to heap-allocated types.

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

Automatic date update in version.in

Remove type::stub_is_supported

I noticed type::stub_is_supported the other day.  It is only set in a
single spot in the DWARF reader.  And looking at this, the logic seems
backward or confused to me.

type::is_opaque ends with this:

  return this->is_stub () || !this->stub_is_supported ();

That is, a type is opaque if a bunch of conditions are met (earlier in
the method), and then either the type is marked as a stub, or else the
type does not have the stub_is_supported flag set.

However the DWARF reader essentially does this:

  if (something)
    type->set_is_stub (true);
  else
    type->set_stub_is_supported (true);

That is, either one flag or the other is going to be true along this
path.

So maybe this was a workaround for some other reader that doesn't set
the flag.  Luckily, most of the other readers were removed.  Checking
the CTF reader, it seems to correctly set the stub flag for incomplete
types.

So, I think the stub_is_supported machinery can simply be removed now.

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

Use dwarf-to-dwarf-assembler.py on dw2-icc-opaque

I ran dwarf-to-dwarf-assembler.py on the output of the dw2-icc-opaque
test.  The test was already architecture-independent, but I think it's
a bit easier to read this way.

I made a couple of tiny edits to the output, that I don't think affect
the test:

* I slightly shortened the producer strings (removing the newline and
  subsequent text)
* I changed a DW_AT_data_member_location to be a constant rather than
  an expression

Print overload debug messages to gdb_stdlog

I noticed that overload debugging messages go to gdb_stderr.  I think
the usual convention is that debug output goes to gdb_stdlog, so this
patch makes this change.

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

binutils/testsuite: don't leave temporary files in main dir

Leaving files in tmpdir/ is generally okay (often intended and helpful),
but the main directory really shouldn't be cluttered.

ld/testsuite: don't leave temporary files in main dir

Leaving files in tmpdir/ is generally okay (often intended and helpful),
but the main directory really shouldn't be cluttered.

testsuites: prune checking gas for CFI / SFrame

Both leave the generated assembler file around. Maybe that's okay-ish
when left in tmpdir/, but the main directories really shouldn't be
cluttered. The file actually doesn't even need putting there when not
working with a remote host.

The SFrame test additionally leaves an a.out file in the main directory,
then the assembler output isn't really of interest anyway.

testsuites: prune huge files

Some tests leave files sometimes well beyond the 10Mb boundary. Remove
those after testing.

bfd: avoid elf-vxworks.c for non-VxWorks targets

It is wasteful to build this file when it's not actually used. Limit it to
VxWorks targets and introduce a compiler define (paralleling
OBJ_MAYBE_ELF, as having similar purpose) to guard internals.

By adding more #ifdef-ary, more savings may be possible. For now, besides
those guarding the vector definitions, only ones necessary to avoid the
need for elf_vxworks_*() inline stubs are being added. Somewhat similarly
tighter #ifdef around the definitions of *_elf*_vxworks*_vec (using
HAVE_..._vec) may yield further savings.

bfd: avoid elf-solaris2.c for non-Solaris targets

Even if small, it is wasteful to build this file when it's not actually
used. Limit it to Solaris targets and introduce a compiler define
(paralleling OBJ_MAYBE_ELF, as having similar purpose) to guard internals.

bfd: avoid elf-sframe.c for SFrame-unaware targets

It is wasteful to build this file when it's not actually used. Limit it
to targets actually using SFrame and introduce a compiler define
(paralleling OBJ_MAYBE_ELF, as having similar purpose) to guard internal
function decls.

bfd: avoid elf-attrs.c for ELF-attributes-free targets

It is wasteful to build this file when it's not actually used. Limit it
to targets actually using ELF attributes and introduce a compiler define
(paralleling OBJ_MAYBE_ELF, as having similar purpose) to guard internal
function decls and to provide stubs for exported functions.

gas: conditionalize body of create_obj_attrs_section()

This way bfd_elf_obj_attr_size() and bfd_elf_set_obj_attr_contents() will
remain unused for targets not supporting object attributes, which allows
libbfd to not provide them.

Also correct the surrounding #if-s: OBJ_MAYBE_ELF really needs taking into
consideration as well.

Automatic date update in version.in