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.

bfd: rename old references to build attributes

A previous refactoring patch [1] introduced "build_attributes" in the
functions naming. However this naming is specific to the AArch64 Build
Attributes specification, and should be replaced by "object_attributes"
going forward.

[1]: 011e50143f0ec1be271f93facb56def9394947d2

RISC-V: Tidy and aligned riscv_supported_std_[z|x]_ext tables

gdb: resolve dynamic type in one value_cast case

This particular path for value_cast does not attempt to resolve a
dynamic target type before assigning it to the new value.  Having a
value with a dynamic type that hasn't been resolved causes an assert
later, when printing the value.  For instance, running the added test
without the fix yields:

    (gdb) p (outer_type) g_outer_as_char_array
    $7 = ( /home/smarchi/src/binutils-gdb/gdb/value.c:3111: internal-error: primitive_field: Assertion `type->dyn_prop (DYN_PROP_DATA_LOCATION)->is_constant ()' failed.

This code path is taken when the value being cast has the same size as
the target type, and no earlier more specific rule matched.  Fix it by
adding a call to resolve_dynamic_type before assigning the target type
to the value.

The test exercises this by defining a char array
(`g_outer_as_char_array`) with the same size as `outer_type` in the
DWARF info, then casting it to `outer_type`.  Without the fix, this
triggers the assertion when printing the result.

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

gdb: force lval_memory for value components with dynamic data location

Using the test program from the added test, I get this internal error:

    $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.dwarf2/data-loc-cast/data-loc-cast -ex "with language fortran -- p (outer_type) g_outer_var" -batch
    $1 = ( /home/smarchi/src/binutils-gdb/gdb/value.c:1697: internal-error: set_component_location: Assertion `this->lval () == lval_memory' failed.

The test added by this patch mimics a problem that was reported when
debugging a Fortran program.  The situation is:

 - The DWARF defines a Fortran-style array type, with a
   DW_AT_data_location attribute.
 - It then defines a structure type (outer_type) with a field
   (outer_type::assoc) of that array type.
 - Trying to cast a minimal symbol (g_outer_var) to that structure type
   leads to the internal error shown above.

The use case for this is: for some reason, a variable of type S isn't
described in the debug info, but GDB still knows about type S.  The user
is trying to say: I know that the variable at this address is an S, show
it to me.

A Fortran-style array doesn't hold the data directly.  It's a structure
(a descriptor) that contains a pointer to the data and possible other
properties, like the length of the array.  The DW_AT_data_location
attribute contains a DWARF expression that yields the location the
actual data, given the location of the descriptor.  In GDB's type
system, this translates to a dynamic property of kind
DYN_PROP_DATA_LOCATION pointing to the DWARF expression.  Before
instantiating a value with such a dynamic type, the dynamic type must
first be resolved, which is done by function resolve_dynamic_type.  That
is, for each dynamic property, compute a concrete value for the specific
instance we're dealing with here.  The result of resolve_dynamic_type is
a type that is just like the input type, but where all dynamic
properties now have concrete, constant values.

Here's the timeline of what happens when doing "p (outer_type)
g_outer_var":

 1. We start in var_msym_value_operation::evaluate_for_cast.

 2. We go in function value_cast, in this branch:

      else if (arg2->lval () == lval_memory)
return value_at_lazy (to_type, arg2->address ());

    ... where to_type is the "outer_type" structure and arg2 is the
    minsym.  This effectively builds a value pretending that there
    exists an instance of outer_type at the address of the minsym, which
    is what we want.  The resulting value is "lval_memory".

 3. Somewhere inside value_at_lazy, there is a call to
    resolve_dynamic_type:

    #0  resolve_dynamic_type (type=0x7e0ff1cfd560, valaddr=..., addr=0x4340, in_frame=0x7bfff0b3f100) at /home/smarchi/src/binutils-gdb/gdb/gdbtypes.c:3011
    #1  0x000055556687dcba in value_from_contents_and_address (type=0x7e0ff1cfd560, valaddr=0x0, address=0x4340, frame=...) at /home/smarchi/src/binutils-gdb/gdb/value.c:3669
    #2  0x00005555667ec527 in get_value_at (type=0x7e0ff1cfd560, addr=0x4340, frame=..., lazy=1) at /home/smarchi/src/binutils-gdb/gdb/valops.c:992
    #3  0x00005555667ec79f in value_at_lazy (type=0x7e0ff1cfd560, addr=0x4340, frame=...) at /home/smarchi/src/binutils-gdb/gdb/valops.c:1039
    #4  0x00005555667e902b in value_cast (type=0x7e0ff1cfd560, arg2=0x7d0ff1c35540) at /home/smarchi/src/binutils-gdb/gdb/valops.c:645

    This is good, it returns a structure type where the type of field
    "assoc" has a constant DYN_PROP_DATA_LOCATION property that holds
    the memory address where the data for this array resides.

 4. Back in var_msym_value_operation::evaluate_for_cast, we do:

      val = value_cast (to_type, val);

      /* Don't allow e.g. '&(int)var_with_no_debug_info'.  */
      if (val->lval () == lval_memory)
        {
          if (val->lazy ())
            val->fetch_lazy ();
          val->set_lval (not_lval);
        }

    This is meant to make GDB behave more or less like C, where the
    result of a cast is not an lvalue, of which you can't take the
    address, for instance.  I am not an expert in this area, but Pedro
    explained that this lval thing in GDB actually conflates two things:

      - where is the value (memory, register, only in GDB's mind, etc)
      - is this an lvalue (is it assignable, can you take its address,
etc)

    Here, we would ideally want to say that the value is not an lvalue,
    but still say that it lives at a given address in memory.  But since
    the two concepts are conflated, we set it to "not_lval", which means
    "not an lval and does not exist on target".

    If there was a way to say "non-lvalue" and "in memory", I think that
    the bug that follows would be hidden.

 5. When printing the value, the value-printing code attempts to fetch
    the "assoc" field of the struct using value::primitive_field, which
    then goes into value::set_component_location.  In
    set_component_location there is this code, which is where we find
    the assert that fails:

      /* If the COMPONENT has a dynamic location, and is an
 lval_internalvar_component, then we change it to a lval_memory.

 Usually a component of an internalvar is created non-lazy, and has
 its content immediately copied from the parent internalvar.
 However, for components with a dynamic location, the content of
 the component is not contained within the parent, but is instead
 accessed indirectly.  Further, the component will be created as a
 lazy value.

 By changing the type of the component to lval_memory we ensure
 that value_fetch_lazy can successfully load the component.

 This solution isn't ideal, but a real fix would require values to
 carry around both the parent value contents, and the contents of
 any dynamic fields within the parent.  This is a substantial
 change to how values work in GDB.  */
      if (this->lval () == lval_internalvar_component)
{
  gdb_assert (lazy ());
  m_lval = lval_memory;
}
      else
gdb_assert (this->lval () == lval_memory);

    I think that what this comment is really trying to say is: if a
    structure is an internalvar, and a field of that structure has a
    dynamic data location, then the actual data is not contained in the
    internalvar, it is in memory.

    The message for the commit that introduced that code (3c8c6de21da
    "gdb: user variables with components of dynamic type")) confirms it,
    I think.  The message also goes on to explain that we could imagine
    a world where the internalvar outer struct value would also capture
    the (indirect) contents of the array field.  The internalvar value
    would then be completely self-contained.  I imagine this could be
    useful in some cases, but we don't have that today.

    The comment makes it sound like it's a hack, but I actually think it
    makes sense.  This is what is really happening.

    This all assumes that the result of the DW_AT_data_location is a
    location in memory.  I guess this is true for all practical purposes
    today, but it would be possible for DW_AT_data_location to yield a
    register, a composite, or even "undefined" (meaning optimized out)
    as  a location (which would be even easier to implement with the
    upcoming DWARF 6 "Location descriptions on the DWARF stack" feature
    [1]).  In that case, the location that we set for the array
    component should reflect whatever the DWARF expression returned.
    But that is future work, for now, we assume that the data location
    can only be in memory.

So, the fix is basically to always set the location of a value
sub-component to "memory", because we assume (for now) that the result
of all DW_AT_data_location expressions will be memory locations.

Now, referring back to point 4 above: if the code in
var_msym_value_operation::evaluate_for_cast could in fact set the value
to "non-lvalue in memory", then we wouldn't hit the assert in
value::set_component_location, because the subcomponent would have
inherited lval_memory from the parent structure.  However, I still think
that the fix in this patch is valid on its own.  Imagine that the DWARF
says that the outer struct (and thus the array descriptor) is in a
register.  Once we evaluate the DW_AT_data_location of the array field,
the value describing the actual data is still in memory.

The takeaway is that regardless of the location of the descriptor, the
DW_AT_data_location expression always returns a memory location (for
now), so we should always set the location of that value to memory.  In
other words, we apply the same logic as commit 3c8c6de21da regardless of
the location of the outer value".

Finally, a note about the test:  I made the array content very long (100
elements), because I did spot some issues where GDB would conflate the
size of the array data with the size of the array field, within the
outer structure.  The test does not expose these issues and I didn't try
to fix them here (one thing at a time), but making the array size very
large might help spot these issues in the future.

[1] https://dwarfstd.org/issues/230524.1.html

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

elf: Verify base symbol version works properly

Add a testcase to verify that VER_NDX_GLOBAL can be used with

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

to create the base version to provide an unversioned compatible symbol.

PR ld/33577
* testsuite/ld-elfvers/pass.out: New file.
* testsuite/ld-elfvers/pr33577-unversioned.c: Likewise.
* testsuite/ld-elfvers/pr33577-unversioned.rd: Likewise.
* testsuite/ld-elfvers/pr33577-versioned.c: Likewise.
* testsuite/ld-elfvers/pr33577-versioned.rd: Likewise.
* testsuite/ld-elfvers/pr33577.map: Likewise.
* testsuite/ld-elfvers/pr33577a.c: Likewise.
* testsuite/ld-elfvers/pr33577b.c: Likewise.
* testsuite/ld-elfvers/vers.exp: Run ld/33577 tests.

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

Automatic date update in version.in

Remove a call to blockvector::map

block_starting_point_at checks blockvector::map before doing a lookup.

This patch removes this call, a step toward making the blockvector API
a bit more opaque.  It arranges to find the necessary blockvector just
once, in gather_inline_frames, and then uses the 'lookup' method to
find the desired block.

Note that this is a slight change of semantics, in that the old code
looked only in the map while the new code looks in the blockvector,
regardless of whether a map was made.  However, I don't think this
should matter, and furthermore this seems like an abstraction
violation, with the inline-frame code knowing details of how buildsym
decided to create the blockvector.

in the longer run, I think only the 'lookup' method should be provided
by blockvector -- that is, separately checking the map should be
impossible.  The idea here is that eventually, for lazy CU expansion,
we will want to be able to expand the blockvector.  This may be easier
with a different underlying data structure, so perhaps the map will go
away entirely.  After this patch, one such use remains.

Regression tested on x86-64 Fedora 40.

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

[gdb/testsuite] Fix whitespace issues

This is the result of:
...
$ git rm -rf gdb/testsuite
$ git commit -a -m tmp
$ git revert HEAD
$ git rebase --whitespace=fix HEAD^
...

Tested on x86_64-linux.

PR build/33616
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33616

[gdb/build, c++20] Fix deprecated implicit capture in cooked_index::set_contents

Fix deprecated implicit capture of this in cooked_index::set_contents, by
removing the capture default, and explicitly listing all captures.

Tested on x86_64-linux.

Automatic date update in version.in

Change dw2_search_one to be static

I noticed that dw2_search_one can be static.  Tested by rebuilding.

[gdb/testsuite] Rewrite strings in gdb.ada/unchecked_union.exp

In test-case gdb.ada/unchecked_union.exp, git --check reports some whitespace
issues:
...
$ git diff-tree --check $(git hash-object -t tree /dev/null) HEAD \
    -- gdb/testsuite/gdb.ada/unchecked_union.exp \
    | grep -c "indent with spaces"
12
...

The problem is that this style of string is used containing space-indented
text:
...
set inner_string {    case ? is
        when 0 =>
            small: range 0 .. 255;
            second: range 0 .. 255;
        when ? =>
            bval: range 0 .. 255;
        when others =>
            large: range 255 .. 510;
            more: range 255 .. 510;
    end case;
}
...

Fix this by changing the string into a list of strings:
...
set inner_string \
    [list \
 "    case ? is" \
 "        when 0 =>" \
 "            small: range 0 .. 255;" \
 "            second: range 0 .. 255;" \
 "        when ? =>" \
 "            bval: range 0 .. 255;" \
 "        when others =>" \
 "            large: range 255 .. 510;" \
 "            more: range 255 .. 510;" \
 "    end case;"]
...
which also fixes the odd position of the first line in the original version.

Tested on x86_64-linux.

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

gprofng: disable LTO as a workaround

Temporarily disable LTO by passing -fno-lto until PR32092 is fixed,
as we get test failures and seemingly a completely broken gprofng otherwise.

Use the same idiom as libdecnumber for -fno-lto.

gprofng/
PR gprofng/32092

* Makefile.am: Pass -fno-lto if supported.
* Makefile.in: Regenerate.
* configure: Regenerate.
* configure.ac: Pass -fno-lto if supported.
* doc/Makefile.in: Regenerate.
* gp-display-html/Makefile.in: Regenerate.
* libcollector/Makefile.am: Pass -fno-lto if supported.
* libcollector/Makefile.in: Regenerate.
* src/Makefile.am: Pass -fno-lto if supported.
* src/Makefile.in: Regenerate.

Re: dlltool memory leaks

I missed one needed strdup of symbol names, needed since the original
symbol name memory is freed on bfd_close.

PR 33651
* dlltool.c (scan_filtered_symbols): xstrdup symbol name.

Automatic date update in version.in

PR 33639 .debug_loclists output

The fuzzed testcase in this PR prints an almost endless table of
offsets, due to a bogus offset count.  Limit that count, and the total
length too.

PR 33639
* dwarf.c (display_loclists_unit_header): Return error on
length too small to read header.  Limit length to section
size.  Limit offset count similarly.

PR 33638, debug_rnglists output

The fuzzed testcase in this PR continuously outputs an error about
the debug_rnglists header.  Fixed by taking notice of the error and
stopping output.  The patch also limits the length in all cases, not
just when a relocation is present, and limits the offset entry count
read from the header.  I removed the warning and the test for relocs
because the code can't work reliably with unresolved relocs in the
length field.

PR 33638
* dwarf.c (display_debug_rnglists_list): Return bool.  Rename
"inital_length" to plain "length".  Verify length is large
enough to read header.  Limit length to rest of section.
Similarly limit offset_entry_count.
(display_debug_ranges): Check display_debug_rnglists_unit_header
return status.  Stop output on error.

som foreign syms

The makes use of the copy_private_symbol_data change in order to
prevent bogus writes seen when running objcopy with binary input and
som output.  It doesn't fix "FAIL: binary symbol", because the som
backend also doesn't copy binary sections to the output, a fact that I
didn't notice until I'd gone quite some way into fixing symbols..

* som.c (som_bfd_copy_private_symbol_data): Make som symbols
for non-som input.

bfd_copy_private_symbol_data

Allow copy_private_symbol_data to replace osym if a target desires.
Change isym similarly for symmetry.  The idea is to make it possible
to give the asymbol an output target specific extension.  Some
targets, eg. som, use such an extension when outputting symbols,
behaving badly if the input object is not som.  There are no
functional changes in this patch; It just changes the signatures.

bfd/
* elf-bfd.h (_bfd_elf_copy_private_symbol_data): Replace
asymbol* params with asymbol**.
* elf.c (_bfd_elf_copy_private_symbol_data): Likewise.
* libbfd-in.h (_bfd_bool_bfd_asymbol_bfd_asymbol_true): Likewise.
* libbfd.c (_bfd_bool_bfd_asymbol_bfd_asymbol_true): Likewise.
* mach-o.c (bfd_mach_o_bfd_copy_private_symbol_data): Likewise.
* mach-o.h (bfd_mach_o_bfd_copy_private_symbol_data): Likewise.
* plugin.c (bfd_plugin_bfd_copy_private_symbol_data): Likewise.
* som.c (som_bfd_copy_private_symbol_data): Likewise.
* targets.c (bfd_target <_bfd_copy_private_symbol_data>): Likewise.
* bfd-in2.h: Regenerate.
* libbfd.h: Regenerate.
binutils/
* objcopy.c (copy_object): Adjust bfd_copy_private_symbol_data call.
gas/
* symbols.c symbol_clone): Adjust bfd_copy_private_symbol_data call.

copy_private and merge_private functions

These are all called via BFD_SEND on the output bfd xvec.  Thus there
is no need to verify the output bfd flavour.  There *is* a need to
verify the input bfd flavour.  Also of course target specific data
shouldn't be accessed until the input target is verified.  Tidy these
issues in many places.

bfd_copy_private_section_data, bfd_copy_private_symbol_data, and
bfd_merge_private_bfd_data are macros.  Delete prototypes created via
synopsis entry in comments.

* aout-target.h (MY_bfd_copy_private_section_data): Remove
unnecessary output bfd flavour check.
* coff-arm.c (coff_arm_merge_private_bfd_data): Likewise.
* elf-m10300.c (_bfd_mn10300_elf_merge_private_bfd_data): Likewise.
* ecoff.c (_bfd_ecoff_bfd_copy_private_bfd_data): Likewise, and
move setup of pointers into target specific data after check.
* elf.c (_bfd_elf_copy_private_bfd_data): Likewise.
(_bfd_elf_copy_private_symbol_data): Likewise.
(copy_private_bfd_data): Remove checks duplicating those done
in caller.
(_bfd_elf_copy_private_section_data): Remove unnecessary
output bfd flavour check.
(_bfd_elf_copy_private_header_data): Likewise.
* elf32-arc.c (arc_elf_print_private_bfd_data): Likewise.
(arc_elf_merge_private_bfd_data): Likewise.
* elf32-arm.c (elf32_arm_copy_private_bfd_data): Likewise.
(elf32_arm_merge_private_bfd_data): Likewise.
* elf32-cr16.c (_bfd_cr16_elf_merge_private_bfd_data): Likewise.
* elf32-cris.c (cris_elf_merge_private_bfd_data): Likewise.
(cris_elf_merge_private_bfd_data): Likewise.
* elf32-csky.c (csky_elf_merge_private_bfd_data): Likewise.
* elf32-h8300.c (elf32_h8_merge_private_bfd_data): Likewise.
* elf32-lm32.c (lm32_elf_fdpic_copy_private_bfd_data): Likewise.
* elf32-m32r.c (m32r_elf_merge_private_bfd_data): Likewise.
* elf32-m68hc1x.c (_bfd_m68hc11_elf_merge_private_bfd_data): Likewise.
* elf32-m68k.c (elf32_m68k_merge_private_bfd_data): Likewise.
* elf32-mcore.c (mcore_elf_merge_private_bfd_data): Likewise.
* elf32-nds32.c (nds32_elf_merge_private_bfd_data): Likewise.
* elf32-or1k.c (elf32_or1k_merge_private_bfd_data): Likewise, and
move setup of pointers into target specific data after check.
* elf32-ppc.c (ppc_elf_merge_private_bfd_data): Remove unnecessary
output bfd flavour check.
* elf32-s390.c (elf32_s390_merge_private_bfd_data): Likewise.
* elf32-score.c (s3_elf32_score_merge_private_bfd_data): Likewise,
and move check before target specific data accesss.
* elf32-sh.c (sh_elf_copy_private_data): Remove unnecessary
output bfd flavour check.
(sh_elf_merge_private_data): Likewise.
* elf32-sparc.c (elf32_sparc_merge_private_bfd_data): Likewise.
* elf32-v850.c (v850_elf_merge_private_bfd_data): Likewise.
* elf32-vax.c (elf32_vax_merge_private_bfd_data): Likewise.
* elf32-visium.c (visium_elf_copy_private_bfd_data): Likewise.
* elf32-xtensa.c (elf_xtensa_merge_private_bfd_data): Likewise.
* elf64-ia64-vms.c (elf64_ia64_merge_private_bfd_data): Likewise.
* elf64-ppc.c (ppc64_elf_merge_private_bfd_data): Likewise.
* elf64-s390.c (elf64_s390_merge_private_bfd_data): Likewise.
* elf64-sparc.c (elf64_sparc_merge_private_bfd_data): Likewise.
* elfnn-aarch64.c (elfNN_aarch64_merge_private_bfd_data): Likewise.
* elfnn-ia64.c (elfNN_ia64_merge_private_bfd_data): Likewise.
* elfnn-kvx.c (elfNN_kvx_merge_private_bfd_data): Likewise.
* elfnn-loongarch.c (elfNN_loongarch_merge_private_bfd_data): Likewise.
* elfnn-riscv.c (_bfd_riscv_elf_merge_private_bfd_data): Likewise.
* elfxx-mips.c (_bfd_mips_elf_merge_private_bfd_data): Likewise.
* mach-o.c (bfd_mach_o_bfd_copy_private_section_data): Likewise.
(bfd_mach_o_bfd_copy_private_header_data): Likewise.
* mmo.c (mmo_bfd_copy_private_bfd_data): Likewise.
* peXXigen.c (_bfd_XX_bfd_copy_private_bfd_data_common): Likewise.
(_bfd_XX_bfd_copy_private_section_data): Likewise.
* som.c (som_bfd_copy_private_section_data): Likewise.
(som_bfd_copy_private_bfd_data): Likewise.
(som_bfd_copy_private_symbol_data): Likewise, and move setup
of pointers into target specific data after check.

* elf32-bfin.c (elf32_bfin_merge_private_bfd_data): Check
input bfd flavour.
* elf32-frv.c (frv_elf_merge_private_bfd_data): Likewise.
* elf32-iq2000.c (iq2000_elf_merge_private_bfd_data): Likewise.
* elf32-m32c.c (m32c_elf_merge_private_bfd_data): Likewise.
* elf32-mep.c (mep_elf_merge_private_bfd_data): Likewise.
* elf32-rl78.c (rl78_elf_merge_private_bfd_data): Likewise.
* elf32-rx.c (rx_elf_merge_private_bfd_data): Likewise.
* elf32-score7.c (s7_elf32_score_merge_private_bfd_data): Likewise.
* elf32-tic6x.c (elf32_tic6x_merge_private_bfd_data): Likewise.
* elf32-v850.c (v850_elf_copy_notes): Likewise.
* elf32-visium.c (visium_elf_merge_private_bfd_data): Likewise.
* mach-o.c (bfd_mach_o_bfd_copy_private_symbol_data): Likewise.

* linker.c (bfd_merge_private_bfd_data): Delete SYNOPSIS.
* section.c (bfd_copy_private_section_data): Likewise.
* syms.c (bfd_copy_private_symbol_data): Likewise.
* bfd-in2.h: Regenerate.

ecoff foreign syms

This fixes the alpha-linux-gnuecoff failures exposed by commit
35e1c33162bf.

* ecoff.c (ecoff_get_extr): Choose better symbol class for
non-ecoff symbols.

RISC-V: Fixed opcodes for some bitmanip instructions

Currently some of the instructions in bitmanip extensions can not be obtained
using DECLARE_INSN macros. I generated them using riscv-opcodes and added to
other opcodes.

Approved-By: Nelson Chu <nelson@rivosinc.com>

[gdb/corefiles] Fix segfault in add_thread_silent

A user reported a segfault when loading a core file [1].

The core file is from arm-linux, but I reproduced the segfault on
x86_64-linux:
...
$ gdb -q --core core

warning: Can't open file /usr/bin/rs_scope during file-backed mapping note processing

warning: Can't open file /lib/libc-2.26.so during file-backed mapping note processing

warning: File /lib/libgcc_s.so.1 doesn't match build-id from core-file during file-backed mapping processing

warning: Can't open file /lib/libm-2.26.so during file-backed mapping note processing

warning: Can't open file /usr/lib/libstdc++.so.6.0.28 during file-backed mapping note processing

warning: Can't open file /lib/libpthread-2.26.so during file-backed mapping note processing

warning: Can't open file /lib/ld-2.26.so during file-backed mapping note processing

Fatal signal: Segmentation fault
----- Backtrace -----
0x64a4ff gdb_internal_backtrace_1
gdb/bt-utils.c:122
0x64a59d _Z22gdb_internal_backtracev
gdb/bt-utils.c:175
0x9429e7 handle_fatal_signal
gdb/event-top.c:1013
0x942b96 handle_sigsegv
gdb/event-top.c:1090
0x7fbf6a64708f ???
/usr/src/debug/glibc-2.40/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x5eb453 _ZN9__gnu_cxx17__normal_iteratorIPKSt4pairI6ptid_tP11thread_infoESt6vectorIS5_SaIS5_EEEC4ERKS7_
/usr/include/c++/15/bits/stl_iterator.h:1059
0x5eb453 _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE3endEv
/usr/include/c++/15/bits/stl_vector.h:1029
0x5eae9e _ZNKSt6vectorISt4pairI6ptid_tP11thread_infoESaIS4_EE5emptyEv
/usr/include/c++/15/bits/stl_vector.h:1224
0xa77588 _ZNK6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE5emptyEv
gdb/../gdbsupport/unordered_dense.h:1351
0xa76533 _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE7do_findIS4_EEN9__gnu_cxx17__normal_iteratorIPSC_St6vectorISC_SD_EEERKT_
gdb/../gdbsupport/unordered_dense.h:1119
0xa74fef _ZN6ankerl15unordered_dense6v4_4_06detail5tableI6ptid_tP11thread_infoNS1_4hashIS4_vEESt8equal_toIS4_ESaISt4pairIS4_S6_EENS1_11bucket_type8standardELb0EE4findERKS4_
gdb/../gdbsupport/unordered_dense.h:1773
0xa6f787 _ZN8inferior11find_threadE6ptid_t
gdb/inferior.c:253
0xfc852a _Z17add_thread_silentP22process_stratum_target6ptid_t
gdb/thread.c:310
0x73b995 core_target_open
gdb/corelow.c:1111
0x73a095 _Z17core_file_commandPKci
gdb/corelow.c:708
0xb6cb38 catch_command_errors
gdb/main.c:510
0xb6e354 captured_main_1
gdb/main.c:1279
0xb6e9a2 captured_main
gdb/main.c:1372
0xb6eaa3 _Z8gdb_mainP18captured_main_args
gdb/main.c:1401
0x419704 main
gdb/gdb.c:38
...

The problem happens as follows.  In core_target_open, we do:
...
      if (thread == NULL)
        thread = add_thread_silent (target, ptid_t (CORELOW_PID));
...
and then in add_thread_silent:
...
struct thread_info *
add_thread_silent (process_stratum_target *targ, ptid_t ptid)
{
  gdb_assert (targ != nullptr);

  inferior *inf = find_inferior_ptid (targ, ptid);
...
find_inferior_ptid returns nullptr, which eventually causes the segfault.

So, why can't we find an inferior with CORELOW_PID?

A bit earlier in core_target_open, we do:
...
  /* Find (or fake) the pid for the process in this core file, and
     initialise the current inferior with that pid.  */
  bool fake_pid_p = false;
  int pid = bfd_core_file_pid (target->core_bfd ());
  if (pid == 0)
    {
      fake_pid_p = true;
      pid = CORELOW_PID;
    }

  inferior *inf = current_inferior ();
  gdb_assert (inf->pid == 0);
  inferior_appeared (inf, pid);
  inf->fake_pid_p = fake_pid_p;
...

The problem is that looking for an inferior using CORELOW_PID is correct in
case fake_pid_p == true, but otherwise not.

Fix this by using inf->pid instead:
...
- thread = add_thread_silent (target, ptid_t (CORELOW_PID));
+ thread = add_thread_silent (target, ptid_t (inf->pid));
...

Doing so enables us to continue to a gdb prompt:
...
Core was generated by `/usr/bin/rs_scope -d'.

⚠️ warning: Couldn't find general-purpose registers in core file.
(gdb)
...

The warning is emitted because the pseudo-section .reg is missing, because
elf32_arm_nabi_grok_prstatus expects the PRSTATUS note to have size 148, but
instead we have:
...
$ eu-readelf -n core | grep -i prstatus
  CORE                 156  PRSTATUS
  CORE                 156  PRSTATUS
  CORE                 156  PRSTATUS
  CORE                 156  PRSTATUS
...

I'm assuming this is a bug for CONFIG_BINFMT_ELF_FDPIC=y configurations, fixed
by v5.9 linux kernel commit 16aead81018c ("take fdpic-related parts of
elf_prstatus out").

The core was generated using a kernel with CONFIG_BINFMT_ELF_FDPIC=y and
v5.3.18.

We can try to work around this bug in elf32_arm_nabi_grok_prstatus, but
that's out of scope for this commit, which focuses on fixing the segfault.

Tested on x86_64-linux.

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

[1] https://bugzilla.suse.com/show_bug.cgi?id=1251213

gprofng: Remove public hz and whoami variables

Remove public hz and whoami variables. This fixes the errors when
building with --enable-shared.

gdb/testsuite: avoid pointer values in test names

A test added in:

  commit 91eee81d23537366bb6072c66f662ab46d88380a
  Date:   Tue Jan 21 17:22:04 2025 +0000

      gdb: include NT_I386_TLS note in generated core files

includes a pointer value in the test name.  The value changes from run
to run making it harder to compare test results.  Fix this by giving
the test an actual name.

There's no change to what is being tested with the commit.

bfd/COFF: mark a function exposed to ld as non-private

As a non-private function, _bfd_coff_read_internal_relocs() shouldn't have
a "_bfd_" prefix, but merely a "bfd_" one. Tidy arguments passed whle at
it.

bfd/PEI: mark internal functions hidden

This reduces the dynamic symbol table a bit (over a hundred symbols when
building all targets) and allows the compiler to be more aggressive about
inlining (as it sees fit, of course).

bfd/XCOFF: mark internal data hidden

This reduces the dynamic symbol table a bit (about a dozen symbols) and
allows the compiler to be more aggressive about inlining (as it sees fit,
of course).

bfd/ECOFF: mark internal functions hidden

This reduces the dynamic symbol table a bit (about 30 symbols) and allows
the compiler to be more aggressive about inlining (as it sees fit, of
course).

bfd/COFF: properly mark bfd_coff_{gc_sections,group_name}() as private

Add an underscore prefix and make them hidden.

bfd/COFF: mark internal functions hidden

This reduces the dynamic symbol table a bit (about 50 symbols) and allows
the compiler to be more aggressive about inlining (as it sees fit, of
course).

Automatic date update in version.in

gdb/dwarf2: add dwarf2_get_symbol_read_needs selftest

Add a test for the fix introduced by commit cc27559a20f4 ("Fix dwarf2
"assertion failed" on bra without skip dwarf expression op").

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

gdb: include NT_I386_TLS note in generated core files

This commit extends GDB for x86/Linux to include the NT_I386_TLS note
in generated core files (i.e. created with `generate-core-file` or
`gcore` command).  This note contains the 3 per-thread TLS related
GDT (global descriptor table) entries, and is present for i386
binaries, or those compiled on x86-64 with -m32.

The approach I have taken to achieve this, is to make the 3 GDT
entries available within 3 new registers.  I added these registers to
the org.gnu.gdb.i386.linux target description feature, as this feature
seemed perfectly named.  As the new registers are optional I don't see
any harm in extending this existing feature.  I did consider adding a
new feature with `tls` in the name, but this seemed excessive given
the existing feature.

Which GDT entries are used for TLS varies between i386 and x86-64
running in 32-bit mode.  As such the registers are named with suffixes
0, 1, and 2, and it is left to GDB or gdbserver, to find the correct
GDT entries (based on the precise target) and place the contents into
these registers.

With this done, adding the relevant regset is sufficient to get the
tls contents emitted as a core file note.  Support for emitting the
note into the generated core file relies on some BFD changes which
were made in an earlier commit:

  commit ea6ec00ff4520895735e4913cb90c933c7296f04
  Date:   Fri Jul 25 19:51:58 2025 +0100

      bfd: support for NT_386_TLS notes

The three new registers are readable and writable.  Writing to one of
the new registers will update the relevant kernel GDT entry.

Each TLS GDT is represented by a 'struct user_desc' (see 'man 2
get_thread_area' for details), the first 4 bytes of each 'user_desc'
is the 'entry_number' field, this is the index of the GDT within the
kernel, and cannot be modified.  Attempts to write to this region of
the register will be ignored, but will not give an error.

I did consider not including this part of the user_desc within the
register value, but this becomes difficult when we consider remote
targets, GDB would then need to figure out what these indexes were so
that the core file note could be generated.  Sure, we probably could
figure the correct index values out, but I figure, why bother, we can
just pass them through in the register and know for certain that we
have the correct values.

For testing, there's a new test that covers the basic functionality,
including read/write access to the new registers, and checking that
the NT_386_TLS note is added to the core file, and that the note
contents can be read by GDB.

I also manually tested opening a core file generated from an old
GDB (so no NT_386_TLS notes) using a GDB with this patch.  This works
fine, the new tls registers are not created as the NT_GDB_TDESC
note (the target description) doesn't include the new registers.

Out of interest I also patched an old version of GDB to avoid creating
the NT_GDB_TDESC, and created a core file.  This core file contained
neither the NT_386_TLS nor NT_GDB_TDESC.  When opening this core file
with a patched GDB, the new registers do show up, but their contents
are given as <unavailable>, which is exactly what we'd expect, GDB
builds a target description based on the architecture, the
architecture says these registers should exist, but they are missing
from the core file, hence, <unavailable>.

I also tested using a patched GDB with an old version of gdbserver,
the new registers don't show up as the old gdbserver doesn't send them
in its target description.  And a core file created using the gcore
command in such a setup leaves no NT_386_TLS notes added, which is
what we'd expect.

And I also tested a new gdbserver running with an old version of GDB.
As the new tls registers are now mentioned in the target description,
then obviously, the old GDB does see the registers, and present them
to the user, however GDB doesn't know how to use these registers to
create a NT_386_TLS, so that note isn't added to any core files.
Also, while a new GDB places the tls registers into the 'system'
group, an old GDB doesn't do this, so the registers end up in the
'general' group by default.  This means they show up within 'info
registers' output.  This isn't ideal, but there's not much that can be
done about this.

Overall, I feel the combinations of old and new tools has been tested,
and the behaviours are what we'd want or expect.

I'm tagging this commit with PR gdb/15591, even though this patch
isn't directly related.  That bug is for improving GDB's testing of
TLS support in core files.  The test in this commit does do some very
simple reading of a TLS variable, but there's only two threads, and
one TLS variable, so it's not extensive.  Additionally, the test in
this commit is x86 only, so this should not be considered a full
resolution to that bug.  But still, it's something.

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

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
Reviewed-By: Keith Seitz <keiths@redhat.com>

Do not apply properties to arch-allocated types

A user reported that gdb would crash when debugging a certain Fortran
executable.

The bug is that the DWARF reader may try to apply dynamic properties
to an arch-allocated type.  This came as a bit of a surprise, but the
issue is that the function-type-allocation code could end up creating
an arch-owned type, when the return type is arch-owned.

This patch fixes the problem, and any other potential future problems,
by arranging for all types created by the DWARF reader to be
objfile-owned.

A better long-term solution might be the fabled "type GC", where the
arch/objfile distinction is finally removed.  However, this is more
difficult to implement.

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

Fix dwarf2 "assertion failed" on bra without skip dwarf expression op

When interpreting dwarf expressions, the function
dwarf2_get_symbol_read_needs walks over all instructions via
the call graph by using a to-visit and a visited list.
Upon reaching a bra operation, it pushes both the next op and the
branch target into the to-visit list.
If the branch-target can be reached linearly from the next op,
the branch-target will be visited twice.

At the top of the visit-loop, there is an assertion that a visited
instruction must never be visited again.
This assertion fails in the above case.

For example a DIE with DW_AT_location: 30 31 28 0 0 9f
(DW_OP_lit0; DW_OP_lit1; DW_OP_bra: 0; DW_OP_stack_value)
will result in
.././binutils-gdb/gdb/dwarf2/loc.c:1905: internal-error: dwarf2_get_symbol_read_needs: Assertion `visited_ops.find (op_ptr) == visited_ops.end ()' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

Adding a skip operation which makes the branch-target not linearly
accessible from the next op, makes the example work. For example a
DIE with DW_AT_location: 32 31 28 3 0 2f 1 0 96 9f (DW_OP_lit2;
DW_OP_lit1; DW_OP_bra: 3; DW_OP_skip: 1; DW_OP_nop; DW_OP_stack_value)
produces the correct result $1 = 2.

This patch replaces the failing assertion with a continue to properly
skip an already visited dwarf expression op.
This makes the first example work correctly and result in $1 = 0.

Running the testsuite resulted in different results upon every run
(arch-linux 6.17.7-arch1-1 x86_64).
Comparing the results of 3 runs of the unmodified code with three
runs containing the fix does not yield a significant difference:

unmodified version: # of expected passes 126821, 126813, 126838
fix version: # of expected passes 126866, 126801, 126817

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

gprofng: Remove runstatedir from Makefile.in

Signed-off-by: Claudiu Zissulescu <claudiu.zissulescu-ianculescu@oracle.com>

gprofng: Add gprofng gmon conversion command test

gprofng: Add documentation on converting gmon files.

Signed-off-by: Claudiu Zissulescu <claudiu.zissulescu-ianculescu@oracle.com>

gprofng: New tool for converting gmon.out file to experiments

This patch introduces the capability to convert a gmon.out file into a
gprofng experiment.

The gmon.out file format includes a histogram record, a call graph
record, and basic block execution count records. A gprofng experiment
folder consists of various files, of which four are particularly
important:

  - log.xml: Contains the profile timer setup and defines the profile
    data structure fields.

  - map.xml: Contains the memory map information of the profiled
    executable.

  - profile: Holds the time profile information.

  - data.frameinfo: Records the stack trace at a specific sampling
    moment, with each trace linked to the time profile information
    stored in the profile file.

This patch adds a new tool to gprofng that reads the gmon.out file and
the profiled executable. With the executable, we can reconstruct
information about the profiled symbols and the memory map layout. The
gmon.out file provides details about the execution duration for each
symbol, as well as data used to build the call graph. This new patch
is a subcommand for the display command.

New gmon subcommand options:

 --version           print the version number and exit.
 -h/--help           print usage information and exit.

 -o <exp_name>     specify the name for (and path to) the experiment directory; the
   the default path is the current directory.

 -O <exp_name>     the same as -o, but unlike the -o option, silently overwrite an
   existing experiment directory with the same name.

The new tool can be executed using the command line:
$ gprofng display gmon EXEC_FILE GMON_FILE

N.B. If EXEC_FILE or GMON_FILE is missing the default a.out and
gmon.out names are considered.

Upon successful execution, an experiment file is created that can be
processed with existing gprofng tools. For example:
$ gprofng display text -calltree EXPERIMENT

This command will display the call tree from the converted gmon file.

Signed-off-by: Claudiu Zissulescu <claudiu.zissulescu-ianculescu@oracle.com>

[contrib] Accept _("") and operator() in check_GNU_style_lib.py

Currently contrib/check_GNU_style_lib.py warns about '_("foo")', expecting
'_ ("foo")' instead:
...
$ cat tmp.patch
  ...
+const char *
+foo (void)
+{
+  return _("foo");
+}
$ ./contrib/check_GNU_style.py tmp.patch
=== ERROR type #1: there should be exactly one space between function name \
  and parenthesis (1 error(s)) ===
test.c:4:10:  return _("foo");
$
...

However '_("")' is an exception [1] to the rule, so skip the ERROR in this
case.

Likewise for 'operator()', which seems common enough:
...
$ find gdb* -type f \
    | egrep -v '/testsuite/|ChangeLog' \
    | xargs grep "::operator()" \
    | wc -l
27
...
for example in gdb/dwarf2/read.c:
...
dwo_file_hash::operator() (const dwo_file_up &file) const noexcept
...

[1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#Gettext_macro

[contrib] Fix typo in check_GNU_style_lib.py

Fix typo: TrailinigOperatorCheck -> TrailingOperatorCheck.

Automatic date update in version.in

Remove section_offsets typedef

This patch removes the section_offsets typedef, in favor of using
either std::vector or gdb::array_view as appropriate.

v2: preserve const-ness when creating views

Regression tested on x86-64 Fedora 40.

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

Return bool from block_starting_point_at

This changes block_starting_point_at to return bool.

gdb/dwarf: use offset in dwarf_expr_context::read_mem

The `offset` variable is the offset within the passed-in object where
`addr` falls.  We use it to verify whether `addr` falls within that
object's bounds, but then the memcpy fails to consider it, meaning that
we always copy from the beginning of the passed-in object, even if
`addr` lands in the middle of the object.  Fix that by adding `offset`
to the source argument of the memcpy.  I caught this by writing a patch
later in this series, so this fix is covered by the test added in that
later patch.

Also, I find it a bit odd to compute the offset of `addr` within the
passed-in object, before knowing if `addr` even lands within the
passed-in object's address range.  If `addr` is before the object's
address, it does an unsigned underflow, which I guess works, but is not
really intuitive.  Change it to check whether `addr` falls within the
object first, and if so, compute the offset of `addr` within the object.

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

Make blockvector a little more self-contained

This patch changes blockvector to be a little more self-contained.

The idea here is that code outside of blockvector shouldn't really
know how it operates.  After this patch, this still doesn't fully
happen -- a couple spots check the result of map() and make decisions
based on that -- but this is a step toward making that happen.  The
longer term idea here is that this is needed to enable lazier CU
expansion.

Meanwhile, this patch seems like a simple cleanup.  Relocation is now
handled by the blockvector itself and the non-const map() method can
be removed.

There wasn't a great spot to move the section_offsets typedef.  I
chose defs.h.  I've also updated the comment there as it has been out
of date for a long time.  I've also removed an obsolete comment from
the symbol-relocation code.

Regression tested on x86-64 Fedora 40.

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

[gdb/build] Handle gdbsupport and gdbserver in gdb.pot

Currently, when making gdb.pot:
...
$ cd build/gdb
$ make po/gdb.pot
test -d po || mkdir po
sh -e /data/vries/gdb/src/gdb/po/gdbtext /usr/bin/xgettext gdb . /data/vries/gdb/src/gdb
$
...
only strings from build/gdb and gdb are added.

Also add strings from gdbsupport and gdbserver.

Update gdb/po/gdbtext to handle the .cc files in gdbsupport and gdbserver.

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

gdb: add more styling to cli/cli-cmds.c

Adds more filename, line number, and address styling to
cli/cli-cmds.c.

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

Automatic date update in version.in

Automatic date update in version.in

gold: Treat symbols with version index 0 as unversioned

Oracle Solaris 11.4 Linker and Libraries Guide:

https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/linkers-libraries/version-symbol-section.html

defines VER_NDX_LOCAL to 0 with a comment, "Symbol has local scope".  This
leads to different interpretations by different linker implementations.
However Solaris as well as ld and ld.so in glibc always treat symbols
with version index 0 as unversioned symbols with global binding.  As
discussed in

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

in hindsight, VER_NDX_NONE might be a better name.  Ali from Oracle is
working on clarifying what version index 0 really means for unversioned
symbols with global binding.  In the meantime, update gold to treat
symbols with version index 0 as unversioned with global binding.

elfcpp/

PR gold/33577
* elfcpp.h (VER_NDX_LOCAL): Update comments.
(VER_NDX_GLOBAL): Likewise.

gold/

PR gold/33577
* dynobj.cc (Versions::symbol_section_contents): Set unversioned
symbol version index to VER_NDX_LOCAL.
* symtab.cc (Symbol_table::add_from_dynobj): Don't check
VER_NDX_LOCAL.
* testsuite/Makefile.am (check_SCRIPTS): Add ver_test_pr33577.sh.
(check_DATA): Add ver_test_pr33577a.syms and
ver_test_pr33577b.syms.
(ver_test_pr33577a.syms): New rule.
(ver_test_pr33577.so): Likewise.
(ver_test_pr33577b.syms): Likewise.
(ver_test_pr33577): Likewise.
* testsuite/Makefile.in: Regenerated.
* testsuite/ver_matching_test.sh: Updated to checking missing
Base version.
* testsuite/ver_test_14.sh (check_missing): New.
Updated to check missing Base version.
* testsuite/ver_test_pr33577.sh: New fille.
* testsuite/ver_test_pr33577a.c: Likewise.
* testsuite/ver_test_pr33577b.c: Likewise.

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

gdb/mips: fix lwp_info ptr -> ref

Fix this:

  CXX    mips-linux-nat.o
/home/smarchi/src/binutils-gdb/gdb/mips-linux-nat.c: In function ‘int write_watchpoint_regs()’:
/home/smarchi/src/binutils-gdb/gdb/mips-linux-nat.c:640:39: error: cannot convert ‘lwp_info’ to ‘const lwp_info*’ in initialization
  640 |   for (const lwp_info *lp : all_lwps ())
      |                                       ^

... which is a fallout of e92df1d0eb6c ("gdb: make lwp_info_iterator
yield references").

Change-Id: I3cfb9eb597bea6c6921219bbf28937784fd8ac55

gdb: revert std -> gdb unordered_map change in x86-nat.c

This particular change in commit 965deba1208 ("gdb: use
gdb::unordered_{set,map} at a few places") causes some regressions,
for instance when running gdb.base/catch-fork-kill.exp:

    (gdb) PASS: gdb.base/catch-fork-kill.exp: fork-kind=fork: exit-kind=exit: fork: continue to child fork
    continue^M
    Continuing.^M
    [Attaching after Thread 0x7ffff7e74740 (LWP 490949) fork to child process 490952]^M
    [New inferior 2 (process 490952)]^M
    [Thread debugging using libthread_db enabled]^M
    Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1".^M
    =================================================================^M
    ^[[1m^[[31m==490919==ERROR: AddressSanitizer: heap-use-after-free on address 0x7c9bac051d88 at pc 0x55f46adc7583 bp 0x7ffc862a1e90 sp 0x7ffc862a1e80

Function x86_linux_nat_target::low_new_fork calls function
x86_debug_reg_state twice in a row.  The first one returns a reference
to an x86_debug_reg_state object in the map.  The second causes an
insertion to be made, moving the first object, rendering the first
reference invalid.

Revert the change and add a comment indicating that the location of
x86_debug_reg_state objects is important.

Change-Id: I85789d7657bec658a01908117efa25611e660878

gdb/netbsd: fix fallout of thread_info ptr to ref change

Fix:

  CXX    netbsd-nat.o
/home/smarchi/src/binutils-gdb/gdb/netbsd-nat.c: In function 'void nbsd_resume(nbsd_nat_target*, ptid_t, int, gdb_signal)':
/home/smarchi/src/binutils-gdb/gdb/netbsd-nat.c:481:10: error: base operand of '->' has non-pointer type 'thread_info'
  481 |    if (tp->ptid.lwp () == ptid.lwp ())
      |          ^~

... following the changes that made thread iterators yield references
instead of points (e.g. 1ad8737b3c5 ("gdb: change inf_threads_iterator
to yield references")).

Change-Id: I6b96d1a81fbe8792e82e071c4871f0f212d2e49d

[gdb] Rewrite strings in producer_parsing_tests

I noticed some odd-looking strings in producer_parsing_tests, like this one:
...
    static const char extern_f_14_0[] = "\
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on \
Intel(R) 64, \
Version 14.0.1.074 Build 20130716";
...

Rewrite this in a more regular style:
...
    static const char extern_f_14_0[]
      = ("Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on"
 " Intel(R) 64, Version 14.0.1.074 Build 20130716");
...

Tested on x86_64-linux.

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

[gdb] Rewrite producer_is_gcc and producer_is_clang

Rewrite functions producer_is_gcc and producer_is_clang into an early-exit
style.

Tested on x86_64-linux.

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

[gdb] Use nullptr instead of NULL in producer.[ch]

Replace the uses of NULL in gdb/producer.[ch] by nullptr.

Tested on x86_64-linux.

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

[gdb] Fix producer_is_gas comment

The comment for producer_is_gas in gdb/producer.h:
...
/* Returns nonzero if the given PRODUCER string is GAS and sets the MAJOR
   and MINOR versions when not NULL.  Returns zero if the given PRODUCER
   is NULL or it isn't GAS.  */
bool producer_is_gas (const char *producer, int *major, int *minor);
...
uses 'nonzero' and 'zero', while the return type is bool.

Fix this by using 'true' and 'false' instead.

Tested on x86_64-linux.

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

[gdb] Return bool in producer_is_gcc

Function producer_is_gcc returns int, but the result is interpreted as zero or
non-zero.

Make it return bool instead.

Tested on x86_64-linux.

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

gdb: use gdb::unordered_{set,map} at a few places

Use the gdb:: set/map types instead of the std:: ones.  I only changed
places in files I can build on my dev machine.

I needed to explicitly default the move constructor and assigment
operator in proc_mem_file.  I think this is ok, as nothing takes the
address of a proc_mem_file, requiring it not to move.

I also needed to do it for refcnt_fd, in solib-rocm.c.  It's a bit odd
to prevent moving / copying a refcnt_fd, as this struct doesn't directly
hold a resource, but I think I get why it was done.

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

[gdb/i18n] Use c++ in po/gdbtext

I came across a script gdb/po/gdbtext:
...
$ ./po/gdbtext
Usage: ./po/gdbtext <xgettext> <package>  <directory> ...
...

When using it, I get:
...
$ ./po/gdbtext xgettext gdb ../gdb ../gdbsupport/ ../gdbserver/
unittests/memory-map-selftests.c:30: warning: unterminated string literal
unittests/memory-map-selftests.c:41: warning: unterminated string literal
$
...
due to raw strings being used in unittests/memory-map-selftests.c.

Fix this by updating the language used in ./po/gdbtext to C++.