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

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

Automatic date update in version.in

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

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

This commit also makes the following changes in gdb/testsuite:

* gdb.base/default.exp: Change $_gdb_minor to 3.

Set GDB version number to 15.2.

This commit changes gdb/version.in to 15.2.

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/python] Make sure python sys.exit makes gdb exit

With gdb 15.1, python sys.exit no longer makes gdb exit:
...
$ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $?
Python Exception <class 'SystemExit'>: 2
Error occurred in Python: 2
$1 = 123
0
...

This is a change in behaviour since commit a207f6b3a38 ("Rewrite "python"
command exception handling"), first available in gdb 15.1.

This patch reverts to the old behaviour by handling PyExc_SystemExit in
gdbpy_handle_exception, such what we have instead:
...
$ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $?
2
...

Tested on x86_64-linux, with python 3.6 and 3.13.

Tested-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR python/31946
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31946

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/symtab] Revert "Change handling of DW_TAG_enumeration_type in DWARF scanner"

After adding dwarf assembly to test-case gdb.dwarf2/enum-type.exp that adds
this debug info:
...
 <1><11f>: Abbrev Number: 3 (DW_TAG_enumeration_type)
    <120>   DW_AT_specification: <0x130>
 <2><124>: Abbrev Number: 4 (DW_TAG_enumerator)
    <125>   DW_AT_name        : val1
    <12a>   DW_AT_const_value : 1
 <2><12b>: Abbrev Number: 0
 <1><12c>: Abbrev Number: 5 (DW_TAG_namespace)
    <12d>   DW_AT_name        : ns
 <2><130>: Abbrev Number: 6 (DW_TAG_enumeration_type)
    <131>   DW_AT_name        : e
    <133>   DW_AT_type        : <0x118>
    <137>   DW_AT_declaration : 1
...
I run into an assertion failure:
...
(gdb) file enum-type^M
Reading symbols from enum-type...^M
cooked-index.h:214: internal-error: get_parent: \
  Assertion `(flags & IS_PARENT_DEFERRED) == 0' failed.^M
...

This was reported in PR32160 comment 1.

This is a regression since commit 4e417d7bb1c ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").

Fix this by reverting the commit.

[ Also drop the kfails for PR31900 and PR32158, which are regressions by that
same commit. ]

That allows us to look at the output of "maint print objfiles", and for val1
we get an entry without parent:
...
    [27] ((cooked_index_entry *) 0x7fbbb4002ef0)
    name:       val1
    canonical:  val1
    qualified:  val1
    DWARF tag:  DW_TAG_enumerator
    flags:      0x0 []
    DIE offset: 0x124
    parent:     ((cooked_index_entry *) 0)
...
which is incorrect, as noted in that same comment, but an improvement over the
assertion failure, and I don't think that ever worked.  This is to be
addressed in a follow-up patch.

Reverting the commit begs the question: what was it trying to fix in the first
place, and do we need a different fix?  I've investigated this and filed
PR32160 to track this.

My guess is that the commit was based on a misunderstand of what we track
in cooked_indexer::m_die_range_map.

Each DIE has two types of parent DIEs:
- a DIE that is the parent as indicated by the tree structure in which DIEs
  occur, and
- a DIE that represent the parent scope.

In most cases, these two are the same, but some times they're not.

The debug info above demonstrates such a case.  The DIE at 0x11f:
- has a tree-parent: the DIE representing the CU, and
- has a scope-parent: DIE 0x12c representing namespace ns.

In cooked_indexer::m_die_range_map, we track scope-parents, and the commit
tried to add a tree-parent instead.

So, I don't think we need a different fix, and propose we backport the reversal
for gdb 15.2.

Tested on x86_64-linux.

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

[gdb/testsuite] Add regression test for PR32158

Consider test-case:
...
namespace ns {
  enum class ec {
    val2 = 2
  };
}

int main () {
  return (int)ns::ec::val2;
}
...
compiled with debug info:
...
$ g++ test.c -g
...

When looking at the cooked index entry for val2 using "maint print objfiles",
we get:
...
    [7] ((cooked_index_entry *) 0x7f8ecc002ef0)
    name:       val2
    canonical:  val2
    qualified:  ns::val2
    DWARF tag:  DW_TAG_enumerator
    flags:      0x0 []
    DIE offset: 0xe9
    parent:     ((cooked_index_entry *) 0x7f8ecc002e90) [ns]
...
which is wrong, there is no source level entity ns::val2.

This is PR symtab/32158.

This is a regression since commit 4e417d7bb1c ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").

Reverting the commit on current trunk fixes the problem, and gets us instead:
...
    [7] ((cooked_index_entry *) 0x7fba70002ef0)
    name:       val2
    canonical:  val2
    qualified:  ns::ec::val2
    DWARF tag:  DW_TAG_enumerator
    flags:      0x0 []
    DIE offset: 0xe9
    parent:     ((cooked_index_entry *) 0x7fba70002ec0) [ec]
...

Add a regression test for this PR in test-case gdb.dwarf2/enum-type-c++.exp.

Tested on x86_64-linux.

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

[gdb/testsuite] Add gdb.dwarf2/enum-type-c++.exp, regression test for PR31900.

Consider the following test-case:
...
$ cat a.h
namespace ns {

class A {
public:
  enum {
    val1 = 1
  };
};

}
$ cat main.c

ns::A a;

int
main (void)
{
  return 0;
}
$ cat val1.c

int u1 = ns::A::val1;
...
compiled with debug info:
...
$ g++ main.c val1.c -g
...

When trying to print ns::A::val with current trunk and gdb 15.1 we get:
...
$ gdb -q -batch a.out -ex "print ns::A::val1"
There is no field named val1
...

This PR c++/31900.

With gdb 14.2 we get the expected:
...
$ gdb -q -batch a.out -ex "print ns::A::val1"
$1 = ns::A::val1
...

This is a regression since commit 4e417d7bb1c ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").

Reverting the commit on current trunk fixes the problem.

So how does this problem happen?

First, let's consider the current trunk, with the commit reverted.

Gdb looks for the entry ns::A::val1, and find this entry:
...
    [29] ((cooked_index_entry *) 0x7f7830002ef0)
    name:       val1
    canonical:  val1
    qualified:  ns::A::val1
    DWARF tag:  DW_TAG_enumerator
    flags:      0x0 []
    DIE offset: 0x15a
    parent:     ((cooked_index_entry *) 0x7f7830002ec0) [A]
...
and expands the corresponding CU val1.c containing this debug info:
...
 <2><14a>: Abbrev Number: 3 (DW_TAG_class_type)
    <14b>   DW_AT_name        : A
    <14d>   DW_AT_byte_size   : 1
 <3><150>: Abbrev Number: 4 (DW_TAG_enumeration_type)
    <151>   DW_AT_encoding    : 7       (unsigned)
    <152>   DW_AT_byte_size   : 4
    <153>   DW_AT_type        : <0x163>
    <159>   DW_AT_accessibility: 1      (public)
 <4><15a>: Abbrev Number: 5 (DW_TAG_enumerator)
    <15b>   DW_AT_name        : val1
    <15f>   DW_AT_const_value : 1
 <4><160>: Abbrev Number: 0
 <3><161>: Abbrev Number: 0
 <2><162>: Abbrev Number: 0
...
after which it finds ns::A::val1 in the expanded symtabs.

Now let's consider the current trunk as is (so, with the commit present).

Gdb looks for the entry ns::A::val1, but doesn't find it because the val1
entry is missing its parent:
...
   [29] ((cooked_index_entry *) 0x7f5240002ef0)
    name:       val1
    canonical:  val1
    qualified:  val1
    DWARF tag:  DW_TAG_enumerator
    flags:      0x0 []
    DIE offset: 0x15a
    parent:     ((cooked_index_entry *) 0)
...

Then gdb looks for the entry ns::A, and finds this entry:
...
   [3] ((cooked_index_entry *) 0x7f5248002ec0)
    name:       A
    canonical:  A
    qualified:  ns::A
    DWARF tag:  DW_TAG_class_type
    flags:      0x0 []
    DIE offset: 0xdd
    parent:     ((cooked_index_entry *) 0x7f5248002e90) [ns]
...
which corresponds to this debug info, which doesn't contain val1
due to -fno-eliminate-unused-debug-types:
...
 <2><dd>: Abbrev Number: 3 (DW_TAG_class_type)
    <de>   DW_AT_name        : A
    <e0>   DW_AT_byte_size   : 1
 <2><e3>: Abbrev Number: 0
...

Gdb expands the corresponding CU main.c, after which it doesn't find
ns::A::val1 in the expanded symtabs.

The root cause of the problem is the missing parent on the val1
cooked_index_entry, but this only becomes user-visible through the
elaborate scenario above.

Add a test-case gdb.dwarf2/enum-type-c++.exp that contains a regression test
for this problem that doesn't rely on expansion state or
-feliminate-unused-debug-types, but simply tests for the root cause by
grepping for ns::A::val1 in the output of "maint print objfile".

Tested on x86_64-linux.

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

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-15-branch: Clear the X86_XSTATE_MPX bit in XCRO for x32

commit 868883583e7520ff1bd99fcb224d2b33a990edff
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Sat Mar 23 16:17:36 2024 +0000

    gdb/arch: assert that X86_XSTATE_MPX is not set for x32

added

  if (xcr0 & X86_XSTATE_MPX)
    {
      /* MPX is not available on x32.  */
      gdb_assert (!is_x32);
      regnum = create_feature_i386_64bit_mpx (tdesc.get (), regnum);
    }

But x32 is a software convention.  There is no x32 mode in hardware and
CPU always returns the 64-bit mode XCR0 value for x32 processes.  This
regression was fixed on master branch by

commit bf616be99153b43c1077be9dbb7b081b4c080031 (HEAD)
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Thu Jan 25 14:25:57 2024 +0000

    gdb/gdbserver: share some code relating to target description creation

which used the gdbserver code to clear the X86_XSTATE_MPX bit in XCR0 for
x32.  Fix this regression on gdb-15-branch by clearing the X86_XSTATE_MPX
bit in XCR0 for x32 in gdb.

PR gdb/32143
* x86-linux-nat.c (x86_linux_nat_target::read_description): Clear
the X86_XSTATE_MPX bit in XCR0 for x32.

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

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

Recognize -2 as a tombstone value in .debug_line

Commit a8caed5d7faa639a1e6769eba551d15d8ddd9510 handled the tombstone
value -1 used by lld (https://reviews.llvm.org/D81784).  The
referenced lld commit also uses the tombstone value -2 for
pre-DWARF-v5
(https://github.com/llvm/llvm-project/commit/e618ccbf431f6730edb6d1467a127c3a52fd57f7).

If not handled, -2 breaks the pc step range calculation and triggers
the assertion:

  gdb/infrun.c:2794: internal-error: resume_1: Assertion
  `pc_in_thread_step_range (pc, tp)' failed.

This commit adds -2 tombstone value and handles it in the same way as -1.

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

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] Handle ^C during disassembly

In PR gdb/32025, a fatal error was reported when sending a SIGINT to gdb while
disassembling.

I managed to reproduce this on aarch64-linux in a Leap 15.5 container using
this trigger patch:
...
 gdb_disassembler_memory_reader::dis_asm_read_memory
   (bfd_vma memaddr, gdb_byte *myaddr, unsigned int len,
    struct disassemble_info *info) noexcept
 {
+  set_quit_flag ();
   return target_read_code (memaddr, myaddr, len);
 }
...
and a simple gdb command line calling the disassemble command:
...
$ gdb -q -batch a.out -ex "disassemble main"
...

The following scenario leads to the fatal error:
- the disassemble command is executed,
- set_quit_flag is called in
  gdb_disassembler_memory_reader::dis_asm_read_memory, pretending that a
  user pressed ^C,
- target_read_code calls QUIT, which throws a
  gdb_exception_quit,
- the exception propagation mechanism reaches c code in libopcodes and a fatal
  error triggers because the c code is not compiled with -fexception.

Fix this by:
- wrapping the body of gdb_disassembler_memory_reader::dis_asm_read_memory in
  catch_exceptions (which consequently needs moving to a header file), and
- reraising the caught exception in default_print_insn using QUIT.

Tested on aarch64-linux.

Approved-By: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32025
(cherry picked from commit c45c3b4162148077765e94fd17d4481f18d6d44c)

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

Mark unavailable bytes of limited-length arrays when allocating contents

Using 'output' to print arrays larger than max-value-size, with only
repeating elements, can cause gdb to crash:
```
$ cat a.c:
char a[1000000];

int main()
{
  return a[0];
}
$ gdb -q a
(gdb) print a
$1 = {0 '\000' <repeats 65536 times>, <unavailable> <repeats 934464 times>}
(gdb) output a

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```

Using 'print' works, because value::record_latest sets the unavailable
bytes of the value when it's added to the value history.
But 'outout' doesn't do that, so the printing tries to access more bytes
than are available.

The original problem in PR32015 was about using 'print' of a dynamic
array in a D program.
Here the crash happens because for 'print' the value was a struct with
length/ptr fields, which is converted in d-valprint.c into an array.
So value::record_latest didn't have a chance to mark the unavailable
bytes in this case.

To make sure the unavailable bytes always match the contents, this fixes
it by marking the unavailable bytes immediately after the contents are
allocated.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32015
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
(cherry picked from commit 8fdd2b2bcd8117cafcc6ef976e45f0d9f95fb528)