[gdbsupport] Regenerate Makefile.in

The buildbot complains about an out-of-date Makefile.in.  Fix this by
regenerating it from Makefile.am using automake.

or1k: Mark undefined TLS symbol as STT_TLS

Update or1k_apply_fix to handle all TLS relocations.

PR gas/33426
* config/tc-or1k.c (or1k_apply_fix): Handle all TLS relocations.

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

x86: Cache the symbol table when packing relative relocations

When packing relative relocations, x86 linker may load the same symbol
table repeatedly, which can take a long time.  On Intel Core i7-1195G7
with 32GB RAM, it takes more than 45 minutes to create an output with
-pie -z pack-relative-relocs from an input with 208025 code sections.
Cache the symbol table to reduce the link time to less than 2 seconds.

On the same machine, creating 3.1GB clang executable in LLVM 21.1.3 debug
build:

user            55.39 seconds
system          6.71 seconds
total           65.80 seconds
maximum set(GB) 10.43
page faults     2406941

PR ld/33765
* elfxx-x86.c (elf_x86_relative_reloc_record_add): Remove
keep_symbuf_p.
(_bfd_x86_elf_link_relax_section): Updated.  Cache the symbol
table to avoid loading it again.

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

Automatic date update in version.in

[gdb/testsuite] Add missing wait in gdb.multi/sched-multi-add-inferior.exp

With a gdb build with -O0 and Address Sanitizer and test-case
gdb.multi/sched-multi-add-inferior.exp, I get:
...
FAIL: $exp: target_type_1=extended-remote: target_type_2=extended-remote: \
  continue to function1
FAIL: $exp: target_type_1=extended-remote: target_type_2=extended-remote: \
  continue to function2
FAIL: $exp: target_type_1=native: target_type_2=extended-remote: \
  continue to function1
FAIL: $exp: target_type_1=native: target_type_2=extended-remote: \
  continue to function2
FAIL: $exp: target_type_1=native: target_type_2=native: continue to function1
FAIL: $exp: target_type_1=native: target_type_2=native: continue to function2
...

In more detail, for the target_type_1 == target_type_2 == native configuration,
we have:
...
(gdb) continue^M
Continuing.^M
[Switching to Thread 0x7ffff7cc02c0 (LWP 2514714)]^M
^M
Thread 2.1 "sched-multi-add" hit Breakpoint 4, main (...) at multi-target.c:94^M
94            function2 (); /* set break 2 here */^M
(gdb) FAIL: $exp: target_type_1=native: target_type_2=native: \
  continue to function1
thread apply 2.1 set wait_for_gdb = 0^M
^M
Thread 2.1 (Thread 0x7ffff7cc02c0 (LWP 2514714) "sched-multi-add"):^M
(gdb) PASS: $exp: target_type_1=native: target_type_2=native: \
  thread apply 2.1 set wait_for_gdb = 0
continue^M
Continuing.^M
[Switching to Thread 0x7ffff7cc02c0 (LWP 2514718)]^M
^M
Thread 3.1 "sched-multi-add" hit Breakpoint 3, main (...) at multi-target.c:93^M
93            function1 (); /* set break 1 here */^M
(gdb) FAIL: $exp: target_type_1=native: target_type_2=native: \
  continue to function2
...

The situation is as follows:
- there are two inferiors
- due to "set schedule-multiple on", continue continues both inferiors
- after the first continue, the test-case expects the breakpoint on thread 3.1
  to trigger
- instead, the breakpoint in thread 2.1 triggers

The mechanism by which this order is supposed to be guaranteed, is that thread
2.1 is blocked, and only unblocked after thread 3.1 hits its breakpoint:
...
    # Unblock thread 2.1 and continue again.  This time, thread 2.1
    # will hit a breakpoint.
    gdb_test "thread apply 2.1 set wait_for_gdb = 0" ".*"
...

However, thread 2.1 is never blocked.

Fix this by adding the missing:
...
    gdb_test "thread apply 2.1 set wait_for_gdb = 1" ".*"
...

Tested on x86_64-linux.

Approved-by: Kevin Buettner <kevinb@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33540

Automatic date update in version.in

gdb/coffread: simplify stab section detection

We look for stab sections for the sole purpose of emitting a warning if
we see one.  Simplify this by using a boolean to indicate if we saw a
stab section or not.  Simplify the search to just look for sections
starting with ".stab", it should be enough for this purpose.

Also, remove the make_scoped_restore that would overwrite the stab
section vector, I'm not sure why it's there.  It seems to me like it
would cause the warning to never be shown.

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

gdb: update shared libraries when inferior is created, even if no bfd exists

I noticed an unexpected behaviour difference when loading a core file
in GDB depending on whether the main executable can be accessed or not.
If GDB knows about the main executable, then symbols for unrelated
libraries (such as libc) are loaded. If GDB cannot find the main
executable, then they are not.

Here is a reproducer using the artifacts from
gdb.python/py-missing-objfile.exp.  This test is ideal to reproduce the
problem, because it hides from GDB the executable and library used to
generate the core file.

In the "good" case, where we give an executable to GDB (in addition to
the core), we get a complete backtrace (assuming GDB can find debug symbols
for glibc):

    $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.python/py-missing-objfile/hidden/py-missing-objfile  -c testsuite/outputs/gdb.python/py-missing-objfile/py-missing-objfile.core -ex bt -batch
    ...
    #0  __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
    #1  0x00007fcbd0c98a13 in __pthread_kill_internal (threadid=<optimized out>, signo=6) at pthread_kill.c:89
    #2  0x00007fcbd0c3e410 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
    #3  0x00007fcbd0c2557a in __GI_abort () at abort.c:77
    #4  0x000055561659d152 in dump_core () at /home/sdarche/binutils-gdb/gdb/testsuite/gdb.python/py-missing-objfile.c:34
    #5  0x000055561659d182 in main () at /home/sdarche/binutils-gdb/gdb/testsuite/gdb.python/py-missing-objfile.c:46

Or, if debug symbols for glibc aren't available, GDB at least tells us
from which .so each frame comes from:

    #0  0x00007fcbd0c9894c in ?? () from /usr/lib/libc.so.6
    #1  0x00007fcbd0c3e410 in raise () from /usr/lib/libc.so.6
    #2  0x00007fcbd0c2557a in abort () from /usr/lib/libc.so.6
    #3  0x000055561659d152 in dump_core () at /home/sdarche/binutils-gdb/gdb/testsuite/gdb.python/py-missing-objfile.c:34
    #4  0x000055561659d182 in main () at /home/sdarche/binutils-gdb/gdb/testsuite/gdb.python/py-missing-objfile.c:46

If we omit passing the main executable to GDB (and GDB has no way to
find it, because the test moved it on purpose), we get:

    $ ./gdb -nx -q --data-directory=data-directory -c testsuite/outputs/gdb.python/py-missing-objfile/py-missing-objfile.core -ex bt -batch
    #0  0x00007fcbd0c9894c in ?? ()
    #1  0x0000000000000000 in ?? ()

Upon investigating, the "normal" path to load associated sos is through
the post_create_inferior function in infcmd.c, which calls
solib_create_inferior_hook.  The solib_ops in turn loads the symbols by
calling solib_add.

When loading a core file, the list of loaded shared libraries can be
found (and as we can see with `info sharedlibraries`, this is done
properly).  However, the current control flow handling in
post_create_inferior does not ask the solib to load the symbols through
solib_create_inferior_hook if a main exec_bfd is not present.

The proposed change eliminates the if statement in the
post_create_inferior function.

This change may have side-effects on some solib_ops which may not check
if the current inferior has a valid exec_bfd().

This commit also modifies the gdb.python/py-missing-objfile.exp test,
providing a test case in which the main exec file is missing, but not
the shared library.  This is a good way to confirm this fix works, as
the symbols from the shared library should be found even though the main
exec file is missing.  The test cases also ask GDB to clean_restart to
ensure there is no leftover bfd or symbols.

Furthermore, the total number of calls to the missing objfiles handler
is 4 in the "all objfiles missing" test case instead of the
previous 3 :
- 2 for the mapped files (exec and so), in
  core_target_build_file_mappings
- 1 for the core file exec, in locate_exec_from_corefile_build_id
- 1 for the missing so, in solib_map_sections

The changes in check_loaded_debug handle the case where no symbol exist
at all, and also when a symbol table exists (but the symbol cannot be
found)

Note: Some comments in some solib_ops (frv, dbst) seem to indicate that
solib_add should be called before solib_create_inferior_hook by
post_create_inferior, but this does not seem to be the case anymore.
Those comments might need to be updated.

Change-Id: I517ff85813c941215b19fa8540c77f755a0aca28
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Tested-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb/solib-svr4: update solib when an inferior is not being executed (e.g. core files)

Loading a core file currently generates a warning when enabling `set
verbose on`:

    $ ./gdb -nx -q --data-directory=data-directory a.out -ex "set verbose on" -ex "core core.151894" -batch
    ...
    warning: platform-specific solib_create_inferior_hook did not load initial shared libraries.

The warning comes from infcmd.c:post_create_inferior() which initializes
the solib_ops.  The latter is in charge of calling solib_add() in its
implementation of solib_ops::create_inferior_hook.  The svr4_solib_ops
class, however, does not call solib_add (through enable_break) if the
inferior is not being executed.

This patch moves the call to solib_add() outside of the conditional
nested call.  No user-visible change should be expected, except for fact
that the warning will no longer be shown.

Change-Id: I5488dc166fdc985669422a0f1c0c2f43158cd8c4
Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

gdb/testsuite: fix typo in gdb.python/py-missing-objfile.exp

The py-missing-objfile.exp test attempts to load a core file with
missing debug info and counts the number of times a python missing
objfile handler is called.

In one test case, the number of expected calls to the missing objfile
handler is two, but the test case misleadingly says three. This commit
fixes this typo.

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

gdb/coffread: remove unused fields of coff_symfile_info

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

gdb/coffread: remove unnecessary forward declarations

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

gdb: remove gdbarch_ecoff_reg_to_regnum

It is unused since the mdebugread removal.

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

gdb: remove gdbarch_stab_reg_to_regnum

It is unused, presumably since we removed stab support.

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

[gdb/symtab] Cache dw2_get_file_names result for dummy CU

Consider function dw2_get_file_names:
...
static struct quick_file_names *
dw2_get_file_names (dwarf2_per_cu *this_cu, dwarf2_per_objfile *per_objfile)
{
  /* This should never be called for TUs.  */
  gdb_assert (!this_cu->is_debug_types ());

  if (this_cu->files_read)
    return this_cu->file_names;

  cutu_reader reader (*this_cu, *per_objfile, nullptr,
                      per_objfile->get_cu (this_cu), true, language_minimal,
                      nullptr);
  if (!reader.is_dummy ())
    dw2_get_file_names_reader (reader.cu (), reader.top_level_die ());

  return this_cu->file_names;
}
...

If dw2_get_file_names_reader is called, the result is cached in
this_cu->file_names, and this fact is tracked in this_cu->files_read, allowing
subsequent calls to access the cached value.

But for dummy CUs, while the result (nullptr) is cached in
this_cu->file_names, this is not noted in this_cu->files_read, and
consequently subsequent calls will read the top-level DIE in the CU again.

Fix this by setting this_cu->files_read also for dummy CUs.

Tested on x86_64-linux.

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

Show constants in DAP scopes output

This changes the DAP code so that constants will now be returned by a
DAP scopes request.  This is perhaps slightly strange with Ada
enumerators, but on the other hand this is consistent with what the
CLI does.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Allow DAP client to set Ada source charset at launch

A co-worker reported that certain symbols weren't appearing in the DAP
'scopes' response.  In particular, symbols with non-ASCII names didn't
appear; though further research showed that this was in fact a result
of the variable in question actually being a constant.

Unfortunately Ada still requires the user to set the Ada source
character set in order to properly display symbol names.  For DAP, it
seemed to make sense to allow this as a launch parameter.  This patch
implements this.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>

Minor reorganization to DAP launch documentation

This changes the DAP launch/attach documentation so that common
options are called out in a separate table.

Approved-By: Eli Zaretskii <eliz@gnu.org>

Explicitly use print_name in DAP

This changes some DAP code to explicitly use a symbol's print name.
Some places were using '.name'; and while 'str' does use the print
name, it seems better to be both consistent and explicit.

gdb: install expanded_symbols_functions into objfiles created by JIT reader

This commit installs expanded_symbols_functions into objfiles created by
JIT reader API. This is needed so the JIT symbols can be used just like
any other symbols.

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

gdb: introduce expanded_symbols_functions

This commit adds new "quick" symbol functions, expanded_symbols_functions,
that work purely on examining objfile's compunits. This is useful for
example for JIT reader API where symbols are created by user-provided
code.

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

gdb: Make printing enum types prettier.

Update printing of enum types to follow the same formatting
conventions as for structs resulting in more readable output.
Now that horizontal space is less of an issue enum values are
always printed.
Empty enums are now printed with an added "<no enum values>"
message.

Example of printing an enum with default values:
enum class TestEnum {A, B, C, D};

(gdb) ptype TestEnum
type = enum class TestEnum : int {
    TestEnum::A = 0,
    TestEnum::B = 1,
    TestEnum::C = 2,
    TestEnum::D = 3
}

Example of printing an empty enum:
enum class TestEnum {};

(gdb) ptype TestEnum
type = enum class TestEnum : int {
    <no enum values>
}

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

gdb: Replace \r\n with multi_line to make tests more readable

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

gdb: Move logic for printing enums to a helper function

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

gdb: Add myself to gdb/MAINTAINERS

Forget the last displayed sal when the referenced objfile is destroyed

When creating a new line-breakpoint after rerunning with a disabled or
removed breakpoint in a solib, you currently get this use-after-free
crash:

(gdb) break solib_main
Breakpoint 1 at 0x1030
(gdb) run
Starting program: /home/src/lappy/binutils-gdb.git/build/gdb/testsuite/outputs/gdb.base/solib-breakpoints-rerun/solib-breakpoints-rerun
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".

Breakpoint 1, solib_main (arg=100) at /home/src/lappy/binutils-gdb.git/build/gdb/testsuite/../../../gdb/testsuite/gdb.base/solib1.c:7
7   int ans = arg*arg; /* HERE */
(gdb) disable
(gdb) set confirm off
(gdb) run
Starting program: /home/src/lappy/binutils-gdb.git/build/gdb/testsuite/outputs/gdb.base/solib-breakpoints-rerun/solib-breakpoints-rerun
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".
[Inferior 1 (process 50868) exited normally]
(gdb) break 18
=================================================================
==50836==ERROR: AddressSanitizer: heap-use-after-free on address 0x7d65a543d488 at pc 0x55f022334c29 bp 0x7ffe9c7f45f0 sp 0x7ffe9c7f45e0
READ of size 8 at 0x7d65a543d488 thread T0
    #0 0x55f022334c28 in symtab::filename() const ../../gdb/symtab.h:1747
    #1 0x55f023a32b7d in create_sals_line_offset ../../gdb/linespec.c:2013
    #2 0x55f023a37937 in convert_linespec_to_sals ../../gdb/linespec.c:2294
    #3 0x55f023a3cf79 in parse_linespec ../../gdb/linespec.c:2652
    #4 0x55f023a415b2 in location_spec_to_sals ../../gdb/linespec.c:3050
    #5 0x55f023a423b0 in decode_line_full(location_spec*, int, program_space*, symtab*, int, linespec_result*, char const*, char const*) ../../gdb/linespec.c:3126
    #6 0x55f022826e1b in parse_breakpoint_sals ../../gdb/breakpoint.c:9069
    #7 0x55f0228291c2 in create_breakpoint(gdbarch*, location_spec*, char const*, int, int, char const*, bool, int, int, bptype, int, auto_boolean, breakpoint_ops const*, int, int, int, unsigned int) ../../gdb/breakpoint.c:9312
    #8 0x55f02282c298 in break_command_1 ../../gdb/breakpoint.c:9471
    #9 0x55f02282d0bb in break_command(char const*, int) ../../gdb/breakpoint.c:9541
    #10 0x55f022b05f56 in do_simple_func ../../gdb/cli/cli-decode.c:94

0x7d65a543d488 is located 904 bytes inside of 4064-byte region [0x7d65a543d100,0x7d65a543e0e0)
freed by thread T0 here:
    #0 0x7f55aa91f79d in free /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:51
    #1 0x55f0221f6403 in xfree<void> ../../gdb/../gdbsupport/gdb-xfree.h:37
    #2 0x55f027b64851 in call_freefun ../../libiberty/obstack.c:103
    #3 0x55f027b66283 in _obstack_free ../../libiberty/obstack.c:280
    #4 0x55f0221f7a07 in auto_obstack::~auto_obstack() ../../gdb/../gdbsupport/gdb_obstack.h:126
    #5 0x55f023f3dd83 in objfile::~objfile() ../../gdb/objfiles.c:509
    #6 0x55f023f511d8 in std::default_delete<objfile>::operator()(objfile*) const /usr/include/c++/15.2.1/bits/unique_ptr.h:93
    #7 0x55f023f4b8cd in std::unique_ptr<objfile, std::default_delete<objfile> >::~unique_ptr() /usr/include/c++/15.2.1/bits/unique_ptr.h:399
    #8 0x55f0240b6dab in owning_intrusive_list<objfile, intrusive_base_node<objfile> >::erase(intrusive_list_iterator<objfile, intrusive_base_node<objfile> >) ../../gdb/../gdbsupport/owning_intrusive_list.h:113
    #9 0x55f0240adb68 in program_space::remove_objfile(objfile*) ../../gdb/progspace.c:202
    #10 0x55f023f3cfcf in objfile::unlink() ../../gdb/objfiles.c:409
    #11 0x55f023f40faf in objfile_purge_solibs(program_space*) ../../gdb/objfiles.c:687
    #12 0x55f02487ec19 in no_shared_libraries(program_space*) ../../gdb/solib.c:1359
    #13 0x55f024b37e1e in target_pre_inferior() ../../gdb/target.c:2474
    #14 0x55f0238ac7cd in run_command_1 ../../gdb/infcmd.c:381
    #15 0x55f0238ae438 in run_command ../../gdb/infcmd.c:510
    #16 0x55f022b05f56 in do_simple_func ../../gdb/cli/cli-decode.c:94

previously allocated by thread T0 here:
    #0 0x7f55aa920cb5 in malloc /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_malloc_linux.cpp:67
    #1 0x55f02241d780 in xmalloc ../../gdb/alloc.c:52
    #2 0x55f027b6461f in call_chunkfun ../../libiberty/obstack.c:94
    #3 0x55f027b649d1 in _obstack_begin_worker ../../libiberty/obstack.c:141
    #4 0x55f027b650c5 in _obstack_begin ../../libiberty/obstack.c:164
    #5 0x55f0221f775a in auto_obstack::auto_obstack() ../../gdb/../gdbsupport/gdb_obstack.h:123
    #6 0x55f023f39c91 in objfile::objfile(gdb::ref_ptr<bfd, gdb_bfd_ref_policy>, program_space*, char const*, enum_flags<objfile_flag>) ../../gdb/objfiles.c:257
    #7 0x55f023f3ccaa in objfile::make(gdb::ref_ptr<bfd, gdb_bfd_ref_policy>, program_space*, char const*, enum_flags<objfile_flag>, objfile*) ../../gdb/objfiles.c:392
    #8 0x55f02498b1d2 in symbol_file_add_with_addrs ../../gdb/symfile.c:1069
    #9 0x55f02498c099 in symbol_file_add_from_bfd(gdb::ref_ptr<bfd, gdb_bfd_ref_policy> const&, char const*, enum_flags<symfile_add_flag>, std::vector<other_sections, std::allocator<other_sections> >*, enum_flags<objfile_flag>, objfile*) ../../gdb/symfile.c:1156
    #10 0x55f02487255b in solib_read_symbols(solib&, enum_flags<symfile_add_flag>) ../../gdb/solib.c:660
    #11 0x55f024876c0c in solib_add(char const*, int, int) ../../gdb/solib.c:993
    #12 0x55f02487f1f8 in handle_solib_event() ../../gdb/solib.c:1399
    #13 0x55f0227df91f in bpstat_stop_status(address_space const*, unsigned long, thread_info*, target_waitstatus const&, bpstat*) ../../gdb/breakpoint.c:5962
    #14 0x55f023944fa8 in handle_signal_stop ../../gdb/infrun.c:7130
    #15 0x55f02393e2a1 in handle_inferior_event ../../gdb/infrun.c:6574
    #16 0x55f0239279f2 in fetch_inferior_event() ../../gdb/infrun.c:4713
    #17 0x55f023885fe3 in inferior_event_handler(inferior_event_type) ../../gdb/inf-loop.c:42
    #18 0x55f023af706e in handle_target_event ../../gdb/linux-nat.c:4449
    #19 0x55f027c2d2f0 in handle_file_event ../../gdbsupport/event-loop.cc:551
    #20 0x55f027c2e4ff in gdb_wait_for_event ../../gdbsupport/event-loop.cc:672

It happened because last_displayed_symtab_info of stack.c still contained
a reference to a symtab that was already freed in the 2nd run.
This fixes it by clearing last_displayed_symtab_info in the objfile
destructor, if it is pointing to that objfile.
Now setting of the 2nd breakpoint works:

(gdb) break 18
Breakpoint 2 at 0x555555555141: file /home/src/lappy/binutils-gdb.git/build/gdb/testsuite/../../../gdb/testsuite/gdb.base/so-impl-ld.c, line 18.
(gdb)

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32668
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

aarch64: Fix out-of-range branch veneers when --fix-cortex-a53-843419

The erratum mitigation support for the Cortex-A53 843419 erratum
inserts a new stub for every possible instance of the erratum.  Since
each stub ends up inserting 4k of space into the binary, in order to
avoid perturbing the alignment of other potential erratum sequences we
can end up adding substantially more space than the distance to the
next long-branch stub that we've prepared for.

The problem is, fundamentally a phase ordering problem, but that's
easily resolvable by running the 843419 erratum pass first and then
creating the stub groups once that is done.  In this way we take into
account the additional padding when forming the groups to ensure that
they remain within range.

aarch64: Use section names for empty stub symbols

If the target symbol for a stub was empty we would previously end up
using an anonymous stub name of the form ___veneer.  To make things a
little clearer use the section symbol for the target section in this
case.  We now end up with veneer symbols like __.text_veneer.

Adjusted the tests accordingly.

x86: optimize MOVZX in a few cases

There are shorter encoding options available, so space optimization is
possible.

x86: optimize MOVSX between accumulator regs

Except on the K6 CBW/CWDE/CDQE perform equally well, but are shorter to
encode.

bfd: avoid elf-properties.c for ELF-free targets

It is absurd to build this file when it's not possibly used. Move its
references to where other elf-*.* are and introduce a compiler define
(paralleling what gas uses, as having the same purpose) to isolate out
ELF-specific pieces in compress.c (which is where the references into
elf-properties.c are coming from).

ELF: give .note.GNU-stack proper section type

Like all .note and .note.* sections it should be SHT_NOTE, not
SHT_PROGBITS.

ld/ELF: suppress note section rearrangement for relocatable linking

Input sections would generally best retain their order from in the
input(s) or relocatable links. In particular the (odd) sorting of note
sections by alignment is entirely unnecessary there, and could potentially
even be harmful. Simply accumulate orphan sections in the order observed.

Of course this has an effect on section order, so a few testsuite
adjustments are necessary. The test for PR ld/27590 is being relaxed, as
it's no clear why sh_link fields would need to have exact expectations
when at the same time section numbers aren't matched. (Obviously the .rela
sections should match their corresponding data sections', but afaict this
cannot be [easily] expressed.) Xstormy16 XFAILs for a few tests can be
dropped as the sections of interest there are orphan ones, and hence now
are placed independent of the linker scripts unusual placing of .data
ahead of .text.

gdb/xcoffread: stylistic cleanup

Do a few cleanups:

 - declaring variables where they are used
 - rename functions to be more precise
 - add explicit comparison against nullptr or 0
 - remove struct/union keywords
 - remove or update outdated comments

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

gdb/xcoffread: replace 2 switches with if

Replace these 2 switches that have only one case with a single if
statement.  It is highly unlikely that we'll ever need to check for
other values.

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

gdb/xcoffread: simplify xcoff_secnum_to_sections

The only remaining caller of xcoff_secnum_to_sections doesn't care about
the section index in the objfile, so remove that part.

Return the BFD section as the return value of the function, instead of
an output parameter.  Remove the unnecessary default in the switch, to
avoid a "jump to label over variable initialization" warning.

Rename to xcoff_secnum_to_section (singular).

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

gdb/xcoffread: allocate symbol table using vector in scan_xcoff_symtab

The symbol table content is only needed for the duration of
scan_xcoff_symtab, so it's not necessary to allocate it on the objfile
obstack.  Switch to using a vector that is freed at the end of the
function.

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

gdb/xcoffread: remove xcoff_symfile_info::{symtbl,symtbl_num_syms}

It is not necessary to save the symbol table content and number of
symbols in xcoff_symfile_info, because they are only needed for the
duration of scan_xcoff_symtab.

Move the reading of the symbol table content to scan_xcoff_symtab, and
keep everything as local variables.

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

gdb/xcoffread: remove XCOFF_DATA macro

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

gdb/xcoffread: remove read of .debug section

This is not used by anything.

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

gdb/xcoffread: remove name computation

It is no longer necessary to get names of symbols.  The only thing we
are interested in is the symbol to get the TOC offset, for which the
name doesn't matter.

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

Automatic date update in version.in

Fix error case in coffread.c

coffread.c is the last spot (that I know of) that incorrectly calls
perror_with_name when a BFD function fails.  The issue here is that
perror_with_name examines errno, but BFD failures do not set this.
This patch changes this to use error and bfd_errmsg.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31041
Approved-By: Simon Marchi <simon.marchi@efficios.com>

gas: sframe: fix PR gas/33756

Previously, sframe_xlate_do_remember_state () relied exclusively on
last_fre (the last Frame Row Entry for the previous PC range block).  At
the start of a function (before an advance in location), last_fre is
NULL.  The intent of DW_CFA_remember_state, however, is to simply
snapshot the state of the call frame information at the time.  In terms
of SFrame generation, this means that we should simply look at cur_fre
(the scratchpad FRE currently being built from initial CFI
instructions in the current context).

Remove the common-empty-1.s which assumed that .cfi_startproc,
immediately followed by a .cfi_remember_state is not present out in the
wild.  Its best to not make such an assumption, as such a sequence is
valid CFI, FWIW.

Initial CFI are arch-specific, so add a new testcase for x86_64 to check
.cfi_remember_state handling for SFrame is sensible.  While at at, also
add a new testcase for s390x.

Co-Authored-by: Jens Remus <jremus@linux.ibm.com>
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
gas/
PR gas/33756
* gen-sframe.c (sframe_xlate_do_remember_state): Use cur_fre.
gas/testsuite/
* gas/cfi-sframe/cfi-sframe.exp: Adjust common-empty-1 test to
be repurposed as cfi-sframe-x86_64-pr33756.  Add s390x testcase.
* gas/cfi-sframe/common-empty-1.d: Removed.
* gas/cfi-sframe/common-empty-1.s: Removed.
* gas/cfi-sframe/cfi-sframe-x86_64-pr33756.d: New test.
* gas/cfi-sframe/cfi-sframe-x86_64-pr33756.s: New test.
* gas/cfi-sframe/cfi-sframe-s390x-pr33756.d: New test.
* gas/cfi-sframe/cfi-sframe-s390x-pr33756.s: New test.

Remove two fields from xcoff_symfile_info

Inspection shows that xcoff_symfile_info::min_lineno_offset and
xcoff_symfile_info::max_lineno_offset are never really used.  Removing
this then shows that find_linenos doesn't do any useful work.  So,
remove the fields and this function.

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

Include libiberty.h in bfdio.c

On my Fedora 41 machine, a cross-hosted mingw build fails with:

../../binutils-gdb/bfd/bfdio.c:249:50: error: implicit declaration of function 'ARRAY_SIZE'; did you mean 'ARRAYSIZE'? [-Wimplicit-function-declaration]

Including libiberty.h in bfdio.c fixes the failure.

Remove obsolete wrap_here declaration

wrap_here is still declared in utils.h, but hasn't been defined in
quite some time.  This removes the obsolete declaration.

Remove sym_fns::sym_read_linetable

The last user of sym_fns::sym_read_linetable was xcoffread.c.  Now
that the code there has been removed, this callback can be removed as
well.  This slightly simplifies buildsym.

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

Remove sym_fns::sym_finish

sym_finish::sym_finish isn't needed by any existing code, so this
patch removes it.

Note that it should never be needed again.  It's much cleaner, IMO,
for symbol readers to attach data to the objfile or per-BFD via the
registry.  Then, any cleanup will be automatic.

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

Remove sym_fns::sym_new_init

sym_fns::sym_new_init has long been weird.  There's even a comment in
symfile.c saying this.

After some recent changes, nothing needs this any more.  So, this
patch removes it entirely.

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

Don't call set_last_source_file from xcoffread.c

xcoffread.c is no longer really using the buildsym code.  This removes
the last call, which should not be needed, and then removes the
include.

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

Remove unused includes from xcoffread.c

I found a number of includes in xcoffread.c that aren't needed.

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

Remove dead code from xcoffread.c

This removes a lot of obviously dead code from xcoffread.c.  There are
some unused macros and types.  A few globals can be removed because
they are never assigned to or really used for anything.

Import the following commits from the master config sources: a2287c3041a3f2a204eb942e09c015eab00dc7dd 973e3e6af23b73a4f1b8d95680454cae22593bf8 3a71dc102953608d4592ec401b519837c28a672a f91a544533876c70f43b9fd51064b2bcf3fa7382  484648c73f3843b256dd011bd415e81594300a0a 7f4149527babe92cb5da1032734f5cb90cefdac5 9f6e0fe8ce04628bbd4a455118ff3f8309a1aef9

Restore changes to libiberty sources created in commit 219822fd5db6305592b45677a3b38c02b523360e

[gdb/testsuite] Add missing require in gdb.debuginfod/solib-with-dwz.exp

Add missing "require allow_debuginfod_tests" in test-case
gdb.debuginfod/solib-with-dwz.exp.

Automatic date update in version.in

gdb/copyright.py: run autoconf

The last new year procedure missed running autoreconf in gnulib/ and
sim/ to update the Makefile.in files (following the updates of the
corresponding Makefile.am files).  I propose to make the script run
`autoreconf -v` to ensure we don't miss those anymore.  It takes a bit
of time, but that script isn't run very frequently (I'd say more or less
once a year).

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

gdb/copyright.py: update unordered_dense path

The unordered_dense library is now contained in the
gdbsupport/unordered_dense directory, update the exclusion entry
accordingly.

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

gdb/dwarf: add dwarf2_per_cu::as_signatured_type

Add dwarf2_per_cu::as_signatured_type, which returns the dwarf2_per_cu
cast to signatured_type if it is indeed a signatured type (type unit),
and nullptr otherwise.  It can replace a few spots where we use the
pattern "check if it's a signatured_type and cast".

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

Mention gdb thread ID in thread messages

Currently the "new thread" message that gdb might print does not
include gdb's own thread ID -- so, if you want to reference the
thread, you must first use "thread find" or "info threads".

This patch changes the announcement to mention the thread.  The
thread-exit message is also updated.

I chose to have it display like this:

    [New Thread 0x7ffff7cbe6c0 (LWP 1267702) (id 2)]
    [Thread 0x7ffff6cbd6c0 (LWP 1267703) (id 3) exited]

... with the 'id' coming later, because it's somewhat of a pain to
wedge the thread id just after the "thread" string where (IMO) it
would more naturally belong.

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

Make 'print_thread_events' static

This makes the 'print_thread_events' global static.  It's never used
outside of thread.c.

Reviewed-by: Stephan Rohr <stephan.rohr@intel.com>

Fix new test for whitespace checker

pre-commit complained about a trailing blank line on this new test.
I've fixed this and also updated the copyright date.

aarch64: Add FEAT_NV3, FEAT_SRMASK2 system registers

aarch64: Add support for FEAT_TPS and FEAT_TPSP system registers

This patch adds support for TPMIN*/TPMAX* system registers
as part of POE2 extension.

gdb: avoid creating misplaced symtabs for dwz files

This commit fixes the issue that is described in detail in the
previous commit; when processing a DWZ file, GDB can end up creating a
symtab associated with a compunit_symtab for a file that was never
compiled into a given compunit_symtab.

The previous commit added a test for this issue, however, things are
slightly complicated because a recent change to GDB:

  commit a736ff7d886dbcc85026264c3ce11c125a8409b2
  Date:   Sat Sep 27 22:29:24 2025 -0600

      Clean up iterate_over_symtabs

Changed GDB in such a way that the problem being discussed here
no longer appears to cause any incorrect behaviour.  Still, I think
this problem is worth fixing.  Adding additional symtabs that are in
the wrong place has the potential to cause problems in the future, but
also, wastes GDB memory, and increases time needed to search through
all symtabs.

The precise problem here is triggered when a DWZ file is created from
multiple object files (as is usually the case).  The DWZ file will
contain a line table which can hold references to any of the source
files, from any of the object files.  Note that a source file doesn't
have to be included in every object file in order to be added to the
line table of the DWZ file.

Within GDB the problem originates from the 'new_symbol' function (in
dwarf2/read.c).  This function looks for the DW_AT_call_file or
DW_AT_decl_file of a symbol, uses this to lookup the line table entry,
and uses this to obtain the symtab to which the symbol should be
attached.

For an inlined subroutine instance, this information can be split
between an objfile's debug information and a shared DWZ file.  For
example, from the gdb.debuginfod/solib-with-dwz.exp test case, this
first bit of DWARF is from the objfile's debug information:

 <2><91>: Abbrev Number: 3 (DW_TAG_inlined_subroutine)
    <92>   DW_AT_abstract_origin: <alt 0x1b>
    <96>   DW_AT_low_pc      : 0x1121
    <9e>   DW_AT_high_pc     : 31
    <9f>   DW_AT_call_file   : 1
    <a0>   DW_AT_call_line   : 26
    <a1>   DW_AT_call_column : 15
 <3><a2>: Abbrev Number: 5 (DW_TAG_formal_parameter)
    <a3>   DW_AT_abstract_origin: <alt 0x2c>
    <a7>   DW_AT_location    : 2 byte block: 91 68      (DW_OP_fbreg: -24)
 <3><aa>: Abbrev Number: 5 (DW_TAG_formal_parameter)
    <ab>   DW_AT_abstract_origin: <alt 0x25>
    <af>   DW_AT_location    : 2 byte block: 91 6c      (DW_OP_fbreg: -20)

The DW_AT_abstract_origin attributes are referencing the following
DWARF which has been placed into the DWZ file:

 <1><1b>: Abbrev Number: 7 (DW_TAG_subprogram)
    <1c>   DW_AT_name        : (indirect string, offset: 0x18a): add_some_int
    <20>   DW_AT_decl_file   : 1
    <21>   DW_AT_decl_line   : 24
    <22>   DW_AT_decl_column : 1
    <23>   DW_AT_prototyped  : 1
    <23>   DW_AT_type        : <0x14>
    <24>   DW_AT_inline      : 3        (declared as inline and inlined)
 <2><25>: Abbrev Number: 8 (DW_TAG_formal_parameter)
    <26>   DW_AT_name        : a
    <28>   DW_AT_decl_file   : 1
    <29>   DW_AT_decl_line   : 24
    <2a>   DW_AT_decl_column : 19
    <2b>   DW_AT_type        : <0x14>
 <2><2c>: Abbrev Number: 8 (DW_TAG_formal_parameter)
    <2d>   DW_AT_name        : b
    <2f>   DW_AT_decl_file   : 1
    <30>   DW_AT_decl_line   : 24
    <31>   DW_AT_decl_column : 26
    <32>   DW_AT_type        : <0x14>

When GDB tries to create the symbols for the DW_TAG_formal_parameter
then this will find the DW_AT_decl_line in the DWZ file.  This will
cause the line table of the DWZ file to be parsed.  This parsing
currently creates symtabs for every file mentioned in the DWZ file's
line table, which includes files that are not part of the original
objfile.

Currently GDB creates and stores the symtabs within the file_entry
object (see dwarf2/line-header.h).  I propose that we make the symtab
creation lazy; when the symtab is requested from a file_entry object,
the symtab will be created at this point.

Doing this will cause another problem though.  In dwarf_decode_lines,
we specifically create all of the symtabs so that there will be a
symtab even for files that contain no code.  We don't want to regress
this case.

The solution is that dwarf_decode_lines will still trigger the symtab
creation (by asking the file_entries for their symtab), unless we're
processing a DWZ file.

We don't need to worry about files that have no code, which are
mentioned in a DWZ file, as these files will also be mentioned in the
original objfile's line table.  When that line table is processed (as
it will be), then symtabs for all files mentioned will be created.  In
this way we will get:

 (a) symtabs for every source file mentioned in the original objfile,
     and

 (b) symtabs for every source file that is specifically used by the
     DWARF from the DWZ file.

I've update the gdb.debuginfod/solib-with-dwz.exp test to check the
symtab creation, and also added gdb.base/dwz-symtabs.exp, which is
very similar to solib-with-dwz.exp, but doesn't depend on debuginfod
and instead just focuses on which symtabs are created, this make the
test a little simpler overall.

Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Simon Marchi <simark@simark.ca>

gdb: test for misplaced symtab causing file not found error

This patch adds a new test that checks for a bug that was, if not
fixed, then at least, worked around, by commit:

  commit a736ff7d886dbcc85026264c3ce11c125a8409b2
  Date:   Sat Sep 27 22:29:24 2025 -0600

      Clean up iterate_over_symtabs

The bug was reported against Fedora GDB which, at the time the bug was
reported, is based off GDB 16, and so doesn't include the above
commit.  The bug report can be found here:

  https://bugzilla.redhat.com/show_bug.cgi?id=2403580

To summarise the bug report: a user is inspecting an application
backtrace.  The original bug report was from a core file, but the same
issue will trigger for a live inferior.  It's the inspection of the
stack frames which is important.  The user moves up the stack with the
'up' command and eventually finds an interesting frame.  They use
'list' to view the source code at the current location, this works and
displays lines 6461 to 6470 from the source file '../glib/gmain.c'.
The user then does 'list 6450' to try and display some earlier lines
from the same source file, at which point GDB gives the message:

   warning: 6445  ../glib/gmain.c: No such file or directory

So GDB initially manages to find the source file, but for the very
next command, GDB now claims that the source file doesn't exist.

As I said, commit a736ff7d886d appears to fix this issue, but it
wasn't clear to me (from the commit message) if this commit was
intended to fix any bugs, or if the bug was being hidden by this
commit.  I've spent some time trying to understand what's going on,
and have come up with this test case.

I think there might still be an issue in GDB, but I do think that the
above commit really is making it so that the issue (if it is an issue)
doesn't occur in that particular situation any more, so I think we can
consider the above commit a fix, and testing for this bug is worth
while to ensure it doesn't get reintroduced.

In order to trigger this bug we need these high level requirements:

  1. Multiple shared libraries compiled from the same source tree.  In
     this case it was glib, but the test in this commit uses a much
     smaller library.

  2. Common DWARF must be pulled from the libraries using the 'dwz'
     tool.

  3. Debuginfod must be in use for at least downloading the source
     code.  In the original bug, and in the test presented here,
     debuginfod is used for fetching both the debug info, and the
     source code for the library.

There are some additional specific requirements for the DWARF in order
to trigger the bug, but to make discussing this easier, lets look at
the structure of the test presented here.  When discussing the source
files I'll drop the solib-with-dwz- prefix, e.g. when I mention
'foo.c' I really mean 'solib-with-dwz-foo.c'.

There are three shared libraries built for this test, libbar.so,
libfoo.so, and libfoo-2.so.  The source file bar.c is used to create
libbar.so, and foo.c is used to create libfoo.so and libfoo-2.so.

The main test executable is built from main.c, and links against
libbar.so and libfoo.so.  libfoo-2.so is not used by the main
executable, and just exists to trigger some desired behaviour from the
dwz tool.

The debug information for each shared library is extracted into a
corresponding .debug file, and the dwz tool is used to extract common
debug from the three .debug files into a file called 'common.dwz'.

Given all this then, in order to trigger the bug, the following
additional requirements must be met:

  4. libbar.so must NOT make use of foo.c.  In this test libbar.so is
     built from bar.c (and some headers) only.

  5. A reference to foo.c must be placed into common.dwz.  This is why
     libfoo-2.so exists, as this library is almost identical to
     libfoo.so, there is lots of shared DWARF between libfoo.so and
     libfoo-2.so which can be moved into common.dwz, this shared DWARF
     includes references to foo.c, so an entry for foo.c is added to
     the file table list in common.dwz.

  6. There must be a DWARF construct within libbar.so.debug that
     references common.dwz, and which causes GDB to parse the line
     table from within common.dwz.  For more details on this, see
     below.

  7. We need libbar.so to appear before libfoo.so in GDB's
     comunit_symtab lists.  This means that GDB will scan the symtabs
     for libbar.so before checking the symtabs of libfoo.so.  I
     achieve this by mentioning libbar.so first when building the
     executable, but this is definitely the most fragile part of the
     test.

To satisfy requirement (6) the inline function 'add_some_int' is added
to the test.  This function appears in both libbar.so and libfoo.so,
this means that the DW_TAG_subprogram representing the abstract
instance tree will be moved into common.dwz.  However, as this is an
inline function, the DW_TAG_inlined_subroutine DIEs for each concrete
instance, will be left in libbar.so.debug and libfoo.so.debug, with a
DW_AT_abstract_origin that points into common.dwz.

When GDB parses libbar.so.debug it finds the DW_TAG_inlined_subroutine
and begins processing it.  It sees the DW_AT_abstract_origin and so
jumps into common.dwz to read the DIEs that define the inline
function.  Here is the DWARF from libbar.so.debug for the inlined
instance:

 <2><91>: Abbrev Number: 3 (DW_TAG_inlined_subroutine)
    <92>   DW_AT_abstract_origin: <alt 0x1b>
    <96>   DW_AT_low_pc      : 0x1121
    <9e>   DW_AT_high_pc     : 31
    <9f>   DW_AT_call_file   : 1
    <a0>   DW_AT_call_line   : 26
    <a1>   DW_AT_call_column : 15
 <3><a2>: Abbrev Number: 5 (DW_TAG_formal_parameter)
    <a3>   DW_AT_abstract_origin: <alt 0x2c>
    <a7>   DW_AT_location    : 2 byte block: 91 68      (DW_OP_fbreg: -24)
 <3><aa>: Abbrev Number: 5 (DW_TAG_formal_parameter)
    <ab>   DW_AT_abstract_origin: <alt 0x25>
    <af>   DW_AT_location    : 2 byte block: 91 6c      (DW_OP_fbreg: -20)

And here's the DWARF from common.dwz for the abstract instance tree:

 <1><1b>: Abbrev Number: 7 (DW_TAG_subprogram)
    <1c>   DW_AT_name        : (indirect string, offset: 0x18a): add_some_int
    <20>   DW_AT_decl_file   : 1
    <21>   DW_AT_decl_line   : 24
    <22>   DW_AT_decl_column : 1
    <23>   DW_AT_prototyped  : 1
    <23>   DW_AT_type        : <0x14>
    <24>   DW_AT_inline      : 3        (declared as inline and inlined)
 <2><25>: Abbrev Number: 8 (DW_TAG_formal_parameter)
    <26>   DW_AT_name        : a
    <28>   DW_AT_decl_file   : 1
    <29>   DW_AT_decl_line   : 24
    <2a>   DW_AT_decl_column : 19
    <2b>   DW_AT_type        : <0x14>
 <2><2c>: Abbrev Number: 8 (DW_TAG_formal_parameter)
    <2d>   DW_AT_name        : b
    <2f>   DW_AT_decl_file   : 1
    <30>   DW_AT_decl_line   : 24
    <31>   DW_AT_decl_column : 26
    <32>   DW_AT_type        : <0x14>

While processing the common.dwz DIEs GDB sees the DW_AT_decl_file
attributes, and this triggers a read of the file table within
common.dwz, which creates symtabs for any files mentioned, if the
symtabs don't already exist.

But, and this is the important bit, when doing this, GDB is creating a
compunit_symtab for libbar.so.debug, so any symtabs created will be
attached to the libbar.so.debug objfile.

Remember requirement (5), the file list in common.dwz mentions
'foo.c', so even though libbar.so doesn't use 'foo.c' we end up with a
symtab for 'foo.c' created within the compunit_symtab for
libbar.so.debug!

I don't think this is ideal.  This wastes memory and time; we have
more symtabs to search through even if, as I'll discuss below, we
usually end up ignoring these symtabs.

The exact path that triggers this weird symtab creation starts with a
call to 'new_symbol' (dwarf2/read.c) for the DW_TAG_formal_parameter
in the abstract instance tree.  These include DW_AT_decl_file, which
is read in 'new_symbol'.  In 'new_symbol' GDB spots that the
line_header has not yet been read in, so handle_DW_AT_stmt_list is
called which reads the file/line table and then calls
'dwarf_decode_lines' (line_program.c), which then creates symtabs for
all the files mentioned.

This symtab creation issue still exists today in GDB, though I've not
been able to find any real issues that this is causing after commit
a736ff7d886d fixed the issue I'm discussing here.

So, having tricked GDB into creating a misplaced symtab, what problem
did this cause prior to commit a736ff7d886d?

To answer this, we need to take a diversion to understand how a
command like 'list 6450' works.  The two interesting functions are
create_sals_line_offset and decode_digits_list_mode, which is called
from the former.  The create_sals_line_offset is called indirectly
from list_command via the initial call to decode_line_1.

In create_sals_line_offset, if the incoming linespec doesn't specify a
specific symtab, then GDB uses the name of the default symtab to
lookup every symtab with a matching name, this is done with the line:

  ls->file_symtabs
    = collect_symtabs_from_filename (self->default_symtab->filename (),
                                     self->search_pspace);

In our case, when the default symtab is 'foo.c', this is going to
return multiple symtabs, these will include the correct 'foo.c' symtab
from libfoo.so, but will also include the misplaced 'foo.c' symtab
from libbar.so.  This is where the ordering is important.  As list
will only ever list one file, at a later point in this process we're
going to toss out everything except the first result.  So, to trigger
the bug, it is critical that the FIRST result returned here be the
misplaced 'foo.c' symtab from libbar.so.  In the test I try to ensure
this by mentioning libbar.so before libfoo.so when building the
executable, which currently means we get back the misplaced symtab
first, but this could change in the future and wouldn't necessarily
mean that the problem has gone away.

Having got the symtab list GDB then calls decode_digits_list_mode
which iterates over the symtabs and converts them into symtab_and_line
objects, at the heart of which is a call to find_line_symtab, which
checks if a given symtab has a line table entry for the desired line.
If it does then the symtab is returned.  If it doesn't then GDB looks
for another symtab with the same name that does have a line table
entry.  If no suitably named symtab has an exact match, then the
symtab with the closest line above the required line is returned.  If
no symtab has a matching line table entry then find_line_symtab
returns NULL.

Remember, the misplaced symtab was only created as a side effect of
trying to attach the DW_TAG_formal_parameter symbol to a symtab.
The actual line table for libbar.so (in libbar.so.debug) has no line
table entries for 'foo.c'.  What this means is that the line table for
'foo.c' attached to libbar.so.debug is empty.  So normally what
happens is that find_line_symtab will instead find a line table entry
for 'foo.c' in libfoo.so.debug that does have a suitable line table
entry, and will switch GDB back to that symtab, effectively avoiding
the problem.  However, that is not what happens in the bug case.  In
the bug case find_line_symtab returns NULL, which means that
decode_digits_list_mode just uses the original symtab, in this case
the symtab for 'foo.c' from libbar.so.debug.

In the original bug, the code is compiled with -O2, and this
optimisation has left the line table covering the problem file pretty
sparse.  In fact, there are no line table entries for any line after
the line that the user is trying to list.  This is why
find_line_symtab doesn't find a better alternative symtab, and instead
just returns NULL.

In the test I've replicated this by having a comment at the end of the
source file, and asking GDB to list a line within this comment.  The
result is that there are no line table entries for that line in any
'foo.c' symtab, and so find_line_symtab returns NULL.

After decode_digits_list_mode sees the NULL from find_line_symtab, it
just uses the initial symtab.

After this we eventually return back to list_command (cli/cli-cmds.c)
with a list of symtab_and_line objects.  The first entry in this list
is for the symtab 'foo.c' from libbar.so.  In list_command we call
filter_sals which throws away everything but the first entry as all
the symtabs have the same filename (and are in the same program
space).

Using the symtab we build an absolute path to the source file.

Now, if the source is installed locally, GDB performs no additional
checks; we found a symtab, the symtab gave us a source filename, if
the source file exists on disk, then the requires lines are listed for
the user.

But if the source file doesn't exist on disk, then we are going to ask
debuginfod for the source file.  To do that we use two pieces of
information; the absolute path to the source file, which we have; and
the build-id of an objfile, this is the objfile that owns the symtab
we are trying to get the source for.  In this case libbar.so.  And so
we send the build-id and filename to debuginfod.

Now debuginfod isn't going to just serve any file to anyone, that
would be a security issue for the server.  Instead, debuginfod scans
the DWARF and builds up its own model of which objfiles use which
source files, and for a given build-id, debuginfod will only serve
back files that the objfile matching that build-id, actually uses.
So, in this case, when we ask for 'foo.c' from libbar.so, debuginfod
correctly realises the 'foo.c' is not part of libbar.so, and refuses
to send the file back.

And this is how the original bug occurred.

So, why does commit a736ff7d886d fix this problem?  The answer is in
iterate_over_symtabs, which is used by collect_symtabs_from_filename
to find the matching symtabs.

Prior to this commit, iterate_over_symtabs had two phases, first a
call to iterate_over_some_symtabs which walks over compunit_symtabs
that already exist looking for matches, during this phase only the
symtab filenames are considered.  The second phase uses
objfile::map_symtabs_matching_filename to look through the objfiles
and expand new symtabs that match the required name.  In our case, by
the time iterate_over_symtabs is called, all of the interesting
symtabs have already been expanded, so we only perform the filename
check in iterate_over_some_symtabs, this passes, and so 'foo.c' from
libbar.so is considered a suitable symtab.

After commit a736ff7d886d the initial call to
iterate_over_some_symtabs has been removed from iterate_over_symtabs,
and only the objfile::map_symtabs_matching_filename call remains.
This ends up in cooked_index_functions::search (dwarf2/read.c) to
search for matching symtabs.

The first think cooked_index_functions::search does is setup a vector
of CUs to skip by calling dw_search_file_matcher, this then calls
dw2_get_file_names to get the file and line table for a CU, this
function in turn creates a cutu_reader object, passing true for the
'skip_partial' argument to its constructor.

As our 'foo.c' symtab was created from within the dwz extracted DWARF,
then it is associated with the DW_TAG_partial_unit that held the
DW_TAG_subprogram DIEs that were being processed when the misplaced
symtab was original created; this is a partial unit.  As this is a
partial unit, and the skip_partial flag was passed true, the
cutu_reader::is_dummy function will return true.

Back in dw2_get_file_names, if cutu_reader::is_dummy is true then
dw2_get_file_names_reader is never called, and the file names are
never read.  This means that back in dw_search_file_matcher, the file
data, returned from dw2_get_file_names is NULL, and so this CU is
marked to be skipped.  Which is exactly what we want, this misplaced
symtab, which was created for a partial unit and associated with
libbar.so, is skipped and never considered as a possible match.

There is a remaining problem, which is marked in the test with an
xfail.  That is, when the test does the 'list LINENO', GDB still tries
to download the source for 'foo.c' from libbar.so.  The reason for
this is that, while it is true that the initial
collect_symtabs_from_filename call no longer returns 'foo.c' from
libbar.so, when decode_digits_list_mode calls find_line_symtab for the
correct 'foo.c' from libfoo.so, it is still the case that there is no
exact match for LINENO in that symtabs line table.

As a result, GDB looks through all the other symtabs for 'foo.c' to
see if any are a better match.  Checking if another symtab is a
possible better match requires a full comparison of the symtabs source
file name, which in this case triggers an attempt to download the
source file from debuginfod.  Here's the backtrace at the time of the
rogue source download request, which appears as an xfail in the test
presented here:

  #0  debuginfod_source_query (build_id=..., build_id_len=..., srcpath=..., destname=...) at ../../src/gdb/debuginfod-support.c:332
  #1  0x0000000000f0bb3b in open_source_file (s=...) at ../../src/gdb/source.c:1152
  #2  0x0000000000f0be42 in symtab_to_fullname (s=...) at ../../src/gdb/source.c:1214
  #3  0x0000000000f6dc40 in find_line_symtab (sym_tab=..., line=..., index=...) at ../../src/gdb/symtab.c:3314
  #4  0x0000000000aea319 in decode_digits_list_mode (self=..., ls=..., line=...) at ../../src/gdb/linespec.c:3939
  #5  0x0000000000ae4684 in create_sals_line_offset (self=..., ls=...) at ../../src/gdb/linespec.c:2039
  #6  0x0000000000ae557f in convert_linespec_to_sals (state=..., ls=...) at ../../src/gdb/linespec.c:2289
  #7  0x0000000000ae6546 in parse_linespec (parser=..., arg=..., match_type=...) at ../../src/gdb/linespec.c:2647
  #8  0x0000000000ae7605 in location_spec_to_sals (parser=..., locspec=...) at ../../src/gdb/linespec.c:3045
  #9  0x0000000000ae7c7f in decode_line_1 (locspec=..., flags=..., search_pspace=..., default_symtab=..., default_line=...) at ../../src.dev-m/gdb/linespec.c:3167

I think that this might not be what we really want to do here.  After
downloading the source file we'll end up with a filename within the
debuginfod download cache, which will be different for each
objfile (the cache partitions downloads based on build-id).  So if two
symtabs originate from the same source file, but are in two different
objfiles, then, when the source is on disk, the filenames for these
symtabs will be identical, and the symtabs will be considered
equivalent by find_line_symtab.  But when debuginfod is downloading
the source the source paths will be different, and find_line_symtab
will consider the symtabs different.  This doesn't seem right to me.
But I'm going to leave worrying about that for another day.

Given this last bug, I am of the opinion that the misplaced symtab is
likely a bug, though after commit a736ff7d886d, the only issue I can
find is the extra debuginfod download request, which isn't huge.  But
still, maybe just reducing the number of symtabs would be worth it?

But this patch isn't about fixing any bugs, it's about adding a test
case for an issue that was a problem, but isn't any longer.

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

gdb: fix line wrapping in new boxed hints when styling is enabled

I noticed that the startup hint text, the stuff that's placed into a
box, is not line wrapping correctly.  For example:

  $ gdb -nw -nh -eiex 'set width 60'
  ... snip ...

  ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
  ┃ Find the GDB manual online at:                           ┃
  ┃ http://www.gnu.org/software/gdb/documentation/.          ┃
  ┃ For help, type "help".                                   ┃
  ┃ Type "apropos <word>" to search                          ┃
  ┃  for commands related to <word>                          ┃
  ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛

  (gdb)

Notice the final two lines within the box, there's no need to wrap
after the word 'search', plenty more would fit on that line.  And
indeed, if we switch off styling:

  $ gdb -nw -nh -eiex 'set width 60' -eiex 'set style enabled off'
  ... snip ...

  +----------------------------------------------------------+
  | Find the GDB manual online at:                           |
  | http://www.gnu.org/software/gdb/documentation/.          |
  | For help, type "help".                                   |
  | Type "apropos <word>" to search for commands related to  |
  |  <word>                                                  |
  +----------------------------------------------------------+

  (gdb)

That's mostly fixed it, except I still think there's a stray white
space character before '<word>' on the final line.

The fact that the output is wrapped differently with styling on and
off tells me that this is not an intentional choice.

The problems are, I think all in box_one_message (from top.c).  There
are a number of issues.

 1. Each time around the loop we count all escape characters in
    MESSAGE, not just the escape characters up to the point where we
    might wrap the message.  This has the potential to over count the
    escape characters.

 2. When splitting MESSAGE we search for a space character.  This
    search starts based on the terminal width, but neglects to take
    into account any escape characters prior to the split point.

 3. If we split a line after an alternative style has been activated,
    but before the style has been reset, then the border of the box on
    that line is going to be rendered in the alternative style.

 4. When computing what content needs to be moved onto the second
    line, we don't move past the space character (as found in point
    2).

Now it just so happens that issues (1) and (3) can be ignored for now.
The surrounding box is only added (and line wrapping performed) if the
terminal is at least wide enough to fit the documentation URL (plus
box borders).  This means a minimum width of 51 characters. On all
the other lines, any styled output is always to the left of the line,
occurring before character 51.  This means that counting all escape
characters is the same as counting just the escape characters that
will appear before the line break.  And we will never need to line
break part way through some styled text.

Obviously we _could_ fix this code properly, but it's not simple, and
it would all be completely theoretical.  So in this commit I plan to
add an assert that all escape sequences occur within the first 51
characters, then if the above text ever changes we will immediately
know that box_one_message will need to be rewritten.

Fixing issue (2) is pretty easy, this line:

  line = message.substr (0, message.rfind (" ", width));

just needs to be updated to take N_ESCAPE_CHARS into account.  We
currently look for a space after WIDTH characters in MESSAGE, but
MESSAGE also contains escape sequences, so we really need to search in
for a space starting from 'WIDTH + N_ESCAPE_CHARS'.

And fixing (4) is also easy, this line:

  message = message.substr (line.length ());

finds the remainder of MESSAGE based on LINE.  But LINE was all
content up to (but not including) the space character we found.  What
we actually need to do is:

  message = message.substr (line.length () + 1);

To add the assert that I discussed above, I've moved the escape
characters counting code out of the line printing loop.  We now count
the escape characters just once, and assert that these all fit within
the WIDTH, this means they will all appear before any line break.

While making these changes I've also made use of std::move to avoid
copying a string in one place.

Finally, the gdb.base/startup-hints.exp test has been expanded to
cover both styled and non-styled output, as well as a greater range of
terminal widths.

Sync libiberty sources with gcc master version

gdb: hold a target_ops_ref in scoped_finish_thread_state

This commit fixes a use after free issue that was reported here:

  https://inbox.sourceware.org/gdb-patches/68354b98-795a-4b50-9eac-e54aa1d01b9d@simark.ca

This issue was exposed by the gdb.replay/missing-thread.exp test that
was added in this commit:

  commit 8bd08ee92c4a7bf2ad9e29c4da32a276ef2257fc
  Date:   Fri May 16 17:56:58 2025 +0100

      gdb: crash if thread unexpectedly disappears from thread list

It is worth pointing out that the use after free issue existed before
this commit, this commit just introduced a test that exposed the issue
when GDB is run with the address sanitizer.

It has taken a while to get this fix ready for upstream as this fix
depended on the recently committed patch:

  commit 43db8f70d86b2492b79f59342187b919fd58b3dd
  Date:   Thu Oct 23 16:34:20 2025 +0100

      gdbsupport: remove undefined behaviour from (forward_)scope_exit

The problem is that the first commit above introduces a test which
causes the remote target to disconnect while processing an inferior
stop event, specifically, within normal_stop (infrun.c), GDB calls
update_thread_list, and it is during this call that the inferior
disconnects.

When the remote target disconnects, GDB immediately unpushes the
remote target.  See remote_unpush_target and its uses in remote.c.

If this is the last use of the remote target, then unpushing it will
cause the target to be deleted.

This is a problem, because in normal_stop, we have an RAII variable
maybe_finish_thread_state, which is an optional
scoped_finish_thread_state, and in some cases, this will hold a
pointer to the process_startum_target which needs to be finished.

So the order of events is:

  1. Call to normal_stop.

  2. Create maybe_finish_thread_state with a pointer to the current
     remote_target object.

  3. Call update_thread_list.

  4. Remote disconnects, GDB unpushes and deletes the current
     remote_target object.  GDB throws an exception.

  5. The exception propagates back to normal_stop.

  6. The destructor for maybe_finish_thread_state runs, and tries to
     make use of its cached pointer to the (now deleted) remote_target
     object.  Badness ensues.

This bug isn't restricted to normal_stop.  If a remote target
disconnects anywhere where there is a scoped_finish_thread_state in
the call stack then this issue could arise.

I think what we need to do is to ensure that the remote_target is not
actually deleted until after the scoped_finish_thread_state has been
cleaned up.

And so, to achieve this, I propose changing scoped_finish_thread_state
to hold a target_ops_ref rather than a pointer to the target_ops
object.  Holding the reference will prevent the object from being
deleted.

The new scoped_finish_thread_state is defined within its own file, and
is a drop in replacement for the existing class.

On my local machine the gdb.replay/missing-thread.exp test passes
cleanly after this commit (with address sanitizers), but when I test
on some other machines with a more recent Fedora install, I'm still
seeing test failures (both before and after this patch), though not
relating to the address sanitizer (at least, I don't see an error from
the sanitizer).  I don't think these other issues are directly related
to the problem being addressed in this commit, and so I'm proposing
this patch for inclusion anyway.  I'll continue to look at the test
and see if I can fix the other failures too.  Or maybe I'll end up
having to back out the test.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>

Improve the linker's --stats option to record memory use information provided by mallinfo().

Add TOC calculation for XCOFF binary in AIX and remove legacy line number information.

Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca>
Closes https://sourceware.org/bugzilla/show_bug.cgi?id=33606

This is a patch to bring back certain XCOFF reading sections back to the GDB code which was removed during the STABS removal.
This patch also removes the legacy line table calculation for STABS since we no longer will support it.

The issue we removed code that will get us the TOC offset in AIX.
This will now cause regressions.

For example,Consider a code where we create a simple library x as below.

int g_in_lib = 777;

int lib_func() {

        return g_in_lib + 1;

}

int lib_func();

Then we use this library X  in main().

int main() {

        printf ("lib_func() = %d \n", lib_func());

        return 0;

}

If we as of today compile master branch in AIX and try to call lib_func() from GDB we get,

GNU gdb (GDB) 18.0.50.20251112-git
Breakpoint 1, main () at //gdb_tests/main.c:5
5           printf ("lib_func() = %d \n", lib_func());

(gdb) call lib_func()

$1 = 536875277

(gdb) q

which is a garbage value instead of 778.

DWARF will not have any information about TOC to maintain uniformity with other operating system.

TOC (Table Of Contents) is a part of XCOFF/AIX ABI and is required for:
1: Loading shared libraries as we need TOC that contain pointers to access global variables and functions entry points.
2: Function calls like the above call where AIX expects register r2 = pointer to TOC which gives fast access to global data plus an ofset
3: Large code model = TOC solves the fact that PPC64 can't embed large 64 bit addresses.

So we need to get GDB to fetch this even though we only read DWARF debug sections in the XCOFF binary. (AIX uses GCC-13 now which produces only DWARF now.).

In the above case since the toc_offset is not there now we cannot access lib_func() causing the regression.

The patch right now brings back the code required to fetch the same. Once this patch is applied we get,

GNU gdb (GDB) 18.0.50.20251204-git
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64-ibm-aix7.2.0.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.

+------------------------------------------------------------------------------+
| Find the GDB manual online at:                                               |
| http://www.gnu.org/software/gdb/documentation/.                              |
| For help, type "help".                                                       |
| Type "apropos <word>" to search for commands related to <word>               |
+------------------------------------------------------------------------------+
..
Reading symbols from //gdb_tests/main...
(gdb) b main
Breakpoint 1 at 0x10000530: file //gdb_tests/main.c, line 5.
(gdb) r
Starting program: /gdb_tests/main

Breakpoint 1, main () at //gdb_tests/main.c:5
5           printf ("lib_func() = %d \n", lib_func());
(gdb) call lib_func()
$1 = 778
(gdb) q
A debugging session is active.

        Inferior 1 [process 7340312] will be killed.

Quit anyway? (y or n) y

Also some clean ups of code and additions, they are:
1: Replaced old APIs like bfd_map_over_sections with gdb_bfd_sections() and range-based loops.
2: Used helpers like obstack_strndup instead of manual allocation like changing p = (char *) obstack_alloc (&objfile->objfile_obstack, and strncpy (p, symbol->n_name, E_SYMNMLEN);
to *name = obstack_strndup(&objfile->objfile_obstack, symbol->n_name, E_SYMNMLEN);
3: Removed unused macros as unnecessary global variables as you mentioned
4: Replaced perror_with_name with error() and bfd_errmsg. See: error(_("reading symbol table: %s"), bfd_errmsg(bfd_get_error()));
5: Also used bfd_get_section_alloc_size().
6: Eliminated the xcoff_find_targ_sec_arg struct used in GDB 17 or earlier because it is no longer necessary for context handling.
7: Eliminated the find_targ_sec () used in GDB 17 or earlier since we find the bfd_sect in xcoff_secnum_to_sections().

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

Automatic date update in version.in

[gdb] Fix heap-buffer-overflow in args_complete_p

PR gdb/33754 reports a heap-buffer-overflow args_complete_p, while checking
the while condition:
...
  while (*input != '\0')
    {
      input = skip_spaces (input);
      ...
      ++input;
    }
...

The problem can be reproduced by calling args_complete_p (" ").  The following
happens:
- at function entry, input == " "
- the while loop is entered
- after skip_spaces, input == ""
- after the ++input at the end of the loop body, input points past the
  terminating '\0'
- while checking the while condition, *input does an out-of-bound access.

Add a unit test exercising this minimal example, fix this by checking
input after skip_spaces, and add an assert to detect the heap-buffer-overflow
without Address Sanitizer.

Another heap-buffer-overflow can be found by calling args_complete_p ("\"\\").
In this case, the following happens:
- at function entry, input == "\"\\"
- the while loop is entered
- dquote is set to true and input == "\\"
- the while loop is entered a second time
- the condition *input == '\\' && strchr ("\"\\", *(input + 1)) != nullptr
  evaluates to true (which is not trivial to understand, because the char
  found in the string "\"\\" is '\0'), leading to two increments of input,
  again making input point past the terminating '\0'.

Fix this by checking for *(input + 1) == '\0', and likewise add a unit test.

Tested on x86_64-linux.

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

[gdb] Fix confusing string in command_line_append_input_line

While writing a unit test for PR33754, I ran into an std::string s where
where strlen (s.data ()) != s.size ().

I tracked this down to command_line_append_input_line, where we do:
...
      /* Copy whole line including terminating null, and we're
 done.  */
      cmd_line_buffer.append (rl, len + 1);
...

As example, consider string s:
...
std::string s = "";
s.append ("", 1);
...

Initially, the string is empty, and we have:
- strlen (s.data ()) == 0
- s.size () == 0

After appending '\0', we have:
- strlen (s.data ()) == 0
- s.size () == 1

While I suppose this is legal, I think it's better to avoid this type of
string, since it tends to cause confusion and off-by-one errors.

And AFAIU, in this case the '\0' is not necessary, it's a remnant of using C
strings.

Fix this by simply appending rl.

Approved-By: Tom Tromey <tom@tromey.com>
Tested on x86_64-linux.

gdb/dwarf: remove redundant DW_AT_containing_type checks

I noticed that some places first check if a DIE has a
DW_AT_containing_type attribute, like so:

  if (dwarf2_attr (type_die, DW_AT_containing_type, type_cu) == NULL)
    return NULL;

and then call function die_containing_type, which does the same check,
erroring out if the attribute does not exist.  The second check is
redundant in these cases.  There is only one call site that does not do
a check before, for which the error might be relevant.

Remove the error call from die_containing_type, making it return nullptr
if the DIE does not have a DW_AT_containing_type attribute, and remove
the redundant checks in all but that one call site.

For that one call site, error out if the return value of
die_containing_type is nullptr.  I changed the error message to be a
little more precise.

There is no expected behavior change, apart from the content of that
error message.

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

sim: re-generate Makefile.in

Makefile.am was updated by the new year procedure, but Makefile.in
should have been re-generated as well, do it now.

Change-Id: I82f36aebbd9ebe33f37eb4af71933ee84c257f38

gnulib: re-generate Makefile.in

Makefile.am was updated by the new year procedure, but Makefile.in
should have been regenerated as well, do it now.

Change-Id: Id56fcce79a5d6efaaeca219d5809011af187787f

[gdbsupport] Fix get_print_cell use in threads

PR gdb/33753 reports problems with get_print_cell when used from threads.

Fix this by making the two static variables in get_print_cell thread_local.

Tested on x86_64-linux.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33753

gdb: remove smash_to_memberptr_type

smash_to_memberptr_type is only used by lookup_memberptr_type, remove it
and inline its code there.

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

gdb: remove make_cv_type typeptr parameter

It is always passed nullptr.

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

gdb: remove make_function_type

We now have make_function_type and lookup_function_type exposed by
gdbtypes.h, which do essentially the same thing.  Remove
make_function_type, inlining its code inside create_function_type.
Change all other callers of make_function_type to use
lookup_function_type instead.

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

gdb: remove make_function_type typeptr parameter

In a few places, it is passed nullptr, meaning that we allocate a type
using a type allocator derived from the return type.

In the

  -> lookup_function_type_with_arguments
    -> create_function_type
      -> make_function_type

and

  -> lookup_function_type
    -> create_function_type
      -> make_function_type

paths, we create an allocator based on the return type, pass it down,
and create a type using that, which then gets passed to
make_function_type.  Instead, we can let make_function_type allocate the
type based on the return type.

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

gdb: remove make_reference_type typeptr parameter

It is always passed nullptr.

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

gdb: remove make_pointer_type typeptr parameter

It is always nullptr.

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

gdb: make create_function_type static

It is only used within gdbtypes.c.

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

Fix check-whitespace complaint

check-whitespace complaint about a trailing empty line in
gdb/dwarf2/cu.c.  This fixes it.

Reindent gdb.ada tests

Various gdb.ada tests had incorrect indentation.  This patch reformats
these.  It was written by script.

Small cleanup to interpreter initialization

interp::inited is currently public, because interp_set does the task
of making sure the interpreter is only initialized a single time.
However, the interpreter can do this job itself, and this member can
be private.

Remove two "unsupported" tests from gdb.dwarf2/imported-unit.exp

gdb.dwarf2/imported-unit.exp yields two "unsupported" results but then
carries on.

These tests look for psymtabs, which haven't been used by the DWARF
reader since the introduction of the cooked index.

This patch removes these tests and also the supporting function
psymtabs_p, which is no longer used.

gdb: remove context_stack::static_link

I don't think it's needed to record this information in the
context_stack structure.  The only user is the DWARF reader, where it
can very well be a local variable.

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

Simplify linespec.c:collect_info

I noticed that linespec has a subclass of collect_info that would be
easily replaced by a boolean.  This patch cleans up this area by
removing the subclass, adding a constructor to collect_info, and
removing an unnecessary structure type used by it.

Regression tested on x86-64 Fedora 40.

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

[gdb/testsuite] Fix gdb.base/watchpoint-adjacent.exp with m32

PR testsuite/33727 reports the following failure with test-case
gdb.base/watchpoint-adjacent.exp and i686-linux (or, x86_64-linux and target
board unix/-m32):
...
(gdb) continue^M
Continuing.^M
watchpoint-adjacent-type_ll: watchpoint-adjacent.c:63: main: \
  Assertion `(((uintptr_t) &obj.a) & 0x7) == 0' failed.^M
^M
Program received signal SIGABRT, Aborted.^M
0xb7fc5579 in __kernel_vsyscall ()^M
(gdb) FAIL: $exp: var_type=type_ll: test= a {a b} : rwatch_first=true: \
  continue to breakpoint: prepare for read test
...

The problem is that the test-case expects 8-byte aligned data as an effect of
using long long, but long long has an alignment of 4 bytes [1].

Fix this by using __attribute__((aligned(8))).

After fixing this, we find one remaining failure.  This has been filed as
PR breakpoints/33762.

Tested on x86_64-linux with target boards unix/-m64 and unix/-m32.

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

[1] https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-malign-double

gdb/dwarf: rename dwarf2_start_subfile to dwarf2_cu::start_subfile

Rename dwarf2_start_subfile to dwarf2_cu::start_subfile.  This
refactor continues the work started in the previous commit.

There should be no user visible changes after this commit.

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

gdb/dwarf: move subfile and symtab creation into dwarf2_cu method

There are two places in the dwarf2/ code where we create subfiles and
symtabs for the entries in a dwarf2_cu's line_header.  The code in
each location is basically the same.

Move this code into a new dwarf2_cu member function.

In dwarf2/read.c the existing code had an additional task; this is
left in dwarf2/read.c in its own loop immediately after the call to
the new member function.

There should be no user visible changes after this commit.

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

gdb/dwarf: remove the line_header argument from dwarf2_start_subfile

As with the previous two commits, this commit removes the line_header
argument from dwarf2_start_subfile.  This function already takes a
dwarf2_cu argument, and the line_header passed in is always the line
header pointed to by the dwarf2_cu argument, so lets just access the
line header through the dwarf2_cu.

As dwarf2_start_subfile relies on the dwarf2_cu always being non-NULL,
I've converted the dwarf2_cu argument from a pointer to a reference.
The alternative was adding an assert within dwarf2_start_subfile that
the pointer was not NULL.

There should be no user visible changes after this commit.

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

gdb/dwarf: remove m_line_header from lnp_state_machine class

Following on from the previous commit, this commit remove
m_line_header from the lnp_state_machine class.  The lnp_state_machine
class already holds m_cu, a dwarf2_cu, and the m_line_header was
always just m_cu->line_header, so instead of holding both of these
separately, lets just hold m_cu, and access the line header through
that.

There should be no user visible changes after this commit.

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

gdb/dwarf: remove line_header parameter from dwarf2_decode_lines

The function declaration for dwarf2_decode_lines is:

  void dwarf_decode_lines (struct line_header *lh, struct dwarf2_cu *cu,
                           unrelocated_addr lowpc, bool decode_mapping)

However, it is always the case that:

  lh == cu->line_header

I propose that we simplify the dwarf_decode_lines signature by
removing the line_header parameter.  The same is true for
dwarf_decode_lines_1, which is only called from dwarf_decode_lines.

I'm proposing this change because I was looking through the DWARF
code, trying to understand how symtabs are created, and this extra
complexity just makes things harder to understand: what is the
relationship between the line_header (LH) and dwarf2_cu (CU)
parameters?  When would we ever want to process a line_header other
than the one attached to CU? (answer: never, and we don't).  This
simplification makes things easier to understand (IMHO).
There should be no user visible changes after this commit.

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

Automatic date update in version.in

gas: dw2gencfi: reset reloc to TC_PARSE_CONS_RETURN_NONE for [su]leb128

Some consumers, like SFrame generation logic in GAS, may want to check
reloc value (without qualifying by e->type) as a part of their
admissibility criteria.  Setting reloc to TC_PARSE_CONS_RETURN_NONE for
these CFI escape expr nodes for [su]leb128 keeps the admissibility
checks simple and generic.

Previous discussion here:
https://sourceware.org/pipermail/binutils/2025-December/146807.html

gas/
* gas/dw2gencfi.c (dot_cfi_escape): Set reloc to
TC_PARSE_CONS_RETURN_NONE.