The PE targets don't support mapping symbols and so the disassembler is unable
to correctly output thumb instructions when the input was thumb.
So for testcases that only have thumb output, I have copied them and skipped the
ones for which auto-detection is supposed to work on PE, and added a new one
that will force thumb output. This so that the tests still check the mapping
symbols.
For the tests that switch between thumb and arm in one file I just skip them
entirely on PE targets.
This cleans up the PE GAS testsuite.
gas/
* testsuite/gas/arm/archv6t2-1-pe.d: New test.
* testsuite/gas/arm/archv6t2-1.d: Skip pe.
* testsuite/gas/arm/csdb.d: Skip pe.
* testsuite/gas/arm/sb-thumb1-pe.d: New test.
* testsuite/gas/arm/sb-thumb1.d: Skip pe.
* testsuite/gas/arm/sb-thumb2-pe.d: New test.
* testsuite/gas/arm/sb-thumb2.d: Skip pe.
* testsuite/gas/arm/udf.d: Skip pe.
* objdump.c (disassemble_section): When disassembling from a
symbol only stop at the next symbol if the original symbol was not
a function symbol. Otherwise continue disassembling until a new
function is reached.
* testsuite/binutils-all/objdump.exp: Add tests of extended
functionality.
* testsuite/binutils-all/disasm.s: New test source file.
I applied the patch "Do not expand macros to 'defined'" by hand because
I couldn't apply it with git-am, and of course forgot to remove the
macro definitions. This patch fixes it, and also makes the ChangeLog
entry a bit cleaner.
2019-01-16 Kito Cheng <kito@andestech.com>
bfd/
* elf-attrs.c (vendor_obj_attr_size): Return 0 if size is 0 even
for OBJ_ATTR_PROC.
gas/
* testsuite/gas/riscv/attribute-empty.d: New.
Expanding a macro which contains 'defined' PP keyword is UB. It causes
a compilation failure when -Wexpansion-to-defined is used.
sim/common/Changelog:
2019-01-16 Pavel I. Kryukov <kryukov@frtk.ru>
* sim-arange.c: eliminate DEFINE_NON_INLINE_P
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.
The assembler incorrectly recognised "c" as a register name, and
refused to allow it where it expected a symbol/label.
gas/
* config/tc-s12z.c (lex_reg_name): Compare the length of the strings
before the contents.
* testsuite/gas/s12z/labels.d: New file.
* testsuite/gas/s12z/labels.s: New file.
* testsuite/gas/s12z/s12z.exp: Add them.
Other assemblers permit "extending" a register into a register of a
smaller size or the same size. It doesn't make much sense to do this
but would appear to be a valid instruction. So change the error to a
warning.
gas/
* config/tc-s12z.c (tfr): Change as_bad to as_warn.
Also fix message typo and semantics.
If HAVE_INLINE is false, SIM_ARANGE_INLINE is currently defined as
#define SIM_ARANGE_INLINE EXTERN
However, EXTERN is not defined anywhere, leading to errors such as:
In file included from
/mipt-mips/simulator/../../sim/common/sim-basics.h:147:0,
from /mipt-mips/simulator/export/gdb/sim-main.h:13,
from /mipt-mips/simulator/export/gdb/gdb_interface.cpp:7:
/mipt-mips/simulator/../../sim/common/sim-arange.h:71:27: error: ‘EXTERN’
does not name a type; did you mean ‘EUSERS’?
#define SIM_ARANGE_INLINE EXTERN
^
/mipt-mips/simulator/../../sim/common/sim-arange.h:76:1: note: in expansion
of macro ‘SIM_ARANGE_INLINE’
SIM_ARANGE_INLINE int
^~~~~~~~~~~~~~~~~
I (Simon) have reproduced the problem by simply removing the HAVE_INLINE
definition. This was originally reported by Pavel I. Kryukov
<kryukov@frtk.ru>.
sim/common/ChangeLog:
* sim-arange.h (SIM_ARANGE_INLINE): Change EXTERN to extern.
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.
Include <string.h> to dis-asm.h to get strchr declaration
include/Changelog:
2019-01-11 Pavel I. Kryukov <kryukov@frtk.ru>
* dis-asm.h: include <string.h>
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.
