summaryrefslogtreecommitdiff
path: root/gdb
Commit message (Collapse)AuthorAgeFilesLines
* [gdb/procfs.c] Fix build failure in find_stop_signalLibor Bukata2021-07-141-2/+2
| | | | | | | | | | | | | | | | | It fixes a regression caused by commit 1edb66d856c82c389edfd7610143236a68c76846 where thread_info::suspend was made private. The public thread_info API has to be used to get stop signal and avoid build failures. gdb/ChangeLog: 2021-07-14 Libor Bukata <libor.bukata@oracle.com> * gdb/procfs.c (find_stop_signal): Use thread_info API. Change-Id: I53bc57a05cd0eca5f28ef0726d6faeeb306e7904
* [gdb/testsuite] Fix gdb.base/gold-gdb-index.expTom de Vries2021-07-142-1/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* [gdb/testsuite] Add missing skip_tui_testsTom de Vries2021-07-143-12/+31
| | | | | | | | | | | | | | | | | | | | | | | | When building gdb with --disable-tui, we run into: ... (gdb) frame apply all -- -^M Undefined command: "-". Try "help".^M (gdb) ERROR: Undefined command "frame apply all -- -". UNRESOLVED: gdb.base/options.exp: test-frame-apply: frame apply all -- - ... Fix this by detecting whether tui is supported, and skipping the tui-related tests otherwise. Same in some gdb.tui test-cases. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-07-13 Tom de Vries <tdevries@suse.de> * gdb.base/options.exp: Skip tui-related tests when tui is not supported. * gdb.python/tui-window-disabled.exp: Same. * gdb.python/tui-window.exp: Same.
* Use /bin/sh as shebang in gdb/make-init-cLancelot SIX2021-07-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* arm-fbsd-nat: Use fetch_register_set and store_register_set.John Baldwin2021-07-131-73/+8
|
* aarch64-fbsd-nat: Use fetch_register_set and store_register_set.John Baldwin2021-07-131-69/+8
|
* riscv-fbsd-nat: Use fetch_register_set and store_register_set.John Baldwin2021-07-131-70/+8
|
* fbsd-nat: Add helper functions to fetch and store register sets.John Baldwin2021-07-132-0/+89
| | | | | | | In particular, this supports register sets described by a regcache_map which are fetched and stored with dedicated ptrace operations. These functions are intended to be used in architecture-specific fetch_registers and store_registers target methods.
* Add regcache_map_supplies helper routine.John Baldwin2021-07-132-0/+36
| | | | | | This helper can be used in the fetch_registers and store_registers target methods to determine if a register set includes a specific register.
* Avoid letting exceptions escape gdb_bfd_iovec_fileio_close (PR gdb/28080)Pedro Alves2021-07-131-3/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix detach with target remote (PR gdb/28080)Pedro Alves2021-07-135-6/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 408f66864a1a823591b26420410c982174c239a2 ("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 408f66864a1a823591b26420410c982174c239a2 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
* [gdb/testsuite] Fix check-libthread-db.exp FAILs with glibc 2.33Tom de Vries2021-07-131-16/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-07 Tom de Vries <tdevries@suse.de> PR testsuite/27690 * gdb.threads/check-libthread-db.exp: Update patterns for glibc 2.33.
* gdb, dwarf: Don't follow the parent of a subprogram to get a prefix.Felix Willgerodt2021-07-133-1/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During prefix resolution, if the parent is a subprogram, there is no need to go to the parent of the subprogram. The DIE will be local. For a program like: ~~~ class F1 { public: int a; int vvv () { class F2 { int f; }; F2 abcd; return 1; } }; ~~~ The class F2 should not be seen as a member of F1. Before: ~~~ (gdb) ptype abcd type = class F1::F2 { private: int f; } ~~~ After: ~~~ (gdb) ptype abcd type = class F2 { private: int f; } ~~~ gdb/ChangeLog: 2021-06-23 Felix Willgerodt <felix.willgerodt@intel.com> * dwarf2/read.c (determine_prefix): Return an empty prefix if the parent is a subprogram. gdb/testsuite/ChangeLog: 2021-06-23 Felix Willgerodt <felix.willgerodt@intel.com> * gdb.cp/nested-class-func-class.cc: New file. * gdb.cp/nested-class-func-class.exp: New file.
* gdb: disable commit-resumed on -exec-interrupt --thread-groupSimon Marchi2021-07-133-0/+198
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix some dangling references to `netbsd-tdep`John Ericson2021-07-133-7/+7
| | | | | | | | | | These files were renamed in 1b71cfcfdc3e13a655fefa6566b5564cec044c10, 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: optimize all_matching_threads_iteratorSimon Marchi2021-07-122-60/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | all_matching_threads_iterator is used extensively in some pretty fast paths, often under the all_non_exited_threads function. If a filter target and thread-specific ptid are given, it iterates on all threads of all inferiors of that target, to ultimately yield exactly on thread. And this happens quite often, which means we unnecessarily spend time iterating on threads to find the one we are looking for. The same thing happens if an inferior-specific ptid is given, although there the iterator yields all the threads of that inferior. In those cases, the callers of all_non_exited_threads could have different behaviors depending on the kind of ptid, to avoid this inefficiency, but that would be very tedious. Using all_non_exited_threads has the advantage that one simple implementation can work seamlessly on multiple threads or on one specific thread, just by playing with the ptid. Instead, optimize all_matching_threads_iterator directly to detect these different cases and limiting what we iterate on to just what we need. - if filter_ptid is minus_one_ptid, do as we do now: filter inferiors based on filter_target, iterate on all of the matching inferiors' threads - if filter_ptid is a pid-only ptid (then a filter_target must necessarily be given), look up that inferior and iterate on all its threads - otherwise, filter_ptid is a thread-specific ptid, so look up that specific thread and "iterate" only on it For the last case, what was an iteration on all threads of the filter target now becomes a call to find_thread_ptid, which is quite efficient now thanks to inferior::ptid_thread_map. gdb/ChangeLog: * thread-iter.h (class all_matching_threads_iterator) <all_matching_threads_iterator>: Use default. <enum class mode>: New. <m_inf, m_thr>: Initialize. <m_filter_ptid>: Remove. * thread-iter.c (all_matching_threads_iterator::m_inf_matches): Don't filter on m_filter_ptid. (all_matching_threads_iterator::all_matching_threads_iterator): Choose path based on filter_ptid (all threads, all threads of inferior, single thread). (all_matching_threads_iterator::advance): Likewise. Change-Id: Ic6a19845f5f760fa1b8eac8145793c0ff431bbc9
* gdb: maintain ptid -> thread map, optimize find_thread_ptidSimon Marchi2021-07-126-5/+47
| | | | | | | | | | | | | | When debugging a large number of threads (thousands), looking up a thread by ptid_t using the inferior::thread_list linked list can add up. Add inferior::thread_map, an std::unordered_map indexed by ptid_t, and change the find_thread_ptid function to look up a thread using std::unordered_map::find, instead of iterating on all of the inferior's threads. This should make it faster to look up a thread from its ptid. Change-Id: I3a8da0a839e18dee5bb98b8b7dbeb7f3dfa8ae1c Co-Authored-By: Pedro Alves <pedro@palves.net>
* gdb: optimize selection of resumed thread with pending eventSimon Marchi2021-07-123-29/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider a case where many threads (thousands) keep hitting a breakpoint whose condition evaluates to false. random_pending_event_thread is responsible for selecting a thread from an inferior among all that are resumed with a pending wait status. It is currently implemented by walking the inferior's thread list twice: once to count the number of candidates and once to select a random one. Since we now maintain a per target list of resumed threads with pending event, we can implement this more efficiently by walking that list and selecting the first thread that matches the criteria (random_pending_event_thread looks for an thread from a specific inferior, and possibly a filter ptid). It will be faster especially in the common case where there isn't any resumed thread with pending event. Currently, we have to iterate the thread list to figure this out. With this patch, the list of resumed threads with pending event will be empty, so it's quick to figure out. The random selection is kept, but is moved to process_stratum_target::random_resumed_with_pending_wait_status. The same technique is used: do a first pass to count the number of candidates, and do a second pass to select a random one. But given that the list of resumed threads with pending wait statuses will generally be short, or at least shorter than the full thread list, it should be quicker. Note that this isn't completely true, in case there are multiple inferiors on the same target. Imagine that inferior A has 10k resumed threads with pending wait statuses, and random_pending_event_thread is called with inferior B. We'll need to go through the list that contains inferior A's threads to realize that inferior B has no resumed threads with pending wait status. But I think that this is a corner / pathological case. And a possible fix for this situation would be to make random_pending_event_thread work per-process-target, rather than per-inferior. Change-Id: I1b71d01beaa500a148b5b9797745103e13917325
* gdb: optimize check for resumed threads with pending wait status in ā†µSimon Marchi2021-07-122-9/+6
| | | | | | | | | | | | | | | | | | | | | | | maybe_set_commit_resumed_all_targets Consider a test case where many threads (thousands) keep hitting a breakpoint whose condition evaluates to false. maybe_set_commit_resumed_all_targets is called at each handled event, when the scoped_disable_commit_resumed object in fetch_inferior_event is reset_and_commit-ed. One particularly expensive check in there is whether the target has at least one resumed thread with a pending wait status (in which case, we don't want to commit the resumed threads, as we want to consume this status first). It is currently implemented as walking all threads of the target. Since we now maintain a per-target list of resumed threads with pending status, we can do this check efficiently, by checking whether that list is empty or not. Add the process_stratum_target::has_resumed_with_pending_wait_status method for this, and use it in maybe_set_commit_resumed_all_targets. Change-Id: Ia1595baa1b358338f94fc3cb3af7f27092dad5b6
* gdb: maintain per-process-target list of resumed threads with pending wait ā†µSimon Marchi2021-07-126-4/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | status Looking up threads that are both resumed and have a pending wait status to report is something that we do quite often in the fast path and is expensive if there are many threads, since it currently requires walking whole thread lists. The first instance is in maybe_set_commit_resumed_all_targets. This is called after handling each event in fetch_inferior_event, to see if we should ask targets to commit their resumed threads or not. If at least one thread is resumed but has a pending wait status, we don't ask the targets to commit their resumed threads, because we want to consume and handle the pending wait status first. The second instance is in random_pending_event_thread, where we want to select a random thread among all those that are resumed and have a pending wait status. This is called every time we try to consume events, to see if there are any pending events that we we want to consume, before asking the targets for more events. To allow optimizing these cases, maintain a per-process-target list of threads that are resumed and have a pending wait status. In maybe_set_commit_resumed_all_targets, we'll be able to check in O(1) if there are any such threads simply by checking whether the list is empty. In random_pending_event_thread, we'll be able to use that list, which will be quicker than iterating the list of threads, especially when there are no resumed with pending wait status threads. About implementation details: using the new setters on class thread_info, it's relatively easy to maintain that list. Any time the "resumed" or "pending wait status" property is changed, we check whether that should cause the thread to be added or removed from the list. In set_thread_exited, we try to remove the thread from the list, because keeping an exited thread in that list would make no sense (especially if the thread is freed). My first implementation assumed that a process stratum target was always present when set_thread_exited is called. That's however, not the case: in some cases, targets unpush themselves from an inferior and then call "exit_inferior", which exits all the threads. If the target is unpushed before set_thread_exited is called on the threads, it means we could mistakenly leave some threads in the list. I tried to see how hard it would be to make it such that targets have to exit all threads before unpushing themselves from the inferior (that would seem logical to me, we don't want threads belonging to an inferior that has no process target). That seemed quite difficult and not worth the time at the moment. Instead, I changed inferior::unpush_target to remove all threads of that inferior from the list. As of this patch, the list is not used, this is done in the subsequent patches. The debug messages in process-stratum-target.c need to print some ptids. However, they can't use target_pid_to_str to print them without introducing a dependency on the current inferior (the current inferior is used to get the current target stack). For debug messages, I find it clearer to print the spelled out ptid anyway (the pid, lwp and tid values). Add a ptid_t::to_string method that returns a string representation of the ptid that is meant for debug messages, a bit like we already have frame_id::to_string. Change-Id: Iad8f93db2d13984dd5aa5867db940ed1169dbb67
* gdb: make thread_info::suspend private, add getters / settersSimon Marchi2021-07-1216-240/+332
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A following patch will want to take some action when a pending wait status is set on or removed from a thread. Add a getter and a setter on thread_info for the pending waitstatus, so that we can add some code in the setter later. The thing is, the pending wait status field is in the thread_suspend_state, along with other fields that we need to backup before and restore after the thread does an inferior function call. Therefore, make the thread_suspend_state member private (thread_info::suspend becomes thread_info::m_suspend), and add getters / setters for all of its fields: - pending wait status - stop signal - stop reason - stop pc For the pending wait status, add the additional has_pending_waitstatus and clear_pending_waitstatus methods. I think this makes the thread_info interface a bit nicer, because we now access the fields as: thread->stop_pc () rather than thread->suspend.stop_pc The stop_pc field being in the `suspend` structure is an implementation detail of thread_info that callers don't need to be aware of. For the backup / restore of the thread_suspend_state structure, add save_suspend_to and restore_suspend_from methods. You might wonder why `save_suspend_to`, as opposed to a simple getter like thread_suspend_state &suspend (); I want to make it clear that this is to be used only for backing up and restoring the suspend state, _not_ to access fields like: thread->suspend ()->stop_pc Adding some getters / setters allows adding some assertions. I find that this helps understand how things are supposed to work. Add: - When getting the pending status (pending_waitstatus method), ensure that there is a pending status. - When setting a pending status (set_pending_waitstatus method), ensure there is no pending status. There is one case I found where this wasn't true - in remote_target::process_initial_stop_replies - which needed adjustments to respect that contract. I think it's because process_initial_stop_replies is kind of (ab)using the thread_info::suspend::waitstatus to store some statuses temporarily, for its internal use (statuses it doesn't intent on leaving pending). process_initial_stop_replies pulls out stop replies received during the initial connection using target_wait. It always stores the received event in `evthread->suspend.waitstatus`. But it only sets waitstatus_pending_p, if it deems the event interesting enough to leave pending, to be reported to the core: if (ws.kind != TARGET_WAITKIND_STOPPED || ws.value.sig != GDB_SIGNAL_0) evthread->suspend.waitstatus_pending_p = 1; It later uses this flag a bit below, to choose which thread to make the "selected" one: if (selected == NULL && thread->suspend.waitstatus_pending_p) selected = thread; And ultimately that's used if the user-visible mode is all-stop, so that we print the stop for that interesting thread: /* In all-stop, we only print the status of one thread, and leave others with their status pending. */ if (!non_stop) { thread_info *thread = selected; if (thread == NULL) thread = lowest_stopped; if (thread == NULL) thread = first; print_one_stopped_thread (thread); } But in any case (all-stop or non-stop), print_one_stopped_thread needs to access the waitstatus value of these threads that don't have a pending waitstatus (those that had TARGET_WAITKIND_STOPPED + GDB_SIGNAL_0). This doesn't work with the assertions I've put. So, change the code to only set the thread's wait status if it is an interesting one that we are going to leave pending. If the thread stopped due to a non-interesting event (TARGET_WAITKIND_STOPPED + GDB_SIGNAL_0), don't store it. Adjust print_one_stopped_thread to understand that if a thread has no pending waitstatus, it's because it stopped with TARGET_WAITKIND_STOPPED + GDB_SIGNAL_0. The call to set_last_target_status also uses the pending waitstatus. However, given that the pending waitstatus for the thread may have been cleared in print_one_stopped_thread (and that there might not even be a pending waitstatus in the first place, as explained above), it is no longer possible to do it at this point. To fix that, move the call to set_last_target_status in print_one_stopped_thread. I think this will preserve the existing behavior, because set_last_target_status is currently using the current thread's wait status. And the current thread is the last one for which print_one_stopped_thread is called. So by calling set_last_target_status in print_one_stopped_thread, we'll get the same result. set_last_target_status will possibly be called multiple times, but only the last call will matter. It just means possibly more calls to set_last_target_status, but those are cheap. Change-Id: Iedab9653238eaf8231abcf0baa20145acc8b77a7
* gdb: add setter / getter for thread_info resumed stateSimon Marchi2021-07-125-34/+40
| | | | | | | | | A following patch will want to do things when a thread's resumed state changes. Make the `resumed` field private (renamed to `m_resumed`) and add a getter and a setter for it. The following patch in question will therefore be able to add some code to the setter. Change-Id: I360c48cc55a036503174313261ce4e757d795319
* gdb: use intrusive list for step-over chainSimon Marchi2021-07-125-138/+147
| | | | | | | | | | | | | | | | | | | | | The threads that need a step-over are currently linked using an hand-written intrusive doubly-linked list, so that seems a very good candidate for intrusive_list, convert it. For this, we have a use case of appending a list to another one (in start_step_over). Based on the std::list and Boost APIs, add a splice method. However, only support splicing the other list at the end of the `this` list, since that's all we need. Add explicit default assignment operators to reference_to_pointer_iterator, which are otherwise implicitly deleted. This is needed because to define thread_step_over_list_safe_iterator, we wrap reference_to_pointer_iterator inside a basic_safe_iterator, and basic_safe_iterator needs to be able to copy-assign the wrapped iterator. The move-assignment operator is therefore not needed, only the copy-assignment operator is. But for completeness, add both. Change-Id: I31b2ff67c7b78251314646b31887ef1dfebe510c
* gdb: make inferior_list use intrusive_listPedro Alves2021-07-1210-116/+103
| | | | | | | | | | | | | | | | | | | | | | Change inferior_list, the global list of inferiors, to use intrusive_list. I think most other changes are somewhat obvious fallouts from this change. There is a small change in behavior in scoped_mock_context. Before this patch, constructing a scoped_mock_context would replace the whole inferior list with only the new mock inferior. Tests using two scoped_mock_contexts therefore needed to manually link the two inferiors together, as the second scoped_mock_context would bump the first mock inferior from the thread list. With this patch, a scoped_mock_context adds its mock inferior to the inferior list on construction, and removes it on destruction. This means that tests run with mock inferiors in the inferior list in addition to any pre-existing inferiors (there is always at least one). There is no possible pid clash problem, since each scoped mock inferior uses its own process target, and pids are per process target. Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: I7eb6a8f867d4dcf8b8cd2dcffd118f7270756018
* gdb: introduce intrusive_list, make thread_info use itPedro Alves2021-07-1210-84/+923
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GDB currently has several objects that are put in a singly linked list, by having the object's type have a "next" pointer directly. For example, struct thread_info and struct inferior. Because these are simply-linked lists, and we don't keep track of a "tail" pointer, when we want to append a new element on the list, we need to walk the whole list to find the current tail. It would be nice to get rid of that walk. Removing elements from such lists also requires a walk, to find the "previous" position relative to the element being removed. To eliminate the need for that walk, we could make those lists doubly-linked, by adding a "prev" pointer alongside "next". It would be nice to avoid the boilerplate associated with maintaining such a list manually, though. That is what the new intrusive_list type addresses. With an intrusive list, it's also possible to move items out of the list without destroying them, which is interesting in our case for example for threads, when we exit them, but can't destroy them immediately. We currently keep exited threads on the thread list, but we could change that which would simplify some things. Note that with std::list, element removal is O(N). I.e., with std::list, we need to walk the list to find the iterator pointing to the position to remove. However, we could store a list iterator inside the object as soon as we put the object in the list, to address it, because std::list iterators are not invalidated when other elements are added/removed. However, if you need to put the same object in more than one list, then std::list<object> doesn't work. You need to instead use std::list<object *>, which is less efficient for requiring extra memory allocations. For an example of an object in multiple lists, see the step_over_next/step_over_prev fields in thread_info: /* Step-over chain. A thread is in the step-over queue if these are non-NULL. If only a single thread is in the chain, then these fields point to self. */ struct thread_info *step_over_prev = NULL; struct thread_info *step_over_next = NULL; The new intrusive_list type gives us the advantages of an intrusive linked list, while avoiding the boilerplate associated with manually maintaining it. intrusive_list's API follows the standard container interface, and thus std::list's interface. It is based the API of Boost's intrusive list, here: https://www.boost.org/doc/libs/1_73_0/doc/html/boost/intrusive/list.html Our implementation is relatively simple, while Boost's is complicated and intertwined due to a lot of customization options, which our version doesn't have. The easiest way to use an intrusive_list is to make the list's element type inherit from intrusive_node. This adds a prev/next pointers to the element type. However, to support putting the same object in more than one list, intrusive_list supports putting the "node" info as a field member, so you can have more than one such nodes, one per list. As a first guinea pig, this patch makes the per-inferior thread list use intrusive_list using the base class method. Unlike Boost's implementation, ours is not a circular list. An earlier version of the patch was circular: the intrusive_list type included an intrusive_list_node "head". In this design, a node contained pointers to the previous and next nodes, not the previous and next elements. This wasn't great for when debugging GDB with GDB, as it was difficult to get from a pointer to the node to a pointer to the element. With the design proposed in this patch, nodes contain pointers to the previous and next elements, making it easy to traverse the list by hand and inspect each element. The intrusive_list object contains pointers to the first and last elements of the list. They are nullptr if the list is empty. Each element's node contains a pointer to the previous and next elements. The first element's previous pointer is nullptr and the last element's next pointer is nullptr. Therefore, if there's a single element in the list, both its previous and next pointers are nullptr. To differentiate such an element from an element that is not linked into a list, the previous and next pointers contain a special value (-1) when the node is not linked. This is necessary to be able to reliably tell if a given node is currently linked or not. A begin() iterator points to the first item in the list. An end() iterator contains nullptr. This makes iteration until end naturally work, as advancing past the last element will make the iterator contain nullptr, making it equal to the end iterator. If the list is empty, a begin() iterator will contain nullptr from the start, and therefore be immediately equal to the end. Iterating on an intrusive_list yields references to objects (e.g. `thread_info&`). The rest of GDB currently expects iterators and ranges to yield pointers (e.g. `thread_info*`). To bridge the gap, add the reference_to_pointer_iterator type. It is used to define inf_threads_iterator. Add a Python pretty-printer, to help inspecting intrusive lists when debugging GDB with GDB. Here's an example of the output: (top-gdb) p current_inferior_.m_obj.thread_list $1 = intrusive list of thread_info = {0x61700002c000, 0x617000069080, 0x617000069400, 0x61700006d680, 0x61700006eb80} It's not possible with current master, but with this patch [1] that I hope will be merged eventually, it's possible to index the list and access the pretty-printed value's children: (top-gdb) p current_inferior_.m_obj.thread_list[1] $2 = (thread_info *) 0x617000069080 (top-gdb) p current_inferior_.m_obj.thread_list[1].ptid $3 = { m_pid = 406499, m_lwp = 406503, m_tid = 0 } Even though iterating the list in C++ yields references, the Python pretty-printer yields pointers. The reason for this is that the output of printing the thread list above would be unreadable, IMO, if each thread_info object was printed in-line, since they contain so much information. I think it's more useful to print pointers, and let the user drill down as needed. [1] https://sourceware.org/pipermail/gdb-patches/2021-April/178050.html Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: I3412a14dc77f25876d742dab8f44e0ba7c7586c0
* [gdb/testsuite] Fix gdb.btrace/tsx.exp on system with tsx disabled in microcodeTom de Vries2021-07-121-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* [gdb/testsuite] Fix gdb.mi/mi-info-sources.exp for extra debug infoTom de Vries2021-07-122-22/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-05 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".
* testsuite: fix whitespace problems in gdb.mi/mi-break.expTankut Baris Aktemur2021-07-121-37/+37
| | | | | Replace leading 8-spaces with tab and remove trailing space in gdb.mi/mi-break.exp.
* Remove unused parameter in maybe_software_singlestepLancelot SIX2021-07-091-8/+7
| | | | | | | | | | | | | | While working around, I noticed that the last parameter of maybe_software_singlestep is never used. This path removes it. Built on x86_64-linux-gnu and riscv64-linux-gnu. gdb/ChangeLog: * infrun.c (maybe_software_singlestep): Remove unused PC parameter. (resume_1): Update calls to maybe_software_singlestep.
* gdb: don't set Linux-specific displaced stepping methods in s390_gdbarch_initSimon Marchi2021-07-082-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 187b041e2514 ("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 d6e589456475 ("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
* gdb/Makefile.in: remove testsuite from SUBDIRSSimon Marchi2021-07-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: bdbbcd577460 ("Always build 'all' in gdb/testsuite") which came after `testsuite` was removed from @subdirs@ by: f99d1d37496f ("Remove gdb/testsuite/configure") My commit a100a94530eb ("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 f99d1d37496f 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
* [gdb/testsuite] Fix gdb.guile/scm-breakpoint.exp with guile 3.0Tom de Vries2021-07-081-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-07 Tom de Vries <tdevries@suse.de> * gdb.guile/scm-breakpoint.exp: Make additional "ERROR: " prefix in exception printing optional.
* gdb: introduce iterator_range, remove next_adapterSimon Marchi2021-07-0614-145/+59
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I was always a bit confused by next_adapter, because it kind of mixes the element type and the iterator type. In reality, it is not much more than a class that wraps two iterators (begin and end). However, it assumes that: - you can construct the begin iterator by passing a pointer to the first element of the iterable - you can default-construct iterator to make the end iterator I think that by generalizing it a little bit, we can re-use it at more places. Rename it to "iterator_range". I think it describes a bit better: it's a range made by wrapping a begin and end iterator. Move it to its own file, since it's not related to next_iterator anymore. iterator_range has two constructors. The variadic one, where arguments are forwarded to construct the underlying begin iterator. The end iterator is constructed through default construction. This is a generalization of what we have today. There is another constructor which receives already constructed begin and end iterators, useful if the end iterator can't be obtained by default-construction. Or, if you wanted to make a range that does not end at the end of the container, you could pass any iterator as the "end". This generalization allows removing some "range" classes, like all_inferiors_range. These classes existed only to pass some arguments when constructing the begin iterator. With iterator_range, those same arguments are passed to the iterator_range constructed and then forwarded to the constructed begin iterator. There is a small functional difference in how iterator_range works compared to next_adapter. next_adapter stored the pointer it received as argument and constructeur an iterator in the `begin` method. iterator_range constructs the begin iterator and stores it as a member. Its `begin` method returns a copy of that iterator. With just iterator_range, uses of next_adapter<foo> would be replaced with: using foo_iterator = next_iterator<foo>; using foo_range = iterator_range<foo_iterator>; However, I added a `next_range` wrapper as a direct replacement for next_adapter<foo>. IMO, next_range is a slightly better name than next_adapter. The rest of the changes are applications of this new class. gdbsupport/ChangeLog: * next-iterator.h (class next_adapter): Remove. * iterator-range.h: New. gdb/ChangeLog: * breakpoint.h (bp_locations_range): Remove. (bp_location_range): New. (struct breakpoint) <locations>: Adjust type. (breakpoint_range): Use iterator_range. (tracepoint_range): Use iterator_range. * breakpoint.c (breakpoint::locations): Adjust return type. * gdb_bfd.h (gdb_bfd_section_range): Use iterator_range. * gdbthread.h (all_threads_safe): Pass argument to all_threads_safe_range. * inferior-iter.h (all_inferiors_range): Use iterator_range. (all_inferiors_safe_range): Use iterator_range. (all_non_exited_inferiors_range): Use iterator_range. * inferior.h (all_inferiors, all_non_exited_inferiors): Pass inferior_list as argument. * objfiles.h (struct objfile) <compunits_range>: Remove. <compunits>: Return compunit_symtab_range. * progspace.h (unwrapping_objfile_iterator) <unwrapping_objfile_iterator>: Take parameter by value. (unwrapping_objfile_range): Use iterator_range. (struct program_space) <objfiles_range>: Define with "using". <objfiles>: Adjust. <objfiles_safe_range>: Define with "using". <objfiles_safe>: Adjust. <solibs>: Return so_list_range, define here. * progspace.c (program_space::solibs): Remove. * psymtab.h (class psymtab_storage) <partial_symtab_iterator>: New. <partial_symtab_range>: Use iterator_range. * solist.h (so_list_range): New. * symtab.h (compunit_symtab_range): New. (symtab_range): New. (compunit_filetabs): Change to a function. * thread-iter.h (inf_threads_range, inf_non_exited_threads_range, safe_inf_threads_range, all_threads_safe_range): Use iterator_range. * top.h (ui_range): New. (all_uis): Use ui_range. Change-Id: Ib7a9d2a3547f45f01aa1c6b24536ba159db9b854
* gdb/testsuite: restore configure scriptSimon Marchi2021-07-066-121/+4957
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit f99d1d37496f ("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 f99d1d37496f, 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
* Rename gdb/ChangeLog to gdb/ChangeLog-2021Joel Brobecker2021-07-062-0/+1
| | | | | | | | | | | Now that ChangeLog entries are no longer used for GDB patches, this commit renames the file gdb/ChangeLog to gdb/ChangeLog-2021, similar to what we would do in the context of the "Start of New Year" procedure. The purpose of this change is to avoid people merging ChangeLog entries by mistake when applying existing commits that they are currently working on.
* Update gdb performance testsuite to be compatible with Python 3.8Pedro Alves2021-07-062-16/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Running "make check-perf" on a system with Python 3.8 (e.g., Ubuntu 20.04) runs into this Python problem: Traceback (most recent call last): File "<string>", line 1, in <module> File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 65, in run self.execute_test() File "<string>", line 35, in execute_test File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 45, in measure m.start(id) File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 102, in start self.start_time = time.clock() AttributeError: module 'time' has no attribute 'clock' Error while executing Python code. (gdb) FAIL: gdb.perf/single-step.exp: python SingleStep(1000).run() ... many times over. The problem is that the testsuite is using time.clock(), deprecated in Python 3.3 and finaly removed in Python 3.8. The guidelines say to use time.perf_counter() or time.process_time() instead depending on requirements. Looking at the current description of those functions, at: https://docs.python.org/3.10/library/time.html we have: time.perf_counter() -> float Return the value (in fractional seconds) of a performance counter, i.e. a clock with the highest available resolution to measure a short duration. It does include time elapsed during sleep and is system-wide. (...) time.process_time() -> float Return the value (in fractional seconds) of the sum of the system and user CPU time of the current process. It does not include time elapsed during sleep. It is process-wide by definition. (...) I'm thinking that it's just best to record both instead of picking one. So this patch replaces the MeasurementCpuTime measurement class with two new classes -- MeasurementPerfCounter and MeasurementProcessTime. Correspondingly, this changes the reports in testsuite/perftest.log -- we have two new "perf_counter" and "process_time" measurements and the "cpu_time" measurement is gone. I don't suppose breaking backward compatibility here is a big problem. I suspect no one is really tracking long term performance using the perf testsuite today. And if they are, it shouldn't be hard to adjust. For backward compatility, with Python < 3.3, both perf_counter and process_time use the old time.clock. gdb/testsuite/ChangeLog: yyyy-mm-dd Qingchuan Shi <qingchuan.shi@amd.com> Pedro Alves <pedro@palves.net> * gdb.perf/lib/perftest/perftest.py: Import sys. (time.perf_counter, time.process_time): Map to time.clock on Python < 3.3. (MeasurementCpuTime): Delete, replaced by... (MeasurementPerfCounter, MeasurementProcessTime): .. these two new classes. * gdb.perf/lib/perftest/perftest.py: Import MeasurementPerfCounter and MeasurementProcessTime instead of MeasurementCpuTime. (TestCaseWithBasicMeasurements): Use MeasurementPerfCounter and MeasurementProcessTime instead of MeasurementCpuTime. Co-authored-by: Qingchuan Shi <qingchuan.shi@amd.com> Change-Id: Ia850c05d5ce57d2dada70ba5b0061f566444aa2b
* gdb.perf/: FAIL on Python errors, avoid "ERROR: internal buffer is full"Pedro Alves2021-07-068-17/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, if you run make check-perf on a system with Python 3.8, tests seen to PASS, but they actually test a lot less than intended, due to: PerfTest::assemble, run ... python BackTrace(64).run() Traceback (most recent call last): File "<string>", line 1, in <module> File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 65, in run self.execute_test() File "<string>", line 49, in execute_test File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 45, in measure m.start(id) File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 102, in start self.start_time = time.clock() AttributeError: module 'time' has no attribute 'clock' Error while executing Python code. (gdb) PASS: gdb.perf/backtrace.exp: python BackTrace(64).run() And then, after fixing the above Python compatibility issues (which will be a separate patch), I get 86 instances of overflowing expect's buffer, like: ERROR: internal buffer is full. UNRESOLVED: gdb.perf/single-step.exp: python SingleStep(1000).run() This patch fixes both problems by adding & using a gdb_test_python_run routine that: - checks for Python errors - consumes output line by line gdb/testsuite/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * gdb.perf/backtrace.exp: Use gdb_test_python_run. * gdb.perf/disassemble.exp: Use gdb_test_python_run. * gdb.perf/single-step.exp: Use gdb_test_python_run. * gdb.perf/skip-command.exp: Use gdb_test_python_run. * gdb.perf/skip-prologue.exp: Use gdb_test_python_run. * gdb.perf/solib.exp: Use gdb_test_python_run. * gdb.perf/template-breakpoints.exp: Use gdb_test_python_run. * lib/perftest.exp (gdb_test_python_run): New. Change-Id: I007af36f164b3f4cda41033616eaaa4e268dfd2f
* [gdb/testsuite] Remove read1 timeout factor from gdb.base/info-macros.expTom de Vries2021-07-063-136/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the moment some check-read1 timeouts are handled like this in gdb.base/info-macros.exp: ... gdb_test_multiple_with_read1_timeout_factor 10 "$test" $testname { -re "$r1$r2$r3" { pass $testname } -re ".*#define TWO.*\r\n$gdb_prompt" { fail $testname } -re ".*#define THREE.*\r\n$gdb_prompt" { fail $testname } -re ".*#define FOUR.*\r\n$gdb_prompt" { fail $testname } } ... which is not ideal. We could use gdb_test_lines, but it currently doesn't support verifying the absence of regexps, which is done using the clauses above calling fail. Fix this by using gdb_test_lines and adding a -re-not syntax to gdb_test_lines, such that we can do: ... gdb_test_lines $test $testname $r1.*$r2 \ -re-not "#define TWO" \ -re-not "#define THREE" \ -re-not "#define FOUR" ... Tested on x86_64-linux, whith make targets check and check-read1. Also observed that check-read1 execution time is reduced from 6m35s to 13s. gdb/testsuite/ChangeLog: 2021-07-06 Tom de Vries <tdevries@suse.de> * gdb.base/info-macros.exp: Replace use of gdb_test_multiple_with_read1_timeout_factor with gdb_test_lines. (gdb_test_multiple_with_read1_timeout_factor): Remove. * lib/gdb.exp (gdb_test_lines): Add handling or -re-not <regexp>.
* [gdb/symtab] Fix skipping of import of C++ CUTom de Vries2021-07-066-7/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tom Tromey observed that when changing the language in gdb.dwarf2/imported-unit-bp.exp from c to c++, the test failed. This is due to this code in process_imported_unit_die: ... /* We're importing a C++ compilation unit with tag DW_TAG_compile_unit into another compilation unit, at root level. Regard this as a hint, and ignore it. */ if (die->parent && die->parent->parent == NULL && per_cu->unit_type == DW_UT_compile && per_cu->lang == language_cplus) return; ... which should have a partial symtabs counterpart. Add the missing counterpart in process_psymtab_comp_unit. Tested on x86_64-linux (openSUSE Leap 15.2), no regressions for config: - using default gcc version 7.5.0 (with 5 unexpected FAILs) - gcc 10.3.0 and target board unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects (with 1000 unexpected FAILs) gdb/ChangeLog: 2021-07-06 Tom de Vries <tdevries@suse.de> * dwarf2/read.c (scan_partial_symbols): Skip top-level imports of c++ CU. * testsuite/gdb.dwarf2/imported-unit-bp.exp: Moved to ... * testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl: ... here. * testsuite/gdb.dwarf2/imported-unit-bp-c++.exp: New test. * testsuite/gdb.dwarf2/imported-unit-bp-c.exp: New test. * testsuite/gdb.dwarf2/imported-unit.exp: Update.
* Simplify debug_names index writingTom Tromey2021-07-051-83/+10
| | | | | | This changes the .debug_names writer to find the TU indices in the main loop over all CUs and TUs. (An earlier patch applied this same treatment to the .gdb_index writer.)
* Simplify gdb_index writingTom Tromey2021-07-051-60/+24
| | | | | | | write_gdbindex writes the CUs first, then walks the signatured type hash table to write out the TUs. However, now that CUs and TUs are unified in the DWARF reader, it's simpler to handle both of these in the same loop.
* Minor cleanup to addrmap_index_data::previous_validTom Tromey2021-07-051-4/+4
| | | | | This changes addrmap_index_data::previous_valid to a bool, and initializes it inline.
* Fix oddity in write_gdbindexTom Tromey2021-07-051-1/+1
| | | | | | | | | | | | My recent patch to unify CUs and TUs introduced an oddity in write_gdbindex. Here, we pass 'i' to recursively_write_psymbols, but we must instead pass 'counter', to handle the situation where a TU is mixed in with the CUs. I am not sure a test case for this is possible. I think it can only happen when using DWARF 5, where a TU appears in .debug_info. However, this situation is already not handled correctly by .gdb_index. I filed a bug about this.
* Fix warning in symtab.cTom Tromey2021-07-051-0/+2
| | | | | | | | 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/testsuite] Fix fail in gdb.fortran/ptype-on-functions.exp with gcc-7Tom de Vries2021-07-052-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 05b85772061 "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-05 Tom de Vries <tdevries@suse.de> * gdb.fortran/ptype-on-functions.exp: Allow both $integer8 and $integer4 for size of string length.
* gdbsupport/common.m4: check for sigtimedwaitSimon Marchi2021-07-052-1/+4
| | | | | | | | | | | | | | | | | | | | 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
* gdb: return early if no execution in darwin_solib_create_inferior_hookSimon Marchi2021-07-041-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ea142fbfc9c1 ("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
* Update NEWS post GDB 11 branch creation.Joel Brobecker2021-07-032-1/+9
| | | | | | | | gdb/ChangeLog: * NEWS: Create a new section for the next release branch. Rename the section of the current branch, now that it has been cut.
* Bump version to 12.0.50.DATE-git.Joel Brobecker2021-07-034-2/+11
| | | | | | | | | | | | | | Now that the GDB 11 branch has been created, we can bump the version number. gdb/ChangeLog: GDB 11 branch created (4b51505e33441c6165e7789fa2b6d21930242927): * version.in: Bump version to 12.0.50.DATE-git. gdb/testsuite/ChangeLog: * gdb.base/default.exp: Change $_gdb_major to 12.
* Use 'bool' more idiomatically in dwarf_decode_linesTom Tromey2021-07-032-2/+7
| | | | | | | | | | | | I noticed a couple of spots related to dwarf_decode_lines where the 'include_p' field was not being used idiomatically -- it is of type bool now, so treat it as such. gdb/ChangeLog 2021-07-03 Tom Tromey <tom@tromey.com> * dwarf2/read.c (lnp_state_machine::record_line): Use 'true'. (dwarf_decode_lines): Remove '=='.
View Lorry Controller Status