| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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 arc_tdesc_init to return bool.
gdb/ChangeLog
2019-05-04 Tom Tromey <tom@tromey.com>
* arc-tdep.c (arc_tdesc_init): Return bool.
|
|
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 arc-tdep.c to use bool, true, and false.
gdb/ChangeLog
2019-05-04 Tom Tromey <tom@tromey.com>
* arc-tdep.c (arc_tdesc_init): Use bool.
|
|
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".
|
|
This changes valid_command_p to return bool.
gdb/ChangeLog
2019-05-04 Tom Tromey <tom@tromey.com>
* cli/cli-cmds.c (valid_command_p): Return bool.
|
|
This changes valid_user_defined_cmd_name_p to return bool.
gdb/ChangeLog
2019-05-04 Tom Tromey <tom@tromey.com>
* cli/cli-decode.c (valid_user_defined_cmd_name_p): Return bool.
* command.h (valid_user_defined_cmd_name_p): Channge return type.
|
|
python/lib/gdb/command/prompt.py
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 799efbe8e01
|
|
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.
|
|
Add some additional builtin procedures for Fortran, these are MOD,
CEILING, FLOOR, MODULO, and CMPLX.
gdb/ChangeLog:
* f-exp.y (BINOP_INTRINSIC): New token.
(exp): New parser rule handling BINOP_INTRINSIC.
(f77_keywords): Add new builtin procedures.
* f-lang.c (evaluate_subexp_f): Handle BINOP_MOD, UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(operator_length_f): Handle UNOP_FORTRAN_CEILING,
UNOP_FORTRAN_FLOOR, BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(print_unop_subexp_f): New function.
(print_binop_subexp_f): New function.
(print_subexp_f): Handle UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX.
(dump_subexp_body_f): Likewise.
(operator_check_f): Likewise.
* fortran-operator.def: Add UNOP_FORTRAN_CEILING, UNOP_FORTRAN_FLOOR,
BINOP_FORTRAN_MODULO, BINOP_FORTRAN_CMPLX
gdb/testsuite/ChangeLog:
* gdb.fortran/intrinsics.exp: Extend to cover MOD, CEILING, FLOOR,
MODULO, CMPLX.
|
|
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 4d00f5d8f6c4 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 858be34c5a03bb8973679ebf00d360182434dc00
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.
|
|
Fix build problem when configuring with guile.
Fix the forgotten copy of ChangeLog info to ChangeLog.
|
|
'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.
|
