tui-wingeneral.h uses WINDOW, which is defined by curses. So, include
gdb_curses.h from tui-wingeneral.h.
2019-01-22 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.h: Include gdb_curses.h.
A compile in the TUI somehow had "lines" defined as a macro. This
caused a compile error when including source-cache.h after whatever
header did that. I tracked this down to a #define in
/usr/include/term.h, so I just changed source-cache.h to avoid the
clash.
gdb/ChangeLog
2019-01-22 Tom Tromey <tom@tromey.com>
* source-cache.h (class source_cache) <get_source_lines,
get_plain_source_lines, extract_lines>: Rename "lines" parameter.
remote-fileio.h refers to remote_target, so forward-declare it.
gdb/ChangeLog
2019-01-22 Tom Tromey <tom@tromey.com>
* remote-fileio.h (struct remote_target): Declare.
py-ref.h can really only be included from a specific spot in
python-internal.h. The other includes are not useful, and cause
compilation errors if the includes are ever sorted. So, remove these
includes.
Arguably, py-ref.h should simply not be a separate header.
gdb/ChangeLog
2019-01-22 Tom Tromey <tom@tromey.com>
* python/py-arch.c: Do not include py-ref.h.
* python/py-bpevent.c: Do not include py-ref.h.
* python/py-cmd.c: Do not include py-ref.h.
* python/py-continueevent.c: Do not include py-ref.h.
* python/py-event.h: Do not include py-ref.h.
* python/py-evtregistry.c: Do not include py-ref.h.
* python/py-finishbreakpoint.c: Do not include py-ref.h.
* python/py-frame.c: Do not include py-ref.h.
* python/py-framefilter.c: Do not include py-ref.h.
* python/py-function.c: Do not include py-ref.h.
* python/py-infevents.c: Do not include py-ref.h.
* python/py-linetable.c: Do not include py-ref.h.
* python/py-objfile.c: Do not include py-ref.h.
* python/py-param.c: Do not include py-ref.h.
* python/py-prettyprint.c: Do not include py-ref.h.
* python/py-progspace.c: Do not include py-ref.h.
* python/py-symbol.c: Do not include py-ref.h.
* python/py-symtab.c: Do not include py-ref.h.
* python/py-type.c: Do not include py-ref.h.
* python/py-unwind.c: Do not include py-ref.h.
* python/py-utils.c: Do not include py-ref.h.
* python/py-value.c: Do not include py-ref.h.
* python/py-varobj.c: Do not include py-ref.h.
* python/py-xmethods.c: Do not include py-ref.h.
* python/python.c: Do not include py-ref.h.
* varobj.c: Do not include py-ref.h.
If objfiles.h is included after bcache.h, then the "bcache" function
will cause a compiler error because "bcache" will be seen as a
function, not a type. Fix this error by using the "struct" keyword.
gdb/ChangeLog
2019-01-22 Tom Tromey <tom@tromey.com>
* objfiles.h (struct objfile_per_bfd_storage): Use "struct"
keyword for bcache.
The include sorter can't handle multi-line comments on the same line
as a #include. This patch removes the only such comment.
In general I think these sorts of comments do not provide much value:
more often than not, I find that the comment is obsolete in one way or
another, and so the include sorter removes them in most cases.
gdb/ChangeLog
2019-01-22 Tom Tromey <tom@tromey.com>
* compile/compile-cplus-types.c: Remove a comment by #include.
gcc-c-plugin.h refers to some types defined in compile-internal.h.
This patch changes the former to include the latter.
gdb/ChangeLog
2019-01-22 Tom Tromey <tom@tromey.com>
* compile/gcc-c-plugin.h: Include compile-internal.h.
This removes the EXTERN define from stabsread.h. This is the only
spot that still uses this approach, and it interfered with sorting the
includes in stabsread.c.
Tested by rebuilding.
gdb/ChangeLog
2019-01-22 Tom Tromey <tom@tromey.com>
* stabsread.c (EXTERN): Do not define.
(symnum, next_symbol_text_func, processing_gcc_compilation)
(within_function, global_sym_chain, global_stabs)
(previous_stab_code, this_object_header_files)
(n_this_object_header_files)
(n_allocated_this_object_header_files): Define.
* stabsread.h (EXTERN): Never define. Use "extern".
E.g. in gdb.base/default.exp, valgrind detects leaks such as
==17663== 1,438 bytes in 101 blocks are definitely lost in loss record 2,804 of 2,884
==17663== at 0x4C2BE6D: malloc (vg_replace_malloc.c:309)
==17663== by 0x418A17: xmalloc (common-utils.c:44)
==17663== by 0x4E6F19C: history_expand (histexpand.c:1061)
==17663== by 0x4B4490: handle_line_of_input(buffer*, char const*, int, char const*) (event-top.c:685)
==17663== by 0x4B4562: command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) (event-top.c:753)
...
Fix the leak by using an unique_xmalloc_ptr for history_value.
gdb/ChangeLog
2019-01-22 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* event-top.c (handle_line_of_input): use unique_xmalloc_ptr for
history_value.
When gdb.base/infcall-nested-structs.c is complied as C++, the compiler
will not pass structs containing empty structs via float arguments.
This is because structs in C++ have a minimum size of 1, causing padding
in the struct once compiled. The AAPCS does not allow structs with
padding to be passed in float arguments.
Add padding checks to AArch64 and add C++ compile variant to the test.
Some of the tests fail on X86_64. This has been raised as bug gdb/24104.
gdb/ChangeLog:
* aarch64-tdep.c (aapcs_is_vfp_call_or_return_candidate_1): Check
for padding.
gdb/testsuite/ChangeLog:
* gdb.base/infcall-nested-structs.exp: Test C++ in addition to C.
Using -fstack-protector-strong will cause GDB to break on the wrong line
when placing a breakpoint on a function. This is due to inadequate dwarf
line numbering, and is being tracked by the GCC bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432
GCC (and Clang) provided by Debian/Ubuntu default to stack protector
being enabled.
Ensure that when running the GDB testsuite, stack protector is always
turned off for GCC 4.1.0 (when stack protector was added) and above.
Ensure that this does not cause infinite recursion due to
test_compiler_info having to compile a file itself.
Add a test to explicitly test breakpoints with various levels of stack
protection on both GCC and Clang, with xfail for the known errors.
Restore change in ovldbreak.exp which worked around the issue.
gdb/testsuite/ChangeLog:
2019-01-18 Alan Hayward <alan.hayward@arm.com>
* gdb.base/stack-protector.c: New test.
* gdb.base/stack-protector.exp: New file.
* gdb.cp/ovldbreak.exp: Only allow a single break line.
* lib/gdb.exp (get_compiler_info): Use getting_compiler_info
option.
(gdb_compile): Remove stack protector for GCC and prevent
recursion.
This simplifies the minimal symbol iterator, by using
minimal_symbol_count and just doing a somewhat ordinary array-like
iteration. array_view is nearly usable, except that it is more
convenient for this iterator to return pointers rather than
references.
gdb/ChangeLog
2019-01-16 Tom Tromey <tom@tromey.com>
* objfiles.h (class objfile_msymbols) <iterator>: Change argument
type. Remove no-argument constructor.
<iterator::operator++>: Simplify.
<begin>: Update.
<end>: Use minimal_symbol_count.
This removes the objfile_psymtabs class in favor of a method on
objfile and on psymtab_storage.
2019-01-16 Tom Tromey <tom@tromey.com>
* objfiles.h (struct objfile) <psymtabs>: New method.
(class objfile_psymtabs): Remove.
* psymtab.h (class psymtab_storage) <partial_symtab_range>: New
typedef.
<range>: New method.
(require_partial_symbols): Change return type.
* psymtab.c (require_partial_symbols)
(psym_expand_symtabs_matching): Update.
* mdebugread.c (parse_partial_symbols): Update.
* dbxread.c (dbx_end_psymtab): Update.
This changes the all_objfiles_safe range adapter to be a method on the
program space, and fixes up all the users.
gdb/ChangeLog
2019-01-15 Tom Tromey <tom@tromey.com>
* progspace.h (program_space) <objfiles_safe_range>: New
typedef.
<objfiles_safe>: New method.
* objfiles.h (class all_objfiles_safe): Remove.
* objfiles.c (free_all_objfiles, objfile_purge_solibs): Update.
* jit.c (jit_inferior_exit_hook): Update.
This removes the remaining cleanups from solib-target.c, plus a VEC,
by using std::vector and std::unique_ptr.
Tested by the buildbot.
gdb/ChangeLog
2019-01-17 Tom Tromey <tom@tromey.com>
* solib-target.c (lm_info_target_p): Remove typedef. Don't
declare VEC.
(solib_target_parse_libraries): Change return type.
(library_list_start_segment, library_list_start_section)
(library_list_end_library, library_list_start_library); Update.
(solib_target_free_library_list): Remove.
(solib_target_parse_libraries): Remove cleanup. Change return
type.
(solib_target_current_sos): Update.
This replaces "the the" with "the" in various comments.
Tested by rebuilding. This didn't test the solib-dsbt.c change, but
it looks harmless.
gdb/ChangeLog
2019-01-17 Tom Tromey <tromey@bapiya>
* valprint.c: Replace "the the" with "the".
* symtab.c: Replace "the the" with "the".
* solib.c: Replace "the the" with "the".
* solib-dsbt.c: Replace "the the" with "the".
* linespec.c: Replace "the the" with "the".
* dwarf2loc.h: Replace "the the" with "the".
* amd64-windows-tdep.c: Replace "the the" with "the".
* aarch64-tdep.c: Replace "the the" with "the".
This patch is an attempt to deal with a variety of bugs reported where
GDB segfaults attempting to access a dwarf2_cu's builder. In certain
circumstances, this builder can be NULL. This is especially common
when inheriting DIEs via inlined subroutines in other CUs. The test
case demonstrates one such situation reported by users. See gdb/23773,
rhbz1638798, and dups for other concrete examples.
The approach taken here is to save the ancestor CU into the dwarf2_cu of
all CUs with DIEs that are "imported." This can happen whenever
follow_die_offset and friends are called. This essentially introduces a
chain of CUs that caused the importation of a DIE from a CU. Whenever
a builder is requested of a CU that has none, the ancestors are searched
for the first one with a builder.
A design side effect of this is that the builder can now only be
accessed by getter and setter methods because the builder itself
is private.
The bulk of the patch is relatively mindless text conversion from
"cu->builder" to "cu->get_builder ()". I've included one test which
was derived from one (of the many) bugs reported on the issue in both
sourceware and Fedora bugzillas.
gdb/ChangeLog:
PR gdb/23773
* dwarf2read.c (dwarf2_cu) <ancestor>: New field.
<builder>: Rename to ..
<m_builder>: ... this and make private.
(dwarf2_cu::get_builder): New method. Change all users of
`builder' to use this method.
(dwarf2_start_symtab): Move to ...
(dwarf2_cu::start_symtab): ... here. Update all callers
(setup_type_unit_groups): Move to ...
(dwarf2_cu::setup_type_unit_groups): ... here. Update all
callers.
(dwarf2_cu::reset_builder): New method.
(process_full_compunit, process_full_type_unit): Use
dwarf2_cu::reset_builder.
(follow_die_offset): Record the ancestor CU if it is different
from the followed DIE's CU.
(follow_die_sig_1): Likewise.
gdb/testsuite/ChangeLog:
PR gdb/23773
* gdb.dwarf2/inlined_subroutine-inheritance.exp: New file.
This patch adds a table summarizing the history or MI versions:
- The version number
- Which GDB version introduced it
- Breaking changes compared to the previous version
The goal of the table is to help writers of front ends know which
version of MI they can use with a given GDB version. It will also help
them update their code to work against a newer MI version.
Right now, we just have 1 and 2, but we expect to add an entry for 3
soon. I did a bit of archelogy and reverse engineering of the code to
come up with the breaking changes for MI 2.
I did some changes to the text around it, some things that I thought
needed to be clarified, seemed a bit dated or seemed just wrong
(especially "Apart from mi0, new versions of @value{GDBN} will not
support old versions of MI").
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Development and Front Ends): Add table of
MI versions. Update text around it.
This removes the remaining cleanup from remote.c, by changing
remote_state::buf to be a gdb::char_vector, and then fixing up all the
fallout. The resulting patch is somewhat ugly, but on the other hand,
it eliminates some possibilities for mistakes.
Regression tested using the
Fedora-x86_64-native-extended-gdbserver-m64 builder on the buildbot.
gdb/ChangeLog
2019-01-15 Tom Tromey <tom@tromey.com>
* remote.c (class remote_state) <buf>: Now a char_vector.
<buf_size>: Remove.
(remote_target::getpkt): Change type of buf. Remove sizeof_buf
parameter.
(remote_target::getpkt_or_notif_sane_1)
(remote_target::getpkt_sane)
(remote_target::getpkt_or_notif_sane): Likewise.
(class remote_target) <putpkt>: New overload.
(remote_target::read_frame): Change type of "buf_p". Remove
sizeof_p parameter.
(packet_ok): New overload.
(packet_check_result): New overload.
Update all uses.
This constifies the "buf" arguments to various remote-notif functions
and updates the users.
gdb/ChangeLog
2019-01-14 Tom Tromey <tom@tromey.com>
* remote-notif.c (handle_notification, remote_notif_ack)
(remote_notif_parse): Make "buf" const.
* remote-notif.h (struct notif_client) <parse, ack>: Make "buf"
const.
(remote_notif_parse, remote_notif_ack, handle_notification):
Likewise.
* remote.c (remote_notif_stop_parse): Make "buf" const.
(remote_target::remote_parse_stop_reply): Make "buf" const.
(remote_notif_stop_ack): Make "buf" const.
This constifies the parameter to remote_console_output.
gdb/ChangeLog
2019-01-14 Tom Tromey <tom@tromey.com>
* remote.c (remote_console_output): Make parameter const.
This constifies the final parameter to target_pass_signals and
target_program_signals and updates the rest of gdb.
Note that I have no way to test the nto-procfs.c change.
gdb/ChangeLog
2019-01-14 Tom Tromey <tom@tromey.com>
* target-debug.h (target_debug_print_signals): Constify.
* nto-procfs.c (nto_procfs_target::pass_signals): Update.
* procfs.c (procfs_target::pass_signals): Update.
* linux-nat.c (linux_nat_target::pass_signals): Update.
* linux-nat.h (class linux_nat_target) <pass_signals>: Update.
* target-delegates.c: Rebuild.
* remote.c (remote_target::program_signals): Update.
(remote_target::pass_signals): Update.
* target.c (target_pass_signals): Constify argument.
(target_program_signals): Likewise.
* target.h (struct target_ops) <pass_signals, program_signals>:
Constify argument.
(target_pass_signals, target_program_signals): Constify argument.
The fix for PR tui/28819 regressed gdb command output a bit. In
"nonl" mode, pressing the Enter key will result in a newline not being
echoed properly, so that gdb output for the command will begin on the
same line as the input.
This patch changes gdb_wgetch to echo the newline. I have only tested
this interactively, as the TUI doesn't have automated tests in
general.
gdb/ChangeLog
2019-01-14 Tom Tromey <tom@tromey.com>
PR tui/28819:
* tui/tui-io.c (gdb_wgetch): Print \r when needed.
This patch defines pseudo-registers "v0" through "v31" as aliases that
map to the corresponding raw "vr0" through "vr31" vector registers for
Power.
The motivation behind this is that although GDB defines these
registers as "vrX", the disassembler prints them as "vX", e.g. as the
operands in instructions such as "vaddubm v2,v1,v1". This can be
confusing to users trying to print out the values of the operands
while inspecting the disassembled code.
The new aliases are made not to belong to any register group, to avoid
duplicated values in "info register vector" and "info register all".
The arch-specific rs6000_pseudo_register_reggroup_p function had
previously been removed since the other pseudo-registers could have
their groups inferred by their type. It restored with this patch to
handle the aliases. Membership for the other pseudo-registers is
still determined using the default function.
A new tests checks that GDB prints the expected values of vector
registers after they are filled by the inferior, by using both the raw
names and the aliases. Two other existing tests are modified to also
test the aliases.
gdb/ChangeLog:
2019-01-14 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* ppc-tdep.h (struct gdbarch_tdep) <ppc_v0_alias_regnum>: New
field.
* rs6000-tdep.c: Include reggroups.h.
(IS_V_ALIAS_PSEUDOREG): Define.
(rs6000_register_name): Return names for the "vX" aliases.
(rs6000_pseudo_register_type): Return type for the "vX" aliases.
(rs6000_pseudo_register_reggroup_p): Restore. Handle "vX"
aliases. Call default_register_reggroup_p for all other
pseudo-registers.
(v_alias_pseudo_register_read, v_alias_pseudo_register_write):
New functions.
(rs6000_pseudo_register_read, rs6000_pseudo_register_write):
Handle "vX" aliases.
(v_alias_pseudo_register_collect): New function.
(rs6000_ax_pseudo_register_collect): Handle "vX" aliases.
(rs6000_gdbarch_init): Initialize "vX" aliases as
pseudo-registers. Restore registration of
rs6000_pseudo_register_reggroup_p with
set_tdesc_pseudo_register_reggroup_p.
gdb/testsuite/ChangeLog:
2019-01-14 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* gdb.arch/vsx-regs.exp: Add tests that use the vector register
aliases.
* gdb.arch/altivec-regs.exp: Likewise. Fix indentation of two
tests.
* gdb.arch/powerpc-vector-regs.c: New file.
* gdb.arch/powerpc-vector-regs.exp: New file.
gdb/doc/ChangeLog:
2019-01-14 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* gdb.texinfo (PowerPC Features): Document the alias
pseudo-registers for the org.gnu.gdb.power.altivec feature.
This patch fixes one of the tests in gdb.arch/altivec-regs.exp that
was passing an incorrect list to gdb_expect_list, which always
matched.
gdb/testsuite/ChangeLog:
2019-01-14 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* gdb.arch/altivec-regs.exp: Fix the list passed to
gdb_expect_list when testing "info vector".
Commit 37d9e06231 ("gdb: xtensa: handle privileged registers") changed
how the tdep->num_regs and tdep->num_pseudo_regs are calculated, but
didn't update these numbers in the gdbarch for the xtensa-linux target.
As a result xtensa-linux-gdb behaves as xtensa-elf-gdb and cannot
communicate with the linux gdbserver.
Fix tdep->num_pseudo_regs calculation and call set_gdbarch_num_regs and
set_gdbarch_num_pseudo_regs in xtensa_linux_init_abi.
gdb/
2019-01-13 Max Filippov <jcmvbkbc@gmail.com>
* xtensa-linux-tdep.c (xtensa_linux_init_abi): Update
tdep->num_pseudo_regs. Add calls to set_gdbarch_num_regs and
set_gdbarch_num_pseudo_regs.
Currently, the behaviour is:
(gdb) show style
(gdb) set style
(gdb) show style address
(gdb) set style address
(gdb)
With this patch, the behaviour is:
(gdb) show style
style address background: The "address" background color is: none
style address foreground: The "address" foreground color is: blue
style address intensity: The "address" display intensity is: normal
enabled: CLI output styling is enabled.
style filename background: The "filename" background color is: none
style filename foreground: The "filename" foreground color is: green
style filename intensity: The "filename" display intensity is: normal
style function background: The "function" background color is: none
style function foreground: The "function" foreground color is: yellow
style function intensity: The "function" display intensity is: normal
style variable background: The "variable" background color is: none
style variable foreground: The "variable" foreground color is: cyan
style variable intensity: The "variable" display intensity is: normal
(gdb) set style
"set style" must be followed by an appropriate subcommand.
List of set style subcommands:
set style address -- Address display styling
set style enabled -- Set whether CLI styling is enabled
set style filename -- Filename display styling
set style function -- Function name display styling
set style variable -- Variable name display styling
Type "help set style" followed by set style subcommand name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb) show style address
background: The "filename" background color is: none
foreground: The "filename" foreground color is: green
intensity: The "filename" display intensity is: normal
(gdb) set style address
List of set style address subcommands:
set style address background -- Set the background color for this property
set style address foreground -- Set the foreground color for this property
set style address intensity -- Set the display intensity color for this property
Type "help set style address" followed by set style address subcommand name for full documentation.
Type "apropos word" to search for commands related to "word".
Command name abbreviations are allowed if unambiguous.
(gdb)
gdb/ChangeLog
* cli/cli-style.h (class cli_style_option): <add_setshow_commands>
Remove arg prefixname, add do_set and do_show.
Add member functions set_list and show_list.
* cli/cli-style.c (class cli_style_option): Update accordingly.
(style_set_list): Move to file scope.
(style_show_list): Likewise.
(set_style): Call help_list.
(show_style): Call cmd_show_list.
(_initialize_cli_style): New macro STYLE_ADD_SETSHOW_COMMANDS.
Update to use the new macro.
One of our users remarked that the help doesn't mention the fact that
the "catch exception" supports the special argument "unhandled" to catch
exceptions which do not have a handler. This patch changes the output
of...
| (gdb) help catch exception
| Catch Ada exceptions, when raised.
| With an argument, catch only exceptions with the given name.
... to ...
| (gdb) help catch exception
| Catch Ada exceptions, when raised.
| Usage: catch exception [ ARG ]
|
| Without any argument, stop when any Ada exception is raised.
| If ARG is "unhandled" (without the quotes), only stop when the exception
| being raised does not have a handler (and will therefore lead to the task's
| termination).
| Otherwise, the catchpoint only stops when the name of the exception being
| raised is the same as ARG.
gdb/ChangeLog:
* ada-lang.c (_initialize_ada_language): Expand the help text
for the "catch exception" command.
Tested on x86_64-linux, no regression.
Having paths in the test names makes it harder to compare results
between two runs in different directories. Give the test a name so
that the path doesn't appear.
gdb/ChangeLog:
* gdb.base/style.exp: Don't include path in testname.
Fix warning:
gdb/symtab.c: In function ‘int matching_obj_sections(obj_section*, obj_section*)’:
gdb/symtab.c:1024:12: warning: ‘obj’ may be used uninitialized in this function [-Wmaybe-uninitialized]
if (obj->separate_debug_objfile_backlink != NULL
2019-01-12 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* symtab.c (matching_obj_sections): Initialize obj,
declare it closer to its usage.
This changes inf_threads_iterator and some range adapters in
thread-iter.h to use next_iterator and next_adapter instead.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* thread-iter.h (inf_threads_iterator): Use next_iterator.
(basic_inf_threads_range): Remove.
(inf_threads_range, inf_non_exited_threads_range)
(safe_inf_threads_range): Use next_adapter.
This is a test derived from one of the reproducers in symtab/23010.
The DIE tree used here is typical of compilations with LTO, where an
artificial parent DIE of language C99 imports DIEs of other languages.
gdb/testsuite/ChangeLog:
PR gdb/23712
PR symtab/23010
* gdb.dwarf2/multidictionary.exp: New file.
Finally, we can remove dw2_add_symbol_to_list since the wrapper function
originally introduced to catch this multi-language scenario is no longer
needed. With multi-language dictionaries, we can now support adding
symbols of multiple languages, negating the need for the assertion
entirely.
This patch should now fix gdb/23712 (and symtab/23010). At least it will
if the NULL buildsym_compunit problem doesn't strike first (see gdb/23773).
gdb/ChangeLog:
PR gdb/23712
PR symtab/23010
* dwarf2read.c (dw2_add_symbol_to_list): Remove.
(fixup_go_packaging, new_symbol): Use add_symbol_to_list.
Now that multidictionary's are being used, there is no longer any need
to retain the four temporary functions introduced in the beginning of
this series.
This patch removes them.
As an additional cleanup, since the single-language dictionaries are
no longer used outside dictionary.c, make all of those functions
static.
gdb/ChangeLog:
PR gdb/23712
PR symtab/23010
* dictionary.c (pending_to_vector): Remove.
(dict_create_hashed_1, dict_create_linear_1, dict_add_pending_1):
Remove _1 suffix, replacing functions of the same name. Update
all callers.
(dict_create_hashed, dict_create_hashed_expandable)
(dict_create_linear, dict_create_linear_expandable, dict_free)
(dict_add_symbol, dict_add_pending, dict_size, dict_empty):
Make functions static.
This patch builds on the previous by enabling the `new' multidictionary
API. A lot of the hunks are simply textual replacements of "dict_"
with "mdict_" and similar transformations.
A word of warning, even with the use of multidictionaries, the code
still does not satisfactorily fix the reported problems with gdb/23712
(or gdb/23010). We still have additional changes to make before that
happens.
gdb/ChangeLog:
PR gdb/23712
PR symtab/23010
* dictionary.h (struct dictionary): Replace declaration with
multidictionary.
(dict_create_hashed, dict_create_hashed_expandable)
(dict_create_linear, dict_create_linear_expandable)
(dict_free, dict_add_symbol, dict_add_pending, dict_empty)
(dict_iterator_first, dict_iterator_next, dict_iter_match_first)
(dict_iter_match_next, dict_size): Rename to "mdict_" versions
taking multidictionary argument.
[ALL_DICT_SYMBOLS]: Update for multidictionary.
* block.h (struct block) <dict>: Change to multidictionary
and rename `multidict'.
* block.c, buildsym.c, jit.c, mdebugread.c, objfiles.c,
symmisc.c: Update all dictionary references to multidictionary.
gdb/23712 is a new manifestation of the now-infamous (at least to me)
symtab/23010 assertion failure (DICT_LANGUAGE == SYMBOL_LANGAUGE).
An example of the problem (using test case from symtab/23010):
Reading symbols from /home/rdiez/rdiez/arduino/JtagDue/BuildOutput/JtagDue-obj-release/firmware.elf...done.
(gdb) p SysTick_Handler
dwarf2read.c:9715: internal-error: void dw2_add_symbol_to_list(symbol*, pending**): Assertion `(*listhead) == NULL || (SYMBOL_LANGUAGE ((*listhead)->symbol[0]) == SYMBOL_LANGUAGE (symbol))' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This assertion was added specifically to catch this condition (of adding
symbols of different languages to a single pending list).
The problems we're now seeing on systems utilizing DWARF debugging seem to
be caused by the use of LTO, which adds a CU with an artificial DIE of
language C99 which references DIEs in other CUs of language C++.
Thus, we create a dictionary containing symbols of C99 but end up
stuffing C++ symbols into it, and the dw2_add_symbol_to_list triggers.
The approach taken here to fix this is to introduce multi-language
dictionaries to "replace" the standard, single-language dictionaries
used today.
Note to reviewers: This patch introduces some temporary functions to
aide with review. This and other artifacts (such as "See dictionary.h"
which appear incorrect) will all be valid at the end of the series.
This first patch introduces the new multidictionary and its API (which
is, by design, identical to the old dictionary interface). It also
mutates dict_create_hashed and dict_create_linear so that they take
a std::vector instead of the usual struct pending linked list. This will
be needed later on.
This patch does /not/ actually enable multidictionary's. That is left
for a subsequent patch in the series.
I've done exhaustive performance testing with this approach, and I've
attempted to minimize the overhead for the (overwhelmingly) most common
one-language scenario.
On average, a -g3 -O0 GDB (the one we developers use) will see
approximately a 4% slowdown when initially reading symbols. [I've
tested only GDB and firefox with -readnow.] When using -O2, this
difference shrinks to ~0.5%. Since a number of runs with these
patches actually run /faster/ than unpatched GDB, I conclude that
these tests have at least a 0.5% error margin.
On our own gdb.perf test suite, again, results appear to be pretty
negligible. Differences to unpatched GDB range from -7.8% (yes,
patched version is again faster than unpatched) to 27%. All tests
lying outside "negligible," such as the 27% slowdown, involve a total
run time of 0.0007 (or less) with smaller numbers of CUs/DSOs (usually 10
or 100). In all cases, the follow-up tests with more CUs/DSOs is never
more than 3% difference to the baseline, unpatched GDB.
In my opinion, these results are satisfactory.
gdb/ChangeLog:
PR gdb/23712
PR symtab/23010
* dictionary.c: Include unordered_map.
(pending_to_vector): New function.
(dict_create_hashed_1, dict_create_linear_1, dict_add_pending_1):
Rewrite the non-"_1" functions to take vector instead
of linked list.
(dict_create_hashed, dict_create_linear, dict_add_pending): Use the
"new" _1 versions of the same name.
(multidictionary): Define.
(std::hash<enum language): New definition.
(collate_pending_symbols_by_language, mdict_create_hashed)
(mdict_create_hashed_expandable, mdict_create_linear)
(mdict_create_linear_expandable, mdict_free)
(find_language_dictionary, create_new_language_dictionary)
(mdict_add_symbol, mdict_add_pending, mdict_iterator_first)
(mdict_iterator_next, mdict_iter_match_first, mdict_iter_match_next)
(mdict_size, mdict_empty): New functions.
* dictionary.h (mdict_iterator): Define.
Coverity points out that gdb/tracepoint.c:parse_tracepoint_definition
can leak 'cond' in this line:
cond = (char *) xmalloc (2 * xlen + 1);
That can leak because we're in a loop and 'cond' may have already been
xmalloc'ed into in a previous iteration. That won't normally happen,
because we don't expect to see a tracepoint definition with multiple
conditions listed, but, it doesn't hurt to be pedantically correct,
in case some stub manages to send something odd back to GDB.
At first I thought I'd just replace the xmalloc call with:
cond = (char *) xrealloc (cond, 2 * xlen + 1);
and be done with it. However, my pedantic self realizes that
warning() can throw as well (due to pagination + Ctrl-C), so I fixed
it using gdb::unique_xmalloc_ptr instead.
While doing this, I noticed that these vectors in struct uploaded_tp:
std::vector<char *> actions;
std::vector<char *> step_actions;
hold heap-allocated strings, but nothing is freeing the strings,
AFAICS.
So I ended up switching all the heap-allocated strings in uploaded_tp
to unique pointers. This patch is the result of that.
I also wrote an alternative, but similar patch that uses std::string
throughout instead of gdb::unique_xmalloc_ptr, but in the end reverted
it because the code didn't look that much better, and I kind of
dislike replacing pointers with fat std::string's (3 or 4 times the
size of a pointer) in structures.
gdb/ChangeLog:
2019-01-10 Pedro Alves <palves@redhat.com>
* breakpoint.c (read_uploaded_action)
(create_tracepoint_from_upload): Adjust to use
gdb::unique_xmalloc_ptr.
* ctf.c (ctf_write_uploaded_tp):
(SET_ARRAY_FIELD): Use emplace_back.
(SET_STRING_FIELD): Adjust to use gdb::unique_xmalloc_ptr.
* tracefile-tfile.c (tfile_write_uploaded_tp):
* tracepoint.c (parse_tracepoint_definition): Adjust to use
gdb::unique_xmalloc_ptr.
* tracepoint.h (struct uploaded_tp) <cond, actions, step_actions,
at_string, cond_string, cmd_strings>: Replace char pointers
with gdb::unique_xmalloc_ptr.
lm_info_target::name is nowadays std::string, so we're leaking the
result of xstrdup.
gdb/ChangeLog:
2019-01-10 Pedro Alves <palves@redhat.com>
* solib-target.c (library_list_start_library): Don't xstrdup name.
Coverity points out that all the "continue;" statements in the switch
case in parse_partial_symbols leak STABSTRING. This is because we
only release STABSTRING at the end of the scope, with:
if (stabstring
&& stabstring != debug_info->ss + fh->issBase + sh.iss)
xfree (stabstring);
but that bit of code is skipped if a case in the switch statement ends
with "continue".
Fix this by using gdb::unique_xmalloc_ptr to manage the heap-allocated
version of 'stabsstring'.
I don't know how to test this.
gdb/ChangeLog:
2019-01-10 Pedro Alves <palves@redhat.com>
* mdebugread.c (parse_partial_symbols): Use
gdb::unique_xmalloc_ptr to manage heap-allocated 'stabsstring'.
The previous commit:
commit 1ef8573cc7
Date: Wed Jan 9 14:02:39 2019 +0000
gdb: Improve scoped_switch_fork_info class
contained a bug, an incorrect variable name was used. Fixed in this
commit.
gdb/ChangeLog:
* linux-fork.c (scoped_switch_fork_info)
<~scoped_switch_fork_info>: Fix incorrect variable name.
After committing this patch I got this feedback:
https://sourceware.org/ml/gdb-patches/2019-01/msg00181.html
This patch makes the constructor of scoped_switch_fork_info explicit,
and wraps the core of the destructor in a TRY/CATCH block.
I've run this through the testsuite on X86-64/GNU Linux, however, this
code is not exercised, so this patch is untested.
gdb/ChangeLog:
* linux-fork.c (scoped_switch_fork_info)
<scoped_switch_fork_info>: Make explicit.
<~scoped_switch_fork_info>: Wrap core in TRY/CATCH.
Previously, the psymtab obstack was just a pointer to the objfile
obstack. This patch changes psymtabs to use their own obstack,
instead. A gdb::optional is used to avoid unnecessary allocation when
the obstack is not needed.
After this patch, the psymtab code lifetime model is that, in the core
psymtab code, objects allocated on the psymtab obstack may point to
other such objects, or to objects on the per-BFD obstack -- but never
to the objfile obstack.
Note however that this invariant is only obeyed the core psymtab code,
and even there not quite fully: there is still a link from the psymtab
to the full symtab.
Symbol readers are free to work however they like; and in particular,
even after this patch, in practice all symbol readers violate this
invariant via the read_symtab_private field.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* objfiles.h (objfile::reset_psymtabs): Update.
* objfiles.c (objfile::objfile): Update.
* psymtab.h (psymtab_storage::obstack): Update.
(psymtab_storage::m_obstack): Use gdb::optional.
(class psymtab_storage): Update comment. Remove objfile
parameter.
* psymtab.c (psymtab_storage::psymtab_storage): Update.
This adds a new psymtab allocation method to psymtab_storage and
changes the free_psymtabs member to be private. While not strictly
necessary, this seems like a decent cleanup, and also makes it simpler
to move psymtabs off of obstacks entirely, should that prove
desirable.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* psymtab.h (psymtab_storage::allocate_psymtab): New method.
<free_psymtabs>: Now private.
* psymtab.c (psymtab_storage::allocate_psymtab): Implement.
(allocate_psymtab): Use new method.
This adds a new method to psymtab_storage to allocate storage for
psymtab dependencies, then changes the symbol readers to use it. This
has the effect of moving the storage to the psymtab storage obstack.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_end_psymtab): Use allocate_dependencies.
* psymtab.h (psymtab_storage::allocate_dependencies): New method.
* mdebugread.c (parse_partial_symbols): Use
allocate_dependencies.
* dwarf2read.c (dwarf2_create_include_psymtab): Use
allocate_dependencies.
(process_psymtab_comp_unit_reader)
(build_type_psymtab_dependencies): Likewise.
* dbxread.c (dbx_end_psymtab): Use allocate_dependencies.
This moves a couple more psymtab-related allocations to the psymtab
obstack.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* psymtab.c (add_psymbol_to_bcache): Pass psymtab obstack to
PSYMBOL_SET_LANGUAGE.
(allocate_psymtab): Allocate psymtab on the psymtab obstack.
After this patch, the psymtab address map will now be allocated on the
psymtab obstack rather than the objfile obstack. This also changes
the psymtab storage object to make the obstack private; this will be
used later.
gdb/ChangeLog
2019-01-10 Tom Tromey <tom@tromey.com>
* psymtab.h (psymtab_storage::obstack): New method.
<m_obstack>: Rename from obstack; now private.
* psymtab.c (psymtab_storage): Update.
* dwarf2read.c (create_addrmap_from_index)
(create_addrmap_from_aranges, dwarf2_build_psymtabs_hard):
Update.
Tom Tromey
Philippe Waroquiers
Alan Hayward
Keith Seitz
Simon Marchi
Pedro Franco de Carvalho
Max Filippov
Joel Brobecker
Andrew Burgess
Pedro Alves