When running test-case gdb.cp/step-and-next-inline.exp with gcc-11, I run
into:
...
KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 1 \
(PRMS symtab/25507)
FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 2
KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 3 \
(PRMS symtab/25507)
...
[ Note that I get the same result with gcc-11 and target board
unix/gdb:debug_flags=-gdwarf-4, so this is not a dwarf 4 vs 5 issue. ]
With gcc-10, I have this trace:
...
64 get_alias_set (&xx);
get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51
51 if (t != NULL
40 if (t->x != i)
52 && TREE_TYPE (t).z != 1
43 return x;
53 && TREE_TYPE (t).z != 2
43 return x;
54 && TREE_TYPE (t).z != 3)
43 return x;
main () at step-and-next-inline.cc:65
65 return 0;
...
and with gcc-11, I have instead:
...
64 get_alias_set (&xx);
get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51
51 if (t != NULL
52 && TREE_TYPE (t).z != 1
43 return x;
53 && TREE_TYPE (t).z != 2
43 return x;
54 && TREE_TYPE (t).z != 3)
43 return x;
main () at step-and-next-inline.cc:65
65 return 0;
...
and with clang-10, I have instead:
...
64 get_alias_set (&xx);
get_alias_set (t=0x601034 <xx>) at step-and-next-inline.cc:51
51 if (t != NULL
52 && TREE_TYPE (t).z != 1
53 && TREE_TYPE (t).z != 2
54 && TREE_TYPE (t).z != 3)
51 if (t != NULL
57 }
main () at step-and-next-inline.cc:65
65 return 0;
...
The test-case tries to verify that we don't step into inlined function
tree_check (lines 40-43) (so, with the clang trace we get that right).
The test-case then tries to kfail the problems when using gcc, but this is
done in such a way that the testing still gets out of sync after a failure.
That is: the "next step 2" check that is supposed to match
"TREE_TYPE (t).z != 2" is actually matching "TREE_TYPE (t).z != 1":
...
(gdb) next^M
52 && TREE_TYPE (t).z != 1^M
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: next step 2
...
Fix this by issuing extra nexts to arrive at the required lines.
Tested on x86_64-linux, with gcc-8, gcc-9, gcc-10, gcc-11, clang-8, clang-10
and clang-12.
gdb/testsuite/ChangeLog:
2021-07-22 Tom de Vries <tdevries@suse.de>
* gdb.cp/step-and-next-inline.cc (tree_check, get_alias_set, main):
Tag closing brace with comment.
* gdb.cp/step-and-next-inline.h: Update to keep identical with
step-and-next-inline.cc.
* gdb.cp/step-and-next-inline.exp: Issue extra next when required.
When running test-case gdb.base/ptype-offsets.exp with gcc-11 (with -gdwarf-5
default) or gcc-10 with target board unix/gdb:debug_flags=-gdwarf-5 we run
into this regression:
...
(gdb) ptype/o static_member^M
/* offset | size */ type = struct static_member {^M
- static static_member Empty;^M
/* 0 | 4 */ int abc;^M
^M
/* total size (bytes): 4 */^M
}^M
-(gdb) PASS: gdb.base/ptype-offsets.exp: ptype/o static_member
+(gdb) FAIL: gdb.base/ptype-offsets.exp: ptype/o static_member
...
This is caused by missing debug info, which I filed as gcc PR101452 - "[debug,
dwarf-5] undefined static member removed by
-feliminate-unused-debug-symbols".
It's not clear yet whether this is a bug or a feature, but work around this in
the test-cases by:
- defining the static member
- adding additional_flags=-fno-eliminate-unused-debug-types.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-07-21 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gcc_major_version): New proc.
* gdb.base/ptype-offsets.cc: Define static member static_member::Empty.
* gdb.cp/templates.exp: Define static member using -DGCC_BUG.
* gdb.cp/m-static.exp: Add
additional_flags=-fno-eliminate-unused-debug-types.
* gdb.cp/pr-574.exp: Same.
* gdb.cp/pr9167.exp: Same.
With gcc-11 we run into:
...
(gdb) print pa_ptr.all^M
That operation is not available on integers of more than 8 bytes.^M
(gdb) KFAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all (PRMS: gdb/20991)
...
This is due to PR exp/20991 - "__int128 type support". Mark this and similar
FAILs as KFAIL.
Also mark this FAIL:
....
(gdb) print pa_ptr(3)^M
cannot subscript or call something of type `foo__packed_array_ptr'^M
(gdb) FAIL: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr(3)
...
as a KFAIL for PR ada/28115 - "Support packed array encoded as
DW_TAG_subrange_type".
Tested on x86_64-linux, with gcc-10 and gcc-11.
gdb/testsuite/ChangeLog:
2021-07-21 Tom de Vries <tdevries@suse.de>
* gdb.ada/arrayptr.exp: Add KFAILs for PR20991 and PR28115.
* gdb.ada/exprs.exp: Add KFAILs for PR20991.
* gdb.ada/packed_array_assign.exp: Same.
When the architecture supports memory tagging, we handle
pointer/reference types in a special way, so we can validate tags and
show mismatches.
Unfortunately, the currently implementation errors out when the user
prints non-address values: composite types, floats, references, member
functions and other things.
Vector registers:
(gdb) p $v0
Value can't be converted to integer.
Non-existent internal variables:
(gdb) p $foo
Value can't be converted to integer.
The same happens for complex types and printing struct/union types.
There are a few problems here.
The first one is that after print_command_1 evaluates the expression
to print, the tag validation code call value_as_address
unconditionally, without making sure we have have a suitable type
where it makes to sense to call it. That results in value_as_address
(if it isn't given a pointer-like type) trying to treat the value as
an integer and convert it to an address, which #1 - doesn't make sense
(i.e., no sense in validating tags after "print 1"), and throws for
non-integer-convertible types. We fix this by making sure we have a
pointer or reference type first, and only if so then proceed to check
if the address-like value has tags.
The second is that we're calling value_as_address even if we have an
optimized out or unavailable value, which throws, because the value's
contents aren't fully accessible/readable. This error currently
escapes out and aborts the print. This case is fixed by checking for
optimized out / unavailable explicitly.
Third, the tag checking process does not gracefully handle exceptions.
If any exception is thrown from the tag validation code, we abort the
print. E.g., the target may fail to access tags via a running thread.
Or the needed /proc files aren't available. Or some other untold
reason. This is a bit too rigid. This commit changes print_command_1
to catch errors, print them, and still continue with the normal
expression printing path instead of erroring out and printing nothing
useful.
With this patch, printing works correctly again:
(gdb) p $v0
$1 = {d = {f = {2.0546950501119882e-81, 2.0546950501119882e-81}, u = {3399988123389603631, 3399988123389603631}, s = {
3399988123389603631, 3399988123389603631}}, s = {f = {1.59329203e-10, 1.59329203e-10, 1.59329203e-10, 1.59329203e-10}, u = {
791621423, 791621423, 791621423, 791621423}, s = {791621423, 791621423, 791621423, 791621423}}, h = {bf = {1.592e-10,
1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10}, f = {0.11224, 0.11224, 0.11224, 0.11224, 0.11224,
0.11224, 0.11224, 0.11224}, u = {12079, 12079, 12079, 12079, 12079, 12079, 12079, 12079}, s = {12079, 12079, 12079, 12079,
12079, 12079, 12079, 12079}}, b = {u = {47 <repeats 16 times>}, s = {47 <repeats 16 times>}}, q = {u = {
62718710765820030520700417840365121327}, s = {62718710765820030520700417840365121327}}}
(gdb) p $foo
$2 = void
(gdb) p 2 + 2i
$3 = 2 + 2i
gdb/ChangeLog
2021-07-20 Luis Machado <luis.machado@linaro.org>
Pedro Alves <pedro@palves.net>
PR gdb/28110
* gdbarch.sh: Updated documentation for gdbarch_tagged_address_p.
* gdbarch.h: Regenerate.
* printcmd.c (should_validate_memtags): Reorder comparisons and only
validate tags for pointer and reference types. Skip validation of
optimized out or unavailable values.
(print_command_1): Guard call memory tagging validation code with
a try/catch block.
Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: I82bf00ac88d23553b3f7563c9872dfa6ca1f2207
PR gdb/28093 points out that gdb crashes when language is set to
"unknown" and expression parsing is attempted. At first I thought
this was a regression due to the expression rewrite, but it turns out
that older versions crash as well.
This patch avoids the crash by changing the default expression parser
to throw an exception. I think this is preferable -- the current
behavior of silently doing nothing does not really make sense.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28093
(cherry picked from commit dcd482c1b7)
gdb/ChangeLog
2021-07-19 Tom Tromey <tromey@adacore.com>
PR gdb/28093
* language.c (auto_or_unknown_language::parser): Call error.
gdb/testsuite/ChangeLog
2021-07-19 Tom Tromey <tromey@adacore.com>
PR gdb/28093
* gdb.base/langs.exp: Add tests.
When running test-case gdb.base/gold-gdb-index.exp on openSUSE Tumbleweed,
I run into:
...
FAIL: gdb.base/gold-gdb-index.exp: maint info symtabs
...
This is due to a dummy .gdb_index:
...
Contents of the .gdb_index section:
Version 7
CU table:
TU table:
Address table:
Symbol table:
...
The dummy .gdb_index is ignored when loading the symbols, and instead partial
symbols are used. Consequently, we get the same result as if we'd removed
-Wl,--gdb-index from the compilation.
Presumably, gold fails to generate a proper .gdb_index because it lacks
DWARF5 support.
Anyway, without a proper .gdb_index we can't test the gdb behaviour we're
trying to excercise. Fix this by detecting whether we actually used a
.gdb_index for symbol loading.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-07-14 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (have_index): New proc.
* gdb.base/gold-gdb-index.exp: Use have_index.
While testing the NixOS[1] packaging for gdb-11.0.90.tar.xz, I got the
following error:
[...]
CXX aarch32-tdep.o
CXX gdb.o
GEN init.c
/nix/store/26a78ync552m8j4sbjavhvkmnqir8c9y-bash-4.4-p23/bin/bash: ./make-init-c: /usr/bin/env: bad interpreter: No such file or directory
make[2]: *** [Makefile:1866: stamp-init] Error 126
make[2]: *** Waiting for unfinished jobs....
make[2]: Leaving directory '/build/gdb-11.0.90/gdb'
make[1]: *** [Makefile:9814: all-gdb] Error 2
make[1]: Leaving directory '/build/gdb-11.0.90'
make: *** [Makefile:903: all] Error 2
builder for '/nix/store/xs8my3rrc3l4kdlbpx0azh6q0v0jxphr-gdb-gdb-11.0.90.drv' failed with exit code 2
error: build of '/nix/store/xs8my3rrc3l4kdlbpx0azh6q0v0jxphr-gdb-gdb-11.0.90.drv' failed
In the nix build environment, /usr/bin/env is not present, only /bin/sh
is. This patch makes sure that gdb/make-init-c uses '/bin/sh' as
interpreter as this is the only one available on this platform.
I do not think this change will cause regressions on any other
configuration.
[1] https://nixos.org/
gdb/Changelog
* make-init-c: Use /bin/sh as shebang.
Before PR gdb/28080 was fixed by the previous patch, GDB was crashing
like this:
(gdb) detach
Detaching from program: target:/any/program, process 3671843
Detaching from process 3671843
Ending remote debugging.
[Inferior 1 (process 3671843) detached]
In main
terminate called after throwing an instance of 'gdb_exception_error'
Aborted (core dumped)
Here's the exception above being thrown:
(top-gdb) bt
#0 throw_error (error=TARGET_CLOSE_ERROR, fmt=0x555556035588 "Remote connection closed") at src/gdbsupport/common-exceptions.cc:222
#1 0x0000555555bbaa46 in remote_target::readchar (this=0x555556a11040, timeout=10000) at src/gdb/remote.c:9440
#2 0x0000555555bbb9e5 in remote_target::getpkt_or_notif_sane_1 (this=0x555556a11040, buf=0x555556a11058, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9928
#3 0x0000555555bbbda9 in remote_target::getpkt_sane (this=0x555556a11040, buf=0x555556a11058, forever=0) at src/gdb/remote.c:10030
#4 0x0000555555bc0e75 in remote_target::remote_hostio_send_command (this=0x555556a11040, command_bytes=13, which_packet=14, remote_errno=0x7fffffffcfd0, attachment=0x0, attachment_len=0x0) at src/gdb/remote.c:12137
#5 0x0000555555bc1b6c in remote_target::remote_hostio_close (this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12455
#6 0x0000555555bc1bb4 in remote_target::fileio_close (During symbol reading: .debug_line address at offset 0x64f417 is 0 [in module build/gdb/gdb]
this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12462
#7 0x0000555555c9274c in target_fileio_close (fd=3, target_errno=0x7fffffffcfd0) at src/gdb/target.c:3365
#8 0x000055555595a19d in gdb_bfd_iovec_fileio_close (abfd=0x555556b9f8a0, stream=0x555556b11530) at src/gdb/gdb_bfd.c:439
#9 0x0000555555e09e3f in opncls_bclose (abfd=0x555556b9f8a0) at src/bfd/opncls.c:599
#10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556b9f8a0) at src/bfd/opncls.c:847
#11 0x0000555555e0a27a in bfd_close (abfd=0x555556b9f8a0) at src/bfd/opncls.c:814
#12 0x000055555595a9d3 in gdb_bfd_close_or_warn (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:626
#13 0x000055555595ad29 in gdb_bfd_unref (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:715
#14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573
#15 0x0000555555ae955a in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:377
#16 0x000055555572b7c8 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
#17 0x00005555557263c3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x555556bf0588, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:730
#18 0x0000555555ae745e in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
#19 0x0000555555ae747e in std::shared_ptr<objfile>::~shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr.h:103
#20 0x0000555555b1c1dc in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x5555564cdd60, __p=0x555556bf0580) at /usr/include/c++/9/ext/new_allocator.h:153
#21 0x0000555555b1bb1d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556bf0580) at /usr/include/c++/9/bits/alloc_traits.h:497
#22 0x0000555555b1b73e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/stl_list.h:1921
#23 0x0000555555b1afeb in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/list.tcc:158
#24 0x0000555555b19576 in program_space::remove_objfile (this=0x5555564cdd20, objfile=0x555556515540) at src/gdb/progspace.c:210
#25 0x0000555555ae4502 in objfile::unlink (this=0x555556515540) at src/gdb/objfiles.c:487
#26 0x0000555555ae5a12 in objfile_purge_solibs () at src/gdb/objfiles.c:875
#27 0x0000555555c09686 in no_shared_libraries (ignored=0x0, from_tty=1) at src/gdb/solib.c:1236
#28 0x00005555559e3f5f in detach_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:2769
Note frame #14:
#14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573
That's a dtor, thus noexcept. That's the reason for the
std::terminate.
The previous patch fixed things such that the exception above isn't
thrown anymore. However, it's possible that e.g., the remote
connection drops just while a user types "nosharedlibrary", or some
other reason that leads to objfile::~objfile, and then we end up the
same std::terminate problem.
Also notice that frames #9-#11 are BFD frames:
#9 0x0000555555e09e3f in opncls_bclose (abfd=0x555556bc27e0) at src/bfd/opncls.c:599
#10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556bc27e0) at src/bfd/opncls.c:847
#11 0x0000555555e0a27a in bfd_close (abfd=0x555556bc27e0) at src/bfd/opncls.c:814
BFD is written in C and thus throwing exceptions over such frames may
either not clean up properly, or, may abort if bfd is not compiled
with -fasynchronous-unwind-tables (x86-64 defaults that on, but not
all GCC ports do).
Thus frame #8 seems like a good place to swallow exceptions. More so
since in this spot we already ignore target_fileio_close return
errors. That's what this commit does. Without the previous fix, we'd
see:
(gdb) detach
Detaching from program: target:/any/program, process 2197701
Ending remote debugging.
[Inferior 1 (process 2197701) detached]
warning: cannot close "target:/lib64/ld-linux-x86-64.so.2": Remote connection closed
Note it prints a warning, which would still be a regression compared
to GDB 10, if it weren't for the previous fix.
gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <pedro@palves.net>
PR gdb/28080
* gdb_bfd.c (gdb_bfd_close_warning): New.
(gdb_bfd_iovec_fileio_close): Wrap target_fileio_close in
try/catch and print warning on exception.
(gdb_bfd_close_or_warn): Use gdb_bfd_close_warning.
Change-Id: Ic7a26ddba0a4444e3377b0e7c1c89934a84545d7
Commit 408f66864a ("detach in all-stop
with threads running") regressed "detach" with "target remote":
(gdb) detach
Detaching from program: target:/any/program, process 3671843
Detaching from process 3671843
Ending remote debugging.
[Inferior 1 (process 3671843) detached]
In main
terminate called after throwing an instance of 'gdb_exception_error'
Aborted (core dumped)
Here's the exception above being thrown:
(top-gdb) bt
#0 throw_error (error=TARGET_CLOSE_ERROR, fmt=0x555556035588 "Remote connection closed") at src/gdbsupport/common-exceptions.cc:222
#1 0x0000555555bbaa46 in remote_target::readchar (this=0x555556a11040, timeout=10000) at src/gdb/remote.c:9440
#2 0x0000555555bbb9e5 in remote_target::getpkt_or_notif_sane_1 (this=0x555556a11040, buf=0x555556a11058, forever=0, expecting_notif=0, is_notif=0x0) at src/gdb/remote.c:9928
#3 0x0000555555bbbda9 in remote_target::getpkt_sane (this=0x555556a11040, buf=0x555556a11058, forever=0) at src/gdb/remote.c:10030
#4 0x0000555555bc0e75 in remote_target::remote_hostio_send_command (this=0x555556a11040, command_bytes=13, which_packet=14, remote_errno=0x7fffffffcfd0, attachment=0x0, attachment_len=0x0) at src/gdb/remote.c:12137
#5 0x0000555555bc1b6c in remote_target::remote_hostio_close (this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12455
#6 0x0000555555bc1bb4 in remote_target::fileio_close (During symbol reading: .debug_line address at offset 0x64f417 is 0 [in module build/gdb/gdb]
this=0x555556a11040, fd=8, remote_errno=0x7fffffffcfd0) at src/gdb/remote.c:12462
#7 0x0000555555c9274c in target_fileio_close (fd=3, target_errno=0x7fffffffcfd0) at src/gdb/target.c:3365
#8 0x000055555595a19d in gdb_bfd_iovec_fileio_close (abfd=0x555556b9f8a0, stream=0x555556b11530) at src/gdb/gdb_bfd.c:439
#9 0x0000555555e09e3f in opncls_bclose (abfd=0x555556b9f8a0) at src/bfd/opncls.c:599
#10 0x0000555555e0a2c7 in bfd_close_all_done (abfd=0x555556b9f8a0) at src/bfd/opncls.c:847
#11 0x0000555555e0a27a in bfd_close (abfd=0x555556b9f8a0) at src/bfd/opncls.c:814
#12 0x000055555595a9d3 in gdb_bfd_close_or_warn (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:626
#13 0x000055555595ad29 in gdb_bfd_unref (abfd=0x555556b9f8a0) at src/gdb/gdb_bfd.c:715
#14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573
#15 0x0000555555ae955a in std::_Sp_counted_ptr<objfile*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:377
#16 0x000055555572b7c8 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x555556c20db0) at /usr/include/c++/9/bits/shared_ptr_base.h:155
#17 0x00005555557263c3 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x555556bf0588, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:730
#18 0x0000555555ae745e in std::__shared_ptr<objfile, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr_base.h:1169
#19 0x0000555555ae747e in std::shared_ptr<objfile>::~shared_ptr (this=0x555556bf0580, __in_chrg=<optimized out>) at /usr/include/c++/9/bits/shared_ptr.h:103
#20 0x0000555555b1c1dc in __gnu_cxx::new_allocator<std::_List_node<std::shared_ptr<objfile> > >::destroy<std::shared_ptr<objfile> > (this=0x5555564cdd60, __p=0x555556bf0580) at /usr/include/c++/9/ext/new_allocator.h:153
#21 0x0000555555b1bb1d in std::allocator_traits<std::allocator<std::_List_node<std::shared_ptr<objfile> > > >::destroy<std::shared_ptr<objfile> > (__a=..., __p=0x555556bf0580) at /usr/include/c++/9/bits/alloc_traits.h:497
#22 0x0000555555b1b73e in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::_M_erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/stl_list.h:1921
#23 0x0000555555b1afeb in std::__cxx11::list<std::shared_ptr<objfile>, std::allocator<std::shared_ptr<objfile> > >::erase (this=0x5555564cdd60, __position=std::shared_ptr<objfile> (expired, weak count 1) = {get() = 0x555556515540}) at /usr/include/c++/9/bits/list.tcc:158
#24 0x0000555555b19576 in program_space::remove_objfile (this=0x5555564cdd20, objfile=0x555556515540) at src/gdb/progspace.c:210
#25 0x0000555555ae4502 in objfile::unlink (this=0x555556515540) at src/gdb/objfiles.c:487
#26 0x0000555555ae5a12 in objfile_purge_solibs () at src/gdb/objfiles.c:875
#27 0x0000555555c09686 in no_shared_libraries (ignored=0x0, from_tty=1) at src/gdb/solib.c:1236
#28 0x00005555559e3f5f in detach_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:2769
So frame #28 already detached the remote process, and then we're
purging the shared libraries. GDB had opened remote shared libraries
via the target: sysroot, so it tries closing them. GDBserver is
tearing down already, so remote communication breaks down and we close
the remote target and throw TARGET_CLOSE_ERROR.
Note frame #14:
#14 0x0000555555ae4730 in objfile::~objfile (this=0x555556515540, __in_chrg=<optimized out>) at src/gdb/objfiles.c:573
That's a dtor, thus noexcept. That's the reason for the
std::terminate.
Stepping back a bit, why do we still have open remote files if we've
managed to detach already, and, we're debugging with "target remote"?
The reason is that commit 408f66864a
makes detach_command hold a reference to the target, so the remote
target won't be finally closed until frame #28 returns. It's closing
the target that invalidates target file I/O handles.
This commit fixes the issue by not relying on target_close to
invalidate the target file I/O handles, instead invalidate them
immediately in remote_unpush_target. So when GDB purges the solibs,
and we end up in target_fileio_close (frame #7 above), there's nothing
to do, and we don't try to talk with the remote target anymore.
The regression isn't seen when testing with
--target_board=native-gdbserver, because that does "set sysroot" to
disable the "target:" sysroot, for test run speed reasons. So this
commit adds a testcase that explicitly tests detach with "set sysroot
target:".
gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <pedro@palves.net>
PR gdb/28080
* remote.c (remote_unpush_target): Invalidate file I/O target
handles.
* target.c (fileio_handles_invalidate_target): Make extern.
* target.h (fileio_handles_invalidate_target): Declare.
gdb/testsuite/ChangeLog:
yyyy-mm-dd Pedro Alves <pedro@palves.net>
PR gdb/28080
* gdb.base/detach-sysroot-target.exp: New.
* gdb.base/detach-sysroot-target.c: New.
Reported-By: Jonah Graham <jonah@kichwacoders.com>
Change-Id: I851234910172f42a1b30e731161376c344d2727d
When running test-case gdb.threads/check-libthread-db.exp on openSUSE
Tumbleweed with glibc 2.33, I get:
...
(gdb) maint check libthread-db^M
Running libthread_db integrity checks:^M
Got thread 0x7ffff7c79b80 => 9354 => 0x7ffff7c79b80; errno = 0 ... OK^M
libthread_db integrity checks passed.^M
(gdb) FAIL: gdb.threads/check-libthread-db.exp: user-initiated check: \
libpthread.so not initialized (pattern 2)
...
The test-case expects instead:
...
Got thread 0x0 => 9354 => 0x0 ... OK^M
...
which is what I get on openSUSE Leap 15.2 with glibc 2.26, and what is
described in the test-case like this:
...
# libthread_db should fake a single thread with th_unique == NULL.
...
Using a breakpoint on check_thread_db_callback we can compare the two
scenarios, and find that in the latter case we hit this code in glibc function
iterate_thread_list in nptl_db/td_ta_thr_iter.c:
...
if (next == 0 && fake_empty)
{
/* __pthread_initialize_minimal has not run. There is just the main
thread to return. We cannot rely on its thread register. They
sometimes contain garbage that would confuse us, left by the
kernel at exec. So if it looks like initialization is incomplete,
we only fake a special descriptor for the initial thread. */
td_thrhandle_t th = { ta, 0 };
return callback (&th, cbdata_p) != 0 ? TD_DBERR : TD_OK;
}
...
while in the former case we don't because this preceding statement doesn't
result in next == 0:
...
err = DB_GET_FIELD (next, ta, head, list_t, next, 0);
...
Note that the comment mentions __pthread_initialize_minimal, but in both cases
it has already run before we hit the callback, so it's possible the comment is
no longer accurate.
The change in behaviour bisect to glibc commit 1daccf403b "nptl: Move stack
list variables into _rtld_global", which moves the initialization of stack
list variables such as __stack_user to an earlier moment, which explains well
enough the observed difference.
Fix this by updating the regexp patterns to agree with what libthread-db is
telling us.
Tested on x86_64-linux, both with glibc 2.33 and 2.26.
gdb/testsuite/ChangeLog:
2021-07-13 Tom de Vries <tdevries@suse.de>
PR testsuite/27690
* gdb.threads/check-libthread-db.exp: Update patterns for glibc 2.33.
As reported in PR gdb/28077, we hit an internal error when using
-exec-interrupt with --thread-group:
info threads
&"info threads\n"
~" Id Target Id Frame \n"
~"* 1 process 403312 \"loop\" (running)\n"
^done
(gdb)
-exec-interrupt --thread-group i1
~"/home/simark/src/binutils-gdb/gdb/target.c:3768: internal-error: void target_stop(ptid_t): Assertion `!proc_target->commit_resumed_state' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? (y or n) "
This is because this code path never disables commit-resumed (a
requirement for calling target_stop, as documented in
process_stratum_target::»commit_resumed_state) before calling
target_stop.
The other 3 code paths in mi_cmd_exec_interrupt use interrupt_target_1,
which does it. But the --thread-group code path uses its own thing
which doesn't do it. Fix this by adding a scoped_disable_commit_resumed
in this code path.
Calling -exec-interrupt with --thread-group is apparently not tested at
the moment (which is why this bug could creep in). Add a new test for
that. The test runs two inferiors and tries to interrupt them with
"-exec-interrupt --thread-group X".
This will need to be merged in the gdb-11-branch, so here are ChangeLog
entries:
gdb/ChangeLog:
* mi/mi-main.c (mi_cmd_exec_interrupt): Use
scoped_disable_commit_resumed in the --thread-group case.
gdb/testsuite/ChangeLog:
* gdb.mi/interrupt-thread-group.c: New.
* gdb.mi/interrupt-thread-group.exp: New.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28077
Change-Id: I615efefcbcaf2c15d47caf5e4b9d82854b2a2fcb
These files were renamed in 1b71cfcfdc,
but evidentially a few dangling references were left behind. This causes
builds to fail:
$ ./configure --target i686-netbsdelf
$ make
make: *** No rule to make target 'nbsd-tdep.c', needed by 'nbsd-tdep.o'. Stop.
gdb/ChangeLog:
* sparc-tdep.h: Fix comment.
* netbsd-tdep.c (nbsd_info_proc_mappings_header): Fix comment.
(nbsd_init_abi): Fix comment.
* configure.tgt (*-*-netbsd* | *-*-knetbsd*-gnu): Fix netbsd
file name.
(alpha*-*-openbsd*): Likewise.
(sparc-*-openbsd*): Likewise.
(sparc64-*-openbsd*): Likewise.
Change-Id: I18a0873902dccadd238615577aac4e08772fa2c8
Recently I started to see this fail with trunk:
...
(gdb) record instruction-history^M
1 0x00000000004004ab <main+4>: call 0x4004b7 <test>^M
2 0x00000000004004c6 <test+15>: mov $0x1,%eax^M
3 0x00000000004004cb <test+20>: ret ^M
(gdb) FAIL: gdb.btrace/tsx.exp: speculation indication
...
This is due to an intel microcode update (1) that disables Intel TSX by default.
Fix this by updating the pattern.
Tested on x86_64-linux, with both gcc 7.5.0 and clang 12.0.1.
[1] https://www.intel.com/content/www/us/en/support/articles/000059422/processors.html
gdb/testsuite/ChangeLog:
2021-07-12 Tom de Vries <tdevries@suse.de>
PR testsuite/28057
* gdb.btrace/tsx.exp: Add pattern for system with tsx disabled in
microcode.
When running test-case gdb.mi/mi-info-sources.exp, I run into:
...
Running src/gdb/testsuite/gdb.mi/mi-info-sources.exp ...
ERROR: internal buffer is full.
...
due to extra debug info from the shared libraries.
Fix this by using "nosharedlibrary".
Then I run into these FAILs:
...
FAIL: gdb.mi/mi-info-sources.exp: debug_read=false: \
-file-list-exec-source-files (unexpected output)
FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \
-file-list-exec-source-files (unexpected output)
FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \
-file-list-exec-source-files --group-by-objfile, look for \
mi-info-sources.c (unexpected output)
FAIL: gdb.mi/mi-info-sources.exp: debug_read=true: \
-file-list-exec-source-files --group-by-objfile, look for \
mi-info-sources-base.c (unexpected output)
...
due to openSUSE executables which have debug info for objects from sources
like sysdeps/x86_64/crtn.S.
Fix these by updating the patterns, and adding "maint expand-symtabs" to
reliably get fully-read objfiles.
Then I run into FAILs when using the readnow target board. Fix these by
skipping the relevant tests.
Then I run into FAILs when using the cc-with-gnu-debuglink board. Fix these
by updating the patterns.
Tested on x86_64-linux, with native, check-read1, readnow, cc-with-gdb-index,
cc-with-debug-names, cc-with-gnu-debuglink, cc-with-dwz, cc-with-dwz-m.
gdb/testsuite/ChangeLog:
2021-07-12 Tom de Vries <tdevries@suse.de>
* lib/mi-support.exp (mi_readnow): New proc.
* gdb.mi/mi-info-sources.exp: Use nosharedlibrary. Update patterns.
Skip tests for readnow. Use "maint expand-symtabs".
The compiler gives this warning when building symtab.c:
../../binutils-gdb/gdb/symtab.c:4247:28: warning: 'to_match' may be used uninitialized in this function [-Wmaybe-uninitialized]
This patch fixes the warning by adding a gdb_assert_not_reached.
gdb/ChangeLog:
* gdb/symtab.c (info_sources_filter::matches): Add default
case hander in switch statement.
(cherry picked from commit b6aeb717a8)
According to bug 28056, running an s390x binary gives:
(gdb) run
Starting program: /usr/bin/ls
/home/ubuntu/tmp/gdb-11.0.90.20210705/gdb/linux-tdep.c:2550: internal-error: displaced_step_prepare_status linux_displaced_step_prepare(gdbarch*, thread_info*, CORE_ADDR&): Assertion `gdbarch_data->num_disp_step_buffers > 0' failed.
This is because the s390 architecture registers some Linux-specific
displaced stepping callbacks in the OS-agnostic s390_gdbarch_init:
set_gdbarch_displaced_step_prepare (gdbarch, linux_displaced_step_prepare);
set_gdbarch_displaced_step_finish (gdbarch, linux_displaced_step_finish);
set_gdbarch_displaced_step_restore_all_in_ptid
(gdbarch, linux_displaced_step_restore_all_in_ptid);
But then the Linux-specific s390_linux_init_abi_any passes
num_disp_step_buffers=0 to linux_init_abi:
linux_init_abi (info, gdbarch, 0);
The problem happens when linux_displaced_step_prepare is called for the
first time. It tries to allocate the displaced stepping buffers, but
sees that the number of displaced stepping buffers for that architecture
is 0, which is unexpected / invalid.
s390_gdbarch_init should not register the linux_* callbacks, that is
expected to be done by linux_init_abi. If debugging a bare-metal s390
program, or an s390 program on another OS GDB doesn't know about, we
wouldn't want to use them. We would either register no callbacks, if
displaced stepping isn't supported, or register a different set of
callbacks if we wanted to support displaced stepping in those cases.
The commit that refactored the displaced stepping machinery and
introduced these set_gdbarch_displaced_step_* calls is 187b041e25
("gdb: move displaced stepping logic to gdbarch, allow starting
concurrent displaced steps"). However, even before that,
s390_gdbarch_init did:
set_gdbarch_displaced_step_location (gdbarch, linux_displaced_step_location);
... which already seemed wrong. The Linux-specific callback was used
even for non-Linux system. Maybe that was on purpose, because it would
also happen to work in some other non-Linux case, or maybe it was simply
a mistake. I'll assume that this was a small mistake when
s390-tdep.{h,c} where factored out of s390-linux-tdep.c, in d6e5894564
("s390: Split up s390-linux-tdep.c into two files").
Fix this by removing the setting of these displaced step callbacks from
s390_gdbarch_init. Instead, pass num_disp_step_buffers=1 to
linux_init_abi, in s390_linux_init_abi_any. Doing so will cause
linux_init_abi to register these same callbacks. It will also mean that
when debugging a bare-metal s390 executable or an executable on another
OS that GDB doesn't know about, gdbarch_displaced_step_prepare won't be
set, so displaced stepping won't be used.
This patch will need to be merged in the gdb-11-branch, since this is a
GDB 11 regression, so here's the ChangeLog entry:
gdb/ChangeLog:
* s390-linux-tdep.c (s390_linux_init_abi_any): Pass 1 (number
of displaced stepping buffers to linux_init_abi.
* s390-tdep.c (s390_gdbarch_init): Don't set the Linux-specific
displaced-stepping gdbarch callbacks.
Change-Id: Ieab2f8990c78fde845ce7378d6fd4ee2833800d5
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28056
When distclean-ing a configured / built gdb directory, like so:
$ ./configure && make all-gdb && make distclean
The distclean operation fails with:
Missing testsuite/Makefile
If we look at the SUBDIRS variable in the generated gdb/Makefile,
testsuite is there twice:
SUBDIRS = doc testsuite data-directory testsuite
So we try distclean-ing the testsuite directory twice. The second time,
gdb/testsuite/Makefile doesn't exist, so it fails.
The first "testsuite" comes from the @subdirs@ replacement, because of
the `AC_CONFIG_SUBDIRS` macro in gdb/configure.ac. The second one is
hard-coded in gdb/Makefile.in:
SUBDIRS = doc @subdirs@ data-directory testsuite
The hard-coded was added by:
bdbbcd5774 ("Always build 'all' in gdb/testsuite")
which came after `testsuite` was removed from @subdirs@ by:
f99d1d3749 ("Remove gdb/testsuite/configure")
My commit a100a94530 ("gdb/testsuite: restore configure script")
should have removed the hard-coded `testsuite`, since it added it back
as a "subdir", but I missed it because I only looked f99d1d3749 to
write my patch.
Fix this by removing the hard-coded one.
This patch should be pushed to both master and gdb-11-branch, hence the
ChangeLog entry:
gdb/ChangeLog:
* Makefile.in (SUBDIRS): Remove testsuite.
Change-Id: I63e5590b1a08673c646510b3ecc74600eae9f92d
When running test-case gdb.guile/scm-breakpoint.exp on openSUSE Tumbleweed
with guile 3.0, I run into:
...
(gdb) guile (define cp (make-breakpoint "syscall" #:type BP_CATCHPOINT))^M
ERROR: In procedure make-breakpoint:^M
In procedure gdbscm_make_breakpoint: unsupported breakpoint type in \
position 3: "BP_CATCHPOINT"^M
Error while executing Scheme code.^M
(gdb) FAIL: gdb.guile/scm-breakpoint.exp: test_catchpoints: \
create a catchpoint via the api
...
The same test passes on openSUSE Leap 15.2 with guile 2.0, where the second
line of the error message starts with the same prefix as the first:
...
ERROR: In procedure gdbscm_make_breakpoint: unsupported breakpoint type in \
position 3: "BP_CATCHPOINT"^M
...
I observe the same difference in many other tests, f.i.:
...
(gdb) gu (print (value-add i '()))^M
ERROR: In procedure value-add:^M
In procedure gdbscm_value_add: Wrong type argument in position 2: ()^M
Error while executing Scheme code.^M
(gdb) PASS: gdb.guile/scm-math.exp: catch error in guile type conversion
...
but it doesn't cause FAILs anywhere else.
Fix this by updating the regexp to make the "ERROR: " prefix optional.
Tested on x86_64-linux, with both guile 2.0 and 3.0.
gdb/testsuite/ChangeLog:
2021-07-08 Tom de Vries <tdevries@suse.de>
* gdb.guile/scm-breakpoint.exp: Make additional "ERROR: " prefix in
exception printing optional.
Commit f99d1d3749 ("Remove gdb/testsuite/configure") removed
gdb/testsuite/configure, as anything gdb/testsuite/configure did could
be done by gdb/configure.
There is however one use case that popped up when this changed
propagated to downstream consumers, to run the testsuite on an already
built GDB. In the workflow of ROCm-GDB at AMD, a GDB package is built
in a CI job. This GDB package is then tested on different machines /
hardware configurations as part of other CI jobs. To achieve this,
those CI jobs only configure the testsuite directory and run "make
check" with an appropriate board file.
In light of this use case, the way I see it is that gdb/testsuite could
be considered its own project. It could be stored in a completely
different repo if we want to, it just happens to be stored inside gdb/.
Since the only downside of having gdb/testsuite/configure is that it
takes a few more seconds to run, but on the other hand it's quite useful
for some people, I propose re-adding it.
In a sense, this is revert of f99d1d3749, but it's not a direct
git-revert, as some things have changed since.
gdb/ChangeLog:
* configure.ac: Remove things that were moved from
testsuite/configure.ac.
* configure: Re-generate.
gdb/testsuite/ChangeLog:
* configure.ac: Restore.
* configure: Re-generate.
* aclocal.m4: Re-generate.
* Makefile.in (distclean): Add config.status.
(Makefile): Adjust paths.
(lib/pdtrace): Adjust paths.
(config.status): Add.
Change-Id: Ic38c79485e1835712d9c99649c9dfb59667254f1
Since commit 05b8577206 "gdb/fortran: Add type info of formal parameter for
clang" I see:
...
(gdb) ptype say_string^M
type = void (character*(*), integer(kind=4))^M
(gdb) FAIL: gdb.fortran/ptype-on-functions.exp: ptype say_string
...
The part of the commit causing the fail is:
...
gdb_test "ptype say_string" \
- "type = void \\(character\\*\\(\\*\\), integer\\(kind=\\d+\\)\\)"
+ "type = void \\(character\[^,\]+, $integer8\\)"
...
which fails to take into account that for gcc-7 and before, the type for
string length of a string argument is int, not size_t.
Fix this by allowing both $integer8 and $integer4.
Tested on x86_64-linux, with gcc-7 and gcc-10.
gdb/testsuite/ChangeLog:
2021-07-06 Tom de Vries <tdevries@suse.de>
* gdb.fortran/ptype-on-functions.exp: Allow both $integer8 and
$integer4 for size of string length.
The macOS platform does not provide sigtimedwait, so we get:
CXX compile/compile.o
In file included from /Users/smarchi/src/binutils-gdb/gdb/compile/compile.c:46:
/Users/smarchi/src/binutils-gdb/gdb/../gdbsupport/scoped_ignore_signal.h:69:4: error: use of undeclared identifier 'sigtimedwait'
sigtimedwait (&set, nullptr, &zero_timeout);
^
An alternative to sigtimedwait with a timeout of 0 is to use sigpending,
to first check which signals are pending, and then sigwait, to consume
them. Since that's slightly more expensive (2 syscalls instead of 1),
keep using sigtimedwait for the platforms that provide it, and fall back
to sigpending + sigwait for the others.
gdbsupport/ChangeLog:
* scoped_ignore_signal.h (struct scoped_ignore_signal)
<~scoped_ignore_signal>: Use sigtimedwait if HAVE_SIGTIMEDWAIT
is defined, else use sigpending + sigwait.
Change-Id: I2a72798337e81dd1bbd21214736a139dd350af87
Co-Authored-By: John Baldwin <jhb@FreeBSD.org>
The next patch will make the use of sigtimedwait conditional to whether
the platform provides it. Start by adding a configure check for it.
gdbsupport/ChangeLog:
* common.m4 (GDB_AC_COMMON): Check for sigtimedwait.
* config.in, configure: Re-generate.
gdb/ChangeLog:
* config.in, configure: Re-generate.
gdbserver/ChangeLog:
* config.in, configure: Re-generate.
Change-Id: Ic7613fe14521b966b4d991bbcd0933ab14629c05
When loading a file using the file command on macOS, we get:
$ ./gdb -nx --data-directory=data-directory -q -ex "file ./test"
Reading symbols from ./test...
Reading symbols from /Users/smarchi/build/binutils-gdb/gdb/test.dSYM/Contents/Resources/DWARF/test...
/Users/smarchi/src/binutils-gdb/gdb/thread.c:72: internal-error: struct thread_info *inferior_thread(): Assertion `current_thread_ != nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
The backtrace is:
* frame #0: 0x0000000101fcb826 gdb`internal_error(file="/Users/smarchi/src/binutils-gdb/gdb/thread.c", line=72, fmt="%s: Assertion `%s' failed.") at errors.cc:52:3
frame #1: 0x00000001018a2584 gdb`inferior_thread() at thread.c:72:3
frame #2: 0x0000000101469c09 gdb`get_current_regcache() at regcache.c:421:31
frame #3: 0x00000001015f9812 gdb`darwin_solib_get_all_image_info_addr_at_init(info=0x0000603000006d00) at solib-darwin.c:464:34
frame #4: 0x00000001015f7a04 gdb`darwin_solib_create_inferior_hook(from_tty=1) at solib-darwin.c:515:5
frame #5: 0x000000010161205e gdb`solib_create_inferior_hook(from_tty=1) at solib.c:1200:3
frame #6: 0x00000001016d8f76 gdb`symbol_file_command(args="./test", from_tty=1) at symfile.c:1650:7
frame #7: 0x0000000100abab17 gdb`file_command(arg="./test", from_tty=1) at exec.c:555:3
frame #8: 0x00000001004dc799 gdb`do_const_cfunc(c=0x000061100000c340, args="./test", from_tty=1) at cli-decode.c:102:3
frame #9: 0x00000001004ea042 gdb`cmd_func(cmd=0x000061100000c340, args="./test", from_tty=1) at cli-decode.c:2160:7
frame #10: 0x00000001018d4f59 gdb`execute_command(p="t", from_tty=1) at top.c:674:2
frame #11: 0x0000000100eee430 gdb`catch_command_errors(command=(gdb`execute_command(char const*, int) at top.c:561), arg="file ./test", from_tty=1, do_bp_actions=true)(char const*, int), char const*, int, bool) at main.c:523:7
frame #12: 0x0000000100eee902 gdb`execute_cmdargs(cmdarg_vec=0x00007ffeefbfeba0 size=1, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x00007ffeefbfec20) at main.c:618:9
frame #13: 0x0000000100eed3a4 gdb`captured_main_1(context=0x00007ffeefbff780) at main.c:1322:3
frame #14: 0x0000000100ee810d gdb`captured_main(data=0x00007ffeefbff780) at main.c:1343:3
frame #15: 0x0000000100ee8025 gdb`gdb_main(args=0x00007ffeefbff780) at main.c:1368:7
frame #16: 0x00000001000044f1 gdb`main(argc=6, argv=0x00007ffeefbff8a0) at gdb.c:32:10
frame #17: 0x00007fff20558f5d libdyld.dylib`start + 1
The solib_create_inferior_hook call in symbol_file_command was added by
commit ea142fbfc9 ("Fix breakpoints on file reloads for PIE
binaries"). It causes solib_create_inferior_hook to be called while
the inferior is not running, which darwin_solib_create_inferior_hook
does not expect. darwin_solib_get_all_image_info_addr_at_init, in
particular, assumes that there is a current thread, as it tries to get
the current thread's regcache.
Fix it by adding a target_has_execution check and returning early. Note
that there is a similar check in svr4_solib_create_inferior_hook.
gdb/ChangeLog:
* solib-darwin.c (darwin_solib_create_inferior_hook): Return
early if no execution.
Change-Id: Ia11dd983a1e29786e5ce663d0fcaa6846dc611bb
Now that the GDB 11 branch has been created, we can
bump the version number.
gdb/ChangeLog:
GDB 11 branch created (4b51505e33):
* version.in: Bump version to 11.0.90.DATE-git.
