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

Fix crash when calling Frame.static_link

If you try to call Frame.static_link for a frame without debug info,
gdb crashes:
```
Temporary breakpoint 1, 0x000000013f821650 in main ()
(gdb) py print(gdb.selected_frame().static_link())

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

The problem was a missing check if get_frame_block returns nullptr
inside frame_follow_static_link.

With this, it works:
```
Temporary breakpoint 1, 0x000000013f941650 in main ()
(gdb) py print(gdb.selected_frame().static_link())
None
```

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31366
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

[gdb/tdep] Fix use-after-free in arm_exidx_fill_cache

On arm-linux the linaro CI occasionally reports:
...
 (gdb) up 10
 #4  0x0001b864 in pthread_join ()
 (gdb) FAIL: gdb.threads/staticthreads.exp: up 10
...
while this is expected:
...
 (gdb) up 10
 #3  0x00010568 in main (argc=1, argv=0xfffeede4) at staticthreads.c:76
 76          pthread_join (thread, NULL);
 (gdb) PASS: gdb.threads/staticthreads.exp: up 10
...

Thiago investigated the problem, and using valgrind found an invalid read in
arm_exidx_fill_cache.

The problem happens as follows:
- an objfile and corresponding per_bfd are allocated
- some memory is allocated in arm_exidx_new_objfile using
  objfile->objfile_obstack, for the "exception table entry cache".
- a symbol reread is triggered, and the objfile, including the
  objfile_obstack, is destroyed
- a new objfile is allocated, using the same per_bfd
- again arm_exidx_new_objfile is called, but since the same per_bfd is used,
  it doesn't allocate any new memory for the "exception table entry cache".
- the "exception table entry cache" is accessed by arm_exidx_fill_cache,
  and we have a use-after-free.

This is a regression since commit a2726d4ff80 ("[ARM] Store exception handling
information per-bfd instead of per-objfile"), which changed the "exception
table entry cache" from per-objfile to per-bfd, but failed to update the
obstack_alloc.

Fix this by using objfile->per_bfd->storage_obstack instead of
objfile->objfile_obstack.

I couldn't reproduce the FAIL myself, but Thiago confirmed that the patch
fixes it.

Tested on arm-linux.

Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/31254
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31254

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 "list ." related crash

When a user attempts to use the "list ." command with an inferior that
doesn't have debug symbols, GDB would crash. This was reported as PR
gdb/31256.

The crash would happen when attempting to get the current symtab_and_line
for the stop location, because the symtab would return a null pointer
and we'd attempt to dereference it to print the line.

This commit fixes that by checking for an empty symtab and erroring out
of the function if it happens.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31256
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

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

Fix printing of global variable stubs if no inferior is running

Since 3c45e9f915ae4aeab7312d6fc55a947859057572 gdb crashes when trying
to print a global variable stub without a running inferior, because of
a missing nullptr-check (the block_scope function took care of that
check before it was converted to a method).

With this check it works again:
```
(gdb) print s
$1 = <incomplete type>
```

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

Automatic date update in version.in

Automatic date update in version.in

Fix DLL export forwarding

I noticed it when I was trying to set a breakpoint at ExitProcess:
```
(gdb) b ExitProcess
Breakpoint 1 at 0x14001fdd0
(gdb) r
Starting program: C:\qiewer\heob\heob64.exe
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x3dbf4120
Cannot insert breakpoint 1.
Cannot access memory at address 0x77644120
```

The problem doesn't exist in gdb 13.2, and the difference can easily be
seen when printing ExitProcess.
gdb 14.1:
```
(gdb) p ExitProcess
$1 = {<text variable, no debug info>} 0x77644120 <UserHandleGrantAccess+36128>
```
gdb 13.2:
```
(gdb) p ExitProcess
$1 = {<text variable, no debug info>} 0x77734120 <ntdll!RtlExitUserProcess>
```

The new behavior started with 9675da25357c7a3f472731ddc6eb3becc65b469a,
where VMA was then calculated relative to FORWARD_DLL_NAME, while it was
relative to DLL_NAME before.

Fixed by calculating VMA relative to DLL_NAME again.

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

Automatic date update in version.in

Automatic date update in version.in

Automatic date update in version.in

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

This commit changes gdb/version.in to 14.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 14.1.

This commit changes gdb/version.in to 14.1.

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

i386: Use a fallback XSAVE layout for remote targets

If a target provides a target description including registers from the
XSAVE extended region, but does not provide an XSAVE layout, use a
fallback XSAVE layout based on the included registers.  This fallback
layout matches GDB's behavior in earlier releases which assumes the
layout from Intel CPUs.

This fallback layout is currently only used for remote targets since
native targets which support XSAVE provide an explicit layout derived
from CPUID.

PR gdb/30912
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30912
Approved-By: Simon Marchi <simon.marchi@efficios.com>
(cherry picked from commit 66637e209cc836c19a21a28e91046649c7702037)

Fix bug in DAP handling of 'pause' requests

While working on cancellation, I noticed that a DAP 'pause' request
would set the "do not emit the continue" flag.  This meant that a
subsequent request that should provoke a 'continue' event would
instead suppress the event.

I then tried writing a more obvious test case for this, involving an
inferior call -- and discovered that gdb.events.cont does not fire for
an inferior call.

This patch installs a new event listener for gdb.events.inferior_call
and arranges for this to emit continue and stop events when
appropriate.  It also fixes the original bug, by adding a check to
exec_and_expect_stop.

(cherry picked from commit c618a1c548193d2a6a8c3d909a3d1c620a156b5d)

Automatic date update in version.in