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

[gdb] Fix '_ ("foo")'

Our documented style [1] is to use '_("foo")', not '_ ("foo")'.

Fix this in a few places.

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

[gdb/cli] Add missing _() for dump commands

Fix a missing _() for help strings for the dump memory/value commands.

Tested on x86_64-linux.

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

Do not crash on recursive pointer types

In Ada, it's possible to create a recursive pointer type, or two
mutually recursive pointer types.  gdb will crash when reading the
DWARF for these.

These types aren't actually useful, and so are unlikely to appear in
real code.  Still, gdb shouldn't crash.

This patch handles this case by noticing recursive pointer types and
representing them as pointer-to-void.

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

gdb/doc: Document AArch64 FPMR support

Add NEWS entry and document new feature in gdb.texinfo.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Luis Machado <luis.machado@arm.com>

gdb/aarch64: Tests for fpmr

Add tests for FPMR support in gdb/gdbserver. These tests check
availability of FPMR, reading/writing to FPMR, core file generation and
preservation under sighandler frame unwinding.

A run of the full gdb testsuite has been done on aarch64-none-linux-gnu
without FPMR support. The gdb.arch tests were run on Shrinkwrap with
FPMR support.

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

gdb/aarch64: core file support for FPMR

Add support for FPMR dumps/reads for core files.

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

gdb/aarch64: signal frame support for fpmr

Add support for FPMR in signal frames and restore contents of FPMR.

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

gdbserver/aarch64: Enable FPMR for AArch64 in gdbserver on Linux

Add support for FPMR in gdbserver.

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

gdb/aarch64: Enable FPMR for AArch64 in gdb on Linux

The Floating Point Mode Register controls the behaviours of FP8
instructions. This patch add FPMR to GDB if it is enabled on the
target.

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

bfd/ELF: Core file support for AArch64 FPMR

The Floating Point Mode Register is a new register which controls the
behaviour of FP8 instructions. This is handled by the Linux kernel
through a new NT_ARM_FPMR register set.

This patch adds required code to support core file dumps with
NT_ARM_FPMR in them.

gdb: simplify find_symbol_at_address

This commit further simplifies find_symbol_at_address by moving
the special handling in case of -readnow down to readnow_functions.

Running all tests in gdb.rust with and without -readnow shown no
regressions (tested on Debian, x86_64).

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

gdb: change find_compunit_symtab_by_address to find_symbol_by_address

This commit changes objfile::find_compunit_symtab_by_address and
corresponding quick_symbol_functions::find_compunit_symtab_by_address
to find_symbol_by_address return symbol.

This will allow simplifying find_symbol_at_address (the only caller of
find_compunit_symtab_by_address) by removing the special-case for
-readnow and moving the logic down to readnow_functions.

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

gdb: change search_symtab helper to be a method

This commit changes search_symtab helper in find_symbol_at_address to
be a method.

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

gdb, gdbserver: fix read/write_ptid types

In write_ptid(), a ptid's LWP member, which is declared long, is stored in
an int local variable before printing, potentially truncating it.  Fix it.

In read_ptid(), both PID and LWP are read as ULONGEST and then cast to
their respective type without checking for overflows.  Fix it.

In read_ptid(), an empty component is treated as zero.  Diagnose that as
an error, instead.

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

gdb, remote: fix set_thread () in start_remote ()

remote_target::start_remote_1 () calls set_continue_thread (minus_one_ptid)
with the intent to

      /* Let the stub know that we want it to return the thread.  */
      set_continue_thread (minus_one_ptid);

I interpret it such that it expects a later get_current_thread () to
return the thread selected by the target:

          /* We have thread information; select the thread the target
             says should be current.  If we're reconnecting to a
             multi-threaded program, this will ideally be the thread
             that last reported an event before GDB disconnected.  */
          ptid_t curr_thread = get_current_thread (wait_status);

This results in the packet sequence Hc-1, qC.

Hc simply sets cont_thread:

          else if (cs.own_buf[1] == 'c')
            cs.cont_thread = thread_id;

          write_ok (cs.own_buf);

and qC returns the general thread.  This doesn't match.

It also has some special treatment for null_ptid and minus_one_ptid:

    if (cs.general_thread != null_ptid && cs.general_thread != minus_one_ptid)
      ptid = cs.general_thread;
    else
      {
        init_thread_iter ();
        ptid = thread_iter->id;
      }

Similarly, Hg has some special treatment for null_ptid:

    if (cs.own_buf[1] == 'g')
      {
        if (thread_id == null_ptid)
          {
            /* GDB is telling us to choose any thread.  Check if
               the currently selected thread is still valid. If
               it is not, select the first available.  */
            thread_info *thread = find_thread_ptid (cs.general_thread);
            if (thread == NULL)
              thread = get_first_thread ();
            thread_id = thread->id;
          }

        cs.general_thread = thread_id;

The comment at Hg matches the intent of GDB for sending Hc-1.

Change the set_thread () call in remote_target::start_remote_1 () to

    set_general_thread (any_thread_ptid);

This results in GDB sending Hg0 and gdbserver preserving the currently
selected thread that is later returned in response to qC.

CC: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdbserver, read_ptid: handle '0' and '-1' thread ids

The special thread id '-1' means 'all threads'.
The special thread id '0' means 'any thread'.

Read_ptid () currently returns

    <current pid>.-1.0

and

    <current pid>.0.0

respectively.

Change that to minus_one_ptid for '-1' and to null_ptid for '0'.

CC: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Tom Tromey <tom@tromey.com>

gdb: build solib-svr4-linux.o when building for targets xtensa*-*-*linux*

When building a GDB configured with --target=xtensa-buildroot-linux-uclibc, we get:

  CXXLD  gdb
/usr/bin/ld: xtensa-linux-tdep.o: in function `xtensa_linux_init_abi(gdbarch_info, gdbarch*)':
/home/simark/src/binutils-gdb/gdb/xtensa-linux-tdep.c:115:(.text+0x102): undefined reference to `make_linux_ilp32_svr4_solib_ops(program_space*)'

Fix it by adding solib-svr4-linux.o to the list of objects build for
targets xtensa*-*-*linux*.

Change-Id: I0caa04a1d1c097defb5ea9c285cccc09ba80058d

Automatic date update in version.in

hppa64: Fix handling of dynamic relocations

This change fixes issues with dynamic relocations.  We now support
R_PARISC_FPTR64 relocations for local symbols for both LTOFF and
simple FPTR64 relocations.  Allocation of dynrel relocations is
revised along the lines of ia64.  OPDs are reduced in size to 16
bytes so .opd section is now identical to that generated by the
HP linker.

Small applications now link and run successfully on HP-UX but better
stub support is needed for executables larger than roughly 8 MB.
Many PCREL22F branches can't reach their target.  This prevents
building any recent version of gcc.

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

bfd/ChangeLog:

* elf64-hppa.c (OPD_ENTRY_SIZE): Change to 16 bytes.
(elf64_hppa_check_relocs): Revise maybe_dynamic calculation.
Revise R_PARISC_FPTR64 case to request dynrel when hh is
not NULL.  Add local symbols to local dynamic symbol table.
Always add global symbols to dynamic symbol table when a
dynrel may be needed.
(allocate_global_data_opd): Update OPD entry allocation
for reduced OPD size.
(allocate_dynrel_entries): Rework along the lines of ia64.
(elf64_hppa_late_size_sections): Revise DLT allocation.
Revise OPD allocation.
(elf64_hppa_finalize_opd): Revise for reduced OPD size.
Remove unnecessary NULL check.
(elf64_hppa_finalize_dlt): Remove unnecessary NULL check.
(elf64_hppa_finalize_dynreloc): Rework along the lines of
ia64.  Correct relocation handling.
(elf_hppa_final_link_relocate): Don't zero first two words
of OPD.  Update relocation handling to output EPLT and
FPTR64 relocations for local symbols.

Automatic date update in version.in

ld-elfvers: Remove vers8.c

commit c8a8d3bb27743c6894b7d5406a84e809965b9266
Author:     Ian Lance Taylor <ian@airs.com>
AuthorDate: Thu Mar 13 02:46:09 1997 +0000
Commit:     Ian Lance Taylor <ian@airs.com>
CommitDate: Thu Mar 13 02:46:09 1997 +0000

    Wed Mar 12 21:44:19 1997  Eric Youngdale  <eric@andante.jic.com>

            * ld-elfvers/vers.exp, *: New tests for symbol versioning.
            * config/default.exp: Set ar and strip.

added an unused vers8.c.  There is

build_vers_lib_pic "vers8" vers1.c vers8 vers8.map "" vers8.ver vers1.dsym vers1.sym

The differences are:

1. Version scripts:

vers1.map:

VERS_1.1 {
 local:
 hide_old*;
 hide_original*;
 hide_new*;
};

VERS_1.2 {
} VERS_1.1;

VERS_2.0 {
 show_bar1; show_bar2;
} VERS_1.2;

vers8.map:

VERSION {
VERS_1.1 {
 local:
 hide_old*;
 hide_original*;
 hide_new*;
};

VERS_1.2 {
} VERS_1.1;

VERS_2.0 {
 show_bar1; show_bar2;
} VERS_1.2;
}

2. Symbol version dump:

vers1.ver:

Version definitions:
[1-4] 0x01 0x0c96425f vers1.so
[1-4] 0x00 0x0a7927b1 VERS_1.1
[1-4] 0x00 0x0a7927b2 VERS_1.2
VERS_1.1
[1-4] 0x00 0x0a7922b0 VERS_2.0
VERS_1.2

vers8.ver:

Version definitions:
[1-4] 0x01 0x0c96b25f vers8.so
[1-4] 0x00 0x0a7927b1 VERS_1.1
[1-4] 0x00 0x0a7927b2 VERS_1.2
VERS_1.1
[1-4] 0x00 0x0a7922b0 VERS_2.0
VERS_1.2

We can remove the unused vers8.c.

PR ld/33631
* testsuite/ld-elfvers/vers8.c: Removed.

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

elf: Wire up PR ld/21086 test

commit 3c5fce9bc29b216af7d10f8d6e4d8c3f11a48359
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri Apr 21 12:00:55 2017 -0700

    Require --no-dynamic-linker with -static -E/--dynamic-list

added pr21086.c and pr21086.list without wiring them up.  Wire them up to
verify that there is no dynamic section with -static -E/--dynamic-list.

PR ld/21086
PR ld/33630
* testsuite/ld-elf/pr21086.rd: New file.
* testsuite/ld-elf/shared.exp: Wire PR ld/21086 test.

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

shared.exp: Use pr14862.map to build libpr14862.so

commit dda8ddc56f160befb8f8fc3ddc69d66cec6ac4f8
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Nov 20 22:17:27 2012 +0000

    Remove ref_dynamic_nonweak added by accident

used pr11138-1.map to build libpr14862.so by accident and pr14862.map
should be used instead.  The difference is

pr11138-1.map:

VERS_1 {
  global: bar; foo;
  local: *;
};

vs

pr14862.map:

VERS_1 {
  global: bar;
  local: *;
};

Since only "bar" is used, it didn't cause test failure.  Use pr14862.map
to build libpr14862.so as intended.

PR ld/14862
* ld-elf/shared.exp: Replace pr11138-1.map with pr14862.map
when building libpr14862.so.

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

Automatic date update in version.in

MIPS/GAS: Select symbolic GPR and FPR names based on current ABI setting

Add GPR and FPR symbolic register names to GAS for all ABI choices,
selecting the set of names based on the ABI being assembled for.

This extends the existing feature where the oldabi and newabi would
provide different symbolic GPR names to the assembler.  Both EABIs and
o64 are now supported along with symbolic FPR names for all ABI choices.

Signed-off-by: Maximilian Ciric <max.ciric@gmail.com>

gdb: add microblaze-linux.xml to XMLTOC, regenerate microblaze-linux.c

microblaze-linux.c is out of date compared to the other .c files in the
features directory.  I think it's because it's missing from XMLTOC.  Add
it there and run the "cfiles" target, causing the updates to
microblaze-linux.c.

I thought that we could get rid of regformats/microblaze-linux.dat,
since microblaze-linux is described with an XML target, but apparently
not, I don't really understand (or forget) how these things work.

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