Instead of using SYMBOL_LANGUAGE (sym) = foo.
Having only a single way to set a symbol's language is clearer and this
is also a requirement for making set_language a member function.
gdb/ChangeLog:
2019-12-15 Christian Biesinger <cbiesinger@google.com>
* ada-exp.y (write_ambiguous_var): Call symbol_set_language to
set the language of sym.
* language.c (language_alloc_type_symbol): Likewise.
Change-Id: I85338ea2e4121155f2da222fe0aa6b7d3ffe26f7
In this commit:
commit 086baaf134
Date: Tue Oct 15 16:18:26 2019 +0100
gdb/python: Introduce gdb.lookup_static_symbols
A duplicate description of gdb.lookup_global_symbol was accidentally
added. This commit corrects this mistake and removes the duplicate.
gdb/doc/ChangeLog:
* python.texi (Symbols In Python): Remove duplicate description of
gdb.lookup_global_symbol.
Change-Id: I4457b42cf05bde39e5c0ff39f168af919cad1255
Ref.: https://bugzilla.redhat.com/show_bug.cgi?id=1728147
Ref.: https://sourceware.org/bugzilla/show_bug.cgi?id=23613
Hi,
This bug has been reported against Fedora GDB, but there's also an
upstream bug. The problem reported is that GDB segfaults when the
working directory is deleted. It's pretty use to reproduce it:
mkdir bla
cd bla
rmdir ../bla
gdb echo
Debugging the problem is a bit tricky, because, since the current
directory doesn't exist anymore, a corefile cannot be saved there.
After a few attempts, I came up with the following:
gdb -ex 'shell mkdir bla' -ex 'cd bla' -ex 'shell rmdir ../bla' -ex 'r echo' ./gdb/gdb
This assumes that you're inside a build directory which contains
./gdb/gdb, of course.
After investigating it, I found that the problem happens at
gdb_abspath, where we're dereferencing 'current_directory' without
checking if it's NULL:
...
(concat (current_directory,
IS_DIR_SEPARATOR (current_directory[strlen (current_directory) - 1])
? "" : SLASH_STRING,
...
So I fixed the problem with the patch below. The idea is that, if
'current_directory' is NULL, then the final string returned should be
just the "path".
After fixing the bug, I found a similar one reported against our
bugzilla: PR gdb/23613. The problem is the same, but the reproducer
is a bit different.
I really tried writing a testcase for this, but unfortunately it's
apparently not possible to start GDB inside a non-existent directory
with DejaGNU.
I regression tested this patch on the BuildBot, and no regressions
were found.
gdb/ChangeLog:
2019-12-14 Sergio Durigan Junior <sergiodj@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1728147
PR gdb/23613
* bsd-kvm.c (bsd_kvm_target_open): Use 'gdb_abspath'.
* corelow.c: Include 'gdbsupport/pathstuff.h'.
(core_target_open): Use 'gdb_abspath'.
* gdbsupport/pathstuff.c (gdb_abspath): Guard against
'current_directory == NULL' case.
* gdbsupport/pathstuff.h (gdb_abspath): Expand comment and
explain what happens when 'current_directory' is NULL.
* go32-nat.c (go32_nat_target::wait): Check if
'current_directory' is NULL before call to 'chdir'.
* source.c (add_path): Use 'gdb_abspath'.
* top.c: Include 'gdbsupport/pathstuff.h'.
(init_history): Use 'gdb_abspath'.
(set_history_filename): Likewise.
* tracefile-tfile.c: Include 'gdbsupport/pathstuff.h'.
(tfile_target_open): Use 'gdb_abspath'.
Change-Id: Ibb0932fa25bc5c2d3ae4a7f64bd7f32885ca403b
This reverts commit 62e77f56f0.
(except for ChangeLog and a bugfix in minimal_symbol_reader::install)
As agreed on the mailing list, now that GDB 9 has branched, this patch
reverts the change to set worker-threads to zero. After this patch,
multithreaded minsym demangling will be enabled again by default.
gdb/ChangeLog:
2019-12-13 Christian Biesinger <cbiesinger@google.com>
* maint.c (n_worker_threads): Default to -1.
(worker_threads_disabled): Remove function.
* maint.h (worker_threads_disabled): Remove function.
* minsyms.c (minimal_symbol_reader::record_full): Don't call
symbol_set_names here if worker_threads_disabled () is true.
Change-Id: I5ff3e318d96f60968c8b8bedb84546ad2314d94b
ARI has a check for multiple calls to warning or error, suggesting
that they be combined into a single call. This triggers at three
places in gdb -- throw_bad_regnum_error, guile_repl_command, and the
end of value_cast -- and after examining these, I think they all make
sense as-is. Instead, it makes sense to remove this check from ARI.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh: Remove check for multiple calls to
warning or error.
Change-Id: I0618683623a3c7324460c7b9e5d7f252d88c2e8d
ARI has a "fix" call for "long long", but this call is incorrect.
This patch removes it.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh: Remove call to "fix" for "long long".
Change-Id: I97bca2dc04b579fcf7c9dba7fe7fd939451bcefa
This adds -Wno- support to ARI, so that warnings can be disabled
selectively. I use this to ignore "deprecated" warnings.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh: Handle -Wno- prefix.
Change-Id: I6919faedf920e857df4f597df66f0ba3943e0eac
This changes the ARI usage text to use the GNU style for
"metasyntactic variables".
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh (usage): Use GNU style.
Change-Id: Ibe5a867571382d2985d1b8b78dfef3ddd02291ff
A few spots can validly call vsprintf; this adds ARI markers to
suppress warnings at these places.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* gdbsupport/common-utils.c (string_printf, string_vprintf)
(string_vappendf): Add ARI comment.
Change-Id: Ia8665aa5d7b7331a3985b18626b19764a264447b
This silences ARI at the one spot that is permitted to call
floatformat_to_double, and also removes the corresponding "fix" call
from gdb_ari.sh -- it was incorrect, and now is not needed.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh: Remove "fix" call for
floatformat_to_double.
* target-float.c (host_float_ops<T>::from_target): Add ARI
comment.
Change-Id: I778a17a04da417c113194004dd7de3b1df381266
There are a handful of spots in gdb that validly call abort. This
patch adds the appropriate ARI marker to these lines, to silence the
ARI report. This also removes the "fix" call for "abort" from
gdb_ari.sh; it was incorrect and now is not needed.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh: Remove "fix" call for abort.
* utils.c (abort_with_message, dump_core, internal_vproblem): Add
ARI marker to abort.
* event-top.c (handle_sigsegv): Add ARI marker to abort.
Change-Id: I09ce6aa5010bbe4e5bb73ffdb727481be39d34d6
ARI reports the wrong substitution for floatformat_from_double.
"floatformat_from_doublest" was renamed in 2017.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh: Fix floatformat_from_double text.
Change-Id: Ibf1b194ea509b12ae8bc30ce285c809c96218557
The text for the ATTRIBUTE_UNUSED check in ARI is plainly incorrect
now -- gdb does in fact use ATTRIBUTE_UNUSED, and there's no issue in
doing so, when done properly.
This patch removes this check.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh: Remove ATTRIBUTE_UNUSED check.
Change-Id: I13fd8e9b40dbaab3978dbf9b6c4228b62299d944
The "boolean" and "var_boolean" checks from ARI seem only to generate
false reports.
Now that gdb is in C++, at least the "boolean" check seems unlikely to
ever generate a true report.
The "var_boolean" check likewise doesn't seem valuable any more --
presumably this refers to some ancient way of doing things in gdb, and
isn't likely to find a bug in the future.
Therefore, this patch removes these two checks.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* contrib/ari/gdb_ari.sh: Remove "boolean" and "var_boolean"
checks.
Change-Id: Iaf449b51e8182ffa0b9ed25fe688e0ff64a07a67
The Solaris buildbot builder complained about some recent patches of
mine. Building with GCC 7 failed.
This patch fixes the bug. I'm checking it in.
gdb/ChangeLog
2019-12-13 Tom Tromey <tromey@adacore.com>
* gdbsupport/safe-iterator.h (class basic_safe_range) <begin,
end>: No longer "const".
Change-Id: I5f428fab61087f467ac3b6475f4ef4dbd314fcb0
Many places in this file use spaces only for indentation. Fix them to
conform to GNU style.
gdb/ChangeLog:
* jit.c: Fix indentation, replace spaces with tabs where
applicable.
This enables support for the msp430-elfbare target being added to GCC.
gdb/ChangeLog:
2019-12-13 Jozef Lawrynowicz <jozef.l@mittosystems.com>
* configure.tgt: Match msp430-*-elf* targets when configuring GDB.
A plan I had a while ago was to write the DWARF index in a worker
thread. This is why objfile::partial_symtabs is a shared_ptr.
However, it turned out that doing this required keeping the objfile
alive as well. Now that objfiles are managed using shared_ptr,
there's no need for partial_symtabs to be one as well, so this patch
reverts that change.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* objfiles.h (struct objfile) <partial_symtabs>: Now a
unique_ptr.
Change-Id: I3d7831006c40d4c8f3173ba51c0c1b0a32021ae5
This changes objfiles to be managed using a shared_ptr. shared_ptr is
chosen because it enables the use of objfiles in background threads.
The simplest way to do this was to introduce a new iterator that will
return the underlying objfile, rather than a shared_ptr. (I also
tried changing the rest of gdb to use shared_ptr, but this was quite
large; and to using intrusive reference counting, but this also was
tricky.)
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* progspace.h (objfile_list): New typedef.
(class unwrapping_objfile_iterator)
(struct unwrapping_objfile_range): Newl
(struct program_space) <objfiles_range>: Change type.
<objfiles>: Change return type.
<add_objfile>: Change type of "objfile" parameter.
<objfiles_list>: Now a list of shared_ptr.
* progspace.c (program_space::add_objfile): Change type of
"objfile". Update.
(program_space::remove_objfile): Update.
* objfiles.h (struct objfile) <~objfile>: Make public.
* objfiles.c (objfile::make): Update.
(objfile::unlink): Don't call delete.
Change-Id: I6fb7fbf06efb7cb7474c525908365863eae27eb3
This changes free_all_objfiles to be a method on program_space, in
line with the other changes to treat program_space as a container for
objfiles.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* symfile.c (symbol_file_clear): Update.
* progspace.h (struct program_space) <free_all_objfiles>: Declare
method.
* progspace.c (program_space::free_all_objfiles): New method.
* objfiles.h (free_all_objfiles): Don't declare.
* objfiles.c (free_all_objfiles): Move to program_space.
Change-Id: I908b549d2981b6005f7ca181fc0e6d24fc8b7b6f
This introduces the basic_safe_range class, which can be used to
create a basic_safe_iterator. This also changes basic_safe_iterator
in two ways.
First, it simplifies the constructor. This seemed unnecessarily
complicated to me, and keeping it this way would prevent the second
change...
... which is to add a second constructor for initializing the
one-past-the-end iterator that is stored in basic_safe_iterator.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* gdbsupport/safe-iterator.h (basic_safe_iterator): Simplify. Add
second constructor.
(basic_safe_range): New class.
Change-Id: Ib351ef6fd435129a5053c64e5561877e1459ab37
This removes the MULTI_OBJFILE_P macro in favor of a method on the
program space.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* progspace.c (program_space::multi_objfile_p): New method.
* printcmd.c (info_symbol_command): Update.
* maint.c (maintenance_translate_address): Update.
* objfiles.h (MULTI_OBJFILE_P): Remove.
* progspace.h (struct program_space) <multi_objfile_p>: New
method.
Change-Id: I2779e26ea8909078d63fea8f13bce94cab73948c
This introduces a new method, program_space::remove_objfile, and
changes the objfile destructor not to unlink an objfile from the
program space's list.
This is cleaner because, like the previous patch, it treats the
program space more like a container for objfiles. Also, this makes it
possible to keep an objfile alive even though it has been unlinked
from the program space's list, which is important for processing in a
worker thread.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* progspace.h (struct program_space) <remove_objfile>: Declare.
* progspace.c (program_space::remove_objfile): New method.
* objfiles.c (unlink_objfile): Remove.
(objfile::unlink): Call remove_objfile.
(objfile): Don't call unlink_objfile.
Change-Id: I22f768827723dce21886fae9b3664532c8349e68
This introduces a new method, program_space::add_objfile, that adds an
objfile to the program space's list of objfiles. It also changes the
obfile's constructor so that linking an objfile into this list is not
done here.
The former is an improvement because it makes more sense to treat the
program space as a container holding objfiles -- so manipulation of
the list belongs there.
The latter is not strictly needed, but seemed better both because it
is removing a global side effect from a constructor, and for symmetry
reasons, as a subsequent patch will remove unlinking from the
destructor.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* progspace.h (struct program_space) <add_objfile>: Declare
method.
* progspace.c (program_space::add_objfile): New method.
* objfiles.c (~objfile): Don't unlink objfile.
(put_objfile_before): Remove.
(add_separate_debug_objfile): Don't call put_objfile_before.
(objfile::make): Call add_objfile. Set new_objfiles_available on
the per-program-space data.
Change-Id: I93e8525dda631cb89dcc2046a5c51c7c9f34ccfd
The idea behind this is that, in the long run, some code will need to
be able to hold onto an objfile after it is unlinked from the program
space. In particular, this is needed for some functionality to be
moved to worker threads -- otherwise the objfile can be deleted while
still in use.
So, this makes ~objfile private, replacing it with an "unlink" method,
making it more obvious which operation is intended at the calling
points.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* symfile.c (syms_from_objfile_1): Use objfile_up.
(syms_from_objfile_1, remove_symbol_file_command): Call unlink
method.
(reread_symbols): Use objfile_up.
* solib.c (update_solib_list, reload_shared_libraries_1): Call
unlink method.
* objfiles.h (struct objfile) <~objfile>: Now private.
<unlink>: New method.
(struct objfile_deleter): New.
(objfile_up): New typedef.
* objfiles.c (objfile::unlink): New method.
(free_objfile_separate_debug, free_all_objfiles)
(objfile_purge_solibs): Use it.
* jit.c (jit_unregister_code): Remove.
(jit_inferior_exit_hook, jit_event_handler): Call unlink on
objfile.
* compile/compile-object-run.c (do_module_cleanup): Call unlink on
objfile.
* compile/compile-object-load.c (compile_object_load): Use
objfile_up.
Change-Id: I934bee70b26b8b24e1735828fb1e60fe8a05714f
This changes objfile::make to take a "parent" parameter, and makes
add_separate_debug_objfile static.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* symfile.c (symbol_file_add_with_addrs): Pass "parent" to
objfile::make.
* objfiles.h (struct objjfile) <make>: No longer inline.
(add_separate_debug_objfile): Don't declare.
* objfiles.c (add_separate_debug_objfile): Now static.
(objfile::make): Move from objfiles.h. Call
add_separate_debug_objfile. Add "parent" parameter.
Change-Id: I631f43bb71738dea6ae0697317bf8ef4a0db4617
This changes the objfile constructor to be private, changing the
callers to use a factory method. This isn't perhaps strictly needed
for the goal of this series -- changing the container model of
objfiles -- but is a nice symmetry.
gdb/ChangeLog
2019-12-12 Tom Tromey <tom@tromey.com>
* symfile.c (symbol_file_add_with_addrs): Use objfile::make.
* objfiles.h (struct objfile): Make constructor private.
<make>: New static method.
* jit.c (jit_object_close_impl): Update.
Change-Id: I42e07bc80a88cf3322ace94ffe869ae5788bcb29
I'm currently studying that code and noticed this manual memory
management, which could easily be replaced with a vector, so here it is.
gdb/ChangeLog:
* jit.c (jit_reader_try_read_symtab): Replace xmalloc/xfree with
gdb::byte_vector.
I noticed a couple of spots that call malloc_failure, but that don't
need to.
* In xml-support.c, "concat" uses xmalloc, so cannot return NULL.
* In utils.c, "buildargv" also uses xmalloc, so can only return NULL
if the argument is empty.
Tested by the buildbot.
gdb/ChangeLog
2019-12-12 Tom Tromey <tromey@adacore.com>
* xml-support.c (xml_fetch_content_from_file): Don't call
malloc_failure.
* utils.h (class gdb_argv): Remove malloc_failure comment.
* utils.c (gdb_argv::reset): Don't call malloc_failure.
Change-Id: I59483620deb6609ccf2f024d94a29113bb62d1a9
This adds Ravenscar support to gdb for RISC-V targets.
This was tested internally using AdaCore's test suite and qemu.
gdb/ChangeLog
2019-12-12 Tom Tromey <tromey@adacore.com>
* Makefile.in (ALL_TARGET_OBS): Add riscv-ravenscar-thread.o.
(HFILES_NO_SRCDIR): Add riscv-ravenscar-thread.h.
(ALLDEPFILES): Add riscv-ravenscar-thread.c.
* configure.tgt (riscv-*-*): Add riscv-ravenscar-thread.o.
* riscv-ravenscar-thread.c: New file.
* riscv-ravenscar-thread.h: New file.
* riscv-tdep.c (riscv_gdbarch_init): Call
register_riscv_ravenscar_ops.
Change-Id: Ic47a3b3cfbbe80c2c82a5f48d2e0481845cac8b0
A recent commit removed DIAGNOSTIC_IGNORE_UNUSED_FUNCTION, which was
used in thread-pool.c. This patch changes this code to use
ATTRIBUTE_UNUSED instead.
Tested by rebuilding.
gdb/ChangeLog
2019-12-12 Tom Tromey <tromey@adacore.com>
* gdbsupport/thread-pool.c (set_thread_name): Use
ATTRIBUTE_UNUSED.
Change-Id: I56d46eaac73690565d0e52db1791411567a918dd
Attempting to build GDB in Ubuntu 16.04.6 LTS on x86_64, I ran into warnings
that caused the build to fail:
binutils-gdb/gdb/gdbsupport/safe-strerror.c:44:1: error: ‘char* select_strerror_r(char*, char*)’ defined but not used [-Werror=unused-function] select_strerror_r (char *res, char *)
The diagnostic macro DIAGNOSTIC_IGNORE_UNUSED_FUNCTION seems to expand
correctly to its respective pragma, but this doesn't seem to have an effect on
the warning. I tried to use the pragma explicitly and got the same result.
ATTRIBUTE_UNUSED works fine in this case if you put it in both functions,
which should fix warnings for both gdb and gdbserver builds.
The compiler version is gcc (Ubuntu 5.4.0-6ubuntu1~16.04.11) 5.4.0 20160609.
This is likely the result of PR64079 in GCC, which was fixed by commit
9e96f1e1b9731c4e1ef4fbbbf0997319973f0537.
To prevent other developers from attempting to use this macro, only to get
confused by it not working as expected, it seems better to not define this
particular macro.
gdb/ChangeLog:
2019-12-12 Luis Machado <luis.machado@linaro.org>
* gdbsupport/safe-strerror.c: Don't include diagnostics.h.
(select_strerror_r): Use ATTRIBUTE_UNUSED instead of the diagnostics
macros.
include/ChangeLog:
2019-12-12 Luis Machado <luis.machado@linaro.org>
* diagnostics.h (DIAGNOSTIC_IGNORE_UNUSED_FUNCTION). Remove
definitions.
Change-Id: Iad6123d61d76d111e3ef8d24aa8c60112304c749
Testing on another TUI series showed that some of the regexps in the
TUI test suite have been incorrect for a while. In particular, "|"
was meant literally in these tests, but was interpreted as pattern
alternation due to lack of quoting.
This patch fixes the bad tests. I am checking this in.
gdb/testsuite/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* gdb.tui/resize.exp: Fix regexp.
* gdb.tui/regs.exp: Fix regexps.
* gdb.tui/main.exp: Fix regexp.
Change-Id: Ib6661361171ac120bb92f4a8aec7efa4bcaa36b9
The "winheight" command resizes a specified window, resizing the other
windows in the layout to adapt. In the current code, this is done by
examining each possible layout separately. The new layout code has a
more general approach to handling this, and this patch simply removes
the old code in favor of a call into the new layout engine.
gdb/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_set_win_height_command): Call
tui_adjust_window_height.
(tui_adjust_win_heights, new_height_ok): Remove.
* tui/tui-layout.h (tui_adjust_window_height): Declare.
* tui/tui-layout.c (tui_adjust_window_height): New function.
Change-Id: I6bb681375a46adc8d29fd06f581deed4e078e78a
The TUI has separate code for each possible layout to handle the case
where the terminal window is resized. With the new layout code, this
can all be replaced with a call to tui_apply_current_layout, which
simply re-applies the current layout.
This results in some small differences in behavior when resizing, so
some tests are updated.
gdb/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_resize_all): Remove code, call
tui_apply_current_layout.
gdb/testsuite/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* gdb.tui/resize.exp: Update.
* gdb.tui/empty.exp (layouts): Update.
Change-Id: I3dc6c02a753d495d9ab5e8213d550a147198ce6f
This patch introduces the first use of tui_layout, by changing
show_layout to clone and use the appropriate tui_layout.
This resulted in one minor layout change, and also in the unintended
-- but good -- side effect that the title of each boxed window is now
visible.
gdb/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* tui/tui-layout.h (tui_apply_current_layout): Declare.
* tui/tui-layout.c (standard_layouts, applied_layout): New
globals.
(tui_apply_current_layout): New function.
(show_layout): Set applied_layout. Call
tui_apply_current_layout.
(show_source_command, show_disasm_command)
(show_source_disasm_command, show_data)
(show_source_or_disasm_and_command): Remove.
(initialize_layouts): New function.
(_initialize_tui_layout): Call initialize_layouts.
gdb/testsuite/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* gdb.tui/regs.exp: Update.
* gdb.tui/empty.exp (layouts): Update.
* gdb.tui/basic.exp: Update.
* lib/tuiterm.exp (_check_box): Don't check bottom border.
Change-Id: If1ee06ee58f4803e8c213f4ab0f5bb59f4650ec2
This introduces a new approach to window layout for the TUI. The idea
behind this code is that a layout should be specified in a declarative
way, and then be applied by generic code that does not need to know
the specifics of every possible layout.
This patch itself does not change any behavior, because the new layout
engine isn't yet connected to anything. That is, this merely
introduces the implementation.
This generic approach makes the code more maintainable. It also
enables some future changes:
* New window types are simpler to add;
* User-specified layouts are possible; and
* Horizontal layouts are more attainable
gdb/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* tui/tui-layout.h (class tui_layout_base)
(class tui_layout_window, class tui_layout_split): New.
* tui/tui-layout.c (tui_get_window_by_name)
(tui_layout_window::clone, tui_layout_window::apply)
(tui_layout_window::get_sizes, tui_layout_window::add_split)
(tui_layout_split::add_window, tui_layout_split::clone)
(tui_layout_split::get_sizes)
(tui_layout_split::set_weights_from_heights)
(tui_layout_split::adjust_size, tui_layout_split::apply): New
functions.
(tui_layout_split::add_split, tui_layout_split::add_split)
(tui_layout_split::set_weights_from_heights)
(tui_layout_split::set_weights_from_heights): New functions.
Change-Id: I3a4cae666327b617d862aaa356f8179f945c6a4e
struct tui_point does not help very much. It is only used for
storage, and never passed between functions. I think it makes the
code more verbose without any corresponding benefit, so this patch
removes it.
gdb/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.c (tui_gen_win_info::make_window): Update.
* tui/tui-win.c (tui_adjust_win_heights, tui_resize_all): Update.
* tui/tui-layout.c (tui_gen_win_info::resize): Update.
* tui/tui-data.h (struct tui_point): Remove.
(struct tui_gen_win_info) <origin>: Remove.
<x, y>: New fields.
* tui/tui-command.c (tui_cmd_window::resize): Update.
Change-Id: I3f77920585b9ea9e2b4b189f3f3ae32d4da0c252
This introduces a new method, tui_gen_win_info::min_height, to fetch
the minimum height of a window. This is used in the subsequent
unified layout patch.
gdb/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* tui/tui-stack.h (struct tui_locator_window) <min_height>:
Implement.
* tui/tui-regs.h (struct tui_data_item_window) <min_height>:
Implement.
* tui/tui-data.h (struct tui_gen_win_info) <min_height>: New
method.
(struct tui_win_info) <min_height>: Implement.
Change-Id: Id33baffdf041fde072e15c1ff89b75f8b8118adb
This moves the can_box method to tui_gen_win_info, so that it will be
available on the tui_locator_window class. This will be used in a
subsequent patch.
gdb/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* tui/tui-data.h (struct tui_gen_win_info) <can_box>: New method.
(struct tui_win_info) <can_box>: Update.
Change-Id: Idfa58af41341607932d3c39415f6a35ee9b5d3dc
This moves the max_height method to tui_gen_win_info and implements it
in the subclasses. This is used by a subsequent patch, which will
normalize window layout across all window types.
gdb/ChangeLog
2019-12-11 Tom Tromey <tom@tromey.com>
* tui/tui-stack.h (struct tui_locator_window) <max_height>: New
method.
* tui/tui-regs.h (struct tui_data_item_window) <max_height>: New
method.
* tui/tui-data.h (struct tui_gen_win_info) <max_height>: New
method.
(struct tui_win_info) <max_height>: Now override.
Change-Id: I4ba3e8899bc4668328d3d78e3c1674c61882450d
Now that the GDB 9 branch has been created, we can
bump the version number.
gdb/ChangeLog:
GDB 9 branch created (27f7b2f640):
* version.in: Bump version to 10.0.50.DATE-git.
PR build/25268 points out that the build fails on macOS, because on
macOS the "pthread_setname_np" function takes a single argument.
This patch fixes the problem, by introducing a new adapter function
that handles both styles of pthread_setname_np.
This change also meant moving the pthread_setname_np call to the
thread function, because macOS only permits setting the name of the
current thread. This means that there can be a brief window when gdb
will see the wrong name; but I think this is a minor concern.
Tested by rebuilding on x86-64 Fedora 30, and on macOS High Sierra.
On Linux I also debugged gdb to ensure that the thread names are still
set correctly.
gdb/ChangeLog
2019-12-11 Tom Tromey <tromey@adacore.com>
PR build/25268:
* gdbsupport/thread-pool.c (set_thread_name): New function.
(thread_pool::set_thread_count): Don't call pthread_setname_np.
(thread_pool::thread_function): Call set_thread_name.
Change-Id: Id7bf28d99ca27a893a9fc87ebb90b15a9c2a9cb4
A recent commit changed bfd_get_signed_8 to extend the result to a
bfd_signed_vma. This caused a compiler error in one spot in my
--enable-targets=all gdb build, where the result of bfd_get_signed_8
was passed to printf.
This patch fixes the build. Tested by rebuilding.
gdb/ChangeLog
2019-12-11 Tom Tromey <tromey@adacore.com>
* fbsd-tdep.c (fbsd_core_info_proc_status): Cast result of
bfd_get_signed_8.
Change-Id: Ic015f5fd3d88da6b5da8f7b4e1d11d5c981333db
The option framework documentation was speaking about a 'print -raw'
option, but this option does not exist.
This patch implements -raw-values option that tells to ignore the
active pretty printers when printing a value.
As we already have -raw-frame-arguments, I thought -raw-values
was more clear, in particular to differentiate
set print raw-values and set print raw-frame-arguments.
gdb/doc/ChangeLog
2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Command Options): Use -p and -pretty in the example,
as -r is ambiguous. Update the print - TAB TAB completion result.
(Data): Document new option -raw-values. Use -p and -pretty in the
example, as -r is ambiguous.
(Print Settings): Document set print raw values.
(Pretty-Printer Commands): Document interaction between enabled
pretty printers and -raw-values/-raw-frame-arguments.
gdb/ChangeLog
2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* NEWS: Document -raw-values option and the related setting commands.
* printcmd.c (print_command_parse_format): Do not set opts->raw off,
only set it on when /r is given.
* valprint.c (value_print_option_defs): New element raw-values.
* Makefile.in: Add the new file.
gdb/testsuite/ChangeLog
2019-12-11 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/options.exp: Add -raw-values in the print completion list.
* gdb.python/py-prettyprint.exp: Add tests for -raw-values.
I noticed that an example in the gdb.prompt documentation used the
wrong kind of quotes -- because it is code, it should use a plain
ASCII quotation mark. I also slightly shortened the sample text here,
so it would more clearly fit on a single line.
gdb/doc/ChangeLog
2019-12-10 Tom Tromey <tom@tromey.com>
* python.texi (gdb.prompt): Use correct quotes in example.
Shorten sample text.
Change-Id: I4153928c0d88001244ad410f3943c952a6ebfeb1
Add tests which check for accessibility of variables from within
various OpenMP parallel regions.
Tested on Fedora 27, 28, 29, 30, and 31. I also tested with my OpenMP
work on Fedora 30. The test has been annotated with setup_xfail and
setup_kfail statements so that there are no unexpected failures on any
of these platforms when using gcc. Better still, for my own testing
anyway, is that there are also no XPASSes or KPASSes either. So,
regardless of platform, when using gcc, and regardless of whether my
(not yet public) OpenMP work is used, seeing a FAIL indicates a real
problem.
Fedora 27 results:
# of expected passes 85
# of expected failures 65
(Note: I have not retested F27 since v1 of the patch; it's possible
that the numbers will be slightly different for v2.)
Fedora 28, 29, 30 results:
# of expected passes 131
# of expected failures 4
# of known failures 16
Fedora 30, 31 results w/ my OpenMP work:
# of expected passes 151
The above results all use gcc, either the system gcc or a development
gcc (when testing against my OpenMP work in GDB). I've also tested
with clang 9.0.0 and icc 19.0.5.281 20190815 on Fedora 31.
Fedora 31, clang:
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print s3
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print i1
FAIL: gdb.threads/omp-par-scope.exp: single_scope: first thread: print i3
FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print s3
FAIL: gdb.threads/omp-par-scope.exp: single_scope: second thread: print i1
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i02
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i11
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i12
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i22
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: second thread: print i11
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: second thread: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: after parallel: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 2nd stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 2nd stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th stop: print num
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print file_scope_var
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: outer_threads: outer stop: print j
Fedora 31, icc:
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i12
FAIL: gdb.threads/omp-par-scope.exp: multi_scope: first thread: print i22
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 1st thread: print j
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print j
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 1st call: 2nd thread: print z
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 1st thread: print j
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print s1
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print i
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print j
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_func: 2nd call: 2nd thread: print z
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 1st stop: print k
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print l
FAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 3rd stop: print k
For both clang and icc, it turns out that there are some problems with
the DWARF that these compilers generate. Of the two, icc does at
least nest the subprogram of the outlined function representing the
parallel region within the function that it's defined, but does not
handle inner scopes if they exist. clang places the subprogram for
the outlined function at the same level as the containing function, so
variables declared within the function aren't visible at all.
I could call setup_xfail to avoid FAILs for clang and icc also, but I don't
want to further complicate the test.
gdb/testsuite/ChangeLog:
* gdb.threads/omp-par-scope.c: New file.
* gdb/threads/omp-par-scope.exp: New file.
Change-Id: Icb9c991730d84ca7509380af817dfcc778e764ea
This commit adds the gdb_caching_proc, support_nested_function_tests,
to lib/gdb.exp. It tests to see whether or not the C compiler has
support for nested function calls.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (support_nested_function_tests): New proc.
Change-Id: Ic2c93bc4cc200e07e104a2398f89a9c0514bdc75
We only ever use one of the two overloads, so to avoid breaking -Werror
builds, supress the warning.
gdb/ChangeLog:
2019-12-10 Christian Biesinger <cbiesinger@google.com>
* gdbsupport/safe-strerror.c: Supress the unused function warning
for select_strerror_r.
Change-Id: I344869a382bb36fe181b5b2a31838d1d20f58169
To do that, this patch makes IPA compile safe-strerror as well. Because
it doesn't use Gnulib, it calls the Glibc version of strerror_r directly.
Consequently this patch also removes the configure checks for strerror.
gdb/ChangeLog:
2019-12-10 Christian Biesinger <cbiesinger@google.com>
* config.in: Regenerate.
* configure: Regenerate.
* gdbsupport/agent.c (gdb_connect_sync_socket): Call
safe_strerror instead of strerror.
* gdbsupport/common.m4: Don't check for strerror.
* gdbsupport/safe-strerror.c: Support both the glibc version
of strerror_r and the XSI version.
gdb/gdbserver/ChangeLog:
2019-12-10 Christian Biesinger <cbiesinger@google.com>
* Makefile.in: Add safe-strerror.c to gdbreplay and IPA, and change
UNDO_GNULIB_CFLAGS to undo strerror_r instead of strerror.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Don't check for strerror.
* linux-i386-ipa.c (initialize_fast_tracepoint_trampoline_buffer):
Call safe_strerror instead of strerror.
* server.h (strerror): Remove this now-unnecessary declaration.
* tracepoint.c (init_named_socket): Call safe_strerror instead of
strerror.
(gdb_agent_helper_thread): Likewise.
* utils.c (perror_with_name): Likewise.
Change-Id: I74848f072dcde75cb55c435ef9398dc8f958cd73
Sometimes -- notably with unchecked unions -- the Ada "ptype" code
will print a "?" or "??" to indicate something unknown. The choice of
what was printed was somewhat arbitrary, and in one case, Ada would
print an empty string rather than "?".
This patch normalizes the Ada code to use "?" rather than an empty
string or "??". My reasoning here is that a single question mark is
enough to convey unknown-ness.
gdb/ChangeLog
2019-12-10 Tom Tromey <tromey@adacore.com>
* ada-typeprint.c (print_choices): Use a single "?".
(print_variant_part): Print "?" if the discriminant name
is not known.
gdb/testsuite/ChangeLog
2019-12-10 Tom Tromey <tromey@adacore.com>
* gdb.ada/unchecked_union.exp: New file.
* gdb.ada/unchecked_union/pck.adb: New file.
* gdb.ada/unchecked_union/pck.ads: New file.
* gdb.ada/unchecked_union/unchecked_union.adb: New file.
* gdb-utils.exp (string_to_regexp): Also quote "?".
Change-Id: I3403040780a155ffa2c44c8e6a04ba86bc810e29
The documentation for make-breakpoint from the Guile API and the `spec'
variant of the gdb.Breakpoint constructor from the Python API state that
the format acceptable for location strings is the same as that accepted
by the break command. However, using the -probe qualifier at the
beginning of the location string causes a GDB internal error as it
attempts to decode a probe location in the wrong code path. Without this
functionality, there doesn't appear to be another way to set breakpoints
on probe points from Python or Guile scripts.
This patch introduces a new helper function that returns a
breakpoint_ops instance appropriate for a parsed location and updates
the Guile and Python bindings to use said function, rather than the
current hard-coded use of bkpt_breakpoint_ops. Since this logic is
duplicated in the handling of the `break' and `trace' commands, those
are also updated to call into the new helper function.
gdb/ChangeLog:
2019-12-10 George Barrett <bob@bob131.so>
Fix scripted probe breakpoints.
* breakpoint.c (tracepoint_probe_breakpoint_ops): Move
declaration forward.
(breakpoint_ops_for_event_location_type)
(breakpoint_ops_for_event_location): Add function definitions.
(break_command_1, trace_command): Use
breakpoint_ops_for_event_location.
* breakpoint.h (breakpoint_ops_for_event_location): Add function
declarations.
* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Use
breakpoint_ops_for_event_location.
* python/py-breakpoint.c (bppy_init): Use
breakpoint_ops_for_event_location.
gdb/testsuite/ChangeLog:
2019-12-10 George Barrett <bob@bob131.so>
Test scripted probe breakpoints.
* gdb.guile/scm-breakpoint.c (main): Add probe point.
* gdb.python/py-breakpoint.c (main): Likewise.
* gdb.guile/scm-breakpoint.exp (test_bkpt_probe): Add probe
specifier test.
* gdb.python/py-breakpoint.exp (test_bkpt_probe): Likewise.
Passing an lvalue argument to a function that takes an rvalue parameter
is not allowed per C++ rules. Consider this function:
int g (int &&x) { return x; }
Calling g as in
int i = 5;
int j = g (i);
is illegal. For instance, GCC 9.2.1 yields
~~~
test.cpp: In function ‘int main()’:
test.cpp:6:14: error: cannot bind rvalue reference of type ‘int&&’ to
lvalue of type ‘int’
6 | int j = g (i);
| ^
~~~
GDB currently allows this function call:
~~~
(gdb) print g(i)
$1 = 5
~~~
Fix this by ranking an lvalue argument incompatible with an rvalue
parameter. The behavior after this patch is:
~~~
(gdb) print g(i)
Cannot resolve function g to any overloaded instance
~~~
Tested with GCC 9.2.1.
gdb/ChangeLog:
2019-12-09 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdbtypes.c (rank_one_type): Return INCOMPATIBLE_TYPE_BADNESS
when ranking an lvalue argument for an rvalue parameter.
gdb/testsuite/ChangeLog:
2019-12-09 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.cp/rvalue-ref-overload.cc (g): New function that takes
an rvalue parameter.
* gdb.cp/rvalue-ref-overload.exp: Test calling it with an lvalue
parameter.
Change-Id: I4a6dfc7dac63efa1e3b9f8f391e4b736fbdccdc1
Extend the output pattern in mi-fortran-modules.exp to skip some
system modules that appear with versions of GFortran after 7.x.x.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-fortran-modules.exp: Add patterns to skip system
modules.
Change-Id: I64aaa395e554a32e8267ffa096faee53c19c0b9e
In some cases the Fortran stride information generated by GCC is wrong
with versions of GCC after 7.x.x. This commit adds kfails for the
tests in question with known bad versions of gcc.
The bug has been reported to GCC here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92775
gdb/testsuite/ChangeLog:
* gdb.fortran/derived-type-striding.exp: KFAIL if we are using a
broken version of GCC.
Change-Id: Iaef08e5e2c87ab3d6983b88f749d40e01aea2bc6
The gdb.fortran/info-modules.exp and gdb.fortran/info-types.exp tests
are failing on versions of gfortran after 7.3 due to the inclusion of
extra "system" modules and type that were not being matched by the
current test patterns.
Rather than building increasingly complex patterns that would always
be at risk of breaking with future versions of GCC I have instead
added a new library that parses the output of the following commands:
info types
info variables
info functions
info modules
info module functions
info module variables
into a data structure, the test can than run checks against the
contents of this data structure.
The benefit is that we can simply ignore extra results that we don't
care about.
There is a small risk that a bug in GDB might allow us to start
reporting incorrect results in such a way that the new library will
not spot the error. However, I have tried to mitigate this risk by
adding extra procedures into the test library (see check_no_entry) and
we can add more in future if we wanted to be even more defensive.
I tested this test file with gFortran 7.3.1, 8.3.0, and 9.2.0, I now
see 100% pass in all cases.
gdb/testsuite/ChangeLog:
* gdb.fortran/info-modules.exp: Rewrite to make use of new
sym-info-cmds library.
* gdb.fortran/info-types.exp: Likewise.
* lib/sym-info-cmds.exp: New file.
Change-Id: Iff81624f51b5afb6c95393932f3d94472d7c2970
This should be the type of startup_with_shell, whose type was changed
from int to bool at commit 80fd28264.
This fixes the build on macOS:
CXX darwin-nat.o
In file included from ../../gdb/darwin-nat.c:22:
In file included from ../../gdb/top.h:25:
In file included from ../../gdb/value.h:23:
In file included from ../../gdb/frame.h:72:
In file included from ../../gdb/language.h:26:
In file included from ../../gdb/symtab.h:33:
../../gdb/gdbsupport/gdb_optional.h:155:19: error: no matching constructor for initialization of 'scoped_restore_tmpl<int>'
new (&m_item) T (std::forward<Args>(args)...);
^ ~~~~~~~~~~~~~~~~~~~~~~~~
../../gdb/darwin-nat.c:1995:31: note: in instantiation of function template specialization 'gdb::optional<scoped_restore_tmpl<int> >::emplace<bool *, int>' requested here
restore_startup_with_shell.emplace (&startup_with_shell, 0);
^
../../gdb/gdbsupport/scoped_restore.h:69:3: note: candidate constructor template not viable: no known conversion from 'bool *' to 'int *' for 1st argument
scoped_restore_tmpl (T *var, T2 value)
^
../../gdb/gdbsupport/scoped_restore.h:57:3: note: candidate constructor not viable: requires single argument 'var', but 2 arguments were provided
scoped_restore_tmpl (T *var)
^
../../gdb/gdbsupport/scoped_restore.h:76:3: note: candidate constructor not viable: requires single argument 'other', but 2 arguments were provided
scoped_restore_tmpl (const scoped_restore_tmpl<T> &other)
^
1 error generated.
gdb/ChangeLog
2019-12-08 Wataru Ashihara <wataash@wataash.com>
* darwin-nat.c (darwin_nat_target::create_inferior): Fix
template argument for scoped_restore_tmpl from bool to int.
Change-Id: Ia0202efd34dbce69b6af5d035fa55ed89215138a
When running the gdb testsuite with the cc-with-dwz board, I run into:
...
Running gdb/testsuite/gdb.dwarf2/imported-unit.exp ...
gdb compile failed, dwz: gdb.dwarf2/imported-unit/imported-unit: \
Couldn't find DIE referenced by DW_AT_abstract_origin
cc-with-tweaks.sh: dwz did not modify gdb.dwarf2/imported-unit/imported-unit.
...
The problem is that the DW_AT_abstract_origin reference here:
...
<0><d2>: Abbrev Number: 2 (DW_TAG_compile_unit)
<1><e6>: Abbrev Number: 4 (DW_TAG_subprogram)
<e7> DW_AT_abstract_origin: <0x142>
<eb> DW_AT_low_pc : 0x4004b2
<f3> DW_AT_high_pc : 0x4004c8
...
referring to a DIE in another compilation unit here:
...
<0><129>: Abbrev Number: 2 (DW_TAG_compile_unit)
<1><142>: Abbrev Number: 4 (DW_TAG_subprogram)
<143> DW_AT_name : main
<148> DW_AT_type : <0x13b>
<14c> DW_AT_external : 1
...
is encoded using intra-CU reference form DW_FORM_ref4 instead of intra-CU
reference DW_FORM_ref_addr:
...
4 DW_TAG_subprogram [has children]
DW_AT_abstract_origin DW_FORM_ref4
DW_AT_low_pc DW_FORM_addr
DW_AT_high_pc DW_FORM_addr
DW_AT value: 0 DW_FORM value: 0
...
Fix this in the DWARF assembler by making all inter-CU references use the '%'
label prefix.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-12-08 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/imported-unit.exp: Fix inter-CU references.
Change-Id: I690ff18c3943705ed478453531b176ff74700f3c
This patch uses new BFD support for detecting build-ids in core
files.
After this patch, it is possible to run gdb with only the
core file, and gdb will automatically load the executable and
debug info [example from tests]:
$ gdb -nx -q
(gdb) core-file corefile-buildid.core
[New LWP 29471]
Reading symbols from gdb.base/corefile-buildid/debugdir-exec/.build-id/36/fe5722c5a7ca3ac746a84e223c6a2a69193a24...
Core was generated by `outputs/gdb.base/coref'.
Program terminated with signal SIGABRT, Aborted.
(gdb)
This work is based on functionality available in Fedora originally
written by Jan Kratochvil.
Regression tested on buildbot.
gdb/ChangeLog:
2019-12-07 Keith Seitz <keiths@redhat.com>
* build-id.c (build_id_bfd_get): Permit bfd_core, too.
(build_id_to_debug_bfd): Make static, rewriting to use
build_id_to_bfd_suffix.
(build_id_to_bfd_suffix): Copy of build_id_to_debug_bfd,
adding `suffix' parameter. Append SUFFIX to file names
when searching for matching files.
(build_id_to_debug_bfd): Use build_id_to_bfd_suffix.
(build_id_to_exec_bfd): Likewise.
* build-id.h (build_id_to_debug_bfd): Clarify that function
searches for BFD of debug info file.
(build_id_to_exec_bfd): Declare.
* corelow.c: Include build-id.h.
(locate_exec_from_corefile_build_id): New function.
(core_target_open): If no executable BFD is found,
search for a core file BFD using build-id.
gdb/testsuite/ChangeLog:
2019-12-07 Keith Seitz <keiths@redhat.com>
* gdb.base/corefile-buildid-shlib-shr.c: New file.
* gdb.base/corefile-buildid-shlib.c: New file.
* gdb.base/corefile-buildid.c: New file.
* gdb.base/corefile-buildid.exp: New file.
Change-Id: I15e9e8e58f10c68b5cae55e2eba58df1e8aef529
This avoids a conflict with a system "struct bcache" on
Solaris (see e.g.
https://www.isi.edu/nsnam/archive/ns-users/webarch/2001/msg05393.html)
Note that the Solaris conflict for now only surfaces with
--enable-targets=all (which the build bot doesn't use).
gdb/ChangeLog:
2019-12-06 Christian Biesinger <cbiesinger@google.com>
* bcache.c: Put in namespace gdb.
* bcache.h: Likewise.
* gdbtypes.c (check_types_worklist): Update.
(types_deeply_equal): Update.
* macrotab.c (struct macro_table) <bcache>: Update.
(new_macro_table): Update.
* macrotab.h (struct bcache): Put this forward declaration
inside namespace gdb.
(new_macro_table): Update.
* objfiles.h (struct objfile_per_bfd_storage) <filename_cache>:
Update.
<macro_cache>: Update.
* psymtab.h: (psymtab_storage) <psymbol_cache>: Update.
Change-Id: I843d5e91f7ccb3db6d1099a8214c15a74510256f
Consider the DWARF as generated by gcc with the tentative patch to fix gcc
PR91507 - "wrong debug for completed array with previous incomplete
declaration":
...
<1><f4>: Abbrev Number: 2 (DW_TAG_array_type)
<f5> DW_AT_type : <0xff>
<f9> DW_AT_sibling : <0xff>
<2><fd>: Abbrev Number: 3 (DW_TAG_subrange_type)
<2><fe>: Abbrev Number: 0
<1><ff>: Abbrev Number: 4 (DW_TAG_pointer_type)
<100> DW_AT_byte_size : 8
<101> DW_AT_type : <0x105>
<1><105>: Abbrev Number: 5 (DW_TAG_base_type)
<106> DW_AT_byte_size : 1
<107> DW_AT_encoding : 6 (signed char)
<108> DW_AT_name : (indirect string, offset: 0x19f): char
<1><10c>: Abbrev Number: 6 (DW_TAG_variable)
<10d> DW_AT_name : zzz
<111> DW_AT_decl_file : 1
<112> DW_AT_decl_line : 1
<113> DW_AT_decl_column : 14
<114> DW_AT_type : <0xf4>
<118> DW_AT_external : 1
<118> DW_AT_declaration : 1
<1><118>: Abbrev Number: 2 (DW_TAG_array_type)
<119> DW_AT_type : <0xff>
<11d> DW_AT_sibling : <0x128>
<1><12f>: Abbrev Number: 8 (DW_TAG_variable)
<130> DW_AT_specification: <0x10c>
<134> DW_AT_decl_line : 2
<135> DW_AT_decl_column : 7
<136> DW_AT_type : <0x118>
<13a> DW_AT_location : 9 byte block: 3 30 10 60 0 0 0 0 0 (DW_OP_addr: 601030)
...
The DWARF will result in two entries in the symbol table, a decl with type
char *[] and a def with type char*[2].
When trying to print the value of zzz:
...
$ gdb a.spec.out -batch -ex "p zzz"
...
the decl (rather than the def) will be found in the symbol table, which is
missing the location information, and consequently we get:
...
$1 = 0x601030 <zzz>
...
[ There is a fallback mechanism that finds the address of the variable in the
minimal symbol table, but that's not used here, because the type of the decl
does not specify a size. We could use the symbol size here to get the size
of the type, but that's currently not done: PR exp/24989. Still, fixing that
PR would not fix the generic case, where minimal symbol info is not
available. ]
Fix this by preferring defs over decls when searching in the symbol table.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2019-12-06 Tom de Vries <tdevries@suse.de>
PR symtab/24971
* block.c (best_symbol, better_symbol): New function.
(block_lookup_symbol_primary, block_lookup_symbol): Prefer def over
decl.
gdb/testsuite/ChangeLog:
2019-12-06 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/varval.exp: Add decl before def test.
Change-Id: Id92326cb8ef9903b121ef9e320658eb565d0f5a9
Simplify the expected test outputs. This is a minor cleanup; no
functional change is intended.
gdb/testsuite/ChangeLog:
2019-12-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.cp/rvalue-ref-overload.exp: Minor cleanup.
Change-Id: Ie760a2856cae3be0eeed5496765a5f1cd102d6b7
The overload resolution mechanism assigns badness values to the
necessary conversions to be made on types to pick a champion. A
badness value consists of a "rank" that scores the conversion and a
"subrank" to differentiate conversions of the same kind.
An auxiliary function, 'sum_ranks', is used for adding two badness
values. In all of its uses, except two, 'sum_ranks' is used for
populating the subrank of a badness value. The two exceptions are in
'rank_one_type':
~~~
/* See through references, since we can almost make non-references
references. */
if (TYPE_IS_REFERENCE (arg))
return (sum_ranks (rank_one_type (parm, TYPE_TARGET_TYPE (arg), NULL),
REFERENCE_CONVERSION_BADNESS));
if (TYPE_IS_REFERENCE (parm))
return (sum_ranks (rank_one_type (TYPE_TARGET_TYPE (parm), arg, NULL),
REFERENCE_CONVERSION_BADNESS));
~~~
Here, the result of a recursive call is combined with
REFERENCE_CONVERSION_BADNESS. This leads to the problem of
over-punishment by combining two ranks. Consider this:
void an_overloaded_function (const foo &);
void an_overloaded_function (const foo &&);
...
foo arg;
an_overloaded_function(arg);
When ranking 'an_overloaded_function (const foo &)', the badness
values REFERENCE_CONVERSION_BADNESS and CV_CONVERSION_BADNESS are
combined, whereas 'rank_one_type' assigns only the
REFERENCE_CONVERSION_BADNESS value to 'an_overloaded_function (const
foo &&)' (there is a different execution flow for that). This yields
in GDB picking the latter function as the overload champion instead of
the former.
In fact, the 'rank_one_type' function should have given
'an_overloaded_function (const foo &)' the CV_CONVERSION_BADNESS
value, with the see-through referencing increasing the subrank a
little bit. This can be achieved by introducing a new badness value,
REFERENCE_SEE_THROUGH_BADNESS, which bumps up the subrank only, and
using it in the two "exceptional" cases of 'sum_ranks'.
gdb/ChangeLog:
2019-12-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdbtypes.h: Define the REFERENCE_SEE_THROUGH_BADNESS value.
* gdbtypes.c (rank_one_type): Use REFERENCE_SEE_THROUGH_BADNESS
for ranking see-through reference cases.
gdb/testsuite/ChangeLog:
2019-12-06 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.cp/rvalue-ref-overload.cc: Add a case that involves both
CV and reference conversion for overload resolution.
* gdb.cp/rvalue-ref-overload.exp: Test it.
Change-Id: I39ae6505ab85ad0bd21915368c82540ceeb3aae9
GDB crashes when doing:
(gdb) faas
Aborted
Do the needed check to avoid crashing.
gdb/ChangeLog
2019-12-06 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* stack.c (faas_command): Check a command is provided.
* thread.c (taas_command, tfaas_command): Likewise.
gdb/testsuite/ChangeLog
2019-12-06 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.threads/pthreads.exp: Test taas and tfaas without command.
* gdb.base/frameapply.exp: Test faas without command.
Valgrind detects various inferior related leaks, such as:
==31877== 5,530 (56 direct, 5,474 indirect) bytes in 1 blocks are definitely lost in loss record 7,131 of 7,355
==31877== at 0x4C2E18C: calloc (vg_replace_malloc.c:760)
==31877== by 0x23E580: xcalloc (alloc.c:100)
==31877== by 0x4794A9: xcnewvec<void*> (poison.h:158)
==31877== by 0x4794A9: registry_alloc_data(registry_data_registry*, registry_fields*) (registry.c:51)
==31877== by 0x3A537C: inferior_alloc_data (inferior.c:43)
==31877== by 0x3A537C: inferior::inferior(int) (inferior.c:92)
==31877== by 0x3A5426: add_inferior_silent(int) (inferior.c:98)
==31877== by 0x3A5530: add_inferior(int) (inferior.c:122)
...
Origin of the leaks is in prune_inferiors: prune_inferiors is first removing
the inferior to prune from the inferior list, then calls delete_inferior.
But delete_inferior will only really destroy the inferior when it finds
it into the inferior list.
As delete_inferior is removing the inferior to delete from the inferior list,
ensure prune_inferiors only calls delete_inferior, without touching the
inferior list.
gdb/ChangeLog
2019-12-05 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* inferior.c (prune_inferiors): Only call delete_inferior.
Do not modify the inferior list.
I happened to find a few more spots that should use metadata style,
but do not. I missed these in my earlier search somehow. This patch
also adds gettext markup in a couple of spots where it was missing.
gdb/ChangeLog
2019-12-04 Tom Tromey <tom@tromey.com>
* valprint.c (val_print_string): Use metadata_style.
* go-valprint.c (print_go_string): Use metadata style.
* p-valprint.c (pascal_object_print_static_field): Use metadata
style.
* cp-valprint.c (cp_print_static_field): Use metadata style.
Change-Id: Id82ca2aa306c6694b111d5c92dfa6f0cce919ebf
When compiling Fortran tests (e.g. gdb.fortran/info-modules.exp), the
Fotran compile produces .mod files. These files contain details of
compiled modules that are then consumed by the compiler when compiling
other files that USE a module.
Currently the compiler writes the .mod files into its current
directory, so for us this turns out to be 'build/gdb/testsuite/'.
This means that .mod files can be shared between tests, which seems
against the spirit of the GDB testsuite; source files should be
compiled fresh for each test.
This commit adds the -J option to the compiler flags whenever we
compile a Fortran file, this option tells the compiler where to write,
and look for, .mod files.
After this commit there was one Fortran test that needed fixing, with
that fix in place all of the Fortran tests pass again, but now the
.mod files are now produced in the per-test output directories.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_compile): Add -J compiler option when building
Fortran tests.
* gdb.mi/mi-fortran-modules.exp: Compile source files in correct
order.
Change-Id: I99444cf22d80e320093d3f3ed9abb8825f378e0b
Extend the Fortran parser to support 'single precision' and 'double
precision' types as well 'single complex' and 'double complex' types.
gdb/ChangeLog:
* f-exp.y (COMPLEX_KEYWORD, SINGLE, DOUBLE, PRECISION): New
tokens.
(typebase): New patterns for complex, single/double precision, and
single/double complex.
(f77_keywords): Change token for complex keyword, and add single,
double, and precision keywords.
gdb/testsuite/ChangeLog:
* gdb.fortran/type-kinds.exp (test_cast_1_to_type_kind): Handle
casting to type with no kind specified.
(test_basic_parsing_of_type_kinds): Additional tests for types
with no kind specified, and add tests for single/double
precision/complex types.
Change-Id: I9c82f4d392c58607747bd08862c1ee330723a1ba
Running the selftests on an all-targets build, I get:
Running selftest help_doc_invariants.
help doc broken invariant: command 'info io_registers' help doc first line is not terminated with a '.' character
Self test failed: self-test failed at /home/simark/src/binutils-gdb/gdb/unittests/help-doc-selftests.c:95
Add a period at the end of the doc of that command, and make it a bit
nicer in general.
gdb/ChangeLog:
* avr-tdep.c (_initialize_avr_tdep): Improve help of command
"info io_registers".
When running the regcache::cooked_read_test selftest in an all targets
build, I get the following internal error:
/home/simark/src/binutils-gdb/gdb/thread.c:95: internal-error: thread_info* inferior_thread(): Assertion `tp' failed.
The stack trace is the followiing:
#9 0x000055fe25584a52 in internal_error (file=0x55fe27a25fe0 "/home/simark/src/binutils-gdb/gdb/thread.c", line=95, fmt=0x55fe27a25c80 "%s: Assertion `%s' failed.")
at /home/simark/src/binutils-gdb/gdb/gdbsupport/errors.c:55
#10 0x000055fe260674bc in inferior_thread () at /home/simark/src/binutils-gdb/gdb/thread.c:95
#11 0x000055fe25c62f0f in get_current_regcache () at /home/simark/src/binutils-gdb/gdb/regcache.c:372
#12 0x000055fe2594fcf1 in current_options () at /home/simark/src/binutils-gdb/gdb/mep-tdep.c:873
#13 0x000055fe2594ff08 in mep_register_name (gdbarch=0x62100056f510, regnr=152) at /home/simark/src/binutils-gdb/gdb/mep-tdep.c:958
#14 0x000055fe25950112 in mep_register_reggroup_p (gdbarch=0x62100056f510, regnum=152, group=0x55fe2924d540 <save_group>) at /home/simark/src/binutils-gdb/gdb/mep-tdep.c:1029
#15 0x000055fe2555ad87 in gdbarch_register_reggroup_p (gdbarch=0x62100056f510, regnum=152, reggroup=0x55fe2924d540 <save_group>) at /home/simark/src/binutils-gdb/gdb/gdbarch.c:3622
#16 0x000055fe25c61d45 in reg_buffer::save(gdb::function_view<register_status (int, unsigned char*)>) (this=0x7ffc61a0ed90, cooked_read=...)
at /home/simark/src/binutils-gdb/gdb/regcache.c:247
#17 0x000055fe2552ac60 in readonly_detached_regcache::readonly_detached_regcache(gdbarch*, gdb::function_view<register_status (int, unsigned char*)>) (this=0x7ffc61a0ed90,
gdbarch=0x62100056f510, cooked_read=...) at /home/simark/src/binutils-gdb/gdb/regcache.h:444
#18 0x000055fe25c61867 in readonly_detached_regcache::readonly_detached_regcache (this=0x7ffc61a0ed90, src=...) at /home/simark/src/binutils-gdb/gdb/regcache.c:212
#19 0x000055fe25c6a5ca in selftests::cooked_read_test (gdbarch=0x62100056f510) at /home/simark/src/binutils-gdb/gdb/regcache.c:1613
The problems is that mep's code ends up calling inferior_thread, which
calls find_thread_ptid. find_thread_ptid searches for a thread by ptid
in the thread list of the inferior that is expected to contain that
thread.
However, the thread list of the mock inferior set up in cooked_read_test
is never initialized. So find_thread_ptid doesn't find the thread,
which is an unexpected situation for inferior_thread.
This is failing since this commit:
0803633106
Per-inferior thread list, thread ranges/iterators, down with ALL_THREADS, etc.
Fix it by putting the mock thread in the thread list of the mock
inferior in cooked_read_test.
gdb/ChangeLog:
* regcache.c (cooked_read_test): Initialize thread list of
mock_inferior.
The == and != operators on filtered_iterator are not doing the
right thing, they compare values pointed by the wrapped iterators
instead of comparing the iterators themselves.
As a result, operator== will return true if the two iterators point to
two equal values at different positions. operator!= will fail
similarly.
Also, this causes it to deference past-the-end iterators when doing.
For example, in
for (iter = ...; iter != end_iter; ++iter)
the != comparison dereferences end_iter. I don't think this should
happen.
I don't think it's a problem today, given that we only use
filtered_iterator to wrap linked lists of threads and inferiors.
Dereferencing past-the-end iterators of these types is not fatal, it
just returns NULL, which is not a value we otherwise find in the lists.
But in other contexts, it could become problematic.
I have added a simple self test that fails without the fix applied.
gdb/ChangeLog:
* filtered-iterator.h (filtered_iterator) <operator==,
operator!=>: Compare wrapped iterators, not wrapped pointers.
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Add
unittests/filtered_iterator-selftests.c.
* unittests/filtered_iterator-selftests.c: New file.
This adds a bit-field test for scalar_storage_order.
gdb/testsuite/ChangeLog
2019-12-04 Tom Tromey <tromey@adacore.com>
* gdb.base/endianity.c (struct other) <x>: New field.
(main): Initialize it.
* gdb.base/endianity.exp: Update.
Change-Id: I9e07d1b3e08e7c3384832b68ef286afe1d11479a
A subrange type should inherit its endianity from its base type.
gdb/ChangeLog
2019-12-04 Tom Tromey <tromey@adacore.com>
* gdbtypes.c (create_range_type): Inherit endianity
from base type.
gdb/testsuite/ChangeLog
2019-12-04 Tom Tromey <tromey@adacore.com>
* gdb.ada/scalar_storage/storage.adb: New file.
* gdb.ada/scalar_storage/pck.adb: New file.
* gdb.ada/scalar_storage/pck.ads: New file.
* gdb.ada/scalar_storage.exp: New file.
Change-Id: I2998ab919dc28aeff097763c4242f9bfb90823a3
From what I can tell, set_gdbarch_bits_big_endian has never been used.
That is, all architectures since its introduction have simply used the
default, which is simply check the architecture's byte-endianness.
Because this interferes with the scalar_storage_order code, this patch
removes this gdbarch setting entirely. In some places,
type_byte_order is used rather than the plain gdbarch.
gdb/ChangeLog
2019-12-04 Tom Tromey <tromey@adacore.com>
* ada-lang.c (decode_constrained_packed_array)
(ada_value_assign, value_assign_to_component): Update.
* dwarf2loc.c (rw_pieced_value, access_memory)
(dwarf2_compile_expr_to_ax): Update.
* dwarf2read.c (dwarf2_add_field): Update.
* eval.c (evaluate_subexp_standard): Update.
* gdbarch.c, gdbarch.h: Rebuild.
* gdbarch.sh (bits_big_endian): Remove.
* gdbtypes.h (union field_location): Update comment.
* target-descriptions.c (make_gdb_type): Update.
* valarith.c (value_bit_index): Update.
* value.c (struct value) <bitpos>: Update comment.
(unpack_bits_as_long, modify_field): Update.
* value.h (value_bitpos): Update comment.
Change-Id: I379b5e0c408ec8742f7a6c6b721108e73ed1b018
I failed to notice that the scalar_storage_order patch put
type_byte_order at the end of gdbtypes.c. The end of the file is
normally where the file's _initialize function goes. This moves
type_byte_order earlier, into a more relevant section.
gdb/ChangeLog
2019-12-04 Tom Tromey <tromey@adacore.com>
* gdbtypes.c (type_byte_order): Move earlier. Assert for unknown
endian-ness.
Change-Id: I4666431ecbb32ec98918f39f72d22c86b2bc8dde
Testing the scalar_storage_order patch pointed out that it does not
handle floating point properly. This patch fixes this problem.
gdb/ChangeLog
2019-12-04 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (dwarf2_init_float_type)
(dwarf2_init_complex_target_type): Add byte_order parameter.
(read_base_type): Compute byte order earlier.
* gdbtypes.c (init_float_type): Add byte_order parameter.
* gdbtypes.h (init_float_type): Add byte_order parameter.
gdb/testsuite/ChangeLog
2019-12-04 Tom Tromey <tromey@adacore.com>
* gdb.base/endianity.c (struct otherendian) <f>: New field.
(main): Initialize it.
* gdb.base/endianity.exp: Update.
Change-Id: Ic02eb711d80ce678ef0ecf8c506a626e441b8440
Christian had emailed me to say that the TUI unit test broke the mingw
build, but I erroneously thought this was fixed by the earlier patch
that made the test body conditional on the TUI being built.
However, I was wrong about this -- tui-selftests.c unconditionally
includes tui-winsource.h, which fails if curses is not available.
This patch fixes the build problem by moving this include into the
"#ifdef TUI" section.
Tested by rebuilding a mingw-hosted gdb.
gdb/ChangeLog
2019-12-04 Tom Tromey <tromey@adacore.com>
* unittests/tui-selftests.c: Conditionally include tui-winsource.h.
Change-Id: If608649ef5cbef8ea92192e11c53379742967ee7
I upgraded to Fedora 30 recently. It includes GCC 9, which gives a
warning for dwarf2read.c:
../../binutils-gdb/gdb/dwarf2read.c:16103:24: warning: ‘discr_offset’ may be used uninitialized in this function [-Wmaybe-uninitialized]
This patch fixes the problem by initializing discr_offset.
Tested by rebuilding.
gdb/ChangeLog
2019-12-04 Tom Tromey <tromey@adacore.com>
* dwarf2read.c (process_structure_scope): Initialize
"discr_offset".
Change-Id: I76a6157921c9beacb641b8a41e10026006621b95
Adds a new parameter -max-results to -symbol-info-functions,
-symbol-info-variables, -symbol-info-types, and -symbol-info-modules.
This parameter limits the number of results returned.
This change still leaves -symbol-info-module-functions and
-symbol-info-module-variables always returning all results, fixing
these commands is slightly harder.
There's currently no mechanism for the user of these commands to know
if the result list has been truncated if you get back the maximum
number of results, so if there are exactly 10 functions and you call
'-symbol-info-functions --max-results 10' the reply would appear no
different than if you had 20 functions and called with a max of 10.
Right now, if you get back the maximum then you should assume that
there might be more results available.
One other thing to note is that the global_symbol_searcher::search by
default returns SIZE_MAX results, there's no longer a mechanism to
return an unlimited number of results, though hopefully this will not
be a huge issue.
gdb/ChangeLog:
* mi/mi-symbol-cmds.c (mi_symbol_info): Take extra parameter, and
add it into the search spec.
(parse_max_results_option): New function.
(mi_info_functions_or_variables): Parse -max-results flag and pass
it to mi_symbol_info.
(mi_cmd_symbol_info_modules): Likewise.
(mi_cmd_symbol_info_types): Likewise.
* symtab.c (global_symbol_searcher::add_matching_symbols): Change
return type to bool, change result container into a set, and don't
add new results if we have enough already.
(global_symbol_searcher::add_matching_msymbols): Change return
type to bool, and don't add new results if we have enough already.
(sort_search_symbols_remove_dups): Delete.
(global_symbol_searcher::search): Early exit from search loop when
we have enough results. Use a std::set to collect the results
from calling add_matching_symbols.
* symtab.h (global_symbol_searcher) <set_max_seach_results>: New
member function.
(global_symbol_searcher) <m_max_search_results>: New member
variable.
(global_symbol_searcher) <add_matching_symbols>: Update header
comment and change return type to bool.
(global_symbol_searcher) <add_matching_msymbols>: Update header
comment and change return type to bool.
gdb/doc/ChangeLog:
* doc/gdb.texinfo (GDB/MI Symbol Query): Add documentation of
-max-results to some -symbol-info-* commands.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-sym-info.exp: Add tests for -max-results parameter.
Change-Id: I90a28feb55b388fb46461a096c5db08b6b0bd427
In preparation for the next commit, this commit restructures the code
by splitting global_symbol_searcher::search into separate functions.
There should be no functional changes after this commit.
gdb/ChangeLog:
* symtab.c (symbol_search::compare_search_syms): Update header
comment.
(global_symbol_searcher::is_suitable_msymbol): New function.
(global_symbol_searcher::expand_symtabs): New function.
(global_symbol_searcher::add_matching_symbols): New function.
(global_symbol_searcher::add_matching_msymbols): New function.
(global_symbol_searcher::search): Move most of the content
into the new functions above, and call them as needed.
* symtab.h (global_symbol_searcher) <expand_symtabs>: New member
function.
(global_symbol_searcher) <add_matching_symbols>: New member
function.
(global_symbol_searcher) <add_matching_msymbols>: New member
function.
(global_symbol_searcher) <is_suitable_msymbol>: New member
function.
Change-Id: I06b26920f35c268f7a38d8203dc2c2813aa501c6
Two new MI command -symbol-info-module-variables and
-symbol-info-module-functions, which are the equivalent of the CLI
command 'info module variables' and 'info module functions'. These
return information about functions and variables within Fortran
modules.
gdb/ChangeLog:
* mi/mi-cmds.c (mi_cmds): Add -symbol-info-module-functions and
-symbol-info-module-variables entries.
* mi/mi-cmds.h (mi_cmd_symbol_info_module_functions): Declare.
(mi_cmd_symbol_info_module_variables): Declare.
* mi/mi-symbol-cmds.c
(module_symbol_search_iterator): New typedef.
(output_module_symbols_in_single_module_and_file): New function.
(output_module_symbols_in_single_module): New function.
(mi_info_module_functions_or_variables): New function.
(mi_cmd_symbol_info_module_functions): New function.
(mi_cmd_symbol_info_module_variables): New function.
* NEWS: Mention new MI command.
gdb/doc/ChangeLog:
* doc/gdb.texinfo (GDB/MI Symbol Query): Document new MI command
-symbol-info-module-functions and -symbol-info-module-variables.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-fortran-modules.exp: Add additional tests for
-symbol-info-module-functions and -symbol-info-module-variables.
Change-Id: Ic96f12dd14bd7e34774c3cde008fec30a4055bfe
This function is not just slower than xxhash, it is slower than
even libiberty's iterative_hash, so there does not seem to be
a reason for it to exist.
------------------------------------------------------------
Benchmark Time CPU Iterations
------------------------------------------------------------
BM_xxh3 11 ns 11 ns 66127192
BM_xxh32 19 ns 19 ns 36792609
BM_xxh64 16 ns 16 ns 42941328
BM_city32 26 ns 26 ns 27028370
BM_city64 17 ns 17 ns 40472793
BM_iterative_hash 77 ns 77 ns 9088854
BM_bcache_hash 125 ns 125 ns 5599232
gdb/ChangeLog:
2019-12-03 Christian Biesinger <cbiesinger@google.com>
* bcache.c (hash): Remove.
(hash_continue): Remove.
* bcache.h (hash): Remove.
(hash_continue): Remove.
(struct bcache) <ctor>: Update.
* psymtab.c (psymbol_hash): Update.
* stabsread.c (hashname): Update.
* utils.h (fast_hash): Add an argument for a start value,
defaulting to zero.
Change-Id: I107f013eda5fdd3293326b5a206be43155dae0f8
A symbol not found inserted in the cache has a xstrdup-ed name
that must be freed, but only the struct block_symbol_cache is freed.
Add a function destroy_block_symbol_cache that clears all slots
before releasing the cache.
2019-12-03 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* symtab.c (symbol_cache_clear_slot): Move close to cleared type.
(destroy_block_symbol_cache): New function.
(symbol_cache:~symbol_cache) Call destroy_block_symbol_cache.
(resize_symbol_cache): Likewise.
An earlier patch introduced a unit test for tui_copy_source_line.
However if the TUI is not built (as is apparently the case on some of
the buildbot builders), then this will fail to link.
This patch fixes the problem. Tested by rebuilding with the TUI
disabled.
gdb/ChangeLog
2019-12-02 Tom Tromey <tom@tromey.com>
* unittests/tui-selftests.c (run_tests): Make conditional.
(_initialize_tui_selftest): Make conditional.
Change-Id: I964811c7635be24cf6c53920e74e920914503674
This fixes AIX build breakage from commit
491144b5e2
Thanks to Sangamesh Mallayya for pointing this out to me.
gdb/ChangeLog:
2019-12-02 Christian Biesinger <cbiesinger@google.com>
* aix-thread.c (debug_aix_thread): Change type to bool.
Change-Id: Ie7b2eab97b75b48067ef77e414e7510d1f79a525
While debugging something, i noticed this odd FIXME comment. It seems stale
and therefore here's a patch removing it.
gdb/ChangeLog:
2019-12-02 Luis Machado <luis.machado@linaro.org>
* infrun.c (follow_fork_inferior): Remove outdated FIXME comment.
Change-Id: I2436ca4ae4a6741012cafe8123325f738b692c9c
Add support for strings with dynamic length using the DWARF attribute
DW_AT_string_length.
Currently gFortran generates DWARF for some strings that make use of
DW_AT_string_length like this:
<1><2cc>: Abbrev Number: 20 (DW_TAG_string_type)
<2cd> DW_AT_string_length: 5 byte block: 99 bd 1 0 0 (DW_OP_call4: <0x1bd>)
<2d3> DW_AT_byte_size : 4
<2d4> DW_AT_sibling : <0x2e2>
In this type entry the DW_AT_string_length attribute references a
second DW_TAG_formal_parameter that contains the string length. The
DW_AT_byte_size indicates that the length is a 4-byte value.
This commit extends GDB's DWARF parsing for strings so that we can
create dynamic types as well as static types, based on the attribute
the DWARF contains.
I then extend the dynamic type resolution code in gdbtypes.c to add
support for resolving dynamic strings.
gdb/ChangeLog:
* dwarf2read.c (read_tag_string_type): Read the fields required to
make a dynamic string, and possibly create a dynamic range for the
string.
(attr_to_dynamic_prop): Setup is_reference based on the type of
attribute being processed.
* gdbtypes.c (is_dynamic_type_internal): Handle TYPE_CODE_STRING.
(resolve_dynamic_array): Rename to...
(resolve_dynamic_array_or_string): ...this, update header comment,
and accept TYPE_CODE_STRING.
(resolve_dynamic_type_internal): Handle TYPE_CODE_STRING.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-slices.exp: Add test for dynamic strings.
Change-Id: I03f2d181b26156f48f27a03c8a59f9bd4d71ac17
This is a minor refactor in preparation for the next commit. Splits
the core of dwarf2_per_cu_addr_sized_int_type out into a separate
function. There should be no user visible changes after this commit.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_per_cu_int_type): New function, takes most
of its implementation from...
(dwarf2_per_cu_addr_sized_int_type): ...here, which now just calls
the new function.
Change-Id: I8b849dd338012ec033b3f0a57d65cec0d7a3bd97
Currently GDB supports a byte or bit stride on arrays, in DWARF this
would be DW_AT_bit_stride or DW_AT_byte_stride on DW_TAG_array_type.
However, DWARF can also support DW_AT_byte_stride or DW_AT_bit_stride
on DW_TAG_subrange_type, the tag used to describe each dimension of an
array.
Strides on subranges are used by gFortran to represent Fortran arrays,
and this commit adds support for this to GDB.
I've extended the range_bounds struct to include the stride
information. The name is possibly a little inaccurate now, but this
still sort of makes sense, the structure represents information about
the bounds of the range, and also how to move from the lower to the
upper bound (the stride).
I've added initial support for bit strides, but I've never actually
seen an example of this being generated. Further, I don't really see
right now how GDB would currently handle a bit stride that was not a
multiple of the byte size as the code in, for example,
valarith.c:value_subscripted_rvalue seems geared around byte
addressing. As a consequence if we see a bit stride that is not a
multiple of 8 then GDB will give an error.
gdb/ChangeLog:
* dwarf2read.c (read_subrange_type): Read bit and byte stride and
create a range with stride where appropriate.
* f-valprint.c: Include 'gdbarch.h'.
(f77_print_array_1): Take the stride into account when walking the
array. Also convert the stride into addressable units.
* gdbtypes.c (create_range_type): Initialise the stride to
constant zero.
(create_range_type_with_stride): New function, initialise the
range as normal, and then setup the stride.
(has_static_range): Include the stride here. Also change the
return type to bool.
(create_array_type_with_stride): Consider the range stride if the
array isn't given its own stride.
(resolve_dynamic_range): Resolve the stride if needed.
* gdbtypes.h (struct range_bounds) <stride>: New member variable.
(struct range_bounds) <flag_is_byte_stride>: New member variable.
(TYPE_BIT_STRIDE): Define.
(TYPE_ARRAY_BIT_STRIDE): Define.
(create_range_type_with_stride): Declare.
* valarith.c (value_subscripted_rvalue): Take range stride into
account when walking the array.
gdb/testsuite/ChangeLog:
* gdb.fortran/derived-type-striding.exp: New file.
* gdb.fortran/derived-type-striding.f90: New file.
* gdb.fortran/array-slices.exp: New file.
* gdb.fortran/array-slices.f90: New file.
Change-Id: I9af2bcd1f2d4c56f76f5f3f9f89d8f06bef10d9a
I noticed that "info win" will print the table header, but no windows,
when the TUI is inactive. This patch changes this to print a message
instead.
gdb/ChangeLog
2019-12-01 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_all_windows_info): Treat inactive TUI
specially.
Change-Id: Ia860be8c786a71289da6609aa14d86b8365424db
tui_copy_source_line has a bug, where it can advance past the
terminating \0 in its input string. This patch fixes the bug and adds
a test case for this function.
gdb/ChangeLog
2019-12-01 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.c (tui_copy_source_line): Don't advance past
\0.
* unittests/tui-selftests.c: New file.
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Add tui-selftests.c.
Change-Id: I46cdabe6e57549983149b8f640cda5edd16fa260
I noticed that "tui enable" did not correctly show the source window
as having the focus. Debugging showed that the problem was that
tui_update_variables was called after the windows were drawn, and its
result was being ignored. This changed the code to re-highlight the
windows if the value changed.
gdb/ChangeLog
2019-12-01 Tom Tromey <tom@tromey.com>
* tui/tui.c (tui_enable): Call tui_update_variables earlier.
Change-Id: I1a4563fb431833dd3211a224c9e2df3b936fe9ce
