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)

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/solib-frv: move lm_info object to solib

I noticed that the lm_info_frv objects created in frv_current_sos are
never moved to the solib object.  This bug was introduced in 8971d2788e
("gdb: link so_list using intrusive_list"), which mistakenly removed the
line

    sop->lm_info = std::move (li);

... probably due so a bad merge conflict resolution.

Re-add this line.

If merged in master, I would cherry-pick this to gdb-15-branch.

Change-Id: I609a1a5ad39e93f70a95ea5ebe3f8ff4ab6a8db2
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32005
Approved-By: Andrew Burgess <aburgess@redhat.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

Fix loading a saved recording

Currently you get this assertion failure if you try to execute the
inferior after loading a saved recording, when no recording was done
earlier in the same gdb session:
```
$ gdb -q c -ex "record restore test.rec"
Reading symbols from c...
[New LWP 26428]
Core was generated by `/tmp/c'.
Restored records from core file /tmp/test.rec.
(gdb) c
Continuing.
../../gdb/inferior.c:293: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
```

The change in step-precsave.exp triggers this bug, since now the
recording is loaded in a new gdb session, where
record_full_resume_ptid was never set.

The fix is to simply set record_full_resume_ptid when resuming a loaded
recording.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31971
Approved-By: Guinevere Larsen <blarsen@redhat.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

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

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

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

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

Set GDB version number to 15.1.

This commit changes gdb/version.in to 15.1.

Automatic date update in version.in

Automatic date update in version.in

Fix cast types for opencl

The bitshift tests for opencl have these failures:

print /x (signed char) 0x0f << 8
No type named signed char.
(gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print /x (signed char) 0x0f << 8
print (signed char) 0x0f << 8
No type named signed char.
(gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print (signed char) 0x0f << 8

Apparently opencl doesn't have the 'signed' modifier for types, only
the 'unsigned' modifier.
Even 'char' is guaranteed to be signed if no modifier is used, so
this changes the casts to match this logic.

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

Fix 64-bit shifts where long only has 32-bit size

On systems where long has 32-bit size you get these failures:

print 1 << (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 << (unsigned long long) 0xffffffffffffffff
print 1 >> (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 >> (unsigned long long) 0xffffffffffffffff
print -1 << (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 << (unsigned long long) 0xffffffffffffffff
print -1 >> (unsigned long long) 0xffffffffffffffff
Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295)
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 >> (unsigned long long) 0xffffffffffffffff

Fixed by changing the number-of-bits variable to ULONGEST.

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

Fix too-large or negative right shift of negative numbers

As seen in these test failures:

print -1 >> -1
warning: right shift count is negative
$N = 0
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -1 >> -1
print -4 >> -2
warning: right shift count is negative
$N = 0
(gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -4 >> -2

Fixed by restoring the logic from before the switch to gmp.

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

Fix right shift of negative numbers

PR31590 shows that right shift of negative numbers doesn't work
correctly since GDB 14:

(gdb) p (-3) >> 1
$1 = -1

GDB 13 and earlier returned the correct value -2.
And there actually is one test that shows the failure:

print -1 >> 1
$84 = 0
(gdb) FAIL: gdb.base/bitshift.exp: lang=asm: rsh neg lhs: print -1 >> 1

The problem was introduced with the change to gmp functions in
commit 303a881f87.
It's wrong because gdb_mpz::operator>> uses mpz_tdif_q_2exp, which
always rounds toward zero, and the gmp docu says this:

For positive n both mpz_fdiv_q_2exp and mpz_tdiv_q_2exp are simple
bitwise right shifts.
For negative n, mpz_fdiv_q_2exp is effectively an arithmetic right shift
treating n as two's complement the same as the bitwise logical functions
do, whereas mpz_tdiv_q_2exp effectively treats n as sign and magnitude.

So this changes mpz_tdiv_q_2exp to mpz_fdiv_q_2exp, since it
does right shifts for both positive and negative numbers.

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

Restore bitshift.exp tests

Commit cdd4206647 unintentionally disabled all tests of bitshift.exp,
so it actually just does this:

Running /c/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/bitshift.exp ...
PASS: gdb.base/bitshift.exp: complete set language

=== gdb Summary ===

 # of expected passes 1

It changed the 'continue' of unsupported languages to 'return', and
since ada is the first language and is unsupported, no tests were run.

This changes it back to 'continue', and the following patches fix
the regressions that were introduced since then unnoticed.

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

Fix gdb.lookup_type for function-local types

Looking for a type defined locally in a function doesn't work
any more since the introduction of TYPE_DOMAIN:
```
(gdb) python print (gdb.lookup_type ('main()::Local'))
Python Exception <class 'gdb.error'>: No type named main()::Local.
Error occurred in Python: No type named main()::Local.
```

cp_search_static_and_baseclasses was simply missing a check for
SEARCH_TYPE_DOMAIN, now it works again:
```
(gdb) python print (gdb.lookup_type ('main()::Local'))
Local
```

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

Include needed unordered_map header

Compiling on FreeBSD 13.2 with the default clang version 14.0.5 and top level
configure options --with-python=/usr/local/bin/python3.9 gives this error:

  CXX    ada-exp.o
./../binutils-gdb/gdb/ada-exp.y:100:8: error: no template named 'unordered_map' in namespace 'std'
  std::unordered_map<std::string, std::vector<ada_index_var_operation *>>
  ~~~~~^
1 error generated.

This change fixes it.

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

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

[gdb/tdep] Fix gdb.base/watchpoint-running.exp on {arm,ppc64le}-linux

When running test-case gdb.base/watchpoint-running on ppc64le-linux (and
similar on arm-linux), we get:
...
(gdb) watch global_var^M
warning: Error when detecting the debug register interface. \
  Debug registers will be unavailable.^M
Watchpoint 2: global_var^M
(gdb) FAIL: $exp: all-stop: hardware: watch global_var
FAIL: $exp: all-stop: hardware: watchpoint hit (timeout)
...

The problem is that ppc_linux_dreg_interface::detect fails to detect the
hardware watchpoint interface, because the calls to ptrace return with errno
set to ESRCH.

This is a feature of ptrace: if a call is done while the tracee is not
ptrace-stopped, it returns ESRCH.

Indeed, in the test-case "watch global_var" is executed while the inferior is
running, and that triggers the first call to ppc_linux_dreg_interface::detect.

And because the detection failure is cached, subsequent attempts at setting
hardware watchpoints will also fail, even if the tracee is ptrace-stopped.

The way to fix this is to make sure that ppc_linux_dreg_interface::detect is
called when we know that the thread is ptrace-stopped, which in the current
setup is best addressed by using target-specific post_attach and
post_startup_inferior overrides.  However, as we can see in
aarch64_linux_nat_target, that causes code duplication.

Fix this by:
- defining a new target hook low_init_process, called from
  linux_init_ptrace_procfs, which is called from both
  linux_nat_target::post_attach and linux_nat_target::post_startup_inferior,
- adding implementations for ppc_linux_nat_target and arm_linux_nat_target
  that detect the hardware watchpoint interface,
- replacing the aarch64_linux_nat_target implementations of post_attach and
  post_startup_inferior with a low_init_process implementation.

Tested on ppc64le-linux, arm-linux, aarch64-linux and x86_64-linux.

Co-Authored-By: Tom de Vries <tdevries@suse.de>
Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/31834
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31834
PR tdep/31705
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31705

(cherry picked from commit 50de502a4f843310e231b3174804e95a9e7de4fc)

Automatic date update in version.in

[gdb/python] Fix gdb.python/py-disasm.exp on arm-linux

After fixing test-case gdb.python/py-disasm.exp to recognize the arm nop:
...
nop {0}
...
we run into:
...
disassemble test^M
Dump of assembler code for function test:^M
   0x004004d8 <+0>:     push    {r11}           @ (str r11, [sp, #-4]!)^M
   0x004004dc <+4>:     add     r11, sp, #0^M
   0x004004e0 <+8>:     nop     {0}^M
=> 0x004004e4 <+12>:    Python Exception <class 'ValueError'>: Buffer \
  returned from read_memory is sized 0 instead of the expected 4^M
^M
unknown disassembler error (error = -1)^M
(gdb) FAIL: $exp: global_disassembler=ShowInfoRepr: disassemble test
...

This is caused by this code in gdbpy_disassembler::read_memory_func:
...
  gdbpy_ref<> result_obj (PyObject_CallMethod ((PyObject *) obj,
                                              "read_memory",
                                              "KL", len, offset));
...
where len has type "unsigned int", while "K" means "unsigned long long" [1].

Fix this by using "I" instead, meaning "unsigned int".

Also, offset has type LONGEST, which is typedef'ed to int64_t, while "L" means
"long long".

Fix this by using type gdb_py_longest for offset, in combination with format
character "GDB_PY_LL_ARG".  Likewise in disasmpy_info_read_memory.

Tested on arm-linux.

Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR python/31845
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845

[1] https://docs.python.org/3/c-api/arg.html

(cherry picked from commit 4cd214dce4579f86a85a96c882e0fc8c4d94601c)

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