Current versions of GCC support switching the format used for "long double"
to either IBM double double or IEEE-128. The resulting binary is marked
via different setting of the Tag_GNU_Power_ABI_FP GNU attribute.
This patch checks this attribute to detect the format of the default
"long double" type and sets GDB's notion of the format accordingly.
The patch also adds support for the "__ibm128" type, which always uses
IBM double double format independent of the format used for "long double".
A new test case verifies that all three types, "long double", "__float128",
and "__ibm128" are correctly detected in all three compiler settings,
the default setting, -mabi=ieeelongdouble, and -mabi=ibmlongdouble.
gdb/ChangeLog:
2017-11-21 Ulrich Weigand <uweigand@de.ibm.com>
* ppc-tdep.h (enum powerpc_long_double_abi): New data type.
(struct gdbarch_tdep): New member long_double_abi.
* rs6000-tdep.c (rs6000_gdbarch_init): Initialize long_double_abi
member of tdep struct based on Tag_GNU_Power_ABI_FP attribute.
* ppc-linux-tdep.c (ppc_linux_init_abi): Install long double data
format depending on long_double_abi tdep member.
(ppc_floatformat_for_type): Handle __ibm128 type.
gdb/testsuite/ChangeLog:
2017-11-21 Ulrich Weigand <uweigand@de.ibm.com>
* gdb.arch/ppc-longdouble.exp: New file.
* gdb.arch/ppc-longdouble.c: Likewise.
This new testcase has a test that fails like this here:
$1 = (<data variable, no debug info> *) 0x60208c <some_minsym>
(gdb) FAIL: gdb.ada/minsyms.exp: print &some_minsym
The problem is that the testcase hardcodes an expected address for the
"some_minsym" variable, which obviously isn't stable.
Fix that by expecting $hex instead.
gdb/testsuite/ChangeLog:
2017-11-21 Pedro Alves <palves@redhat.com>
* gdb.ada/minsyms.exp: Accept any address for 'some_minsym'.
Fix:
/Users/simark/src/binutils-gdb/gdb/darwin-nat.c:2404:3: error: no matching function for call to 'add_setshow_boolean_cmd'
add_setshow_boolean_cmd ("mach-exceptions", class_support,
^~~~~~~~~~~~~~~~~~~~~~~
gdb/ChangeLog:
* darwin-nat.c (set_enable_mach_exceptions): Constify parameter.
Here we want to find where we'd insert "after", so we want
std::lower_bound, not std::upper_bound.
gdb/ChangeLog:
2017-11-21 Pedro Alves <palves@redhat.com>
* dwarf2read.c (mapped_index::find_name_components_bounds)
<completion mode, upper bound>: Use std::lower_bound instead of
std::upper_bound.
(test_mapped_index_find_name_component_bounds): Remove incorrect
"t1_fund" from expected symbols.
This commit factors out the name-components-vector building and bounds
searching out of dw2_expand_symtabs_matching_symbol into separate
functions, and adds unit tests that:
- expose both the latent bug mentioned in the previous commit, and
also,
- for completeness exercise the 0xff character handling fixed in the
previous commit more directly.
The actual fix for the now-exposed bug is left for the following
patch.
gdb/ChangeLog:
2017-11-21 Pedro Alves <palves@redhat.com>
* dwarf2read.c (mapped_index::name_components_casing): New field.
(mapped_index) <build_name_components,
find_name_components_bounds): Declare new methods.
(mapped_index::find_name_components_bounds)
(mapped_index::build_name_components): New methods, factored out
from dw2_expand_symtabs_matching_symbol.
(check_find_bounds_finds)
(test_mapped_index_find_name_component_bounds): New.
(run_test): Rename to ...
(test_dw2_expand_symtabs_matching_symbol): ... this.
(run_test): Reimplement.
The find-upper-bound-for-completion algorithm in the name components
accelerator table in dwarf2read.c increments a char in a string, and
asserts that it's not incrementing a 0xff char, but that's incorrect.
First, we shouldn't be calling gdb_assert on input.
Then, if "char" is signed, comparing a caracther with "0xff" will
never yield true, which is caught by Clang with:
error: comparison of constant 255 with expression of type '....' (aka 'char') is always true [-Werror,-Wtautological-constant-out-of-range-compare]
gdb_assert (after.back () != 0xff);
~~~~~~~~~~~~~ ^ ~~~~
And then, 0xff is a valid character on non-UTF-8/ASCII character sets.
E.g., it's 'ÿ' in Latin1. While GCC nor Clang support !ASCII &&
!UTF-8 characters in identifiers (GCC supports UTF-8 characters only
via UCNs, see https://gcc.gnu.org/onlinedocs/cpp/Character-sets.html),
but other compilers might (Visual Studio?), so it doesn't hurt to
handle it correctly. Testing is covered by extending the
dw2_expand_symtabs_matching unit tests with relevant cases.
However, without further changes, the unit tests still fail... The
problem is that cp-name-parser.y assumes that identifiers are ASCII
(via ISALPHA/ISALNUM). This commit fixes that too, so that we can
unit test the dwarf2read.c changes. (The regular C/C++ lexer in
c-lang.y needs a similar treatment, but I'm leaving that for another
patch.)
While doing this, I noticed a thinko in the computation of the upper
bound for completion in dw2_expand_symtabs_matching_symbol. We're
using std::upper_bound but we should use std::lower_bound. I extended
the unit test with a case that I thought would expose it, this one:
+ /* These are used to check that the increment-last-char in the
+ matching algorithm for completion doesn't match "t1_fund" when
+ completing "t1_func". */
+ "t1_func",
+ "t1_func1",
+ "t1_fund",
+ "t1_fund1",
The algorithm actually returns "t1_fund1" as lower bound, so "t1_fund"
matches incorrectly. But turns out the problem is masked because
later here:
for (;lower != upper; ++lower)
{
const char *qualified = index.symbol_name_at (lower->idx);
if (!lookup_name_matcher.matches (qualified)
the lookup_name_matcher.matches check above filters out "t1_fund"
because that doesn't start with "t1_func".
I'll fix the latent bug in follow up patches, after factoring things
out a bit in a way that allows unit testing the relevant code more
directly.
gdb/ChangeLog:
2017-11-21 Pedro Alves <palves@redhat.com>
* cp-name-parser.y (cp_ident_is_alpha, cp_ident_is_alnum): New.
(symbol_end): Use cp_ident_is_alnum.
(yylex): Use cp_ident_is_alpha and cp_ident_is_alnum.
* dwarf2read.c (make_sort_after_prefix_name): New function.
(dw2_expand_symtabs_matching_symbol): Use it.
(test_symbols): Add more symbols.
(run_test): Add tests.
The gdb.base/whatis-ptype-typedefs.exp testcase has several tests that
fail on 32-bit architectures. E.g., on 'x86-64 -m32', I see:
...
FAIL: gdb.base/whatis-ptype-typedefs.exp: lang=c: cast: whatis (float_typedef) v_uchar_array_t_struct_typedef (invalid)
FAIL: gdb.base/whatis-ptype-typedefs.exp: lang=c: cast: ptype (float_typedef) v_uchar_array_t_struct_typedef (invalid)
...
gdb.log:
(gdb) whatis (float_typedef) v_uchar_array_t_struct_typedef
type = float_typedef
(gdb) FAIL: gdb.base/whatis-ptype-typedefs.exp: lang=c: cast: whatis (float_typedef) v_uchar_array_t_struct_typedef (invalid)
As Simon explained [1], the issue boils down to the fact that on
64-bit, this is an invalid cast:
(gdb) p (float_typedef) v_uchar_array_t_struct_typedef
Invalid cast.
while on 32 bits it is valid:
(gdb) p (float_typedef) v_uchar_array_t_struct_typedef
$1 = 1.16251721e-41
The expression basically tries to cast an array (which decays to a
pointer) to a float. The cast works on 32 bits because a float and a
pointer are of the same size, and value_cast works in that case:
~~~
More general than a C cast: accepts any two types of the same length,
and if ARG2 is an lvalue it can be cast into anything at all. */
~~~
On 64 bits, they are not the same size, so it ends throwing the
"Invalid cast" error.
The testcase is expecting the invalid cast behavior, thus the FAILs.
A point of these tests was to cover as many code paths in value_cast
as possible, as a sort of documentation of the current behavior:
# The main idea here is testing all the different paths in the
# value casting code in GDB (value_cast), making sure typedefs are
# preserved.
...
# We try all combinations, even those that don't parse, or are
# invalid, to catch the case of a regression making them
# inadvertently valid. For example, these convertions are
# invalid:
...
In that spirit, this commit makes the testcase adjust itself depending
on size of floats and pointers, and also test floats of different
sizes.
Passes cleanly on x86-64 GNU/Linux both -m64/-m32.
[1] - https://sourceware.org/ml/gdb-patches/2017-11/msg00382.html
gdb/ChangeLog:
2017-11-20 Pedro Alves <palves@redhat.com>
* gdb.base/whatis-ptype-typedefs.c (double_typedef)
(long_double_typedef): New typedefs.
Use DEF on double and long double.
* gdb.base/whatis-ptype-typedefs.exp: Add double and long double
cases.
(run_tests): New 'float_ptr_same_size', 'double_ptr_same_size',
and 'long_double_ptr_same_size' locals. Use them to decide
whether cast from array/function to float is valid/invalid.
Replace with for_each_thread.
gdb/gdbserver/ChangeLog:
* linux-low.c (kill_one_lwp_callback): Return void, take
argument directly, don't filter on pid.
(linux_kill): Use for_each_thread.
Replace with find_thread. Instead of setting the flag in the callback,
make the callback return true/false, and check the result against NULL
in the caller.
gdb/gdbserver/ChangeLog:
* linux-low.c (resume_status_pending_p): Return bool, remove
flag_p argument.
(linux_resume): Use find_thread.
Replace it with for_each_thread.
gdb/gdbserver/ChangeLog:
* linux-low.c (struct thread_resume_array): Remove.
(linux_set_resume_request): Return void, take arguments
directly.
(linux_resume): Use for_each_thread.
Replace with for_each_thread. I inlined unsuspend_one_lwp in
unsuspend_all_lwps, since it is very simple.
gdb/gdbserver/ChangeLog:
* linux-low.c (unsuspend_one_lwp): Remove.
(unsuspend_all_lwps): Use for_each_thread, inline code from
unsuspend_one_lwp.
Replace find_inferior with find_thread. Since it may be useful in the
future, I added another overload to find_thread which filters based on a
ptid (using ptid_t::matches), so now iterate_over_lwps doesn't have to
do the filtering itself. iterate_over_lwps_filter is removed and
inlined into iterate_over_lwps.
gdb/gdbserver/ChangeLog:
* gdbthread.h (find_thread): Add overload with ptid_t filter.
* linux-low.c (struct iterate_over_lwps_args): Remove.
(iterate_over_lwps_filter): Remove.
(iterate_over_lwps): Use find_thread.
Replace with for_each_thread, and inline code from
reset_lwp_ptrace_options_callback.
gdb/gdbserver/ChangeLog:
* linux-low.c (reset_lwp_ptrace_options_callback): Remove.
(linux_handle_new_gdb_connection): Use for_each_thread, inline
code from reset_lwp_ptrace_options_callback.
Replace two usages with the overload of for_each_thread that filters on
pid. It allows to simplify the callback a little bit.
gdb/gdbserver/ChangeLog:
* linux-arm-low.c (struct update_registers_data): Remove.
(update_registers_callback): Return void, take arguments
directly, don't check thread's pid.
(arm_insert_point, arm_remove_point): Use for_each_thread.
Replace with for_each_thread.
gdb/gdbserver/ChangeLog:
* win32-low.c (continue_one_thread): Return void, take argument
directly.
(child_continue): Use for_each_thread.
Straightforward replacement of find_inferior with the overload of
for_each_thread that filters on pid. I am able to build-test this
patch, but not run it.
gdb/gdbserver/ChangeLog:
* win32-i386-low.c (update_debug_registers_callback): Rename
to ...
(update_debug_registers): ... this, return void, remove pid_p arg.
(x86_dr_low_set_addr, x86_dr_low_set_control): Use for_each_thread.
This changes struct symbol to use an enum to encode the concrete
subclass of a particular symbol. Note that "enum class" doesn't work
properly with bitfields, so a plain enum is used.
2017-11-17 Tom Tromey <tom@tromey.com>
* symtab.h (enum symbol_subclass_kind): New.
(struct symbol) <is_cplus_template_function, is_rust_vtable>:
Remove.
<subclass>: New member.
(SYMBOL_IS_CPLUS_TEMPLATE_FUNCTION): Update.
* rust-lang.c (rust_get_trait_object_pointer): Update.
* dwarf2read.c (read_func_scope): Update.
(read_variable): Update.
This changes template_symbol to derive from symbol, which seems a bit
cleaner; and also more consistent with rust_vtable_symbol.
2017-11-17 Tom Tromey <tom@tromey.com>
* dwarf2read.c (read_func_scope): Update.
* symtab.h (struct template_symbol): Derive from symbol.
<base>: Remove.
In Rust, virtual tables work a bit differently than they do in C++. In
C++, as you know, they are connected to a particular class hierarchy.
Rust, instead, can generate a virtual table for potentially any type --
in fact, one such virtual table for each trait (a trait is similar to an
abstract class or to a Java interface) that a type implements.
Objects that are referenced via a trait can't currently be inspected by
gdb. This patch implements the Rust equivalent of "set print object".
gdb relies heavily on the C++ ABI to decode virtual tables; primarily to
make "set print object" work; but also "info vtbl". However, Rust does
not currently have a specified ABI, so this approach seems unwise to
emulate.
Instead, I've changed the Rust compiler to emit some DWARF that
describes trait objects (previously their internal structure was
opaque), vtables (currently just a size -- but I hope to expand this in
the future), and the concrete type for which a vtable was emitted.
The concrete type is expressed as a DW_AT_containing_type on the
vtable's type. This is a small extension to DWARF.
This patch adds a new entry to quick_symbol_functions to return the
symtab that holds a data address. Previously there was no way in gdb to
look up a full (only minimal) non-text symbol by address. The psymbol
implementation of this method works by lazily filling in a map that is
added to the objfile. This avoids slowing down psymbol reading for a
feature that is likely to not be used too frequently.
I did not update .gdb_index. My thinking here is that the DWARF 5
indices will obsolete .gdb_index soon-ish, meaning that adding a new
feature to them is probably wasted work. If necessary I can update the
DWARF 5 index code when it lands in gdb.
Regression tested on x86-64 Fedora 25.
2017-11-17 Tom Tromey <tom@tromey.com>
* symtab.h (struct symbol) <is_rust_vtable>: New member.
(struct rust_vtable_symbol): New.
(find_symbol_at_address): Declare.
* symtab.c (find_symbol_at_address): New function.
* symfile.h (struct quick_symbol_functions)
<find_compunit_symtab_by_address>: New member.
* symfile-debug.c (debug_qf_find_compunit_symtab_by_address): New
function.
(debug_sym_quick_functions): Link to
debug_qf_find_compunit_symtab_by_address.
* rust-lang.c (rust_get_trait_object_pointer): New function.
(rust_evaluate_subexp) <case UNOP_IND>: New case. Call
rust_get_trait_object_pointer.
* psymtab.c (psym_relocate): Clear psymbol_map.
(psym_fill_psymbol_map, psym_find_compunit_symtab_by_address): New
functions.
(psym_functions): Link to psym_find_compunit_symtab_by_address.
* objfiles.h (struct objfile) <psymbol_map>: New member.
* dwarf2read.c (dwarf2_gdb_index_functions): Update.
(process_die) <DW_TAG_variable>: New case. Call read_variable.
(rust_containing_type, read_variable): New functions.
2017-11-17 Tom Tromey <tom@tromey.com>
* gdb.rust/traits.rs: New file.
* gdb.rust/traits.exp: New file.
This patch makes the syscalls_to_catch field of process_info an
std::vector<int>. The process_info structure must now be
newed/deleted.
In handle_extended_wait, the code that handles exec events destroys the
existing process_info and creates a new one. It moves the content of
syscalls_to_catch from the old to the new vector. I used std::move for
that (through an intermediary variable), which should have the same
behavior as the old code.
gdb/gdbserver/ChangeLog:
* inferiors.h (struct process_info): Add constructor, initialize
fields..
<syscalls_to_catch>: Change type to std::vector<int>.
* inferiors.c (add_process): Allocate process_info with new.
(remove_process): Free process_info with delete.
* linux-low.c (handle_extended_wait): Adjust.
(gdb_catching_syscalls_p, gdb_catch_this_syscall_p): Adjust.
* server.c (handle_general_set): Adjust.
Simple replacement of VEC with std::vector.
gdb/ChangeLog:
* common/filestuff.c: Include <algorithm>.
(open_fds): Change type to std::vector<int>.
(do_mark_open_fd): Adjust.
(unmark_fd_no_cloexec): Adjust.
(do_close): Adjust.
A simple replacement of VEC with std::vector.
gdb/ChangeLog:
* breakpoint.c (output_thread_groups): Take an std::vector.
(print_one_breakpoint_location): Adjust.
Consider a program which provides a symbol without debugging
information. For instance, compiling the following code without -g:
Some_Minimal_Symbol : Integer := 1234;
pragma Export (C, Some_Minimal_Symbol, "some_minsym");
Trying to print this variable with GDB now causes an error, which
is now expected:
(gdb) p some_minsym
'some_minsym' has unknown type; cast it to its declared type
However, trying to cast this symbol, or to take its address
does not work:
(gdb) p integer(some_minsym)
'some_minsym' has unknown type; cast it to its declared type
(gdb) p &some_minsym
'some_minsym' has unknown type; cast it to its declared type
Another manisfestation of this issue can be seen when trying to
insert an Ada exception catchpoint for a specific standard exception
(this only occurs if the Ada runtime is built without debugging
information, which is the default). For instance:
$ (gdb) catch exception constraint_error
warning: failed to reevaluate internal exception condition for catchpoint 0: 'constraint_error' has unknown type; cast it to its declared type
This is because, internally, the cachtpoint uses a condition referencing
a minimal symbol, more precisely:
long_integer (e) = long_integer (&constraint_error)
This patch fixes all issues listed above:
1. resolve_subexp: Special-case the handling of OP_VAR_MSYM_VALUE
expression elements, where there are no ambiguities to be resolved
in that situation;
2. ada_evaluate_subexp: Enhance the handling of the UNOP_CAST
handling so as to process the case where the target of
the cast is a minimal symbol (as well as a symbol with debugging
information). This mimics what's done in C.
gdb/ChangeLog:
* ada-lang.c (resolve_subexp): Add handling of OP_VAR_MSYM_VALUE.
(ada_evaluate_subexp_for_cast): New function.
(ada_evaluate_subexp) <UNOP_CAST>: Replace code by call to
ada_evaluate_subexp_for_cast.
(ada_evaluate_subexp) <nosideret>: Replace code by call to
eval_skip_value.
* eval.c (evaluate_var_value): Make non-static.
(evaluate_var_msym_value, eval_skip_value): Likewise.
* value.h (evaluate_var_value, evaluate_var_msym_value)
(eval_skip_value): Declare.
gdb/testsuite/ChangeLog:
* gdb.ada/minsyms: New testcase.
Tested on x86_64-linux. No regression. Fixes the following failures:
catch_ex.exp: continuing to Program_Error exception
catch_ex.exp: continuing to failed assertion
catch_ex.exp: continuing to unhandled exception
catch_ex.exp: continuing to program completion
complete.exp: p <Exported_Capitalized>
complete.exp: p Exported_Capitalized
complete.exp: p exported_capitalized
mi_catch_ex.exp: catch Program_Error (unexpected output)
mi_catch_ex.exp: continue to exception catchpoint hit (unknown output after running)
mi_catch_ex.exp: continue to assert failure catchpoint hit (unknown output after running)
mi_catch_ex.exp: continue to unhandled exception catchpoint hit (unknown output after running)
mi_ex_cond.exp: catch C_E if i = 2 (unexpected output)
This adds the testcase that exposed the multiple problems with Ctrl-C
handling fixed by the previous patches, when run against both native
and gdbserver GNU/Linux.
gdb/ChangeLog:
2017-11-16 Pedro Alves <palves@redhat.com>
* gdb.base/bp-cmds-continue-ctrl-c.c: New file.
* gdb.base/bp-cmds-continue-ctrl-c.exp: New file.
If you happen to press Ctrl-C while GDB is running the Python unwinder
machinery, the Ctrl-C is swallowed by the Python unwinder machinery.
For example, with:
break foo
commands
> c
> end
and
while (1)
foo ();
and then let the inferior hit "foo" repeatedly, sometimes Ctrl-C
results in:
~~~
23 usleep (100);
Breakpoint 2, foo () at gdb.base/bp-cmds-continue-ctrl-c.c:23
23 usleep (100);
^C
Breakpoint 2, Python Exception <class 'KeyboardInterrupt'> <class 'KeyboardInterrupt'>:
foo () at gdb.base/bp-cmds-continue-ctrl-c.c:23
23 usleep (100);
Breakpoint 2, foo () at gdb.base/bp-cmds-continue-ctrl-c.c:23
23 usleep (100);
Breakpoint 2, foo () at gdb.base/bp-cmds-continue-ctrl-c.c:23
23 usleep (100);
~~~
Notice the Python exception above. The interesting thing here is that
GDB continues as if nothing happened, doesn't really stop and give
back control to the user. Instead, the Ctrl-C aborted the Python
unwinder sniffer and GDB moved on to just use another unwinder.
Fix this by translating a PyExc_KeyboardInterrupt back into a Quit
exception once back in GDB.
This was exposed by the new gdb.base/bp-cmds-continue-ctrl-c.exp
testcase added later in the series.
gdb/ChangeLog:
2017-11-16 Pedro Alves <palves@redhat.com>
* python/py-unwind.c (pyuw_sniffer): Translate
PyExc_KeyboardInterrupt to a GDB Quit exception.
If you have a breakpoint command that re-resumes the target, like:
break foo
commands
> c
> end
and then let the inferior run, hitting the breakpoint, and then press
Ctrl-C at just the right time, between GDB processing the stop at
"foo", and re-resuming the target, you'll hit the QUIT call in
infrun.c:resume.
With this hack, we can reproduce the bad case consistently:
--- a/gdb/inf-loop.c
+++ b/gdb/inf-loop.c
@@ -31,6 +31,8 @@
#include "top.h"
#include "observer.h"
+bool continue_hack;
+
/* General function to handle events in the inferior. */
void
@@ -64,6 +66,8 @@ inferior_event_handler (enum inferior_event_type event_type,
{
check_frame_language_change ();
+ continue_hack = true;
+
/* Don't propagate breakpoint commands errors. Either we're
stopping or some command resumes the inferior. The user will
be informed. */
diff --git a/gdb/infrun.c b/gdb/infrun.c
index d425664..c74b14c 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -2403,6 +2403,10 @@ resume (enum gdb_signal sig)
gdb_assert (!tp->stop_requested);
gdb_assert (!thread_is_in_step_over_chain (tp));
+ extern bool continue_hack;
+
+ if (continue_hack)
+ set_quit_flag ();
QUIT;
The GDB backtrace looks like this:
(top-gdb) bt
...
#3 0x0000000000612e8b in throw_quit(char const*, ...) (fmt=0xaf84a1 "Quit") at src/gdb/common/common-exceptions.c:408
#4 0x00000000007fc104 in quit() () at src/gdb/utils.c:748
#5 0x00000000006a79d2 in default_quit_handler() () at src/gdb/event-top.c:954
#6 0x00000000007fc134 in maybe_quit() () at src/gdb/utils.c:762
#7 0x00000000006f66a3 in resume(gdb_signal) (sig=GDB_SIGNAL_0) at src/gdb/infrun.c:2406
#8 0x0000000000700c3d in keep_going_pass_signal(execution_control_state*) (ecs=0x7ffcf3744e60) at src/gdb/infrun.c:7793
#9 0x00000000006f5fcd in start_step_over() () at src/gdb/infrun.c:2145
#10 0x00000000006f7b1f in proceed(unsigned long, gdb_signal) (addr=18446744073709551615, siggnal=GDB_SIGNAL_DEFAULT)
at src/gdb/infrun.c:3135
#11 0x00000000006ebdd4 in continue_1(int) (all_threads=0) at src/gdb/infcmd.c:842
#12 0x00000000006ec097 in continue_command(char*, int) (args=0x0, from_tty=0) at src/gdb/infcmd.c:938
#13 0x00000000004b5140 in do_cfunc(cmd_list_element*, char*, int) (c=0x2d18570, args=0x0, from_tty=0)
at src/gdb/cli/cli-decode.c:106
#14 0x00000000004b8219 in cmd_func(cmd_list_element*, char*, int) (cmd=0x2d18570, args=0x0, from_tty=0)
at src/gdb/cli/cli-decode.c:1952
#15 0x00000000007f1532 in execute_command(char*, int) (p=0x7ffcf37452b1 "", from_tty=0) at src/gdb/top.c:608
#16 0x00000000004bd127 in execute_control_command(command_line*) (cmd=0x3a88ef0) at src/gdb/cli/cli-script.c:485
#17 0x00000000005cae0c in bpstat_do_actions_1(bpstat*) (bsp=0x37edcf0) at src/gdb/breakpoint.c:4513
#18 0x00000000005caf67 in bpstat_do_actions() () at src/gdb/breakpoint.c:4563
#19 0x00000000006e8798 in inferior_event_handler(inferior_event_type, void*) (event_type=INF_EXEC_COMPLETE, client_data=0x0)
at src/gdb/inf-loop.c:72
#20 0x00000000006f9447 in fetch_inferior_event(void*) (client_data=0x0) at src/gdb/infrun.c:3970
#21 0x00000000006e870e in inferior_event_handler(inferior_event_type, void*) (event_type=INF_REG_EVENT, client_data=0x0)
at src/gdb/inf-loop.c:43
#22 0x0000000000494d58 in remote_async_serial_handler(serial*, void*) (scb=0x3585ca0, context=0x2cd1b80)
at src/gdb/remote.c:13820
#23 0x000000000044d682 in run_async_handler_and_reschedule(serial*) (scb=0x3585ca0) at src/gdb/ser-base.c:137
#24 0x000000000044d767 in fd_event(int, void*) (error=0, context=0x3585ca0) at src/gdb/ser-base.c:188
#25 0x00000000006a5686 in handle_file_event(file_handler*, int) (file_ptr=0x45997d0, ready_mask=1)
at src/gdb/event-loop.c:733
#26 0x00000000006a5c29 in gdb_wait_for_event(int) (block=1) at src/gdb/event-loop.c:859
#27 0x00000000006a4aa6 in gdb_do_one_event() () at src/gdb/event-loop.c:347
#28 0x00000000006a4ade in start_event_loop() () at src/gdb/event-loop.c:371
and when that happens, you end up with GDB's run control in quite a
messed up state. Something like this:
thread_function1 (arg=0x1) at threads.c:107
107 usleep (SLEEP); /* Loop increment. */
Quit
(gdb) c
Continuing.
** nothing happens, time passes..., press ctrl-c again **
^CQuit
(gdb) info threads
Id Target Id Frame
1 Thread 1462.1462 "threads" (running)
* 2 Thread 1462.1466 "threads" (running)
3 Thread 1462.1465 "function0" (running)
(gdb) c
Cannot execute this command while the selected thread is running.
(gdb)
The first "Quit" above is thrown from within "resume", and cancels run
control while GDB is in the middle of stepping over a breakpoint.
with step_over_info_valid_p() true. The next "c" didn't actually
resume anything, because GDB throught that the step-over was still in
progress. It wasn't, because the thread that was supposed to be
stepping over the breakpoint wasn't actually resumed.
So at this point, we press Ctrl-C again, and this time, the default
quit handler is called directly from the event loop
(event-top.c:default_quit_handler -> quit()), because gdb was left
owning the terminal (because the previous resume was cancelled before
we reach target_resume -> target_terminal::inferior()).
Note that the exception called from within resume ends up calling
normal_stop via resume_cleanups. That's very borked though, because
normal_stop is going to re-handle whatever was the last reported
event, possibly even re-running a hook stop... I think that the only
sane way to safely cancel the run control state machinery is to push
an event via handle_inferior_event like all other events.
The fix here does two things, and either alone would fix the problem
at hand:
#1 - passes the terminal to the inferior earlier, so that any QUIT
call from the point we declare the target as running goes to the
inferior directly, protecting run control from unsafe QUIT calls.
#2 - gets rid of this QUIT call in resume and of its related unsafe
resume_cleanups.
Aboout #2, the comment describing resume says:
/* Resume the inferior, but allow a QUIT. This is useful if the user
wants to interrupt some lengthy single-stepping operation
(for child processes, the SIGINT goes to the inferior, and so
we get a SIGINT random_signal, but for remote debugging and perhaps
other targets, that's not true).
but that's a really old comment that predates a lot of fixes to Ctrl-C
handling throughout both GDB core and the remote target, that made
sure that a Ctrl-C isn't ever lost. In any case, if some target
depended on this, a much better fix would be to make the target return
a SIGINT stop out of target_wait the next time that is called.
This was exposed by the new gdb.base/bp-cmds-continue-ctrl-c.exp
testcase added later in the series.
gdb/ChangeLog:
2017-11-16 Pedro Alves <palves@redhat.com>
* infrun.c (resume_cleanups): Delete.
(resume): No longer install a resume_cleanups cleanup nor call
QUIT.
(proceed): Pass the terminal to the inferior.
(keep_going_pass_signal): No longer install a resume_cleanups
cleanup.
If you press Ctrl-C while GDB is processing breakpoint commands the
TRY/CATCH in inferior_event_handler catches the Quit exception and
prints it, and then if the interpreter was running a foreground
execution command, nothing re-adds stdin back in the event loop,
meaning the debug session ends up busted, because the user can't type
anything...
This was exposed by the new gdb.base/bp-cmds-continue-ctrl-c.exp
testcase added later in the series.
gdb/ChangeLog:
2017-11-16 Pedro Alves <palves@redhat.com>
* inf-loop.c (inferior_event_handler): Don't swallow the exception
if the prompt is blocked.
If GDB is inserting a breakpoint and you type Ctrl-C at the exact
"right" time, you'll hit a QUIT call in target_read, and the
breakpoint insertion is cancelled. However, the related TRY/CATCH
code in insert_bp_location does:
CATCH (e, RETURN_MASK_ALL)
{
bp_err = e.error;
bp_err_message = e.message;
}
The problem with that is that a RETURN_QUIT exception has e.error ==
0, which means that further below, in the places that check for error
with:
if (bp_err != GDB_NO_ERROR)
because GDB_NO_ERROR == 0, GDB continues as if the breakpoint was
inserted succesfully, and resumes the inferior. Since the breakpoint
wasn't inserted the inferior runs free, out of our control...
Fix this by having insert_bp_location store a copy of the whole
exception instead of just a error/message parts, and then checking
"gdb_exception::reason" instead.
This was exposed by the new gdb.base/bp-cmds-continue-ctrl-c.exp
testcase added later in the series.
gdb/ChangeLog:
2017-11-16 Pedro Alves <palves@redhat.com>
* breakpoint.c (insert_bp_location): Replace bp_err and
bp_err_message locals by a gdb_exception local.
I expect to use this in more places (in inflow.c) in follow up
patches, but I think this is still good on its own.
gdb/ChangeLog:
2017-11-16 Pedro Alves <palves@redhat.com>
* inflow.c (scoped_ignore_sigttou): New class.
(child_terminal_ours_1, new_tty): Use it.
Currently several tests in gdb.rust/modules.exp fail with
--target_board=native-gdbserver:
Running src/gdb/testsuite/gdb.rust/modules.exp ...
FAIL: gdb.rust/modules.exp: call f3()
FAIL: gdb.rust/modules.exp: call self::f2()
FAIL: gdb.rust/modules.exp: call self::super::f2()
FAIL: gdb.rust/modules.exp: call super::f2()
FAIL: gdb.rust/modules.exp: call self::super::super::f2()
FAIL: gdb.rust/modules.exp: call super::super::f2()
FAIL: gdb.rust/modules.exp: call ::f2()
FAIL: gdb.rust/modules.exp: call extern modules::mod1::f2()
This is because these tests rely on matching inferior output.
However, when testing with gdbserver, inferior output goes to a
separate terminal instead of to gdb's terminal, and so gdb_test won't
cut it, as that is only reading from gdb's pty/gdb_spawn_id:
(gdb) call f3()
(gdb) FAIL: gdb.rust/modules.exp: call f3()
call self::f2()
(gdb) FAIL: gdb.rust/modules.exp: call self::f2()
Fix this by using gdb_test_stdio instead, which handles output coming
out of gdbserver's pty.
Also, skip the tests if the target/board doesn't support inferior I/O
at all.
gdb/ChangeLog:
2017-11-16 Pedro Alves <palves@redhat.com>
* gdb.rust/modules.exp: Skip tests that rely on inferior I/O if
gdb,noinferiorio is set, and use gdb_test_stdio otherwise.
This patch moves endian conversion into the decimal_from_number and
decimal_to_number routines, and removes it from all their callers,
making the code simpler overall. No functional change.
gdb/ChangeLog:
2017-11-16 Ulrich Weigand <uweigand@de.ibm.com>
* target-float.c (decimal_from_number): Add byte_order argument and
call match_endianness. Error if unknown floating-point type.
(decimal_to_number): Add byte_order argument and call match_endianness.
(decimal_from_longest): Update call. Do not call match_endianness.
(decimal_from_ulongest): Likewise.
(decimal_binop): Likewise.
(decimal_is_zero): Likewise.
(decimal_compare): Likewise.
(decimal_convert): Likewise.
This fixes the issue reported by Dmitry Antipov <dantipov@nvidia.com>
here:
https://sourceware.org/ml/gdb/2017-10/msg00048.html
The problem is that GDBserver stops listening to Ctrl-C/interrupt
requests if you disconnect and reconnect back.
Dmitry wrote:
~~~
Currently gdbserver installs SIGIO handler just once, in
initialize_async_io() called from captured_main(), and this handler is
removed when remote_desc is closed in remote_close(). Next, when a
new instance of remote_desc is fetched from accept() and has '\003'
arrived, input_interrupt() is never called because it is not
registered as SIGIO handler.
~~~
The fix here is not remove the SIGIO handler in the first place, thus
going back to the original before-first-connection state.
(I haven't gone back to try it, but I think this was a regression
caused by commit 8b20733984 ("[GDBserver] Block and unblock SIGIO"),
which was what made remote_close remove the signal handler.)
New test included.
gdb/gdbserver/ChangeLog:
2017-11-16 Pedro Alves <palves@redhat.com>
* remote-utils.c (remote_close): Block SIGIO signals instead of
uninstalling the SIGIO handler.
gdb/testsuite/ChangeLog:
2017-11-16 Pedro Alves <palves@redhat.com>
* gdb.server/reconnect-ctrl-c.c: New file.
* gdb.server/reconnect-ctrl-c.exp: New file.
This commit fixes a couple problems with gdb.base/starti.exp, causing
spurious FAILs.
The first is a double-prompt problem:
~~~
(gdb) PASS: gdb.base/starti.exp: hook-stop
starti
[....]
gdb_expect_list pattern: /\$1 = 0/
$1 = 0
gdb_expect_list pattern: //
0x00007ffff7ddcc80 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) # EXPECTED PROMPT
(gdb) PASS: gdb.base/starti.exp: starti # ANOTHER PROMPT!
break main
~~~
This happens because the test uses gdb_test_sequence with no command,
like this:
gdb_test_sequence "" "starti" {
"Program stopped."
"\\$1 = 0"
}
but gdb_test_sequence doesn't have a check for empty command like
gdb_test_multiple does, and so sends "\n" to GDB:
proc gdb_test_sequence { command test_name expected_output_list } {
global gdb_prompt
if { $test_name == "" } {
set test_name $command
}
lappend expected_output_list ""; # implicit ".*" before gdb prompt
send_gdb "$command\n"
return [gdb_expect_list $test_name "$gdb_prompt $" $expected_output_list]
}
"starti" is a no-repeat command, so pressing <ret> just makes another
prompt appear, confusing the following gdb_test/gdb_test_multiple/etc.
Even with that fixed, the testcase is still racy though.
The second problem is that sometimes the "continue" test times out
here:
~~~
continue
Continuing.
$2 = 1
gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/
Breakpoint 1, main () at /home/pedro/src/gdb/testsuite/gdb.base/starti.c:29
29 return 0;
(gdb) gdb_expect_list pattern: //
* hung here *
~~~
The problem is that the too-greedy ".*" trailing match in
gdb_expect_list's pattern ends up consuming GDB's prompt too soon.
Fix that by removing the unnecessary trailing ".*". While at it,
remove all ".*"s to be stricter.
Tested on x86_64 GNU/Linux.
gdb/testsuite/ChangeLog:
2017-11-16 Pedro Alves <palves@redhat.com>
* gdb.base/starti.exp ("continue" test): Remove ".*"s from
pattern.
* lib/gdb.exp (gdb_test_sequence): Don't send empty command to
GDB.
They are not used by GDB nor by GDBserver. This patch removes them.
gdb:
2017-11-16 Yao Qi <yao.qi@linaro.org>
* features/tic6x-c62x.xml: Remove.
* features/tic6x-c64x.xml: Remove.
* features/tic6x-c64xp.xml: Remove.
I can't find a c6x-uclinux c++ compiler, so I use my host g++ to build
tic6x-uclinux GDBserver, and find the following build failures. They are
not target specific, so I believe they are real errors. This patch fixes
them.
../binutils-gdb/gdb/gdbserver/linux-tic6x-low.c:313:34: error: invalid
conversion from 'void*' to 'tic6x_register*' [-fpermissive]
union tic6x_register *regset = buf;
^
../binutils-gdb/gdb/gdbserver/linux-tic6x-low.c: In function 'void tic6x_store_gregset(regcache*, const void*)':
../binutils-gdb/gdb/gdbserver/linux-tic6x-low.c:324:40: error: invalid
conversion from 'const void*' to 'const tic6x_register*' [-fpermissive]
const union tic6x_register *regset = buf;
^
../binutils-gdb/gdb/gdbserver/linux-tic6x-low.c: At global scope:
../binutils-gdb/gdb/gdbserver/linux-tic6x-low.c:359:28: error: redefinition of 'usrregs_info tic6x_usrregs_info'
static struct usrregs_info tic6x_usrregs_info =
^
../binutils-gdb/gdb/gdbserver/linux-tic6x-low.c:186:28: note: 'usrregs_info tic6x_usrregs_info' previously declared here
static struct usrregs_info tic6x_usrregs_info;
^
gdb/gdbserver:
2017-11-16 Yao Qi <yao.qi@linaro.org>
* linux-tic6x-low.c (tic6x_fill_gregset): Cast buf.
(tic6x_store_gregset): Likewise.
(tic6x_usrregs_info): Move it up.
This patch replaces an instance of VEC (const_char_ptr) with
std::vector<const char *>. Tested by running gdb.tui/completion.exp,
which exercises this function.
gdb/ChangeLog:
* tui/tui-win.c (window_name_completer): Replace VEC with
std::vector.
When I run it locally, the test gdb.tui/completion.exp test fails
because of a timeout:
Running /home/emaisin/src/binutils-gdb/gdb/testsuite/gdb.tui/completion.exp ...
FAIL: gdb.tui/completion.exp: completion of layout names: tab completion (timeout)
The problem seems to be this regex, which confirms that after doing
layout<TAB>, "layout" is printed again after the gdb prompt:
-re "^$input_line$"
The problem is that there's a trailing space in the output after
"layout". Since the regex has an anchored end (the $), it doesn't
match. Adding a space fixes the test.
gdb/testsuite/ChangeLog:
* gdb.tui/completionn.exp (test_tab_completion): Add space in
regex.
tdesc_nios2_linux is not used at all. Remove features/nios2-linux.c,
and don't generate it anymore.
gdb:
2017-11-15 Yao Qi <yao.qi@linaro.org>
* features/Makefile (XMLTOC): Remove nios2-linux.xml.
* features/nios2-linux.c: Remove.
* nios2-linux-tdep.c (_initialize_nios2_linux_tdep): Don't call
initialize_tdesc_nios2_linux.
M68HC11_LAST_HARD_REG is 8, but m68hc11 register number is started from 0,
so there are 9 raw registers, but M68HC11_NUM_REGS is 8 by mistake.
My following unit test can find this issue (GDB is built with asan)
=================================================================
==15555==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000113150 at pc 0x51393f bp 0x7fffcec36f60 sp 0x7fffcec36f58
WRITE of size 2 at 0x602000113150 thread T0
#0 0x51393e in m68hc11_pseudo_register_read gdb/m68hc11-tdep.c:320
#1 0xc4b620 in gdbarch_pseudo_register_read(gdbarch*, regcache*, int, unsigned char*) gdb/gdbarch.c:1974
#2 0xddad88 in regcache::cooked_read(int, unsigned char*) gdb/regcache.c:710
#3 0xddff2b in cooked_read_test gdb/regcache.c:1850
#4 0xdf8cfb in selftests::gdbarch_selftest::operator()() const gdb/selftest-arch.c:73
gdb:
2017-11-15 Yao Qi <yao.qi@linaro.org>
* m68hc11-tdep.c (M68HC11_NUM_REGS): Change it to
M68HC11_LAST_HARD_REG + 1.
Ulrich Weigand
Pedro Alves
Simon Marchi
Simon Marchi
Tom Tromey
Joel Brobecker
Phil Muldoon
Yao Qi
Alan Hayward
John Baldwin
Andrew Cagney