gdb/testsuite: Fix doc comment in allow_aarch64_sme_tests

The comment says that it returns 0 if the target supports SME and 1 if
it doesn't, but it actually does the opposite.  The code does the right
thing, so fix the comment.

gdb/record: Support fense.tso, zicond, bitmanip, sinval and zihintntl in RISC-V

Added record-full support for these extensions.

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

Fix some indentation in rust-lang.c

I noticed some incorrect indentation in rust-lang.c.  This fixes it.

[gdbsupport] Clean whitespace

Clean whitespace issues in ax.def and rsp-low.cc.

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

[gdbsupport] Handle Makefile.in and unordered_dense in .gitattributes

Unset the whitespace attribute in .gitattributes for:
- Makefile.in (because it's generated), and
- unordered_dense/* (because they're imported).

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

gdb/guile: remove support for Guile < 2.2

I propose to remove the code in guile/scm-ports.c supporting Guile <
2.2.  The rationale is:

 - The code within USING_GUILE_BEFORE_2_2 amounts to about half of the
   file, it makes it much more complicated than it would be otherwise.
   I'm trying to investigate PR 29825 [1] and this is getting in the
   way.
 - Guile 2.2, which would now be the baseline for what we require, is
   now 8 years old.  Guile 2.2 is legacy (the current stable branch is
   3.0), but it is still actively packaged [2][3].
 - The Guile support code doesn't receive as much contribution, testing
   and love as the Python support code, for instance.  We don't have
   cycles to spare to support an obsolete version of Guile.

This patch removes the USING_GUILE_BEFORE_2_2 define and all the
portions of code within `#if USING_GUILE_BEFORE_2_2`.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=29825
[2] https://packages.debian.org/sid/guile-2.2-dev
[3] https://archlinux.org/packages/extra/x86_64/guile2.2/

Change-Id: I926e79cde9835567eb3b7e3d22db402c841b79d7
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

Print more template parameters with ptype

This bug points out that a template parameter that is a constant is
not printed by 'ptype' -- in fact, only type parameters are displayed.
However, there's no real reason for this, and any template parameter
that the DWARF reader can turn into a symbol should be printable.

Note that some parameters are still missing from the DWARF; see the
kfails in the test for details.

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

[gdb/testsuite] Fix ERROR: can't read _line_unit_advertised_version: no such variable

With test-case gdb.base/until-trailing-insns.exp I run into:
...
ERROR: tcl error code TCL READ VARNAME
ERROR: can't read "_line_unit_advertised_version": no such variable
    while executing
"if {$_line_unit_advertised_version == "default"} {
            set _line_unit_advertised_version $_line_unit_version
        }"
...

Fix this by using the correct variable name in two places in Dwarf::lines:
use _line_unit_advertised_version instead of _line_advertised_unit_version.

Tested on x86_64-linux.

[gdb/symtab] Fix DW_TAG_member regression

On openSUSE Leap 15.6 x86_64, with gcc 7 and test-case
gdb.base/condbreak-multi-context.exp I run into:
...
(gdb) print aaa^M
$3 = <optimized out>^M
(gdb) FAIL: $exp: start_before=true: scenario_1: print aaa
...

This is a regression since commit 86ac8c54623 ("Convert
lookup_symbol_in_objfile").

Likewise in test-cases gdb.cp/m-static.exp and gdb.cp/namespace.exp.

The failure is specific to using Dwarf v4:
- using target board unix/gdb:debug_flags=-gdwarf-5 fixes it
- using target board unix/gdb:debug_flags=-gdwarf-4 on Tumbleweed (with gcc 15
  and Dwarf v5 default) triggers it

The variable we're trying to print, A::aaa is a static const int member:
...
class A : public Base
{
public:
  static const int aaa = 10;
  ...
};
...

With Dwarf v5, we have this DIE:
...
<2><356>: Abbrev Number: 2 (DW_TAG_variable)
    <357>   DW_AT_name        : aaa
    <35c>   DW_AT_linkage_name: _ZN1A3aaaE
    <364>   DW_AT_external    : 1
    <364>   DW_AT_accessibility: 1      (public)
    <364>   DW_AT_declaration : 1
    <364>   DW_AT_const_value : 10
...
and the cooked index contains these corresponding entries:
...
    [45] ((cooked_index_entry *) 0x7facf0004730)
    name:       _ZN1A3aaaE
    canonical:  _ZN1A3aaaE
    qualified:  _ZN1A3aaaE
    DWARF tag:  DW_TAG_variable
    flags:      0x4 [IS_LINKAGE]
    DIE offset: 0x356
    parent:     ((cooked_index_entry *) 0)
    [52] ((cooked_index_entry *) 0x7facf0004700)
    name:       aaa
    canonical:  aaa
    qualified:  A::aaa
    DWARF tag:  DW_TAG_variable
    flags:      0x0 []
    DIE offset: 0x356
    parent:     ((cooked_index_entry *) 0x7facf00046d0) [A]
...

With Dwarf v4, we have instead the following DIE:
...
 <2><350>: Abbrev Number: 3 (DW_TAG_member)
    <351>   DW_AT_name        : aaa
    <35b>   DW_AT_external    : 1
    <35b>   DW_AT_accessibility: 1      (public)
    <35c>   DW_AT_declaration : 1
    <35c>   DW_AT_const_value : 4 byte block: a 0 0 0
...
and there are no corresponding entries.

Fix this by adding an entry:
...
    [47] ((cooked_index_entry *) 0x7f5a24004660)
    name:       aaa
    canonical:  aaa
    qualified:  A::aaa
    DWARF tag:  DW_TAG_member
    flags:      0x0 []
    DIE offset: 0x350
    parent:     ((cooked_index_entry *) 0x7f5a24004630) [A]
...

Add a regression test in the form of a dwarf assembly test-case printing the
value of variable A::aaa.

In the test-case, for A::aaa, DW_FORM_flag is used to encode
DW_AT_declaration.  In v1 of this patch that mattered (because of using
has_hardcoded_declaration in abbrev_table::read), but that's no longer the
case.  Nevertheless, also add an A::bbb using FORM_flag_present for
DW_AT_declaration (and while we're at it, DW_AT_external as well).

Also add two variants, for which <optimized out> is printed:
- A::ccc: a variant with DW_AT_location instead of DW_AT_const_value, and
- A::ddd: a variant without external.
This behavior is not part of the regression.  I've reproduced it using a
system gdb based on 14.2.  It's also not specific to using the cooked index,
it reproduces with -readnow as well.

Tested on x86_64-linux.

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

[gdb/symtab] Bail out for too short line header

The Free Pascal Compiler fpc supports generating different versions of DWARF:
...
$ fpc -h
Free Pascal Compiler version 3.2.2 [2025/09/10] for x86_64
  ...
      -gw        Generate DWARFv2 debug information (same as -gw2)
      -gw2       Generate DWARFv2 debug information
      -gw3       Generate DWARFv3 debug information
      -gw4       Generate DWARFv4 debug information (experimental)
...

The v4 support is experimental, and indeed the line number information is
broken (missing maximum_operations_per_instruction field in the .debug_line
header), so setting a breakpoint on a line number is not possible:
...
$ fpc -gw4 hello.pas
  ...
$ gdb -q hello
Reading symbols from hello...
(gdb) b hello.pas:8
No compiled code for line 8 in file "hello.pas".
Make breakpoint pending on future shared library load? (y or [n])
...

The brokenness is detected by llvm-dwarfdump (second warning):
...
$ llvm-dwarfdump -debug-line hello
hello: file format elf64-x86-64

.debug_line contents:
debug_line[0x00000000]
warning: parsing line table prologue at offset 0x0 found opcode base of 0. \
  Assuming no standard opcodes
warning: unknown data in line table prologue at offset 0x0: parsing ended (at \
  offset 0x00000017) before reaching the prologue end at offset 0x2a
...

Likewise, detect the situation the second warning describes in
dwarf_decode_line_header, getting us instead:
...
(gdb) b hello.pas:8
❌malformed line number program header, advertised length does not match \
  actual length
(gdb)
...

Tested on x86_64-linux.

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

Automatic date update in version.in

[gdb] Fix typos in gdb/dwarf2

Fix the following typos:
...
gdb/dwarf2/cooked-index-shard.c:296: re-use ==> reuse
gdb/dwarf2/read-gdb-index.c:629: re-use ==> reuse
gdb/dwarf2/read.c:2399: re-using ==> reusing
gdb/dwarf2/read.c:11692: endianity ==> endianness
gdb/dwarf2/read.c:11694: endianity ==> endianness
gdb/dwarf2/read.c:11696: endianity ==> endianness
gdb/dwarf2/read.c:11709: endianity ==> endianness
...

Add aranges to the ignore list.

Also replace readin by "read_in".

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

[gdb] Clean whitespace in *.ac and *.m4 files

This is the result of:
...
$ git rm -f $(find gdb* -name "*.ac")
$ git rm -f $(find gdb* -name "*.m4")
$ git commit -a -m tmp
$ git revert HEAD
$ git rebase --whitespace=fix HEAD^
$ git reset --soft HEAD^
$ git commit --amend
...
and running autoreconf -f in directories gdb, gdb/testsuite, gdbsupport and
gdbserver.

Tested on x86_64-linux.

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

[gdb] Handle *.ac and *.m4 files in .gitattributes

Since commit 52ca3d3fe61 ("toplevel: unify the GCC and GDB/binutils .editorconfig
files"), .editorconfig has settings for .ac and .m4 files:
...
[*.{ac,m4}]
indent_style = tab
indent_size = 2
trim_trailing_whitespace = true
...

There are no setting for those files in .gitattributes, so the whitespace
attribute defaults to trailing-space (shorthand for blank-at-eol,
blank-at-eof) and space-before-tab.

Since according to .editorconfig the indentation style is tab, add
indent-with-non-tab as well.

Since aclocal.m4 is generated, unset the whitespace attribute.  Likewise for
configure.

Probably, this eventually needs to be added to root level .gitattributes, but
for now try this in gdb*/.gitattributes.

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

gdb/ser-unix: work around conflicting types for tcflag_t

When trying to cross-compile GDB to sparc-buildroot-linux-uclibc, I get:

      CXX    ser-unix.o
    In file included from /data1/smarchi/many-buildroots/toolchains/sparc/sparc-buildroot-linux-uclibc/sysroot/usr/include/termios.h:39,
                     from /home/smarchi/src/binutils-gdb/gdb/ser-unix.c:51:
    /data1/smarchi/many-buildroots/toolchains/sparc/sparc-buildroot-linux-uclibc/sysroot/usr/include/bits/termios.h:26:22: error: conflicting declaration ‘typedef unsigned int tcflag_t’
       26 | typedef unsigned int tcflag_t;
          |                      ^~~~~~~~
    In file included from /home/smarchi/src/binutils-gdb/gdb/ser-unix.c:46:
    /data1/smarchi/many-buildroots/toolchains/sparc/sparc-buildroot-linux-uclibc/sysroot/usr/include/asm/termbits.h:13:25: note: previous declaration as ‘typedef long unsigned int tcflag_t’
       13 | typedef unsigned long   tcflag_t;
          |                         ^~~~~~~~

uClibc and the kernel don't agree on the definition of tcflag_t for this
architecture.  Here' uClibc [1]:

    typedef unsigned int tcflag_t;

And here's the kernel [2]:

    #if defined(__sparc__) && defined(__arch64__)
    typedef unsigned int tcflag_t;
    #else
    typedef unsigned long tcflag_t; <--- that branch is take
    #endif

glibc [3] has the same definition as uClibc, so we would get the same
problem.

I propose to work around this the same way as we handle differences in
the termios structure, by renaming the version from the kernel.

I opened a bug on the glibc bugzilla [4] to ask if this is something
that would need to be fixed on the libc side, but in the mean time we
need to work around it.

[1] https://github.com/kraj/uClibc/blob/ca1c74d67dd115d059a875150e10b8560a9c35a8/libc/sysdeps/linux/sparc/bits/termios.h#L26
[2] https://github.com/torvalds/linux/blob/e7c375b181600caf135cfd03eadbc45eb530f2cb/arch/sparc/include/uapi/asm/termbits.h#L7-L11
[3] https://gitlab.com/gnutools/glibc/-/blob/efc8642051e6c4fe5165e8986c1338ba2c180de6/bits/termios.h#L104
[4] https://sourceware.org/bugzilla/show_bug.cgi?id=33643

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

gdb/testsuite: Fix gdb/testsuite/gdb.arch/riscv-unwind-long-insn.S

The .size calculation for bar's function incorrectly uses the label func
instead of bar.  Fix it.

Signed-off-by: Yu-Cheng Liang <yclwlcy@gmail.com>

Rewrite the @selector code

This rewrites the Objective-C @selector implementation in c-exp.y,
following a couple general comments in the patch supplied for
bug 20503.

I suspect something else changed in the Objective-C runtime, though,
as most of the examples in that bug still do not work, even though
this series (I believe) addresses all the same points.

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

Avoid crash with "NSString" literals

Evaluating an Objective-C "NSString" literal will cause gdb to crash.
This patch fixes the crash.

I think the result here still isn't correct -- I see a warning from
the runtime ("autorelease called without pool for object") with the
new code.

However, not crashing is an improvement on its own.

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

Remove a couple Objective-C expression helpers

The Objective-C expression code has a couple of helper functions with
just a single caller.  This patch unifies them with the appropriate
evaluate method.

Rename lookup_struct_typedef

The helper function lookup_struct_typedef is only ever called with
"noerr=1".  This patch removes the parameter, changes the name, and
removes some unnecessary code.

Minor fixes to make gdb.objc tests pass

Once the gdb.objc tests compile, you can see that they do not pass.
The issue is primarily that they are over-strict about line numbers.
This fixes the problem by replacing these line numbers with $decimal.

Make the gdb.objc tests compile

The gdb.objc tests haven't compiled in years.  This patch fixes this,
based on a comment in bug 31671.

I don't know whether this approach works with the clang implementation
of Objective-C.  However, it does work with GCC, provided that
gnustep-base is installed.

Reformat gdb.objc tests

This patch applies some minor formatting changes and cleanups to the
gdb.objc tests.

Require GNAT 8 for gdb.ada/recursive-access.exp

Tom pointed out that gdb.ada/recursive-access.exp causes a compiler
crash with gcc 7.5.  This patch adjusts the test case to skip testing
in this case.

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

Synchronize the dwarf2.h and dwarf2.def files with their gcc counterparts, bringing the definitions of DW_AT_language_name and DW_AT_language_version.  Add code to binutils/dwarf.c to display these attributes.

x86: traverse loc_hash_table only if used

Traverse x86 loc_hash_table only if it is used.

* elf32-i386.c (elf_i386_output_arch_local_syms): Traverse
loc_hash_table only if has_loc_hash_table is set.
* elf64-x86-64.c (elf_x86_64_output_arch_local_syms): Likewise.
* elfxx-x86.c (_bfd_elf_x86_get_local_sym_hash): Set
has_loc_hash_table.
(_bfd_x86_elf_late_size_sections): Traverse loc_hash_table only
if has_loc_hash_table is set.
* elfxx-x86.h (elf_x86_link_hash_table): Move plt0_pad_byte and
add has_loc_hash_table.

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

mips regression fixes

Commit 54fbc12d64 introduced mips-linux testsuite regressions.
+FAIL: MIPS magic __ehdr_start symbol test 1 (o32)
+FAIL: PR ld/21334 MIPS GOT16 relocation in static binary
+FAIL: PR ld/21375 in SVR4 executable (hidden)
These are all assertion failures in mips_elf_sort_hash_table
  BFD_ASSERT (hsd.max_local_dynindx <= htab->root.local_dynsymcount + 1);

This was a pre-existing problem exposed by commit 54fbc12d64.

* elfxx-mips.c (mips_elf_sort_hash_table): Properly test for
no dynsyms.

Automatic date update in version.in

gdb, gdbserver: propagate use of target_desc unique pointers

Propagate the use of target_desc unique pointers further.  Basically,
avoid releasing target_desc objects, except in some spots in gdbserver
(e.g. netbsd) where we don't currently have a persistent container for
created target descriptions (and the target desc just leaks).  Introduce
const_target_desc_up to change some `const target_desc *` to a unique
pointer without loss of constness.

Architectures that use the old regformats/regdat.sh don't need to be
changed, because their target_desc objects are statically allocated in
the generated files.

I was able to built-test these native configs:

 - Linux AArch64
 - Linux ARC
 - Linux AMD64
 - Linux ARM
 - Linux LoongArch
 - Linux M68K
 - Linux Microblaze
 - Linux MIPS (32 and 64)
 - Linux or1k
 - Linux PPC (32 and 64)
 - Linux RISC-V
 - Linux s390x
 - Linux SH4
 - Linux Sparc (32 and 64)
 - Linux Xtensa
 - FreeBSD AMD64
 - NetBSD AMD64
 - Windows i686
 - Windows AMD64

For the rest, I did my best by staring at the code long enough.  I
probably missed or messed some spots, but that shouldn't be difficult to
fix.

Change-Id: I8db8790c57942edd2bfe890987157e2dc0c67879
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>

gdbserver: remove leftovers from tic6x target_desc selftests

Commit 9a5d3e6c4a50 ("gdb: remove tic6x .dat files") removed the .dat
files that were used solely for selftests in linux-tic6x-low.cc.
However, I forgot to remove the things that depended on that in
linux-tic6x-low.cc (or rather, I put them in the wrong patch).  As-is,
linux-tic6x-low.cc will certainly no build, because function
selftests::tdesc::tic6x_tdesc_test is not defined anywere.  Remove those
remaining bits.

Change-Id: I3f307a6ae4848ef748e2a685a870b662c88180b5

Merge eval_op_objc_msgcall into objc_msgcall_operation::evaluate

objc_msgcall_operation::evaluate is the only caller of
eval_op_objc_msgcall.  This patch merges them into a single function.

This is just a leftover from the big expression change from several
years ago.  There are probably still many such cases remaining.

Rename some locals in objc_msgcall_operation::evaluate

This renames a couple of local variables in
objc_msgcall_operation::evaluate, in preparation for the next patch.
This is done separately because the next patch is pretty messy and
this makes it a little simpler.

Use a vector in objc_msgcall_operation::evaluate

This changes objc_msgcall_operation::evaluate to use a std::vector
rather than XALLOCAVEC.  alloca is bad and should generally be
avoided; and anyway there's no justification for it here.

Fix crash from eval_op_objc_msgcall

Trying to evaluate an Objective-C message call will cause gdb to
crash.  This happens because this code was not correctly updated when
call_function_by_hand was changed to accept an array_view, and the
trailing NULL pointer was no longer required.

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

Add support for new Ada task state

GNAT recently added support for asynchronous aborts of tasks blocked in
calls to Ada.Synchronous_Task_Control.Suspend_Until_True. That GNAT
change added a new value to the Task_States enumerated type. This patch
adds the corresponding value to task_states.

gdb/dwarf: clarify meaning dwarf2_per_cu::{m_section,m_sect_off,m_length} in presence of DWO file

The comments above these fields are almost accurate.  If a unit in a DWO
file has a corresponding skeleton in the main file, these fields
describe the skeleton in the main file.  However, it's missing the
detail that if the unit in the DWO file does not have a corresponding
skeleton in the main file, then the fields describe the unit in the DWO
file.  Update the comments to reflect that.

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

gdb/dwarf: use dwarf2_per_cu::ref_addr_size in one spot

I noticed this spot that could use dwarf2_per_cu::ref_addr_size, instead
of implementing the same logic.

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

gdb/dwarf: store addr/offset/ref_addr sizes in dwarf2_per_cu

New in v2:

 - make the test try with indexes by default
 - using uint8_t instead of unsigned char

In some specific circumstances, it is possible for GDB to read a type
unit from a .dwo file without ever reading in the section of the stub in
the main file.  In that case, calling any of these methods:

  - dwarf2_per_cu::addr_size()
  - dwarf2_per_cu::offset_size()
  - dwarf2_per_cu::ref_addr_size()

will cause a crash, because they will try to read the unit header from
the not-read-in section buffer.  See the previous patch for more
details.

The remaining calls to these methods are in the loc.c and expr.c
files.  That is, in the location and expression machinery.  It is
possible to set things up to cause them to trigger a crash, as shown by
the new test, when running it with the cc-with-gdb-index board:

    $ make check TESTS="gdb.dwarf2/fission-type-unit-locexpr.exp" RUNTESTFLAGS="--target_board=cc-with-gdb-index"
    Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.dwarf2/fission-type-unit-locexpr.exp ...
    ERROR: GDB process no longer exists

The backtrace at the moment of the crash is:

    #0  0x0000555566968b1f in bfd_getl32 (p=0x78) at /home/simark/src/binutils-gdb/bfd/libbfd.c:846
    #1  0x00005555642e51b7 in read_initial_length (abfd=0x7d1ff1eb0e40, buf=0x78 <error: Cannot access memory at address 0x78>, bytes_read=0x7bfff09daca0, handle_nonstd=true)
        at /home/simark/src/binutils-gdb/gdb/dwarf2/leb.c:92
    #2  0x00005555647ca584 in read_unit_head (header=0x7d0ff1e06c70, info_ptr=0x78 <error: Cannot access memory at address 0x78>, section=0x7c3ff1dea7d0, section_kind=ruh_kind::COMPILE)
        at /home/simark/src/binutils-gdb/gdb/dwarf2/unit-head.c:44
    #3  0x000055556452df18 in dwarf2_per_cu::get_header (this=0x7d0ff1e06c40) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18531
    #4  0x000055556452e10e in dwarf2_per_cu::addr_size (this=0x7d0ff1e06c40) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18544
    #5  0x0000555564314ac3 in dwarf2_locexpr_baton_eval (dlbaton=0x7bfff0c9a508, frame=..., addr_stack=0x7bfff0b59150, valp=0x7bfff0c9a430, push_values=..., is_reference=0x7bfff0d33030)
        at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1593
    #6  0x0000555564315bd2 in dwarf2_evaluate_property (prop=0x7bfff0c9a450, initial_frame=..., addr_stack=0x7bfff0b59150, value=0x7bfff0c9a430, push_values=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1668
    #7  0x0000555564a14ee1 in resolve_dynamic_field (field=..., addr_stack=0x7bfff0b59150, frame=...) at /home/simark/src/binutils-gdb/gdb/gdbtypes.c:2758
    #8  0x0000555564a15e24 in resolve_dynamic_struct (type=0x7e0ff1f02550, addr_stack=0x7bfff0b59150, frame=...) at /home/simark/src/binutils-gdb/gdb/gdbtypes.c:2839
    #9  0x0000555564a17061 in resolve_dynamic_type_internal (type=0x7e0ff1f02550, addr_stack=0x7bfff0b59150, frame=..., top_level=true) at /home/simark/src/binutils-gdb/gdb/gdbtypes.c:2972
    #10 0x0000555564a17899 in resolve_dynamic_type (type=0x7e0ff1f02550, valaddr=..., addr=0x4010, in_frame=0x7bfff0d32e60) at /home/simark/src/binutils-gdb/gdb/gdbtypes.c:3019
    #11 0x000055556675fb34 in value_from_contents_and_address (type=0x7e0ff1f02550, valaddr=0x0, address=0x4010, frame=...) at /home/simark/src/binutils-gdb/gdb/value.c:3674
    #12 0x00005555666ce911 in get_value_at (type=0x7e0ff1f02550, addr=0x4010, frame=..., lazy=1) at /home/simark/src/binutils-gdb/gdb/valops.c:992
    #13 0x00005555666ceb89 in value_at_lazy (type=0x7e0ff1f02550, addr=0x4010, frame=...) at /home/simark/src/binutils-gdb/gdb/valops.c:1039
    #14 0x000055556491909f in language_defn::read_var_value (this=0x5555725fce40 <minimal_language_defn>, var=0x7e0ff1f02500, var_block=0x7e0ff1f025d0, frame_param=...)
        at /home/simark/src/binutils-gdb/gdb/findvar.c:504
    #15 0x000055556491961b in read_var_value (var=0x7e0ff1f02500, var_block=0x7e0ff1f025d0, frame=...) at /home/simark/src/binutils-gdb/gdb/findvar.c:518
    #16 0x00005555666d1861 in value_of_variable (var=0x7e0ff1f02500, b=0x7e0ff1f025d0) at /home/simark/src/binutils-gdb/gdb/valops.c:1384
    #17 0x00005555647f7099 in evaluate_var_value (noside=EVAL_NORMAL, blk=0x7e0ff1f025d0, var=0x7e0ff1f02500) at /home/simark/src/binutils-gdb/gdb/eval.c:533
    #18 0x00005555647f740c in expr::var_value_operation::evaluate (this=0x7c2ff1e3b690, expect_type=0x0, exp=0x7c2ff1e3aa00, noside=EVAL_NORMAL) at /home/simark/src/binutils-gdb/gdb/eval.c:559
    #19 0x00005555647f3347 in expression::evaluate (this=0x7c2ff1e3aa00, expect_type=0x0, noside=EVAL_NORMAL) at /home/simark/src/binutils-gdb/gdb/eval.c:109
    #20 0x000055556543ac2f in process_print_command_args (args=0x7fffffffe728 "global_var", print_opts=0x7bfff0be4a30, voidprint=true) at /home/simark/src/binutils-gdb/gdb/printcmd.c:1328
    #21 0x000055556543ae65 in print_command_1 (args=0x7fffffffe728 "global_var", voidprint=1) at /home/simark/src/binutils-gdb/gdb/printcmd.c:1341
    #22 0x000055556543b707 in print_command (exp=0x7fffffffe728 "global_var", from_tty=1) at /home/simark/src/binutils-gdb/gdb/printcmd.c:1408

The problem to solve is: in order to evaluate a location expression, we
need to know some information (the various sizes) found in the unit
header.  In that context, it's not possible to get it from
dwarf2_cu::header, like the previous patch did: at the time the
expression is evaluated, the corresponding dwarf2_cu might have been
freed.  We don't want to re-build a dwarf2_cu just for that, it would be
very inefficient.  We could force reading in the dwarf2_per_cu::section
section (in the main file), but we never needed to read that section
before, so it would be better to avoid reading it unnecessarily.

My initial attempt was to store this information in baton objects
(dwarf2_locexpr_baton & co), so that it can be retrieved when the time
comes to evaluate the expressions.  However, it quickly became obvious
that storing it there would be redundant and wasteful.

I instead opted to store this information directly inside dwarf2_per_cu,
making it easily available when evaluating expressions.  These fields
initially have the value 0, and are set by cutu_reader whenever the
unit is parsed.  The various getters (dwarf2_per_cu::addr_size & al) now
just return these fields.

Doing so allows removing anything related to reading the header from
dwarf2_per_cu, which I think is a nice simplification.  This means that
nothing ever needs to read the header from just a dwarf2_per_cu.

It also happens to shrink the dwarf2_per_cu object size a bit, going
from:

    (top-gdb) p sizeof(dwarf2_per_cu)
    $1 = 176

to

    (top-gdb) p sizeof(dwarf2_per_cu)
    $1 = 120

I placed the new fields at this strange location in dwarf2_per_cu
because there happened to be a nice 3 bytes hole there (on Linux amd64
at least).

The new test set things up as described previously.  Note that the crash
only occurs if using the cc-with-gdb-index board.

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

gdb/dwarf: when in dwarf2_cu, read addr_size from dwarf2_cu::header

New in v2: make the test try with indexes by default

This patch fixes a crash caused by GDB trying to read from a section not
read in.  The bug happens in those specific circumstances:

 - reading a type unit from .dwo
 - that type unit has a stub in the main file
 - there is a GDB index (.gdb_index) present

This crash is the cause of the following test failure, with the
cc-with-gdb-index target board:

    $ make check TESTS="gdb.dwarf2/fission-reread.exp" RUNTESTFLAGS="--target_board=cc-with-gdb-index"
    Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.dwarf2/fission-reread.exp ...
    ERROR: GDB process no longer exists

Or, manually:

    $ ./gdb -nx -q --data-directory=data-directory /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-reread/fission-reread -ex "p 1"
    Reading symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-reread/fission-reread...

    Fatal signal: Segmentation fault

For this last one, you need to interrupt the test (e.g. add a return)
before the test deletes the .dwo file.

The backtrace at the moment of the crash is:

    #0  0x0000555566968f7f in bfd_getl32 (p=0x0) at /home/simark/src/binutils-gdb/bfd/libbfd.c:846
    #1  0x00005555642e561d in read_initial_length (abfd=0x7d1ff1eb0e40, buf=0x0, bytes_read=0x7bfff0962fa0, handle_nonstd=true) at /home/simark/src/binutils-gdb/gdb/dwarf2/leb.c:92
    #2  0x00005555647ca9ea in read_unit_head (header=0x7d0ff1e068b0, info_ptr=0x0, section=0x7c3ff1dea7d0, section_kind=ruh_kind::COMPILE) at /home/simark/src/binutils-gdb/gdb/dwarf2/unit-head.c:44
    #3  0x000055556452e37e in dwarf2_per_cu::get_header (this=0x7d0ff1e06880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18531
    #4  0x000055556452e574 in dwarf2_per_cu::addr_size (this=0x7d0ff1e06880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:18544
    #5  0x000055556406af91 in dwarf2_cu::addr_type (this=0x7d7ff1e20880) at /home/simark/src/binutils-gdb/gdb/dwarf2/cu.c:124
    #6  0x0000555564534e48 in set_die_type (die=0x7e0ff1f23dd0, type=0x7e0ff1f027f0, cu=0x7d7ff1e20880, skip_data_location=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:19020
    #7  0x00005555644dcc7b in read_structure_type (die=0x7e0ff1f23dd0, cu=0x7d7ff1e20880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:11239
    #8  0x000055556451c834 in read_type_die_1 (die=0x7e0ff1f23dd0, cu=0x7d7ff1e20880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16878
    #9  0x000055556451c5e0 in read_type_die (die=0x7e0ff1f23dd0, cu=0x7d7ff1e20880) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16861
    #10 0x0000555564526f3a in get_signatured_type (die=0x7e0ff1f0ffb0, signature=10386129560629316377, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:17998
    #11 0x000055556451c23b in lookup_die_type (die=0x7e0ff1f0ffb0, attr=0x7e0ff1f10008, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16808
    #12 0x000055556451b2e9 in die_type (die=0x7e0ff1f0ffb0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16684
    #13 0x000055556451457f in new_symbol (die=0x7e0ff1f0ffb0, type=0x0, cu=0x7d7ff1e0f480, space=0x0) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:16089
    #14 0x00005555644c52a4 in read_variable (die=0x7e0ff1f0ffb0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9119
    #15 0x0000555564494072 in process_die (die=0x7e0ff1f0ffb0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:5197
    #16 0x000055556449c88e in read_file_scope (die=0x7e0ff1f0fdd0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:6125
    #17 0x0000555564493671 in process_die (die=0x7e0ff1f0fdd0, cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:5098
    #18 0x00005555644912f5 in process_full_comp_unit (cu=0x7d7ff1e0f480) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:4851
    #19 0x0000555564485e18 in process_queue (per_objfile=0x7d6ff1e71100) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:4161
    #20 0x000055556446391d in dw2_do_instantiate_symtab (per_cu=0x7ceff1de42d0, per_objfile=0x7d6ff1e71100, skip_partial=true) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:1650
    #21 0x0000555564463b3c in dw2_instantiate_symtab (per_cu=0x7ceff1de42d0, per_objfile=0x7d6ff1e71100, skip_partial=true) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:1671
    #22 0x00005555644687fd in dwarf2_base_index_functions::expand_all_symtabs (this=0x7c1ff1e04990, objfile=0x7d5ff1e46080) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:1990
    #23 0x0000555564381050 in cooked_index_functions::expand_all_symtabs (this=0x7c1ff1e04990, objfile=0x7d5ff1e46080) at /home/simark/src/binutils-gdb/gdb/dwarf2/cooked-index.h:237
    #24 0x0000555565df5b0d in objfile::expand_all_symtabs (this=0x7d5ff1e46080) at /home/simark/src/binutils-gdb/gdb/symfile-debug.c:372
    #25 0x0000555565eafc4a in maintenance_expand_symtabs (args=0x0, from_tty=1) at /home/simark/src/binutils-gdb/gdb/symmisc.c:914

The main file contains a stub (skeleton) for a compilation unit and a
stub for a type unit.   The .dwo file contains a compilation unit and a
type unit matching those stubs.  When doing the initial scan of the main
file, the DWARF reader parses the CU/TU list from the GDB index
(.gdb_index), and thus creates a signatured_type object based on that.
The section field of this signatured_type points to the .debug_types
section in the main file, the one containing the stub.  And because GDB
trusts the GDB index, it never needs to look at that .debug_types
section in the main file.  That section remains not read in.

When expanding the compilation unit, GDB encounters a type unit
reference (by signature) corresponding to the type in the type unit.  We
get in lookup_dwo_signatured_type, trying to see if there is a type unit
matching that signature in the current .dwo file.  We proceed to read
and expand that type unit, until we eventually get to a
dwarf2_cu::addr_type() call, which does:

     int addr_size = this->per_cu->addr_size ();

dwarf2_per_cu::addr_size() tries to read the header from the section
pointed to by dwarf2_per_cu::section which, if you recall, is the
.debug_types section in the main file that was never read in.  That
causes the segfault.

All this was working fine before these patches of mine, that tried to do
some cleanups:

    a47e2297fc28 ("gdb/dwarf: pass section offset to dwarf2_per_cu_data constructor")
    c44ab627b021 ("gdb/dwarf: pass section to dwarf2_per_cu_data constructor")
    39ee8c928551 ("gdb/dwarf: pass unit length to dwarf2_per_cu_data constructor")

Before these patches, the fill_in_sig_entry_from_dwo_entry function
(called from lookup_dwo_signatured_type, among others) would overwrite
some dwarf2_per_cu fields (including the section) to point to the .dwo,
rather than represent what's in the main file.  Therefore, the header
would have been read from the unit in the .dwo file, and things would
have been fine.

When doing these changes, I mistakenly assumed that the section written
by fill_in_sig_entry_from_dwo_entry was the same as the section already
there, which is why I removed the statements overwriting the section
field (and the two others).  To my defense, here's the comment on
dwarf2_per_cu::section:

    /* The section this CU/TU lives in.
       If the DIE refers to a DWO file, this is always the original die,
       not the DWO file.  */
    struct dwarf2_section_info *section = nullptr;

I would prefer to not reintroduce the behavior of overwriting the
section info in dwarf2_per_cu, because:

 1. I find it confusing, I like the invariant of dwarf2_per_cu::section
    points to the stub, and dwarf2_cu::section points to where we
    actually read the debug info from.
 2. The dwarf2_per_bfd::all_units vector is nowadays sorted by (section,
    section offset).  If we change the section and section offset of a
    dwarf2_per_cu, then we can no longer do binary searches in it, we
    would have to re-sort the vector (not a big deal, but still adds to
    the confusion).

One possible fix would be to make sure that the section is read in when
reading the header, probably in dwarf2_per_cu::get_header.  An approach
like that was proposed by Andrew initially, here:

  https://inbox.sourceware.org/gdb-patches/60ba2b019930fd6164f8e6ab6cb2e396c32c6ac2.1759486109.git.aburgess@redhat.com/

It would work, but there is a more straightforward fix for this
particular problem, I believe.  In dwarf2_cu, we have access to the
header read from the unit we're actually reading the DWARF from.  In the
DWO case, that is the header read from the .dwo file.  We can get the
address size from there instead of going through the dwarf2_per_cu
object.  This is what this patch does.

However, there are other case where we get the address (or offset) size
from the dwarf2_per_cu in the DWARF expression evaluator (expr.c,
loc.c), that could cause a similar crash. The next patch handles these
cases.

Modify the gdb.dwarf2/fission-reread.exp test so that it tries running
with an index even with the standard board (that part was originally
written by Andrew).

Finally, just to put things in context, having a stub in the main file
for a type unit is obsolete.  It happened in the gcc 4.x days, until
this commit:

    commit 4dd7c3b285daf030da0ff9c0d5e2f79b24943d1e
    Author: Cary Coutant <ccoutant@google.com>
    Date:   Fri Aug 8 20:33:26 2014 +0000

        Remove skeleton type units that were being produced with -gsplit-dwarf.

In DWARF 5, split type units don't have stubs, only split compilations
units do.

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

gdb/testsuite/dwarf: emit type unit sections as COMDAT

In an effort to generate ELF files and DWARF info as close as possible
as an actual compiler would generate, change how we emit type unit
sections to emit each type unit in its own section, in COMDAT section
groups.

We currently emit all type units in a single, standard section (either
.debug_info or .debug_types, depending on the DWARF version).  Compilers
emit each type unit in its own .debug_types section.  Each section is
placed in a COMDAT section group with a signature based on the type
unit's signature.  This lets the linker deduplicate identical type units
by discarding section groups with identical signatures (keeping only one
group with a given signature).

Looking at a .s file generated by gcc, we can see that this is how it
specifies the section for a type unit:

    .section .debug_info,"G",@progbits,wi.006fd2152a3054a6,comdat

The "G" flag tells the assembler to place the section in a section
group with signature "wi.006fd2152a3054a6".  That string was generated
from the type unit, signature.  Finally, the comdat linkage field
indicates that the section group should have the COMDAT flag.

Update the tu proc to emit a section with these properties.  In this
case, it's mandatory to specify the type of the section (progbits).

Update the _section proc to accept the new options "group_signature" and
"linkage".

As a result, if you look at the .debug_types section in a .o file from
gcc:

    $ readelf -g main.o
    COMDAT group section [    1] `.group' [wt.006fd2152a3054a6] contains 2 sections:
       [Index]    Name
       [   11]   .debug_types
       [   12]   .rela.debug_types

    COMDAT group section [    2] `.group' [wt.c621aa8e3c23e450] contains 2 sections:
       [Index]    Name
       [   13]   .debug_types
       [   14]   .rela.debug_types

And a .o file created by our DWARF assembler:

    $ readelf -g testsuite/outputs/gdb.dwarf2/struct-with-sig/struct-with-sig1.o
    COMDAT group section [    1] `.group' [sig.0x0000000000000001] contains 2 sections:
       [Index]    Name
       [   10]   .debug_types
       [   11]   .rela.debug_types

    COMDAT group section [    2] `.group' [sig.0x0000000000000002] contains 2 sections:
       [Index]    Name
       [   12]   .debug_types
       [   13]   .rela.debug_types

In both cases, in the fully linked files, there is a single .debug_types section
containing the two type units, as expected.

Before this patch, when I run gdb.dwarf2/fission-with-type-unit.exp, the
resulting .dwo file has a single .debug_info.dwo.  After this patch it
has two: one with the type unit and one with the compile unit (the test
uses DWARF 5).  Based on what I see gcc generate when using "-gdwarf-5
-gsplit-dwarf -fdebug-types-section", this is what we expect.

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

gdb/testsuite/dwarf: convert _section proc to use parse_options

New in v2: return early if the section is .debug_str

The following patch will add more options to the _section proc, so
convert it to use options, to be more user-friendly.

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

gdb/testsuite/dwarf: use single abbrev table in .dwo files

When I wrote test gdb.dwarf2/fission-with-type-unit.exp, I did not use
build_executable_and_dwo_files, because it wouldn't work to have
multiple units in the .dwo file, each referring to their own abbrev
table using labels.  build_executable_and_dwo_files extracts the .dwo
file content from the .o using objcopy (just like gcc does, I learned),
meaning that the .dwo file never runs through a linker.  Anything
needing relocation (like labels pointing to abbrev tables) doesn't work.

I instead opted to use gdb_compile_shlib to build the .dwo file on its
own, so that those labels would get resolved.  That causes problems now
that I'm trying to write a test with multiple type units in a .dwo file,
where each type unit should be in its own .debug_types section.  Running
the .dwo file through the linker causes all the .debug_types section to
be collapsed into one.  And generally, I think it was a bad idea to
generate a .dwo file using the linker, since the idea behind .dwo files
is that they do not need to be linked (therefore improving link
times).  We want to produce files as close to what an actual compiler
would produce.

This patch fixes this by doing what compilers do in the same situation:
use a single abbrev table shared by all units in the .dwo file.  This
requires the following changes in lib/dwarf.exp:

 - Declare a new variable _dwo_abbrev_num, which holds the next
   abbrev number to use in the .dwo file's abbrev section
   (.debug_abbrev.dwo).  Initialize this variable to 1.
 - When producing a CU or TU in a .dwo file, use 0 as the abbrev table
   offset.
 - When generating a DIE, return $_dwo_abbrev_num or $_abbrev_num,
   depending on whether the current CU is in a .dwo file.
 - After producing a CU or TU in a .dwo file, don't append the
   terminator byte.
 - After finishing producing the CUs and TUs, append the terminator byte
   in .debug_abbrev.dwo if we did output anything there.

Update gdb.dwarf2/fission-with-type-unit.exp to use
build_executable_and_dwo_files, as it should.  Remove the
gdb_remote_download call from gdb.dwarf/fission-with-type-unit.exp,
because build_executable_and_dwo_files does not support remote hosts
anyway.

With this change, running with the cc-with-gdb-index board, I see:

    (gdb) maint expand-symtabs
    /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3056: internal-error: cutu_reader: Assertion `sig_type->signature == cu->header.signature' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    ----- Backtrace -----
    FAIL: gdb.dwarf2/fission-with-type-unit.exp: maint expand-symtabs (GDB internal error)

This is actually an improvement, as the test case didn't run properly
before.  The compilation failed with:

    gdb compile failed, During symbol reading: Could not find DWO CU fission-with-type-unit.dwo(0xf00d) referenced by CU at offset 0xc [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-with-type-unit/.tmp/fission-with-type-unit]

The reason was that the old code would try to generate the GDB index
during this step:

    # Build main file.
    if { [build_executable "${testfile}.exp" $binfile \
     [list ${srcfile} ${main_asm_file}] {nodebug}] } {
        return
    }

... which is before the DWO file is even generated.  With this patch
things are done in the correct order:

 - The -dw.S file is generated
 - The -dw.o file is compiled from the -dw.S
 - The .dwo sections are extracted to the .dwo file, and stripped from
   the -dw.o file
 - The executable is linked from the .o and -dw.o
 - gdb-add-index is ran on the executable

When gdb-add-index runs, the .dwo file exists, so GDB is able to produce
an index.  That index is bogus though, because the .gdb_index format is
unable to describe skeletonless type units.  And then GDB gets confused
trying to use that index, leading to the internal error.

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

gdb/testsuite/dwarf: ensure build_executable_and_dwo_files calls untested in all failure paths

There are some paths of build_executable_and_dwo_files that return -1
without calling "untested".  As a result, tests such as
gdb.dwarf2/fission-absolute-dwo.exp would exit without leaving a trace.
Add some untested calls to fix that.

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

gdb/dwarf: remove nullptr check in dwarf2_locexpr_baton_eval

The sole caller of this function passes the address of a field, we know
it's not nullptr.

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

gdb/dwarf: remove nullptr prop check in dwarf2_evaluate_property

This nullptr is pointless most of the time: almost all callers either
check that the prop is not nullptr or they pass the address of a local
variable, which is necessarily not nullptr.  I propose to remove it.  I
found only one call site where I needed to add a check.

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

gdb/testsuite: make more use of clean_restart's argument

Commits:

  commit aaad5a3254db53434eaf1cf70384e7ee0dfb886a
  Author: Tom de Vries <tdevries@suse.de>
  Date:   Fri Sep 5 15:36:23 2025 +0200

      [gdb/testsuite] Fix clean_restart <absolute filename> in gdb.base, part 3

  commit 2e61486fcefe8812714dcb0fb787581592675502
  Author: Tom de Vries <tdevries@suse.de>
  Date:   Fri Sep 5 15:36:23 2025 +0200

      [gdb/testsuite] Fix clean_restart <absolute filename> in gdb.base, part 2

  commit 202beb3feebd44fbc1979d9fdb4d74c44e16a417
  Author: Tom de Vries <tdevries@suse.de>
  Date:   Fri Sep 5 15:36:23 2025 +0200

      [gdb/testsuite] Fix clean_restart <absolute filename> in gdb.base, part 1

were made to work around the changes to clean_restart in commit:

  commit cba778b944af90c362a618af0630877736a54baa
  Date:   Sun Sep 7 11:53:30 2025 +0200

      [gdb/testsuite] Error out on clean_restart <absolute filename>

These commits added a lot of calls to gdb_load which can be removed in
many cases by passing $testfile to clean_restart, or by switching to
use prepare_for_testing to compile the test executable.

In this commit I've gone through the gdb.base/ directory and removed
as many of the gdb_load calls as possible.  I was only looking for
places where the gdb_load call immediately follows the call to
clean_restart.  And I did skip a few where it was not as simple as
just passing $testfile.

Where possible I've updated tests to use calls to prepare_for_testing,
and simply removed the clean_restart call altogether (this is done as
part of prepare_for_testing).  This is, I think, the best solution.

In other cases I've removed the gdb_load call, and passed $testfile to
clean_restart.  I've preferred $::testfile to adding a 'global'
declaration, and in some cases switching to testfile has allowed me to
remove the 'global binfile' as an additional cleanup.

I ran the complete set of tests that I touched and I didn't see any
regressions, so I don't believe I broke anything.

I know that there are probably gdb_load calls that can be cleaned up
in other testsuite sub-directories, if/when this patch is merged I'll
take a look at those too.

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

gdb/aarch64: change target_ops::stopped_data_address API

At Red Hat we have an out of tree AArch64 watchpoint test which broke
after this commit:

  commit cf16ab724a41e4cbaf723b5633d4e7b29f61372b
  Date:   Tue Mar 12 17:08:18 2024 +0100

      [gdb/tdep] Fix gdb.base/watch-bitfields.exp on aarch64

The problem with AArch64 hardware watchpoints is that they (as I
understand it) are restricted to a minimum of 8 bytes.

The problem is that current AArch64 hardware has imprecise hardware
watchpoint events due to unaligned accesses.  The address reported for
the watchpoint event will depend on the access size.  As a result, it
is possible that multiple watchpoints could potentially account for a
single watchpoint event, which is the case in the RH test.  GDB can
then miss-identify which watchpoint actually triggered.

Prior to the above commit the RH test was passing.  However, the test
was relying on, in the case of ambiguity, GDB selecting the first
created watchpoint.  That behaviour changed with the above commit.
Now GDB favours reporting non write breakpoints, and will only report
a write breakpoint if no non-write breakpoint exists in the same
region.

I originally posted a patch to try and tweak the existing logic to
restore enough of the original behaviour that the RH test would pass,
this can be found here (2 iterations):

  https://inbox.sourceware.org/gdb-patches/65e746b6394f04faa027e778f733eda95d20f368.1753115072.git.aburgess@redhat.com
  https://inbox.sourceware.org/gdb-patches/638cbe9b738c0c529f6370f90ba4a395711f63ae.1753971315.git.aburgess@redhat.com

Neither of these really resolved the problem, they fixed some cases,
but broke others.

Ultimately, the problem on AArch64 is that for a single watchpoint
trap, there could be multiple watchpoints that are potentially
responsible.  The existing API defined by the target_ops methods
stopped_by_watchpoint() and stopped_data_address() only allow for two
possible options:

  1. If stopped_by_watchpoint() is true then stopped_data_address()
     can return true and a single address which identifies all
     watchpoints at that single address, or

  2. If stopped_by_watchpoint() is true then stopped_data_address()
     can return false, in which case GDB will check all write
     watchpoints to see if any have changed, if they have, then GDB
     tells the user that that was the triggering watchpoint.

If we are in a situation where we have to choose between multiple
write and read watchpoints then the current API doesn't allow the
architecture specific code to tell GDB core about this case.

In this commit I propose that we change the target_ops API,
specifically, the method:

  bool target_ops::stopped_data_address (CORE_ADDR *);

will change to:

  std::vector<CORE_ADDR> target_ops::stopped_data_addresses ();

The architecture specific code can now return a set of watchpoint
addresses, allowing GDB to identify a set of watchpoints that might
have triggered.  GDB core can then select the most likely watchpoint,
and present that to the user.

As with the old API, target_ops::stopped_data_addresses should only be
called when target_ops::stopped_by_watchpoint is true, in which case
it's return values can be interpreted like this:

  a. An empty vector; this replaces the old case where false was
     returned.  GDB should check all the write watchpoints and select
     the one that changed as the responsible watchpoint.

  b. A single entry vector; all targets except AArch64 currently
     return at most a single entry vector.  The single address
     indicates the watchpoint(s) that triggered.

  c. A multi-entry vector; currently AArch64 only.  These addresses
     indicate the set of watchpoints that might have triggered.  GDB
     will check the write watchpoints to see which (if any) changed,
     and if no write watchpoints changed, GDB will present the first
     access watchpoint.

In the future, we might want to improve the handling of (c) so that
GDB tells the user that multiple access watchpoints might have
triggered, and then list all of them.  This might clear up some
confusion.  But I think that can be done in the future (I don't have
an immediate plan to work on this).  I think this change is already a
good improvement.

The changes for this are pretty extensive, but here's a basic summary:

  * Within gdb/ changing the API name from stopped_data_address to
    stopped_data_addresses throughout.  Comments are updated too where
    needed.

  * For targets other than AArch64, the existing code is retained with
    as few changes as possible, we only allow for a single address to
    be returned, the address is now wrapped in a vector.  Where we
    used to return false, we now return the empty vector.

  * For AArch64, the return a vector logic is pushed through to
    gdb/nat/aarch64-hw-point.{c,h}, and aarch64_stopped_data_address
    changes to aarch64_stopped_data_addresses, and is updated to
    return a vector of addresses.

  * In infrun.c there's some updates to some debug output.

  * In breakpoint.c the interesting changes are in
    watchpoints_triggered.  The existing code has three cases to
    handle:

    (i) target_stopped_by_watchpoint returns false.  This case is
        unchanged.

    (ii) target_stopped_data_address returns false.  This case is now
         calling target_stopped_data_addresses, and checks for the
 empty vector, but otherwise is unchanged.

    (iii) target_stopped_data_address returns true, and a single
          address.  This code calls target_stopped_data_addresses, and
  now handles the possibility of a vector containing multiple
  entries.  We need to first loop over every watchpoint
  setting its triggered status to 'no', then we check every
  address in the vector setting matching watchpoint's
  triggered status to 'yes'.  But the actual logic for if a
  watchpoint matches an address or not is unchanged.

    The important thing to notice here is that in case (iii), before
    this patch, GDB could already set _multiple_ watchpoints to
    triggered.  For example, setting a read and write watchpoint on
    the same address would result in multiple watchpoints being marked
    as triggered.  This patch just extends this so that multiple
    watchpoints, at multiple addresses, can now be marked as
    triggered.

  * In remote.c there is an interesting change.  We need to allow
    gdbserver to pass the multiple addresses back to GDB.  To achieve
    this, I now allow multiple 'watch', 'rwatch', and 'awatch' tokens
    in a 'T' stop reply packet.  There's a new feature multi-wp-addr
    which is passed in the qSupported packet to determine if the
    remote is allowed to pass back multiple watchpoint stop reasons.

    If the remote passed multiple watchpoint addresses then these are
    collected and returned from the target_ops::stopped_data_addresses
    call.

    If a new GDB connects to an old gdbserver that doesn't understand
    the multi-wp-addr feature, then gdbserver will continue to return
    a single watchpoint address in the 'T' packet, which is what
    happens before this patch.

  * In gdbserver/ the changes are pretty similar.  The API is renamed
    from ::stopped_data_address to ::stopped_data_addresses, and
    ::low_stopped_data_address to ::low_stopped_data_addresses.

    There's also code added to detect the new multi-wp-addr feature.
    If this feature is not advertised from GDB then only a single
    watchpoint address will be returned in the 'T' stop reply packet.

  * In GDB and gdbserver, for all targets except AArch64, the existing
    code to figure out a watchpoint address is retained, we just wrap
    the single address into a vector.

  * For AArch64, we call aarch64_stopped_data_addresses, which returns
    the required vector.

For testing, I've built GDB on GNU/Linux for i386, x86-64, PPC64le,
ARM, and AArch64.  That still leaves a lot of targets possibly
impacted by this change as untested.  Which is a risk.  I certainly
wouldn't want to push this patch until after GDB 17 branches so we
have time to find and fix any regressions that are introduced.

I've run a full regression test on AArch64 and x86-64 (both GNU/Linux)
with no regressions.  As I said above, for other targets nothing
should really have changed, all non-AArch64 targets just return a
single watchpoint address from target_ops::stopped_data_addresses(),
so, as long as the target builds, it should run unchanged.

I also sent the branch through the sourceware CI, and everything
passed.

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

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

[gdb/corefiles] Sort info proc mappings table

On x86_64-linux, with test-case gdb.python/py-corefile.exp I run into:
...
FAIL: $exp: test mapped files data: diff input and output one
...

The failing test compares the output of:
- info proc mappings, and
- info proc py-mappings, a python implementation of "info proc mappings".

The difference in output is order: while the latter prints the entries sorted
on start address, the former doesn't.

Fix this by sorting the entries in linux_read_core_file_mappings.

Tested on x86_64-linux.

PR corefiles/33543
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33543

Automatic date update in version.in

lto: Compile PR ld/23818 test with -fPIC

Compile PR ld/23818 test with -fPIC to fix

testsuite/ld-plugin/pr23818b.c:6:(.text+0x34): relocation R_MIPS_26 against `a local symbol' cannot be used when making a shared object; recompile with -fPIC
FAIL: Build libpr23818.so

for mips.

PR ld/23818
* testsuite/ld-plugin/lto.exp: Compile PR ld/23818 test with
-fPIC.

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

elf: Properly place base symbols in DT_GNU_HASH and DT_HASH

The base symbol, a symbol with the empty version string, created by

asm (".symver foo_base, foo@");

is used to provide a compatibility symbol in a versioned shared library
for binaries linked against the previous unversioned shared library.
The dynamic linker will pick the first match to resolve the unversioned
symbol reference.  If the newest version, VERS_1,

asm (".symver foo_v1, foo@@VERS_1");

is picked before the base symbol in DT_GNU_HASH and DT_HASH, foo@@VERS_1,
instead of foo@, will be used to resolve the unversioned reference.
Properly place base symbols in DT_GNU_HASH and DT_HASH so that they will
be picked first.

Also check defined function symbol, foo, and undefined function symbol,
bar, separately to support different dynamic symbol orders.

bfd/

PR ld/33577
PR ld/33673
* elf-bfd.h (elf_link_hash_entry): Add base_symbol.
(elf_link_hash_table): Add has_base_symbols.
* elflink.c (_bfd_elf_merge_symbol): Set base_symbol and
has_base_symbols if the version string is empty.
(collect_gnu_hash_codes): Add base_symbol.
(elf_gnu_hash_process_symidx): Skip if base symbol doesn't match.
(bfd_elf_size_dynsym_hash_dynstr): If there are base symbols,
output base symbols first in DT_GNU_HASH.
(elf_outext_info): Add base_symbol.
(elf_link_output_extsym): Skip if base symbol doesn't match.
(_bfd_elf_final_link): If there are base symbols, output base
symbols last in DT_HASH.

ld/

PR ld/33577
PR ld/33673
* testsuite/ld-elfvers/pr33577-unversioned.rd: Removed.
* testsuite/ld-elfvers/pr33577-versioned.rd: Likewise.
* testsuite/ld-elfvers/pr33577-unversioned-a.rd: New file.
* testsuite/ld-elfvers/pr33577-unversioned-b.rd: Likewise.
* testsuite/ld-elfvers/pr33577-versioned-a.rd: Likewise.
* testsuite/ld-elfvers/pr33577-versioned-b.rd: Likewise.
* ld-elfvers/vers.exp (base_symbol_test): New.
Run PR ld/33673 tests.

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

elf: Renumber local dynamic symbols only if needed

Only hppa, ia64 and sparc ELF targets use local dynamic symbols.  But
elf_link_renumber_local_hash_table_dynsyms is always called to renumber
local dynamic symbols even if there is none.  Add has_local_dynsyms to
elf_link_hash_table and set it to true only if there are local dynamic
symbols.  Renumber local dynamic symbols only if there are local dynamic
symbols.

* elf-bfd.h (elf_link_hash_table): Add has_local_dynsyms.
* elflink.c (_bfd_elf_link_renumber_dynsyms): Renumber local
dynamic symbols only if there are local dynamic symbols.
(_bfd_elf_adjust_dynamic_symbol): Set has_local_dynsyms if
there are local dynamic symbols.

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

ELF symbol version output cleanup

* elflink.c (elf_link_output_extsym): Localise code setting
VERSYM_HIDDEN to previous branch of "if" where def_regular
might be true.  Delete noversion.  Set vs_vers to zero instead.

PR 33637, abort in byte_get

When DWARF5 support was added to binutils in commit 77145576fadc,
the loop over CUs in process_debug_info set do_types when finding a
DW_UT_type unit, in order to process the signature and type offset
entries.  Unfortunately that broke debug_information/debug_info_p
handling, which previously was allocated and initialised for each unit
in .debug_info.  debug_info_p was NULL when processing a DWARF4
.debug_types section.  After the 77145576fadc change it was possible
for debug_infp_p to be non-NULL but point to zeroed data, in
particular a zeroed offset_size.  A zero for offset_size led to the
byte_get_little_endian abort triggered by the fuzzer testcase.

I haven't investigated whether there is any need for a valid
offset_size when processing a non-fuzzed DWARF4 .debug_types section.
Presumably we'd have found that out in the last 6 years if that was
the case.  We don't want to change debug_information[] for
.debug_types!

PR 33637
* dwarf.c (process_debug_info): Don't change DO_TYPES flag bit
depending on cu_unit_type.  Instead test cu_unit_type along
with DO_TYPES to handle signature and type_offset for a type
unit.  Move find_cu_tu_set_v2 call a little later.

Re: bfd/Dwarf: Add suitable defines to use at call and use sites

Commit 1f7e70ddd2c4 made changes to process_debug_info parameters
without adjusting the function comment to suit.  Fix that, and tidy
do_printing flag use.

* dwarf.c (process_debug_info): Edit function comment.
Make do_printing a bool.  Fold DO_LOC test into do_printing.

bfd: fix potential missing seek

If a file was closed by cache and then bfd_open_file was called followed
by e.g. bfd_seek to the original position, the seek would be optimized out
while the real file position was still zero (as fopened).  I added
`bfd_io_force` to force the seek at next IO occasion.

This could lead e.g. to appearence of a corrupted object in ld:
  symbol number 0 uses unsupported binding of 6
  or invalid string offset #X >= #Y for section

Signed-off-by: Roman Kapl <code@rkapl.cz>

Automatic date update in version.in

Automatic date update in version.in

gprofng: protect against standard library macros

The CALL_UTIL macro can expand to an unparsable expression of the argument
is a macro, like with the new const-preserving standard library macros in
C23.

* gprofng/src/collector_module.h (CALL_UTIL): Add parens to not
expand its argument if it is a function-like macro.

gdb/testsuite: fix a few typos

When merging the big "whitespace fix" commit in a downstream repo,
pre-commit/codespell identified a lot of typos, fix a few of them.

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

gdb: update is_addr_in_objfile to support "dynamic" objfiles

While working with objfiles in Python I noticed that
gdb.Progspace.objfile_for_address () does not return "dynamic" objfiles
created by (for example) GDB's JIT reader API.

This is because is_addr_in_objfile() checks if a given address falls into
any (mappped) section of that objfile. However objfiles created by JIT
reader API do not have sections.

To solve this issue, this commit updates is_addr_in_objfile() to also
check if the address fall into any compunit in that objfile. It does so
only if the objfile has no sections.

gdb: add unittests for blockvector lookup functions

This commit adds new unittest - blockvector-lookup - that tests
blockvector::lookup () and blockvector::contains ().

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

gdb: change blockvector::contains() to handle blockvectors with "holes"

This commit slightly changes the logic in blockvector::contains()
to handle a case where the blockvector contains blocks with disjoint
regions (see the comment in blockvector::contains for details).

This change may potentially change GDB's behavior. It is not clear to me
if there was a reason for blockvector_contains_pc() behaving differently
depending whether or not given blockvector contain a map. With this
change, blockvector::contains() return the same value regardless. The
reason for it is to make it work as expected also for "dynamic" code
created by JIT reader (and perhaps by Python in the future).

Note that for CUs created from DWARF, blockvectors have always a map set
so this change in behavior should not affect them. Running testsuite
on Linux x86_64 shown no regressions.

Finally, I was considering of making this change up in lookup method
but in the end decided to be bit more conservative because comment in
original find_block_in_blockvector() suggested that returning a static
block from there is an expected situation.

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

gdb: update blockvector::lookup

This commit changes blockvector::lookup() to improve style and
readability. It also adds quick range check to see if given address
falls into global block.

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

[gdb/build, c++20] Fix UTF-8 string literal usage

PR build/33675 reports a build breaker:
...
top.c: In function ‘void box_one_message(ui_file*, std::string, int)’:
top.c:1368:35: error: conditional expression between distinct pointer types \
  ‘const char8_t*’ and ‘const char*’ lacks a cast
 1368 |   const char *wall = emojis_ok () ? u8"\u2503" : "|";
      |                      ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
...

The problem is that UTF-8 string literals have type:
- const char[N]    (until C++20), or
- const char8_t[N] (since C++20)

Fix this by assigning to variables:
...
static const char bd_heavy_vertical[] = u8"\u2503";
...
and using the variables instead.

Tested by rebuilding on x86_64-linux, and starting gdb and checking the
welcome message box.

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

[gdb/testsuite] Fix three typos in gdb.base/long_long.exp

Fix three types in test-case gdb.base/long_long.exp:
...
$ codespell gdb.base/long_long.exp
gdb.base/long_long.exp:19: differnet ==> different
gdb.base/long_long.exp:208: Implict ==> Implicit
gdb.base/long_long.exp:224: Implict ==> Implicit
...

x86: drop a few excess AVX512VL from opcode table

In commit 24187fb9c0d0 ("x86/APX: extend SSE2AVX coverage") I apparently
went a little to far with AVX512VL uses:
- PEXTRQ and PINSRQ are AVX512DQ alone, despite using 128-bit (XMM)
  registers,
- SSE41DQ is used for only PEXTRD and PINSRD, falling in the same
  category.

With the SSE41DQ observation above, also simplify Disp8MemShift handling
there: No need to override it in the insn template, as long as the
manufacturing template specifies it correctly.

Note that the AVX512DW form of PINSRQ also had a stray "AVX" CPU specifier
on it. Make this disappear by templatizing via a new SSE41DQ64
manufacturing template (covering PEXTRQ and PINSRQ, paralleling SSE41DQ).

ld: support most modifiers for printf() like vfinfo() format specifiers

Not doing so is pretty error prone: One needs to distinguish e.g.
->einfo() and alike invocations out of libbfd from _bfd_error_handler()
ones. Omit support for * though for now, as that would be more intrusive
to implement.

Use this then to disambiguate x86'es ISA level diagnostic of unknown bits,
where decimal vs hex isn't immediately clear.

bfd/Dwarf: Add suitable defines to use at call and use sites

use do_loc and do_types arguments into a signle unsigned int do_flags for
better code readability.

binutils/

* dwarf.c (DO_LOC, DO_TYPES): Define.
(process_debug_info): Change arguments do_loc and do_types
to a single unsigned int do_flags.
(find_cu_tu_set_v2): Change parameter do_types from int to bool.

Signed-off-by: Guillaume VACHERIAS <guillaume.vacherias@foss.st.com>

Automatic date update in version.in

gdb/MAINTAINERS: add Christina Schimpe as x86-64 and i386 maintainer

Christina Schimpe has kindly agreed to take on the role of maintainer
for the x86-64 and i386 targets (thank you!).  Update the MAINTAINERS
file to reflect that.

Change-Id: I0b01ea5a1dedf0f5f58dc9f66d54014d4f5bbb00

gdb: Make startup message more user friendly

Currently, on startup, GDB prints a lot of licensing information and
then a few hints for new users.  While there is an attempt to separate
the hints from the rest of the text, my user testing showed that it is
not good enough, and most unfamiliar users will just skip the
information.  Especially considering that the documentation link happens
before the separation.

This commit attempts to make the startup message more friendly to new
users by visually separating the most important commands from the
copyright.  If there is enough space available, a box is printed
containing the hints (either using unicode box drawing characters, if
emojis are allowed, or using ascii).  If there isn't space for a box,
a simple line separator is printed.  The code deems "enough space
available" when there is enough space to print the documentation URL
inside the box, since the other hints will be broken into multiple
lines if necessary.
Here are examples of the 2 possible startups, with enough space:

+-----------------------------------------------------------------+
| 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". |
+-----------------------------------------------------------------+

And with limited space:

---------------------------------------------
Find the GDB manual documentation resources o
nline at:
    <http://www.gnu.org/software/gdb/document
ation/>.
For help, type "help".
Type "apropos word" to search for commands re
lated to "word".

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

gdb: make test name initials lowercase in gdb.base/gdbvars.exp

According to GDB coding style, test names should start with lowercase:

  https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Follow_the_test_name_convention

Modify the test names in gdb.base/gdbvars.exp accordingly.

[gdb/tdep] Simplify i386_thiscall_push_dummy_call

I came across this code in i386_thiscall_push_dummy_call:
...
  int args_space = 0;
  ...
  for (write_pass = 0; write_pass < 2; write_pass++)
    {
      int args_space_used = 0;
      ...
  if (write_pass)
    {
      store_unsigned_integer (buf, 4, byte_order, struct_addr);
      write_memory (sp, buf, 4);
      args_space_used += 4;
    }
  else
    args_space += 4;
...
and wondered about the difference between arg_space and arg_space_used.

AFAICT, there is none:
- args_space is available after the loop, but unused after the loop
- in the loop body:
  - if write_pass == 0: args_space is used
  - if write_pass == 1: arg_space_used
- the code modifying args_space and args_space_used is identical

Simplify the loop body by using just one variable: args_space.

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

Obsolete support for Solaris < 10

Support for Solaris 8 and 9 has long been removed from GCC:

* Solaris 8 support in GCC 4.8 (2013)

* Solaris 9 support in GCC 5 (2015)

so it's time to obsolete anything before Solaris 10 in binutils, too.

Both wouldn't even build since binutils 2.41.

Tested on both i386-pc-solaris2.8 (with and without --enable-obsolete)
and i386-pc-solaris2.11.

2025-11-26  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

bfd:
* config.bfd <*-*-solaris2.[0-9]*>: Obsolete.

Automatic date update in version.in

PR 33453 linker generated .eh_frame

This is the final piece to fix the PR33453 testcase.  It makes use of
the extended size final link buffer when writing linker generated
.eh_frame.

PR 33453
* elf-bfd.h (_bfd_elf_write_linker_section_eh_frame): Declare.
* elf-eh-frame.c (_bfd_elf_write_linker_section_eh_frame): New.
* elf32-ppc.c (ppc_elf_finish_dynamic_sections): Use new function.
* elf64-ppc.c (ppc64_elf_finish_dynamic_sections): Likewise.
* elf64-s390.c (elf_s390_finish_dynamic_sections): Likewise.
* elfxx-x86.c (_bfd_x86_elf_finish_dynamic_sections): Likewise.

PR 33453 backend_finish_dynamic_sections final link buffer

This adds a pointer parameter to backend_finish_dynamic_sections, to
give the function access to the final link section contents buffer.
The patch is entirely mechanical changes in preparation for the next
patch.  No use is made of the buffer here.

PR 33453 allow extra for .eh_frame in final link buffer

The PR33453 testcase overflows a buffer allocated for the .eh_frame
section.  This happens with a silly large alignment for .eh_frame,
creating a large gap between two .eh_frame sections.  When the last
FDE of the first section is stretched to cover the gap, we get a
buffer overflow.  This patch makes the final link buffer large enough
to cover such gaps.  It doesn't fix the testcase yet, because there
the first .eh_frame section in question is the x86 plt_eh_frame
section which uses a different buffer.  However, similar testcases
could be constructed using object file .eh_frame sections.

PR 33453
* elflink.c (bfd_elf_final_link): Round up max_contents_size
for .eh_frame alignment.

Tidy .eh_frame rawsize manipulation

bfd_elf_discard_info is only called once.  Well, it was until commit
9b854f169df9 introduced cmdline_emit_object_only_section, but I think
and hope that function does enough reinitialisation to not cause a
problem.  There would be a problem if bfd_elf_discard_info was called
iteratively, shrinking an eh_frame section on the first pass, then
further shrinking on another pass.  That's because
_bfd_elf_discard_section_eh_frame uses rawsize to store the last
section size, which is against the general rules for input sections.
rawsize needs to be kept as the initial size to be able to read
section contents again (or you'd need to cache the edited contents).
Other eh_frame functions would break too.

So this tidy makes it obvious when looking at
_bfd_elf_discard_section_eh_frame alone that rawsize is only set once,
to the initial size.  There are no functional changes here.

* elf-bfd.h (_bfd_elf_discard_section_eh_frame): Update decl.
* elf-eh-frame.c (_bfd_elf_discard_section_eh_frame): Return
an int status.  Don't set rawsize unless it is zero.
* elflink.c (bfd_elf_discard_info): Use new return status
from _bfd_elf_discard_section_eh_frame rather than comparing
section size with rawsize.

gdb: fix some whitespace issues

Replace 8 spaces with a tab.

Change-Id: Ie8f942ce4b4ba4a83c2ee83cb904153b2e58cf8c

libsframe: testsuite: remove usage of ##__VA_ARGS__

'##__VA_ARGS' is a GNU extension, the usage of which in the testsuite of
libsframe may cause failure to build on platforms where the compiler may
not support the GNU extension.

This GNU extension swallows the preceding comma if the variable
arguments list is empty.  In libsframe testsuite though, an empty list
is never used.  Usages will remain of the following type:
  - TEST (cond, "string", vars);
or
  - TEST (cond, "string");

Mailing list discussion:
https://sourceware.org/pipermail/binutils/2025-November/145825.html

PR libsframe/33437

libsframe/testsuite/
PR libsframe/33437
* sframe-test.h: Replace ##__VA_ARGS__ with __VA_ARGS__.

PowerPC: Skip base type RTTI tests before inferior start

On PowerPC targets, RTTI typeinfo objects for simple base types such as
`int`, `char*`, and `const char*` may not be emitted until the inferior
has been started.  As a result, the `gdb.cp/typeid.exp` test fails when
checking typeid results before program execution begins.

This patch extends the existing Clang-specific logic that skips base type
RTTI checks before the inferior starts, to also apply on PowerPC.  This
ensures consistent test behavior across compilers and targets.

gdb/testsuite/
    * gdb.cp/typeid.exp (do_typeid_tests): Skip base type RTTI tests
    before inferior start on PowerPC.

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

libsframe: bugfix in flip_sframe

A previous commit bdb0d62281a to make flip_fde version aware added a new
argument for passing the remaning buffer size to the involved functions.
Fix the passed value to the intended.

libsframe/
        * sframe.c (flip_sframe): Correct the passed value of buf size.

Automatic date update in version.in

gdb/solib-svr4: remove unnecessary assert and variable

I don't think this assert adds any value.

Change-Id: Ibc12566f97bf9b7c091967a34b74d2b76c2b8e54
Cc: Lancelot SIX <lancelot.six@amd.com>

gdb: replace FRAME_OBSTACK_{C,Z}ALLOC macros with templated functions

While reviewing a patch, I saw these macros and thought they could be
modernized a bit.

Change-Id: I540edbcfd2e1e3cfd6afa0e911f43c8b89862414

LoongArch: set PRSTATUS_SIZE=0x1e0 to match kernel's struct elf_prstatus size

As PRSTATUS_SIZE is now with the value 0x1d8, which causes inconsistency with the kernel
definition and then can not lead to the correct branch for loongarch64 backend.

With the correct value 0x1e0 for the master branch, the loongarch64 banckend will work well.

Signed-off-by: Li Jian <lijian1@kylinos.cn>

hppa64: Fix bogus warning from elf_hppa_final_link_relocate

2025-11-24  John David Anglin  <danglin@gcc.gnu.org>

bfd/ChangeLog:

* elf64-hppa.c (elf_hppa_final_link_relocate): Initialize opd_off.

Automatic date update in version.in

hppa64: Fix R_PARISC_LTOFF_FPTR64 and R_PARISC_LTOFF_TP64 relocation support

The elf_hppa_final_link_relocate function didn't handle
R_PARISC_LTOFF_FPTR64 and R_PARISC_LTOFF_TP64 relocations
for local symbols.

DLT and OPD output relocation support for local symbols is
consolidated in elf_hppa_dlt_dynrel_reloc() and
elf_hppa_opd_dynrel_relocs().

2025-11-24  John David Anglin  <danglin@gcc.gnu.org>

bfd/ChangeLog:

* elf64-hppa.c (elf_hppa_dlt_dynrel_reloc): New.
(elf_hppa_opd_dynrel_relocs): New.
(elf_hppa_final_link_relocate): Use elf_hppa_dlt_dynrel_reloc()
and elf_hppa_opd_dynrel_relocs().  Fix relocation support for
R_PARISC_LTOFF_FPTR64 and R_PARISC_LTOFF_TP64.

PR 33474 SEGV in init_reloc_cookie

This segfault is triggered by a tekhex input.

PR 33474
* elflink.c (bfd_elf_gc_sections): Don't try to parse .eh_frame
in non-ELF input files.

PR 33473 SEGV in _bfd_elf_gc_mark_debug_special_section_group

The code that faulted made the assumption that a group section always
had at least one valid member.  Fix that assumption.  Also fail if all
entries in a SHT_GROUP section are invalid.  (An empty group will not
result in a call to process_sht_group_entries.)

PR 33473
* elflink.x (_bfd_elf_gc_mark_debug_special_section_group): Don't
segfault on empty group.
* elf.c (process_sht_group_entries): Return false if all
entries are invalid.

replace tail with sed

The default Solaris tail doesn't support "tail -n +4", apparently.
Use sed instead.

PR 33396
* testsuite/binutils-all/objdump.exp: Replace tail with an
equivalent sed expression in dwarf5 objdump -Wi test.

bogus FAILs from mmix ld testsuite

Get rid of [^c][^h][^i][^l][^d] from error regex.  It won't match
/home/... and other legitimate paths printed for the program name of
the ld under test.

* testsuite/ld-mmix/bpo-15.d: Fix error regex.
* testsuite/ld-mmix/bpo-15m.d: Likewise.
* testsuite/ld-mmix/bpo-21.d: Likewise.
* testsuite/ld-mmix/bpo-21m.d: Likewise.

Use version index 1 for defined symbols

It's reasonable to use version index 0 for undefined
symbols, so let's continue doing that.  For defined (global)
symbols that aren't otherwise versioned continue using
VER_NDX_GLOBAL (partly reverting behaviour introduced in
commit f685e395).

bfd/
PR ld/33577
* elflink.c (elf_link_output_extsym): Don't set noversion
for defined syms.

ld/
PR ld/33577
* ld-elfvers/vers16.dsym: Add back the "Base" version for
defined syms.

Make readelf not print 'foo@@' for normal symbols

when a symbol 'foo' is exported and non-hidden and hence is
available for resolving from other objects it's unreasonable
for readelf to print it as 'foo@@'.  If it's not available
for unversioned resolving because its version is hidden
(but without name), then continue printing it as 'foo@' to
indicate that something special goes on.

aarch64: constify BTI and GCS report functions

This patch consitifies the arguments of the functions used to report BTI
and GCS errors, and also renames the argument "ebfd" to "abfd" as this
naming is confusing and inconsistent with others places.

gas: move code for object attribute parsing into obj-elf-attr.c

Gas, contrarilly to others binutils tools, is compiled for a specific
target. Some targets don't support Object Attributes (OAs). For those
cases, today the OA directive ".gnu_attribute" is still enabled but the
processing would probably fail in most of cases because the named tag
would be unknown. Most of the parsing code on such a target can be
considered as dead code.

This patch aims at removing this dead code from Gas when the target does
not support the OAs by:
- moving the code of OA parsing into a separate file under gas/config
  which is only included for the relevant targets supporting OAs.
- disabling the code related to OAs on non-OA target via a TC_OBJ_ATTR
  macro.

Adding/removing the OA feature from Gas for a specific target can easilly
be done from tc-<arch>.h by changing the values of TC_OBJ_ATTR: 1 enabled,
0 disabled. You might also want to guard the enablement of OAs only for
ELF targets with OBJ_ELF (see example below).

\#ifdef OBJ_ELF
/* The target supports Object Attributes.  */
\#define TC_OBJ_ATTR 1
\#endif

bfd: rename parsing methods of object attribute v1 API

This patch is a preparation for the introduction of object attributes
v2. It aims at:
- making clear what methods are used to parse OAv1
- adding more constaints on parameters type by using enums instead of
defines.
- hiding the attribute tag type behind a typedef.
- preparing the move of object attributes's parsing code to another
  file.

Note: the name obj_attr_v1_process_attribute is exposed in the API.
Ideally, the version should not be part of the name, and be hidden
behind a macro. However, a later patch will unify the parsing of
OAv1 and OAv2, and will make the use of such a macro obsolete.