aboutsummaryrefslogtreecommitdiff
path: root/gdb/ChangeLog
AgeCommit message (Collapse)AuthorFilesLines
2019-11-18Fix crash with core + TUI + runSergio Durigan Junior1-0/+7
Ref.: https://bugzilla.redhat.com/show_bug.cgi?id=1765117 A segfault can happen in a specific scenario when using TUI + a corefile, as explained in the bug mentioned above. The problem happens when opening a corefile on GDB: $ gdb ./core program entering TUI (C-x a), and then issuing a "run" command. GDB segfaults with the following stack trace: (top-gdb) bt #0 0x00000000004cd5da in target_ops::shortname (this=0x0) at ../../binutils-gdb/gdb/target.h:449 #1 0x0000000000ac08fb in target_shortname () at ../../binutils-gdb/gdb/target.h:1323 #2 0x0000000000ac09ae in tui_locator_window::make_status_line[abi:cxx11]() const (this=0x23e1fa0 <_locator>) at ../../binutils-gdb/gdb/tui/tui-stack.c:86 #3 0x0000000000ac1043 in tui_locator_window::rerender (this=0x23e1fa0 <_locator>) at ../../binutils-gdb/gdb/tui/tui-stack.c:231 #4 0x0000000000ac1632 in tui_show_locator_content () at ../../binutils-gdb/gdb/tui/tui-stack.c:369 #5 0x0000000000ac63b6 in tui_set_key_mode (mode=TUI_COMMAND_MODE) at ../../binutils-gdb/gdb/tui/tui.c:321 #6 0x0000000000aaf9be in tui_inferior_exit (inf=0x2d446a0) at ../../binutils-gdb/gdb/tui/tui-hooks.c:181 #7 0x000000000044cddf in std::_Function_handler<void (inferior*), void (*)(inferior*)>::_M_invoke(std::_Any_data const&, inferior*&&) (__functor=..., __args#0=@0x7fffffffd650: 0x2d446a0) at /usr/include/c++/9/bits/std_function.h:300 #8 0x0000000000757db9 in std::function<void (inferior*)>::operator()(inferior*) const (this=0x2cf3168, __args#0=0x2d446a0) at /usr/include/c++/9/bits/std_function.h:690 #9 0x0000000000757876 in gdb::observers::observable<inferior*>::notify (this=0x23de0c0 <gdb::observers::inferior_exit>, args#0=0x2d446a0) at ../../binutils-gdb/gdb/gdbsupport/observable.h:106 #10 0x000000000075532d in exit_inferior_1 (inftoex=0x2d446a0, silent=1) at ../../binutils-gdb/gdb/inferior.c:191 #11 0x0000000000755460 in exit_inferior_silent (inf=0x2d446a0) at ../../binutils-gdb/gdb/inferior.c:234 #12 0x000000000059f47c in core_target::close (this=0x2d68590) at ../../binutils-gdb/gdb/corelow.c:265 #13 0x0000000000a7688c in target_close (targ=0x2d68590) at ../../binutils-gdb/gdb/target.c:3293 #14 0x0000000000a63d74 in target_stack::push (this=0x23e1800 <g_target_stack>, t=0x23c38c8 <the_amd64_linux_nat_target>) at ../../binutils-gdb/gdb/target.c:568 #15 0x0000000000a63dbf in push_target (t=0x23c38c8 <the_amd64_linux_nat_target>) at ../../binutils-gdb/gdb/target.c:583 #16 0x0000000000748088 in inf_ptrace_target::create_inferior (this=0x23c38c8 <the_amd64_linux_nat_target>, exec_file=0x2d58d30 "/usr/bin/cat", allargs="", env=0x25f12b0, from_tty=1) at ../../binutils-gdb/gdb/inf-ptrace.c:128 #17 0x0000000000795ccb in linux_nat_target::create_inferior (this=0x23c38c8 <the_amd64_linux_nat_target>, exec_file=0x2d58d30 "/usr/bin/cat", allargs="", env=0x25f12b0, from_tty=1) at ../../binutils-gdb/gdb/linux-nat.c:1094 #18 0x000000000074eae9 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at ../../binutils-gdb/gdb/infcmd.c:639 ... The problem happens because 'tui_locator_window::make_status_line' needs the value of 'target_shortname' in order to update the status line. 'target_shortname' is a macro which expands to: #define target_shortname (current_top_target ()->shortname ()) and, in our scenario, 'current_top_target ()' returns NULL, which obviously causes a segfault. But why does it return NULL, since, according to its comment on target.h, it should never do that? What is happening is that we're being caught in the middle of a "target switch". We had the 'core_target' on top, because we were inspecting a corefile, but when the user decided to invoke "run" GDB had to actually create the inferior, which ends up detecting that we have a target already, and tries to close it (from target.c): /* See target.h. */ void target_stack::push (target_ops *t) { /* If there's already a target at this stratum, remove it. */ strata stratum = t->stratum (); if (m_stack[stratum] != NULL) { target_ops *prev = m_stack[stratum]; m_stack[stratum] = NULL; target_close (prev); // <-- here } ... When the current target ('core_target') is being closed, it checks for possible observers registered with it and calls them. TUI is one of those observers, it gets called, tries to update the status line, and GDB crashes. The real problem is that we are clearing 'm_stack[stratum]', but forgetting to adjust 'm_top'. Interestingly, this scenario is covered in 'target_stack::unpush', but Pedro said he forgot to call it here.. The fix, therefore, is to call '::unpush' if there's a target on the stack. This patch has been tested on the Buildbot and no regressions have been found. I'm also submitting a testcase for it. gdb/ChangeLog: 2019-11-18 Sergio Durigan Junior <sergiodj@redhat.com> Pedro Alves <palves@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=1765117 * target.c (target_stack::push): Call 'unpush' if there's a target on top of the stack. gdb/testsuite/ChangeLog: 2019-11-18 Sergio Durigan Junior <sergiodj@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=1765117 * gdb.tui/corefile-run.exp: New file. Change-Id: I39e2f8b538c580c8ea5bf1d657ee877e47746c8f
2019-11-18Fix a bunch of python leaks due to missing calls to tp_free in *_dealloc ↵Philippe Waroquiers1-0/+12
functions. valgrind reports leaks in many python tests, such as: ==17162== VALGRIND_GDB_ERROR_BEGIN ==17162== 8,208 (5,472 direct, 2,736 indirect) bytes in 57 blocks are definitely lost in loss record 7,551 of 7,679 ==17162== at 0x4835753: malloc (vg_replace_malloc.c:307) ==17162== by 0x6EAFD1: _PyObject_New (object.c:279) ==17162== by 0x4720E6: blpy_iter(_object*) (py-block.c:92) ==17162== by 0x698772: PyObject_GetIter (abstract.c:2577) ==17162== by 0x2343BE: _PyEval_EvalFrameDefault (ceval.c:3159) ==17162== by 0x22E9E2: function_code_fastcall (call.c:283) ==17162== by 0x2340A8: _PyObject_Vectorcall (abstract.h:127) ==17162== by 0x2340A8: call_function (ceval.c:4987) ==17162== by 0x2340A8: _PyEval_EvalFrameDefault (ceval.c:3486) ==17162== by 0x22E9E2: function_code_fastcall (call.c:283) ==17162== by 0x82172B: _PyObject_Vectorcall (abstract.h:127) ==17162== by 0x82172B: method_vectorcall (classobject.c:67) ==17162== by 0x6AF474: _PyObject_Vectorcall (abstract.h:127) ==17162== by 0x6AF474: _PyObject_CallNoArg (abstract.h:153) ==17162== by 0x6AF474: _PyObject_CallFunctionVa (call.c:914) ==17162== by 0x6B0673: callmethod (call.c:1010) ==17162== by 0x6B0673: _PyObject_CallMethod_SizeT (call.c:1103) ==17162== by 0x477DFE: gdb_PyObject_CallMethod<> (python-internal.h:182) ==17162== by 0x477DFE: get_py_iter_from_func(_object*, char const*) (py-framefilter.c:272) ==17162== by 0x4791B4: py_print_args (py-framefilter.c:706) ==17162== by 0x4791B4: py_print_frame(_object*, enum_flags<frame_filter_flag>, ext_lang_frame_args, ui_out*, int, htab*) (py-framefilter.c:960) ==17162== by 0x47A130: gdbpy_apply_frame_filter(extension_language_defn const*, frame_info*, enum_flags<frame_filter_flag>, ext_lang_frame_args, ui_out*, int, int) (py-framefilter.c:1236) ==17162== by 0x369C39: apply_ext_lang_frame_filter(frame_info*, enum_flags<frame_filter_flag>, ext_lang_frame_args, ui_out*, int, int) (extension.c:563) ==17162== by 0x4EC9C9: backtrace_command_1 (stack.c:2031) ==17162== by 0x4EC9C9: backtrace_command(char const*, int) (stack.c:2183) ... Most of the leaks in python tests are due to the fact that many PyObject xxxxx_dealloc functions are missing the line to free self or obj such as: Py_TYPE (self)->tp_free (self); or Py_TYPE (obj)->tp_free (obj); With this patch, the number of python tests leaking decreases from 52 to 12. gdb/ChangeLog 2019-11-18 Philippe Waroquiers <philippe.waroquiers@skynet.be> * python/py-block.c (blpy_dealloc): Call tp_free. (blpy_block_syms_dealloc): Likewise. * python/py-finishbreakpoint.c (bpfinishpy_dealloc): Likewise. * python/py-inferior.c (infpy_dealloc): Likewise. * python/py-lazy-string.c (stpy_dealloc): Likewise. * python/py-linetable.c (ltpy_iterator_dealloc): Likewise. * python/py-symbol.c (sympy_dealloc): Likewise. * python/py-symtab.c (stpy_dealloc): Likewise. * python/py-type.c (typy_iterator_dealloc): Likewise.
2019-11-18Don't use class-initialization for the owner unionChristian Biesinger1-0/+5
As reported by PhilippeW, valgrind reports that symtab is uninitialized when compiling with GCC 4.8.5, which is the default compiler on CentOS 7. This is apparently a compiler bug fixed in later versions, but to keep CentOS 7 working, this patch initializes the union explicitly instead of using a class initializer. gdb/ChangeLog: 2019-11-18 Christian Biesinger <cbiesinger@google.com> * symtab.h (struct symbol) <owner>: Initialize explicitly in the constructor instead of using a class initializer. Change-Id: I94f48afeae5d29cf81a280295e2d02e2d7e1c1f1
2019-11-15Use gnulib's strerror_r on MinGWChristian Biesinger1-0/+10
There is no need to keep mingw-strerror around; we can just always use the code from posix-strerror. The main reason we had that code, it seems, is to handle winsock error codes, but gnulib's version handles those. Unfortunately the code can't be moved into common-utils.c because libinproctrace.so uses common-utils but not gnulib. gdb/ChangeLog: 2019-11-15 Christian Biesinger <cbiesinger@google.com> * Makefile.in: Replace {posix,mingw}-strerror.c with safe-strerror.c. * configure: Regenerate. * configure.ac: Don't source common.host. * gdbsupport/common.host: Remove. * gdbsupport/mingw-strerror.c: Remove. * gdbsupport/posix-strerror.c: Rename to... * gdbsupport/safe-strerror.c: ...this. gdb/gdbserver/ChangeLog: 2019-11-15 Christian Biesinger <cbiesinger@google.com> * Makefile.in: Add safe-strerror.c. * configure: Regenerate. * configure.ac: Don't source common.host. Change-Id: I9e6d8a752fc398784201f370cafee65e0ea05474
2019-11-15Use ctime_r and localtime_r for threadsafetyChristian Biesinger1-0/+7
To make these calls threadsafe. localtime_r is provided by gnulib if necessary, and for ctime_r we can just use it because it is in a linux- specific file. gdb/ChangeLog: 2019-11-15 Christian Biesinger <cbiesinger@google.com> * maint.c (scoped_command_stats::print_time): Use localtime_r instead of localtime (provided through gnulib if necessary). * nat/linux-osdata.c (time_from_time_t): Use ctime_r instead of ctime. Change-Id: I329bbdc39d5b576f51859ba00f1617e024c30cbd
2019-11-15Import the time_r gnulib moduleChristian Biesinger1-0/+5
This allows GDB to use localtime_r unconditionally. See https://lists.gnu.org/archive/html/bug-gnulib/2019-11/msg00022.html for details on the compile error mentioned below. gdb/ChangeLog: 2019-11-15 Christian Biesinger <cbiesinger@google.com> * gdbsupport/common-defs.h: Include time.h before pathmax.h to avoid compile errors. gnulib/ChangeLog: 2019-11-15 Christian Biesinger <cbiesinger@google.com> * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * config.in: Regenerate. * configure: Regenerate. * import/Makefile.am: Update. * import/Makefile.in: Regenerate. * import/m4/gnulib-cache.m4: Update. * import/m4/gnulib-comp.m4: Update. * import/m4/time_r.m4: New file. * import/time_r.c: New file. * update-gnulib.sh: Import time_r. Change-Id: I53fc861b192940d613ca97f2910b4533c730f667
2019-11-15Import the strerror_r-posix module and use it in GDB.Christian Biesinger1-0/+9
Makes sure to assign the return value of strerror_r to an int, so that we get a compile error if we accidentally get the wrong version. gdb/ChangeLog: 2019-11-15 Christian Biesinger <cbiesinger@google.com> * config.in: Regenerate. * configure: Regenerate. * gdbsupport/common.m4: No longer check for strerror_r. * gdbsupport/posix-strerror.c (safe_strerror): Always call the POSIX version of strerror_r, now that gnulib provides it if necessary. gdb/gdbserver/ChangeLog: 2019-11-15 Christian Biesinger <cbiesinger@google.com> * config.in: Regenerate. * configure: Regenerate. gnulib/ChangeLog: 2019-11-15 Christian Biesinger <cbiesinger@google.com> * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * config.in: Regenerate. * configure: Regenerate. * import/Makefile.am: Update. * import/Makefile.in: Regenerate. * import/extra/config.rpath: New file. * import/glthread/lock.c: New file. * import/glthread/lock.h: New file. * import/glthread/threadlib.c: New file. * import/m4/gnulib-cache.m4: Update. * import/m4/gnulib-comp.m4: Update. * import/m4/lib-ld.m4: New file. * import/m4/lib-link.m4: New file. * import/m4/lib-prefix.m4: New file. * import/m4/lock.m4: New file. * import/m4/strerror_r.m4: New file. * import/m4/threadlib.m4: New file. * import/strerror_r.c: New file. * update-gnulib.sh: Import strerror_r-posix. Change-Id: I5cfeb12a5203a4cd94a78581541e6085a68685c3
2019-11-14Update READMEChristian Biesinger1-0/+4
Adds descriptions for some recent-ish configure options to README. Also updates the minimum Python version per commit 6c28e44a359e9f6cf455ddff0009ca99406f7224. 2019-11-14 Christian Biesinger <cbiesinger@google.com> * README (`configure' options): Update. Change-Id: I8ce8ca6935afbd130295e143802c585cf1e735f9
2019-11-14Allow re-assigning to convenience variablesTom Tromey1-0/+5
A customer reported somewhat odd gdb behavior, where re-assigning an array or string to a convenience variable would yield "Too many array elements". A test case is: (gdb) p $x = "x" (gdb) p $x = "xyz" This patch fixes the problem by making a special case in the evaluator for assignment to convenience variables, which seems like the correct behavior. Note that a previous patch implemented this for Ada, see commit f411722cb ("Allow re-assigning to convenience variables"). gdb/ChangeLog 2019-11-14 Tom Tromey <tromey@adacore.com> * eval.c (evaluate_subexp_standard) <BINOP_ASSIGN>: Do not pass an expected type for the RHS if the LHS is a convenience variable. gdb/testsuite/ChangeLog 2019-11-14 Tom Tromey <tromey@adacore.com> * gdb.base/gdbvars.exp (test_convenience_variables): Add regression tests. Change-Id: I5e66a2d243931a5c43c7af4bc9f6717464c2477e
2019-11-14gdb: fix build error in unittests/vec-utils-selftests.cSimon Marchi1-0/+5
When building with gcc 9.2.0, I get the following build error: In file included from /home/simark/src/binutils-gdb/gdb/unittests/vec-utils-selftests.c:23: /home/simark/src/binutils-gdb/gdb/gdbsupport/gdb_vecs.h: In instantiation of ‘T unordered_remove(std::__debug::vector<T>&, typename std::__debug::vector<T>::iterator) [with T = selftests::vector_utils_tests::unordered_remove_tests()::obj; typename std::__debug::vector<T>::iterator = __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<selftests::vector_utils_tests::unordered_remove_tests()::obj*, std::__cxx1998::vector<selftests::vector_utils_tests::unordered_remove_tests()::obj, std::allocator<selftests::vector_utils_tests::unordered_remove_tests()::obj> > >, std::__debug::vector<selftests::vector_utils_tests::unordered_remove_tests()::obj>, std::random_access_iterator_tag>]’: /home/simark/src/binutils-gdb/gdb/unittests/vec-utils-selftests.c:53:26: required from here /home/simark/src/binutils-gdb/gdb/gdbsupport/gdb_vecs.h:53:5: error: implicitly-declared ‘selftests::vector_utils_tests::unordered_remove_tests()::obj::obj(const selftests::vector_utils_tests::unordered_remove_tests()::obj&)’ is deprecated [-Werror=deprecated-copy] 53 | T removed = std::move (*it); | ^~~~~~~ /home/simark/src/binutils-gdb/gdb/unittests/vec-utils-selftests.c:41:10: note: because ‘selftests::vector_utils_tests::unordered_remove_tests()::obj’ has user-provided ‘selftests::vector_utils_tests::unordered_remove_tests()::obj& selftests::vector_utils_tests::unordered_remove_tests()::obj::operator=(const selftests::vector_utils_tests::unordered_remove_tests()::obj&)’ 41 | obj &operator= (const obj &other) | ^~~~~~~~ In file included from /home/simark/src/binutils-gdb/gdb/unittests/vec-utils-selftests.c:23: /home/simark/src/binutils-gdb/gdb/gdbsupport/gdb_vecs.h:58:10: error: implicitly-declared ‘selftests::vector_utils_tests::unordered_remove_tests()::obj::obj(const selftests::vector_utils_tests::unordered_remove_tests()::obj&)’ is deprecated [-Werror=deprecated-copy] 58 | return removed; | ^~~~~~~ /home/simark/src/binutils-gdb/gdb/unittests/vec-utils-selftests.c:41:10: note: because ‘selftests::vector_utils_tests::unordered_remove_tests()::obj’ has user-provided ‘selftests::vector_utils_tests::unordered_remove_tests()::obj& selftests::vector_utils_tests::unordered_remove_tests()::obj::operator=(const selftests::vector_utils_tests::unordered_remove_tests()::obj&)’ 41 | obj &operator= (const obj &other) | ^~~~~~~~ I think gcc is just trying to be nice and recommends the good practice of providing a copy constructor if an assignment operator is provided. Silence the warning by providing that copy constructor. gdb/ChangeLog: * unittests/vec-utils-selftests.c (unordered_remove_tests::obj): Provide explicit default and copy constructor. Change-Id: I323361b1c120bf8525613b74e7e5983910e002df
2019-11-14Fix python gdbpy_breakpoint_object leak.Philippe Waroquiers1-0/+5
valgrind reports a leak when a breakpoint is created then deleted: ==1313== 40 bytes in 1 blocks are definitely lost in loss record 1,115 of 8,596 ==1313== at 0x4835753: malloc (vg_replace_malloc.c:307) ==1313== by 0x6E05BC: _PyObject_New (object.c:255) ==1313== by 0x470E4B: gdbpy_breakpoint_created(breakpoint*) (py-breakpoint.c:1023) ==1313== by 0x2946D9: operator() (std_function.h:687) ==1313== by 0x2946D9: notify (observable.h:106) ==1313== by 0x2946D9: install_breakpoint(int, std::unique_ptr<breakpoint, std::default_delete<breakpoint> >&&, int) (breakpoint.c:8136) ==1313== by 0x295BCA: create_breakpoint_sal (breakpoint.c:8878) ==1313== by 0x295BCA: create_breakpoints_sal (breakpoint.c:8919) ==1313== by 0x295BCA: create_breakpoints_sal_default (breakpoint.c:13671) ... The leak is due to a superfluous Py_INCREF when the python object is allocated inside gdbpy_breakpoint_created, when the python object is allocated locally: this object has already a refcount of 1, and the only reference is the reference from the C breakpoint object. The Py_INCREF is however needed when the python object was created from python: the python object was stored in bppy_pending_object, and gdbpy_breakpoint_created creates a new reference to this object. Solve the leak by calling 'Py_INCREF (newbp);' only in the bppy_pending_object case. Regression tested on debian/amd64 natively and under valgrind on centos/amd64. Before the patch, 795 tests have a definite leak. After the patch, 197 have a definite leak. Thanks to Tom, that helped on irc with the python refcount logic. gdb/ChangeLog 2019-11-14 Philippe Waroquiers <philippe.waroquiers@skynet.be> * python/py-finishbreakpoint.c (gdbpy_breakpoint_created): only call Py_INCREF (newbp) in the bppy_pending_object case.
2019-11-13Remove symbol-related static assertsTom Tromey1-0/+6
commit 3573abe1d added static asserts to ensure that symbol sizes don't vary. However, this failed to build on Windows, on at least one ARM platform (see PR build/25182) and internally at AdaCore for PPC. So, I think it is probably best to just remove these assertions, effectively reverting 3573abe1d. gdb/ChangeLog 2019-11-13 Tom Tromey <tromey@adacore.com> PR build/25182: * psympriv.h (partial_symbol): Remove static assert. * symtab.h (general_symbol_info, symbol): Remove static assert. Change-Id: I51940fb2240c474838b48494b5072081701789bb
2019-11-12gdb: Support printf 'z' size modifierAndrew Burgess1-0/+11
The gdb format mechanism doesn't currently support the 'z' size modifier, there are a few places in GDB where this is used. Instead of removing these uses lets just add support to GDB for using 'z'. I found this issue when trying to use some of the debug output. Before this commit: (gdb) set debug dwarf-line 9 (gdb) file test Reading symbols from test... Unrecognized format specifier 'z' in printf (No debugging symbols found in test) (gdb) After this commit: (gdb) set debug dwarf-line 9 (gdb) file test Reading symbols from test... Adding dir 1: /usr/include Adding file 1: test.c Adding file 2: stdc-predef.h Processing actual line 3: file 1, address 0x4004a0, is_stmt 1, discrim 0 Processing actual line 4: file 1, address 0x4004a0, is_stmt 1, discrim 0 .... lots of debug output ... Processing actual line 10: file 1, address 0x4003b7, is_stmt 0, discrim 0 (gdb) I've added a self test to cover the integer format size modifiers, including the 'z' modifier. gdb/ChangeLog: * gdbsupport/format.c (format_pieces::format_pieces): Support printf 'z' size modifier. * gdbsupport/format.h (enum argclass): Add size_t_arg. * printcmd.c (ui_printf): Handle size_t_arg. * ui-out.c (ui_out::vmessage): Likewise. * unittests/format_pieces-selftests.c (test_format_int_sizes): New function. (run_tests): Call test_format_int_sizes. gdb/gdbserver/ChangeLog: * ax.c (ax_printf): Handle size_t_arg. Change-Id: Ib6c44d88aa5bce265d757e4c0698881803dd186f
2019-11-12Make struct symbol inherit from general_symbol_infoChristian Biesinger1-0/+39
Since this is now no longer a POD, also give it a constructor that initializes all fields. (I have considered overloading operator new to zero-initialize the memory instead; let me know if you prefer that) gdb/ChangeLog: 2019-11-12 Christian Biesinger <cbiesinger@google.com> * ada-exp.y (write_ambiguous_var): Update. * buildsym.c (add_symbol_to_list): Update. * dwarf2read.c (read_variable): Update. (new_symbol): Update. * jit.c (finalize_symtab): Update. * language.c (language_alloc_type_symbol): Update. * symtab.c (fixup_symbol_section): Update. (initialize_objfile_symbol_1): Move code to... (initialize_objfile_symbol): ...here. Remove now-unnecessary memset. (allocate_symbol): Update. (allocate_template_symbol): Update. (get_symbol_address): Update. * symtab.h (struct symbol): Inherit from general_symbol_info instead of having as a field, and add a constructor. (SYMBOL_VALUE): Update. (SYMBOL_VALUE_ADDRESS): Update. (SET_SYMBOL_VALUE_ADDRESS): Update. (SYMBOL_VALUE_BYTES): Update. (SYMBOL_VALUE_COMMON_BLOCK): Update. (SYMBOL_BLOCK_VALUE): Update. (SYMBOL_VALUE_CHAIN): Update. (SYMBOL_LANGUAGE): Update. (SYMBOL_SECTION): Update. (SYMBOL_OBJ_SECTION): Update. (SYMBOL_SET_LANGUAGE): Update. (SYMBOL_SET_LINKAGE_NAME): Update. (SYMBOL_SET_NAMES): Update. (SYMBOL_NATURAL_NAME): Update. (SYMBOL_LINKAGE_NAME): Update. (SYMBOL_DEMANGLED_NAME): Update. (SYMBOL_SEARCH_NAME): Update. (SYMBOL_MATCHES_SEARCH_NAME): Update. (struct symbol): Update. (struct template_symbol): Update. (struct rust_vtable_symbol): Update. * xcoffread.c (SYMBOL_DUP): Update. Change-Id: I05b1628455bcce3efaa101e65ef051708d17eb07
2019-11-12Consolidate setting of current_layoutTom Tromey1-0/+6
Currently several functions in tui-layout.c set current_layout after their work is done. This moves this assignment to show_layout, instead. gdb/ChangeLog 2019-11-12 Tom Tromey <tom@tromey.com> * tui/tui-layout.c (show_layout): Set current_layout. (show_source_disasm_command, show_data) (show_source_or_disasm_and_command): Don't set current_layout. Change-Id: Id8b23797d68e607f0fcd6d29b8801869d40d1869
2019-11-12Move _initialize_tui_layout to end of fileTom Tromey1-0/+4
This moves _initialize_tui_layout to the end of the file, conforming to the typical gdb style. gdb/ChangeLog 2019-11-12 Tom Tromey <tom@tromey.com> * tui/tui-layout.c (_initialize_tui_layout): Move to end. Change-Id: I667f741b44b2bc470878a36f093a96d89fa31893
2019-11-12Make TUI resizing tests more robustTom Tromey1-0/+8
As Sergio pointed out, the TUI resizing tests are flaky. Debugging this showed three main problems. 1. expect's "stty" command processes its arguments one-by-one. So, rather than requesting a single resize, it sends two separate resize requests (one for rows and one for columns). This means gdb sees two SIGWINCH signals and resizes the terminal twice. I consider this a bug in expect, but I couldn't readily see how to report a bug; and anyway the fix wouldn't propagate very quickly. This patch works around this problem by explicitly doing two separate resizes (so it will be robust if expect ever does change); and then by waiting for each resize to complete before continuing. 2. gdb uses curses to drive the console rendering. Currently the test suite looks for terminal text insertion sequences to decide when a command has completed. However, it turns out that, sometimes, curses can output things in non-obvious ways. I didn't debug into curses but I guess this can happen due to output optimizations. No matter the reason, sometimes the current approach of only tracking text insertions is not enough to detect that gdb has finished rendering. This patch fixes this problem by arranging to detect the termination output after any curses command, not just insertion. 3. Detecting when a resize has completed is tricky. In fact, I could not find a way to reliably do this. This patch fixes this problem by adding a special maint "tui-resize-message" setting to gdb. When this is enabled, gdb will print a message after each SIGWINCH has been fully processed. The test suite enables this mode and then waits for the message in order to know when control can be returned to the calling test. This patch also adds a timeout, to avoid the situation where the terminal code fails to notice a change for some reason. This lets the test at least try to continue. gdb/ChangeLog 2019-11-12 Tom Tromey <tom@tromey.com> * tui/tui-win.c (resize_message): New global. (show_tui_resize_message): New function. (tui_async_resize_screen): Print message if requested. (_initialize_tui_win): Add tui-resize-message setting. * NEWS: Add entry for new commands. gdb/doc/ChangeLog 2019-11-12 Tom Tromey <tom@tromey.com> * gdb.texinfo (Maintenance Commands): Document new command. gdb/testsuite/ChangeLog 2019-11-12 Tom Tromey <tom@tromey.com> * lib/tuiterm.exp (_accept): Add wait_for parameter. Check output after any command. Expect prompt after WAIT_FOR is seen. (enter_tui): Enable resize messages. (command): Expect command in output. (get_line): Avoid error when cursor appears to be off-screen. (dump_screen): Include screen size in title. (_do_resize): New proc, from "resize". (resize): Rewrite. Do resize in two steps. * gdb.tui/empty.exp (layouts): Fix entries. (check_boxes): Remove xfail. (check_text): Dump screen on failure. Change-Id: I420e0259cb99b21adcd28f671b99161eefa7a51d
2019-11-11Document and extend readline-bindable functionsTom Tromey1-0/+5
This adds readline-bindable function names to a few gdb functions that already had key bindings. This lets users change the bindings. This also removes the gdb-command function. Due to how this function is implemented, it doesn't make sense to allow binding it. Finally, this updates the documentation to reflect these changes. gdb/ChangeLog 2019-11-11 Tom Tromey <tom@tromey.com> * tui/tui.c (tui_initialize_readline): Add new bindable readline functions. gdb/doc/ChangeLog 2019-11-11 Tom Tromey <tom@tromey.com> * gdb.texinfo (TUI Keys): Document readline function names. Change-Id: I2233779b7aefe372f19bd03c8f325733c3385e72
2019-11-11Use getpwuid_r instead of getpwuidChristian Biesinger1-0/+4
gdb/ChangeLog: 2019-11-11 Christian Biesinger <cbiesinger@google.com> * nat/linux-osdata.c (user_from_uid): Use getpwuid_r. Change-Id: I587359267f8963ef1da6ba0223a1525807a721de
2019-11-10gdb/python: Introduce gdb.lookup_static_symbolsAndrew Burgess1-0/+10
If gdb.lookup_static_symbol is going to return a single symbol then it makes sense (I think) for it to return a context sensitive choice of symbol, that is the global static symbol that would be visible to the program at that point. However, if the user of the python API wants to instead get a consistent set of global static symbols, no matter where they stop, then they have to instead consider all global static symbols with a given name - there could be many. That is what this new API function offers, it returns a list (possibly empty) of all global static symbols matching a given name (and optionally a given symbol domain). gdb/ChangeLog: * python/py-symbol.c (gdbpy_lookup_static_symbols): New function. * python/python-internal.h (gdbpy_lookup_static_symbols): Declare new function. * python/python.c (python_GdbMethods): Add gdb.lookup_static_symbols method. * NEWS: Mention gdb.lookup_static_symbols. gdb/testsuite/ChangeLog: * gdb.python/py-symbol.exp: Add test for gdb.lookup_static_symbols. gdb/doc/ChangeLog: * python.texi (Symbols In Python): Add documentation for gdb.lookup_static_symbols. Change-Id: I1153b0ae5bcbc43b3dcf139043c7a48bf791e1a3
2019-11-10gdb/python: smarter symbol lookup for gdb.lookup_static_symbolAndrew Burgess1-0/+6
When using gdb.lookup_static_symbol I think that GDB should find static symbols (global symbol with static linkage) from the current object file ahead of static symbols from other object files. This means that if we have two source files f1.c and f2.c, and both files contains 'static int foo;', then when we are stopped in f1.c a call to 'gdb.lookup_static_symbol ("foo")' will find f1.c::foo, and if we are stopped in f2.c we would find 'f2.c::foo'. Given that gdb.lookup_static_symbol always returns a single symbol, but there can be multiple static symbols with the same name GDB is always making a choice about which symbols to return. I think that it makes sense for the choice GDB makes in this case to match what a user would get on the command line if they asked to 'print foo'. gdb/testsuite/ChangeLog: * gdb.python/py-symbol.c: Declare and call function from new py-symbol-2.c file. * gdb.python/py-symbol.exp: Compile both source files, and add new tests for gdb.lookup_static_symbol. * gdb.python/py-symbol-2.c: New file. gdb/doc/ChangeLog: * python.texi (Symbols In Python): Extend documentation for gdb.lookup_static_symbol. gdb/ChangeLog: * python/py-symbol.c (gdbpy_lookup_static_symbol): Lookup in static block of current object file first. Also fix typo in header comment. Change-Id: Ie55dbeb8806f35577b46015deecde27a0ca2ab64
2019-11-10gdb: Add a class to track last display symtab and line informationAndrew Burgess1-0/+27
In stack.c we currently have a set of static global variables to track the last displayed symtab and line. This commit moves all of these into a class and adds an instance of the class to track the same information. The API into stack.c is unchanged after this cleanup. There should be no user visible changes after this commit. gdb/ChangeLog: * stack.c (set_last_displayed_sal): Delete. (last_displayed_sal_valid): Delete. (last_displayed_pspace): Delete. (last_displayed_addr): Delete. (last_displayed_symtab): Delete. (last_displayed_line): Delete. (class last_displayed_symtab_info_type): New. (last_displayed_symtab_info): New static global variable. (print_frame_info): Call methods on last_displayed_symtab_info. (clear_last_displayed_sal): Update header comment, and make use of last_displayed_symtab_info. (last_displayed_sal_is_valid): Likewise. (get_last_displayed_pspace): Likewise. (get_last_displayed_addr): Likewise. (get_last_displayed_symtab): Likewise. (get_last_displayed_line): Likewise. (get_last_displayed_sal): Likewise. * stack.h (clear_last_displayed_sal): Update header comment. (last_displayed_sal_is_valid): Likewise. (get_last_displayed_pspace): Likewise. (get_last_displayed_addr): Likewise. (get_last_displayed_symtab): Likewise. (get_last_displayed_line): Likewise. (get_last_displayed_sal): Likewise. Change-Id: Ia3dbfe267feec03108c5c8ed8bd94fc0a030c3ed
2019-11-10gdb: Convert frame_show_address to return a boolAndrew Burgess1-0/+6
Just a clean up, should be no user visible changes after this commit. gdb/ChangeLog: * stack.c (frame_show_address): Convert return type to bool. * stack.h (frame_show_address): Likewise, and update header comment. Change-Id: Iaaa9ebd4ff6534db19c5329f1c604932c747bd7f
2019-11-10gdb_vecs.h: Avoid self move assignAndrew Burgess1-0/+6
While working on another patch I ran into an issue with unordered_remove (in gdb_vecs.h), where removing the last item of the vector can cause a self move assign. When compiling the C++ standard library in debug mode (with -D_GLIBCXX_DEBUG=1) this causes an error to trigger. I've fixed the issue in this patch and provided a unit test. The provided unit test includes an assignment operator which checks for self move assign, this removes the need to compile with -D_GLIBCXX_DEBUG=1 in order to spot the bug. If you're keen to see the error reported from the C++ standard library then remove operator= from the unit test and recompile GDB with -D_GLIBCXX_DEBUG=1. gdb/ChangeLog: * Makefile.in (SUBDIR_UNITTESTS_SRCS): Add new file to the list. * unittests/vec-utils-selftests.c: New file. * gdbsupport/gdb_vecs.h (unordered_remove): Avoid self move assign. Change-Id: I80247b20cd5212038117db7412865f5e6a9257cd
2019-11-10Remove can_highlight from TUI windowsTom Tromey1-0/+9
Each TUI window has a "can_highlight" member. However, this has the same meaning as "can_box" -- a window can be highlighted if and only if it can be boxed. So, this patch removes can_highlight in favor of simply using can_box. gdb/ChangeLog 2019-11-10 Tom Tromey <tom@tromey.com> * tui/tui-wingeneral.c (tui_unhighlight_win): Use can_box. (tui_highlight_win): Likewise. (tui_win_info::check_and_display_highlight_if_needed): Likewise. * tui/tui-data.h (struct tui_win_info) <can_highlight>: Remove. * tui/tui-command.h (struct tui_cmd_window) <tui_cmd_window>: Don't set can_highlight. Change-Id: I35916859070efcdfcc6e692c71cc6070956dcfce
2019-11-10Remove unused constructor declaration from cli_style_optionTom Tromey1-0/+5
I noticed that cli_style_option declares a constructor that is never defined. This removes it. gdb/ChangeLog 2019-11-10 Tom Tromey <tom@tromey.com> * cli/cli-style.h (class cli_style_option) <cli_style_option>: Remove unused declaration. Change-Id: Ic59ec7eab4d7183d9392b58709354b2d4449b7be
2019-11-08Constify command_line_inputTom Tromey1-0/+10
This changes command_line_input to return a "const char *", which is appropriate because the memory is owned by command_line_input. Then it fixes up the users. I looked at making command_line_input transfer ownership to its caller instead, but this is complicated due to the way read_next_line is called, so I decided against it. Tested by rebuilding. gdb/ChangeLog 2019-11-08 Tom Tromey <tromey@adacore.com> * top.c (read_command_file): Update. (command_line_input): Make return type const. * python/py-gdb-readline.c: Update. * linespec.c (decode_line_2): Update. * defs.h (command_line_input): Make return type const. * cli/cli-script.c (read_next_line): Make return type const. * ada-lang.c (get_selections): Update. Change-Id: I27e6c9477fd1005ab5b16e0d337e4c015b6e6248
2019-11-06Use strtok_r instead of strtokChristian Biesinger1-0/+10
Improves threadsafety. This will be important when the patch series at https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/176 lands. gdb/ChangeLog: 2019-11-06 Christian Biesinger <cbiesinger@google.com> * linux-tdep.c (linux_info_proc): Use strtok_r instead of strtok. * mi/mi-main.c (output_cores): Likewise. * nat/linux-osdata.c (linux_xfer_osdata_cpus): Likewise. (linux_xfer_osdata_modules): Likewise. * remote.c (register_remote_support_xml): Likewise. * sparc64-tdep.c (adi_is_addr_mapped): Likewise. * xml-syscall.c (syscall_create_syscall_desc): Likewise. gdb/gdbserver/ChangeLog: 2019-11-06 Christian Biesinger <cbiesinger@google.com> * linux-x86-low.c (x86_linux_process_qsupported): Use strtok_r instead of strtok. * server.c (handle_query): Likewise. (captured_main): Likewise. Change-Id: Ief6138965a24398e5fc064598cd8f2abd3b5047c
2019-11-06Remove some includes of readline.hTom Tromey1-0/+14
I went through most of the spots that include readline.h and, when appropriate, either removed the include or changed it to include tilde.h. Note that remote-sim.c and bsd-kvm.c could probably include tilde.h instead, but I did not change these. I think I can't build the latter, and I didn't want to set up a sim build for the former. Tested by rebuilding. gdb/ChangeLog 2019-11-06 Tom Tromey <tom@tromey.com> * tui/tui-interp.c: Don't include readline.h. * tui/tui-hooks.c: Don't include readline.h. * symmisc.c: Include tilde.h, not readline.h. * symfile.c: Include tilde.h, not readline.h. * source.c: Include tilde.h, not readline.h. * solib.c: Include tilde.h, not readline.h. * psymtab.c: Include tilde.h, not readline.h. * exec.c: Include tilde.h, not readline.h. * corelow.c: Include tilde.h, not readline.h. * cli/cli-dump.c: Include tilde.h, not readline.h. * cli/cli-cmds.c: Don't include readline.h. Change-Id: I60487a190c43128b800ef77517d1ab42957571d7
2019-11-05Fix regression from TUI disassembly style patchTom Tromey1-0/+6
My previous patch to add styling to the TUI disassembly failed to correctly fix a bug that Simon had pointed out in review. This patch fixes the bug. gdb/ChangeLog 2019-11-05 Tom Tromey <tom@tromey.com> * tui/tui-disasm.c (struct tui_asm_line) <addr_size>: New member. (tui_disassemble): Set addr_size. (tui_disasm_window::set_contents): Use addr_size. Change-Id: Ic0152f3b82a2f79be28ae46d590096661f271580
2019-11-05Remove la_get_string memberTom Tromey1-0/+21
The la_get_string member of struct language_defn was intended to provide a way to fetch string data from a "string" object in a language-dependent way. However, it turned out that this was never needed, and was only ever implemented for C. This patch removes the language hook entirely. gdb/ChangeLog 2019-11-05 Tom Tromey <tom@tromey.com> * rust-lang.c (rust_language_defn): Update. * python/py-value.c (valpy_string): Call c_get_string. * p-lang.c (pascal_language_defn): Update. * opencl-lang.c (opencl_language_defn): Update. * objc-lang.c (objc_language_defn): Update. * m2-lang.c (m2_language_defn): Update. * language.c (unknown_language_defn, auto_language_defn): Update. (default_get_string): Remove. * guile/scm-value.c (gdbscm_value_to_string): Use c_get_string. * go-lang.c (go_language_defn): Update. * f-lang.c (f_language_defn): Update. * d-lang.c (d_language_defn): Update. * c-lang.c (c_language_defn, cplus_language_defn) (asm_language_defn, minimal_language_defn): Update. * ada-lang.c (ada_language_defn): Update. * language.h (struct language_defn) <la_get_string>: Remove. (LA_GET_STRING): Remove. (default_get_string): Don't declare. Change-Id: Ia97763dfe34dc8ecb46587f7a651f8af9be8fdbd
2019-11-05Style disassembly in the TUITom Tromey1-0/+27
This patch changes the TUI disassembly window to style its contents. The styling should be identical to what is seen in the CLI. This involved a bit of rearrangement, so that the source and disassembly windows could share both the copy_source_line utility function, and the ability to react to changes in "set style enabled". This version introduces a new function to strip the styling from the address string when computing the length. As a byproduct, it also removes the unused "insn_size" computation from tui_disasm_window::set_contents. gdb/ChangeLog 2019-11-05 Tom Tromey <tom@tromey.com> * tui/tui-source.h (struct tui_source_window): Inline constructor. Remove destructor. <style_changed, m_observable>: Move to superclass. * tui/tui-winsource.h (tui_copy_source_line): Declare. (struct tui_source_window_base): Move private members to end. <style_changed, m_observable>: Move from tui_source_window. * tui/tui-winsource.c (tui_copy_source_line): Move from tui-source.c. Rename from copy_source_line. Add special handling for negative line number. (tui_source_window_base::style_changed): Move from tui_source_window. (tui_source_window_base): Register observer. (~tui_source_window_base): New. * tui/tui-source.c (copy_source_line): Move to tui-winsource.c; rename. (tui_source_window::set_contents): Use tui_copy_source_line. (tui_source_window::tui_source_window): Move to tui-source.h. (tui_source_window::~tui_source_window): Remove. (tui_source_window::style_changed): Move to superclass. * tui/tui-disasm.c (tui_disassemble): Create string file with styling, when possible. Add "addr_size" parameter. (tui_disasm_window::set_contents): Use tui_copy_source_line. Don't compute maximum size. (len_without_escapes): New function Change-Id: I8722635eeecbbb1633d943a65b856404c2d467b0
2019-11-05Change tui_source_element::line to have type std::stringTom Tromey1-0/+8
This changes tui_source_element::line to be of type std::string. This reduces the number of copies made. gdb/ChangeLog 2019-11-05 Tom Tromey <tom@tromey.com> * tui/tui-winsource.h (struct tui_source_element) <line>: Now a std::string. * tui/tui-winsource.c (tui_show_source_line): Update. * tui/tui-source.c (tui_source_window::set_contents): Update. * tui/tui-disasm.c (tui_disasm_window::set_contents): Update. Change-Id: Id600f3e1d386a2911f187366e05e2ec599068dd2
2019-11-05Fix ARI warning in symtab.hChristian Biesinger1-0/+5
gdb/ChangeLog: 2019-11-05 Christian Biesinger <cbiesinger@google.com> * symtab.h (gdb_static_assert): Put && operator at the beginning of the line instead of the end. Change-Id: I6d05c2f5e46c3f317ba97458509b2da9fd03464b
2019-11-04Add static_asserts for the sizes of space-critical structsChristian Biesinger1-0/+6
Specifically the three structs mentioned in symtab.h: - general_symbol_info - symbol - partial_symbol This ensures that those structs won't accidentally get bigger. gdb/ChangeLog: 2019-11-04 Christian Biesinger <cbiesinger@google.com> * psympriv.h: Add static_asserts for sizeof (general_symbol_info) and sizeof (symbol). * symtab.h: Add a static_assert for sizeof (partial_symbol). Change-Id: Idd68320aa3e79ee7cc749019724636a58ce4b9c6
2019-11-04Obsolete Solaris 10 supportRainer Orth1-0/+8
Here's the patch corresponding to the Solaris 10 obsoletion announcement https://sourceware.org/ml/gdb/2019-10/msg00008.html Right now it doesn't remove any code, but obviates the need to test on that ancient platform. Besides, some of the patches I have in my queue would require different solutions for Solaris 10 and 11. There are a few comment-only references that I've kept since they are still correct as is, even when GDB doesn't support Solaris 10 any longer. The only code fragment I've left in is support for /proc/<pid/path/a.out in procfs.c (procfs_target::pid_to_exec_file): while current Solaris 11 updates provide /proc/<pid>/execname, that wasn't present in Solaris 11.0 and still isn't in current Illumos and I didn't want to make live harder for them. Tested on i386-pc-solaris2.10 (obsolete configuration rejected) and x86_64-pc-linux-gnu x sparc64-solaris2.10 (likewise) resp. x86_64-pc-linux-gnu x sparcv9-solaris2.11 (still builds; I'm using the sparcv9 form for 64-bit SPARC customary on Solaris in the MAINTAINERS file now). * NEWS (Changes since GDB 8.3): Document Solaris 10 removal. * configure.host: Mark *-*-solaris2.10* obsolete. * configure.tgt: Mark Solaris < 11 obsolete. * MAINTAINERS (Target Instruction Set Architectures) <sparc>: Update target triplet.
2019-11-01Simplify print_sys_errmsgTom Tromey1-0/+4
On irc, Christian pointed out that print_sys_errmsg could be simplified by avoiding alloca entirely. This patch implements this. gdb/ChangeLog 2019-11-01 Tom Tromey <tromey@adacore.com> * utils.c (print_sys_errmsg): Simplify. Change-Id: Ic399dade274ea61b63ef0540b3a3be2f0f80160a
2019-11-01Fix up safe_strerror constificationTom Tromey1-0/+4
The earlier patch to constify safe_strerror missed a couple of spots, corrected here. gdb/ChangeLog 2019-11-01 Tom Tromey <tromey@adacore.com> * gdbsupport/mingw-strerror.c (safe_strerror): Constify result. Change-Id: I36d5ced144d27b1a6734d9ab9a10a7b9f339ae88
2019-11-01Move check for strerror_r to common.m4 where it belongsChristian Biesinger1-0/+6
gdb/ChangeLog: 2019-11-01 Christian Biesinger <cbiesinger@google.com> * configure: Regenerate. * configure.ac: Remove check for strerror_r. * gdbsupport/common.m4: Check for strerror_r. gdb/gdbserver/ChangeLog: 2019-11-01 Christian Biesinger <cbiesinger@google.com> * configure: Regenerate. * configure.ac: Remove check for strerror_r. Change-Id: Ibc290c3f84b1db23e998cffdbe2c1f97651d2a8d
2019-11-01[ARM, thumb] Fix disassembling bug after reloading a symbol fileLuis Machado1-0/+12
The speed optimization from commit 5f6cac4085c95c5339b9549dc06d4f9184184fa6 made GDB skip reloading all symbols when the same symbol file is reloaded. As a result, ARM targets only read the mapping symbols the first time we load a symbol file. When reloaded, the speed optimization above will cause an early return and gdbarch_record_special_symbol won't be called to save mapping symbol data, which in turn affects disassembling of thumb instructions. First load and correct disassemble output: Dump of assembler code for function main: 0x0000821c <+0>: bx pc 0x0000821e <+2>: nop 0x00008220 <+4>: mov r0, #0 0x00008224 <+8>: bx lr Second load and incorrect disassemble output: Dump of assembler code for function main: 0x0000821c <+0>: bx pc 0x0000821e <+2>: nop 0x00008220 <+4>: movs r0, r0 0x00008222 <+6>: b.n 0x8966 0x00008224 <+8>: vrhadd.u16 d14, d14, d31 This happens because the mapping symbol data is stored in an objfile_key-based container, and that data isn't preserved across the two symbol loading operations. The following patch fixes this by storing the mapping symbol data in a bfd_key-based container, which doesn't change as long as the bfd is the same. I've also added a new test to verify the correct disassemble output. gdb/ChangeLog: 2019-11-01 Luis Machado <luis.machado@linaro.org> PR gdb/25124 * arm-tdep.c (arm_per_objfile): Rename to ... (arm_per_bfd): ... this. (arm_objfile_data_key): Rename to ... (arm_bfd_data_key): ... this. (arm_find_mapping_symbol): Adjust access to new bfd_key-based data. (arm_record_special_symbol): Likewise. gdb/testsuite/ChangeLog: 2019-11-01 Luis Machado <luis.machado@linaro.org> PR gdb/25124 * gdb.arch/pr25124.S: New file. * gdb.arch/pr25124.exp: New file. Change-Id: I22c3e6ebe9bfedad66d56fe9656994fa1761c485
2019-10-31gdb: Don't print a newline in language la_print_typedef methodsAndrew Burgess1-0/+12
When calling the language la_print_typedef method, don't include a newline at the end, instead print the newline from the users of la_print_typedef. This change will be useful in a later commit when the output from la_print_typedef will be placed into an MI output field, in which case the trailing newline is not required. There should be no user visible changes after this commit. gdb/ChangeLog: * ada-typeprint.c (ada_print_typedef): Don't print newline at the end. * c-typeprint.c (c_print_typedef): Likewise. * f-typeprint.c (f_print_typedef): Likewise. * m2-typeprint.c (m2_print_typedef): Likewise. * p-typeprint.c (pascal_print_typedef): Likewise. * rust-lang.c (rust_print_typedef): Likewise. * symtab.c (print_symbol_info): Print a newline after calling typedef_print. Change-Id: I6e697ea1ec0eadaa31aefaea959b2055188d680d
2019-10-31gdb: Add new commands to list module variables and functionsAndrew Burgess1-0/+18
This patch adds two new commands "info module functions" and "info module variables". These commands list all of the functions and variables grouped by module and then by file. For example: (gdb) info module functions All functions in all modules: Module "mod1": File /some/path/gdb/testsuite/gdb.fortran/info-types.f90: 35: void mod1::__copy_mod1_M1t1(Type m1t1, Type m1t1); 25: void mod1::sub_m1_a(integer(kind=4)); 31: integer(kind=4) mod1::sub_m1_b(void); Module "mod2": File /some/path/gdb/testsuite/gdb.fortran/info-types.f90: 41: void mod2::sub_m2_a(integer(kind=4), logical(kind=4)); 49: logical(kind=4) mod2::sub_m2_b(real(kind=4)); The new commands take set of flags that allow the output to be filtered, the user can filter by variable/function name, type, or containing module. As GDB doesn't currently track the relationship between a module and the variables or functions within it in the symbol table, so I filter based on the module prefix in order to find the functions or variables in each module. What this makes clear is that a user could get this same information using "info variables" and simply provide the prefix themselves, for example: (gdb) info module functions -m mod1 _a All functions matching regular expression "_a", in all modules matching regular expression "mod1": Module "mod1": File /some/path/gdb/testsuite/gdb.fortran/info-types.f90: 25: void mod1::sub_m1_a(integer(kind=4)); Is similar to: (gdb) info functions mod1::.*_a.* All functions matching regular expression "mod1::.*_a": File /some/path/gdb/testsuite/gdb.fortran/info-types.f90: 25: void mod1::sub_m1_a(integer(kind=4)); The benefits I see for a separate command are that the user doesn't have to think (or know) about the module prefix format, nor worry about building a proper regexp. The user can also easily scan across modules without having to build complex regexps. The new function search_module_symbols is extern in this patch despite only being used within symtab.c, this is because a later patch in this series will also be using this function from outside symtab.c. This patch is a new implementation of an idea originally worked on by Mark O'Connor, Chris January, David Lecomber, and Xavier Oro from ARM. gdb/ChangeLog: * symtab.c (info_module_cmdlist): New variable. (info_module_command): New function. (search_module_symbols): New function. (info_module_subcommand): New function. (struct info_modules_var_func_options): New struct. (info_modules_var_func_options_defs): New variable. (make_info_modules_var_func_options_def_group): New function. (info_module_functions_command): New function. (info_module_variables_command): New function. (info_module_var_func_command_completer): New function. (_initialize_symtab): Register new 'info module functions' and 'info module variables' commands. * symtab.h (typedef symbol_search_in_module): New typedef. (search_module_symbols): Declare new function. * NEWS: Mention new commands. gdb/doc/ChangeLog: * gdb.texinfo (Symbols): Document new 'info module variables' and 'info module functions' commands. gdb/testsuite/ChangeLog: * gdb.fortran/info-modules.exp: Update expected results, and add additional tests for 'info module functinos', and 'info module variables'. * gdb.fortran/info-types.exp: Update expected results. * gdb.fortran/info-types.f90: Extend testcase with additional module variables and functions. Change-Id: I8c2960640e2e101b77eff54027d687e21ec22e2b
2019-10-31gdb/fortran: Add new 'info modules' commandAndrew Burgess1-0/+19
Add a new command 'info modules' that lists all of the modules GDB knows about from the debug information. A module is a debugging entity in the DWARF defined with DW_TAG_module, currently Fortran is known to use this tag for its modules. I'm not aware of any other language that currently makes use of DW_TAG_module. The output style is similar to the 'info type' output: (gdb) info modules All defined modules: File info-types.f90: 16: mod1 24: mod2 (gdb) Where the user is told the file the module is defined in and, on the left hand side, the line number at which the module is defined along with the name of the module. This patch is a new implementation of an idea originally worked on by Mark O'Connor, Chris January, David Lecomber, and Xavier Oro from ARM. gdb/ChangeLog: * dwarf2read.c (dw2_symtab_iter_next): Handle MODULE_DOMAIN. (dw2_expand_marked_cus): Handle MODULES_DOMAIN. (dw2_debug_names_iterator::next): Handle MODULE_DOMAIN and MODULES_DOMAIN. (scan_partial_symbols): Only create partial module symbols for non declarations. * psymtab.c (recursively_search_psymtabs): Handle MODULE_DOMAIN and MODULES_DOMAIN. * symtab.c (search_domain_name): Likewise. (search_symbols): Likewise. (print_symbol_info): Likewise. (symtab_symbol_info): Likewise. (info_modules_command): New function. (_initialize_symtab): Register 'info modules' command. * symtab.h (enum search_domain): Add MODULES_DOMAIN. * NEWS: Mention new 'info modules' command. gdb/doc/ChangeLog: * gdb.texinfo (Symbols): Document new 'info modules' command. gdb/testsuite/ChangeLog: * gdb.fortran/info-modules.exp: New file. * gdb.fortran/info-types.exp: Build with new file. * gdb.fortran/info-types.f90: Include and use new module. * gdb.fortran/info-types-2.f90: New file. Change-Id: I2b781dd5a06bcad04620ccdc45f01a0f711adfad
2019-10-31NEWS and documentation for $_gdb_setting and $_gdb_setting_str.Philippe Waroquiers1-0/+5
gdb/ChangeLog 2019-10-31 Philippe Waroquiers <philippe.waroquiers@skynet.be> * NEWS: Mention $_gdb_setting, $_gdb_setting_str, $_gdb_maint_setting and $_gdb_maint_setting_str. gdb/doc/ChangeLog 2019-10-31 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.texinfo (Convenience Funs): Document the new $_gdb_setting_str, $_gdb_maint_setting and $_gdb_maint_setting_str convenience functions.
2019-10-31Implement convenience functions to examine GDB settings.Philippe Waroquiers1-0/+10
The new convenience functions $_gdb_setting and $_gdb_setting_str provide access to the GDB settings in user-defined commands. Similarly, $_gdb_maint_setting and $_gdb_maint_setting_str provide access to the GDB maintenance settings. The patch was developed following a comment of Eli about the 'set may-call-functions'. Eli said that user-defined functions should have a way to change their behavior according to this setting. Rather than have a specialized $_may_call_functions, this patch implements a general way to access any GDB setting. Compared to doing such access via Python 'gdb.parameter' and/or 'gdb.execute("set somesetting tosomevalue"): * The 'with' command is much better than the above python usage: if the user types C-c or an error happens between the set pagination off and the python "set pagination on", the above python does not restore the original setting. * Effectively, with the "gdb.parameter" python one liner, it is possible to do simple 'if' conditions, such as set and restore pagination. But mixing the "python if" within canned sequence of commands is cumbersome for non trivial combinations. E.g. if several commands have to be done for a certain condition accessed from python, I guess something like will be needed: python if __some_setting: gdb.execute("some command") python if __some_setting: gdb.execute("some other command") python if __some_setting: gdb.execute("some different command") (without speaking about nested "if-s"). With the convenience function: if $_gdb_setting("some_setting") some command some other command some different command end Integer settings (for example print elements) will also be more difficult to use. For example, a user defined function that scans and prints a linked list might want to use the value of "set print elements" to stop printing the linked list. Doing that by mixing python expression/if is likely doable, but seems not easy with the above one liners. So, in summary, the $_gdb_setting and $_gdb_setting_str avoids to have the heterogeneous mix of python and GDB commands in one single script (and of course, it works even if python is not configured, but that must be an unusual setup I guess). gdb/ChangeLog 2019-10-31 Philippe Waroquiers <philippe.waroquiers@skynet.be> * cli/cli-cmds.c (setting_cmd, value_from_setting) (gdb_setting_internal_fn, gdb_maint_setting_internal_fn) (str_value_from_setting, gdb_setting_str_internal_fn) (gdb_maint_setting_str_internal_fn): New functions. (_initialize_cli_cmds): Define the new convenience functions. * gdb/cli/cli-setshow.h (get_setshow_command_value_string): Constify. * gdb/cli/cli-setshow.c (get_setshow_command_value_string): Constify.
2019-10-31Don't read agent symbols when disabledChristian Biesinger1-0/+7
This avoids unnecessary work, and becomes important with the patch in https://sourceware.org/ml/gdb-patches/2019-10/msg01143.html gdb/ChangeLog: 2019-10-31 Christian Biesinger <cbiesinger@google.com> * agent.c (set_can_use_agent): When the setting is turned on, look up agent symbols if we don't have them yet. (agent_new_objfile): Don't look up agent symbols when the agent setting is off. Change-Id: I6523a5640c95d38299998050a6c620e51096e8ed
2019-10-31Regenerate config.inChristian Biesinger1-0/+4
I forgot to do this in the last commit (b231e86ac9608056ea837e24d42a878927f5787a) gdb/ChangeLog: 2019-10-31 Christian Biesinger <cbiesinger@google.com> * config.in: Regenerate. Change-Id: I60946ffd853a59469c35f19ef8012ac6ea88a31c
2019-10-31Use strerror_r in safe_strerror if availableChristian Biesinger1-0/+11
Also stores the result in a thread-local static variable and changes the return value to a const char*. This is already important because Guile creates threads and Python can create threads, but with the patch series here: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/176 GDB itself will create threads, too. gdb/ChangeLog: 2019-10-31 Christian Biesinger <cbiesinger@google.com> * configure: Regenerate. * configure.ac: Check for strerror_r. * gdbsupport/common-utils.h (safe_strerror): Change return value to const char * and document that this function is now threadsafe. * gdbsupport/posix-strerror.c (safe_strerror): Make buf thread_local and call strerror_r, if available. * utils.c (perror_string): Update. (print_sys_errmsg): Update. Change-Id: I81048fbaf148035c221c528727f7efe58ba528eb
2019-10-31[ARM] Store exception handling information per-bfd instead of per-objfileLuis Machado1-0/+8
Based on feedback from Tromey, update the use of objfile_key in gdb/arm-tdep.c to use bfd_key instead. That way we don't have to re-create the exception handling data all over again if it was done before for the same BFD. gdb/ChangeLog: 2019-10-31 Luis Machado <luis.machado@linaro.org> * arm-tdep.c (arm_exidx_data_key): Use bfd_key instead of objfile_key. (arm_exidx_new_objfile): Adjust to use objfile->obfd instead of objfile to fetch per-bfd data. (arm_find_exidx_entry): Likewise. Change-Id: Ia7b3208ea8d788414600fa6d770ac76db0562859
2019-10-31Convert int to bool in agent.cChristian Biesinger1-0/+13
Also moves an int declaration inside the for loop. Code cleanup, no change in behavior intended. gdb/ChangeLog: 2019-10-31 Christian Biesinger <cbiesinger@google.com> * gdbsupport/agent.c (debug_agent): Change type to bool. (use_agent): Likewise. (all_agent_symbols_look_up): Likewise. (agent_loaded_p): Change return value to bool. (agent_look_up_symbols): Update. (agent_capability_check): Change return value to bool. * gdbsupport/agent.h (agent_loaded_p): Likewise. (debug_agent): Change type to bool. (use_agent): Likewise. (agent_capability_check): Change return value to bool. gdb/gdbserver/ChangeLog: 2019-10-31 Christian Biesinger <cbiesinger@google.com> * ax.h (debug_agent): Remove duplicate declaration. Change-Id: Icb28a65fcc8c7108bcd59287e6be66bf56f8ccb5
generated by cgit v1.1 at 2024-12-28 19:54:03 +0000