Add missing documentation for the debugredirect setting.
Add description and uses of gdb.in/gdb.cmd to the testsuite README.
Mention this in the NEWS file.
gdb/ChangeLog:
* NEWS: Add debugredirect and testsuite sections.
gdb/doc/ChangeLog:
* gdb.texinfo (Shell Commands): Add debugredirect.
gdb/testsuite/ChangeLog:
* README (Re-running Tests Outside The Testsuite): New section.
This solves an assertion failure when a remote provides a target
description which only refers to floating point registers by their
hardware name (e.g. f0), rather than their ABI name (e.g. ft0). GDB
assumed that should the floating point register feature be presented,
it would contain a register called ft0.
The floating point length is now instead determined by searching for
the same register, but looking for any of its aliases.
gdb/ChangeLog:
* riscv-tdep.c (riscv_gdbarch_init): Support determining flen from
target descriptions using exclusively floating point register name
aliases.
In this commit:
commit 34d11c682f
Date: Fri May 3 15:23:55 2019 +0100
gdb/fortran: Use floatformats_ia64_quad for fortran 16-byte floats
GDB was changed such that the Fortran's 16-byte float format was
obtained by calling gdbarch_floatformat_for_type instead of just using
gdbarch_long_double_format as it was before.
The problem with this default_floatformat_for_type can return NULL in
some cases, and the code introduced in 34d11c682f didn't consider
this.
This commit introduces several alternative strategies for finding a
suitable 16-byte floating point type. First GDB calls
gdbarch_floatformat_for_type (this was what 34d11c682f added), if this
returns null GDB will use gdbarch_long_double_format if it is the
correct size (this was the format used before 34d11c682f). Finally,
if neither of the above provides a suitable type then GDB will create
a new dummy type.
This final dummy type is unlikely to provide an correct debug
experience as far as examining the 16-byte floats, but it should
prevent GDB crashing.
gdb/ChangeLog:
PR gdb/18644:
* f-lang.c (build_fortran_types): Handle the case where
gdbarch_floatformat_for_type returns a nullptr.
When building gdb on ubuntu 16.04 with gcc 5.4.0, and running the gdb
testsuite we run into:
...
FAIL: gdb.linespec/explicit.exp: complete after -line: \
cmd complete "b -line argument " (timeout)
...
The failure is reproducible outside the testsuite like this:
...
$ gdb -q build/gdb/testsuite/outputs/gdb.linespec/explicit/explicit \
-ex "complete b -line argument"
Reading symbols from \
build/gdb/testsuite/outputs/gdb.linespec/explicit/explicit...
terminate called after throwing an instance of 'std::length_error'
what(): basic_string::_M_create
Aborted (core dumped)
...
The problem is here in complete_command:
...
completion_result result = complete (arg, &word, "e_char);
std::string arg_prefix (arg, word - arg);
if (result.number_matches != 0)
...
The problem is that the word variable is not initialized when
result.number_matches == 0, but the variable is still used in the arg_prefix
initialization.
Fix this by guarding the arg_prefix initialization with the
'result.number_matches != 0' test.
Build and tested on x86_64-linux.
gdb/ChangeLog:
2019-05-21 Tom de Vries <tdevries@suse.de>
PR cli/24587
* cli/cli-cmds.c (complete_command): Fix use of unitialized variable.
When building gdb on ubuntu 16.04 with gcc 5.4.0, and running the gdb
testsuite we run into failures due test-cases requiring at least c++1.
Fix this by adding -std=c++11 to those test-cases.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-21 Tom de Vries <tdevries@suse.de>
* gdb.arch/amd64-eval.exp: Require c++11.
* gdb.base/max-depth.exp: Same.
* gdb.compile/compile-cplus-array-decay.exp: Same.
* gdb.cp/meth-typedefs.exp: Same.
* gdb.cp/subtypes.exp: Same.
* gdb.cp/temargs.exp: Same.
This matches the kill in gdb_file_cmd, and ensures that the command is not
sent to the gdb.in file.
When gdb.in is used as a batch file, any kill commands run before the target
is started will cause gdb to stop processing commands.
gdb/testsuite/ChangeLog:
* lib/gdbserver-support.exp (gdbserver_run): Mark kill as optional.
PR gdb/18644 is caused by GDB using the wrong floating point format
for gfortran's 16-byte floating point type, including when the 16-byte
float is used as the component of a 32-byte complex type.
This commit addresses the issue in two places, first in i386-tdep.c,
there is already some code to force the use of floatformats_ia64_quad
for specific named types, this is extended to include the type names
that gfortran uses for its 16-byte floats.
Second, the builtin 16-byte float type (in f-lang.c) is changed so it
no longer uses gdbarch_long_double_format. On i386 this type is not
16-bytes, but is smaller, this is not what gfortran is expecting.
Instead we now use gdbarch_floatformat_for_type and ask for a
16-byte (128 bit) type using the common gfortran type name. This is
then spotted in i386-tdep.c (thanks to the first change above) and we
again get floatformats_ia64_quad returned.
This patch was tested on X86-64/GNU-Linux using '--target_board=unix'
and '--target_board=unix/-m32', and resolves all of the known failures
associated with PR gdb/18644. I've also added the test case from the
original bug report.
gdb/ChangeLog:
PR gdb/18644:
* f-lang.c (build_fortran_types): Use floatformats_ia64_quad for
16-byte floats.
* i386-tdep.c (i386_floatformat_for_type): Use
floatformats_ia64_quad for the 16-byte floating point component
within a fortran 32-byte complex number.
gdb/testsuite/ChangeLog:
PR gdb/18644
* gdb.fortran/complex.exp: Remove setup_kfail calls.
* gdb.fortran/printing-types.exp: Add new test.
* gdb.fortran/printing-types.f90: Add 16-byte real variable for
testing.
* gdb.fortran/type-kinds.exp (test_cast_1_to_type_kind): Remove
setup_kfail call.
Adds a constructor to 'struct cu_partial_die_info' and disables the
default constructor, preventing partially initialised instances from
being created.
Update 'find_partial_die' to return a const struct.
Users of 'find_partial_die' are updated to take account of the above
two changes.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* dwarf2read.c (struct cu_partial_die_info): Add constructor,
delete default constructor.
(find_partial_die): Update to return const struct.
(partial_die_parent_scope): Move variable declaration into scope
of its use and change its type to auto.
(guess_partial_die_structure_name): Likewise.
(partial_die_info::fixup): Likewise.
find_and_open_source casts away const, but hasn't needed to in a
while. This removes the cast and a strangely hostile comment.
gdb/ChangeLog
2019-05-17 Tom Tromey <tromey@adacore.com>
* source.c (find_and_open_source): Remove cast.
I noticed that annotate_source takes a "char *", but really should
take a "const char *". This patch fixes this.
gdb/ChangeLog
2019-05-17 Tom Tromey <tromey@adacore.com>
* annotate.c (annotate_source): Make "filename" const.
* annotate.h (annotate_source): Use const.
TRANSCRIPT is superseeded by the .in, .cmd and .debug files, and
can be removed.
gdb/testsuite/ChangeLog
* README (Running the Testsuite): Change example.
(Testsuite Parameters): Remove TRANSCRIPT.
* lib/gdb.exp: Remove TRANSCRIPT check.
Add "replay" to the list of GDBSERVER_DEBUG options. This will
cause a gdbserver.replay file to be written to the test output
directory.
At the same time switch this to a comma separated list in order
to easily handle all possible options.
The replay log is created by GDB, but has been added to
GDBSERVER_DEBUG as it is only required for gdbserver tests. To
enable it, the gdb_debug_init is overridden to allow the additional
checking, before calling the original function.
gdb/testsuite/ChangeLog:
* README (Testsuite Parameters): Add replay logging to
GDBSERVER_DEBUG.
(gdbserver,debug): Refer to GDBSERVER_DEBUG.
* lib/gdbserver-support.exp (gdbserver_start): Treat gdbserverdebug
as a comma separated list.
(gdb_debug_init): Override procedure.
When spawning gdb or gdbserver create a .cmd file in the test output
directory containing the full command line, ensuring the current gdb
instance is appended to the files so that they can be quickly matched
to the corresponding gdb.in file.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (default_gdb_spawn): Call gdb_write_cmd_file.
(gdb_write_cmd_file): New procedure.
* lib/gdbserver-support.exp (gdbserver_start): Call
gdbserver_write_cmd_file.
(gdbserver_write_cmd_file): New proedure.
When debugging testsuite failures, it can be awkward parsing gdb.log to
obtain all the commands run in order to manually re-run the test.
This patch adds the functionality to save all gdb commands to the file gdb.in
when the testsuite is run. The file is saved in the directory for the test and
if gdb is restarted then .1, .2, .3 etc is added to the filename.
Once a test has been run, the .in file can be used to re-run the test in the
following way:
gdb -x outputs/gdb.store/gdb.in outputs/gdb.store/store
The code works by intercepting send_gdb. I've added a TYPE to ensure that any
commands that would destroy the playback are kept from the log (for example the
Y from an answer to a y/n question).
Adds library function standard_output_file_with_gdb_instance to open a file
postfixed with count of the gdb instance. Ensure this count is reset when a new
.exp script is run.
I've re-run a random selection of .in files to check they do not error. Logs with
commands such as "attach <pid>" will not directly work when re-run.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_unload): Mark Y as an answer.
(delete_breakpoints): Likewise.
(gdb_run_cmd): Likewise.
(gdb_start_cmd): Likewise.
(gdb_starti_cmd): Likewise.
(gdb_internal_error_resync): Likewise.
(gdb_test_multiple): Likewise.
(gdb_reinitialize_dir): Likewise.
(default_gdb_exit): Likewise.
(gdb_file_cmd): Mark kill as optional.
(default_gdb_start): Call gdb_stdin_log_init.
(send_gdb): Call gdb_stdin_log_write.
(rerun_to_main): Mark Y as an answer.
(gdb_stdin_log_init): New function.
(gdb_stdin_log_write): Likewise.
Fix up all failures encountered when running the testsuite with
GDB_DEBUG="infrun".
Some tests rely on enabling debugging for various components. With
debugging on, this will be lost to the debug file.
Disable separate tty for mi tests when debugging. This currently
does not work.
disasm.c should send errors to the stderr instead of the logfile.
Note that enabling debug for other components might still cause
additional errors above what has been fixed here.
gdb/ChangeLog:
* disasm.c (set_disassembler_options): Send errors to stderr.
gdb/testsuite/ChangeLog:
* gdb.base/breakpoint-in-ro-region.exp: Disable when debugging.
* gdb.base/debug-expr.exp: Likewise.
* gdb.base/foll-fork.exp: Likewise.
* gdb.base/foll-vfork.exp: Likewise.
* gdb.base/fork-print-inferior-events.exp: Likewise.
* gdb.base/gdb-sigterm.exp: Likewise.
* gdb.base/gdbinit-history.exp: Likewise.
* gdb.base/osabi.exp: Likewise.
* gdb.base/sss-bp-on-user-bp-2.exp: Likewise.
* gdb.base/ui-redirect.exp: Likewise.
* gdb.gdb/unittest.exp: Likewise.
* gdb.mi/mi-break.exp: Disable separate-mi-tty when debugging.
* gdb.mi/mi-watch.exp: Likewise.
* gdb.mi/new-ui-mi-sync.exp: Likewise.
* gdb.mi/user-selected-context-sync.exp: Likewise.
* gdb.python/python.exp: Disable debug test when debugging.
* gdb.threads/check-libthread-db.exp: Disable when debugging.
* gdb.threads/signal-while-stepping-over-bp-other-thread.exp:
Likewise.
* gdb.threads/stepi-random-signal.exp: Likewise.
Add both board option and environment variable which enables gdb
debug via a comma separated list and sends it to the file gdb.debug,
located in the output directory for the current test. Document this.
Add support for the environment variable in the Makefile.
The testsuite can be run with gdb debug enabled in the following way:
make check GDB_DEBUG="infrun,target,remote"
A Test with multiple invocations of GDB will all append debug to the
same log file.
gdb/testsuite/ChangeLog:
* Makefile.in: Pass through GDB_DEBUG.
* README (Testsuite Parameters): Add GDB_DEBUG.
(gdb,debug): Add board setting.
* lib/gdb.exp (default_gdb_start): Start debugging.
(gdb_debug_enabled): New procedure.
(gdb_debug_init): Likewise.
Currently, when logging is enabled, output will be sent to both a
logfile and standard terminal output. The redirect option sends output
only to the logfile. This includes all debug output.
Add the option to redirect debug output seperately to normal
output, using the cli command:
set logging debugredirect on
By setting this and enabling logging, all output and debug will
be sent to the logfile. The user will still see all output but
no debug output.
This causes a change in behaviour for anyone currently using
logging redirect, as now only output will be redirected. Users
will have to issue the additional command above to also redirect
debug.
Expand ui-redirect.exp cover the changes.
gdb/ChangeLog:
* cli/cli-interp.c (struct saved_output_files): Add saved entry.
(cli_interp_base::set_logging): Check debug_redirect.
* cli/cli-interp.h (set_logging): Add debug_redirect parameter.
* cli/cli-logging.c (debug_redirect): Add static variable.
(pop_output_files): Add default param.
(handle_redirections): Print debug setting.
(show_logging_command): Likewise.
(_initialize_cli_logging): Add debugredirect command.
* interps.c (current_interp_set_logging): Add debug_redirect
parameter.
* interps.h (set_logging): Add debug_redirect parameter.
(current_interp_set_logging): Likewise.
* mi/mi-common.h: Likewise.
* mi/mi-interp.c (mi_interp::set_logging): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/ui-redirect.exp: Add debug redirect tests.
Instead of using two bools to decide if the files should close when tee_file
is closed, make file one stay open and file two close. This simplifies the
use cases for it.
Inline the make_logging_output into the calling functions (the logic here
looks ugly in order to simplify a later change).
Expand ui-redirect.exp to cover the changes, similar to mi-logging.exp.
gdb/ChangeLog:
* cli/cli-interp.c (cli_interp_base::set_logging): Create tee_file
directly.
* cli/cli-interp.h (make_logging_output): Remove declaration.
* cli/cli-logging.c (make_logging_output): Remove function.
* mi/mi-interp.c (mi_interp::set_logging): Create tee_file
directly.
* ui-file.c (tee_file::tee_file): Remove bools.
(tee_file::~tee_file): Remove deletes.
* ui-file.h (tee_file): Remove bools.
gdb/testsuite/ChangeLog:
* gdb.base/ui-redirect.exp: Test redirection.
There is a CLI command 'complete' intended to use with emacs. Such a command
would also be useful for MI frontends, when separate CLI and MI channels cannot
be used. For example, on Windows (because of lack of PTYs) or when GDB is used
through SSH session.
This commit adds a new '-complete' MI command.
gdb/Changelog:
2019-01-28 Jan Vrany <jan.vrany@fit.cvut.cz>
* mi/mi-cmds.h (mi_cmd_complete): New function.
* mi/mi-main.c (mi_cmd_complete): Likewise.
* mi/mi-cmds.c: Define new MI command -complete.
* NEWS: Mention new -complete command.
gdb/doc/ChangeLog:
2019-01-28 Jan Vrany <jan.vrany@fit.cvut.cz>
* gdb.texinfo (Miscellaneous GDB/MI Commands): Document new
MI command -complete.
gdb/testsuite/ChangeLog:
2019-01-28 Jan Vrany <jan.vrany@fit.cvut.cz>
* gdb.mi/mi-complete.exp: New file.
* gdb.mi/mi-complete.cc: Likewise.
Extract completion logic from CLI complete_command() into a new
helper function complete().
gdb/Changelog:
* completer.h (complete): New function.
* completer.c (complete): Likewise.
* cli/cli-cmds.c: (complete_command): Update to use new complete()
function defined in completer.h.
When running gdb using AddressSanitizer, and loading a cc1plus binary built
with profiledbootstrap and -flto, we run into a heap-use-after-free error:
...
$ LD_PRELOAD=/usr/lib64/libasan.so.3 ./gdb -batch cc1plus
==26855==ERROR: AddressSanitizer: heap-use-after-free on address \
0x62100ad8a8b0 at pc 0x7f13803cc9e3 bp 0x7ffe55b0d090 sp 0x7ffe55b0c840
READ of size 47 at 0x62100ad8a8b0 thread T0
#0 0x7f13803cc9e2 (/usr/lib64/libasan.so.3+0x3e9e2)
#1 0x5e7a0d in typename_concat gdb/dwarf2read.c:22661
#2 0x5c6437 in partial_die_full_name gdb/dwarf2read.c:8876
#3 0x5c6555 in add_partial_symbol gdb/dwarf2read.c:8893
#4 0x5c6ecf in add_partial_subprogram gdb/dwarf2read.c:9156
#5 0x5c5e90 in scan_partial_symbols gdb/dwarf2read.c:8668
#6 0x5c6c0a in add_partial_namespace gdb/dwarf2read.c:9081
#7 0x5c5f99 in scan_partial_symbols gdb/dwarf2read.c:8702
#8 0x5c48b6 in process_psymtab_comp_unit_reader gdb/dwarf2read.c:8056
#9 0x5c3c1f in init_cutu_and_read_dies gdb/dwarf2read.c:7689
#10 0x5c4c03 in process_psymtab_comp_unit gdb/dwarf2read.c:8140
#11 0x5c58a2 in dwarf2_build_psymtabs_hard gdb/dwarf2read.c:8500
#12 0x5c0d03 in dwarf2_build_psymtabs(objfile*) gdb/dwarf2read.c:6337
#13 0x612359 in read_psyms gdb/elfread.c:1311
#14 0x798a64 in require_partial_symbols(objfile*, int) gdb/psymtab.c:115
#15 0x867d7b in read_symbols gdb/symfile.c:821
#16 0x8683d9 in syms_from_objfile_1 gdb/symfile.c:1000
#17 0x8684a1 in syms_from_objfile gdb/symfile.c:1017
#18 0x868873 in symbol_file_add_with_addrs gdb/symfile.c:1124
#19 0x868b0a in symbol_file_add_from_bfd(bfd*, char const*, \
enum_flags<symfile_add_flag>, std::vector<other_sections, \
std::allocator<other_sections> >*, \
enum_flags<objfile_flag>, objfile*) gdb/symfile.c:1204
#20 0x868b64 in symbol_file_add(char const*, \
enum_flags<symfile_add_flag>, \
std::vector<other_sections, \
std::allocator<other_sections> >*, \
enum_flags<objfile_flag>) gdb/symfile.c:1217
#21 0x868c39 in symbol_file_add_main_1 gdb/symfile.c:1240
#22 0x868bd0 in symbol_file_add_main(char const*, \
enum_flags<symfile_add_flag>) gdb/symfile.c:1231
#23 0x71f1b2 in symbol_file_add_main_adapter gdb/main.c:395
#24 0x71f10e in catch_command_errors gdb/main.c:372
#25 0x71ff5f in captured_main_1 gdb/main.c:1043
#26 0x72045d in captured_main gdb/main.c:1163
#27 0x7204c8 in gdb_main(captured_main_args*) gdb/main.c:1188
#28 0x40fd7d in main gdb/gdb.c:32
#29 0x7f137e300f49 in __libc_start_main (/lib64/libc.so.6+0x20f49)
#30 0x40fc89 in _start (/data/gdb_versions/devel/build/gdb/gdb+0x40fc89)
0x62100ad8a8b0 is located 944 bytes inside of 4064-byte region \
[0x62100ad8a500,0x62100ad8b4e0)
freed by thread T0 here:
#0 0x7f13804523a0 in __interceptor_free (/usr/lib64/libasan.so.3+0xc43a0)
#1 0x435e44 in xfree<void> gdb/common/common-utils.h:60
#2 0xa82c25 in call_freefun libiberty/obstack.c:103
#3 0xa83098 in _obstack_free libiberty/obstack.c:280
#4 0x4367da in auto_obstack::~auto_obstack() gdb/gdb_obstack.h:101
#5 0x5ed72c in dwarf2_cu::~dwarf2_cu() gdb/dwarf2read.c:25341
#6 0x5fb5bb in std::default_delete<dwarf2_cu>::operator()(dwarf2_cu*) const \
/usr/include/c++/7/bits/unique_ptr.h:78
#7 0x5f7334 in std::unique_ptr<dwarf2_cu, \
std::default_delete<dwarf2_cu> >::~unique_ptr() \
/usr/include/c++/7/bits/unique_ptr.h:268
#8 0x5c3ce5 in init_cutu_and_read_dies gdb/dwarf2read.c:7624
#9 0x5c4c03 in process_psymtab_comp_unit gdb/dwarf2read.c:8140
#10 0x5c58a2 in dwarf2_build_psymtabs_hard gdb/dwarf2read.c:8500
#11 0x5c0d03 in dwarf2_build_psymtabs(objfile*) gdb/dwarf2read.c:6337
#12 0x612359 in read_psyms gdb/elfread.c:1311
#13 0x798a64 in require_partial_symbols(objfile*, int) gdb/psymtab.c:115
#14 0x867d7b in read_symbols gdb/symfile.c:821
#15 0x8683d9 in syms_from_objfile_1 gdb/symfile.c:1000
#16 0x8684a1 in syms_from_objfile gdb/symfile.c:1017
#17 0x868873 in symbol_file_add_with_addrs gdb/symfile.c:1124
#18 0x868b0a in symbol_file_add_from_bfd(bfd*, char const*, \
enum_flags<symfile_add_flag>, std::vector<other_sections, \
std::allocator<other_sections> >*, \
enum_flags<objfile_flag>, objfile*) gdb/symfile.c:1204
#19 0x868b64 in symbol_file_add(char const*, \
enum_flags<symfile_add_flag>, std::vector<other_sections, \
std::allocator<other_sections> >*, \
enum_flags<objfile_flag>) gdb/symfile.c:1217
#20 0x868c39 in symbol_file_add_main_1 gdb/symfile.c:1240
#21 0x868bd0 in symbol_file_add_main(char const*, \
enum_flags<symfile_add_flag>) gdb/symfile.c:1231
#22 0x71f1b2 in symbol_file_add_main_adapter gdb/main.c:395
#23 0x71f10e in catch_command_errors gdb/main.c:372
#24 0x71ff5f in captured_main_1 gdb/main.c:1043
#25 0x72045d in captured_main gdb/main.c:1163
#26 0x7204c8 in gdb_main(captured_main_args*) gdb/main.c:1188
#27 0x40fd7d in main gdb/gdb.c:32
#28 0x7f137e300f49 in __libc_start_main (/lib64/libc.so.6+0x20f49)
previously allocated by thread T0 here:
#0 0x7f13804526b8 in __interceptor_malloc (/usr/lib64/libasan.so.3+0xc46b8)
#1 0x5114b5 in xmalloc gdb/common/common-utils.c:44
#2 0xa82bd5 in call_chunkfun libiberty/obstack.c:94
#3 0xa82eda in _obstack_newchunk libiberty/obstack.c:206
#4 0x477310 in allocate_on_obstack::operator new(unsigned long, obstack*) \
gdb/gdb_obstack.h:117
#5 0x5dea8c in load_partial_dies gdb/dwarf2read.c:18571
#6 0x5c487f in process_psymtab_comp_unit_reader gdb/dwarf2read.c:8054
#7 0x5c3c1f in init_cutu_and_read_dies gdb/dwarf2read.c:7689
#8 0x5c4c03 in process_psymtab_comp_unit gdb/dwarf2read.c:8140
#9 0x5c58a2 in dwarf2_build_psymtabs_hard gdb/dwarf2read.c:8500
#10 0x5c0d03 in dwarf2_build_psymtabs(objfile*) gdb/dwarf2read.c:6337
#11 0x612359 in read_psyms gdb/elfread.c:1311
#12 0x798a64 in require_partial_symbols(objfile*, int) gdb/psymtab.c:115
#13 0x867d7b in read_symbols gdb/symfile.c:821
#14 0x8683d9 in syms_from_objfile_1 gdb/symfile.c:1000
#15 0x8684a1 in syms_from_objfile gdb/symfile.c:1017
#16 0x868873 in symbol_file_add_with_addrs gdb/symfile.c:1124
#17 0x868b0a in symbol_file_add_from_bfd(bfd*, char const*, \
enum_flags<symfile_add_flag>, \
std::vector<other_sections, \
std::allocator<other_sections> >*, \
enum_flags<objfile_flag>, objfile*) gdb/symfile.c:1204
#18 0x868b64 in symbol_file_add(char const*, enum_flags<symfile_add_flag>, \
std::vector<other_sections, \
std::allocator<other_sections> >*, \
enum_flags<objfile_flag>) gdb/symfile.c:1217
#19 0x868c39 in symbol_file_add_main_1 gdb/symfile.c:1240
#20 0x868bd0 in symbol_file_add_main(char const*, \
enum_flags<symfile_add_flag>) gdb/symfile.c:1231
#21 0x71f1b2 in symbol_file_add_main_adapter gdb/main.c:395
#22 0x71f10e in catch_command_errors gdb/main.c:372
#23 0x71ff5f in captured_main_1 gdb/main.c:1043
#24 0x72045d in captured_main gdb/main.c:1163
#25 0x7204c8 in gdb_main(captured_main_args*) gdb/main.c:1188
#26 0x40fd7d in main gdb/gdb.c:32
#27 0x7f137e300f49 in __libc_start_main (/lib64/libc.so.6+0x20f49)
...
This error happens as follows.
The function find_partial_die has a cu argument, but returns a pdi which may
or may not be from that cu:
...
/* Find a partial DIE at OFFSET, which may or may not be in CU,
except in the case of .debug_types DIEs which do not reference
outside their CU (they do however referencing other types via
DW_FORM_ref_sig8). */
static struct partial_die_info *
find_partial_die (sect_offset sect_off, int offset_in_dwz, struct dwarf2_cu *cu)
...
So the pdi returned by find_partial_die here in partial_die_parent_scope may
be from another cu:
...
partial_die_parent_scope (struct partial_die_info *pdi,
struct dwarf2_cu *cu)
{
const char *grandparent_scope;
struct partial_die_info *parent, *real_pdi;
/* We need to look at our parent DIE; if we have a DW_AT_specification,
then this means the parent of the specification DIE. */
real_pdi = pdi;
while (real_pdi->has_specification)
real_pdi = find_partial_die (real_pdi->spec_offset,
real_pdi->spec_is_dwz, cu);
parent = real_pdi->die_parent;
...
in which case both real_pdi and parent will be not from cu, but from another
one, say cu2.
Subsequently, cu's comp_unit_obstack is used to set parent->scope:
...
parent->scope = typename_concat (&cu->comp_unit_obstack,
grandparent_scope,
parent->name, 0, cu);
...
So, we use cu->comp_unit_obstack to assign a value to the scope field of
a pdi belonging to cu2, and when cu is deleted, the scope field points to a
freed value.
Fix this by making find_partial_die return the cu corresponding to the
returned pdi, and handling this at the call sites.
Tested on x86_64-linux.
gdb/ChangeLog:
2019-05-17 Tom de Vries <tdevries@suse.de>
PR gdb/24094
* dwarf2read.c (struct cu_partial_die_info): New struct.
(find_partial_die): Return cu_partial_die_info.
(partial_die_parent_scope, guess_partial_die_structure_name)
(partial_die_info::fixup): Handle new return type of find_partial_die.
This patch simplifies the code of
stap-probe.c:stap_parse_register_operand by making "regname" an
std::string. No functionality change.
I'm this code's maintainer, so I'm pushing this as it's a fairly
trivial patch.
gdb/ChangeLog:
2019-05-16 Sergio Durigan Junior <sergiodj@redhat.com>
* stap-probe.c (stap_parse_register_operand): Make "regname" an
"std::string", simplifying the algorithm.
I think the string formatting for complaints was messed up by Tom's
patch to simplify the complaint mechanism. This small and trivial
patch fixes them.
Pushed as obvious.
gdb/ChangeLog:
2019-05-16 Sergio Durigan Junior <sergiodj@redhat.com>
* stap-probe.c (handle_stap_probe): Fix complaint formatting.
(stap_static_probe_ops::get_probes): Likewise.
This patch contains three very small improvement on the logic of some
operations we do on stap-probe.c. They don't change what the code
does.
Pushed as obvious.
gdb/ChangeLog:
2019-05-16 Sergio Durigan Junior <sergiodj@redhat.com>
* stap-probe.c (stap_parse_register_operand): Make "if (*p->arg ==
'-')" and "else if".
(stap_parse_single_operand): Join checks for
"gdbarch_stap_parse_special_token_p" and
"gdbarch_stap_parse_special_token" in the same "if" statement.
Invert check when verifying for operation on register
displacement.
Some functions's comments were not entirely correct on stap-probe.c,
so this patch updates them.
Pushed as obvious.
gdb/ChangeLog:
2019-05-16 Sergio Durigan Junior <sergiodj@redhat.com>
* stap-probe.c (stap_get_opcode): Update comment.
(stap_get_expected_argument_type): Likewise.
(handle_stap_probe): Likewise.
This simple patch converts a bunch of "int"s to "bool" on stap-probe.c
and on the stap-related code present on i386-tdep.c.
Pushed as obvious (+ I'm the maintainer of this code).
gdb/ChangeLog:
2019-05-16 Sergio Durigan Junior <sergiodj@redhat.com>
* i386-tdep.c (i386_stap_parse_special_token_triplet): Change
return type to 'bool'. Adjust comment. Use 'bool' when
appropriate.
(i386_stap_parse_special_token_three_arg_disp): Likewise.
* stap-probe.c (stap_parse_argument_1): Likewise.
(stap_is_operator): Likewise.
(stap_is_generic_prefix): Likewise.
(stap_is_register_prefix): Likewise.
(stap_is_register_indirection_prefix): Likewise.
(stap_is_integer_prefix): Likewise.
(stap_generic_check_suffix): Likewise.
(stap_check_integer_suffix): Likewise.
(stap_check_register_suffix): Likewise.
(stap_check_register_indirection_suffix): Likewise.
(stap_parse_register_operand): Likewise.
(stap_parse_single_operand): Likewise.
(stap_parse_argument_1): Likewise.
(stap_probe::get_argument_count): Likewise.
(stap_is_operator): Likewise.
John Marshall pointed out that darwin-nat.c fails to build:
CXX darwin-nat.o
../../../binutils-gdb/gdb/darwin-nat.c:1709:8: error: must use 'class' tag to refer to type 'thread_info' in this scope
for (thread_info *it : all_threads ())
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/mach/thread_act.h:240:15: note:
class 'thread_info' is hidden by a non-type declaration of 'thread_info' here
kern_return_t thread_info
Mach has a thread_info() function declared in that header, which darwin-nat.c #includes.
This patch fixes the problem by reintroducing the struct keyword.
gdb/ChangeLog
2019-05-16 Tom Tromey <tromey@adacore.com>
* darwin-nat.c (thread_info_from_private_thread_info): Add struct
keyword to foreach.
Add tests for calling sizeof on indexed and sliced arrays, and on
pointers to arrays. These are all things that currently work, but
were previously untested.
gdb/testsuite/ChangeLog:
* gdb.fortran/vla-sizeof.exp: Add tests of sizeof applied to
indexed and sliced arrays, and pointers to arrays.
I happened to be looking at this code and noticed we could replace ints
by bools at a few places.
gdb/ChangeLog:
* linux-thread-db.c (try_thread_db_load_1): Change return type
to bool.
(try_thread_db_load): Likewise.
(try_thread_db_load_from_pdir_1): Likewise.
(try_thread_db_load_from_pdir): Likewise.
(try_thread_db_load_from_sdir): Likewise.
(try_thread_db_load_from_dir): Likewise.
(thread_db_load_search): Likewise.
(has_libpthread): Likewise.
(thread_db_load): Likewise.
Hi,
Ref.: https://bugzilla.redhat.com/show_bug.cgi?id=1708192https://bugzilla.redhat.com/show_bug.cgi?id=1708786
During the Fedora RPM build process, gdb-add-index is invoked to
extract the DWARF index from the binary, and GDB will segfault because
dwarf2read.c:parse_definition_macro's 'body' variable is NULL.
The underlying problem is that Fedora's rpm-build's "debugedit"
program will silently corrupt .debug_macro strings when a binary is
compiled with -g3. This is being taken care of by Mark Wielaard,
here:
https://bugzilla.redhat.com/show_bug.cgi?id=1708786
However, I still feel it's important to make GDB more resilient
against invalid DWARF input, so I'm proposing this rather simple patch
to catch the situation when "body == NULL" (i.e., it's probably been
corrupted) and issue a complaint. This is not a real fix to the
problem, of course, but at least GDB is able to finish without
segfaulting.
OK for master?
gdb/ChangeLog:
2019-05-15 Sergio Durigan Junior <sergiodj@redhat.com>
Ref.: https://bugzilla.redhat.com/show_bug.cgi?id=1708192
* dwarf2read.c (dwarf_decode_macro_bytes): Check whether 'body' is
NULL, and complain if that's the case.
Previously, the stack unwinder searched through consecutive bytes for values
which it thought might be the start of a stack mutating operation.
This was error prone, because such bytes could also be the operands of other
instructions. This change uses the opcodes api to interpret the code in each
frame.
gdb/ChangeLog:
* s12z-tdep.c (push_pull_get_stack_adjustment): New function.
(advance, posn, abstract_read_memory): New functions.
[struct mem_read_abstraction]: New struct.
(s12z_frame_cache): Use opcodes API to interpret stack frame code.
coerce_unspec_val_to_type does:
set_value_address (result, value_address (val));
However, this is only valid for lval_memory. This patch changes this
code to only set the address for lval_memory values.
This seems like an ordinary oversight in coerce_unspec_val_to_type,
and a test case would be difficult to write, so I'm submitting it
without a test case.
Tested on x86-64 Fedora 29; plus using an Ada program that exhibits
the bug (but which cannot be shared).
gdb/ChangeLog
2019-05-14 Tom Tromey <tromey@adacore.com>
* ada-lang.c (coerce_unspec_val_to_type): Only set address when
value is not lval_memory.
The "automatic symbol index cache" entry in the docs is missing entries in the
concept and command indices. Add them.
gdb/doc/ChangeLog:
2019-05-14 Tom de Vries <tdevries@suse.de>
* gdb.texinfo (Automatic symbol index cache): Add concept and command
index entries.
A base address selection entry in a location list consist of two (constant or
relocated) address offsets. The two offsets are the same size as an address
on the target machine.
The test-case gdb.dwarf2/dw2-skip-prologue.S encodes a base address selection
entry using .4byte, which is incorrect for 8-byte pointer size. [ Which
triggers an assert in dwz, see PR dwz/24172. ]
Fix this by using PTRBYTE instead.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-14 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/dw2-skip-prologue.S (.debug_loc): Fix base address
selection entry encoding.
Currently, the entry for the command "maint info selftests" in the Command,
Variable, and Function Index is listed at '"', rather than next to the other
"maint info" commands.
Fix this by removing the superfluous quoting in the @kindex entry.
gdb/doc/ChangeLog:
2019-05-14 Tom de Vries <tdevries@suse.de>
* gdb.texinfo (Maintenance Commands): Remove superfluous
quoting on command index entry for "maint info selftests".
Since commit
b4be1b0648 ("Fix MI output for multi-location breakpoints")
we get this error when building with --disable-gdbmi:
CXXLD gdb
/home/smarchi/src/binutils-gdb/gdb/breakpoint.c:6358: error: undefined reference to 'mi_multi_location_breakpoint_output_fixed(ui_out*)'
This is due to breakpoint.c using a function defined in mi/mi-main.c, even
though mi/mi-main.c isn't included in the build.
To fix it, use the flags feature of ui_out. mi_ui_out has the new
fix_multi_location_breakpoint_output flag set for versions >= 3. Also,
move the global variable fix_multi_location_breakpoint_output to
breakpoint.c, so it can be read there even when we build without MI. I
renamed it to fix_multi_location_breakpoint_output_globally so it
doesn't clash with the new enumerator.
gdb/ChangeLog:
* breakpoint.h (fix_multi_location_breakpoint_output_globally):
New variable declaration.
* breakpoint.c (fix_multi_location_breakpoint_output_globally):
New variable.
(print_one_breakpoint): Use ui_out::test_flags and new global
variable to compute use_fixed_output.
* mi/mi-main.h (mi_multi_location_breakpoint_output_fixed):
Remove.
* mi/mi-main.c (fix_multi_location_breakpoint_output): Remove.
(mi_multi_location_breakpoint_output_fixed): Remove.
(mi_cmd_fix_multi_location_breakpoint_output): Adjust to set the
new variable.
* mi/mi-out.c (mi_ui_out::mi_ui_out): Set
fix_multi_location_breakpoint_output flag if version >= 3.
* ui-out.h (enum ui_out_flag)
<fix_multi_location_breakpoint_output>: New enumerator.
When running the gdb.base/index-cache.exp test case with the
cc-with-dwz-m board, I noticed that the final executable didn't actually
contain a .gnu_debugaltlink section with the name of the external dwz
file:
$ readelf --debug-dump=links testsuite/outputs/gdb.base/index-cache/index-cache
* empty *
Running dwz by hand, I realized it's because dwz complains that the
output .debug_info section is empty and fails:
$ gcc ~/src/binutils-gdb/gdb/testsuite/gdb.base/index-cache.c -g3 -O0 -o a && cp a b
$ dwz -m foo a b
dwz: foo: .debug_info section not present
$ echo $?
1
This is because index-cache.c is trivial (just an empty main) and dwz
doesn't find anything to factor out to the dwz file. [1]
I think that cc-with-tweaks should fail in this scenario: if the user
asks for an external dwz file to be generated (the -m flag), then it
should be an error if cc-with-tweaks doesn't manage to produce an
executable with the proper link to this external dwz file. Otherwise,
the test runs with a regular non-dwzified executable, which gives a
false sense of security about whether the feature under test works with
dwzified executables.
So this patch adds checks for that after invoking dwz. It also removes
the 2>&1 to allow the error message to be printed like so:
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.base/index-cache.exp ...
gdb compile failed, dwz: /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/index-cache/index-cache.dwz: .debug_info section not present
- In the -m case (multi-file compression), we check if the expected output file
exists.
- In the -z case (single-file compression), we check if the file
contents has changed. This should catch cases where dwz doesn't modify the
file because it's not worth it.
It was chosen not to check for dwz's exit code, as it is not very
reliable up to dwz 0.12.
With this patch, fewer tests will pass than before with the
cc-with-dwz and cc-with-dwz-m boards, but those were false positives
anyway, as the test ran with regular executables.
[1] Note that dwz has been patched by Tom de Vries to work correctly in
this case, so we can use dwz master to run the test:
https://sourceware.org/git/?p=dwz.git;a=commit;h=08becc8b33453b6d013a65e7eeae57fc1881e801
gdb/ChangeLog:
* contrib/cc-with-tweaks.sh: Validate dwz's work.
I found out recently that some users didn't know that the Python
pretty-printers "children" method should compute its result lazily.
This has been a good idea since the earliest days, but wasn't
mentioned in the docs. This patch adds some text to this effect.
gdb/doc/ChangeLog
2019-05-10 Tom Tromey <tromey@adacore.com>
* python.texi (Pretty Printing API): Mention lazy computation for
"children".
This patch adds a completion function to the "catch exception"
and "catch handlers" commands.
Tested on x86-64 Fedora 29; reviewed off-list by Joel.
gdb/ChangeLog
2019-05-10 Tom Tromey <tromey@adacore.com>
* ada-lang.c (catch_ada_completer): New function.
(_initialize_ada_language): Use it.
gdb/testsuite/ChangeLog
2019-05-10 Tom Tromey <tromey@adacore.com>
* gdb.ada/info_exc.exp: Add "complete" test.
This patch makes a few minor improvements to the catchpoint
documentation:
* "catch exception" and "catch handlers" now mention the argument in
the @item.
* "catch exception unhandled" is moved to be closer to "catch
exception", rather than after "catch handlers".
* "catch load" and "catch unload" now wrap the argument in @var.
gdb/doc/ChangeLog
2019-05-10 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Set Catchpoints): Add text for parameter to "catch
exception" and "catch handlers". Move "catch exception unhandled"
text. Use @var for "catch load" and "catch unload"
I noticed a couple of spots where a "char *" was used where a
"const char *" made more sense. This patch fixes both of them.
Tested by rebuilding.
gdb/ChangeLog
2019-05-10 Tom Tromey <tromey@adacore.com>
* thread.c (print_thread_info): Make "requested_threads" const.
* gdbthread.h (print_thread_info): Make "requested_threads"
const.
* ada-tasks.c (print_ada_task_info): Make "taskno_str" const.
* ada-lang.h (print_ada_task_info): Make "taskno_str" const.
The test-case gdb.arch/amd64-tailcall-self.exp fails here:
...
if ![runto b] {
return -1
}
...
like:
...
(gdb) file build/gdb/testsuite/outputs/gdb.arch/amd64-tailcall-self/\
amd64-tailcall-self
Reading symbols from build/gdb/testsuite/outputs/gdb.arch/\
amd64-tailcall-self/amd64-tailcall-self...
Dwarf Error: Cannot find DIE at 0x1f5 referenced from DIE at 0x107 [in \
module build/gdb/testsuite/outputs/gdb.arch/amd64-tailcall-self/\
amd64-tailcall-self]
...
The problem is that in amd64-tailcall-self.S, CU-relative references are
assigned .debug_info section relative values. [ This is similar to the
problem fixed by "Fix gdb.arch/amd64-entry-value-paramref.S". ]
Fix this by assigning CU-relative references instead.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-09 Tom de Vries <tdevries@suse.de>
* gdb.arch/amd64-tailcall-self.S: Make DW_FORM_ref4 references
CU-relative.
The file gdb.arch/amd64-entry-value-paramref.S contains a DIE for function
bar:
...
DIE29: .uleb128 0x2 # (DIE (0x29) DW_TAG_subprogram)
.ascii "bar\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file (gdb.arch/amd64-entry-value-paramref.cc)
.byte 0x15 # DW_AT_decl_line
.long DIE45 # DW_AT_type
.byte 0x1 # DW_AT_inline
...
which refers to DIE45:
...
DIE45: .uleb128 0x4 # (DIE (0x45) DW_TAG_base_type)
.byte 0x4 # DW_AT_byte_size
.byte 0x5 # DW_AT_encoding
.ascii "int\0" # DW_AT_name
...
using a form DW_FORM_ref4:
...
.uleb128 0x2 # (abbrev code)
.uleb128 0x2e # (TAG: DW_TAG_subprogram)
.byte 0x1 # DW_children_yes
...
.uleb128 0x49 # (DW_AT_type)
.uleb128 0x13 # (DW_FORM_ref4)
...
However, the DW_FORM_ref4 is a CU-relative reference, while using a label for
the value will result in a section-relative value.
So, if linked in object files contain dwarf info and are placed in the
.debug_info section before the compilation units generated from
amd64-entry-value-paramref.S, then the referenced type is at 0x108:
...
<1><108>: Abbrev Number: 4 (DW_TAG_base_type)
<109> DW_AT_byte_size : 4
<10a> DW_AT_encoding : 5 (signed)
<10b> DW_AT_name : int
...
but the reference will point to a non-existing DIE at 0x1cf:
...
<1><f0>: Abbrev Number: 2 (DW_TAG_subprogram)
<f1> DW_AT_name : bar
<f5> DW_AT_decl_file : 1
<f6> DW_AT_decl_line : 21
<f7> DW_AT_type : <0x1cf>
<fb> DW_AT_inline : 1 (inlined)
...
which happens to cause a GDB internal error described in PR23270 - "GDB
internal error: dwarf2read.c:18656: internal-error: could not find partial
DIE 0x1b7 in cache".
Fix the invalid DWARF by making the reference value CU-relative:
...
- .long DIE45 # DW_AT_type
+ .long DIE45 - .Ldebug_info0 # DW_AT_type
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-09 Tom de Vries <tdevries@suse.de>
* gdb.arch/amd64-entry-value-paramref.S: Make DW_FORM_ref4 references
CU-relative.
This changes gdbtypes.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* gdbtypes.c (objfile_type_data): Change type.
(objfile_type, _initialize_gdbtypes): Update.
This changes dwarf2-frame.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* dwarf2-frame.c (dwarf2_frame_objfile_data): Change type.
(dwarf2_frame_find_fde, dwarf2_build_frame_info)
(_initialize_dwarf2_frame): Update.
This changes objc-lang.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* objc-lang.c (objc_objfile_data): Change type.
(find_methods): Update.
(_initialize_objc_lang): Remove.
This changes stabsread.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* stabsread.c (rs6000_builtin_type_data): Change type.
(rs6000_builtin_type, _initialize_stabsread): Update.
mips_pdr_data is unused, so this patch removes it.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* mips-tdep.c (mips_pdr_data): Remove.
(_initialize_mips_tdep): Update.
This changes hppa-tdep.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* hppa-tdep.c (hppa_objfile_priv_data): Change type.
(hppa_init_objfile_priv_data, read_unwind_info)
(find_unwind_entry, _initialize_hppa_tdep): Update.
This changes elfread.c to use the type-safe registry API. This also
fixes a potential memory leak, by changing the hash table so that it
is no longer allocated on an obstack.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* elfread.c (elf_objfile_gnu_ifunc_cache_data): Change type.
(elf_gnu_ifunc_record_cache): Update. Don't allocate hash table
on obstack.
(elf_gnu_ifunc_resolve_by_cache, _initialize_elfread): Update.
This changes mdebugread.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* mdebugread.c (basic_type_data): Change type.
(basic_type, _initialize_mdebugread): Update.
This adds a no-op deleter, which is used in subsequent patches.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* common/gdb_unique_ptr.h (struct noop_deleter): New.
This changes the probes code in elfread.c to use the type-safe
registry API. While doing this, I saw that the caller of get_probes
owns the probes, so I went through the code and changed the vectors to
store unique_ptrs, making the ownership relationship more clear.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* symfile.h (struct sym_probe_fns) <sym_get_probes>: Change type.
* symfile-debug.c (debug_sym_get_probes): Change type.
* stap-probe.c (handle_stap_probe):
(stap_static_probe_ops::get_probes): Change type.
* probe.h (class static_probe_ops) <get_probes>: Change type.
* probe.c (class any_static_probe_ops) <get_probes>: Change type.
(parse_probes_in_pspace): Update.
(find_probes_in_objfile, find_probe_by_pc, collect_probes):
Update.
(any_static_probe_ops::get_probes): Change type.
* elfread.c (elfread_data): New typedef.
(probe_key): Change type.
(elf_get_probes): Likewise. Update.
(probe_key_free): Remove.
(_initialize_elfread): Update.
* dtrace-probe.c (class dtrace_static_probe_ops) <get_probes>:
Change type.
(dtrace_process_dof_probe, dtrace_process_dof)
(dtrace_static_probe_ops::get_probe): Change type.
This changes xcoffread.c to use the type-safe registry API. It also
renames coff_symfile_info to xcoff_symfile_info, to avoid any possible
ODR violation.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* xcoffread.c (struct xcoff_symfile_info): Rename from
coff_symfile_info. Add initializers.
(xcoff_objfile_data_key): Move lower. Change type.
(XCOFF_DATA): Rewrite.
(xcoff_free_info): Remove.
(xcoff_symfile_init, _initialize_xcoffread, read_xcoff_symtab)
(read_symbol, read_symbol_lineno, find_linenos, init_stringtab)
(xcoff_initial_scan): Update.
This changes solib-svr4y.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* solib-svr4.c (struct svr4_info): Add initializers and
destructor.
<probes_table>: Now an htab_up.
(solib_svr4_pspace_data): Change type.
(free_probes_table): Simplify.
(~svr4_info): Rename from svr4_pspace_data_cleanup.
(get_svr4_info, probes_table_htab_remove_objfile_probes)
(probes_table_remove_objfile_probes, register_solib_event_probe)
(solib_event_probe_at, svr4_update_solib_event_breakpoint)
(_initialize_svr4_solib): Update.
This changes remote.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* remote.c (remote_pspace_data): Change type.
(remote_pspace_data_cleanup): Remove.
(get_remote_exec_file, set_pspace_remote_exec_file)
(_initialize_remote): Update.
This changes breakpoint.c to use the type-safe registry API.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* breakpoint.c (breakpoint_objfile_key): Change type.
(get_breakpoint_objfile_data): Update.
(free_breakpoint_objfile_data): Remove.
(_initialize_breakpoint): Update.
This changes dwarf2_per_objfile to use the type-safe registry API.
This also changes dwarf2_per_objfile not to be allocated on an
obstack. It seemed clearer to me to simply allocate it on the heap;
and I didn't see a drawback from doing so.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* dwarf2read.h (struct dwarf2_per_objfile): Don't inherit from
allocate_on_obstack.
* dwarf2read.c (dwarf2_objfile_data_key): Change type.
(get_dwarf2_per_objfile): Update.
(set_dwarf2_per_objfile): Remove.
(dwarf2_has_info, dwarf2_get_section_info): Update.
(dwarf2_free_objfile): Remove.
(_initialize_dwarf2_read): Update.
This changes auto-load.c to use the type-safe registry API. It also
changes a couple of types to "bool", removing uses of "FALSE".
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* auto-load.c (struct auto_load_pspace_info): Add destructor and
initializers.
<unsupported_script_warning_printed,
script_not_found_warning_printed>: Now bool.
(auto_load_pspace_data): Change type.
(~auto_load_pspace_info): Rename from
auto_load_pspace_data_cleanup.
(get_auto_load_pspace_data, init_loaded_scripts_info)
(clear_section_scripts, maybe_print_unsupported_script_warning)
(maybe_print_script_not_found_warning, _initialize_auto_load):
Update.
This changes inflow.c to use the type-safe registry API. This fixes a
latent bug in swap_terminal_info, which previously said:
terminal_info *info_a
= (terminal_info *) inferior_data (a, inflow_inferior_data);
terminal_info *info_b
= (terminal_info *) inferior_data (a, inflow_inferior_data);
... both of which examine 'a'.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* inflow.c (struct terminal_info): Add destructor and
initializers.
(inflow_inferior_data): Change type.
(~terminal_info): Rename from inflow_inferior_data_cleanup.
(get_inflow_inferior_data, inflow_inferior_exit)
(swap_terminal_info, _initialize_inflow): Update.
This changes DECLARE_REGISTRY to add a type-safe interface. This
interface is a C++ class that handles the details of registering a
key, and provides various useful methods, including policy-based
cleanup.
gdb/ChangeLog
2019-05-08 Tom Tromey <tom@tromey.com>
* registry.h (DECLARE_REGISTRY): Define the _key class.
Commit 2e62ab400f added a second 'New commands' section to the NEWS
file, this commit merges the two together.
gdb/ChangeLog:
* NEWS: Merge two 'New commands' sections.
- set print frame-arguements all
- an Ada function named pck.call_me calls a C function named break_me
- you put a breakpoint in break_me and the program reaches this
breakpoint.
Now display the backtrace:
(gdb) bt
#0 break_me () at [...]
#1 0x000000000040243e in pck.call_me (
s={P_ARRAY = 0x7fffffffe21c, P_BOUNDS = 0x41e6e8}) at [...]
whereas we should expect:
(gdb) bt
#0 break_me () at [...]
#1 0x000000000040243e in pck.call_me (s="test") at [...]
The problem is that GDB prints the S parameter in the pck.call_me Ada
function using the current language, so the C one, because the program
is stopped in a C function, whereas it should use the pck.call_me frame
one. This behavior is ok when user manually changes the language but it's
not the right one when language is auto.
This patch fixes this problem so now when using auto language, all Ada
frame arguments are printed using Ada like syntax when the frame is part
of Ada code, even if the program is stopped in a frame using a different
language.
If the user explicitly sets a language (using "set language ...") then
no change here, all the Ada frame arguments are printed using this
language.
gdb/ChangeLog:
* ada-valprint.c (ada_val_print_gnat_array): Remove language
parameter and use Ada language definition instead.
(ada_val_print_ptr): Remove unused language parameter.
(ada_val_print_num): Remove language parameter and use Ada language
definition instead.
(ada_val_print_enum, ada_val_print_flt): Remove unused language
parameter.
(ada_val_print_struct_union, ada_val_print_ref): Remove language
parameter and use Ada language definition instead.
(ada_val_print_1): Update all ada_val_print_xxx calls.
Remove language parameter.
(ada_val_print): Update ada_val_print_1 call.
gdb/testsuite/ChangeLog:
* gdb.ada/frame_arg_lang.exp: New testcase.
* gdb.ada/frame_arg_lang/bla.adb: New file.
* gdb.ada/frame_arg_lang/pck.ads: New file.
* gdb.ada/frame_arg_lang/pck.adb: New file.
* gdb.ada/frame_arg_lang/foo.c: New file.
Tested on x86_64-linux, no regressions.
I noticed a three globals in remote.c that could be static. This
patch makes this change.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* remote.c (remote_hw_watchpoint_limit)
(remote_hw_watchpoint_length_limit, remote_hw_breakpoint_limit):
Now static.
The "watchdog" global is only used in remote.c, so this patch moves it
there and makes it static.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* maint.c (_initialize_maint_cmds): Move initialization code to
remote.c.
(watchdog, show_watchdog): Move to remote.c.
* remote.c (watchdog, show_watchdog): Move from maint.c. Make
"watchdog" static.
(_initialize_remote): Move initialization code from maint.c.
* defs.h (watchdog): Don't declare.
This moves the interpreter_p declaration from defs.h to main.h. I
think this makes more sense, as it is defined in main.c. Also, this
declaration was in the wrong place -- between a comment and the things
the comment described.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* tui/tui-interp.c: Include main.h.
* interps.c: Include main.h.
* main.h (interpreter_p): Declare.
* defs.h (interpreter_p): Don't declare.
I noticed that read_unsigned_leb128 is declared in defs.h. There's no
reason this should be here, so this patch moves it to dwarf2read.h.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* dwarf2loc.c: Include dwarf2read.h.
* defs.h (read_unsigned_leb128): Don't declare.
* dwarf2read.h (read_unsigned_leb128): Declare.
When merging commit 99f20f ("Fix style bug when paging") to master, I
had to make some changes to get it to compile again. Unfortunately, I
must not have added these to the index at the correct time, because
they were not committed.
This patch fixes the problem.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* utils.c (fputs_maybe_filtered): Call can_emit_style_escape as a
method.
Philippe pointed out a styling bug that would occur in some conditions
when paging:
https://sourceware.org/ml/gdb-patches/2019-04/msg00101.html
I was finally able to reproduce this, and this patch fixes the bug.
The problem occurred when text overflowed the line, causing a
pagination prompt, but when no wrap column had been set. In this
case, the current style was reset to show the prompt, but then not
reset back to the previously applied style before emitting the rest of
the line.
The fix is to record the applied style in this case, and re-apply it
afterward -- but only if the pager prompt was emitted, something that
the existing style.exp pointed out on the first, more naive, version
of the patch.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* utils.c (fputs_maybe_filtered): Reset style after paging, even
when no wrap column is set.
A user here noticed that the Python Value.string method did not work
for Ada arrays. I tracked this down to an oddity in value_as_address
-- namely, it calls coerce_array, but that function will not force
array coercion when the language has c_style_arrays=false, as Ada
does.
This patch fixes the problem by changing c_get_string so that arrays
take the "in GDB's memory" branch. The actual patch is somewhat more
complicated than you might think, because the caller can request more
array elements than the type allows. This is normal when the type is
using the C struct hack.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* c-lang.c (c_get_string): Handle non-C-style arrays.
gdb/testsuite/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* gdb.python/py-value.exp (test_value_in_inferior): Add Ada test.
Consider this short C example:
struct inner
{
unsigned x;
unsigned y : 3;
unsigned z : 3;
};
struct outer
{
unsigned char o : 3;
struct inner i __attribute__ ((packed));
};
When I use "ptype/o" on this, I get:
(gdb) ptype/o struct outer
/* offset | size */ type = struct outer {
/* 0: 5 | 1 */ unsigned char o : 3;
/* XXX 5-bit hole */
/* 1 | 8 */ struct inner {
/* 1 | 4 */ unsigned int x;
/* 5:29 | 4 */ unsigned int y : 3;
/* 5:26 | 4 */ unsigned int z : 3;
/* XXX 2-bit padding */
/* XXX 3-byte padding */
/* total size (bytes): 8 */
} i;
/* total size (bytes): 9 */
}
In the location of "o" ("0: 5"), the "5" means "there are 5 bits left
relative to the size of the underlying type.
I find this very difficult to follow. On irc, Sergio said that this
choice came because it is what pahole does. However, I think it's not
very useful, and maybe is just an artifact of the way that
DW_AT_bit_offset was defined in DWARF 3.
This patch changes ptype/o to print the offset of a bitfield in a more
natural way, that is, using the bit number according to the platform's
bit numbering.
With this patch, the output is now:
(gdb) ptype/o struct outer
/* offset | size */ type = struct outer {
/* 0: 0 | 1 */ unsigned char o : 3;
/* XXX 5-bit hole */
/* 1 | 8 */ struct inner {
/* 1 | 4 */ unsigned int x;
/* 5: 0 | 4 */ unsigned int y : 3;
/* 5: 3 | 4 */ unsigned int z : 3;
/* XXX 2-bit padding */
/* XXX 3-byte padding */
/* total size (bytes): 8 */
} i;
/* total size (bytes): 9 */
}
This is better, IMO, because now the "offset" of a bitfield is
consistent with the offset of an ordinary member, referring to its
offset from the start of the structure.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* typeprint.c (print_offset_data::update): Print the bit offset,
not the number of bits remaining.
gdb/doc/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Symbols): Document change to ptype/o.
gdb/testsuite/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* gdb.base/ptype-offsets.exp: Update tests.
I noticed that ptype/o will print:
/* 3: 3 | 1 */ signed char a4 : 2;
/* XXX 3-bit hole */
That is, "*/" at the end of the "hole" message does not line up with
the other comment ends. I thought it would be a bit nicer if this did
line up, so I fixed it. Then, to my surprise, I found that I could
not make ptype-offsets.exp fail.
I still am not sure why it doesn't fail, but changing the tests to use
string_to_regexp and changing the quoting helped. This in turn showed
that some of the existing test cases were wrong, so I've also updated
them here.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* typeprint.c (print_offset_data::maybe_print_hole): Add extra
padding at end of comment.
gdb/testsuite/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* gdb.base/ptype-offsets.exp: Use string_to_regexp. Fix test
cases.
* gdb.base/ptype-offsets.cc (struct abc) <my_int_type>: Now
"short".
While looking at a different Ada problem, I found that printing a
record containing a VLA did not work properly.
I tracked the problem down to dwarf2_evaluate_property trying, and
failing, to compare two types that differed only in qualifiers.
This patch changes dwarf2_evaluate_property to ignore qualifiers when
comparing types.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* dwarf2loc.c (dwarf2_evaluate_property) <PROP_ADDR_OFFSET>:
Compare main types.
gdb/testsuite/ChangeLog
2019-05-08 Tom Tromey <tromey@adacore.com>
* gdb.ada/vla.exp: New file.
* gdb.ada/vla/vla.adb: New file.
When adding a debug print here in index-cache.exp:
...
proc_with_prefix test_cache_disabled { cache_dir } {
lassign [ls_host $cache_dir] ret files_before
+ puts "before: '$files_before'"
+ exit
...
we have:
...
files_before: ''
...
When further adding:
...
proc_with_prefix test_cache_disabled { cache_dir } {
+ exec touch $cache_dir/foo.1 $cache_dir/foo.2 $cache_dir/foo.3
...
we have:
...
files_before: 'foo.1'
...
while we're expecting file_before to contain foo.[123].
Fix this by making the return statement in ls_host return a list rather than a
string (in accordance with the ls_host documentation), after which we have:
...
files_before: 'foo.1 foo.2 foo.3'
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-07 Tom de Vries <tdevries@suse.de>
* gdb.base/index-cache.exp (ls_host): Fix return statement.
When running gdb.dlang/watch-loc.exp with target board cc-with-debug-names, we
run into:
...
FAIL: gdb.dlang/watch-loc.exp: disassemble _Dmain (GDB internal error)
...
in more detail:
...
(gdb) disassemble _Dmain
gdb/dwarf2read.c:5293: internal-error: \
compunit_symtab* dw2_find_pc_sect_compunit_symtab(objfile*, \
bound_minimal_symbol, CORE_ADDR, obj_section*, int): \
Assertion `result != NULL' failed.
...
The problem is that the .debug_aranges section in watch-loc.c contains a
debug_info_offset which is set to 0:
...
asm (
" .pushsection .debug_aranges,\"\",%progbits\n"
" .4byte .Laranges_end - .Laranges_start\n"
".Laranges_start:\n"
" .2byte 0x2\n"
" .4byte 0\n"
...
while the compilation unit at offset 0 in the .debug_section in the executable
is in fact not the compilation unit generated from watch-loc-dw.S.
[ Note: this is a non-trivial test-case. The file watch-loc-dw.S contains a
.debug_info section, but not an .debug_aranges section or any actual code.
The file watch-loc.c contains code and a .debug_aranges section, but no other
debug section. So, the intent for the .debug_aranges section in watch-loc.c
is to refer to a compilation unit in the .debug_info section in
watch-loc-dw.S. ]
This happens when linked in object files contain dwarf info and are placed in
the .debug_info section before the compilation units generated from
watch-loc.c and watch-loc-dw.S.
Fix this by defining the debug_info_offset field using a label .Lcu1_begin
that defines the start of an empty .debug_section compilation unit:
...
asm (
+ " .pushsection .debug_info,\"\",%progbits\n"
+ ".Lcu1_begin:"
+ " .popsection\n"
" .pushsection .debug_aranges,\"\",%progbits\n"
" .4byte .Laranges_end - .Laranges_start \n"
".Laranges_start:\n"
" .2byte 0x2\n"
- " .4byte 0\n"
+ " .4byte .Lcu1_begin\n"
...
which during linking merges with the start of the .debug_info section of
watch-loc-dw.S.
Tested on x86_64-linux with native, cc-with-gdb-index and cc-with-debug-names.
gdb/testsuite/ChangeLog:
2019-05-07 Tom de Vries <tdevries@suse.de>
PR testsuite/24522
* gdb.dlang/watch-loc.c: Fix debug_info_offset in .debug_aranges
section.
When running gdb.dwarf2/dw2-case-insensitive.exp with target board
cc-with-debug-names, we run into:
...
FAIL: gdb.dwarf2/dw2-case-insensitive.exp: regexp case-sensitive off \
(GDB internal error)
...
in more detail:
...
(gdb) info functions fUnC_lang
gdb/dwarf2read.c:5293: internal-error: \
compunit_symtab* dw2_find_pc_sect_compunit_symtab(objfile*, \
bound_minimal_symbol, CORE_ADDR, obj_section*, int): \
Assertion `result != NULL' failed.
...
The problem is that the .debug_aranges section in dw2-case-insensitive-debug.S
contains a debug_info_offset which is set to 0:
...
.section .debug_aranges,"",@progbits
.4byte .Laranges_end - .Laranges_start
.Laranges_start:
.2byte 0x2
.4byte 0
...
while the compilation unit at offset 0 in the .debug_section of the executable
is in fact not the compilation unit generated from
dw2-case-insensitive-debug.S.
This happens when linked in object files contain dwarf info and are placed in
the .debug_info section before the compilation unit generated from
dw2-case-insensitive-debug.S.
Fix this by defining the debug_info_offset field using the label .Lcu1_begin
that defines the start of the compilation unit:
...
- .4byte 0
+ .4byte .Lcu1_begin
...
Tested on x86_64-linux with native, cc-with-gdb-index and cc-with-debug-names.
gdb/testsuite/ChangeLog:
2019-05-07 Tom de Vries <tdevries@suse.de>
PR testsuite/24522
* gdb.dwarf2/dw2-case-insensitive-debug.S: Fix debug_info_offset in
.debug_aranges section.
When running gdb.dwarf2/multidictionary.exp with target board cc-with-dwz and
current dwz, we run into a dwz abort:
...
gdb compile failed, gdb/contrib/cc-with-tweaks.sh: line 188: 11484 Aborted \
(core dumped) $DWZ "$output_file" > /dev/null 2>&1
UNTESTED: gdb.dwarf2/multidictionary.exp: multidictionary.exp
...
The dwz abort (PR dwz/24169) is caused by an invalid DW_FORM_ref_addr in the
multidictionary binary.
The multidictionary binary is build from multidictionary.S which is generated
using the dwarf assembler, and multidictionary.S contains dwarf for 3
compilation units.
In multidictionary0.o (generated from multidictionary.S), we find a concrete
formal parameter DIE:
...
<2><dc>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<dd> DW_AT_abstract_origin: <0xa6>
...
referring to an abstract formal parameter DIE at 0xa6:
...
<2><a6>: Abbrev Number: 8 (DW_TAG_formal_parameter)
<a7> DW_AT_name : msg
<ab> DW_AT_type : <0x92>
...
but in the multidictionary binary the concrete formal parameter DIE is still
referring to 0xa6:
...
<2><1a3>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<1a4> DW_AT_abstract_origin: <0xa6>
...
while the abstract formal parameter DIE has moved to 0x16d:
...
<2><16d>: Abbrev Number: 8 (DW_TAG_formal_parameter)
<16e> DW_AT_name : msg
<172> DW_AT_type : <0x159>
...
The concrete formal parameter DIE is specified in multidictionary.S like this:
...
.Llabel21:
.uleb128 4
.4byte .Llabel17 - .Lcu1_begin
...
The problem is that the .Lcu1_begin label is assumed to mark the start of the
.debug_info section in the executable, but in fact it marks the start of the
first compilation unit from multidictionary.S in the executable. Usually
these two entities are the same, but they are not when linked in object files
contain dwarf info and are placed in the .debug_info section before the
compilation units generated from multidictionary.S.
Fix this in the dwarf assembler by generating instead the label itself:
...
.Llabel21:
.uleb128 4
.4byte .Llabel17
...
resulting in a relocation in the object file:
...
Offset Info Type Sym. Value Sym. Name + Addend
0000000000dd 00040000000a R_X86_64_32 0000000000000000 .debug_info + a6
...
and resulting in the correct offset in the executable:
...
<2><1a3>: Abbrev Number: 4 (DW_TAG_formal_parameter)
<1a4> DW_AT_abstract_origin: <0x16d>
...
Tested on x86_64-linux with native and cc-with-dwz.
gdb/testsuite/ChangeLog:
2019-05-07 Tom de Vries <tdevries@suse.de>
PR testsuite/24159
* lib/dwarf.exp: Fix handling of DW_FORM_ref_addr.
I noticed that scoped_mmap.h included config.h, and that scoped_mmap.c
included defs.h. This patch fixes both of these problems.
Tested by the buildbot.
gdb/ChangeLog
2019-05-06 Tom Tromey <tom@tromey.com>
* common/scoped_mmap.c: Include common-defs.h.
* common/scoped_mmap.h: Don't include config.h.
This line of code...
*(int64_t *) ptr = *(int32_t *) ptr;
...in linux-x86-low.c is not needed (and does not work correctly)
within a 32-bit executable. I added an __x86_64__ ifdef (which is
used extensively elsewhere in the file for like purposes) to prevent
this code from being included in 32-bit builds.
It fixes the following regressions when running on native
i686-pc-linux-gnu:
FAIL: gdb.server/abspath.exp: continue to main
FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=auto: continue to main
FAIL: gdb.server/connect-without-multi-process.exp: multiprocess=off: continue to main
FAIL: gdb.server/ext-restart.exp: restart: run to main
FAIL: gdb.server/ext-restart.exp: run to main
FAIL: gdb.server/ext-run.exp: continue to main
FAIL: gdb.server/ext-wrapper.exp: print d
FAIL: gdb.server/ext-wrapper.exp: restart: print d
FAIL: gdb.server/ext-wrapper.exp: restart: run to marker
FAIL: gdb.server/ext-wrapper.exp: run to marker
FAIL: gdb.server/no-thread-db.exp: continue to breakpoint: after tls assignment
FAIL: gdb.server/reconnect-ctrl-c.exp: first: stop with control-c
FAIL: gdb.server/reconnect-ctrl-c.exp: second: stop with control-c
FAIL: gdb.server/run-without-local-binary.exp: run test program until the end
FAIL: gdb.server/server-kill.exp: continue to breakpoint: after server_pid assignment
FAIL: gdb.server/server-kill.exp: tstatus
FAIL: gdb.server/server-run.exp: continue to main
gdb/gdbserver/ChangeLog:
* linux-x86-low.c (x86_fill_gregset): Don't compile 64-bit
sign extension code on 32-bit builds.
In gdb.base/index-cache.exp, handle the case that binfile contains either a
.gdb_index or .debug_names index section.
Tested on x86_64-linux with native, cc-with-gdb-index and cc-with-debug-names.
gdb/testsuite/ChangeLog:
2019-05-06 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (exec_has_index_section): New proc.
* gdb.base/index-cache.exp: Handle case that binfile contains an index
section.
This removes a VEC from aarch64-tdep.c, replacing it with a
std::vector.
gdb/ChangeLog
2019-05-04 Tom Tromey <tom@tromey.com>
* aarch64-tdep.c (stack_item_t): Remove typedef and DEF_VEC.
(struct aarch64_call_info): Add initializers.
<si>: Now a std::vector.
(pass_on_stack, aarch64_push_dummy_call): Update.
This replaces a VEC in ppc-linux-nat.c with a std::vector.
gdb/ChangeLog
2019-05-04 Simon Marchi <simon.marchi@efficios.com>
Tom Tromey <tom@tromey.com>
* ppc-linux-nat.c (thread_points_p): Remove typedef and DEF_VEC.
(ppc_threads): Now a std::vector. Now static.
(hwdebug_find_thread_points_by_tid)
(ppc_linux_nat_target::low_new_thread, ppc_linux_thread_exit):
Update.
This changes arm-linux-nat.c to use gdb_assert_not_reached rather than
an assert of false.
gdb/ChangeLog
2019-05-04 Tom Tromey <tom@tromey.com>
* arm-linux-nat.c (arm_linux_nat_target::can_use_hw_breakpoint):
Use gdb_assert_not_reached.
This changes compile_cplus_convert_enum to use "false".
Note that this variable is never modified, which seems like an error.
I filed PR compile/24473 for this.
gdb/ChangeLog
2019-05-04 Tom Tromey <tom@tromey.com>
* compile/compile-cplus-types.c (compile_cplus_convert_enum): Use
"false".
This changes select_frame_for_mi to use "false" rather than "FALSE".
gdb/ChangeLog
2019-05-04 Tom Tromey <tom@tromey.com>
* stack.c (select_frame_for_mi): Use "false", not "FALSE".
The 'is' operator is not meant to be used for comparisons. It currently working
is an implementation detail of CPython. CPython 3.8 has added a SyntaxWarning
for this.
This patch partly reverts commit 8a6d42345 ("Change representation of
psymbol to flush out accessors"); specifically, it changes
partial_symbol to no longer derive from general_symbol_info.
The basic problem here is that the bcache compares objects bitwise,
and this change made it less likely that the relevant fields in the
psymbol would be fully initialized. This could be seen by running a
test under valgrind on the Fedora-i686 buildbot.
I considered a simpler patch, namely just zeroing the psymbol's
"value" field in add_psymbol_to_bcache. However, it wasn't clear to
me that this memset could not then be optimized away by the compiler.
Regression tested by the buildbot. I think this should go in 8.3 as
well.
gdb/ChangeLog
2019-05-04 Tom Tromey <tom@tromey.com>
* psymtab.c (psymbol_name_matches, match_partial_symbol)
(lookup_partial_symbol, print_partial_symbols)
(recursively_search_psymtabs, sort_pst_symbols, psymbol_hash)
(psymbol_compare): Update.
(add_psymbol_to_bcache): Clear the entire psymbol.
(maintenance_check_psymtabs): Update.
* psympriv.h (struct partial_symbol): Don't derive from
general_symbol_info.
<obj_section, unrelocated_address, address,
set_unrelocated_address>: Update.
<ginfo>: New member.
* dwarf-index-write.c (write_psymbols, debug_names::insert)
(debug_names::write_psymbols): Update.
Add a target board that makes it easy to run the test suite with a
.debug_names section added to executables.
gdb/ChangeLog:
2019-05-04 Tom de Vries <tdevries@suse.de>
* contrib/cc-with-tweaks.sh: Support -n arg.
gdb/testsuite/ChangeLog:
2019-05-04 Tom de Vries <tdevries@suse.de>
* boards/cc-with-debug-names.exp: New file.
Valgrind reports leaks such as the below in the tests:
gdb.threads/corethreads.exp
gdb.threads/gcore-thread.exp
gdb.ada/task_switch_in_core.exp
gdb.trace/tfile.exp
gdb.base/siginfo-thread.exp
==12701== 1,123 (72 direct, 1,051 indirect) bytes in 1 blocks are definitely lost in loss record 2,928 of 3,247
==12701== at 0x4C2C4CC: operator new(unsigned long) (vg_replace_malloc.c:344)
==12701== by 0x5CF771: get_thread_arch_aspace_regcache(ptid_t, gdbarch*, address_space*) (regcache.c:330)
==12701== by 0x5CF92A: get_thread_regcache (regcache.c:366)
==12701== by 0x5CF92A: get_current_regcache() (regcache.c:372)
==12701== by 0x4C7964: get_current_frame() (frame.c:1587)
==12701== by 0x4C7A3C: get_selected_frame(char const*) (frame.c:1651)
==12701== by 0x669EAD: print_thread_info_1(ui_out*, char const*, int, int, int) (thread.c:1151)
==12701== by 0x66A9A1: info_threads_command(char const*, int) (thread.c:1217)
==12701== by 0x40A878: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:1892)
...
Fix these leaks by clearing registers and frame caches.
This leak and fix is similar to the leak fixed by 799efbe8e0
Some versions of gcc have a bug that causes
for (struct mumble : something)
... to give a compiler error. We routinely work around this bug in
gdb, but apparently had not done so in a while. This patch fixes the
remaining known cases of this problem.
gdb/ChangeLog
2019-05-03 Sandra Loosemore <sandra@codesourcery.com>
Tom Tromey <tom@tromey.com>
* dictionary.c (collate_pending_symbols_by_language): Remove
"struct" from foreach.
* symtab.c (lookup_global_symbol_from_objfile)
(lookup_symbol_in_objfile_from_linkage_name): Remove "struct" from
foreach.
* ser-tcp.c (net_open): Remove "struct" from foreach.
* objfiles.c (objfile_relocate, objfile_rebase)
(objfile_has_symbols): Remove "struct" from foreach.
* minsyms.c (lookup_minimal_symbol_by_pc_section): Remove "struct"
from foreach.
* dwarf2read.c (handle_struct_member_die): Remove "struct" from
foreach.
* darwin-nat.c (thread_info_from_private_thread_info): Remove
"struct" from foreach.
* ada-lang.c (create_excep_cond_exprs)
(ada_exception_catchpoint_cond_string): Remove "struct" from
foreach.
An internal bug report points out that, when a global character enum
type is used, casting fails, like:
(gdb) print global_char_enum'('F')
$1 = 70
The bug here turns out to be that enumerators are qualified, so for
example the mangled name might be "pck__QU48", rather than "QU48".
This patch fixes the problem by only examining the suffix of the
enumerator. This is ok because the type is already known, and because
the mangling scheme ensures that there won't be clashes.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-05-03 Tom Tromey <tromey@adacore.com>
* ada-exp.y (convert_char_literal): Check suffix of each
enumerator.
gdb/testsuite/ChangeLog
2019-05-03 Tom Tromey <tromey@adacore.com>
* gdb.ada/char_enum/pck.ads (Global_Enum_Type): New type.
* gdb.ada/char_enum/foo.adb: Use Global_Enum_Type.
* gdb.ada/char_enum.exp: Add test.
This patch comes from PR ada/21406. It adds the noyywrap option to
ada-lex.l. This was already done (by the same author) for other .l
files in the binutils-gdb tree, so it seems reasonably safe.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-05-03 Dilyan Palauzov <dilyan.palauzov@aegee.org>
PR ada/21406:
* ada-exp.y (yywrap): Don't define.
* ada-lex.l (%option): Add noyywrap
(yywrap): Remove.
Add a target board cc-with-gdb-index.exp, to make it easy to run cc-with-tweaks
with CC_WITH_TWEAKS_FLAGS='-i'.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-05-03 Tom de Vries <tdevries@suse.de>
* boards/cc-with-gdb-index.exp: New file.
This changeset defines _WIN32_WINNT to at least 0x0501, the level
of Windows XP, unless defined to a higher level, in a single
place. It then removes all the overrides of _WIN32_WINNT in
individual files as no longer needed. Doing this also solves
compilation of windows-nat.c with mingw.org's MinGW, as that
file uses CONSOLE_FONT_INFO which needs the XP level to become
exposed in the Windows headers, while mingw.org defaults to
Windows 9X.
gdb/ChangeLog:
2019-05-03 Eli Zaretskii <eliz@gnu.org>
* common/common-defs.h [__MINGW32__ || __CYGWIN__]: Define
_WIN32_WINNT to the XP level, unless already defined to a higher
level.
* unittests/parse-connection-spec-selftests.c:
* ser-tcp.c:
* common/netstuff.c [USE_WIN32API]: Remove the _WIN32_WINNT
override.
gdb/gdbserver/ChangeLog:
2019-05-03 Eli Zaretskii <eliz@gnu.org>
* remote-utils.c:
* gdbreplay.c [USE_WIN32API]: Remove the _WIN32_WINNT override.
If you put the separate debug file in a global debug directory, GDB on
MS-Windows would fail to find it. This happens because we obtain the
directory to look up the debug file by concatenating the debug
directory name with the leading directories of the executable, and the
latter includes the drive letter on MS-Windows. So we get an invalid
file name like
d:/usr/lib/debug/d:/usr/bin/foo.debug
This commit fixes that by removing the colon of the drive letter,
thus producing
d:/usr/lib/debug/d/usr/bin/foo.debug
gdb/ChangeLog:
2019-05-03 Eli Zaretskii <eliz@gnu.org>
* symfile.c (find_separate_debug_file): Remove colon from the
drive spec of DOS/Windows file names of the target, so that the
file name produced from DEBUGDIR and the target's directory will
be valid on DOS/Windows systems.
gdb/doc/ChangeLog:
2019-05-03 Eli Zaretskii <eliz@gnu.org>
* gdb.texinfo (Separate Debug Files): Document how the
subdirectory of the global debug directory is computed on
MS-Windows/MS-DOS.
When printing a rust structure that contains a string GDB can
currently fail to read the fields that define the string. This is
because GDB mistakenly treats a value that is the parent structure as
though it is the structure that defines the string, and then fails to
find the fields needed to extract a string.
The solution is to create a new value to represent the string field of
the parent value.
gdb/ChangeLog:
* rust-lang.c (val_print_struct): Handle printing structures
containing strings.
gdb/testsuite/ChangeLog:
* gdb.rust/simple.exp: Add new test case.
* gdb.rust/simple.rs (struct StringAtOffset): New struct.
(main): Initialise an instance of the new struct.
I noticed that _initialize_valarith is empty. This patch removes it.
Because init.c is constructed at build time, there's no reason to keep
empty initialization functions around, because there's no overhead to
reintroducing them when needed.
gdb/ChangeLog
2019-05-02 Tom Tromey <tromey@adacore.com>
* valarith.c (_initialize_valarith): Remove.
A user at AdaCore found a case where assignment to a nested packed
structure would fail. The bug is that ada_value_primitive_field
doesn't account for the situation where a field is not packed relative
to its containing structure, but where the structure itself is packed
in its parent.
gdb/ChangeLog
2019-05-01 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_value_primitive_field): Treat more fields as
bitfields.
gdb/testsuite/ChangeLog
2019-05-01 Tom Tromey <tromey@adacore.com>
* gdb.ada/packed_array_assign/aggregates.ads (Nested_Packed): New
record.
(NPR): New variable.
* gdb.ada/packed_array_assign.exp: Add nested packed assignment
test.
A bug internal to AdaCore notes that assigning a non-scalar value to
an element of a packed array will sometimes fail.
The bug turns out to be that ada_value_assign incorrectly computes the
starting point for the assignment. This patch fixes the problem.
gdb/ChangeLog
2019-05-01 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_value_assign): Correctly compute starting offset
for big-endian copies.
gdb/testsuite/ChangeLog
2019-05-01 Tom Tromey <tromey@adacore.com>
* gdb.ada/packed_array_assign.exp: Add packed assignment
regression test.
When running fullpath-expand.exp with target_board=dwarf4-gdb-index, we run
into:
...
$ make check-gdb RUNTESTFLAGS="--target_board=dwarf4-gdb-index fullpath-expand.exp"
Running src/gdb/testsuite/gdb.base/fullpath-expand.exp ...
gdb compile failed, cc-with-tweaks.sh: unable to find usable gdb
=== gdb Summary ===
nr of untested testcases 1
...
The same happens with fullname.exp.
The dwarf4-gdb-index.exp board file includes cc-with-tweaks.exp, which uses
cc-with-tweaks.sh, which calls gdb-add-index.sh.
The gdb-add-index.sh script uses a gdb executable, defaulting to gdb:
...
GDB=${GDB:=gdb}
...
The cc-with-tweaks.sh script tries to ensure that the build gdb executable is
used by gdb-add-index.sh:
...
if [ -z "$GDB" ]
then
if [ -f ./gdb ]
then
GDB="./gdb -data-directory data-directory"
elif [ -f ../gdb ]
then
GDB="../gdb -data-directory ../data-directory"
elif [ -f ../../gdb ]
then
GDB="../../gdb -data-directory ../../data-directory"
else
echo "$myname: unable to find usable gdb" >&2
exit 1
fi
fi
...
So, if the current directory is build/gdb/testsuite, then a gdb executable
build/gdb/testsuite/../gdb will be used.
However, in the case of fullpath-expand.exp the test cd's into the sources:
...
set saved_pwd [pwd]
cd $srcdir
set err [gdb_compile "${subdir}/${srcfile} ${subdir}/${srcfile2}" $binfile \
executable {debug}]
cd $saved_pwd
...
and cc-with-tweaks.sh generates the "unable to find usable gdb" error.
The same error occurs if we use --target_board=cc-with-dwz instead (only in
this case we actually don't need gdb, we just need the GDB variable to be set
in cc-with-tweaks.sh, which arguably is a bug in cc-with-tweaks.sh).
Fix both errors in cc-with-tweaks.exp by generating a gdb script gdb.sh using
$GDB, $GDBFLAGS and $INTERNAL_GDBFLAGS and passing this script to
cc-with-tweaks.sh by setting env(GDB).
Tested on x86_64-linux for gdb.base.
gdb/testsuite/ChangeLog:
2019-05-01 Tom de Vries <tdevries@suse.de>
* boards/cc-with-tweaks.exp: Generate gdb.sh, and pass it in env(GDB).
Board file dwarf4-gdb-index.exp contains all the commands from
cc-with-tweaks.exp (with CC_WITH_TWEAKS_FLAGS set to "-i").
Make dwarf4-gdb-index.exp smaller by including cc-with-tweaks.exp.
Tested on x86_64-linux for gdb.base.
gdb/testsuite/ChangeLog:
2019-05-01 Tom de Vries <tdevries@suse.de>
* boards/dwarf4-gdb-index.exp: Use cc-with-tweaks.exp.
Dwarf5 defines DW_FORM_strx1 and others, which are similar
to DW_FORM_strx but uses 1-4 bytes unsigned integers. This is
a small step towards supporting dwarf5 in gdb.
This global is meant to point to the "main" thread of execution of
the program we are debugging. It is set when attaching to a process
or when receiving a CREATE_PROCESS_DEBUG_EVENT event. The theory at
the time was that this was also going to be the thread receiving
the EXIT_PROCESS_DEBUG_EVENT event.
Unfortunately, we have discovered since then that this is actually
not guaranteed. What this means in practice is that there is moderate
risk that main_thread_id refers to a thread which no longer exists.
This global is used in 3 situations:
- OUTPUT_DEBUG_STRING_EVENT
- LOAD_DLL_DEBUG_EVENT
- UNLOAD_DLL_DEBUG_EVENT
It's not clear why we would need to use the main_thread_id in those cases
instead of using the thread ID provided by the kernel events itself.
So this patch implements this approach, which then allows us to delete
the main_thread_id global.
gdb/testsuite:
* windows-nat.c (main_thread_id): Delete.
(handle_output_debug_string): Replace main_thread_id by
current_event.dwThreadId.
(fake_create_process): Likewise.
(get_windows_debug_event) <CREATE_PROCESS_DEBUG_EVENT>:
Do not set main_thread_id.
<LOAD_DLL_DEBUG_EVENT>: Replace main_thread_id by
current_event.dwThreadId.
<UNLOAD_DLL_DEBUG_EVENT>: Likewise.
We have observed that GDB would randomly trip the following
assertion failure when debugging on Windows. When allowing
the program to run until the inferior exits, we occasionally see:
(gdb) cont
Continuing.
[Thread 48192.0xd100 exited with code 1]
[Thread 48192.0x10ad8 exited with code 1]
[Thread 48192.0x36e28 exited with code 0]
[Thread 48192.0x52be4 exited with code 0]
[Thread 48192.0x5aa40 exited with code 0]
../../src/gdb/thread.c:453: internal-error: void delete_thread_1(thread_inf
o*, bool): Assertion `thr != nullptr' failed.
Running the same scenario with some additional traces enabled...
(gdb) set verbose
(gdb) set debugevents
... allows us to understand what the issue is. To understand, we need
to first look at the events received when starting the program, and
in particular which threads got created how. First, we get a
CREATE_PROCESS_DEBUG_EVENT for tid=0x442a8:
gdb: kernel event for pid=317536 tid=0x442a8 code=CREATE_PROCESS_DEBUG_EVENT)
Shortly after, we get some CREATE_THREAD_DEBUG_EVENT events,
one of them being for tid=0x4010c:
gdb: kernel event for pid=317536 tid=0x4010c code=CREATE_THREAD_DEBUG_EVENT)
Fast forward a bit of debugging, and we do a "cont" as above,
at which point the programs reaches the end, and the system reports
"exit" events. The first interesting one is the following:
gdb: kernel event for pid=317536 tid=0x442a8 code=EXIT_THREAD_DEBUG_EVENT)
This is reporting a thread-exit event for a thread whose tid
is the TID of what we call the "main thread". That's the thread
that was created when we received the CREATE_PROCESS_DEBUG_EVENT
notification, and whose TID is actually stored in a global variable
named main_thread_id. This is not something we expected, as
the assumption we made was that the main thread would exit last,
and we would be notified of it via an EXIT_PROCESS_DEBUG_EVENT.
But apparently, this is not always true, at least on Windows Server
2012 and 2016 where this issue has been observed happening randomly.
The consequence of the above notification is that we call
windows_delete_thread for that thread, which removes it from
our list of known threads.
And a little bit later, then we then get the EXIT_PROCESS_DEBUG_EVENT,
and we can see that the associated tid is not the main_thread_id,
but rather the tid of one of the threads that was created during
the lifetime of the program, in this case tid=0x4010c:
gdb: kernel event for pid=317536 tid=0x4010c code=EXIT_PROCESS_DEBUG_EVENT)
And the debug trace printed right after shows why we're crashing:
[Deleting Thread 317536.0x442a8]
We are trying to delete the thread whose tid=0x442a8, which is
the main_thread_id! As we have already deleted that thread before,
the search for it returns a nullptr, which then trips the assertion
check in delete_thread_1.
This commit fixes this issue. It ignores the open question of
what to do with the main_thread_id global, particularly after
that thread has been removed from our list of threads. This will
be dealt with as a separate patch, to allow cherry-picking
this patch into a release branch.
For now, we fix the code so as to avoid this crash.
gdb/ChangeLog:
* windows-nat.c (get_windows_debug_event) <EXIT_PROCESS_DEBUG_EVENT>:
Use current_event.dwThreadId instead of main_thread_id.
When an Ada program is dynamically linked against libgnat, and when
one of the standard exceptions is used, the exception object may be
referenced by the main executable using a copy relocation.
In this situation, a "catch exception" for those exceptions will not
manage to stop. This happens because, under the hood, "catch
exception" creates an expression object that examines the object
addresses -- but in this case, the address will be incorrect.
This patch fixes the problem by arranging for these filter expressions
to examine all the relevant minimal symbols. This way, the object
from libgnat will be found as well.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-04-30 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_lookup_simple_minsyms): New function.
(create_excep_cond_exprs): Iterate over program spaces.
(ada_exception_catchpoint_cond_string): Examine all minimal
symbols for exception types.
gdb/testsuite/ChangeLog
2019-04-30 Tom Tromey <tromey@adacore.com>
* lib/ada.exp (find_ada_tool): New proc.
* lib/gdb.exp (gdb_compile_shlib): Allow .o files as inputs.
* gdb.ada/catch_ex_std.exp: New file.
* gdb.ada/catch_ex_std/foo.adb: New file.
* gdb.ada/catch_ex_std/some_package.adb: New file.
* gdb.ada/catch_ex_std/some_package.ads: New file.
PR c++/24470 concerns a crash in dwarf2read.c that occurs with a
particular test case.
The issue turns out to be that process_structure_scope will pass NULL
to symbol_symtab. This happens because new_symbol decided not to
create a symbol for the particular DIE.
This patch fixes the problem by finding another reasonably-appropriate
symtab to use instead; issuing a complaint if one cannot be found for
some reason.
As mentioned in the bug, I think there are other bugs here. For
example, when using "ptype" on the "l" object in the test case, I
think I would expect to see the template parameter. I didn't research
this too closely, since it seemed more important to fix the crash.
Tested on x86-64 Fedora 29.
I'd like to check this in to the 8.3 branch as well.
2019-04-30 Tom Tromey <tromey@adacore.com>
PR c++/24470:
* dwarf2read.c (process_structure_scope): Handle case where type
has template parameters but no symbol was created.
gdb/testsuite/ChangeLog
2019-04-30 Tom Tromey <tromey@adacore.com>
PR c++/24470:
* gdb.cp/temargs.cc: Add test code from PR.
Types in Fortran can have the 'allocatable' qualifier attached to
indicate that memory needs to be explicitly allocated by the user.
This patch extends GDB to show this qualifier when printing types.
Lots of tests results are then updated to include this new qualifier
in the expected results.
gdb/ChangeLog:
* f-typeprint.c (f_type_print_base): Print 'allocatable' type
qualifier.
* gdbtypes.h (TYPE_IS_ALLOCATABLE): Define.
gdb/testsuite/ChangeLog:
* gdb.fortran/vla-datatypes.exp: Update expected results.
* gdb.fortran/vla-ptype.exp: Likewise.
* gdb.fortran/vla-type.exp: Likewise.
* gdb.fortran/vla-value.exp: Likewise.
The whitespace produced as types are printed seems inconsistent. This
commit updates the rules in an attempt to make whitespace more
balanced and consistent. Expected results are updated.
gdb/ChangeLog:
* f-typeprint.c (f_print_type): Update rules for printing
whitespace.
(f_type_print_varspec_suffix): Likewise.
gdb/testsuite/ChangeLog:
* gdb.fortran/ptr-indentation.exp: Update expected results.
* gdb.fortran/ptype-on-functions.exp: Likewise.
* gdb.fortran/vla-ptr-info.exp: Likewise.
* gdb.fortran/vla-value.exp: Likewise.
Before this commit using ptype on a Fortran function will include
information about the functions return type, but not the expected
arguments as it would for C or C++. After this commit argument types
are included in the ptype output.
For example, before GDB prints:
(gdb) ptype fun1
type = integer(kind=4) ()
(gdb) ptype is_bigger
type = logical(kind=4) ()
and after GDB prints:
(gdb) ptype fun1
type = integer(kind=4) (integer(kind=4))
(gdb) ptype is_bigger
type = logical(kind=4) (integer(kind=4), integer(kind=4))
gdb/ChangeLog:
* f-typeprint.c (f_type_print_varspec_suffix): Handle printing
function arguments.
gdb/testsuite/ChangeLog:
* gdb.fortran/ptype-on-functions.exp: New file.
* gdb.fortran/ptype-on-functions.f90: New file.
For a program compiled with gfortran the base type names are written
as lower cases in the DWARF, and so GDB will display them as lower
case. Additionally, in most places where GDB supplies its own type
names (for example all of the types defined in f-lang.c in
`build_fortran_types`), the type names are all lower case.
An exception to this is where GDB prints the void type for Fortran.
In this case GDB uses upper case.
I'm not aware of any reason why this type should merit special
attention, and it looks our of place when printing types, so this
commit changes from 'VOID' to 'void' to match all the other types.
gdb/ChangeLog:
* f-lang.c (build_fortran_types): Change name of void type to
lower case.
* f-typeprint.c (f_type_print_base): Print the name of the void
type, rather than a fixed string.
* f-valprint.c (f_decorations): Use lower case void string.
gdb/testsuite/ChangeLog:
* gdb.fortran/exprs.exp (test_convenience_variables): Expect lower
case void string.
Currently when using $_creal and $_cimag to access the components of a
complex number the types of these components will have C type names
'float', 'double', etc. This is because the components of a complex
number are not given type names in DWARF, so GDB has to pick some
suitable names, and currently we always use the C names.
This commit changes the type names used based on the language, so for
Fortran we will now use the Fortran float types, and so will get the
Fortran float type names 'real', 'real*8', etc.
gdb/ChangeLog:
* dwarf2read.c (dwarf2_init_complex_target_type): Use different
types for Fortran.
gdb/testsuite/ChangeLog:
* gdb.fortran/complex.exp: Expand.
* gdb.fortran/complex.f: Renamed to...
* gdb.fortran/complex.f90: ...this, and extended to add more
complex values.
Future commits will add more Fortran specific expression operators.
In preparation for these new operators, this commit adds a new
fortran-operator.def file similar to how GDB already has
ada-operator.def.
I've moved UNOP_KIND the Fortran specific operator I introduced in
commit 4d00f5d8f6 into this file, and renamed it to make it clearer
that the operator is Fortran specific. I've then updated the Fortran
exp_descriptor table (exp_descriptor_f) to use entirely Fortran
specific functions that now handle UNOP_FORTRAN_KIND (the new name for
UNOP_KIND).
There should be no visible changes for standard users after this
commit, though for developers, the output when 'set debug expression
1' is now better, before:
(gdb) p kind (l1)
Dump of expression @ 0x2ccc7a0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 42 *...............
1 OP_NULL 47730176 .N..............
2 BINOP_INTDIV 47729184 J..............
3 OP_VAR_VALUE 42 *...............
4 UNOP_KIND 78 N...............
Dump of expression @ 0x2ccc7a0, after conversion to prefix form:
Expression: `Invalid expression
(gdb)
and after:
(gdb) p kind (l1)
Dump of expression @ 0x294d0b0, before conversion to prefix form:
Language fortran, 5 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 unknown opcode: 224 44088544 ................
2 unknown opcode: 208 44087504 ................
3 OP_VAR_VALUE 40 (...............
4 UNOP_FORTRAN_KIND 119 w...............
Dump of expression @ 0x294d0b0, after conversion to prefix form:
Expression: `KIND(test::l1)'
Language fortran, 5 elements, 16 bytes each.
0 UNOP_FORTRAN_KIND
1 OP_VAR_VALUE Block @0x2a0bce0, symbol @0x2a0b8d0 (l1)
$1 = 1
(gdb)
gdb/ChangeLog:
* gdb/expprint.c (dump_subexp_body_standard): Remove use of
UNOP_KIND.
* gdb/expression.h (exp_opcode): Include 'fortran-operator.def'.
* gdb/f-exp.y (exp): Rename UNOP_KIND to UNOP_FORTRAN_KIND.
* gdb/f-lang.c (evaluate_subexp_f): Likewise.
(operator_length_f): New fuction.
(print_subexp_f): New function.
(op_name_f): New function.
(dump_subexp_body_f): New function.
(operator_check_f): New function.
(exp_descriptor_f): Replace standard expression handling functions
with new functions.
* gdb/fortran-operator.def: New file.
* gdb/parse.c (operator_length_standard): Remove use of UNOP_KIND.
* gdb/std-operator.def: Remove UNOP_KIND.
What appears to be a stray double quote character in std-operator.def
causes incorrect highlighting in my editor.
The quote was introduced in this commit:
commit 858be34c5a
Date: Mon Sep 4 20:21:15 2017 +0100
Handle "p S::method()::static_var" in the C++ parser
I can't see any reason why the quote should be there, so this commit
removes it.
gdb/ChangeLog:
* std-operator.def: Remove unbalanced, stray double quote
character.
Introduce a new print setting max-depth which can be set with 'set
print max-depth DEPTH'. The default value of DEPTH is 20, but this
can also be set to unlimited.
When GDB is printing a value containing nested structures GDB will
stop descending at depth DEPTH. Here is a small example:
typedef struct s1 { int a; } s1;
typedef struct s2 { s1 b; } s2;
typedef struct s3 { s2 c; } s3;
typedef struct s4 { s3 d; } s4;
s4 var = { { { { 3 } } } };
The following table shows how various depth settings affect printing
of 'var':
| Depth Setting | Result of 'p var' |
|---------------+--------------------------------|
| Unlimited | $1 = {d = {c = {b = {a = 3}}}} |
| 4 | $1 = {d = {c = {b = {a = 3}}}} |
| 3 | $1 = {d = {c = {b = {...}}}} |
| 2 | $1 = {d = {c = {...}}} |
| 1 | $1 = {d = {...}} |
| 0 | $1 = {...} |
Only structures, unions, and arrays are replaced in this way, scalars
and strings are not replaced.
The replacement is counted from the level at which you print, not from
the top level of the structure. So, consider the above example and
this GDB session:
(gdb) set print max-depth 2
(gdb) p var
$1 = {d = {c = {...}}}
(gdb) p var.d
$2 = {c = {b = {...}}}
(gdb) p var.d.c
$3 = {b = {a = 3}}
Setting the max-depth to 2 doesn't prevent the user from exploring
deeper into 'var' by asking for specific sub-fields to be printed.
The motivation behind this feature is to try and give the user more
control over how much is printed when examining large, complex data
structures.
The default max-depth of 20 means that there is a change in GDB's
default behaviour. Someone printing a data structure with 20 levels
of nesting will now see '{...}' instead of their data, they would need
to adjust the max depth, or call print again naming a specific field
in order to dig deeper into their data structure. If this is
considered a problem then we could increase the default, or even make
the default unlimited.
This commit relies on the previous commit, which added a new field to
the language structure, this new field was a string that contained the
pattern that should be used when a structure/union/array is replaced
in the output, this allows languages to use a syntax that is more
appropriate, mostly this will be selecting the correct types of
bracket '(...)' or '{...}', both of which are currently in use.
This commit should have no impact on MI output, expressions are
printed through the MI using -var-create and then -var-list-children.
As each use of -var-list-children only ever displays a single level of
an expression then the max-depth setting will have no impact.
This commit also adds the max-depth mechanism to the scripting
language pretty printers following basically the same rules as for the
built in value printing.
One quirk is that when printing a value using the display hint 'map',
if the keys of the map are structs then GDB will hide the keys one
depth level after it hides the values, this ensures that GDB produces
output like this:
$1 = map_object = {[{key1}] = {...}, [{key2}] = {...}}
Instead of this less helpful output:
$1 = map_object = {[{...}] = {...}, [{...}] = {...}}
This is covered by the new tests in gdb.python/py-nested-maps.exp.
gdb/ChangeLog:
* cp-valprint.c (cp_print_value_fields): Allow an additional level
of depth when printing anonymous structs or unions.
* guile/scm-pretty-print.c (gdbscm_apply_val_pretty_printer):
Don't print either the top-level value, or the children if the
max-depth is exceeded.
(ppscm_print_children): When printing the key of a map, allow one
extra level of depth.
* python/py-prettyprint.c (gdbpy_apply_val_pretty_printer): Don't
print either the top-level value, or the children if the max-depth
is exceeded.
(print_children): When printing the key of a map, allow one extra
level of depth.
* python/py-value.c (valpy_format_string): Add max_depth keyword.
* valprint.c: (PRINT_MAX_DEPTH_DEFAULT): Define.
(user_print_options): Initialise max_depth field.
(val_print_scalar_or_string_type_p): New function.
(val_print): Check to see if the max depth has been reached.
(val_print_check_max_depth): Define new function.
(show_print_max_depth): New function.
(_initialize_valprint): Add 'print max-depth' option.
* valprint.h (struct value_print_options) <max_depth>: New field.
(val_print_check_max_depth): Declare new function.
* NEWS: Document new feature.
gdb/doc/ChangeLog:
* gdb.texinfo (Print Settings): Document 'print max-depth'.
* guile.texi (Guile Pretty Printing API): Document that 'print
max-depth' can effect the display of a values children.
* python.texi (Pretty Printing API): Likewise.
(Values From Inferior): Document max_depth keyword.
gdb/testsuite/ChangeLog:
* gdb.base/max-depth.c: New file.
* gdb.base/max-depth.exp: New file.
* gdb.python/py-nested-maps.c: New file.
* gdb.python/py-nested-maps.exp: New file.
* gdb.python/py-nested-maps.py: New file.
* gdb.python/py-format-string.exp (test_max_depth): New proc.
(test_all_common): Call test_max_depth.
* gdb.fortran/max-depth.exp: New file.
* gdb.fortran/max-depth.f90: New file.
* gdb.go/max-depth.exp: New file.
* gdb.go/max-depth.go: New file.
* gdb.modula2/max-depth.exp: New file.
* gdb.modula2/max-depth.c: New file.
* lib/gdb.exp (get_print_expr_at_depths): New proc.
This commit is preparation work for the next commit, and by itself
makes no user visible change to GDB. I've split this work into a
separate commit in order to make code review easier.
This commit adds a new field 'la_is_string_type_p' to the language
struct, this predicate will return true if a type is a string type for
the given language.
Some languages already have a "is this a string" predicate that I was
able to reuse, while for other languages I've had to add a new
predicate. In this case I took inspiration from the value printing
code for that language - what different conditions would result in
printing something as a string.
A default "is this a string" method has also been added that looks for
TYPE_CODE_STRING, this is the fallback I've used for a couple of
languages.
In this commit I add the new field and initialise it for each
language, however at this stage the new field is never used.
gdb/ChangeLog:
* ada-lang.c (ada_language_defn): Initialise new field.
* c-lang.c (c_is_string_type_p): New function.
(c_language_defn): Initialise new field.
(cplus_language_defn): Initialise new field.
(asm_language_defn): Initialise new field.
(minimal_language_defn): Initialise new field.
* c-lang.h (c_is_string_type_p): Declare new function.
* d-lang.c (d_language_defn): Initialise new field.
* f-lang.c (f_is_string_type_p): New function.
(f_language_defn): Initialise new field.
* go-lang.c (go_is_string_type_p): New function.
(go_language_defn): Initialise new field.
* language.c (default_is_string_type_p): New function.
(unknown_language_defn): Initialise new field.
(auto_language_defn): Initialise new field.
* language.h (struct language_defn) <la_is_string_type_p>: New
member variable.
(default_is_string_type_p): Declare new function.
* m2-lang.c (m2_language_defn): Initialise new field.
* objc-lang.c (objc_language_defn): Initialise new field.
* opencl-lang.c (opencl_language_defn): Initialise new field.
* p-lang.c (pascal_is_string_type_p): New function.
(pascal_language_defn): Initialise new field.
* rust-lang.c (rust_is_string_type_p): New function.
(rust_language_defn): Initialise new field.
This commit is preparation work for a later commit, and by itself
makes no user visible change to GDB. I've split this work into a
separate commit in order to make code review easier.
This commit adds a new field 'la_struct_too_deep_ellipsis' to the
language struct, this string will be used in the next commit to print
a language specific string from within the generic value printing
code.
In this commit I add the new field and initialise it for each
language, however at this stage the new field is never used.
gdb/ChangeLog:
* language.h (struct language_defn) <la_struct_too_deep_ellipsis>:
New field.
* ada-lang.c (ada_language_defn): Initialise new field.
* c-lang.c (c_language_defn): Likewise.
(cplus_language_defn): Likewise.
(asm_language_defn): Likewise.
(minimal_language_defn): Likewise.
* d-lang.c (d_language_defn): Likewise.
* f-lang.c (f_language_defn): Likewise.
* go-lang.c (go_language_defn): Likewise.
* language.c (unknown_language_defn): Likewise.
(auto_language_defn): Likewise.
* m2-lang.c (m2_language_defn): Likewise.
* objc-lang.c (objc_language_defn): Likewise.
* opencl-lang.c (opencl_language_defn): Likewise.
* p-lang.c (pascal_language_defn): Likewise.
* rust-lang.c (rust_language_defn): Likewise.
A later commit would like to make use of a pointer to the function
ada_is_string_type, however, this will require the function to return
a bool (so the signature matches).
As the ada_is_string_type is a predicate function, and its return
value is only ever used as either true or false, then this commit
updates the function to return a bool.
As a consequence ada_is_character_type needs to change too.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* ada-lang.c (ada_is_character_type): Change return type to bool.
(ada_is_string_type): Likewise.
* ada-lang.h (ada_is_character_type): Update declaration
(ada_is_string_type): Likewise.
When running gdb-caching-proc.exp, if skip_opencl_tests fails like this:
...
(gdb) run
Starting program: \
build/gdb/testsuite/outputs/gdb.base/gdb-caching-proc/opencltest13530.x
CHK_ERR (clGetPlatformIDs (1, &platform, NULL), -1001)
src/gdb/testsuite/lib/opencl_hostapp.c:73 error: Unknown
[Inferior 1 (process 13600) exited with code 01]
(gdb)
skip_opencl_tests: OpenCL support not detected
...
then this regexp in skip_opencl_tests fails to match:
...
-re ".*$inferior_exited_re code.*${gdb_prompt} $" {
...
so instead we hit the default clause after a 30 seconds timeout. With the
iteration count set at 10, we end up taking 6 minutes to run this test-case.
Fix this by adding the missing "with" in the regexp, bring back the runtime to
half a minute.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2019-04-29 Tom de Vries <tdevries@suse.de>
* lib/opencl.exp (skip_opencl_tests): Add missing "with" in regexp.
'thread|frame apply CMD' launches CMD so that CMD output goes to a string_file.
This patch ensures that string_file for such CMD output contains
style escape sequences that 'thread|frame apply' will later on
output on the real terminal, so as to have CMD output properly styled.
The idea is to have the class ui_file having overridable methods
to indicate that the output to this ui_file should be done using
'terminal' behaviour such as styling.
Then these methods are overriden in string_file so that a specially
constructed string_file will get output with style escape sequences.
After this patch, the output of CMD by thread|frame apply CMD is styled
similarly as when CMD is launched directly.
Note that string_file (term_out true) could also support wrapping,
but this is not done (yet?).
Tested on debian/amd64.
gdb/ChangeLog
2019-04-27 Philippe Waroquiers <philippe.waroquiers@skynet.be>
Support style in 'frame|thread apply'
* gdbcmd.h (execute_command_to_string): New term_out parameter.
* record.c (record_start, record_stop): Update callers of
execute_command_to_string with false.
* ui-file.h (class ui_file): New term_out and can_emit_style_escape
methods.
(class string_file): New constructor with term_out parameter.
Override methods term_out and can_emit_style_escape. New member
term_out.
(class stdio_file): Override can_emit_style_escape.
(class tee_file): Override term_out and can_emit_style_escape.
* utils.h (can_emit_style_escape): Remove.
* utils.c (can_emit_style_escape): Likewise.
Update all callers of can_emit_style_escape (SOMESTREAM) to
SOMESTREAM->can_emit_style_escape.
* source-cache.c (source_cache::get_source_lines): Likewise.
* stack.c (frame_apply_command_count): Call execute_command_to_string
passing the term_out characteristic of the current gdb_stdout.
* thread.c (thr_try_catch_cmd): Likewise.
* top.c (execute_command_to_string): pass term_out parameter
to construct the string_file for the command output.
* ui-file.c (term_cli_styling): New function (most code moved
from utils.c can_emit_style_escape).
(string_file::string_file, string_file::can_emit_style_escape,
stdio_file::can_emit_style_escape, tee_file::term_out,
tee_file::can_emit_style_escape): New functions.
Inferior function calls are powerful but might lead to undesired
results such as crashes when calling nested functions (frequently
used in particular in Ada).
This implements a GDB setting to disable calling inferior functions.
Note: the idea is that if/when the 'slash command' patch is pushed,
that this setting can be changed e.g. by using the shortcut /c.
This is version 2 of the patch. It handles all the received comments,
mostly replace 'can-call' by 'may-call', and avoid using
'inferior function call' in factor of 'calling function in the program'.
2019-04-26 Philippe Waroquiers <philippe.waroquiers@skynet.be>
gdb/ChangeLog
* NEWS: Mention the new set|show may-call-functions.
* infcall.c (may_call_functions_p): New variable.
(show_may_call_functions_p): New function.
(call_function_by_hand_dummy): Throws an error if not
may-call-functions.
(_initialize_infcall): Call add_setshow_boolean_cmd for
may-call-functions.
gdb/testsuite/ChangeLog
* gdb.base/callexit.exp: Test may-call-functions off.
gdb/doc/ChangeLog
* gdb.texinfo (Calling): Document the new
set|show may-call-functions.
This bug finds another usage where we end up segfaulting while
normalizing user input. inspect_type and replace_type recurse,
attempting to substitute the "real" symbol name for the typedef name.
However, since the both these names are the same, they keep calling
each other until the stack overflows.
A simple reproducer for it is given by
typedef struct foo foo;
int qux (foo *f) { return 0; }
(gdb) b qux(foo*)
Segmentation fault
inspect_type already contains some special handling to prevent a
similar situation from occurring with namespaces. I wonder, however,
whether we need be so pedantic about the exact nature of the substitution.
This patch implements this rather more aggressive assumption that these
substitutions should be avoided whenever the replacement symbol's name is
exactly the same as the one we're trying to substitute. [In the above
example, we're trying to substitute the tyepdef named "foo" with the symbol
named "foo" (a struct).]
gdb/ChangeLog:
PR c++/24367
* cp-support.c (inspect_type): Don't attempt substitutions
of symbol with the same name.
gdb/testsuite/ChangeLog:
PR c++/24367
* gdb.cp/meth-typedefs.cc (incomplete_struct)
(another_incomplete_struct, test_incomplete): New definitions.
(main): Use new definitions.
* gdb.cp/meth-typedefs.exp: Add new tests for `test_incomplete'
functions.
PR gdb/24475 concerns a memory leak coming from gdb's exception
handling code.
The leak occurs because throw_exception_sjlj does not arrange to
destroy the exception object it is passed. However, because
gdb_exception has a destructor, it's undefined to longjmp in this
situation.
This patch fixes the problem by avoiding the need to run any
destructors in gdb_rl_callback_handler, by making the gdb_exception
"static".
gdb/ChangeLog
2019-04-25 Tom Tromey <tromey@adacore.com>
PR gdb/24475:
* event-top.c (gdb_rl_callback_handler): Make "gdb_rl_expt"
static.
This makes exception handling more efficient in a few spots, through
the use of const- and rvalue-references.
I wrote this patch by commenting out the gdb_exception copy
constructor and then examining the resulting error messages one by
one, introducing the use of std::move where appropriate.
gdb/ChangeLog
2019-04-25 Tom Tromey <tromey@adacore.com>
* xml-support.c (struct gdb_xml_parser) <set_error>: Take an
rvalue reference.
(gdb_xml_start_element_wrapper, gdb_xml_end_element_wrapper)
(gdb_xml_parser::parse): Use std::move.
* python/python-internal.h (gdbpy_convert_exception): Take a const
reference.
* python/py-value.c (valpy_getitem, valpy_nonzero): Use
std::move.
* python/py-utils.c (gdbpy_convert_exception): Take a const
reference.
* python/py-inferior.c (infpy_write_memory, infpy_search_memory):
Use std::move.
* python/py-breakpoint.c (bppy_set_condition, bppy_set_commands):
Use std::move.
* mi/mi-main.c (mi_print_exception): Take a const reference.
* main.c (handle_command_errors): Take a const reference.
* linespec.c (parse_linespec): Use std::move.
* infcall.c (run_inferior_call): Use std::move.
(call_function_by_hand_dummy): Use std::move.
* exec.c (try_open_exec_file): Use std::move.
* exceptions.h (exception_print, exception_fprintf)
(exception_print_same): Update.
* exceptions.c (print_exception, exception_print)
(exception_fprintf, exception_print_same): Change parameters to
const reference.
* event-top.c (gdb_rl_callback_read_char_wrapper): Update.
* common/new-op.c: Use std::move.
* common/common-exceptions.h (struct gdb_exception): Add move
constructor.
(struct gdb_exception_error, struct gdb_exception_quit, struct
gdb_quit_bad_alloc): Change constructor to move constructor.
(throw_exception): Change parameter to rvalue reference.
* common/common-exceptions.c (throw_exception): Take rvalue
reference.
* cli/cli-interp.c (safe_execute_command): Use std::move.
* breakpoint.c (insert_bp_location, location_to_sals): Use
std::move.
The Guile code will longjmp (via scm_throw) when an object requiring
destruction is on the stack. This is undefined behavior.
This changes this code to run any destructors in inner scopes, and to
pass a POD to gdbscm_throw_gdb_exception.
gdb/ChangeLog
2019-04-25 Tom Tromey <tromey@adacore.com>
* guile/scm-exception.c (gdbscm_scm_from_gdb_exception)
(gdbscm_throw_gdb_exception): Take a gdbscm_gdb_exception.
* guile/scm-block.c, guile/scm-breakpoint.c, guile/scm-cmd.c,
guile/scm-disasm.c, guile/scm-frame.c, guile/scm-lazy-string.c,
guile/scm-math.c, guile/scm-param.c, guile/scm-ports.c,
guile/scm-symbol.c, guile/scm-symtab.c, guile/scm-type.c,
guile/scm-value.c: Use unpack.
* guile/guile-internal.h (gdbscm_scm_from_gdb_exception): Take a
gdbscm_gdb_exception.
(gdbscm_throw_gdb_exception): Likewise.
(struct gdbscm_gdb_exception): New.
(unpack): New function.
(gdbscm_wrap): Use unpack.
This changes the SJLJ exception handling code to be a bit more
efficient, by using rvalue references and move assignment when
possible.
Tested by the buildbot.
gdb/ChangeLog
2019-04-25 Tom Tromey <tromey@adacore.com>
* event-top.c (gdb_rl_callback_read_char_wrapper_noexcept)
(gdb_rl_callback_handler): Use std::move.
* common/common-exceptions.h (struct gdb_exception): Add move
assignment operator.
(throw_exception_sjlj): Change "exception" to const reference.
* common/common-exceptions.c (exceptions_state_mc_catch): Update.
(throw_exception_sjlj): Change "exception" to const reference.
Alan Hayward
Simon Cook
Jan Vrany
Andrew Burgess
Tom de Vries
Tom Tromey
Sergio Durigan Junior
Simon Marchi
John Darrington
Simon Marchi
Joel Brobecker
Tom Tromey
Xavier Roirand
Kevin Buettner
Raul Tambre
Philippe Waroquiers
Dilyan Palauzov
Eli Zaretskii
Ali Tamur
Keith Seitz