Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

gdb: fix slowdown during skeletonless type units processing

My commit 6474c699a525 ("gdb/dwarf: sort dwarf2_per_bfd::all_units by
(section, offset)") introduced a pretty bad performance regression in
the "skeletonless type units" step.  I have a pretty big executable
(Blender) compiled with -gsplit-dwarf (to generate .dwo files) and
-fdebug-types-section (to generate type units).  Before the offending
commit:

    Time for "DWARF skeletonless type units": wall 29.126, user 28.507, sys 0.497, user+sys 29.004, 99.6 % CPU

... and after:

    Time for "DWARF skeletonless type units": wall 120.768, user 119.543, sys 0.651, user+sys 120.194, 99.5 % CPU

The reason for the slowdown is that add_type_unit now inserts type units
at the right place in the all_units vector to keep it sorted.  These
repeated insertions in the middle of the vector require shifting a lot
of elements and end up taking a lot of time.

This patch fixes it by doing just one sort at the end of
process_skeletonless_type_units.  The responsibility of keeping the
all_units sorted is delegated to the callers of add_type_unit.  The
other two callers call finalize_all_units right after calling
add_type_unit.

One drawback that is probably not a real one: in
process_skeletonless_type_unit, we call process_type_unit.  If something
in there needs to look up another type unit by (section, offset), it
wouldn't find it.  I don't think that's a real issue though, as type
units are typically self contained.  If a type unit needs to refer to a
type defined in another type unit, it would do so by signature, with
DW_FORM_ref_sig8.  And during the indexing phase, I don't think we even
look at the DW_AT_type of things anyway.

With this patch applied, I am back to:

    Time for "DWARF skeletonless type units": wall 29.277, user 28.632, sys 0.521, user+sys 29.153, 99.6 % CPU

I would like to cherry pick this patch to GDB 17, to avoid shipping GDB
17 with the performance regression.

Change-Id: I2a5b89ebca9e1a4e6248032e144520c9a579f47a
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33526
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
(cherry picked from commit 2c3d37c44b70a6e45a43045fcf07e8e739573c49)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[gdb/tdep] Fix inferior call return of small char array for ppc64 v1 abi some more

PR tdep/33534 reports a regression due to commit 13f1820106c ("[gdb/tdep] Fix
inferior call return of small char array for ppc64 v1 abi").

The regression can be reproduced with the test-case introduced in the commit:
gdb.ada/return-small-char-array.exp, on a ppc64-linux setup with v1 elf abi
(cfarm121).

The commit contains two changes to a piece of code in
ppc64_sysv_abi_return_value:
...
   /* Small character arrays are returned, right justified, in r3.  */
-  if (valtype->code () == TYPE_CODE_ARRAY
+  if (tdep->elf_abi == POWERPC_ELF_V1
+      && valtype->code () == TYPE_CODE_ARRAY
       && !valtype->is_vector ()
       && valtype->length () <= 8
-      && valtype->target_type ()->code () == TYPE_CODE_INT
+      && (valtype->target_type ()->code () == TYPE_CODE_INT
+   || valtype->target_type ()->code () == TYPE_CODE_CHAR)
       && valtype->target_type ()->length () == 1)
...

The first change limits the effect of the if clause to the v1 elf abi.  This
change doesn't affect the regression, since it's on a ppc64-linux setup with
v1 elf abi.  Furthermore, it's correct in the sense that the v2 elf abi
doesn't have this kind of special treatment of small character arrays.

The second change is the part that causes the regression.  The code itself
seems correct, in the sense that it enables gdb to recognize small char arrays
in ada.

The regression stems from the following discrepancy.

The comment in gdb states that "small character arrays are returned, right
justified, in r3".  This matches the v1 ABI [1].

OTOH, gcc produces code that is not in agreement with this.  Instead, it
passes the small character arrays in memory, in a caller-allocated storage
buffer pointed at by r3.  This turns out to be an gcc bug [2].

Fix this by treating this as an abi spec bug, and replacing the code handling
the "Small character arrays" case with a comment.

Doing so reveals that there are two problems in the test-case:
- missing fvar-tracking, and
- the "step 2" command doesn't land at the intended line.

Fix these by:
- adding fvar-tracking, and
- setting a breakpoint at the intended line, and continuing to it.

Tested on ppc64-linux (v1 abi), ppc64le-linux (v2 abi), and x86_64-linux.

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

[1] https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html.
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122282

(cherry picked from commit 0e4fd060ee7244d00c76f0d4815063dfcc9877f1)

Automatic date update in version.in

[gdb/c++] Fix hang on whatis std::string::npos

Consider the following scenario, exercising "whatis std::string::npos":
...
$ cat test.cc
int main (void) {
  std::string foo = "bar";
  return foo.size ();
}
$ g++ test.cc -g
$ gdb -q -batch -iex "set trace-commands on" a.out -x gdb.in
+start
Temporary breakpoint 1 at 0x4021c7: file test.cc, line 3.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Temporary breakpoint 1, main () at test.cc:3
3   std::string foo = "bar";
+info auto-load python-scripts
No auto-load scripts.
+whatis std::string
type = std::__cxx11::basic_string<char, std::char_traits<char>, \
  std::allocator<char> >
+whatis std::string::npos
type = const std::__cxx11::basic_string<char, std::char_traits<char>, \
  std::allocator<char> >::size_type
...

After installing the package containing the pretty-printers:
...
$ zypper install libstdc++6-pp
...
and adding some commands to use them, we get instead:
...
$ gdb -q -batch -iex "set trace-commands on" a.out -x gdb.in
+add-auto-load-safe-path /usr/share/gdb/auto-load
+add-auto-load-scripts-directory /usr/share/gdb/auto-load
+start
  ...
+info auto-load python-scripts
Loaded  Script
Yes     /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.34-gdb.py
+whatis std::string
type = std::string
+whatis std::string::npos
type = const std::__cxx11::basic_string<char, std::char_traits<char>, \
  std::allocator<char> >::size_type
...

Note that "whatis std::string" now prints "std::string", but that
"whatis std::string::npos" still uses the longer name for std::string.

This is when compiling gdb with -O0.  With -O2 -fstack-protector-strong, we
have a hang instead:
...
+whatis std::string
type = std::string
+whatis std::string::npos
<HANG>
...

Valgrind complains about an uninitialized field
demangle_component::d_counting, which is fixed by using
cplus_demangle_fill_name in replace_typedefs_qualified_name.

After fixing that, the hang is also reproducible at -O0.

The hang happens because we're stuck in the while loop in
replace_typedefs_qualified_name, replacing "std::string::size_type" with
"std::string::size_type".

Fix this in inspect_type by checking for this situation, getting us instead:
...
+whatis std::string
type = std::string
+whatis std::string::npos
type = const std::string::size_type
$
...

The test-case is a bit unusual:
- pretty-print.cc is a preprocessed c++ source, reduced using cvise [1], then
  hand-edited to fix warnings with gcc and clang.
- the pretty-printer .py file is a reduced version of
  /usr/share/gcc-15/python/libstdcxx/v6/printers.py.

Using the test-case (and the cplus_demangle_fill_name fix), I managed to
reproduce the hang on both:
- openSUSE Leap 15.6 with gcc 7, and
- openSUSE Tumbleweed with gcc 15.

The test-case compiles with clang, but the hang didn't reproduce.

Tested on x86_64-linux.

PR testsuite/33480
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33480

[1] https://github.com/marxin/cvise

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[gdb] Fix assertion failure due to null frame

PR gdb/33512 reports an assertion failure in test-case
gdb.ada/access_to_packed_array.exp on i386-linux:
...
(gdb) maint print symbols
gdb/frame.c:3400: internal-error: reinflate: \
  Assertion `m_cached_level >= -1' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) FAIL: $exp: \
  maint print symbols (GDB internal error)
...

I haven't been able to reproduce the failure by running the test-case on
x86_64-linux with target board unix/-m32, but I'm able to reproduce on
x86_64-linux by using the exec attached to the PR:
...
$ cat gdb.in
file foo
maint expand-symtabs
maint print symbols
$ gdb -q -batch -ex "set trace-commands on" -x gdb.in
   ...
         c_to: array (gdb/frame.c:3395: internal-error: reinflate: \
                Assertion `m_cached_level >= -1' failed.
...

The problem happens when trying to print variable c_to:
...
 <4><f227>: Abbrev Number: 3 (DW_TAG_variable)
    <f228>   DW_AT_name        : c_to
    <f230>   DW_AT_type        : <0xf214>
...
with type:
...
 <4><f214>: Abbrev Number: 7 (DW_TAG_array_type)
    <f215>   DW_AT_type        : <0x9f39>
 <5><f21d>: Abbrev Number: 12 (DW_TAG_subrange_type)
    <f21e>   DW_AT_type        : <0x9d6c>
    <f222>   DW_AT_upper_bound : <0xf209>
...
with upper bound:
...
 <4><f209>: Abbrev Number: 89 (DW_TAG_variable)
    <f20a>   DW_AT_name        : system__os_lib__copy_file__copy_to__TTc_toSP1___U
    <f20e>   DW_AT_type        : <0x9d6c>
    <f212>   DW_AT_artificial  : 1
    <f212>   DW_AT_location    : 1 byte block: 57       (DW_OP_reg7 (edi))
...

The backtrace at the point of the assertion failure is:
...
 (gdb) bt
 #0  __pthread_kill_implementation (threadid=<optimized out>,
     signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
 #1  0x00007ffff62a8e7f in __pthread_kill_internal (signo=6,
     threadid=<optimized out>) at pthread_kill.c:78
 #2  0x00007ffff6257842 in __GI_raise (sig=sig@entry=6)
     at ../sysdeps/posix/raise.c:26
 #3  0x00007ffff623f5cf in __GI_abort () at abort.c:79
 #4  0x00000000010e7ac6 in dump_core () at gdb/utils.c:223
 #5  0x00000000010e81b8 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_list_tag __va_list_tag *) (
     problem=0x2ceb0c0 <internal_error_problem>,
     file=0x1ad5a90 "gdb/frame.c", line=3395,
     fmt=0x1ad5a08 "%s: Assertion `%s' failed.", ap=0x7fffffffc3c0)
     at gdb/utils.c:475
 #6  0x00000000010e82ac in internal_verror (
     file=0x1ad5a90 "gdb/frame.c", line=3395,
     fmt=0x1ad5a08 "%s: Assertion `%s' failed.", ap=0x7fffffffc3c0)
     at gdb/utils.c:501
 #7  0x00000000019be79f in internal_error_loc (
     file=0x1ad5a90 "gdb/frame.c", line=3395,
     fmt=0x1ad5a08 "%s: Assertion `%s' failed.")
     at gdbsupport/errors.cc:57
 #8  0x00000000009b5c16 in frame_info_ptr::reinflate (this=0x7fffffffc878)
     at gdb/frame.c:3395
 #9  0x00000000009b66f9 in frame_info_ptr::operator-> (this=0x7fffffffc878)
     at gdb/frame.h:290
 #10 0x00000000009b4bd5 in get_frame_arch (this_frame=...)
     at gdb/frame.c:3075
 #11 0x000000000081dd89 in dwarf_expr_context::fetch_result (
     this=0x7fffffffc810, type=0x410d600, subobj_type=0x410d600,
     subobj_offset=0, as_lval=true)
     at gdb/dwarf2/expr.c:1006
 #12 0x000000000081e2ef in dwarf_expr_context::evaluate (this=0x7fffffffc810,
     addr=0x7ffff459ce6b "W\aF\003", len=1, as_lval=true,
     per_cu=0x7fffd00053f0, frame=..., addr_info=0x7fffffffcc30, type=0x0,
     subobj_type=0x0, subobj_offset=0)
     at gdb/dwarf2/expr.c:1136
 #13 0x0000000000877c14 in dwarf2_locexpr_baton_eval (dlbaton=0x3e99c18,
     frame=..., addr_stack=0x7fffffffcc30, valp=0x7fffffffcab0,
     push_values=..., is_reference=0x7fffffffc9b0)
     at gdb/dwarf2/loc.c:1604
 #14 0x0000000000877f71 in dwarf2_evaluate_property (prop=0x3e99ce0,
     initial_frame=..., addr_stack=0x7fffffffcc30, value=0x7fffffffcab0,
     push_values=...) at gdb/dwarf2/loc.c:1668
 #15 0x00000000009def76 in resolve_dynamic_range (dyn_range_type=0x3e99c50,
     addr_stack=0x7fffffffcc30, frame=..., rank=0, resolve_p=true)
     at gdb/gdbtypes.c:2198
 #16 0x00000000009e0ded in resolve_dynamic_type_internal (type=0x3e99c50,
     addr_stack=0x7fffffffcc30, frame=..., top_level=true)
     at gdb/gdbtypes.c:2934
 #17 0x00000000009e1079 in resolve_dynamic_type (type=0x3e99c50, valaddr=...,
     addr=0, in_frame=0x0) at gdb/gdbtypes.c:2989
 #18 0x0000000000488ebc in ada_discrete_type_low_bound (type=0x3e99c50)
     at gdb/ada-lang.c:710
 #19 0x00000000004eb734 in print_range (type=0x3e99c50, stream=0x30157b0,
     bounds_preferred_p=0) at gdb/ada-typeprint.c:156
 #20 0x00000000004ebffe in print_array_type (type=0x3e99d10, stream=0x30157b0,
     show=1, level=9, flags=0x1bdcf20 <type_print_raw_options>)
     at gdb/ada-typeprint.c:381
 #21 0x00000000004eda3c in ada_print_type (type0=0x3e99d10,
     varstring=0x401f710 "c_to", stream=0x30157b0, show=1, level=9,
     flags=0x1bdcf20 <type_print_raw_options>)
     at gdb/ada-typeprint.c:1015
 #22 0x00000000004b4627 in ada_language::print_type (
     this=0x2f949b0 <ada_language_defn>, type=0x3e99d10,
     varstring=0x401f710 "c_to", stream=0x30157b0, show=1, level=9,
     flags=0x1bdcf20 <type_print_raw_options>)
     at gdb/ada-lang.c:13681
 #23 0x0000000000f74646 in print_symbol (gdbarch=0x3256270, symbol=0x3e99db0,
     depth=9, outfile=0x30157b0) at gdb/symmisc.c:545
 #24 0x0000000000f737e6 in dump_symtab_1 (symtab=0x3ddd7e0, outfile=0x30157b0)
     at gdb/symmisc.c:313
 #25 0x0000000000f73a69 in dump_symtab (symtab=0x3ddd7e0, outfile=0x30157b0)
     at gdb/symmisc.c:370
 #26 0x0000000000f7420f in maintenance_print_symbols (args=0x0, from_tty=0)
     at gdb/symmisc.c:481
 #27 0x00000000006c7fde in do_simple_func (args=0x0, from_tty=0, c=0x321e270)
     at gdb/cli/cli-decode.c:94
 #28 0x00000000006ce65a in cmd_func (cmd=0x321e270, args=0x0, from_tty=0)
     at gdb/cli/cli-decode.c:2826
 #29 0x0000000001005b78 in execute_command (p=0x3f48fe3 "", from_tty=0)
     at gdb/top.c:564
 #30 0x0000000000966095 in command_handler (
     command=0x3f48fd0 "maint print symbols")
     at gdb/event-top.c:613
 #31 0x0000000001005141 in read_command_file (stream=0x3011a40)
     at gdb/top.c:333
 #32 0x00000000006e2a64 in script_from_file (stream=0x3011a40,
     file=0x7fffffffe21f "gdb.in")
     at gdb/cli/cli-script.c:1705
 #33 0x00000000006bb88c in source_script_from_stream (stream=0x3011a40,
     file=0x7fffffffe21f "gdb.in", file_to_open=0x7fffffffd760 "gdb.in")
     at gdb/cli/cli-cmds.c:706
 #34 0x00000000006bba12 in source_script_with_search (
     file=0x7fffffffe21f "gdb.in", from_tty=0, search_path=0)
     at gdb/cli/cli-cmds.c:751
 #35 0x00000000006bbab2 in source_script (file=0x7fffffffe21f "gdb.in",
     from_tty=0) at gdb/cli/cli-cmds.c:760
 #36 0x0000000000b835cb in catch_command_errors (
     command=0x6bba7e <source_script(char const*, int)>,
     arg=0x7fffffffe21f "gdb.in", from_tty=0, do_bp_actions=false)
     at gdb/main.c:510
 #37 0x0000000000b83803 in execute_cmdargs (cmdarg_vec=0x7fffffffd980,
     file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd8c8)
     at gdb/main.c:606
 #38 0x0000000000b84d79 in captured_main_1 (context=0x7fffffffdb90)
     at gdb/main.c:1349
 #39 0x0000000000b84fe4 in captured_main (context=0x7fffffffdb90)
     at gdb/main.c:1372
 #40 0x0000000000b85092 in gdb_main (args=0x7fffffffdb90)
     at gdb/main.c:1401
 #41 0x000000000041a382 in main (argc=9, argv=0x7fffffffdcc8)
     at gdb/gdb.c:38
 (gdb)
...

The immediate problem is in dwarf_expr_context::fetch_result where we're
calling get_frame_arch:
...
      switch (this->m_location)
{
case DWARF_VALUE_REGISTER:
  {
    gdbarch *f_arch = get_frame_arch (this->m_frame);
...
with a null frame:
...
(gdb) p this->m_frame.is_null ()
$1 = true
(gdb)
...

Fix this using ensure_have_frame in dwarf_expr_context::execute_stack_op for
DW_OP_reg<n> and DW_OP_regx, getting us instead:
...
         c_to: array (<>) of character; computed at runtime
...

Tested on x86_64-linux.

Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33512
(cherry picked from commit 32a7293a027d1bf7690d428075e52aa97dbf8350)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

PowerPC: Fix typo in PowerPC note pseudo-section names

The recent tidy-up commit 09e56f0515c3 ("Code tidy: bfd/elf.c:
Tidy up core note handling code.") introduced regressions in the
PowerPC core note handling.  The pseudo-section names for TM_CVSX,
TM_SPR, VSX and VMX notes were defined with an underscore instead of a
hyphen, breaking GDB test cases.  The same goes for one riscv and one
s390 define.

This patch restores the correct section names by using hyphens in the
definitions, fixing 897 GDB test failures on PowerPC.

bfd/
* elf.c: (NOTE_PSEUDO_SECTION_PPC_TM_CVSX),
(NOTE_PSEUDO_SECTION_PPC_TM_SPR, NOTE_PSEUDO_SECTION_PPC_VSX),
(NOTE_PSEUDO_SECTION_PPC_VMX, NOTE_PSEUDO_SECTION_RISCV_CSR),
(NOTE_PSEUDO_SECTION_S390_CTRS): Use hyphens in section names
instead of underscores.

(cherry picked from commit 30300ceca334a1a8997809b41ee7550bafa29b71)

Automatic date update in version.in

Automatic date update in version.in

Change return value of _bfd_mmap_temporary

_bfd_mmap_temporary will return MAP_FAILED in some cases, but only one
caller was prepared for this.  This caused a couple of issues in gdb.

This patch chnages _bfd_mmap_temporary to always return NULL on
failure.  It also changes the logic to fall back to bfd_malloc if mmap
fails.

I took the opportunity to change some "(void *) -1" to MAP_FAILED
where appropriate.

Tested by "make check" in binutils, and also by applying a hack from
bug 33354 to gdb and testing something approximating the original
report.

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

(cherry picked from commit 8b50cc76f19d129b3887dbcb58f8286a7b36099f)

Fix crash in f-typeprint.c

I noticed a crash in f-typeprint.c that was hidden by an xfail:

XFAIL: gdb.fortran/vla-array.exp: print variable length string array type (GDB internal error) (PRMS gcc/101826)

I think this was introduced by commit 6594ca4a ("do not handle a NULL
linebuffer in pager_file::puts") but not detected due to the xfail.

It seems bad for an xfail to cover up a crash but I haven't
investigated that.

Meanwhile, this patch fixes the crash by checking for a NULL pointer
when calling gdb_puts.

Approved-by: Kevin Buettner <kevinb@redhat.com>
(cherry picked from commit 18400a9cdf6b3d84996a99697a97774f268576c2)

Automatic date update in version.in

Update HFILES_NO_SRCDIR in gdb/Makefile.in

I noticed a header file from dwarf2/ was missing from HFILES_NO_SRCDIR
in gdb/Makefile.in.  Looking more, I found many missing files.  This
patch adds them all and sorts the list -- using "sort", though, and
not the advice at the top of Makefile.in that, IMO, seems hard to
implement.

This also removes some code from the 'tags' rule that I think is
obsolete.

(cherry picked from commit 58f22c76b29088c69eb6f272da7f20fdc5a80c50)

Automatic date update in version.in

Automatic date update in version.in

New '--binary-output' command line option, fix gdb.mi/ testing on Windows

MI testcases currently all fail on native Windows with:

 Running /c/gdb/src/gdb/testsuite/gdb.mi/mi-simplerun.exp ...
 ERROR: (timeout) GDB never initialized after 10 seconds.

This is because when GDB is started in MI mode, it prints info to the
terminal before -iex options are processed.  I.e., before the "maint
set console-translation-mode binary" command in

 gdb -nw -nx -q -iex "set height 0" -iex "set width 0" \
    -iex "set interactive-mode on" \
    -iex "maint set console-translation-mode binary" \
    -i=mi

... is processed.  This results in GDB printing early output with
\r\r\n, like can be easily seen by passing --debug to runtest:

  expect: does "=thread-group-added,id="i1"\r\r\n=cmd-param-changed,param="width",value="4294967295"\r\r\n=cmd-param-changed,param="interactive-mode",value="on"\r\r\n(gdb) \r\n" (spawn_id exp10) match regular expression "~"GNU.*\r\n~".*[(]gdb[)] \r\n$"? Gate "~"GNU*\r\n~"*gdb? \r\n"? gate=no

Fix this by adding a new Windows-only --binary-output command line
option to GDB, which is processed much earlier than -iex, and making
the testsuite pass that instead of "maint set console-translation-mode
binary".

Remove "maint set console-translation-mode" completely, since the only
reason it existed was for the testsuite, and it was never included in
any release.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Tom de Vries <tdevries@suse.de>
Change-Id: I4632707bb7c8ca573cffff9641ddeb33a0e150af

Automatic date update in version.in

Correct bounds check when working around GAS DWARF 5 directory table bug

Recent Go toolchains are causing GDB to crash on a relatively recent
workaround for a GAS bug:

commit a833790a626d9620319d0ca6aee23daa584d445c
Date:   Wed Nov 1 00:33:12 2023 +0100

    [gdb/symtab] Work around gas PR28629

In the original GAS bug, the first directory table entry did not contain
the current directory of the compilation. So the above commit added a
workaround fix to prepend the second directory table entry.

However recent Go toolchain compilations (specifically on aarch64)
only output a single directory table entry. Looking at the workaround:

       if (lh->version == 5 && lh->is_valid_file_index (1))
         {
           std::string dir = lh->include_dir_at (1);
           fnd.set_comp_dir (std::move (dir));
         }

`lh->is_valid_file_index (1)' is true, but since the directory table only
has one entry, `include_dir_at (1)' returns nullptr. Consequently the
std::string ctor will segfault. Since there are no guarantees that the file
and directory tables are the same size, a better bounds check is to simply
rely on `include_dir_at' to ensure a valid directory table entry.

I have updated the workaround commit's test, gdb.dwarf2/dw2-gas-workaround.exp
and tested on x86_64 and aarch64 RHEL 9 and Fedora 41.

Approved-By: Andrew Burgess <aburgess@redhat.com>
(cherry picked from commit 31cb4bb676dde0db3f24e03380a02ae92633c98f)

Automatic date update in version.in

Have gdb.ThreadExitedEvent inherit from gdb.ThreadEvent

The documentation says that ThreadExitedEvent is derived from
ThreadEvent, but the code does not actually implement this.

This patch fixes the problem.  I propose applying this to gdb 17 as
well.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33444
Approved-By: Simon Marchi <simon.marchi@efficios.com>
(cherry picked from commit 3a9f5df6ea8adcae7769f271cccbc2da8553c08d)

Automatic date update in version.in

GDB: aarch64: Use GCS features to calculate hash of struct aarch64_features

Luis noticed that when adding the gcs and gcs_linux members to struct
aarch64_features in my Guarded Control Stack patch series, I neglected to
modify struct hash<aarch64_features>::operator() to take them into account
when computing its hash.

This can cause GDB to use the wrong aarch64_features object during a
debugging session.

Regression tested on aarch64-linux-gnu.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33440
Suggested-by: Luis Machado <luis.machado.foss@gmail.com>
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
(cherry picked from commit 86e6907244c89bde0d1584dbcbd617b53319d0f9)

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Fix gdb.Value.dynamic_type attribute

gdb currently crashes if you try to get the dynamic_type from a
gdb.Value of a POD struct:

(gdb) py print(gdb.parse_and_eval('pod').dynamic_type)
Fatal signal: Segmentation fault

It happens because value_rtti_type() returns NULL for them, and this is
not handled correctly.

Fixed by using val->type() as a fallback in this case.

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

gdb: Add i386-gnu-tdep to the list of objects for x86_64-*-gnu*

When starting GDB on Hurd amd64, one will currently see the following
warning:

  # gdb -q
  gdb: warning: A handler for the OS ABI "GNU/Hurd" is not built into this configuration
  of GDB.  Attempting to continue with the default i386 settings.
  (gdb)

This happens because, in gdb/configure.tgt, the "x86_64-*-gnu*" target
is not pulling in the i386-gnu-tdep.o object, which means that only
64-bit debugging is currently supported.

The fix here is to add i386-gnu-tdep.o to the gdb_target_obs for Hurd
amd64.

Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net>
Suggested-by: Andrew Burgess <aburgess@redhat.com>
Reported-by: Mark Wielaard <mark@klomp.org>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33377
Approved-by: Kevin Buettner <kevinb@redhat.com>
(cherry picked from commit 3d22a6cee4b27866c544d67a82e2272ae4201f9e)

Automatic date update in version.in

gdb: Add svr4-tls-tdep.o to list of objects of i*86 targets

GDB currently fails to build from source on i386 if compiled with
--enable-64-bit-bfd.  This is happening because svr4-tls-tdep.o is
missing from the gdb_target_obs variable, while amd64-linux-tdep.o is
obviously there.

Fix the problem by adding svr4-tls-tdep.o to the object list, but only
when --enable-64-bit-bfd is provided.

Signed-off-by: Sergio Durigan Junior <sergiodj@sergiodj.net>
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33399
(cherry picked from commit b318480f27322c15c6b10c1bab4418e81d44b77e)

gdb/testsuite: small fix for amd64-extended-prologue-analysis.exp

I noticed I was sometimes getting this failure:

  FAIL: gdb.arch/amd64-extended-prologue-analysis.exp: offset \
      initialization: ASM source: gdb_breakpoint: set breakpoint \
      at *0x0000000000401151

The problem was introduced in commit:

  commit f9aa48dc545ef511e19f4dfab88a196b820fd2da
  Date:   Thu Aug 28 11:50:13 2025 +0000

      gdb, amd64: extend the amd64 prologue analyzer to skip register pushes

A gdb_test_multiple exits early when processing the results of a
'disassemble' command, without waiting for the prompt to be seen.
This can leave unhandled output in expect's input buffer, which will
then throw off the next test.

Update the gdb_test_multiple to wait for the prompt before declaring
the test passed.

After this I'm no longer seeing the above failure.

There should be no change in what is tested after this commit.

Automatic date update in version.in

Automatic date update in version.in

Bump GDB's version number to 17.0.90.DATE-git.

This commit changes gdb/version.in to 17.0.90.DATE-git.

Set GDB version number to 17.0.90.

This commit changes gdb/version.in to 17.0.90.

gdb/NEWS: Change "since GDB 16" into "in GDB 17"

Now that the major release version number is confirmed, we can adjust
the title of the corresponding section in the gdb/NEWS file.

Set development mode to "off" by default.

This is done by setting the "development" variable to "false"
in bfd/development.sh.

Bump version to 17.0.90.DATE-git.

Now that the GDB 17 branch has been created,
this commit bumps the version number in gdb/version.in to
17.0.90.DATE-git

For the record, the GDB 17 branch was created
from commit 46ada32fc979550ad4f46792b74c182bb7232aeb.

Update x86: Add GLIBC_ABI_GNU2_TLS version dependency

commit 0d1e88f8bfb0e62f37bf8a89172cd91373ace5e6
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri Jul 4 08:39:03 2025 +0800

    x86: Add GLIBC_ABI_GNU2_TLS version dependency

added solaris2-x86-64.em to accommodate moving x86-64 specific extra
emulation bits to elf-x86-64.em.  Update emulparams/elf_x86_64_sol2.sh
to use it.

* emulparams/elf_x86_64_sol2.sh (EXTRA_EM_FILE): Set to
"solaris2-x86-64".

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

Re: tekhex test for commit bf0f85df1254

* testsuite/binutils-all/objcopy.exp (objcopy_tek2bin): Correct
isremote to is_remote.

Automatic date update in version.in

bfd: configure.ac: Fix mention of flag to enable 64-bit BFD in comment

It was changed back in 1994.  Fixing because it misled me into using the
wrong flag in a build.

Allow conversion of 128-bit integers to Python

Currently, trying to convert a 128-bit integer from a gdb.Value to a
Python integer will fail.  This is surprising because Python uses
bigints internally.

The bug here is that valpy_long uses value_as_long, which fails for
anything wider than LONGEST.  This patch fixes the problem by using
the recommended Python API.

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

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

Fix fallout in gdb.base from erroring out on clean_restart
<absolute filename>.

Tested on x86_64-linux.

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

Manually fix the test-cases found by:
...
$ find gdb/testsuite/gdb.base -name *.exp* \
  | xargs grep -l 'clean_restart[^;]*binfile'
$ find gdb/testsuite/gdb.base -name *.exp* \
  | xargs grep -l 'prepare_for_testing.*bin'
...
except for gdb.base/foll-vfork.exp and gdb.base/solib-overlap.exp.

Tested on x86_64-linux.

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

Run:
...
$ find gdb/testsuite/gdb.base/ -name *.exp* \
    | xargs sed -i 's/^\([ \t]*\)clean_restart $binfile$/\1clean_restart\n\1gdb_load $binfile/'
$ find gdb/testsuite/gdb.base/ -name *.exp* \
    | xargs sed -i 's/^\([ \t]*\)clean_restart ${binfile}$/\1clean_restart\n\1gdb_load $binfile/'
$ find gdb/testsuite/gdb.base/ -name *.exp* \
    | xargs sed -i 's/^\([ \t]*\)clean_restart $::binfile$/\1clean_restart\n\1gdb_load $::binfile/'
$ find gdb/testsuite/gdb.base/ -name *.exp* \
    | xargs sed -i 's/^\([ \t]*\)clean_restart ${::binfile}$/\1clean_restart\n\1gdb_load $::binfile/'
...

Revert the change in test-case gdb.base/foll-vfork.exp, which does
'set binfile $testfile'.

Tested on x86_64-linux.

The only modified test-case I was not able to test is
gdb.base/dtrace-probe.exp (filed PR testsuite/33379 about this).  The change
in the test-case is trivial though.

readelf: Handle 0 sh_entsize of GOT sections

Gold, lld and mold set sh_entsize to 0 on .got and .got.plt sections.
If sh_entsize of GOT sections is 0, assume 8 for ELFCLASS64 and 4 for
ELFCLASS32, except for x32 which uses 8.

PR binutils/33368
* readelf.c (process_got_section_contents): Handle 0 sh_entsize
of GOT sections.

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

Revert "MicroBlaze: Add microblaze_get_next_pcs"

This reverts commit c6df5d79aac5c4a77c06314fd26c837470360f70.

Causes buildbot failure. Bug 33381

gdb: ensure bp_location::section is set correct to avoid an assert

While reviewing and testing another patch I set a breakpoint on an
gnu ifunc function, then restarted the inferior, and this assert
triggered:

  ../../src/gdb/breakpoint.c:14747: internal-error: breakpoint_free_objfile: Assertion `loc->symtab == nullptr' failed.

The backtrace at the time of the assert is:

  #6  0x00000000005ffee0 in breakpoint_free_objfile (objfile=0x4064b30) at ../../src/gdb/breakpoint.c:14747
  #7  0x0000000000c33ff2 in objfile::~objfile (this=0x4064b30, __in_chrg=<optimized out>) at ../../src/gdb/objfiles.c:478
  #8  0x0000000000c38da6 in std::default_delete<objfile>::operator() (this=0x7ffc1a49d538, __ptr=0x4064b30) at /usr/include/c++/9/bits/unique_ptr.h:81
  #9  0x0000000000c3782a in std::unique_ptr<objfile, std::default_delete<objfile> >::~unique_ptr (this=0x7ffc1a49d538, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/unique_ptr.h:292
  #10 0x0000000000caf1bd in owning_intrusive_list<objfile, intrusive_base_node<objfile> >::erase (this=0x3790d68, i=...) at ../../src/gdb/../gdbsupport/owning_intrusive_list.h:111
  #11 0x0000000000cacd0c in program_space::remove_objfile (this=0x3790c80, objfile=0x4064b30) at ../../src/gdb/progspace.c:192
  #12 0x0000000000c33e1c in objfile::unlink (this=0x4064b30) at ../../src/gdb/objfiles.c:408
  #13 0x0000000000c34fb9 in objfile_purge_solibs (pspace=0x3790c80) at ../../src/gdb/objfiles.c:729
  #14 0x0000000000edf6f7 in no_shared_libraries (pspace=0x3790c80) at ../../src/gdb/solib.c:1359
  #15 0x0000000000fb3f6c in target_pre_inferior () at ../../src/gdb/target.c:2466
  #16 0x0000000000a724d7 in run_command_1 (args=0x0, from_tty=0, run_how=RUN_NORMAL) at ../../src/gdb/infcmd.c:390
  #17 0x0000000000a72a97 in run_command (args=0x0, from_tty=0) at ../../src/gdb/infcmd.c:514
  #18 0x00000000006bbb3d in do_simple_func (args=0x0, from_tty=0, c=0x39124b0) at ../../src/gdb/cli/cli-decode.c:95
  #19 0x00000000006c1021 in cmd_func (cmd=0x39124b0, args=0x0, from_tty=0) at ../../src/gdb/cli/cli-decode.c:2827

The function breakpoint_free_objfile is being called when an objfile
representing a shared library is being unloaded ahead of the inferior
being restarted, the function is trying to remove references to
anything that could itself reference the objfile that is being
deleted.

The assert is making the claim that, for a bp_location, which has a
single address, the objfile of the symtab associated with the location
will be the same as the objfile associated with the section of the
location.

This seems reasonable to me now, as it did when I added the assert in
commit:

  commit 5066f3680667ec0f2d1745847a2372d85973a1e7
  Date:   Mon Nov 11 21:45:17 2024 +0000

      gdb: do better in breakpoint_free_objfile

The bp_location::section is maintained, according to the comments in
breakpoint.h, to aid overlay debugging (is that even used any more),
and looking at the code, this does appear to be the case.

The problem in the above case arises when we are dealing with an ifunc
function.  What happens is that we end up with a section from one
objfile, but a symtab from a different objfile.

This problem originates from minsym_found (in linespec.c).  The user
asked for 'break gnu_ifunc' where 'gnu_ifunc' is an ifunc function.
What this means is that gnu_ifunc is actually a resolver function that
returns the address of the actual function to use.

In this particular test case, the resolver function is in a shared
library, and the actual function to use is in the main executable.

So, when GDB looks for 'gnu_ifunc' is finds the minimal_symbol with
that name, and spots that this has type mst_text_gnu_ifunc.  GDB then
uses this to figure out the actual address of the function that will
be run.

GDB then creates the symtab_and_line using the _real_ address and the
symtab in which that address lies, in our case this will all be
related to the main executable objfile.

But, finally, in minsym_found, GDB fills in the symtab_and_line's
section field, and this is done using the section containing the
original minimal_symbol, which is from the shared library objfile.

The minimal symbol and section are then use to initialise the
bp_location object, and this is how we end up in, what I think, is an
unexpected state.

So what to do about this?

The symtab_and_line::msymbol field is _only_ set within minsym_found,
and is then _only_ used to initialise the bp_location::msymbol field.

The bp_location::msymbol field is _only_ used in the function
set_breakpoint_location_function, and we only really care about the
msymbol type, we check to see if it's an ifunc symbol or not.  This
allows us to set the name of the function correctly.

The bp_location::section is used, as far as I can tell, extensively
for overlay handling.  It would seem to me, that this section should
be the section containing the actual breakpoint address.  If the
question we're asking is, is this breakpoint mapped in or not?  Then
surely we need to ask about the section holding the breakpoint's
address, and not the section holding some other code (e.g. the
resolver function).  In fact, in a memory constrained environment,
you'd expect the resolver functions to get mapped out pretty early on,
but while the actual functions might still be mapped in.

Finally, symtab_and_line::section.  This is mostly set using calls to
find_pc_overlay.  The minsym_found function is one of the few places
where we do things differently.  In the places where the section is
used, it is (almost?) always used in conjunction with the
symtab_and_line::pc to lookup information, e.g. calls to
block_for_pc_sect, or find_pc_sect_containing_function.  In all these
cases, it appears to me that the assumption is that the section will
be the section that contains the address.

So, where does this leave us?

I think what we need to do is update minsym_found to just use
find_pc_overlay, which is how the symtab_and_line::section is set in
most other cases.  What this actually means in practise is that the
section field will be set to NULL (see find_pc_overlay in symfile.c).
But given that this is how the section is computed in most other
cases, I don't see why it should be especially problematic for this
case.  In reality, I think this just means that the section is
calculated via a call to find_pc_section when it's needed, as an
example, see lookup_minimal_symbol_by_pc_section (minsyms.c).

I do wonder if we should be doing better when creating the
symtab_and_line, and insist that the section be calculated correctly
at that point, but I really don't want to open that can of worms right
now, so I think just changing minsym_found to "do it just like
everyone else" should be good enough.

I've extended the existing ifunc test to expose this issue, the
updated test fails without this patch, and passes with.

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

gdb: pass core file to gdbarch_core_read_x86_xsave_layout

Continuing the removal of 'current_program_space->core_bfd ()' from
GDB, this commit updates the gdbarch method
'gdbarch_core_read_x86_xsave_layout' to take the core file BFD as a
reference parameter.  For now this just moves the
'current_program_space->core_bfd ()' calls up the program stack into
core_target::fetch_x86_xsave_layout.  In the future I plan to move the
core file BFD object out of the program_space and into the
core_target, at which point these new global accesses can also be
removed.

There should be no user visible changes after this commit.

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

gdb: pass core file to gdbarch_core_thread_name method

Continuing the removal of 'current_program_space->core_bfd ()' from
GDB, this commit updates the gdbarch method 'gdbarch_core_thread_name'
to take the core file BFD as a reference parameter.  For now this just
moves the 'current_program_space->core_bfd ()' calls up the program
stack into core_target::thread_name.  In the future I plan to move the
core file BFD object out of the program_space and into the
core_target, at which point these new global accesses can also be
removed.

There should be no user visible changes after this commit.

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

gdb: pass core file through gdbarch API when loading shared libraries

Continuing the removal of 'current_program_space->core_bfd ()' from
GDB, this commit updates two gdbarch methods:

  gdbarch_core_xfer_shared_libraries
  gdbarch_core_xfer_shared_libraries_aix

to take the core file BFD as a reference parameter.  For now this just
moves the 'current_program_space->core_bfd ()' calls up the program
stack into core_target::xfer_partial.  In the future I plan to move
the core file BFD object out of the program_space and into the
core_target, at which point these new global accesses can also be
removed.

There should be no user visible changes after this commit.

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

[gdb/testsuite] Fix gdb.base/fileio.exp for local-remote-host-native

When running test-case gdb.base/fileio.exp with host/target board
local-remote-host-native I run into:
...
gdb compile failed, fileio.c: In function 'test_open':
<command-line>:0:8: error: expected expression before '.' token
fileio.c:89:15: note: in expansion of macro 'OUTDIR'
   ret = open (OUTDIR FILENAME, O_CREAT | O_TRUNC | O_RDWR, S_IWUSR | S_IRUSR);
               ^~~~~~
...

Fix this by using:
- quote_for_host to pass -DOUTDIR to the compilation, and
- STRINGIFY to stringify OUTDIR in fileio.c.

Tested on x86_64-linux, with target board unix and host/target board
local-remote-host-native.

MicroBlaze: Add microblaze_get_next_pcs

This patch enables software single stepping for gdbserver target

* gdb/microblaze-tdep.c: Add microblaze_get_next_pcs

Signed-off-by: David Holsgrove <david.holsgrove@petalogix.com>
Signed-off-by: Nathan Rossi <nathan.rossi@petalogix.com>
Signed-off-by: Mahesh Bodapati <mbodapat@xilinx.com>
Signed-off-by: Gopi Kumar Bulusu <gopi@sankhya.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

[gdb/testsuite] Fix clean_restart <absolute filename> in allow_aarch64_sme_tests

Fix fallout on aarch64-linux with test-case
gdb.testsuite/gdb-caching-proc-consistency.exp from erroring out on
clean_restart <absolute filename>.