aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-07-22[gdb/testsuite] Fix FAILs due to PR gcc/101575Tom de Vries4-5/+77
When running test-case gdb.ada/formatted_ref.exp with gcc-11 and target board unix/gdb:debug_flags=-gdwarf-4 we run into: ... (gdb) print/x s^M No definition of "s" in current context.^M (gdb) FAIL: gdb.ada/formatted_ref.exp: print/x s ... which is caused by "runto defs.adb:20" taking us to defs__struct1IP: ... (gdb) break defs.adb:20^M Breakpoint 1 at 0x402cfd: defs.adb:20. (2 locations)^M (gdb) run ^M Starting program: formatted_ref ^M ^M Breakpoint 1, defs__struct1IP () at defs.adb:20^M 20 return s.x; -- Set breakpoint marker here.^M (gdb) print s1'access^M ... instead of the expected defs.f1: ... (gdb) break defs.adb:20^M Breakpoint 1 at 0x402d0e: file defs.adb, line 20.^M (gdb) run ^M Starting program: formatted_ref ^M ^M Breakpoint 1, defs.f1 (s=...) at defs.adb:20^M 20 return s.x; -- Set breakpoint marker here.^M ... This is caused by incorrect line info due to gcc PR 101575 - "[gcc-11, -gdwarf-4] Missing .file <n> directive causes invalid line info". Fix this by when landing in defs__struct1IP: - xfailing the runto, and - issuing a continue to land in defs.f1. Likewise in a few other test-cases. Tested on x86_64-linux, with: - system gcc. - gcc-11 and target boards unix/gdb:debug_flags=-gdwarf-4 and unix/gdb:debug_flags=-gdwarf-5. gdb/testsuite/ChangeLog: 2021-07-22 Tom de Vries <tdevries@suse.de> * gdb.ada/formatted_ref.exp: Add xfail for PR gcc/101575. * gdb.ada/iwide.exp: Same. * gdb.ada/pkd_arr_elem.exp: Same.
2021-07-22[gdb/testsuite] Fix gdb.cp/step-and-next-inline.exp with gcc-11Tom de Vries4-13/+92
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.
2021-07-22Automatic date update in version.inGDB Administrator1-1/+1
2021-07-21[gdb/testsuite] Fix FAILs due to PR gcc/101452Tom de Vries7-4/+62
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.
2021-07-21[gdb/testsuite] Add KFAILs for gdb.ada FAILs with gcc-11Tom de Vries4-22/+133
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.
2021-07-21Automatic date update in version.inGDB Administrator1-1/+1
2021-07-20Fix printing of non-address types when memory tagging is enabledLuis Machado4-31/+68
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
2021-07-20Automatic date update in version.inGDB Administrator1-1/+1
2021-07-19Avoid expression parsing crash with unknown languageTom Tromey4-2/+18
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 dcd482c1b756d9da2130552a6eb58b852d6efb97) 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.
2021-07-19Automatic date update in version.inGDB Administrator1-1/+1
2021-07-18Automatic date update in version.inGDB Administrator1-1/+1
2021-07-17Add basic Z80 CPU supportSergey Belyashov12-2/+2982
Supported ISAs: - Z80 (all undocumented instructions) - Z180 - eZ80 (Z80 mode only) Datasheets: Z80: https://www.zilog.com/manage_directlink.php?filepath=docs/z80/um0080&extn=.pdf Z180: https://www.zilog.com/manage_directlink.php?filepath=docs/z180/ps0140&extn=.pdf eZ80: http://www.zilog.com/force_download.php?filepath=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTlWVFRBd056Y3VjR1Jt To debug Z80 programs using GDB you must configure and embed z80-stub.c to your program (SDCC compiler is required). Or you may use some simulator with GDB support. gdb/ChangeLog: * Makefile.in (ALL_TARGET_OBS): Add z80-tdep.c. * NEWS: Mention z80 support. * configure.tgt: Handle z80*. * features/Makefile (XMLTOC): Add z80.xml. * features/z80-cpu.xml: New. * features/z80.c: Generate. * features/z80.xml: New. * z80-tdep.c: New file. * z80-tdep.h: New file. gdb/stubs/ChangeLog: * z80-stub.c: New file. Change-Id: Id0b7a6e210c3f93c6853c5e3031b7bcee47d0db9
2021-07-17Automatic date update in version.inGDB Administrator1-1/+1
2021-07-16Automatic date update in version.inGDB Administrator1-1/+1
2021-07-15Automatic date update in version.inGDB Administrator1-1/+1
2021-07-14[gdb/testsuite] Fix gdb.base/gold-gdb-index.expTom de Vries3-1/+34
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.
2021-07-14Automatic date update in version.inGDB Administrator1-1/+1
2021-07-13Use /bin/sh as shebang in gdb/make-init-cLancelot SIX2-1/+5
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.
2021-07-13Avoid letting exceptions escape gdb_bfd_iovec_fileio_close (PR gdb/28080)Pedro Alves2-3/+29
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
2021-07-13Fix detach with target remote (PR gdb/28080)Pedro Alves7-6/+112
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
2021-07-13[gdb/testsuite] Fix check-libthread-db.exp FAILs with glibc 2.33Tom de Vries2-16/+26
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.
2021-07-13gdb: disable commit-resumed on -exec-interrupt --thread-groupSimon Marchi5-0/+208
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
2021-07-13Fix some dangling references to `netbsd-tdep`John Ericson4-7/+18
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/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
2021-07-13Automatic date update in version.inGDB Administrator1-1/+1
2021-07-12[gdb/testsuite] Fix gdb.btrace/tsx.exp on system with tsx disabled in microcodeTom de Vries2-0/+14
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.
2021-07-12[gdb/testsuite] Fix gdb.mi/mi-info-sources.exp for extra debug infoTom de Vries3-22/+85
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".
2021-07-12Automatic date update in version.inGDB Administrator1-1/+1
2021-07-11Fix warning in symtab.cTom Tromey2-0/+8
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 b6aeb717a8bdaa9cc348ec88a5fdf059e1337580)
2021-07-11Automatic date update in version.inGDB Administrator1-1/+1
2021-07-10Automatic date update in version.inGDB Administrator1-1/+1
2021-07-09Automatic date update in version.inGDB Administrator1-1/+1
2021-07-08gdb: don't set Linux-specific displaced stepping methods in s390_gdbarch_initSimon Marchi3-5/+8
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
2021-07-08gdb/Makefile.in: remove testsuite from SUBDIRSSimon Marchi2-1/+5
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
2021-07-08[gdb/testsuite] Fix gdb.guile/scm-breakpoint.exp with guile 3.0Tom de Vries2-3/+8
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.
2021-07-08Automatic date update in version.inGDB Administrator1-1/+1
2021-07-07Automatic date update in version.inGDB Administrator1-1/+1
2021-07-06gdb/testsuite: restore configure scriptSimon Marchi8-121/+4973
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
2021-07-06[gdb/testsuite] Fix fail in gdb.fortran/ptype-on-functions.exp with gcc-7Tom de Vries2-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-06 Tom de Vries <tdevries@suse.de> * gdb.fortran/ptype-on-functions.exp: Allow both $integer8 and $integer4 for size of string length.
2021-07-06Automatic date update in version.inGDB Administrator1-1/+1
2021-07-05gdb: fall back on sigpending + sigwait if sigtimedwait is not availableSimon Marchi2-2/+19
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>
2021-07-05gdbsupport/common.m4: check for sigtimedwaitSimon Marchi10-4/+26
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
2021-07-05Automatic date update in version.inGDB Administrator1-1/+1
2021-07-04gdb: return early if no execution in darwin_solib_create_inferior_hookSimon Marchi2-0/+9
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
2021-07-04Automatic date update in version.inGDB Administrator1-1/+1
2021-07-03Bump GDB version number to 11.0.90.DATE-git.Joel Brobecker2-1/+5
gdb/ChangeLog: * version.in: Set GDB version number to 11.0.90.DATE-git.
2021-07-03Document the GDB 11.0.90 release in gdb/ChangeLogJoel Brobecker1-0/+4
gdb/ChangeLog: GDB 11.0.90 released.
2021-07-03Set GDB version number to 11.0.90.Joel Brobecker2-1/+5
gdb/ChangeLog: * version.in: Set GDB version number to 11.0.90.
2021-07-03gdb/NEWS: Replace "Changes since GDB 10" by "Changes in GDB 11".Joel Brobecker2-1/+5
gdb/ChangeLog: * NEWS: Replace "Changes since GDB 10" by "Changes in GDB 11".
2021-07-03Set development mode to "off" by default.Joel Brobecker2-1/+5
bfd/ChangeLog: * development.sh (development): Set to false.
2021-07-03Bump version to 11.0.90.DATE-git.Joel Brobecker2-1/+6
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 11.0.90.DATE-git.
generated by cgit v1.1 at 2025-09-21 17:33:32 +0000