Merge eval_op_objc_msgcall into objc_msgcall_operation::evaluate

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

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

Rename some locals in objc_msgcall_operation::evaluate

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

Use a vector in objc_msgcall_operation::evaluate

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

Fix crash from eval_op_objc_msgcall

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

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

Add support for new Ada task state

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

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

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

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

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

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

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

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

New in v2:

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

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

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

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

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

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

The backtrace at the moment of the crash is:

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

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

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

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

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

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

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

to

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

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

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

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

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

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

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

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

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

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

Or, manually:

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

    Fatal signal: Segmentation fault

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

The backtrace at the moment of the crash is:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

And a .o file created by our DWARF assembler:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

gdb/dwarf: remove nullptr check in dwarf2_locexpr_baton_eval

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

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

gdb/dwarf: remove nullptr prop check in dwarf2_evaluate_property

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

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

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

Commits:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

gdb/aarch64: change target_ops::stopped_data_address API

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  bool target_ops::stopped_data_address (CORE_ADDR *);

will change to:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[gdb/corefiles] Sort info proc mappings table

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

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

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

Fix this by sorting the entries in linux_read_core_file_mappings.

Tested on x86_64-linux.

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

Automatic date update in version.in

lto: Compile PR ld/23818 test with -fPIC

Compile PR ld/23818 test with -fPIC to fix

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

for mips.

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

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

elf: Properly place base symbols in DT_GNU_HASH and DT_HASH

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

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

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

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

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

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

bfd/

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

ld/

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

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

elf: Renumber local dynamic symbols only if needed

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

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

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

ELF symbol version output cleanup

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

PR 33637, abort in byte_get

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

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

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

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

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

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

bfd: fix potential missing seek

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

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

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

Automatic date update in version.in

Automatic date update in version.in

gprofng: protect against standard library macros

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

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

gdb/testsuite: fix a few typos

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

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

gdb: update is_addr_in_objfile to support "dynamic" objfiles

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

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

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

gdb: add unittests for blockvector lookup functions

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

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

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

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

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

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

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

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

gdb: update blockvector::lookup

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

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

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

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

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

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

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

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

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

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

x86: drop a few excess AVX512VL from opcode table

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

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

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

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

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

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

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

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

binutils/

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

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

Automatic date update in version.in

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

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

Change-Id: I0b01ea5a1dedf0f5f58dc9f66d54014d4f5bbb00

gdb: Make startup message more user friendly

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

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

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

And with limited space:

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

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

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

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

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

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

[gdb/tdep] Simplify i386_thiscall_push_dummy_call

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

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

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

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

Obsolete support for Solaris < 10

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

* Solaris 8 support in GCC 4.8 (2013)

* Solaris 9 support in GCC 5 (2015)

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

Both wouldn't even build since binutils 2.41.

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

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

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

Automatic date update in version.in

PR 33453 linker generated .eh_frame

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

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

PR 33453 backend_finish_dynamic_sections final link buffer

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

PR 33453 allow extra for .eh_frame in final link buffer

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

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

Tidy .eh_frame rawsize manipulation

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

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

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

gdb: fix some whitespace issues

Replace 8 spaces with a tab.

Change-Id: Ie8f942ce4b4ba4a83c2ee83cb904153b2e58cf8c

libsframe: testsuite: remove usage of ##__VA_ARGS__

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

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

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

PR libsframe/33437

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

PowerPC: Skip base type RTTI tests before inferior start

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

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

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

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

libsframe: bugfix in flip_sframe

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

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

Automatic date update in version.in

gdb/solib-svr4: remove unnecessary assert and variable

I don't think this assert adds any value.

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

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

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

Change-Id: I540edbcfd2e1e3cfd6afa0e911f43c8b89862414

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

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

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

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

hppa64: Fix bogus warning from elf_hppa_final_link_relocate

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

bfd/ChangeLog:

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

Automatic date update in version.in

hppa64: Fix R_PARISC_LTOFF_FPTR64 and R_PARISC_LTOFF_TP64 relocation support

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

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

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

bfd/ChangeLog:

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

PR 33474 SEGV in init_reloc_cookie

This segfault is triggered by a tekhex input.

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

PR 33473 SEGV in _bfd_elf_gc_mark_debug_special_section_group

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

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

replace tail with sed

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

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

bogus FAILs from mmix ld testsuite

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

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

Use version index 1 for defined symbols

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

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

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

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

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

aarch64: constify BTI and GCS report functions

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

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

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

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

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

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

bfd: rename parsing methods of object attribute v1 API

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

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

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.