I think it would be clearer to not use gen_ret_current_ui_field_ptr to
generate the implementation of current_ui_gdb_stdout_ptr et al. It
doesn't save much code, but adds a layer of complexity for the reader.
Plus, it doesn't work well with IDEs, for example if you ask to find all
usages the m_gdb_stdout field.
gdb/ChangeLog:
* top.c (current_ui_gdb_stdout_ptr): Spell out by hand.
(current_ui_gdb_stdin_ptr): Likewise.
(current_ui_gdb_stderr_ptr): Likewise.
(current_ui_gdb_stdlog_ptr): Likewise.
(current_ui_current_uiout_ptr): Likewise.
(gen_ret_current_ui_field_ptr): Remove.
Change-Id: I86f821c9d119453701caedf0e47124ccddfbab2d
The problem reported in PR mi/25055 is that the output of the backtrace
command, when executed as breakpoint command does not show when executing
using the MI interpreter:
...
$ gdb a.out
Reading symbols from a.out...
(gdb) break main
Breakpoint 1 at 0x4003c0: file test.c, line 19.
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>bt
>end
(gdb) interpreter-exec mi "-exec-run"
^done
Breakpoint 1, main () at test.c:19
19 return foo (4);
(gdb)
...
Interestingly, the function print_frame is called twice during -exec-run:
- once during tui_on_normal_stop where the ui_out is temporarily set to
tui->interp_ui_out (), resulting in the part after the comma in
"Breakpoint 1, main () at test.c:19"
- once during execute_control_command, where the ui_out is the default for the
current interpreter: mi_ui_out, which ignores calls to output text.
The commit 3a87ae656c2 "Use console uiout when executing breakpoint commands"
fixes the problem by temporarily switching to the ui_out of INTERP_CONSOLE in
execute_control_command.
This however caused a regression in redirection (escaping '#' using '\' for
git commit message convenience):
...
$ rm -f gdb.txt; gdb a.out
Reading symbols from a.out...
(gdb) break main
Breakpoint 1 at 0x4003c0: file test.c, line 19.
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>bt
>end
(gdb) set logging redirect on
(gdb) set logging on
Redirecting output to gdb.txt.
Copying debug output to gdb.txt.
(gdb) run
\#0 main () at test.c:19
(gdb) q
A debugging session is active.
Inferior 1 [process 22428] will be killed.
Quit anyway? (y or n) y
$ cat gdb.txt
Starting program: /data/gdb_versions/devel/a.out
Breakpoint 1, main () at test.c:19
19 return foo (4);
...
The problem is that the '#0 main () at test.c:19' ends up in the gdb output
output rather than in gdb.txt. This is due to the fact that the redirect is
setup for the current ui_out (which is tui->interp_ui_out ()), while the
backtrace output is printed to the INTERP_CONSOLE ui_out.
Fix this by limiting switching to INTERP_CONSOLE ui_out to when INTERP_MI is
active.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-11-21 Tom de Vries <tdevries@suse.de>
PR gdb/24956
* cli/cli-script.c (execute_control_command): Only switch to
INTERP_CONSOLE's ui_out when INTERP_MI is active.
gdb/testsuite/ChangeLog:
2019-11-21 Tom de Vries <tdevries@suse.de>
PR gdb/24956
* gdb.base/ui-redirect.exp: Test output of user-defined command.
Change-Id: Id1771e7fcc9496a7d97ec2b2ea6b1487596f1ef7
Commit 33d569b709886a1208145806da80b689d9cae9da ("gdb/python: Return
None from Progspace.block_for_pc on error") added a few tests on
gdb.python/py-progspace.exp which use 'print', but forgot to use
parentheses when passing the arguments to be printed. This fails on
Python 3.
This commit adds these missing parentheses. Pushed as obvious.
gdb/testsuite/ChangeLog:
2019-11-20 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.python/py-progspace.exp: Add missing parentheses on some
'print' commands.
Change-Id: Iac0a7578855d128bbee3b98e7ea5888dae55fc00
The current code checks for the presence of a SVE target description by
comparing the number of registers. This is a bit fragile since the number
of registers can change whenever we add new sets. Like PAC, for example.
If the comparison breaks, then we're left with SVE registers in the
description, but gdbserver doesn't send the registers to GDB, which in
turn displays stale information to the user.
The following patch changes the check to use the SVE feature string instead,
which hopefully should be more stable.
gdb/gdbserver/ChangeLog:
2019-11-20 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-low.c (is_sve_tdesc): Check against target feature
instead of register count.
* tdesc.c (tdesc_contains_feature): New function.
* tdesc.h (tdesc_contains_feature): New prototype.
Change-Id: I28b782cb1677560ca9a06a1be442974b25aabae4
The "winheight" command is broken. I probably broke it in one of my
TUI refactoring patches, though I didn't track down exactly which one.
The bug is that the code does:
*buf_ptr = '\0';
... but then never advances buf_ptr past this point, so no window name
is seen.
This patch refactors the code a bit so that a copy of the argument
string is not needed, also fixing the bug.
A new test case is included.
gdb/ChangeLog
2019-11-19 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_partial_win_by_name): Move from tui-data.c.
Now static. Change type of "name".
(tui_set_win_height_command): Don't copy "arg".
* tui/tui-data.h (tui_partial_win_by_name): Don't declare.
* tui/tui-data.c (tui_partial_win_by_name): Move to tui-win.c.
gdb/testsuite/ChangeLog
2019-11-19 Tom Tromey <tom@tromey.com>
* gdb.tui/winheight.exp: New file.
Change-Id: I0871e93777a70036dbec9c9543f862f42e3a81e5
When DebugActiveProcess fails, the error message is fairly generic:
error (_("Can't attach to process."));
It would be more useful for diagnosing problems if the Windows error
code was included in the message. This patch implements this.
gdb/ChangeLog
2019-11-19 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat_target::attach): Include GetLastError
result in error when DebugActiveProcess fails.
Change-Id: Ie1bf502a0d96bb7c09bd5b1c5e0c924ba58cd68c
The recently added gdb.base/ctf-whatis.exp test is a slightly modified
version of gdb.base/whatis.exp, with a few tests removed, and the
source compiled with different compiler options. This patch merges
the two tests together into a single test script.
I tested using a version of GCC with CTF support added.
gdb/testsuite/ChangeLog:
* gdb.base/ctf-whatis.c: Delete.
* gdb.base/ctf-whatis.exp: Delete.
* gdb.base/whatis.exp: Rewrite to compile as both dwarf and ctf.
Change-Id: I09e11c70f197b79d2b1e0ae8c86a21c622be6c51
The recently added gdb.base/ctf-cvexpr.exp is just a copy of
gdb.base/cvexpr.exp but compiled with different options. This patch
merges these two tests together into a single test script.
I tested this change using a version of GCC with CTF support added.
gdb/testsuite/ChangeLog:
* gdb.base/ctf-cvexpr.exp: Delete.
* gdb.base/cvexpr.exp: Rewrite to compile as both dwarf and ctf.
Change-Id: If678c3e38cb444867defa970203d26563f15dba4
Most versions of GCC in the wild don't support CTF debug format right
now, so, rather than attempting to compile the tests and failing each
time, this patch introduces a guard function to check if the compiler
supports CTF. If we don't have CTF support then the CTF tests are
skipped.
This patch only updates 3 of the 4 CTF tests, the fourth will be
handled in the next patch.
gdb/testsuite/ChangeLog:
* gdb.base/ctf-constvars.exp: Skip test if CTF is not supported in
the compiler. Clean up header comment a little.
* gdb.base/ctf-ptype.exp: Likewise.
* gdb.base/ctf-whatis.exp: Likewise.
* lib/gdb.exp (skip_ctf_tests): New proc.
Change-Id: I505c11169a9bc9871a31fc0c61e119f92f32cc63
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
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.
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
This adds some documentation for the operate-and-get-next readline
function that gdb supplies. The text is largely taken from the Bash
manual.
gdb/doc/ChangeLog
2019-11-11 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Editing): Document operate-and-get-next.
Change-Id: I9adb16d9ce84bfbda5fe8a2828f668ea878c080c
A user on irc noticed that the remote protocol documentation mentioned
"vFile:write" -- but this is a typo, there is only "vFile:pwrite".
This patch fixes the bug. Tested by rebuilding, committing as
obvious.
gdb/doc/ChangeLog
2019-11-11 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Host I/O Packets): Fix typo in "vFile:pwrite".
Change-Id: I2f668a691eed7883ba6bc092471739f44c82301b
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
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
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
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
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
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
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
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
Add a script that takes a list of files as arguments and output a list of
words from the C comments with their frequencies.
For:
...
$ ./gdb/contrib/words.sh $(find gdb -type f -name "*.c" -o -name "*.h")
...
it generates a list of ~15000 words prefixed with frequency.
This could be used to generate a dictionary that is kept as part of the
sources, against which new code can be checked, generating a warning or
error. The hope is that misspellings would trigger this frequently, and rare
words rarely, otherwise the burden of updating the dictionary would be too
much.
And for:
...
$ ./gdb/contrib/words.sh -f 1 $(find gdb -type f -name "*.c" -o -name "*.h")
...
it generates a list of ~5000 words with frequency 1.
This can be used to scan for misspellings manually.
Change-Id: I7b119c9a4519cdbf62a3243d1df2927c80813e8b
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
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
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
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
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
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
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
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
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.
