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
This adds the ability to change the color of the TUI borders, both
ordinary and active. Unlike other styling options, this doesn't allow
setting the intensity, because that is already done by the TUI in a
different way.
gdb/ChangeLog
2019-12-01 Tom Tromey <tom@tromey.com>
* NEWS: Document new settings.
* tui/tui-wingeneral.c (box_win): Apply appropriate border style.
* tui/tui-win.c (_initialize_tui_win): Add border style
observers.
* tui/tui-io.h (tui_apply_style): Declare.
* tui/tui-io.c (tui_apply_style): Rename from apply_style. No
longer static.
(apply_ansi_escape, tui_set_reverse_mode): Update.
* cli/cli-style.h (class cli_style_option) <add_setshow_commands>:
Add "skip_intensity" parameter.
<changed>: New member.
<do_set_value>: Declare.
(tui_border_style, tui_active_border_style): Declare.
* cli/cli-style.c (tui_border_style, tui_active_border_style): New
globals.
(cli_style_option): Initialize "changed".
(cli_style_option::do_set_value): New function.
(cli_style_option::add_setshow_commands): Add "skip_intensity"
parameter. Update.
(STYLE_ADD_SETSHOW_COMMANDS): Add "SKIP" parameter.
(_initialize_cli_style): Update. Create TUI border style
commands.
gdb/doc/ChangeLog
2019-12-01 Tom Tromey <tom@tromey.com>
* gdb.texinfo (TUI Configuration): Mention TUI border styles.
(Output Styling): Document new settings.
Change-Id: Id13e2af0af2a0bde61282752f2c379db3220c9fc
The source window currently uses a field width of 6 for line numbers,
and it further aligns to the next tab stop. This seemed a bit
wasteful of horizontal space to me, so I changed that in an earlier
patch.
However, that change wasn't universally popular. This patch instead
adds the option to use less horizontal space in the TUI source window.
gdb/ChangeLog
2019-12-01 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.h (tui_copy_source_line): Add "ndigits"
parameter.
* tui/tui-winsource.c (tui_copy_source_line): Add "ndigits"
parameter.
* tui/tui-win.h (compact_source): Declare.
* tui/tui-win.c (compact_source): New global.
(tui_set_compact_source, tui_show_compact_source): New functions.
(_initialize_tui_win): Add "compact-source" setting.
* tui/tui-source.c (tui_source_window::set_contents): Handle
compact_source setting.
* tui/tui-disasm.c (tui_disasm_window::set_contents): Update.
* NEWS: Document new setting.
gdb/doc/ChangeLog
2019-12-01 Tom Tromey <tom@tromey.com>
* gdb.texinfo (TUI Configuration): Document new setting.
Change-Id: I46ce9a68b12c9c79332d510f9c14b3c84b7efadd
Currently, gdb internally transforms DW_TAG_variant_part into a union
(with some special attbributes). When doing so, it computes the
length of this union from the length of the fields. However, this
computation didn't include the offset of these fields, resulting in
the length being too short.
This is not a problem given the way the code currently works.
However, I have a patch series to switch gdb to value-based printing,
where this does have an impact.
Tested on x86-64 Fedora 28; and, considering that this only affects
Rust, I am checking it in.
gdb/ChangeLog
2019-11-30 Tom Tromey <tom@tromey.com>
* dwarf2read.c (dwarf2_add_field): Include field offset when
computing variant part length.
Change-Id: I25d84fc237eb3c1e7f11f6eaf35ffe198efde6cc
gdb/ChangeLog
2019-11-30 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* NEWS: Mention define-prefix. Tell that command names can now
contain a . character.
gdb/doc/ChangeLog
2019-11-30 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Define): Indicate that user-defined prefix can
be used in 'define' command. Document 'define-prefix' command.
This patch adds . as an allowed character for user defined commands.
Combined with 'define-prefix', this allows to e.g. define a set of Valgrind
specific user command corresponding to the Valgrind monitor commands
(such as check_memory, v.info, v.set, ...).
gdb/ChangeLog
2019-11-30 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* command.h (valid_cmd_char_p): Declare.
* cli/cli-decode.c (valid_cmd_char_p): New function factorizing
the check of valid command char.
(find_command_name_length, valid_user_defined_cmd_name_p): Use
valid_cmd_char_p.
* cli/cli-script.c (validate_comname): Likewise.
* completer.c (gdb_completer_command_word_break_characters):
Do not remove . from the word break char, update comments.
(complete_line_internal_1): Use valid_cmd_char_p.
* guile/scm-cmd.c (gdbscm_parse_command_name): Likewise.
* python/py-cmd.c (gdbpy_parse_command_name): Likewise.
gdb/testsuite/ChangeLog
2019-11-30 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/define.exp: Test . in command names.
* gdb.base/setshow.exp: Update test, as . is now part of
command name.
Adds a test testing the new define-prefix command.
2019-11-30 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/define-prefix.exp: New file.
This patch adds the new 'define-prefix' command that creates (or mark an
existing user defined command) as a prefix command.
This approach was preferred compared to add a -prefix option to
'define' command : with define-prefix, a command can be defined and
afterwards marked as a prefix. Also, it is easier to define a
'prefix' only command in one operation.
This patch also adds completers for the 'define' and 'document' commands.
This makes it easier for the user to type the prefixes for 'define'
and type the documented command name for 'document'.
gdb/ChangeLog
2019-11-30 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* cli/cli-script.c (do_define_command): Ensure a redefined
prefix command is kept as a prefix command.
(define_prefix_command): New function.
(show_user_1): Report user defined prefixes.
(_initialize_cli_script): Create the new 'define-prefix' command.
Add completers for 'define' and 'document'.
* top.c (execute_command): If command is a user-defined prefix only
command, report the list of commands for this prefix command.
Function overload resolution prints debug output if turned on via the
'set debug overload' command. The output includes the badness vector
(BV). For each function, this vector contains a badness value of the
length of parameters as its first element. So, BV[0] does not
correspond to a parameter. The badness values of parameters start
with BV[1].
A badness value is a pair; it contains a rank and a subrank. Printing
both fields provides useful information.
Improve printing the badness vector along these lines.
gdb/ChangeLog:
2019-11-29 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* valops.c (find_oload_champ): Improve debug output.
Change-Id: I771017e7afbbaf4809e2238a9b23274f55c61f55
A segfault occurs if overload resolution debug mode is turned on via
the 'set debug overload' command. E.g.:
~~~
$ gdb ./a.out
...
(gdb) start
...
(gdb) set debug overload 1
(gdb) print foo(5)
-- Arg is int [8], parm is double [9]
Overloaded function instance (null) # of parms 1
Segmentation fault
$
~~~
The problem is, GDB tries to print the badness vector after it has
been std::move'd. Fix the problem by printing the vector before it is
moved.
gdb/ChangeLog:
2019-11-29 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* valops.c (find_oload_champ): Print part of debug messages
before the badness vector is std::move'd.
Change-Id: Ia623f9637e82ec332bfeac23eb6b0f2ffdcdde27
I noticed that the comment before creal_internal_fn refers to $_cimag,
but should refer to $_creal.
gdb/ChangeLog
2019-11-28 Tom Tromey <tom@tromey.com>
* value.c (creal_internal_fn): Fix comment.
Change-Id: I5665aceb4be5aae7014e914cfb39db184c65d5ea
While debugging gdb, I noticed that the bitfields in a range_bounds
were signed, causing the values of these fields to be -1.
I think this is odd; and while we haven't yet committed to boolean
bitfields, I think it is a small improvement to change these types to
unsigned.
gdb/ChangeLog
2019-11-28 Tom Tromey <tom@tromey.com>
* gdbtypes.h (struct range_bounds) <flag_upper_bound_is_count,
flag_bound_evaluated>: Now unsigned.
Change-Id: Ia377fd931594bbf8653180d4dcb4e60354d90139
guile-internal.h declares a function that is never defined. This
removes the declaration.
gdb/ChangeLog
2019-11-28 Tom Tromey <tom@tromey.com>
* guile/guile-internal.h (vlscm_scm_from_value_unsafe): Don't
declare.
Change-Id: I2dca228534bc1325d2d4bb319c31328121edecc4
gdb/ChangeLog:
2019-11-28 Mihails Strasuns <mihails.strasuns@intel.com>
* jit.c (jit_bfd_try_read_symtab): Fix printed function name in the
debug output.
* jit.c (jit_unregister_code): Add debug print to match
`jit_register_code`.
Change-Id: Ie66064f3aaa1c74facfc025c8d87f3a057869779
The two guard functions skip_btrace_tests and skip_btrace_pt_tests
have a minor bug, if the check function fails to compile then surely
we should skip the btrace tests - currently we return 0 to indicate
don't skip.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (skip_btrace_tests): Return 1 if the test fails to
compile.
(skip_btrace_pt_tests): Likewise.
Change-Id: I6dfc04b4adcf5b9424fb542ece7ddbe751bee301
Just to let people know that this is available and how to use it.
Also updates the description of the setting to say the default is 0.
gdb/ChangeLog:
2019-11-26 Christian Biesinger <cbiesinger@google.com>
* NEWS: Mention the new multithreaded symbol loading.
Change-Id: I263add6aae03b523f0870ad4d1e972eada4b382a
Per discussion on gdb-patches with Joel, this patch turns off multihreaded
symbol loading by default. It can be turned on using:
maint set worker-threads unlimited
To keep the behavior as close as possible to the old code, it still
calls symbol_set_names in the old place if n_worker_threads is 0.
gdb/ChangeLog:
2019-11-27 Christian Biesinger <cbiesinger@google.com>
* maint.c (n_worker_threads): Default to 0.
(worker_threads_disabled): New function.
* maint.h (worker_threads_disabled): New function.
* minsyms.c (minimal_symbol_reader::record_full): Call symbol_set_names
here if worker_threads_disabled () is true.
(minimal_symbol_reader::install): Skip all threading if
worker_threads_disabled () is true.
Change-Id: I92ba4f6bbf07363189666327cad452d6b9c8e01d
This is for the msymbol_hash and msymbol_demangled_hash hashtables
in objfile_per_bfd_storage. This basically computes those hash
codes together with the demangled symbol name in the background,
before it inserts the symbols in the hash table.
gdb/ChangeLog:
2019-11-27 Christian Biesinger <cbiesinger@google.com>
* minsyms.c (add_minsym_to_hash_table): Use a previously computed
hash code if possible.
(add_minsym_to_demangled_hash_table): Likewise.
(minimal_symbol_reader::install): Compute the hash codes for msymbol
on the background thread.
* symtab.h (struct minimal_symbol) <hash_value, demangled_hash_value>:
Add these fields.
Change-Id: Ifaa3346e9998f05743bff9e2eaad3f83b954d071
We can also compute the hash for the mangled name on a background
thread so make this function even faster (about a 7% speedup).
gdb/ChangeLog:
2019-11-27 Christian Biesinger <cbiesinger@google.com>
* minsyms.c (minimal_symbol_reader::install): Also compute the hash
of the mangled name on the background thread.
* symtab.c (symbol_set_names): Allow passing in the hash of the
linkage_name.
* symtab.h (symbol_set_names): Likewise.
Change-Id: I044449e7eb60cffc1c43efd3412f2b485bd9faac
The Fortran test gdb.fortran/info-modules compiles the files
info-types.f90 and info-types-2.f90 in that order. Unfortunately
info-types.f90 makes use of a module defined in info-types-2.f90.
This currently doesn't cause a problem if you run all of the Fortran
tests as the info-types.exp test already compiles info-types-2.f90 and
so the module description file 'mod2.mod' will be created, and can
then be found by info-modules.exp during its compile.
If however you try to run just info-modules.exp in a clean build
directory, the test will fail to compile.
Fix this by compiling the source files in the reverse order so that
the module is compiled first, then the test program that uses the
module.
gdb/testsuite/ChangeLog:
* gdb.fortran/info-modules.exp: Compile source files in correct
order.
Change-Id: Ic3a1eded0486f6264ebe3066cf1beafbd2534a91
Running a GDB with the fix for BZ 25065 should cause these new tests
to all pass.
When run against a GDB without the fix, there will be 2 unresolved
testcases. This is what I see in the gdb.sum file when I try it using
a GDB without the fix:
ERROR: GDB process no longer exists
UNRESOLVED: gdb.dwarf2/imported-unit.exp: ptype main::Foo
ERROR: Couldn't send ptype main::foo to GDB.
UNRESOLVED: gdb.dwarf2/imported-unit.exp: ptype main::foo
These are "unresolved" versus outright failures due to the fact that
GDB dies (segfaults) during the running of the test.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/imported-unit.exp: New file.
* gdb.dwarf2/imported-unit.c: New file.
Change-Id: I073fe69b81bd258951615f752df8e95b6e33a271
This is a fix for BZ 25065.
GDB segfaults when running either gdb.cp/subtypes.exp or
gdb.cp/local.exp in conjunction with using the -flto compiler/linker
flag.
A much simpler program, which was used to help create the test for
this fix, is:
-- doit.cc --
int main()
{
class Foo {
public:
int doit ()
{
return 0;
}
};
Foo foo;
return foo.doit ();
}
-- end doit.cc --
gcc -o doit -flto -g doit.cc
gdb -q doit
Reading symbols from doit...
(gdb) ptype main::Foo
type = class Foo {
Segmentation fault (core dumped)
The segfault occurs due to a NULL physname in
c_type_print_base_struct_union in c-typeprint.c. Specifically,
calling is_constructor_name() eventually causes the SIGSEGV is this
code in c-typeprint.c:
const char *physname = TYPE_FN_FIELD_PHYSNAME (f, j);
int is_full_physname_constructor =
TYPE_FN_FIELD_CONSTRUCTOR (f, j)
|| is_constructor_name (physname)
|| is_destructor_name (physname)
|| method_name[0] == '~';
However, looking at compute_delayed_physnames(), we see that
the TYPE_FN_FIELD_PHYSNAME field should never be NULL. This
field will be set to "" for NULL physnames:
physname = dwarf2_physname (mi.name, mi.die, cu);
TYPE_FN_FIELD_PHYSNAME (fn_flp->fn_fields, mi.index)
= physname ? physname : "";
For this particular case, it turns out that compute_delayed_physnames
wasn't being called, which left TYPE_FN_FIELD_PHYSNAME set to the NULL
value that it started with when that data structure was allocated.
The place to fix it, I think, is towards the end of
inherit_abstract_dies().
My first attempt at fix caused the origin CU's method_list (which is
simply the list of methods whose physnames still need to be computed)
to be added to the CU which is doing the inheriting. One drawback
with this approach is that compute_delayed_physnames is (eventually)
called with a CU that's different than the CU in which the methods
were found. It's not clear whether this will cause problems or not.
A safer approach, which is what I ultimately settled on, is to call
compute_delayed_physnames() from inherit_abstract_dies(). One
potential drawback is that all needed types might not be known at that
point. However, in my testing, I haven't seen a problem along these
lines.
gdb/ChangeLog:
* dwarf2read.c (inherit_abstract_dies): Ensure that delayed
physnames are computed for inherited DIEs.
Change-Id: I6c6ffe96b301a9daab9f653956b89e3a33fa9445
I found a couple of unnecessary backslashes in gdb. This removes
them.
Offhand, I wonder whether this abstract_to_concrete thing could be
done some other way? This seems possibly expensive.
Anyway, tested by rebuilding. I'm going to check this in as obvious.
gdb/ChangeLog
2019-11-27 Tom Tromey <tromey@adacore.com>
* dwarf2read.h (struct dwarf2_per_objfile): Remove unnecessary
backslashes.
* cp-support.c: Remove unnecessary backslashes.
Change-Id: I956c91ae24407eeafec8a731545b45f5222e6a9d
Easier to read, shorter, and will later make it possible to make the
name field private.
gdb/ChangeLog:
2019-11-27 Christian Biesinger <cbiesinger@google.com>
* ada-exp.y (write_ambiguous_var): Replace SYMBOL_SET_LINKAGE_NAME
with sym->set_linkage_name.
* coffread.c (coff_read_enum_type): Likewise.
* mdebugread.c (parse_symbol): Likewise.
* stabsread.c (patch_block_stabs): Likewise.
(define_symbol): Likewise.
(read_enum_type): Likewise.
(common_block_end): Likewise.
* symtab.h (struct general_symbol_info) <set_linkage_name>: New
function.
(SYMBOL_SET_LINKAGE_NAME): Remove.
* xcoffread.c (process_xcoff_symbol): Replace SYMBOL_SET_LINKAGE_NAME
with sym->set_linkage_name.
Change-Id: I174a0542c014f1b035070068076308bb8ae79abb
Add '-symbol-info-modules', an MI version of the CLI 'info modules'
command.
gdb/ChangeLog:
* mi/mi-cmds.c (mi_cmds): Add 'symbol-info-modules' entry.
* mi/mi-cmds.h (mi_cmd_symbol_info_modules): Declare.
* mi/mi-symbol-cmds.c (mi_cmd_symbol_info_modules): New function.
* NEWS: Mention new MI command.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-fortran-modules-2.f90: New file.
* gdb.mi/mi-fortran-modules.exp: New file.
* gdb.mi/mi-fortran-modules.f90: New file.
gdb/doc/ChangeLog:
* doc/gdb.texinfo (GDB/MI Symbol Query): Document new MI command
-symbol-info-modules.
Change-Id: Ibc618010d1d5f36ae8a8baba4fb9d9d724e62b0f
Add new MI commands -symbol-info-functions, -symbol-info-variables,
and -symbol-info-types which correspond to the CLI commands 'info
functions', 'info variables', and 'info types' respectively.
gdb/ChangeLog:
* mi/mi-cmds.c (mi_cmds): Add '-symbol-info-functions',
'-symbol-info-types', and '-symbol-info-variables'.
* mi/mi-cmds.h (mi_cmd_symbol_info_functions): Declare.
(mi_cmd_symbol_info_types): Declare.
(mi_cmd_symbol_info_variables): Declare.
* mi/mi-symbol-cmds.c: Add 'source.h' and 'mi-getopt.h' includes.
(output_debug_symbol): New function.
(output_nondebug_symbol): New function.
(mi_symbol_info): New function.
(mi_info_functions_or_variables): New function.
(mi_cmd_symbol_info_functions): New function.
(mi_cmd_symbol_info_types): New function.
(mi_cmd_symbol_info_variables): New function.
* NEWS: Mention new commands.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-sym-info-1.c: New file.
* gdb.mi/mi-sym-info-2.c: New file.
* gdb.mi/mi-sym-info.exp: New file.
gdb/doc/ChangeLog:
* doc/gdb.texinfo (GDB/MI Symbol Query): Document new MI command
-symbol-info-functions, -symbol-info-types, and
-symbol-info-variables.
Change-Id: Ic2fc6a6750bbce91cdde2344791014e5ef45642d
Split the function print_symbol_info into two parts, the new worker
core returns a string, which print_symbol_info then prints. This will
be useful in a later commit when some new MI commands will be added
which will use the worker core to fill some MI output fields.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* symtab.c (symbol_to_info_string): New function, most content
moved from print_symbol_info, but updated to return a std::string.
(print_symbol_info): Update to use symbol_to_info_string and print
returned string.
* symtab.h (symbol_to_info_string): Declare new function.
Change-Id: I6454ce43cacb61d32fbadb9e3655e70823085777
Introduce a new class to wrap up the parameters needed for the
function search_symbols, which has now become a member function of
this new class.
The motivation is that search_symbols already takes a lot of
parameters, and a future commit is going to add even more. This
commit hopefully makes collecting the state required for a search
easier.
As part of this conversion the list of filenames in which to search
has been converted to a std::vector.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* python/python.c (gdbpy_rbreak): Convert to using
global_symbol_searcher.
* symtab.c (file_matches): Convert return type to bool, change
file list to std::vector, update header comment.
(search_symbols): Rename to...
(global_symbol_searcher::search): ...this and update now its
a member function of global_symbol_searcher. Take account of the
changes to file_matches.
(symtab_symbol_info): Convert to using global_symbol_searcher.
(rbreak_command): Likewise.
(search_module_symbols): Likewise.
* symtab.h (enum symbol_search): Update comment.
(search_symbols): Remove declaration.
(class global_symbol_searcher): New class.
Change-Id: I488ab292a892d9e9e84775c632c5f198b6ad3710
Christian pointed out on irc that the threading series broke the build
on mingw. This patch fixes the problem, by moving the initialization
of gdb_demangle_attempt_core_dump into the appropriate #if.
gdb/ChangeLog
2019-11-26 Tom Tromey <tromey@adacore.com>
* cp-support.c (_initialize_cp_support): Conditionally initialize
gdb_demangle_attempt_core_dump.
Change-Id: I9ace0bea75a51f317ea933b607f6b5a94d651eea
This adds a "name_allocated" field to cmd_list_element, so that
commands can own their "name" when necessary. Then, this changes a
few spots in gdb that currently free the name by hand to instead use
this facility.
gdb/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* python/py-function.c (fnpy_init): Update.
* value.h (add_internal_function): Adjust declaration.
* value.c (function_destroyer): Remove.
(do_add_internal_function): Don't set destroyer or copy name.
(add_internal_function): Take unique_xmalloc_ptr<char> for name.
Set name_allocated.
* python/py-cmd.c (cmdpy_destroyer): Don't free "name".
(cmdpy_init): Set name_allocated.
* cli/cli-decode.h (struct cmd_list_element) <name_allocated>: New
member.
(~cmd_list_element): Free "name" if needed.
Change-Id: Ie1435cea5bbf4bd92056125f112917c607cbb761
add_internal_function sets a command destroyer that frees the doc
string. However, many callers do not pass in an allocated doc string.
This adds a new overload to clearly differentiate the two cases,
fixing the latent bug.
gdb/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* value.h (add_internal_function): Add new overload. Move
documentation from value.h.
* value.c (do_add_internal_function): New function.
(add_internal_function): Use it. Add new overload.
(function_destroyer): Don't free doc.
* python/py-function.c (fnpy_init): Update.
Change-Id: I3f6df925bc6b3e1bccbad9eeebc487b908bb5a2a
Python commands manage their "doc" string manually, but
cmd_list_element already has doc_allocated to handle this case. This
changes the Python code to use the existing facility.
gdb/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* python/py-cmd.c (cmdpy_destroyer): Don't free "doc".
(cmdpy_init): Set "doc_allocated".
Change-Id: I0014edc117b051bba1f4db267687d231e7fe9b56
This adds some configury so that gdb can set the names of worker
threads. This makes them show up more nicely when debugging gdb
itself.
2019-11-26 Tom Tromey <tom@tromey.com>
* gdbsupport/thread-pool.c (thread_pool::set_thread_count): Set
name of worker thread.
* gdbsupport/common.m4 (GDB_AC_COMMON): Check for
pthread_setname_np.
* configure, config.in: Rebuild.
gdb/gdbserver/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* configure, config.in: Rebuild.
Change-Id: I60473d65ae9ae14d8c56ddde39684240c16aaf35
This changes gdb.post_event to use the new run_on_main_thread
function. This is somewhat tricky because the Python GIL must be held
while manipulating reference counts.
2019-11-26 Tom Tromey <tom@tromey.com>
* python/python.c (class gdbpy_gil): New.
(struct gdbpy_event): Add constructor, destructor, operator().
(gdbpy_post_event): Use run_on_main_thread.
(gdbpy_initialize_events): Remove.
(do_start_initialization): Update.
Change-Id: Ie4431e60f328dae48bd96b6c6a8e875e70bda1de
This adds maint commands to control the number of worker threads that
gdb can use.
2019-11-26 Tom Tromey <tom@tromey.com>
* NEWS: Add entry.
* maint.c (_initialize_maint_cmds): Add "worker-threads" maint
commands. Call update_thread_pool_size.
(update_thread_pool_size, maintenance_set_worker_threads): New
functions.
(n_worker_threads): New global.
gdb/doc/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Maintenance Commands): Document new maint
commands.
Change-Id: I4fb514faa05879d8afe62c77036a4469d57dca2a
This patch introduces a simple parallel for_each and changes the
minimal symbol reader to use it when computing the demangled name for
a minimal symbol. This yields a speedup when reading minimal symbols.
2019-11-26 Christian Biesinger <cbiesinger@google.com>
Tom Tromey <tom@tromey.com>
* minsyms.c (minimal_symbol_reader::install): Use
parallel_for_each.
* gdbsupport/parallel-for.h: New file.
* Makefile.in (HFILES_NO_SRCDIR): Add gdbsupport/parallel-for.h.
Change-Id: I220341f70e94dd02df5dd424272c50a5afb64978
This adds a simple thread pool to gdb. In the end, this seemed
preferable to the approach taken in an earlier version of this series;
namely, starting threads in the parallel-foreach implementation. This
approach reduces the overhead of starting new threads, and also lets
the user control (in a subsequent patch) exactly how many worker
threads are running.
gdb/ChangeLog
2019-11-26 Christian Biesinger <cbiesinger@google.com>
Tom Tromey <tom@tromey.com>
* gdbsupport/thread-pool.h: New file.
* gdbsupport/thread-pool.c: New file.
* Makefile.in (COMMON_SFILES): Add thread-pool.c.
(HFILES_NO_SRCDIR): Add thread-pool.h.
Change-Id: I597bb642780cb9d578ca92373d2a638efb44fe52
The gdb demangler installs a SIGSEGV handler in order to protect gdb
from demangler bugs. However, this is not thread-safe, as signal
handlers are global to the process.
This patch changes gdb to always install a global SIGSEGV handler, and
then lets threads indicate their interest in handling the signal by
setting a thread-local variable.
This patch then arranges for the demangler code to use this; being
sure to arrange for calls to warning and the like to be done on the
main thread.
One thing I wondered while writing this patch is if there are any
systems that do not have "sigaction". If gdb could assume this, it
would simplify this code.
gdb/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* event-top.h (thread_local_segv_handler): Declare.
* event-top.c (thread_local_segv_handler): New global.
(install_handle_sigsegv, handle_sigsegv): New functions.
(async_init_signals): Install SIGSEGV handler.
* cp-support.c (gdb_demangle_jmp_buf): Change type. Now
thread-local.
(report_failed_demangle): New function.
(gdb_demangle): Make core_dump_allowed atomic. Remove signal
handler-setting code, instead use segv_handler. Run warning code
on main thread.
Change-Id: Ic832bbb033b64744e4b44f14b41db7e4168ce427
This introduces a way for a callback to be run on the main thread.
gdb/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* run-on-main-thread.c: New file.
* run-on-main-thread.h: New file.
* unittests/main-thread-selftests.c: New file.
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Add
main-thread-selftests.c.
(HFILES_NO_SRCDIR): Add run-on-main-thread.h.
(COMMON_SFILES): Add run-on-main-thread.c.
Change-Id: I16ef82f0564e9f8a524bdc64cb31df79a988ad9f
This introduces a new RAII class that temporarily installs an
alternate signal stack (on systems that have sigaltstack); then
changes the one gdb use of sigaltstack to use this class instead.
This will be used in a later patch, when creating new threads that may
want to handle SIGSEGV.
gdb/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* main.c (setup_alternate_signal_stack): Remove.
(captured_main_1): Use gdb::alternate_signal_stack.
* gdbsupport/alt-stack.h: New file.
Change-Id: I721c047ae9d51a35fd274a6dbc00a58c6440dae6
This adds configury support and an RAII class that can be used to
temporarily block signals that are used by gdb. (This class is not
used in this patch, but it split out for easier review.)
The idea of this patch is that these signals should only be delivered
to the main thread. So, when creating a background thread, they are
temporarily blocked; the blocked state is inherited by the new thread.
The sigprocmask man page says:
The use of sigprocmask() is unspecified in a multithreaded
process; see pthread_sigmask(3).
This patch changes gdb to use pthread_sigmask when appropriate, by
introducing a convenience define.
I've updated gdbserver as well, because I had to touch gdbsupport, and
because the threading patches will make it link against the thread
library.
I chose not to touch the NTO code, because I don't know anything about
that platform and because I cannot test it.
Finally, this modifies an existing spot in the Guile layer to use the
new facility.
gdb/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* gdbsupport/signals-state-save-restore.c (original_signal_mask):
Remove comment.
(save_original_signals_state, restore_original_signals_state): Use
gdb_sigmask.
* linux-nat.c (block_child_signals, restore_child_signals_mask)
(_initialize_linux_nat): Use gdb_sigmask.
* guile/guile.c (_initialize_guile): Use block_signals.
* Makefile.in (HFILES_NO_SRCDIR): Add gdb-sigmask.h.
* gdbsupport/gdb-sigmask.h: New file.
* event-top.c (async_sigtstp_handler): Use gdb_sigmask.
* cp-support.c (gdb_demangle): Use gdb_sigmask.
* gdbsupport/common.m4 (GDB_AC_COMMON): Check for
pthread_sigmask.
* configure, config.in: Rebuild.
* gdbsupport/block-signals.h: New file.
gdb/gdbserver/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* remote-utils.c (block_unblock_async_io): Use gdb_sigmask.
* linux-low.c (linux_wait_for_event_filtered, linux_async): Use
gdb_sigmask.
* configure, config.in: Rebuild.
Change-Id: If3f37dc57dd859c226e9e4d79458a0514746e8c6
This adds a configure check for std::thread. This is needed because
std::thread is not available on some systems, like some versions of
mingw and DJGPP.
This also adds configury to make sure that a threaded gdb links
against the correct threading library (-lpthread or the like), and
passes the right flags (e.g., -pthread) to the compilations.
Note that this also links gdbserver against the thread library. This
is not strictly necessary at this point in the series, but a later
patch will change gdbsupport to use pthread_sigmask, at which point
this will be needed.
gdb/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* acinclude.m4: Include ax_pthread.m4.
* Makefile.in (PTHREAD_CFLAGS, PTHREAD_LIBS): New variables.
(INTERNAL_CFLAGS_BASE): Use PTHREAD_CFLAGS.
(CLIBS): Use PTHREAD_LIBS.
(aclocal_m4_deps): Add ax_pthread.m4.
* config.in, configure: Rebuild.
* gdbsupport/common.m4 (GDB_AC_COMMON): Check for std::thread.
gdb/gdbserver/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* Makefile.in (PTHREAD_CFLAGS, PTHREAD_LIBS): New variables.
(INTERNAL_CFLAGS_BASE): Use PTHREAD_CFLAGS.
(GDBSERVER_LIBS): Use PTHREAD_LIBS.
* acinclude.m4: Include ax_pthread.m4.
* config.in, configure: Rebuild.
Change-Id: I00ec55db6077f2615421a93461fc3be57e916aa0
Currently the demangled name of a minimal symbol is set when creating
the symbol. However, there is no intrinsic need to do this. This
patch instead arranges for the demangling to be done just before the
minsym hash tables are filled. This will be useful in a later patch.
gdb/ChangeLog
2019-11-26 Tom Tromey <tom@tromey.com>
* symtab.h (struct minimal_symbol) <name_set>: New member.
* minsyms.c (minimal_symbol_reader::record_full): Copy name.
Don't call symbol_set_names.
(minimal_symbol_reader::install): Call symbol_set_names.
Change-Id: I4fe3993b99fb3a43968067806e294d48e377fd76
When running GDB tests under Valgrind, various tests are failing due
to invalid memory access.
Here is the stack trace reported by Valgrind, for gdb.base/freebpcmd.exp :
==18658== Invalid read of size 8
==18658== at 0x7F9107: is_main (signalmodule.c:195)
==18658== by 0x7F9107: PyOS_InterruptOccurred (signalmodule.c:1730)
==18658== by 0x3696E2: check_quit_flag() (extension.c:829)
==18658== by 0x36980B: restore_active_ext_lang(active_ext_lang_state*) (extension.c:782)
==18658== by 0x48F617: gdbpy_enter::~gdbpy_enter() (python.c:235)
==18658== by 0x47BB71: add_thread_object(thread_info*) (object.h:470)
==18658== by 0x53A84D: operator() (std_function.h:687)
==18658== by 0x53A84D: notify (observable.h:106)
==18658== by 0x53A84D: add_thread_silent(ptid_t) (thread.c:311)
==18658== by 0x3CD954: inf_ptrace_target::create_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&
, char**, int) (inf-ptrace.c:139)
==18658== by 0x3FE644: linux_nat_target::create_inferior(char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&,
char**, int) (linux-nat.c:1094)
==18658== by 0x3D5727: run_command_1(char const*, int, run_how) (infcmd.c:633)
==18658== by 0x2C05D1: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1948)
==18658== by 0x53F29F: execute_command(char const*, int) (top.c:639)
==18658== by 0x3638EB: command_handler(char const*) (event-top.c:586)
==18658== by 0x36468C: command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) (event-top.c:771)
==18658== by 0x36407C: gdb_rl_callback_handler(char*) (event-top.c:217)
==18658== by 0x5B2A1F: rl_callback_read_char (callback.c:281)
==18658== by 0x36346D: gdb_rl_callback_read_char_wrapper_noexcept() (event-top.c:175)
==18658== by 0x363F70: gdb_rl_callback_read_char_wrapper(void*) (event-top.c:192)
==18658== by 0x3633AF: stdin_event_handler(int, void*) (event-top.c:514)
==18658== by 0x362504: gdb_wait_for_event (event-loop.c:857)
==18658== by 0x362504: gdb_wait_for_event(int) (event-loop.c:744)
==18658== by 0x362676: gdb_do_one_event() [clone .part.11] (event-loop.c:321)
==18658== by 0x3627AD: gdb_do_one_event (event-loop.c:303)
==18658== by 0x3627AD: start_event_loop() (event-loop.c:370)
==18658== by 0x41D35A: captured_command_loop() (main.c:381)
==18658== by 0x41F2A4: captured_main (main.c:1224)
==18658== by 0x41F2A4: gdb_main(captured_main_args*) (main.c:1239)
==18658== by 0x227D0A: main (gdb.c:32)
==18658== Address 0x10 is not stack'd, malloc'd or (recently) free'd
The problem seems to be created by gdbpy_enter::~gdbpy_enter () releasing the GIL lock
too early:
~gdbpy_enter () does:
...
PyGILState_Release (m_state);
python_gdbarch = m_gdbarch;
python_language = m_language;
restore_active_ext_lang (m_previous_active);
}
So, it releases the GIL lock, does 2 assignments and then leads to the following
call sequence:
restore_active_ext_lang => check_quit_flag => python.c gdbpy_check_quit_flag
=> PyOS_InterruptOccurred => is_main.
is_main code is:
static int
is_main(_PyRuntimeState *runtime)
{
unsigned long thread = PyThread_get_thread_ident();
PyInterpreterState *interp = _PyRuntimeState_GetThreadState(runtime)->interp;
return (thread == runtime->main_thread
&& interp == runtime->interpreters.main);
}
The macros and functions to access the thread state are documented as:
/* Variable and macro for in-line access to current thread
and interpreter state */
#define _PyRuntimeState_GetThreadState(runtime) \
((PyThreadState*)_Py_atomic_load_relaxed(&(runtime)->gilstate.tstate_current))
/* Get the current Python thread state.
Efficient macro reading directly the 'gilstate.tstate_current' atomic
variable. The macro is unsafe: it does not check for error and it can
return NULL.
The caller must hold the GIL.
See also PyThreadState_Get() and PyThreadState_GET(). */
#define _PyThreadState_GET() _PyRuntimeState_GetThreadState(&_PyRuntime)
So, we see that GDB releases the GIL and then potentially calls
_PyRuntimeState_GetThreadState that needs the GIL.
It is not very clear why the problem is only observed when running under
Valgrind. Probably caused by the slowdown due to Valgrind and/or to the 'single
thread' scheduling by Valgrind.
This patch fixes the crashes by releasing the GIT lock later.
2019-11-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* python/python.c (gdbpy_enter::~gdbpy_enter): Release GIL after
restore_active_ext_lang, as GIL is needed for (indirectly)
called PyOS_InterruptOccurred.
When building sparc-nat.c with -Wmissing-declarations, we get:
CXX sparc-nat.o
/home/smarchi/src/binutils-gdb/gdb/sparc-nat.c: In function ‘target_xfer_status sparc_xfer_wcookie(target_ops*, target_object, const char*, gdb_byte*, const gdb_byte*, ULONGEST, ULONGEST, ULONGEST*)’:
/home/smarchi/src/binutils-gdb/gdb/sparc-nat.c:255:1: error: no previous declaration for ‘target_xfer_status sparc_xfer_wcookie(target_ops*, target_object, const char*, gdb_byte*, const gdb_byte*, ULONGEST, ULONGEST, ULONGEST*)’ [-Werror=missing-declarations]
sparc_xfer_wcookie (struct target_ops *ops, enum target_object object,
^~~~~~~~~~~~~~~~~~
Indeed, the declaration is not in sync with the definition, fix that.
sparc_xfer_wcookie is used in sparc_target::xfer_partial. sparc_target
is only used in the BSD sparc native files. The error above was
obtained by running "make sparc-nat.o" on Linux with a cross-compiler
for sparc64-linux-gnu. But I presume that if we were to build for real
with a BSD/sparc compiler, we would end up with an undefined symbol.
gdb/ChangeLog:
* sparc-nat.c (sparc_xfer_wcookie): Sync declaration with
definition.
Change-Id: Id41e706e5516968ff6a49469ddc48eceb29dd3ea
The simulator_command function is not used outside its file, so make it
static. Remove the declaration, which is not needed and not even in
sync with the definition.
gdb/ChangeLog:
* remote-sim.c (simulator_command): Make static, remove
declaration.
Change-Id: I40bd1e3662f849c4c9970443931ab9ee0ccccea1
The declaration of tui_set_var_cmd is not in sync with the definition.
Since tui_set_var_cmd is only used in the file where it's defined,
remove the declaration and make the definition static.
gdb/ChangeLog:
* tui-win.h (tui_set_var_cmd): Remove.
* tui-win.c (tui_set_var_cmd): Make static.
Change-Id: If4bddbfb573347fb7254fb6f1a940052a72f464f
rbreak_command_wrapper is unused, so remove it. And while at it, remove
other declarations around it.
gdb/ChangeLog:
* breakpoint.h (hbreak_command_wrapper, thbreak_command_wrapper,
rbreak_command_wrapper): Remove.
* symtab.c (rbreak_command_wrapper): Remove.
Change-Id: If9782f205e4913f8dfc5beeaa526544f25e099c6
The info_terminal_command declaration in inflow.h does not match the
current definition. It is not needed anyway, as info_terminal_command
is only used locally, so remove it and make the definition static.
gdb/ChangeLog:
* inferior.h (info_terminal_command): Remove declaration.
* inflow.c (info_terminal_command): Make static.
Change-Id: I22c3fcc44244e3cf877b5e27eff189af11c39503
This function is not used in the code base.
gdb/ChangeLog:
* inferior.c (exit_inferior_silent): Remove.
Change-Id: Ib2b7662744da079185ceac2a165b47590bd3113c
These functions are not used in the code base, remove them.
gdb/ChangeLog:
* dictionary.c (dict_empty, mdict_empty): Remove.
* dictionary.c (mdict_empty): Remove.
Change-Id: I4c1b08c730f6790b2f3d28b680607618e3c08e48
The following errors show that these files are missing the include of
their matching header, add them.
CXX dwarf-index-write.o
/home/smarchi/src/binutils-gdb/gdb/dwarf-index-write.c: In function ‘void write_psymtabs_to_index(dwarf2_per_objfile*, const char*, const char*, const char*, dw_index_kind)’:
/home/smarchi/src/binutils-gdb/gdb/dwarf-index-write.c:1670:1: error: no previous declaration for ‘void write_psymtabs_to_index(dwarf2_per_objfile*, const char*, const char*, const char*, dw_index_kind)’ [-Werror=missing-declarations]
write_psymtabs_to_index (struct dwarf2_per_objfile *dwarf2_per_objfile,
^~~~~~~~~~~~~~~~~~~~~~~
CXX mi/mi-interp.o
/home/smarchi/src/binutils-gdb/gdb/mi/mi-interp.c: In function ‘void mi_output_solib_attribs(ui_out*, so_list*)’:
/home/smarchi/src/binutils-gdb/gdb/mi/mi-interp.c:1030:1: error: no previous declaration for ‘void mi_output_solib_attribs(ui_out*, so_list*)’ [-Werror=missing-declarations]
mi_output_solib_attribs (ui_out *uiout, struct so_list *solib)
^~~~~~~~~~~~~~~~~~~~~~~
gdb/ChangeLog:
* dwarf-index-write.c: Include dwarf-index-write.h.
* mi/mi-interp.c: Include mi/mi-interp.h.
Change-Id: I0103b8669e16e0fcaa476f8c5e96f49608157745
The error below shows that aarch32-tdep.c is missing an include for
aarch32-tdep.h, add it.
CXX aarch32-tdep.o
/home/smarchi/src/binutils-gdb/gdb/aarch32-tdep.c: In function ‘const target_desc* aarch32_read_description()’:
/home/smarchi/src/binutils-gdb/gdb/aarch32-tdep.c:27:1: error: no previous declaration for ‘const target_desc* aarch32_read_description()’ [-Werror=missing-declarations]
aarch32_read_description ()
^~~~~~~~~~~~~~~~~~~~~~~~
Putting the include of aarch32-tdep.h early in aarch32-tdep.c gives us
an error about target_desc not being defined. Indeed, aarch32-tdep.h
uses target_desc without forward-declaring it or including the proper
header. Add a forward-declaration for it.
gdb/ChangeLog:
* aarch32-tdep.c: Include aarch32-tdep.h.
* aarch32-tdep.h: Forward-declare struct target_desc.
Change-Id: Ica4be4de0fbd7f22d56a29a40fbf0a31b5abdb16
This provides threadsafety. Unfortunately, since libinproctrace.so
does not link to gnulib, we can't use it there, especially since it
still includes the gnulib headers (so it is difficult to directly
call the system strerror_r).
gdb/ChangeLog:
2019-11-26 Christian Biesinger <cbiesinger@google.com>
* linux-nat.c (detach_one_lwp): Call safe_strerror instead of
strerror.
* nto-procfs.c (nto_procfs_target::create_inferior): Likewise.
* windows-nat.c (windows_nat_target::create_inferior): Likewise.
gdb/gdbserver/ChangeLog:
2019-11-26 Christian Biesinger <cbiesinger@google.com>
* debug.c (debug_set_output): Call safe_strerror instead of
strerror.
* linux-low.c (attach_proc_task_lwp_callback): Likewise.
(linux_kill_one_lwp): Likewise.
(linux_detach_one_lwp): Likewise.
(linux_wait_for_event_filtered): Likewise.
(store_register): Likewise.
* lynx-low.c (lynx_attach): Likewise.
* mem-break.c (insert_memory_breakpoint): Likewise.
(remove_memory_breakpoint): Likewise.
(delete_fast_tracepoint_jump): Likewise.
(set_fast_tracepoint_jump): Likewise.
(uninsert_fast_tracepoint_jumps_at): Likewise.
(reinsert_fast_tracepoint_jumps_at): Likewise.
* nto-low.c (nto_xfer_memory): Likewise.
(nto_resume): Likewise.
Change-Id: I9e259cdcaa6e11bbcc4ee6bdc5b7127d73e11abe
Christian pointed out that I had accidentally put a ChangeLog entry
into gdbserver that was meant for testsuite.
I'm checking in this patch to fix it.
Change-Id: Iba6124cea6f63539ad66494d3355fb657b78a66d
The words.sh script in its current form extracts c comments from files, which
it then transforms into a list of words.
To use the script on the documentation (as I did for commit 6b92c0d353
"[gdb/doc] Fix typos"), I needed to disable the "extract c comments" part.
Add an option -c that enables extracting c comments, and is off by default.
gdb/ChangeLog:
2019-11-25 Tom de Vries <tdevries@suse.de>
* contrib/words.sh: Add -c option.
Change-Id: Ifa34d435b3c41b3ff845dc07ae4b0d9f02d92a2d
This does not touch "int from_tty" and a couple of other instances
that require a bigger change.
gdb/ChangeLog:
2019-11-25 Christian Biesinger <cbiesinger@google.com>
* solib.c (solib_find_1): Change int to bool.
(exec_file_find): Change int to bool.
(solib_find): Change int to bool.
(solib_read_symbols): Change int to bool.
(solib_used): Change int to bool.
(solib_add): Change int to bool.
(info_sharedlibrary_command): Change int to bool.
(solib_contains_address_p): Change int to bool.
(solib_keep_data_in_core): Change int to bool.
(in_solib_dynsym_resolve_code): Change int to bool.
(reload_shared_libraries_1): Change int to bool.
(gdb_sysroot_changed): Change int to bool.
* solib.h (solib_read_symbols): Change int to bool.
(solib_contains_address_p): Change int to bool.
(solib_keep_data_in_core): Change int to bool.
(in_solib_dynsym_resolve_code): Change int to bool.
(libpthread_name_p): Change int to bool.
Change-Id: Id695ed4ed0c3526af477d4d2bf585a7193c36cab
While debugging, i felt the need to adjust the truncation length of remote
packets so i could see more or less data as needed. The default is currently
set to 512 bytes.
This patch makes this option adjustable through the new "set debug
remote-packet-max-chars" command. It can be set to unlimited if we want to
completely disable truncation.
Update on v5:
- Adjusted function and variable documentation, NEWS entry and GDB manual.
gdb/ChangeLog:
2019-11-25 Luis Machado <luis.machado@linaro.org>
* NEWS (New Commands): Mention "set debug remote-packet-max-chars".
* remote.c (REMOTE_DEBUG_MAX_CHAR): Remove.
(remote_packet_max_chars): New static global.
(show_remote_packet_max_chars): New function.
(remote_target::putpkt_binary): Adjust to use new
remote_packet_max_chars option.
(remote_target::getpkt_or_notif_sane_1): Likewise.
(_initialize_remote): Register new remote-packet-max-chars option.
gdb/doc/ChangeLog:
2019-11-25 Luis Machado <luis.machado@linaro.org>
* gdb.texinfo (Debugging Output): Document set debug
remote-packet-max-chars.
Change-Id: I2e871b37bfcaa6376537c3fe3db8f016dd806a7c
Fix this compilation error, and a bunch of similar ones:
CXX m68k-linux-nat.o
/home/smarchi/src/binutils-gdb/gdb/m68k-linux-nat.c: In function ‘void fetch_register(regcache*, int)’:
/home/smarchi/src/binutils-gdb/gdb/m68k-linux-nat.c:133:9: error: ‘gdbarch_register_name’ was not declared in this scope
gdbarch_register_name (gdbarch, regno),
^~~~~~~~~~~~~~~~~~~~~
gdb/ChangeLog:
* m68k-linux-nat.c: Include gdbarch.h.
Change-Id: I7cd47bc5d094241b2596e29c244eb55ed11f7a02
This changes require_partial_symbols to use bool as its parameter
type.
gdb/ChangeLog
2019-11-24 Tom Tromey <tom@tromey.com>
* symfile.c (read_symbols): Update.
* psymtab.c (require_partial_symbols): Change type of "verbose" to
bool.
(psym_map_symtabs_matching_filename, find_pc_sect_psymtab)
(psym_lookup_symbol, psym_find_last_source_symtab)
(psym_forget_cached_source_info, psym_print_stats)
(psym_expand_symtabs_for_function, psym_expand_all_symtabs)
(psym_expand_symtabs_with_fullname, psym_map_symbol_filenames)
(psym_map_matching_symbols, psym_expand_symtabs_matching)
(psym_find_compunit_symtab_by_address)
(maintenance_print_psymbols, maintenance_info_psymtabs)
(maintenance_check_psymtabs): Update.
* psymtab.h (require_partial_symbols): Change type of "verbose" to
bool.
Change-Id: Iae87aa5e4590706bb9e90a33adb86f1fe0fbf3c7
Ages ago, when we switched observables to be templates, Joel asked me
to restore the parameter names that were used in the old
observer.texi.
I've finally done this, putting the names into comments. I also
updated the comments in this file to use the GNU metasyntactic
variable convention as well.
gdb/ChangeLog
2019-11-22 Tom Tromey <tom@tromey.com>
* observable.h: Update comments.
Change-Id: Id71bea7a7fcaa8f5d4491f33aa8861c56ba9c3f0
In MI mode, print_ada_task_info can crash in find_thread_ptid when
trying to print an Ada task that is no longer alive. This patch
avoids the problem by checking for this case.
Because this is Ada-specific, and because Joel approved it internally,
I am checking it in.
gdb/ChangeLog
2019-11-22 Tom Tromey <tromey@adacore.com>
* ada-tasks.c (ada_task_is_alive): Make parameter const.
(print_ada_task_info): Don't try to fetch thread id if task is not
alive.
gdb/gdbserver/ChangeLog
2019-11-22 Tom Tromey <tromey@adacore.com>
* gdb.ada/tasks.exp: Add -ada-task-info regression test.
* gdb.ada/tasks/foo.adb: Add another stopping location.
Change-Id: If25eae6507eebb7537eb8adbcbaa1fc1eec88f5c
If we have a minsym count, we know the demangled names hashtable will
be at least that big. So use that count to size it, so we don't
have to resize/rehash it as much.
This is a 6% improvement in minsym loading time.
2019-11-22 Christian Biesinger <cbiesinger@google.com>
* symtab.c (create_demangled_names_hash): Use per_bfd->
minimal_symbol_count for computing the initial size, if greater
than our default size.
Change-Id: I1f074d38e1d90af58705ec852f90c84cc034cd2e
Remove more punctuation and quoting in words.sh script.
gdb/ChangeLog:
2019-11-22 Tom de Vries <tdevries@suse.de>
* contrib/words.sh: Improve words extraction.
Change-Id: I1d9eea165731af4e6c4e1c7e09aed9b07af6395c
Currently running words.sh on all the c source and header files in the repo
takes ~16s in user time:
...
$ time ./gdb/contrib/words.sh \
$(find -type f -name "*.c" -o -name "*.h") \
>/dev/null
real 0m7,787s
user 0m16,349s
sys 0m0,367s
...
Rewrite the sed invocations using the -e option from this:
...
| sed <sedprog1>
| sed <sedprog2>
...
into this:
...
| sed \
-e <sedprog1>
-e <sedprog2>
...
and reduce user time to ~11s:
...
$ time ./gdb/contrib/words.sh \
$(find -type f -name "*.c" -o -name "*.h") \
>/dev/null
real 0m7,243s
user 0m11,220s
sys 0m0,205s
...
gdb/ChangeLog:
2019-11-22 Tom de Vries <tdevries@suse.de>
* contrib/words.sh: Combine sed invocations.
Change-Id: Ib08453f3712f32ed02d9f503ee960711ebb9421b
In addition to renaming demangle.c to match the header file naming,
this also makes is_cplus_marker return a bool and removes a duplicate
declaration of "bool demangle" from symtab.h.
gdb/ChangeLog:
2019-11-21 Christian Biesinger <cbiesinger@google.com>
* Makefile.in: Update.
* demangle.c: Rename to...
* gdb-demangle.c: ..this.
(is_cplus_marker): Change return type to bool.
(_initialize_demangler): Rename to...
(_initialize_gdb_demangle): ...this.
* gdb-demangle.h (is_cplus_marker): Change return type to bool.
* symtab.h (demangle): Remove declaration; instead include
gdb-demangle.h.
Change-Id: I83c3b3f7ee71b2bf6f5b5d0f9eb1d4b5208f2a97
We found a bug internally where gdb would crash while disassembling a
certain instruction. This was tracked down to the handling of %I64d
in format_pieces.
format_pieces will convert %ll to %I64d on mingw -- so format_pieces
should also handle parsing this format. In this patch, I've made the
parsing unconditional, since I think it is harmless to accept extra
formats. I've also taken the opportunity to convert the length
modifier test to a "switch".
Tested internally using our failing test case.
gdb/ChangeLog
2019-11-21 Tom Tromey <tromey@adacore.com>
* gdbsupport/format.c (format_pieces): Parse %I64d.
* unittests/format_pieces-selftests.c (test_windows_formats): New
function.
(run_tests): Call it.
Change-Id: If335c7c2fc8d01e629cd55182394a483334d79c7
- Rationale:
It is possible for compilers to indicate the desired byte order
interpretation of scalar variables using the DWARF attribute:
DW_AT_endianity
A type flagged with this variable would typically use one of:
DW_END_big
DW_END_little
which instructs the debugger what the desired byte order interpretation
of the variable should be.
The GCC compiler (as of V6) has a mechanism for setting the desired byte
ordering of the fields within a structure or union. For, example, on a
little endian target, a structure declared as:
struct big {
int v;
short a[4];
} __attribute__( ( scalar_storage_order( "big-endian" ) ) );
could be used to ensure all the structure members have a big-endian
interpretation (the compiler would automatically insert byte swap
instructions before and after respective store and load instructions).
- To reproduce
GCC V8 is required to correctly emit DW_AT_endianity DWARF attributes
in all situations when the scalar_storage_order attribute is used.
A fix for (dwarf endianity instrumentation) for GCC V6-V7 can be found
in the URL field of the following PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82509
- Test-case:
A new test case (testsuite/gdb.base/endianity.*) is included with this
patch.
Manual testing for mixed endianity code has also been done with GCC V8.
See:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82509#c4
- Observed vs. expected:
Without this change, using scalar_storage_order that doesn't match the
target, such as
struct otherendian
{
int v;
} __attribute__( ( scalar_storage_order( "big-endian" ) ) );
would behave like the following on a little endian target:
Breakpoint 1 at 0x401135: file endianity.c, line 41.
(gdb) run
Starting program: /home/pjoot/freeware/t/a.out
Missing separate debuginfos, use: debuginfo-install glibc-2.17-292.el7.x86_64
Breakpoint 1, main () at endianity.c:41
41 struct otherendian o = {3};
(gdb) n
43 do_nothing (&o); /* START */
(gdb) p o
$1 = {v = 50331648}
(gdb) p /x
$2 = {v = 0x3000000}
whereas with this gdb enhancement we can access the variable with the user
specified endianity:
Breakpoint 1, main () at endianity.c:41
41 struct otherendian o = {3};
(gdb) p o
$1 = {v = 0}
(gdb) n
43 do_nothing (&o); /* START */
(gdb) p o
$2 = {v = 3}
(gdb) p o.v = 4
$3 = 4
(gdb) p o.v
$4 = 4
(gdb) x/4xb &o.v
0x7fffffffd90c: 0x00 0x00 0x00 0x04
(observe that the 4 byte int variable has a big endian representation in the
hex dump.)
gdb/ChangeLog
2019-11-21 Peeter Joot <peeter.joot@lzlabs.com>
Byte reverse display of variables with DW_END_big, DW_END_little
(DW_AT_endianity) dwarf attributes if different than the native
byte order.
* ada-lang.c (ada_value_binop):
Use type_byte_order instead of gdbarch_byte_order.
* ada-valprint.c (printstr):
(ada_val_print_string):
* ada-lang.c (value_pointer):
(ada_value_binop):
Use type_byte_order instead of gdbarch_byte_order.
* c-lang.c (c_get_string):
Use type_byte_order instead of gdbarch_byte_order.
* c-valprint.c (c_val_print_array):
Use type_byte_order instead of gdbarch_byte_order.
* cp-valprint.c (cp_print_class_member):
Use type_byte_order instead of gdbarch_byte_order.
* dwarf2loc.c (rw_pieced_value):
Use type_byte_order instead of gdbarch_byte_order.
* dwarf2read.c (read_base_type): Handle DW_END_big,
DW_END_little
* f-lang.c (f_get_encoding):
Use type_byte_order instead of gdbarch_byte_order.
* findvar.c (default_read_var_value):
Use type_byte_order instead of gdbarch_byte_order.
* gdbtypes.c (check_types_equal):
Require matching TYPE_ENDIANITY_NOT_DEFAULT if set.
(recursive_dump_type): Print TYPE_ENDIANITY_BIG,
and TYPE_ENDIANITY_LITTLE if set.
(type_byte_order): new function.
* gdbtypes.h (TYPE_ENDIANITY_NOT_DEFAULT): New macro.
(struct main_type) <flag_endianity_not_default>:
New field.
(type_byte_order): New function.
* infcmd.c (default_print_one_register_info):
Use type_byte_order instead of gdbarch_byte_order.
* p-lang.c (pascal_printstr):
Use type_byte_order instead of gdbarch_byte_order.
* p-valprint.c (pascal_val_print):
Use type_byte_order instead of gdbarch_byte_order.
* printcmd.c (print_scalar_formatted):
Use type_byte_order instead of gdbarch_byte_order.
* solib-darwin.c (darwin_current_sos):
Use type_byte_order instead of gdbarch_byte_order.
* solib-svr4.c (solib_svr4_r_ldsomap):
Use type_byte_order instead of gdbarch_byte_order.
* stap-probe.c (stap_modify_semaphore):
Use type_byte_order instead of gdbarch_byte_order.
* target-float.c (target_float_same_format_p):
Use type_byte_order instead of gdbarch_byte_order.
* valarith.c (scalar_binop):
(value_bit_index):
Use type_byte_order instead of gdbarch_byte_order.
* valops.c (value_cast):
Use type_byte_order instead of gdbarch_byte_order.
* valprint.c (generic_emit_char):
(generic_printstr):
(val_print_string):
Use type_byte_order instead of gdbarch_byte_order.
* value.c (unpack_long):
(unpack_bits_as_long):
(unpack_value_bitfield):
(modify_field):
(pack_long):
(pack_unsigned_long):
Use type_byte_order instead of gdbarch_byte_order.
* findvar.c (unsigned_pointer_to_address):
(signed_pointer_to_address):
(unsigned_address_to_pointer):
(address_to_signed_pointer):
(default_read_var_value):
(default_value_from_register):
Use type_byte_order instead of gdbarch_byte_order.
* gnu-v3-abi.c (gnuv3_make_method_ptr):
Use type_byte_order instead of gdbarch_byte_order.
* riscv-tdep.c (riscv_print_one_register_info):
Use type_byte_order instead of gdbarch_byte_order.
gdb/testsuite/ChangeLog
2019-11-21 Peeter Joot <peeter.joot@lzlabs.com>
* gdb.base/endianity.c: New test.
* gdb.base/endianity.exp: New file.
Change-Id: I4bd98c1b4508c2d7c5a5dbb15d7b7b1cb4e667e2
I think it would be clearer to not use gen_ret_current_ui_field_ptr to
generate the implementation of current_ui_gdb_stdout_ptr et al. It
doesn't save much code, but adds a layer of complexity for the reader.
Plus, it doesn't work well with IDEs, for example if you ask to find all
usages the m_gdb_stdout field.
gdb/ChangeLog:
* top.c (current_ui_gdb_stdout_ptr): Spell out by hand.
(current_ui_gdb_stdin_ptr): Likewise.
(current_ui_gdb_stderr_ptr): Likewise.
(current_ui_gdb_stdlog_ptr): Likewise.
(current_ui_current_uiout_ptr): Likewise.
(gen_ret_current_ui_field_ptr): Remove.
Change-Id: I86f821c9d119453701caedf0e47124ccddfbab2d
The problem reported in PR mi/25055 is that the output of the backtrace
command, when executed as breakpoint command does not show when executing
using the MI interpreter:
...
$ gdb a.out
Reading symbols from a.out...
(gdb) break main
Breakpoint 1 at 0x4003c0: file test.c, line 19.
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>bt
>end
(gdb) interpreter-exec mi "-exec-run"
^done
Breakpoint 1, main () at test.c:19
19 return foo (4);
(gdb)
...
Interestingly, the function print_frame is called twice during -exec-run:
- once during tui_on_normal_stop where the ui_out is temporarily set to
tui->interp_ui_out (), resulting in the part after the comma in
"Breakpoint 1, main () at test.c:19"
- once during execute_control_command, where the ui_out is the default for the
current interpreter: mi_ui_out, which ignores calls to output text.
The commit 3a87ae656c "Use console uiout when executing breakpoint commands"
fixes the problem by temporarily switching to the ui_out of INTERP_CONSOLE in
execute_control_command.
This however caused a regression in redirection (escaping '#' using '\' for
git commit message convenience):
...
$ rm -f gdb.txt; gdb a.out
Reading symbols from a.out...
(gdb) break main
Breakpoint 1 at 0x4003c0: file test.c, line 19.
(gdb) commands
Type commands for breakpoint(s) 1, one per line.
End with a line saying just "end".
>bt
>end
(gdb) set logging redirect on
(gdb) set logging on
Redirecting output to gdb.txt.
Copying debug output to gdb.txt.
(gdb) run
\#0 main () at test.c:19
(gdb) q
A debugging session is active.
Inferior 1 [process 22428] will be killed.
Quit anyway? (y or n) y
$ cat gdb.txt
Starting program: /data/gdb_versions/devel/a.out
Breakpoint 1, main () at test.c:19
19 return foo (4);
...
The problem is that the '#0 main () at test.c:19' ends up in the gdb output
output rather than in gdb.txt. This is due to the fact that the redirect is
setup for the current ui_out (which is tui->interp_ui_out ()), while the
backtrace output is printed to the INTERP_CONSOLE ui_out.
Fix this by limiting switching to INTERP_CONSOLE ui_out to when INTERP_MI is
active.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-11-21 Tom de Vries <tdevries@suse.de>
PR gdb/24956
* cli/cli-script.c (execute_control_command): Only switch to
INTERP_CONSOLE's ui_out when INTERP_MI is active.
gdb/testsuite/ChangeLog:
2019-11-21 Tom de Vries <tdevries@suse.de>
PR gdb/24956
* gdb.base/ui-redirect.exp: Test output of user-defined command.
Change-Id: Id1771e7fcc9496a7d97ec2b2ea6b1487596f1ef7
Commit 33d569b709 ("gdb/python: Return
None from Progspace.block_for_pc on error") added a few tests on
gdb.python/py-progspace.exp which use 'print', but forgot to use
parentheses when passing the arguments to be printed. This fails on
Python 3.
This commit adds these missing parentheses. Pushed as obvious.
gdb/testsuite/ChangeLog:
2019-11-20 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.python/py-progspace.exp: Add missing parentheses on some
'print' commands.
Change-Id: Iac0a7578855d128bbee3b98e7ea5888dae55fc00
The current code checks for the presence of a SVE target description by
comparing the number of registers. This is a bit fragile since the number
of registers can change whenever we add new sets. Like PAC, for example.
If the comparison breaks, then we're left with SVE registers in the
description, but gdbserver doesn't send the registers to GDB, which in
turn displays stale information to the user.
The following patch changes the check to use the SVE feature string instead,
which hopefully should be more stable.
gdb/gdbserver/ChangeLog:
2019-11-20 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-low.c (is_sve_tdesc): Check against target feature
instead of register count.
* tdesc.c (tdesc_contains_feature): New function.
* tdesc.h (tdesc_contains_feature): New prototype.
Change-Id: I28b782cb1677560ca9a06a1be442974b25aabae4
The "winheight" command is broken. I probably broke it in one of my
TUI refactoring patches, though I didn't track down exactly which one.
The bug is that the code does:
*buf_ptr = '\0';
... but then never advances buf_ptr past this point, so no window name
is seen.
This patch refactors the code a bit so that a copy of the argument
string is not needed, also fixing the bug.
A new test case is included.
gdb/ChangeLog
2019-11-19 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (tui_partial_win_by_name): Move from tui-data.c.
Now static. Change type of "name".
(tui_set_win_height_command): Don't copy "arg".
* tui/tui-data.h (tui_partial_win_by_name): Don't declare.
* tui/tui-data.c (tui_partial_win_by_name): Move to tui-win.c.
gdb/testsuite/ChangeLog
2019-11-19 Tom Tromey <tom@tromey.com>
* gdb.tui/winheight.exp: New file.
Change-Id: I0871e93777a70036dbec9c9543f862f42e3a81e5
When DebugActiveProcess fails, the error message is fairly generic:
error (_("Can't attach to process."));
It would be more useful for diagnosing problems if the Windows error
code was included in the message. This patch implements this.
gdb/ChangeLog
2019-11-19 Tom Tromey <tromey@adacore.com>
* windows-nat.c (windows_nat_target::attach): Include GetLastError
result in error when DebugActiveProcess fails.
Change-Id: Ie1bf502a0d96bb7c09bd5b1c5e0c924ba58cd68c
The recently added gdb.base/ctf-whatis.exp test is a slightly modified
version of gdb.base/whatis.exp, with a few tests removed, and the
source compiled with different compiler options. This patch merges
the two tests together into a single test script.
I tested using a version of GCC with CTF support added.
gdb/testsuite/ChangeLog:
* gdb.base/ctf-whatis.c: Delete.
* gdb.base/ctf-whatis.exp: Delete.
* gdb.base/whatis.exp: Rewrite to compile as both dwarf and ctf.
Change-Id: I09e11c70f197b79d2b1e0ae8c86a21c622be6c51
The recently added gdb.base/ctf-cvexpr.exp is just a copy of
gdb.base/cvexpr.exp but compiled with different options. This patch
merges these two tests together into a single test script.
I tested this change using a version of GCC with CTF support added.
gdb/testsuite/ChangeLog:
* gdb.base/ctf-cvexpr.exp: Delete.
* gdb.base/cvexpr.exp: Rewrite to compile as both dwarf and ctf.
Change-Id: If678c3e38cb444867defa970203d26563f15dba4
Most versions of GCC in the wild don't support CTF debug format right
now, so, rather than attempting to compile the tests and failing each
time, this patch introduces a guard function to check if the compiler
supports CTF. If we don't have CTF support then the CTF tests are
skipped.
This patch only updates 3 of the 4 CTF tests, the fourth will be
handled in the next patch.
gdb/testsuite/ChangeLog:
* gdb.base/ctf-constvars.exp: Skip test if CTF is not supported in
the compiler. Clean up header comment a little.
* gdb.base/ctf-ptype.exp: Likewise.
* gdb.base/ctf-whatis.exp: Likewise.
* lib/gdb.exp (skip_ctf_tests): New proc.
Change-Id: I505c11169a9bc9871a31fc0c61e119f92f32cc63
Ref.: https://bugzilla.redhat.com/show_bug.cgi?id=1765117
A segfault can happen in a specific scenario when using TUI + a
corefile, as explained in the bug mentioned above. The problem
happens when opening a corefile on GDB:
$ gdb ./core program
entering TUI (C-x a), and then issuing a "run" command. GDB segfaults
with the following stack trace:
(top-gdb) bt
#0 0x00000000004cd5da in target_ops::shortname (this=0x0) at ../../binutils-gdb/gdb/target.h:449
#1 0x0000000000ac08fb in target_shortname () at ../../binutils-gdb/gdb/target.h:1323
#2 0x0000000000ac09ae in tui_locator_window::make_status_line[abi:cxx11]() const (this=0x23e1fa0 <_locator>) at ../../binutils-gdb/gdb/tui/tui-stack.c:86
#3 0x0000000000ac1043 in tui_locator_window::rerender (this=0x23e1fa0 <_locator>) at ../../binutils-gdb/gdb/tui/tui-stack.c:231
#4 0x0000000000ac1632 in tui_show_locator_content () at ../../binutils-gdb/gdb/tui/tui-stack.c:369
#5 0x0000000000ac63b6 in tui_set_key_mode (mode=TUI_COMMAND_MODE) at ../../binutils-gdb/gdb/tui/tui.c:321
#6 0x0000000000aaf9be in tui_inferior_exit (inf=0x2d446a0) at ../../binutils-gdb/gdb/tui/tui-hooks.c:181
#7 0x000000000044cddf in std::_Function_handler<void (inferior*), void (*)(inferior*)>::_M_invoke(std::_Any_data const&, inferior*&&) (__functor=..., __args#0=@0x7fffffffd650: 0x2d446a0)
at /usr/include/c++/9/bits/std_function.h:300
#8 0x0000000000757db9 in std::function<void (inferior*)>::operator()(inferior*) const (this=0x2cf3168, __args#0=0x2d446a0) at /usr/include/c++/9/bits/std_function.h:690
#9 0x0000000000757876 in gdb::observers::observable<inferior*>::notify (this=0x23de0c0 <gdb::observers::inferior_exit>, args#0=0x2d446a0)
at ../../binutils-gdb/gdb/gdbsupport/observable.h:106
#10 0x000000000075532d in exit_inferior_1 (inftoex=0x2d446a0, silent=1) at ../../binutils-gdb/gdb/inferior.c:191
#11 0x0000000000755460 in exit_inferior_silent (inf=0x2d446a0) at ../../binutils-gdb/gdb/inferior.c:234
#12 0x000000000059f47c in core_target::close (this=0x2d68590) at ../../binutils-gdb/gdb/corelow.c:265
#13 0x0000000000a7688c in target_close (targ=0x2d68590) at ../../binutils-gdb/gdb/target.c:3293
#14 0x0000000000a63d74 in target_stack::push (this=0x23e1800 <g_target_stack>, t=0x23c38c8 <the_amd64_linux_nat_target>) at ../../binutils-gdb/gdb/target.c:568
#15 0x0000000000a63dbf in push_target (t=0x23c38c8 <the_amd64_linux_nat_target>) at ../../binutils-gdb/gdb/target.c:583
#16 0x0000000000748088 in inf_ptrace_target::create_inferior (this=0x23c38c8 <the_amd64_linux_nat_target>, exec_file=0x2d58d30 "/usr/bin/cat", allargs="", env=0x25f12b0, from_tty=1)
at ../../binutils-gdb/gdb/inf-ptrace.c:128
#17 0x0000000000795ccb in linux_nat_target::create_inferior (this=0x23c38c8 <the_amd64_linux_nat_target>, exec_file=0x2d58d30 "/usr/bin/cat", allargs="", env=0x25f12b0, from_tty=1)
at ../../binutils-gdb/gdb/linux-nat.c:1094
#18 0x000000000074eae9 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at ../../binutils-gdb/gdb/infcmd.c:639
...
The problem happens because 'tui_locator_window::make_status_line'
needs the value of 'target_shortname' in order to update the status
line. 'target_shortname' is a macro which expands to:
#define target_shortname (current_top_target ()->shortname ())
and, in our scenario, 'current_top_target ()' returns NULL, which
obviously causes a segfault. But why does it return NULL, since,
according to its comment on target.h, it should never do that?
What is happening is that we're being caught in the middle of a
"target switch". We had the 'core_target' on top, because we were
inspecting a corefile, but when the user decided to invoke "run" GDB
had to actually create the inferior, which ends up detecting that we
have a target already, and tries to close it (from target.c):
/* See target.h. */
void
target_stack::push (target_ops *t)
{
/* If there's already a target at this stratum, remove it. */
strata stratum = t->stratum ();
if (m_stack[stratum] != NULL)
{
target_ops *prev = m_stack[stratum];
m_stack[stratum] = NULL;
target_close (prev); // <-- here
}
...
When the current target ('core_target') is being closed, it checks for
possible observers registered with it and calls them. TUI is one of
those observers, it gets called, tries to update the status line, and
GDB crashes.
The real problem is that we are clearing 'm_stack[stratum]', but
forgetting to adjust 'm_top'. Interestingly, this scenario is covered
in 'target_stack::unpush', but Pedro said he forgot to call it here..
The fix, therefore, is to call '::unpush' if there's a target on the
stack.
This patch has been tested on the Buildbot and no regressions have
been found. I'm also submitting a testcase for it.
gdb/ChangeLog:
2019-11-18 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1765117
* target.c (target_stack::push): Call 'unpush' if there's a
target on top of the stack.
gdb/testsuite/ChangeLog:
2019-11-18 Sergio Durigan Junior <sergiodj@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1765117
* gdb.tui/corefile-run.exp: New file.
Change-Id: I39e2f8b538c580c8ea5bf1d657ee877e47746c8f
valgrind reports leaks in many python tests, such as:
==17162== VALGRIND_GDB_ERROR_BEGIN
==17162== 8,208 (5,472 direct, 2,736 indirect) bytes in 57 blocks are definitely lost in loss record 7,551 of 7,679
==17162== at 0x4835753: malloc (vg_replace_malloc.c:307)
==17162== by 0x6EAFD1: _PyObject_New (object.c:279)
==17162== by 0x4720E6: blpy_iter(_object*) (py-block.c:92)
==17162== by 0x698772: PyObject_GetIter (abstract.c:2577)
==17162== by 0x2343BE: _PyEval_EvalFrameDefault (ceval.c:3159)
==17162== by 0x22E9E2: function_code_fastcall (call.c:283)
==17162== by 0x2340A8: _PyObject_Vectorcall (abstract.h:127)
==17162== by 0x2340A8: call_function (ceval.c:4987)
==17162== by 0x2340A8: _PyEval_EvalFrameDefault (ceval.c:3486)
==17162== by 0x22E9E2: function_code_fastcall (call.c:283)
==17162== by 0x82172B: _PyObject_Vectorcall (abstract.h:127)
==17162== by 0x82172B: method_vectorcall (classobject.c:67)
==17162== by 0x6AF474: _PyObject_Vectorcall (abstract.h:127)
==17162== by 0x6AF474: _PyObject_CallNoArg (abstract.h:153)
==17162== by 0x6AF474: _PyObject_CallFunctionVa (call.c:914)
==17162== by 0x6B0673: callmethod (call.c:1010)
==17162== by 0x6B0673: _PyObject_CallMethod_SizeT (call.c:1103)
==17162== by 0x477DFE: gdb_PyObject_CallMethod<> (python-internal.h:182)
==17162== by 0x477DFE: get_py_iter_from_func(_object*, char const*) (py-framefilter.c:272)
==17162== by 0x4791B4: py_print_args (py-framefilter.c:706)
==17162== by 0x4791B4: py_print_frame(_object*, enum_flags<frame_filter_flag>, ext_lang_frame_args, ui_out*, int, htab*) (py-framefilter.c:960)
==17162== by 0x47A130: gdbpy_apply_frame_filter(extension_language_defn const*, frame_info*, enum_flags<frame_filter_flag>, ext_lang_frame_args, ui_out*, int, int) (py-framefilter.c:1236)
==17162== by 0x369C39: apply_ext_lang_frame_filter(frame_info*, enum_flags<frame_filter_flag>, ext_lang_frame_args, ui_out*, int, int) (extension.c:563)
==17162== by 0x4EC9C9: backtrace_command_1 (stack.c:2031)
==17162== by 0x4EC9C9: backtrace_command(char const*, int) (stack.c:2183)
...
Most of the leaks in python tests are due to the fact that many
PyObject xxxxx_dealloc functions are missing the line to free self
or obj such as:
Py_TYPE (self)->tp_free (self);
or
Py_TYPE (obj)->tp_free (obj);
With this patch, the number of python tests leaking decreases from 52 to 12.
gdb/ChangeLog
2019-11-18 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* python/py-block.c (blpy_dealloc): Call tp_free.
(blpy_block_syms_dealloc): Likewise.
* python/py-finishbreakpoint.c (bpfinishpy_dealloc): Likewise.
* python/py-inferior.c (infpy_dealloc): Likewise.
* python/py-lazy-string.c (stpy_dealloc): Likewise.
* python/py-linetable.c (ltpy_iterator_dealloc): Likewise.
* python/py-symbol.c (sympy_dealloc): Likewise.
* python/py-symtab.c (stpy_dealloc): Likewise.
* python/py-type.c (typy_iterator_dealloc): Likewise.
As reported by PhilippeW, valgrind reports that symtab is uninitialized
when compiling with GCC 4.8.5, which is the default compiler on CentOS 7.
This is apparently a compiler bug fixed in later versions, but to keep
CentOS 7 working, this patch initializes the union explicitly instead of
using a class initializer.
gdb/ChangeLog:
2019-11-18 Christian Biesinger <cbiesinger@google.com>
* symtab.h (struct symbol) <owner>: Initialize explicitly in the
constructor instead of using a class initializer.
Change-Id: I94f48afeae5d29cf81a280295e2d02e2d7e1c1f1
There is no need to keep mingw-strerror around; we can just always use
the code from posix-strerror. The main reason we had that code, it
seems, is to handle winsock error codes, but gnulib's version
handles those.
Unfortunately the code can't be moved into common-utils.c because
libinproctrace.so uses common-utils but not gnulib.
gdb/ChangeLog:
2019-11-15 Christian Biesinger <cbiesinger@google.com>
* Makefile.in: Replace {posix,mingw}-strerror.c with safe-strerror.c.
* configure: Regenerate.
* configure.ac: Don't source common.host.
* gdbsupport/common.host: Remove.
* gdbsupport/mingw-strerror.c: Remove.
* gdbsupport/posix-strerror.c: Rename to...
* gdbsupport/safe-strerror.c: ...this.
gdb/gdbserver/ChangeLog:
2019-11-15 Christian Biesinger <cbiesinger@google.com>
* Makefile.in: Add safe-strerror.c.
* configure: Regenerate.
* configure.ac: Don't source common.host.
Change-Id: I9e6d8a752fc398784201f370cafee65e0ea05474
To make these calls threadsafe. localtime_r is provided by gnulib if
necessary, and for ctime_r we can just use it because it is in a linux-
specific file.
gdb/ChangeLog:
2019-11-15 Christian Biesinger <cbiesinger@google.com>
* maint.c (scoped_command_stats::print_time): Use localtime_r
instead of localtime (provided through gnulib if necessary).
* nat/linux-osdata.c (time_from_time_t): Use ctime_r instead
of ctime.
Change-Id: I329bbdc39d5b576f51859ba00f1617e024c30cbd
Makes sure to assign the return value of strerror_r to an int,
so that we get a compile error if we accidentally get the
wrong version.
gdb/ChangeLog:
2019-11-15 Christian Biesinger <cbiesinger@google.com>
* config.in: Regenerate.
* configure: Regenerate.
* gdbsupport/common.m4: No longer check for strerror_r.
* gdbsupport/posix-strerror.c (safe_strerror): Always call the
POSIX version of strerror_r, now that gnulib provides it if
necessary.
gdb/gdbserver/ChangeLog:
2019-11-15 Christian Biesinger <cbiesinger@google.com>
* config.in: Regenerate.
* configure: Regenerate.
gnulib/ChangeLog:
2019-11-15 Christian Biesinger <cbiesinger@google.com>
* Makefile.in: Regenerate.
* aclocal.m4: Regenerate.
* config.in: Regenerate.
* configure: Regenerate.
* import/Makefile.am: Update.
* import/Makefile.in: Regenerate.
* import/extra/config.rpath: New file.
* import/glthread/lock.c: New file.
* import/glthread/lock.h: New file.
* import/glthread/threadlib.c: New file.
* import/m4/gnulib-cache.m4: Update.
* import/m4/gnulib-comp.m4: Update.
* import/m4/lib-ld.m4: New file.
* import/m4/lib-link.m4: New file.
* import/m4/lib-prefix.m4: New file.
* import/m4/lock.m4: New file.
* import/m4/strerror_r.m4: New file.
* import/m4/threadlib.m4: New file.
* import/strerror_r.c: New file.
* update-gnulib.sh: Import strerror_r-posix.
Change-Id: I5cfeb12a5203a4cd94a78581541e6085a68685c3
Adds descriptions for some recent-ish configure options to README.
Also updates the minimum Python version per commit
6c28e44a35.
2019-11-14 Christian Biesinger <cbiesinger@google.com>
* README (`configure' options): Update.
Change-Id: I8ce8ca6935afbd130295e143802c585cf1e735f9
A customer reported somewhat odd gdb behavior, where re-assigning an
array or string to a convenience variable would yield "Too many array
elements". A test case is:
(gdb) p $x = "x"
(gdb) p $x = "xyz"
This patch fixes the problem by making a special case in the evaluator
for assignment to convenience variables, which seems like the correct
behavior.
Note that a previous patch implemented this for Ada, see commit
f411722cb ("Allow re-assigning to convenience variables").
gdb/ChangeLog
2019-11-14 Tom Tromey <tromey@adacore.com>
* eval.c (evaluate_subexp_standard) <BINOP_ASSIGN>: Do not pass an
expected type for the RHS if the LHS is a convenience variable.
gdb/testsuite/ChangeLog
2019-11-14 Tom Tromey <tromey@adacore.com>
* gdb.base/gdbvars.exp (test_convenience_variables): Add
regression tests.
Change-Id: I5e66a2d243931a5c43c7af4bc9f6717464c2477e
When building with gcc 9.2.0, I get the following build error:
In file included from /home/simark/src/binutils-gdb/gdb/unittests/vec-utils-selftests.c:23:
/home/simark/src/binutils-gdb/gdb/gdbsupport/gdb_vecs.h: In instantiation of ‘T unordered_remove(std::__debug::vector<T>&, typename std::__debug::vector<T>::iterator) [with T = selftests::vector_utils_tests::unordered_remove_tests()::obj; typename std::__debug::vector<T>::iterator = __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<selftests::vector_utils_tests::unordered_remove_tests()::obj*, std::__cxx1998::vector<selftests::vector_utils_tests::unordered_remove_tests()::obj, std::allocator<selftests::vector_utils_tests::unordered_remove_tests()::obj> > >, std::__debug::vector<selftests::vector_utils_tests::unordered_remove_tests()::obj>, std::random_access_iterator_tag>]’:
/home/simark/src/binutils-gdb/gdb/unittests/vec-utils-selftests.c:53:26: required from here
/home/simark/src/binutils-gdb/gdb/gdbsupport/gdb_vecs.h:53:5: error: implicitly-declared ‘selftests::vector_utils_tests::unordered_remove_tests()::obj::obj(const selftests::vector_utils_tests::unordered_remove_tests()::obj&)’ is deprecated [-Werror=deprecated-copy]
53 | T removed = std::move (*it);
| ^~~~~~~
/home/simark/src/binutils-gdb/gdb/unittests/vec-utils-selftests.c:41:10: note: because ‘selftests::vector_utils_tests::unordered_remove_tests()::obj’ has user-provided ‘selftests::vector_utils_tests::unordered_remove_tests()::obj& selftests::vector_utils_tests::unordered_remove_tests()::obj::operator=(const selftests::vector_utils_tests::unordered_remove_tests()::obj&)’
41 | obj &operator= (const obj &other)
| ^~~~~~~~
In file included from /home/simark/src/binutils-gdb/gdb/unittests/vec-utils-selftests.c:23:
/home/simark/src/binutils-gdb/gdb/gdbsupport/gdb_vecs.h:58:10: error: implicitly-declared ‘selftests::vector_utils_tests::unordered_remove_tests()::obj::obj(const selftests::vector_utils_tests::unordered_remove_tests()::obj&)’ is deprecated [-Werror=deprecated-copy]
58 | return removed;
| ^~~~~~~
/home/simark/src/binutils-gdb/gdb/unittests/vec-utils-selftests.c:41:10: note: because ‘selftests::vector_utils_tests::unordered_remove_tests()::obj’ has user-provided ‘selftests::vector_utils_tests::unordered_remove_tests()::obj& selftests::vector_utils_tests::unordered_remove_tests()::obj::operator=(const selftests::vector_utils_tests::unordered_remove_tests()::obj&)’
41 | obj &operator= (const obj &other)
| ^~~~~~~~
I think gcc is just trying to be nice and recommends the good practice
of providing a copy constructor if an assignment operator is provided.
Silence the warning by providing that copy constructor.
gdb/ChangeLog:
* unittests/vec-utils-selftests.c (unordered_remove_tests::obj):
Provide explicit default and copy constructor.
Change-Id: I323361b1c120bf8525613b74e7e5983910e002df
valgrind reports a leak when a breakpoint is created then deleted:
==1313== 40 bytes in 1 blocks are definitely lost in loss record 1,115 of 8,596
==1313== at 0x4835753: malloc (vg_replace_malloc.c:307)
==1313== by 0x6E05BC: _PyObject_New (object.c:255)
==1313== by 0x470E4B: gdbpy_breakpoint_created(breakpoint*) (py-breakpoint.c:1023)
==1313== by 0x2946D9: operator() (std_function.h:687)
==1313== by 0x2946D9: notify (observable.h:106)
==1313== by 0x2946D9: install_breakpoint(int, std::unique_ptr<breakpoint, std::default_delete<breakpoint> >&&, int) (breakpoint.c:8136)
==1313== by 0x295BCA: create_breakpoint_sal (breakpoint.c:8878)
==1313== by 0x295BCA: create_breakpoints_sal (breakpoint.c:8919)
==1313== by 0x295BCA: create_breakpoints_sal_default (breakpoint.c:13671)
...
The leak is due to a superfluous Py_INCREF when the python object
is allocated inside gdbpy_breakpoint_created, when the python object
is allocated locally: this object has already a refcount of 1, and
the only reference is the reference from the C breakpoint object.
The Py_INCREF is however needed when the python object was created from
python: the python object was stored in bppy_pending_object, and
gdbpy_breakpoint_created creates a new reference to this object.
Solve the leak by calling 'Py_INCREF (newbp);' only in the bppy_pending_object
case.
Regression tested on debian/amd64 natively and under valgrind on centos/amd64.
Before the patch, 795 tests have a definite leak.
After the patch, 197 have a definite leak.
Thanks to Tom, that helped on irc with the python refcount logic.
gdb/ChangeLog
2019-11-14 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* python/py-finishbreakpoint.c (gdbpy_breakpoint_created):
only call Py_INCREF (newbp) in the bppy_pending_object case.
commit 3573abe1d added static asserts to ensure that symbol sizes
don't vary. However, this failed to build on Windows, on at least one
ARM platform (see PR build/25182) and internally at AdaCore for PPC.
So, I think it is probably best to just remove these assertions,
effectively reverting 3573abe1d.
gdb/ChangeLog
2019-11-13 Tom Tromey <tromey@adacore.com>
PR build/25182:
* psympriv.h (partial_symbol): Remove static assert.
* symtab.h (general_symbol_info, symbol): Remove static assert.
Change-Id: I51940fb2240c474838b48494b5072081701789bb
The gdb format mechanism doesn't currently support the 'z' size
modifier, there are a few places in GDB where this is used. Instead
of removing these uses lets just add support to GDB for using 'z'.
I found this issue when trying to use some of the debug output.
Before this commit:
(gdb) set debug dwarf-line 9
(gdb) file test
Reading symbols from test...
Unrecognized format specifier 'z' in printf
(No debugging symbols found in test)
(gdb)
After this commit:
(gdb) set debug dwarf-line 9
(gdb) file test
Reading symbols from test...
Adding dir 1: /usr/include
Adding file 1: test.c
Adding file 2: stdc-predef.h
Processing actual line 3: file 1, address 0x4004a0, is_stmt 1, discrim 0
Processing actual line 4: file 1, address 0x4004a0, is_stmt 1, discrim 0
.... lots of debug output ...
Processing actual line 10: file 1, address 0x4003b7, is_stmt 0, discrim 0
(gdb)
I've added a self test to cover the integer format size modifiers,
including the 'z' modifier.
gdb/ChangeLog:
* gdbsupport/format.c (format_pieces::format_pieces): Support
printf 'z' size modifier.
* gdbsupport/format.h (enum argclass): Add size_t_arg.
* printcmd.c (ui_printf): Handle size_t_arg.
* ui-out.c (ui_out::vmessage): Likewise.
* unittests/format_pieces-selftests.c (test_format_int_sizes): New
function.
(run_tests): Call test_format_int_sizes.
gdb/gdbserver/ChangeLog:
* ax.c (ax_printf): Handle size_t_arg.
Change-Id: Ib6c44d88aa5bce265d757e4c0698881803dd186f
Since this is now no longer a POD, also give it a constructor that
initializes all fields. (I have considered overloading operator new
to zero-initialize the memory instead; let me know if you prefer that)
gdb/ChangeLog:
2019-11-12 Christian Biesinger <cbiesinger@google.com>
* ada-exp.y (write_ambiguous_var): Update.
* buildsym.c (add_symbol_to_list): Update.
* dwarf2read.c (read_variable): Update.
(new_symbol): Update.
* jit.c (finalize_symtab): Update.
* language.c (language_alloc_type_symbol): Update.
* symtab.c (fixup_symbol_section): Update.
(initialize_objfile_symbol_1): Move code to...
(initialize_objfile_symbol): ...here. Remove now-unnecessary memset.
(allocate_symbol): Update.
(allocate_template_symbol): Update.
(get_symbol_address): Update.
* symtab.h (struct symbol): Inherit from general_symbol_info instead
of having as a field, and add a constructor.
(SYMBOL_VALUE): Update.
(SYMBOL_VALUE_ADDRESS): Update.
(SET_SYMBOL_VALUE_ADDRESS): Update.
(SYMBOL_VALUE_BYTES): Update.
(SYMBOL_VALUE_COMMON_BLOCK): Update.
(SYMBOL_BLOCK_VALUE): Update.
(SYMBOL_VALUE_CHAIN): Update.
(SYMBOL_LANGUAGE): Update.
(SYMBOL_SECTION): Update.
(SYMBOL_OBJ_SECTION): Update.
(SYMBOL_SET_LANGUAGE): Update.
(SYMBOL_SET_LINKAGE_NAME): Update.
(SYMBOL_SET_NAMES): Update.
(SYMBOL_NATURAL_NAME): Update.
(SYMBOL_LINKAGE_NAME): Update.
(SYMBOL_DEMANGLED_NAME): Update.
(SYMBOL_SEARCH_NAME): Update.
(SYMBOL_MATCHES_SEARCH_NAME): Update.
(struct symbol): Update.
(struct template_symbol): Update.
(struct rust_vtable_symbol): Update.
* xcoffread.c (SYMBOL_DUP): Update.
Change-Id: I05b1628455bcce3efaa101e65ef051708d17eb07
Currently several functions in tui-layout.c set current_layout after
their work is done. This moves this assignment to show_layout,
instead.
gdb/ChangeLog
2019-11-12 Tom Tromey <tom@tromey.com>
* tui/tui-layout.c (show_layout): Set current_layout.
(show_source_disasm_command, show_data)
(show_source_or_disasm_and_command): Don't set current_layout.
Change-Id: Id8b23797d68e607f0fcd6d29b8801869d40d1869
This moves _initialize_tui_layout to the end of the file, conforming
to the typical gdb style.
gdb/ChangeLog
2019-11-12 Tom Tromey <tom@tromey.com>
* tui/tui-layout.c (_initialize_tui_layout): Move to end.
Change-Id: I667f741b44b2bc470878a36f093a96d89fa31893
As Sergio pointed out, the TUI resizing tests are flaky. Debugging
this showed three main problems.
1. expect's "stty" command processes its arguments one-by-one. So,
rather than requesting a single resize, it sends two separate resize
requests (one for rows and one for columns). This means gdb sees two
SIGWINCH signals and resizes the terminal twice.
I consider this a bug in expect, but I couldn't readily see how to
report a bug; and anyway the fix wouldn't propagate very quickly.
This patch works around this problem by explicitly doing two separate
resizes (so it will be robust if expect ever does change); and then by
waiting for each resize to complete before continuing.
2. gdb uses curses to drive the console rendering. Currently the test
suite looks for terminal text insertion sequences to decide when a
command has completed. However, it turns out that, sometimes, curses
can output things in non-obvious ways. I didn't debug into curses but
I guess this can happen due to output optimizations. No matter the
reason, sometimes the current approach of only tracking text
insertions is not enough to detect that gdb has finished rendering.
This patch fixes this problem by arranging to detect the termination
output after any curses command, not just insertion.
3. Detecting when a resize has completed is tricky. In fact, I could
not find a way to reliably do this.
This patch fixes this problem by adding a special maint
"tui-resize-message" setting to gdb. When this is enabled, gdb will
print a message after each SIGWINCH has been fully processed. The
test suite enables this mode and then waits for the message in order
to know when control can be returned to the calling test.
This patch also adds a timeout, to avoid the situation where the
terminal code fails to notice a change for some reason. This lets the
test at least try to continue.
gdb/ChangeLog
2019-11-12 Tom Tromey <tom@tromey.com>
* tui/tui-win.c (resize_message): New global.
(show_tui_resize_message): New function.
(tui_async_resize_screen): Print message if requested.
(_initialize_tui_win): Add tui-resize-message setting.
* NEWS: Add entry for new commands.
gdb/doc/ChangeLog
2019-11-12 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Maintenance Commands): Document new command.
gdb/testsuite/ChangeLog
2019-11-12 Tom Tromey <tom@tromey.com>
* lib/tuiterm.exp (_accept): Add wait_for parameter. Check output
after any command. Expect prompt after WAIT_FOR is seen.
(enter_tui): Enable resize messages.
(command): Expect command in output.
(get_line): Avoid error when cursor appears to be off-screen.
(dump_screen): Include screen size in title.
(_do_resize): New proc, from "resize".
(resize): Rewrite. Do resize in two steps.
* gdb.tui/empty.exp (layouts): Fix entries.
(check_boxes): Remove xfail.
(check_text): Dump screen on failure.
Change-Id: I420e0259cb99b21adcd28f671b99161eefa7a51d
This adds readline-bindable function names to a few gdb functions that
already had key bindings. This lets users change the bindings.
This also removes the gdb-command function. Due to how this function
is implemented, it doesn't make sense to allow binding it.
Finally, this updates the documentation to reflect these changes.
gdb/ChangeLog
2019-11-11 Tom Tromey <tom@tromey.com>
* tui/tui.c (tui_initialize_readline): Add new bindable readline
functions.
gdb/doc/ChangeLog
2019-11-11 Tom Tromey <tom@tromey.com>
* gdb.texinfo (TUI Keys): Document readline function names.
Change-Id: I2233779b7aefe372f19bd03c8f325733c3385e72
This adds some documentation for the operate-and-get-next readline
function that gdb supplies. The text is largely taken from the Bash
manual.
gdb/doc/ChangeLog
2019-11-11 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Editing): Document operate-and-get-next.
Change-Id: I9adb16d9ce84bfbda5fe8a2828f668ea878c080c
A user on irc noticed that the remote protocol documentation mentioned
"vFile:write" -- but this is a typo, there is only "vFile:pwrite".
This patch fixes the bug. Tested by rebuilding, committing as
obvious.
gdb/doc/ChangeLog
2019-11-11 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Host I/O Packets): Fix typo in "vFile:pwrite".
Change-Id: I2f668a691eed7883ba6bc092471739f44c82301b
If gdb.lookup_static_symbol is going to return a single symbol then it
makes sense (I think) for it to return a context sensitive choice of
symbol, that is the global static symbol that would be visible to the
program at that point.
However, if the user of the python API wants to instead get a
consistent set of global static symbols, no matter where they stop,
then they have to instead consider all global static symbols with a
given name - there could be many. That is what this new API function
offers, it returns a list (possibly empty) of all global static
symbols matching a given name (and optionally a given symbol domain).
gdb/ChangeLog:
* python/py-symbol.c (gdbpy_lookup_static_symbols): New
function.
* python/python-internal.h (gdbpy_lookup_static_symbols):
Declare new function.
* python/python.c (python_GdbMethods): Add
gdb.lookup_static_symbols method.
* NEWS: Mention gdb.lookup_static_symbols.
gdb/testsuite/ChangeLog:
* gdb.python/py-symbol.exp: Add test for
gdb.lookup_static_symbols.
gdb/doc/ChangeLog:
* python.texi (Symbols In Python): Add documentation for
gdb.lookup_static_symbols.
Change-Id: I1153b0ae5bcbc43b3dcf139043c7a48bf791e1a3
When using gdb.lookup_static_symbol I think that GDB should find
static symbols (global symbol with static linkage) from the current
object file ahead of static symbols from other object files.
This means that if we have two source files f1.c and f2.c, and both
files contains 'static int foo;', then when we are stopped in f1.c a
call to 'gdb.lookup_static_symbol ("foo")' will find f1.c::foo, and if
we are stopped in f2.c we would find 'f2.c::foo'.
Given that gdb.lookup_static_symbol always returns a single symbol,
but there can be multiple static symbols with the same name GDB is
always making a choice about which symbols to return. I think that it
makes sense for the choice GDB makes in this case to match what a user
would get on the command line if they asked to 'print foo'.
gdb/testsuite/ChangeLog:
* gdb.python/py-symbol.c: Declare and call function from new
py-symbol-2.c file.
* gdb.python/py-symbol.exp: Compile both source files, and add new
tests for gdb.lookup_static_symbol.
* gdb.python/py-symbol-2.c: New file.
gdb/doc/ChangeLog:
* python.texi (Symbols In Python): Extend documentation for
gdb.lookup_static_symbol.
gdb/ChangeLog:
* python/py-symbol.c (gdbpy_lookup_static_symbol): Lookup in
static block of current object file first. Also fix typo in
header comment.
Change-Id: Ie55dbeb8806f35577b46015deecde27a0ca2ab64
In stack.c we currently have a set of static global variables to track
the last displayed symtab and line. This commit moves all of these
into a class and adds an instance of the class to track the same
information.
The API into stack.c is unchanged after this cleanup.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* stack.c (set_last_displayed_sal): Delete.
(last_displayed_sal_valid): Delete.
(last_displayed_pspace): Delete.
(last_displayed_addr): Delete.
(last_displayed_symtab): Delete.
(last_displayed_line): Delete.
(class last_displayed_symtab_info_type): New.
(last_displayed_symtab_info): New static global variable.
(print_frame_info): Call methods on last_displayed_symtab_info.
(clear_last_displayed_sal): Update header comment, and make use of
last_displayed_symtab_info.
(last_displayed_sal_is_valid): Likewise.
(get_last_displayed_pspace): Likewise.
(get_last_displayed_addr): Likewise.
(get_last_displayed_symtab): Likewise.
(get_last_displayed_line): Likewise.
(get_last_displayed_sal): Likewise.
* stack.h (clear_last_displayed_sal): Update header comment.
(last_displayed_sal_is_valid): Likewise.
(get_last_displayed_pspace): Likewise.
(get_last_displayed_addr): Likewise.
(get_last_displayed_symtab): Likewise.
(get_last_displayed_line): Likewise.
(get_last_displayed_sal): Likewise.
Change-Id: Ia3dbfe267feec03108c5c8ed8bd94fc0a030c3ed
Just a clean up, should be no user visible changes after this commit.
gdb/ChangeLog:
* stack.c (frame_show_address): Convert return type to bool.
* stack.h (frame_show_address): Likewise, and update header
comment.
Change-Id: Iaaa9ebd4ff6534db19c5329f1c604932c747bd7f
While working on another patch I ran into an issue with
unordered_remove (in gdb_vecs.h), where removing the last item of the
vector can cause a self move assign.
When compiling the C++ standard library in debug mode (with
-D_GLIBCXX_DEBUG=1) this causes an error to trigger.
I've fixed the issue in this patch and provided a unit test.
The provided unit test includes an assignment operator which checks
for self move assign, this removes the need to compile with
-D_GLIBCXX_DEBUG=1 in order to spot the bug. If you're keen to see
the error reported from the C++ standard library then remove operator=
from the unit test and recompile GDB with -D_GLIBCXX_DEBUG=1.
gdb/ChangeLog:
* Makefile.in (SUBDIR_UNITTESTS_SRCS): Add new file to the list.
* unittests/vec-utils-selftests.c: New file.
* gdbsupport/gdb_vecs.h (unordered_remove): Avoid self move assign.
Change-Id: I80247b20cd5212038117db7412865f5e6a9257cd
Each TUI window has a "can_highlight" member. However, this has the
same meaning as "can_box" -- a window can be highlighted if and only
if it can be boxed. So, this patch removes can_highlight in favor of
simply using can_box.
gdb/ChangeLog
2019-11-10 Tom Tromey <tom@tromey.com>
* tui/tui-wingeneral.c (tui_unhighlight_win): Use can_box.
(tui_highlight_win): Likewise.
(tui_win_info::check_and_display_highlight_if_needed): Likewise.
* tui/tui-data.h (struct tui_win_info) <can_highlight>: Remove.
* tui/tui-command.h (struct tui_cmd_window) <tui_cmd_window>:
Don't set can_highlight.
Change-Id: I35916859070efcdfcc6e692c71cc6070956dcfce
I noticed that cli_style_option declares a constructor that is never
defined. This removes it.
gdb/ChangeLog
2019-11-10 Tom Tromey <tom@tromey.com>
* cli/cli-style.h (class cli_style_option) <cli_style_option>:
Remove unused declaration.
Change-Id: Ic59ec7eab4d7183d9392b58709354b2d4449b7be
This changes command_line_input to return a "const char *", which is
appropriate because the memory is owned by command_line_input. Then
it fixes up the users.
I looked at making command_line_input transfer ownership to its caller
instead, but this is complicated due to the way read_next_line is
called, so I decided against it.
Tested by rebuilding.
gdb/ChangeLog
2019-11-08 Tom Tromey <tromey@adacore.com>
* top.c (read_command_file): Update.
(command_line_input): Make return type const.
* python/py-gdb-readline.c: Update.
* linespec.c (decode_line_2): Update.
* defs.h (command_line_input): Make return type const.
* cli/cli-script.c (read_next_line): Make return type const.
* ada-lang.c (get_selections): Update.
Change-Id: I27e6c9477fd1005ab5b16e0d337e4c015b6e6248
Add a script that takes a list of files as arguments and output a list of
words from the C comments with their frequencies.
For:
...
$ ./gdb/contrib/words.sh $(find gdb -type f -name "*.c" -o -name "*.h")
...
it generates a list of ~15000 words prefixed with frequency.
This could be used to generate a dictionary that is kept as part of the
sources, against which new code can be checked, generating a warning or
error. The hope is that misspellings would trigger this frequently, and rare
words rarely, otherwise the burden of updating the dictionary would be too
much.
And for:
...
$ ./gdb/contrib/words.sh -f 1 $(find gdb -type f -name "*.c" -o -name "*.h")
...
it generates a list of ~5000 words with frequency 1.
This can be used to scan for misspellings manually.
Change-Id: I7b119c9a4519cdbf62a3243d1df2927c80813e8b
Improves threadsafety. This will be important when the patch series at
https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/176
lands.
gdb/ChangeLog:
2019-11-06 Christian Biesinger <cbiesinger@google.com>
* linux-tdep.c (linux_info_proc): Use strtok_r instead of strtok.
* mi/mi-main.c (output_cores): Likewise.
* nat/linux-osdata.c (linux_xfer_osdata_cpus): Likewise.
(linux_xfer_osdata_modules): Likewise.
* remote.c (register_remote_support_xml): Likewise.
* sparc64-tdep.c (adi_is_addr_mapped): Likewise.
* xml-syscall.c (syscall_create_syscall_desc): Likewise.
gdb/gdbserver/ChangeLog:
2019-11-06 Christian Biesinger <cbiesinger@google.com>
* linux-x86-low.c (x86_linux_process_qsupported): Use strtok_r
instead of strtok.
* server.c (handle_query): Likewise.
(captured_main): Likewise.
Change-Id: Ief6138965a24398e5fc064598cd8f2abd3b5047c
I went through most of the spots that include readline.h and, when
appropriate, either removed the include or changed it to include
tilde.h.
Note that remote-sim.c and bsd-kvm.c could probably include tilde.h
instead, but I did not change these. I think I can't build the
latter, and I didn't want to set up a sim build for the former.
Tested by rebuilding.
gdb/ChangeLog
2019-11-06 Tom Tromey <tom@tromey.com>
* tui/tui-interp.c: Don't include readline.h.
* tui/tui-hooks.c: Don't include readline.h.
* symmisc.c: Include tilde.h, not readline.h.
* symfile.c: Include tilde.h, not readline.h.
* source.c: Include tilde.h, not readline.h.
* solib.c: Include tilde.h, not readline.h.
* psymtab.c: Include tilde.h, not readline.h.
* exec.c: Include tilde.h, not readline.h.
* corelow.c: Include tilde.h, not readline.h.
* cli/cli-dump.c: Include tilde.h, not readline.h.
* cli/cli-cmds.c: Don't include readline.h.
Change-Id: I60487a190c43128b800ef77517d1ab42957571d7
My previous patch to add styling to the TUI disassembly failed to
correctly fix a bug that Simon had pointed out in review. This patch
fixes the bug.
gdb/ChangeLog
2019-11-05 Tom Tromey <tom@tromey.com>
* tui/tui-disasm.c (struct tui_asm_line) <addr_size>: New member.
(tui_disassemble): Set addr_size.
(tui_disasm_window::set_contents): Use addr_size.
Change-Id: Ic0152f3b82a2f79be28ae46d590096661f271580
The la_get_string member of struct language_defn was intended to
provide a way to fetch string data from a "string" object in a
language-dependent way. However, it turned out that this was never
needed, and was only ever implemented for C. This patch removes the
language hook entirely.
gdb/ChangeLog
2019-11-05 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_language_defn): Update.
* python/py-value.c (valpy_string): Call c_get_string.
* p-lang.c (pascal_language_defn): Update.
* opencl-lang.c (opencl_language_defn): Update.
* objc-lang.c (objc_language_defn): Update.
* m2-lang.c (m2_language_defn): Update.
* language.c (unknown_language_defn, auto_language_defn): Update.
(default_get_string): Remove.
* guile/scm-value.c (gdbscm_value_to_string): Use c_get_string.
* go-lang.c (go_language_defn): Update.
* f-lang.c (f_language_defn): Update.
* d-lang.c (d_language_defn): Update.
* c-lang.c (c_language_defn, cplus_language_defn)
(asm_language_defn, minimal_language_defn): Update.
* ada-lang.c (ada_language_defn): Update.
* language.h (struct language_defn) <la_get_string>: Remove.
(LA_GET_STRING): Remove.
(default_get_string): Don't declare.
Change-Id: Ia97763dfe34dc8ecb46587f7a651f8af9be8fdbd
This patch changes the TUI disassembly window to style its contents.
The styling should be identical to what is seen in the CLI. This
involved a bit of rearrangement, so that the source and disassembly
windows could share both the copy_source_line utility function, and
the ability to react to changes in "set style enabled".
This version introduces a new function to strip the styling from the
address string when computing the length. As a byproduct, it also
removes the unused "insn_size" computation from
tui_disasm_window::set_contents.
gdb/ChangeLog
2019-11-05 Tom Tromey <tom@tromey.com>
* tui/tui-source.h (struct tui_source_window): Inline
constructor. Remove destructor.
<style_changed, m_observable>: Move to superclass.
* tui/tui-winsource.h (tui_copy_source_line): Declare.
(struct tui_source_window_base): Move private members to end.
<style_changed, m_observable>: Move from tui_source_window.
* tui/tui-winsource.c (tui_copy_source_line): Move from
tui-source.c. Rename from copy_source_line. Add special handling
for negative line number.
(tui_source_window_base::style_changed): Move from
tui_source_window.
(tui_source_window_base): Register observer.
(~tui_source_window_base): New.
* tui/tui-source.c (copy_source_line): Move to tui-winsource.c;
rename.
(tui_source_window::set_contents): Use tui_copy_source_line.
(tui_source_window::tui_source_window): Move to tui-source.h.
(tui_source_window::~tui_source_window): Remove.
(tui_source_window::style_changed): Move to superclass.
* tui/tui-disasm.c (tui_disassemble): Create string file with
styling, when possible. Add "addr_size" parameter.
(tui_disasm_window::set_contents): Use tui_copy_source_line.
Don't compute maximum size.
(len_without_escapes): New function
Change-Id: I8722635eeecbbb1633d943a65b856404c2d467b0
This changes tui_source_element::line to be of type std::string. This
reduces the number of copies made.
gdb/ChangeLog
2019-11-05 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.h (struct tui_source_element) <line>: Now a
std::string.
* tui/tui-winsource.c (tui_show_source_line): Update.
* tui/tui-source.c (tui_source_window::set_contents): Update.
* tui/tui-disasm.c (tui_disasm_window::set_contents): Update.
Change-Id: Id600f3e1d386a2911f187366e05e2ec599068dd2
gdb/ChangeLog:
2019-11-05 Christian Biesinger <cbiesinger@google.com>
* symtab.h (gdb_static_assert): Put && operator at the beginning
of the line instead of the end.
Change-Id: I6d05c2f5e46c3f317ba97458509b2da9fd03464b
Specifically the three structs mentioned in symtab.h:
- general_symbol_info
- symbol
- partial_symbol
This ensures that those structs won't accidentally get bigger.
gdb/ChangeLog:
2019-11-04 Christian Biesinger <cbiesinger@google.com>
* psympriv.h: Add static_asserts for sizeof (general_symbol_info)
and sizeof (symbol).
* symtab.h: Add a static_assert for sizeof (partial_symbol).
Change-Id: Idd68320aa3e79ee7cc749019724636a58ce4b9c6
Here's the patch corresponding to the Solaris 10 obsoletion announcement
https://sourceware.org/ml/gdb/2019-10/msg00008.html
Right now it doesn't remove any code, but obviates the need to test on
that ancient platform. Besides, some of the patches I have in my queue
would require different solutions for Solaris 10 and 11.
There are a few comment-only references that I've kept since they are
still correct as is, even when GDB doesn't support Solaris 10 any
longer. The only code fragment I've left in is support for
/proc/<pid/path/a.out in procfs.c (procfs_target::pid_to_exec_file):
while current Solaris 11 updates provide /proc/<pid>/execname, that
wasn't present in Solaris 11.0 and still isn't in current Illumos and I
didn't want to make live harder for them.
Tested on i386-pc-solaris2.10 (obsolete configuration rejected) and
x86_64-pc-linux-gnu x sparc64-solaris2.10 (likewise)
resp. x86_64-pc-linux-gnu x sparcv9-solaris2.11 (still builds; I'm using
the sparcv9 form for 64-bit SPARC customary on Solaris in the
MAINTAINERS file now).
* NEWS (Changes since GDB 8.3): Document Solaris 10 removal.
* configure.host: Mark *-*-solaris2.10* obsolete.
* configure.tgt: Mark Solaris < 11 obsolete.
* MAINTAINERS (Target Instruction Set Architectures) <sparc>:
Update target triplet.
On irc, Christian pointed out that print_sys_errmsg could be
simplified by avoiding alloca entirely. This patch implements this.
gdb/ChangeLog
2019-11-01 Tom Tromey <tromey@adacore.com>
* utils.c (print_sys_errmsg): Simplify.
Change-Id: Ic399dade274ea61b63ef0540b3a3be2f0f80160a
The earlier patch to constify safe_strerror missed a couple of spots,
corrected here.
gdb/ChangeLog
2019-11-01 Tom Tromey <tromey@adacore.com>
* gdbsupport/mingw-strerror.c (safe_strerror): Constify result.
Change-Id: I36d5ced144d27b1a6734d9ab9a10a7b9f339ae88
The speed optimization from commit 5f6cac4085
made GDB skip reloading all symbols when the same symbol file is reloaded.
As a result, ARM targets only read the mapping symbols the first time we
load a symbol file. When reloaded, the speed optimization above will
cause an early return and gdbarch_record_special_symbol won't be called to
save mapping symbol data, which in turn affects disassembling of thumb
instructions.
First load and correct disassemble output:
Dump of assembler code for function main:
0x0000821c <+0>: bx pc
0x0000821e <+2>: nop
0x00008220 <+4>: mov r0, #0
0x00008224 <+8>: bx lr
Second load and incorrect disassemble output:
Dump of assembler code for function main:
0x0000821c <+0>: bx pc
0x0000821e <+2>: nop
0x00008220 <+4>: movs r0, r0
0x00008222 <+6>: b.n 0x8966
0x00008224 <+8>: vrhadd.u16 d14, d14, d31
This happens because the mapping symbol data is stored in an objfile_key-based
container, and that data isn't preserved across the two symbol loading
operations.
The following patch fixes this by storing the mapping symbol data in a
bfd_key-based container, which doesn't change as long as the bfd is the same.
I've also added a new test to verify the correct disassemble output.
gdb/ChangeLog:
2019-11-01 Luis Machado <luis.machado@linaro.org>
PR gdb/25124
* arm-tdep.c (arm_per_objfile): Rename to ...
(arm_per_bfd): ... this.
(arm_objfile_data_key): Rename to ...
(arm_bfd_data_key): ... this.
(arm_find_mapping_symbol): Adjust access to new bfd_key-based
data.
(arm_record_special_symbol): Likewise.
gdb/testsuite/ChangeLog:
2019-11-01 Luis Machado <luis.machado@linaro.org>
PR gdb/25124
* gdb.arch/pr25124.S: New file.
* gdb.arch/pr25124.exp: New file.
Change-Id: I22c3e6ebe9bfedad66d56fe9656994fa1761c485
When calling the language la_print_typedef method, don't include a
newline at the end, instead print the newline from the users of
la_print_typedef.
This change will be useful in a later commit when the output from
la_print_typedef will be placed into an MI output field, in which case
the trailing newline is not required.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-typeprint.c (ada_print_typedef): Don't print newline at the
end.
* c-typeprint.c (c_print_typedef): Likewise.
* f-typeprint.c (f_print_typedef): Likewise.
* m2-typeprint.c (m2_print_typedef): Likewise.
* p-typeprint.c (pascal_print_typedef): Likewise.
* rust-lang.c (rust_print_typedef): Likewise.
* symtab.c (print_symbol_info): Print a newline after calling
typedef_print.
Change-Id: I6e697ea1ec0eadaa31aefaea959b2055188d680d
This patch adds two new commands "info module functions" and "info
module variables". These commands list all of the functions and
variables grouped by module and then by file.
For example:
(gdb) info module functions
All functions in all modules:
Module "mod1":
File /some/path/gdb/testsuite/gdb.fortran/info-types.f90:
35: void mod1::__copy_mod1_M1t1(Type m1t1, Type m1t1);
25: void mod1::sub_m1_a(integer(kind=4));
31: integer(kind=4) mod1::sub_m1_b(void);
Module "mod2":
File /some/path/gdb/testsuite/gdb.fortran/info-types.f90:
41: void mod2::sub_m2_a(integer(kind=4), logical(kind=4));
49: logical(kind=4) mod2::sub_m2_b(real(kind=4));
The new commands take set of flags that allow the output to be
filtered, the user can filter by variable/function name, type, or
containing module.
As GDB doesn't currently track the relationship between a module and
the variables or functions within it in the symbol table, so I filter
based on the module prefix in order to find the functions or variables
in each module. What this makes clear is that a user could get this
same information using "info variables" and simply provide the prefix
themselves, for example:
(gdb) info module functions -m mod1 _a
All functions matching regular expression "_a",
in all modules matching regular expression "mod1":
Module "mod1":
File /some/path/gdb/testsuite/gdb.fortran/info-types.f90:
25: void mod1::sub_m1_a(integer(kind=4));
Is similar to:
(gdb) info functions mod1::.*_a.*
All functions matching regular expression "mod1::.*_a":
File /some/path/gdb/testsuite/gdb.fortran/info-types.f90:
25: void mod1::sub_m1_a(integer(kind=4));
The benefits I see for a separate command are that the user doesn't
have to think (or know) about the module prefix format, nor worry
about building a proper regexp. The user can also easily scan across
modules without having to build complex regexps.
The new function search_module_symbols is extern in this patch despite
only being used within symtab.c, this is because a later patch in this
series will also be using this function from outside symtab.c.
This patch is a new implementation of an idea originally worked on by
Mark O'Connor, Chris January, David Lecomber, and Xavier Oro from ARM.
gdb/ChangeLog:
* symtab.c (info_module_cmdlist): New variable.
(info_module_command): New function.
(search_module_symbols): New function.
(info_module_subcommand): New function.
(struct info_modules_var_func_options): New struct.
(info_modules_var_func_options_defs): New variable.
(make_info_modules_var_func_options_def_group): New function.
(info_module_functions_command): New function.
(info_module_variables_command): New function.
(info_module_var_func_command_completer): New function.
(_initialize_symtab): Register new 'info module functions' and
'info module variables' commands.
* symtab.h (typedef symbol_search_in_module): New typedef.
(search_module_symbols): Declare new function.
* NEWS: Mention new commands.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Document new 'info module variables' and
'info module functions' commands.
gdb/testsuite/ChangeLog:
* gdb.fortran/info-modules.exp: Update expected results, and add
additional tests for 'info module functinos', and 'info module
variables'.
* gdb.fortran/info-types.exp: Update expected results.
* gdb.fortran/info-types.f90: Extend testcase with additional
module variables and functions.
Change-Id: I8c2960640e2e101b77eff54027d687e21ec22e2b
Add a new command 'info modules' that lists all of the modules GDB
knows about from the debug information.
A module is a debugging entity in the DWARF defined with
DW_TAG_module, currently Fortran is known to use this tag for its
modules. I'm not aware of any other language that currently makes use
of DW_TAG_module.
The output style is similar to the 'info type' output:
(gdb) info modules
All defined modules:
File info-types.f90:
16: mod1
24: mod2
(gdb)
Where the user is told the file the module is defined in and, on the
left hand side, the line number at which the module is defined along
with the name of the module.
This patch is a new implementation of an idea originally worked on by
Mark O'Connor, Chris January, David Lecomber, and Xavier Oro from ARM.
gdb/ChangeLog:
* dwarf2read.c (dw2_symtab_iter_next): Handle MODULE_DOMAIN.
(dw2_expand_marked_cus): Handle MODULES_DOMAIN.
(dw2_debug_names_iterator::next): Handle MODULE_DOMAIN and
MODULES_DOMAIN.
(scan_partial_symbols): Only create partial module symbols for non
declarations.
* psymtab.c (recursively_search_psymtabs): Handle MODULE_DOMAIN
and MODULES_DOMAIN.
* symtab.c (search_domain_name): Likewise.
(search_symbols): Likewise.
(print_symbol_info): Likewise.
(symtab_symbol_info): Likewise.
(info_modules_command): New function.
(_initialize_symtab): Register 'info modules' command.
* symtab.h (enum search_domain): Add MODULES_DOMAIN.
* NEWS: Mention new 'info modules' command.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Document new 'info modules' command.
gdb/testsuite/ChangeLog:
* gdb.fortran/info-modules.exp: New file.
* gdb.fortran/info-types.exp: Build with new file.
* gdb.fortran/info-types.f90: Include and use new module.
* gdb.fortran/info-types-2.f90: New file.
Change-Id: I2b781dd5a06bcad04620ccdc45f01a0f711adfad
gdb/testsuite/ChangeLog
2019-10-31 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/setshow.exp: Test $_gdb_setting and $_gdb_setting_str.
* gdb.base/settings.exp: Test all settings types using
$_gdb_maint_setting and $_gdb_maint_setting_str in proc_show_setting,
that now verifies that the value of "maint show" is the same as
returned by the settings functions. Test the type of the
maintenance settings.
* gdb.base/default.exp: Update show_conv_list.
The new convenience functions $_gdb_setting and $_gdb_setting_str
provide access to the GDB settings in user-defined commands.
Similarly, $_gdb_maint_setting and $_gdb_maint_setting_str
provide access to the GDB maintenance settings.
The patch was developed following a comment of Eli about the
'set may-call-functions'. Eli said that user-defined functions
should have a way to change their behavior according to this setting.
Rather than have a specialized $_may_call_functions, this patch
implements a general way to access any GDB setting.
Compared to doing such access via Python 'gdb.parameter' and/or
'gdb.execute("set somesetting tosomevalue"):
* The 'with' command is much better than the above python usage:
if the user types C-c or an error happens between the set pagination off
and the python "set pagination on", the above python
does not restore the original setting.
* Effectively, with the "gdb.parameter" python one liner, it is possible to do
simple 'if' conditions, such as set and restore pagination.
But mixing the "python if" within canned
sequence of commands is cumbersome for non trivial combinations.
E.g. if several commands have to be done for a certain condition
accessed from python, I guess something like will be needed:
python if __some_setting: gdb.execute("some command")
python if __some_setting: gdb.execute("some other command")
python if __some_setting: gdb.execute("some different command")
(without speaking about nested "if-s").
With the convenience function:
if $_gdb_setting("some_setting")
some command
some other command
some different command
end
Integer settings (for example print elements) will also be more difficult
to use.
For example, a user defined function that scans and prints a linked list
might want to use the value of "set print elements" to stop printing
the linked list.
Doing that by mixing python expression/if is likely doable, but seems
not easy with the above one liners.
So, in summary, the $_gdb_setting and $_gdb_setting_str avoids to have the
heterogeneous mix of python and GDB commands in one single script
(and of course, it works even if python is not configured, but that
must be an unusual setup I guess).
gdb/ChangeLog
2019-10-31 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* cli/cli-cmds.c (setting_cmd, value_from_setting)
(gdb_setting_internal_fn, gdb_maint_setting_internal_fn)
(str_value_from_setting, gdb_setting_str_internal_fn)
(gdb_maint_setting_str_internal_fn): New functions.
(_initialize_cli_cmds): Define the new convenience functions.
* gdb/cli/cli-setshow.h (get_setshow_command_value_string): Constify.
* gdb/cli/cli-setshow.c (get_setshow_command_value_string): Constify.
I forgot to do this in b231e86ac9
Since safe_strerror is in gdbsupport, gdbserver also needs to
check for strerror_r, although it's less critical since gdbserver
does not use threads as much.
gdb/gdbserver/ChangeLog:
2019-10-31 Christian Biesinger <cbiesinger@google.com>
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Also check for strerror_r.
Change-Id: I6a67c8543cd7a28d6dc94f5986f56abcb55727fe
This avoids unnecessary work, and becomes important with the patch in
https://sourceware.org/ml/gdb-patches/2019-10/msg01143.html
gdb/ChangeLog:
2019-10-31 Christian Biesinger <cbiesinger@google.com>
* agent.c (set_can_use_agent): When the setting is turned on,
look up agent symbols if we don't have them yet.
(agent_new_objfile): Don't look up agent symbols when the agent
setting is off.
Change-Id: I6523a5640c95d38299998050a6c620e51096e8ed
I forgot to do this in the last commit
(b231e86ac9)
gdb/ChangeLog:
2019-10-31 Christian Biesinger <cbiesinger@google.com>
* config.in: Regenerate.
Change-Id: I60946ffd853a59469c35f19ef8012ac6ea88a31c
Also stores the result in a thread-local static variable and
changes the return value to a const char*.
This is already important because Guile creates threads and
Python can create threads, but with the patch series here:
https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/176
GDB itself will create threads, too.
gdb/ChangeLog:
2019-10-31 Christian Biesinger <cbiesinger@google.com>
* configure: Regenerate.
* configure.ac: Check for strerror_r.
* gdbsupport/common-utils.h (safe_strerror): Change return value
to const char * and document that this function is now threadsafe.
* gdbsupport/posix-strerror.c (safe_strerror): Make buf
thread_local and call strerror_r, if available.
* utils.c (perror_string): Update.
(print_sys_errmsg): Update.
Change-Id: I81048fbaf148035c221c528727f7efe58ba528eb
Based on feedback from Tromey, update the use of objfile_key in gdb/arm-tdep.c
to use bfd_key instead. That way we don't have to re-create the exception
handling data all over again if it was done before for the same BFD.
gdb/ChangeLog:
2019-10-31 Luis Machado <luis.machado@linaro.org>
* arm-tdep.c (arm_exidx_data_key): Use bfd_key instead of
objfile_key.
(arm_exidx_new_objfile): Adjust to use objfile->obfd instead of
objfile to fetch per-bfd data.
(arm_find_exidx_entry): Likewise.
Change-Id: Ia7b3208ea8d788414600fa6d770ac76db0562859
Also moves an int declaration inside the for loop.
Code cleanup, no change in behavior intended.
gdb/ChangeLog:
2019-10-31 Christian Biesinger <cbiesinger@google.com>
* gdbsupport/agent.c (debug_agent): Change type to bool.
(use_agent): Likewise.
(all_agent_symbols_look_up): Likewise.
(agent_loaded_p): Change return value to bool.
(agent_look_up_symbols): Update.
(agent_capability_check): Change return value to bool.
* gdbsupport/agent.h (agent_loaded_p): Likewise.
(debug_agent): Change type to bool.
(use_agent): Likewise.
(agent_capability_check): Change return value to bool.
gdb/gdbserver/ChangeLog:
2019-10-31 Christian Biesinger <cbiesinger@google.com>
* ax.h (debug_agent): Remove duplicate declaration.
Change-Id: Icb28a65fcc8c7108bcd59287e6be66bf56f8ccb5
Proc gdb_test_multiple builds up and executes a gdb_expect expression with
pattern/action clauses. The clauses are either implicit (added by
gdb_test_multiple) or explicit (passed via the gdb_test_multiple parameter
user_code).
However, there are a few implicit clauses which are inserted before the
explicit ones, making sure those take precedence.
Add an -early pattern flag for a gdb_test_multiple user_code clause to specify
that the clause needs to be inserted before any implicit clause.
Using this pattern flag, we can f.i. setup a kfail for an assertion failure
<assert> during gdb_continue_to_breakpoint by the rewrite:
...
gdb_continue_to_breakpoint <msg> <pattern>
...
into:
...
set breakpoint_pattern "(?:Breakpoint|Temporary breakpoint) .* (at|in)"
gdb_test_multiple "continue" "continue to breakpoint: <msg>" {
-early -re "internal-error: <assert>" {
setup_kfail gdb/nnnnn "*-*-*"
exp_continue
}
-re "$breakpoint_pattern <pattern>\r\n$gdb_prompt $" {
pass $gdb_test_name
}
}
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-30 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_test_multiple): Handle -early pattern flag.
Change-Id: I376c636b0812be52e7137634b1a4f50bf2b999b6
The array starts out initialized to zero:
minimal_symbol *msymbol_hash[MINIMAL_SYMBOL_HASH_SIZE] {};
So we only need to explicitly clear it if there were previous minsyms
added to it. This patch does that.
gdb/ChangeLog:
2019-10-30 Christian Biesinger <cbiesinger@google.com>
* minsyms.c (clear_minimal_symbol_hash_tables): New function.
(build_minimal_symbol_hash_tables): Code to clear the table moved
to clear_minimal_symbol_hash_tables.
(minimal_symbol_reader::install): Call clear_minimal_symbol_hash_tables
when needed.
Change-Id: I7da994fe6747f67714e7efe9fdbb0dbc4d6ea532
This patch cleans up ada-lang.h:
- Some functions just don't exist anymore, remove their declaration
- Some functions are implemented in ada-lang.c and only used there, make
them static to that file.
I moved some functions higher in the file to avoid having to
forward-declare them, but the implementations are unchanged.
gdb/ChangeLog:
* ada-lang.h (GROW_VECT): Move to ada-lang.c.
(grow_vect): Remove declaration.
(ada_type_of_array): Remove declaration.
(ada_update_initial_language): Remove declaration.
(ada_fold_name): Remove declaration.
(ada_fill_in_ada_prototype): Remove declaration.
(user_select_syms): Remove declaration.
(get_selections): Remove declaration.
(ada_tag_type): Remove declaration.
(ada_value_tag): Remove declaration.
(ada_is_others_clause): Remove declaration.
(ada_in_variant): Remove declaration.
(ada_value_struct_elt): Remove declaration.
(ada_attribute_name): Remove declaration.
(ada_system_address_type): Remove declaration.
* ada-lang.c (ada_watch_location_expression): Make static.
(GROW_VECT): Move here from ada-lang.h.
(grow_vect): Make static.
(ada_update_initial_language): Make static.
(ada_fold_name): Make static.
(ada_type_of_array): Make static.
(encoded_ordered_before): Move up.
(sort_choices): Move up.
(print_signatures): Move up.
(ada_print_symbol_signature): Move up.
(get_selections): Move up and make static.
(user_select_syms): Move up and make static.
(ada_value_struct_elt): Move up and make static.
(ada_tag_type): Make static.
(ada_value_tag): Make static.
(ada_is_others_clause): Make static.
(ada_in_variant): Make static.
(ada_attribute_name): Make static.
Change-Id: If0d46ba87d6585ab674c87244068a19e84718fc9
These assertions can be done at compile time instead of at runtime.
gdb/ChangeLog:
* addrmap.c: Add static assertions of type size, moved from
_initialize_addrmap.
(_initialize_addrmap): Remove.
Change-Id: If089fc5d620a7168bdcdf967c6c4fecd6696b670
Just some code cleanup. This change has a few benefits:
- Shorter argument list in the functions
- If the caller needs to calculate the string, they no longer
need to explicitly call strlen
- It is easy to pass std::string to this (done in one place
currently)
This also updates a couple of places that were passing 0/1 to
a bool parameter.
gdb/ChangeLog:
2019-10-29 Christian Biesinger <cbiesinger@google.com>
* coffread.c (record_minimal_symbol): Update.
(process_coff_symbol): Update.
* dbxread.c (read_dbx_symtab): Update.
* dwarf2read.c (add_partial_symbol): Update.
(fixup_go_packaging): Update.
(load_partial_dies): Update.
(new_symbol): Update.
* elfread.c (record_minimal_symbol): Change signature to use
gdb::string_view instead of name+len.
(elf_symtab_read): Update.
(elf_rel_plt_read): Update.
* mdebugread.c (parse_partial_symbols): Update.
(handle_psymbol_enumerators): Update.
(new_symbol): Update.
* minsyms.c (minimal_symbol_reader::record_full): Change signature
to use gdb::string_view instead of name+len.
* minsyms.h (class minimal_symbol_reader) <record_full>: Likewise.
* psympriv.h (add_psymbol_to_list): Likewise.
* psymtab.c (add_psymbol_to_bcache): Likewise.
(add_psymbol_to_list): Likewise.
* stabsread.c (define_symbol): Update.
* symtab.c (symbol_set_names): Change signature to use gdb::string_view.
* symtab.h (SYMBOL_SET_NAMES): Likewise.
(symbol_set_names): Likewise.
* xcoffread.c (scan_xcoff_symtab): Update.
Change-Id: I2675c6865e0368f9c755a1081088a53aa54dda4c
As of 7bb4305982, we no longer need
a nullterminated linkage_name to look up the entry in the hash table.
So this patch makes it so we only make the copy if the entry was
not found.
By auditing all callers of symbol_set_names, I found out that all cases
where the string may not be nullterminated already pass true for COPY_NAME.
So here, I am documenting that as a requirement and am removing the code
that relies on undefined behavior in symbol_set_names (it accessed the string
past the provided length to check for nulltermination). Note that the Ada
case at the beginning of symbol_set_names was already relying on this.
gdb/ChangeLog:
2019-10-29 Christian Biesinger <cbiesinger@google.com>
* symtab.h (symbol_set_names): Document that copy_name must be
set to true for non-nullterminated strings.
* symtab.c (symbol_set_names): Only make a nullterminated copy of
linkage_name if the entry was not found and we need to demangle.
Change-Id: I183302e1f51483ff6dff0fd5c3b0f32f0f04a5d2
This is more type-safe and can be faster due to inlining and
avoiding overhead from calling through a function pointer.
gdb/ChangeLog:
2019-10-29 Christian Biesinger <cbiesinger@google.com>
* Makefile.in (HFILES_NO_SRCDIR): Add gdb_binary_search.h.
* dwarf2-frame.c (bsearch_fde_cmp): Update.
(dwarf2_frame_find_fde): Replace bsearch with gdb::binary_search.
* gdbsupport/gdb_binary_search.h: New file.
Change-Id: I07e0a0e333f4062b27fc68d3a3f24881ebc68fd4
Adds a configure option --with-system-gdbinit-dir to specify a directory
in which to look for gdbinit files. All files in this directory are
loaded on startup (subject to -n/-nx as usual) as long as the extension
matches a known and enabled scripting language (.gdb/.py/.scm).
This also changes get_ext_lang_of_file to support ".gdb" files, similar
to get_ext_lang_defn's handling of EXT_LANG_GDB.
gdb/ChangeLog:
2019-10-29 Christian Biesinger <cbiesinger@google.com>
* NEWS: Mention new --with-system-gdbinit-dir option.
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Add new option --with-system-gdbinit-dir.
* extension.c (get_ext_lang_of_file): Return extension_language_gdb
for a ".gdb" suffix.
* main.c (get_init_files): Change system_gdbinit argument to
a vector and return the files in SYSTEM_GDBINIT_DIR in
addition to SYSTEM_GDBINIT.
(captured_main_1): Update.
(print_gdb_help): Update.
* top.c (print_gdb_configuration): Also print the value of
SYSTEM_GDBINIT_DIR.
gdb/doc/ChangeLog:
2019-10-29 Christian Biesinger <cbiesinger@google.com>
* Makefile.in: Also set SYSTEM_GDBINIT_DIR for the info manual
generation.
* gdb.texinfo (many sections): Document new --with-system-gdbinit-dir
option.
Change-Id: If233859ecc21bc6421d589b37cd658a3c7d030f2
Makes sure that the string is longer than prefix, so that strncmp will
do the right thing even if the string is not null-terminated.
For use in my string_view conversion patch:
https://sourceware.org/ml/gdb-patches/2019-10/msg00030.htmlhttps://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/125
gdb/ChangeLog:
2019-10-28 Christian Biesinger <cbiesinger@google.com>
* gdbsupport/common-utils.h (startswith): Add an overloaded version
that takes gdb::string_view arguments.
Change-Id: I5389855de2fd70e7065a789a79374b0693651b71
The patch f2aec7f6d1 changed the return type of relocate_gdb_directory to
std::string, but the change is not reflected in find_charset_names function.
(Probably missed because the broken code is behind an #ifdef).
gdb/ChangeLog
* charset.c (find_charset_names): Reflect API change.
In the previous commit, I accidentally changed the wrong line;
this reverts it to what it should be.
gdb/ChangeLog:
2019-10-25 Christian Biesinger <cbiesinger@google.com>
* symtab.c (symbol_set_names): Revert unintentional change in the
Ada case.
Change-Id: I9abf174927687e74c7435bd4607aab7f248c6e79
We can just keep around the malloc()-ed name we got from bfd and free
it later.
gdb/ChangeLog:
2019-10-25 Christian Biesinger <cbiesinger@google.com>
* symtab.c (struct demangled_name_entry): Change demangled name
to a unique_xmalloc_ptr<char>, now that we don't allocate it as
part of the struct anymore.
(symbol_set_names): No longer obstack allocate + copy the demangled
name, just store the allocated name from bfd.
Change-Id: Ie6ad50e1e1e73509f55d756f0a437897bb93e3b0
Currently gdb has an assertion that requires CIEs to be read in the
order in which they appear in the debug info:
gdb_assert (n < 1
|| cie_table->entries[n - 1]->cie_pointer < cie->cie_pointer);
This assertion ensures that the table will be sorted, which is
important because it is later searched using bsearch.
However, a customer provided an executable that causes this assertion
to trigger. This executable causes decode_frame_entry_1 to call
decode_frame_entry to find the CIE, resulting in an out-of-order read.
I don't know a good way to construct a reproducer, but this can happen
if the FDE appears before its CIE. See
https://sourceware.org/bugzilla/show_bug.cgi?id=16563
This patch fixes the problem by storing CIEs in an unordered map. The
CIE table is discarded after the frame section is parsed, so this
seemed both simple and straightforward.
gdb/ChangeLog
2019-10-25 Tom Tromey <tromey@adacore.com>
* dwarf2-frame.c (dwarf2_cie_table): Now a typedef.
(bsearch_cie_cmp, add_cie): Remove.
(find_cie): Reimplement.
(decode_frame_entry_1, decode_frame_entry): Change type. Update.
(dwarf2_build_frame_info): Update.
Change-Id: I4a99597fa4b1398a9d105b683a36d992d506485c
gdbserver has its own implementation of xstrdup. However, because
gdbserver links against libiberty now, I think this is not needed.
This patch removes it.
gdb/gdbserver/ChangeLog
2019-10-25 Tom Tromey <tromey@adacore.com>
* utils.c (xstrdup): Remove.
Change-Id: I2aa56d18d0f9af8e70a00dff431d2fda5705a5d5
Make gdb_test_multiple calls shorter by using new gdb_test_multiple variable
$gdb_test_name and new gdb_test_multiple pattern flag -wrap.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-25 Tom de Vries <tdevries@suse.de>
* gdb.reverse/sigall-precsave.exp: Use -wrap and $gdb_test_name in
gdb_test_multiple calls.
* gdb.reverse/sigall-reverse.exp: Same.
* gdb.reverse/solib-precsave.exp: Same.
* gdb.reverse/solib-reverse.exp: Same.
* gdb.reverse/until-precsave.exp: Same.
* gdb.reverse/until-reverse.exp: Same.
Change-Id: I67bb327d069dbc439410996bcfe6c7f905b2ca52
Clear the stale source cache when re-reading symbols.
PR gdb/25126
* symfile.c (reread_symbols): Call forget_cached_source_info to
clear the stale source cache.
The only use of python_has_threads has been removed in
commit 404f29021a
gdb/ChangeLog:
2019-10-24 Christian Biesinger <cbiesinger@google.com>
* configure: Rebuild.
* configure.ac: Remove code that sets python_has_threads.
Change-Id: I75f1b873562bc2abc6f2db17699a3e82fcfd2de3
The version checking code is not necessary. It is only used to define
HAVE_LIBPYTHON2_6 or HAVE_LIBPYTHON2_7, which is not used anywhere.
If a version check is desired, the PY_{MAJOR,MINOR}_VERSION macro from
the Python headers can be (and is) used, which does not require updating
configure.ac whenever a new Python version is released.
gdb/ChangeLog:
2019-10-24 Christian Biesinger <cbiesinger@google.com>
* config.in: Regenerate.
* configure: Regenerate.
* configure.ac: Remove the code that uses sed to get the python
version and defines HAVE_LIBPYTHON2_6 / HAVE_LIBPYTHON2_7.
Change-Id: I07073870d9040c2bc8519882c8b3c1368edd4513
Currently, in order to rewrite:
...
gdb_test <command> <pattern> <message>
...
using gdb_test_multiple, we get:
...
gdb_test_multiple <command> <message> {
-re "\[\r\n\]*(?:<pattern>)\[\r\n\]+$gdb_prompt $" {
pass $gdb_test_name
}
}
...
Add a '-wrap pattern flag to gdb_test_multiple, that wraps the regexp
pattern as gdb_test wraps its message argument.
This allows us to rewrite into the more compact:
...
gdb_test_multiple <command> <message> {
-re -wrap <pattern> {
pass $gdb_test_name
}
}
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-10-24 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_test_multiple): Add -wrap pattern flag.
* gdb.reverse/step-precsave.exp: Rewrite gdb_test_multiple containing
kfail using -wrap pattern flag and convenience variable
gdb_test_name.
Change-Id: Ie42c97d5ab7acf6db351299ccd23a83540fe6e1a
The documentation for Progspace.block_for_pc says:
Return the innermost gdb.Block containing the given pc value. If the
block cannot be found for the pc value specified, the function will
return None.
However, the implementation actually throws an error for invalid
addresses, like this:
(gdb) python print gdb.current_progspace ().block_for_pc (1)
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Cannot locate object file for block.
Error while executing Python code.
(gdb)
This has been the behaviour since the command was first added (when
the documentation was still as above) in this commit:
commit f3e9a8177c
Date: Wed Feb 24 21:18:28 2010 +0000
Since that commit the code in question has moved around, but the
important parts are largely unchanged. The function in question is
now in py-progspace.c:pspy_block_for_pc.
Examining the code shows that the real state is more complex than just
the function throws an error instead of returning None, instead the
real situation is:
1. If we can't find a compilation unit for the $pc value then we
throw an error, but
2. If we can find a compilation unit, but can't find a block within
the compilation unit for the $pc then return None.
I suspect for most users of the Python API this distinction is
irrelevant, and I propose that we standardise on one single failure
mechanism.
Given the function can currently return None in some cases, and is
documented to return None on error, I propose we make that the case
for all error paths, which is what this patch does.
As the Progspace.block_for_pc method is currently untested, I've added
some basic tests including for a call with an invalid $pc.
This is potentially an API breaking change, though an undocumented
part of the API. Also, users should have been checking and handling a
None return value anyway, so my hope is that this shouldn't be too
disruptive.
gdb/ChangeLog:
* python/py-progspace.c (pspy_block_for_pc): Return None for all
error paths.
gdb/testsuite/ChangeLog:
* gdb.python/py-progspace.exp: Add tests for the
Progspace.block_for_pc method.
Change-Id: I9cea8d2132902bcad0013d1fd39080dd5423cc57
Now that gdb can unconditionally use a -I pointing at the top of the
source tree, we can remove the ugly "../opcodes/" formulation that was
needed earlier. This patch adds the -I and cleans up these includes.
gdb/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
* arc-tdep.c: Remove ".." from include.
* frv-tdep.c: Remove ".." from include.
* lm32-tdep.c: Remove ".." from include.
* microblaze-tdep.c: Remove ".." from include.
* or1k-tdep.h: Remove ".." from include.
* s12z-tdep.c: Remove ".." from include.
* Makefile.in (OPCODES_CFLAGS): Add comment.
(TOP_CFLAGS): New variable.
(INTERNAL_CFLAGS_BASE): Add TOP_CFLAGS.
Change-Id: I21428726d55f9fab0c9da90b56f6664f258cf91a
readline turns out to be a bit of a stumbling block for the project to
move gdbsupport (and then gdbserver) to the top-level.
The issue is that readline headers are intended to be included with
names like "readline/readline.h". To support this, gdb effectively
adds a -I option pointing to the top-level source directory -- but,
importantly, this option is not used when the system readline is used.
For gdbsupport, a -I option like this would always be needed, but that
in turn would break the system readline case. This was PR build/17077,
fixed in commit a8a5dbcab8.
Previously, we had discussed this on the gdb-patches list in terms of
removing readline from the tree
https://sourceware.org/ml/gdb-patches/2019-09/msg00317.html
However, Eli expressed some concerns, and Joel did as well (off-list).
Given those concerns, and the fact that a patch-free local readline is
relatively new in gdb (it was locally patched for years), I changed my
mind and decided to handle this situation by moving the readline
sources down a level.
That is, upstream readline is now in readline/readline, and the
top-level readline directory just contains the minimal configury
needed to build that.
This fixes the problem because, when gdb unconditionally adds a
-I$(top_srcdir), this will not find readline headers. A separate -I
will be needed instead, which is exactly what's needed for
--with-system-readline.
gdb/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
* Makefile.in (READLINE_DIR): Update.
gdb/doc/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
* Makefile.in (READLINE_DIR): Update.
readline/ChangeLog
2019-10-23 Tom Tromey <tom@tromey.com>
Move old contents to readline/ subdirectory.
* aclocal.m4, configure, configure.ac, .gitignore, Makefile.am,
Makefile.in, README: New files.
Change-Id: Ice156a2ee09ea68722b48f64d97146d7428ea9e4
Extract out the code region that reserves stack space to a separate
function.
Fix the comment of 'call_function_by_hand_dummy' to remove reference
to the NARGS argument that was removed in commit (e71585ffe2 "Use
gdb:array_view in call_function_by_hand & friends").
gdb/ChangeLog:
2019-10-23 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infcall.c (call_function_by_hand_dummy): Fix the function
comment. And extract out a code section into...
(reserve_stack_space): ...this new function.
Change-Id: I8938ef4134aff68a0a21724aaa2406bfe453438a
Remove the unused SP parameter from the auxiliary function
'value_arg_coerce'.
gdb/ChangeLog:
2019-10-23 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infcall.c (value_arg_coerce): Remove an unused parameter.
(call_function_by_hand_dummy): Update the call to
'value_arg_coerce'.
Change-Id: If324a1dda3fa5d4c145790b92bd3f656c00296f4
This is a refactoring that performs type assertions on the callee
function at the beginning of 'call_function_by_hand_dummy' rather than
at a later point so that
- the checks are grouped together at the beginning of the function for
improved readability, and
- we don't have to align and push things on the stack only to find out
later that the function call is illegal.
gdb/ChangeLog:
2019-10-23 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infcall.c (call_function_by_hand_dummy): Refactor.
Change-Id: I411ac083ac6a9ee6eb93c4b82393a81a4fc927be
Tom Tromey
Simon Marchi
Tom Tromey
Luis Machado
Joel Brobecker
Simon Marchi
Philippe Waroquiers
Kevin Buettner
Christian Biesinger
George Barrett
Tankut Baris Aktemur
Andrew Burgess
Wataru Ashihara
Tom de Vries
Keith Seitz
Mihails Strasuns
Peeter Joot
Lukas Durfina
Sergio Durigan Junior
Ali Tamur
Rainer Orth
H.J. Lu