| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This second patch introduces mfpr_float_ops, an new implementation
of target_float_ops. This implements precise emulation of target
floating-point formats using the MPFR library. This is then used
to perform operations on types that do not match any host type.
Note that use of MPFR is still not required. The patch adds
a configure option --with-mpfr similar to --with-expat. If use of
MPFR is disabled via the option or MPFR is not available, code will
fall back to current behavior. This means that operations on types
that do not match any host type will be implemented on the host
long double type instead.
A new test case verifies that we can correctly print the largest
__float128 value now.
gdb/ChangeLog:
2017-11-22 Ulrich Weigand <uweigand@de.ibm.com>
* NEWS: Document use of GNU MPFR.
* README: Likewise.
* Makefile.in (LIBMPFR): Add define.
(CLIBS): Add $(LIBMPFR).
* configure.ac: Add --with-mpfr configure option.
* configure: Regenerate.
* config.in: Regenerate.
* target-float.c [HAVE_LIBMPFR]: Include <mpfr.h>.
(class mpfr_float_ops): New type.
(mpfr_float_ops::from_target): Two new overloaded functions.
(mpfr_float_ops::to_target): Likewise.
(mpfr_float_ops::to_string): New function.
(mpfr_float_ops::from_string): Likewise.
(mpfr_float_ops::to_longest): Likewise.
(mpfr_float_ops::from_longest): Likewise.
(mpfr_float_ops::from_ulongest): Likewise.
(mpfr_float_ops::to_host_double): Likewise.
(mpfr_float_ops::from_host_double): Likewise.
(mpfr_float_ops::convert): Likewise.
(mpfr_float_ops::binop): Likewise.
(mpfr_float_ops::compare): Likewise.
(get_target_float_ops): Use mpfr_float_ops if available.
gdb/doc/ChangeLog:
2017-11-22 Ulrich Weigand <uweigand@de.ibm.com>
* gdb.texinfo (Requirements): Document use of GNU MPFR.
gdb/testsuite/ChangeLog:
2017-11-22 Ulrich Weigand <uweigand@de.ibm.com>
* gdb.base/float128.c (large128): New variable.
* gdb.base/float128.exp: Add test to print largest __float128 value.
|
|
Prepare for using MPFR to implement floating-point arithmetic by
refactoring the way host floating-point arithmetic is currently used.
In particular, fix the following two problems that cause different
(and incorrect) results due to using host arithmetic:
- Current processing always uses host "long double", and then converts
back to the actual target format. This may introduce rounding errors.
- Conversion of FP values to LONGEST simply does a host C++ type cast.
However the result of such a cast is undefined if the source value
is outside the representable range. MPFR always has defined behavior
here (returns the minimum or maximum representable value).
To fix the first issue, I've now created not just one set of routines
using host FP arithmetic (on long double), but instead three different
sets of routines, one each for host float, double, and long double.
Operations can then be performed in the desired type directly, avoiding
the extra rounding step. Using C++ templates, the three sets can all
share the same source code without duplication.
To fix the second issue, I'm simply enforcing the same conversion rule
(which makes sense anyway) when converting out-of-range values from
FP to LONGEST.
To contain the code complexity with the variety of options now possible,
I've created a new class "target_float_ops". There are a total of five
separate implementations of this:
host_float_ops<float> Implemented via host FP in given type
host_float_ops<double>
host_float_ops<long double>
mpfr_float_ops Implemented via MPFR if available
decimal_float_ops Implemented via libdecnumber
Note instead of using the DOUBLEST define, this always just uses the
"long double" data type. But since we now require C++11 anyway, this
type must in any case be avaialble unconditionally.
Most target floating-point operations simply dispatch to a (virtual)
member routine of this class. Which implementation to choose is
determined from the target types involved, and whether they match
some host type or not. E.g. any operation on a single type that
matches a host type is performed in that type. Operations involving
two types that both match host types are performed in the larger one
(according to C/C++ implicit conversion rules). Operations that
involve any type that does not match a host type are performed using
MPFR. (And of course operations involving decimal FP are performed
using libdecnumber.)
This first patch implements the refactoring of target-float.c as
described above, introduing the host_float_ops and decimal_float_ops
classes, and using them. Use of MPFR is introduced in the second patch.
A bit of special-case handling code is moved around to as to avoid
code duplication between host_float_ops and mpfr_float_ops.
Note that due to the changes mentioned above, I've had to update (fix)
the floating-point register values tested in the gdb.arch/vsx-regs.exp
test case. (The new values now work both with host arithmetic and MPFR.)
gdb/ChangeLog:
2017-11-22 Ulrich Weigand <uweigand@de.ibm.com>
* target-float.c: Do not include <math.h>.
Include <cmath> and <limits>.
(DOUBLEST): Do not define.
(class target_float_ops): New type.
(class host_float_ops): New templated type.
(class decimal_float_ops): New type.
(floatformat_to_doublest): Rename to ...
(host_float_ops<T>::from_target): ... this. Use template type T
instead of DOUBLEST. Use C++ math routines. Update recursive calls.
(host_float_ops<T>::from_target): New overload using a type argument.
(floatformat_from_doublest): Rename to ...
(host_float_ops<T>::to_target): ... this. Use template type T
instead of DOUBLEST. Use C++ math routines. Update recursive calls.
(host_float_ops<T>::to_target): New overload using a type argument.
(floatformat_printf_format): New function.
(struct printf_length_modifier): New templated type.
(floatformat_to_string): Rename to ...
(host_float_ops<T>::to_string): ... this. Use type instead of
floatformat argument. Use floatformat_printf_format and
printf_length_modifier. Remove special handling of invalid numbers,
infinities and NaN (moved to target_float_to_string).
(struct scanf_length_modifier): New templated type.
(floatformat_from_string): Rename to ...
(host_float_ops<T>::from_string): ... this. Use type instead of
floatformat argument. Use scanf_length_modifier.
(floatformat_to_longest): Rename to ...
(host_float_ops<T>::to_longest): ... this. Use type instead of
floatformat argument. Handle out-of-range values deterministically.
(floatformat_from_longest): Rename to ...
(host_float_ops<T>::from_longest): ... this. Use type instead of
floatformat argument.
(floatformat_from_ulongest): Rename to ...
(host_float_ops<T>::from_ulongest): ... this. Use type instead of
floatformat argument.
(floatformat_to_host_double): Rename to ...
(host_float_ops<T>::to_host_double): ... this. Use type instead of
floatformat argument.
(floatformat_from_host_double): Rename to ...
(host_float_ops<T>::from_host_double): ... this. Use type instead of
floatformat argument.
(floatformat_convert): Rename to ...
(host_float_ops<T>::convert): ... this. Use type instead of
floatformat arguments. Remove handling of no-op conversions.
(floatformat_binop): Rename to ...
(host_float_ops<T>::binop): ... this. Use type instead of
floatformat arguments.
(floatformat_compare): Rename to ...
(host_float_ops<T>::compare): ... this. Use type instead of
floatformat arguments.
(match_endianness): Use type instead of length/byte_order arguments.
(set_decnumber_context): Likewise.
(decimal_from_number): Likewise. Update calls.
(decimal_to_number): Likewise.
(decimal_is_zero): Likewise. Update calls. Move to earlier in file.
(decimal_float_ops::to_host_double): New dummy function.
(decimal_float_ops::from_host_double): Likewise.
(decimal_to_string): Rename to ...
(decimal_float_ops::to_string): ... this. Use type instead of
length/byte_order arguments. Update calls.
(decimal_from_string): Rename to ...
(decimal_float_ops::from_string): ... this. Use type instead of
length/byte_order arguments. Update calls.
(decimal_from_longest): Rename to ...
(decimal_float_ops::from_longest): ... this. Use type instead of
length/byte_order arguments. Update calls.
(decimal_from_ulongest): Rename to ...
(decimal_float_ops::from_ulongest): ... this. Use type instead of
length/byte_order arguments. Update calls.
(decimal_to_longest): Rename to ...
(decimal_float_ops::to_longest): ... this. Use type instead of
length/byte_order arguments. Update calls.
(decimal_binop): Rename to ...
(decimal_float_ops::binop): ... this. Use type instead of
length/byte_order arguments. Update calls.
(decimal_compare): Rename to ...
(decimal_float_ops::compare): ... this. Use type instead of
length/byte_order arguments. Update calls.
(decimal_convert): Rename to ...
(decimal_float_ops::convert): ... this. Use type instead of
length/byte_order arguments. Update calls.
(target_float_same_category_p): New function.
(target_float_same_format_p): Likewise.
(target_float_format_length): Likewise.
(enum target_float_ops_kind): New type.
(get_target_float_ops_kind): New function.
(get_target_float_ops): Three new overloaded functions.
(target_float_is_zero): Update call.
(target_float_to_string): Add special handling of invalid numbers,
infinities and NaN (moved from floatformat_to_string). Use
target_float_ops callback.
(target_float_from_string): Use target_float_ops callback.
(target_float_to_longest): Likewise.
(target_float_from_longest): Likewise.
(target_float_from_ulongest): Likewise.
(target_float_to_host_double): Likewise.
(target_float_from_host_double): Likewise.
(target_float_convert): Add special case for no-op conversions.
Use target_float_ops callback.
(target_float_binop): Use target_float_ops callback.
(target_float_compare): Likewise.
gdb/testsuite/ChangeLog:
2017-11-22 Ulrich Weigand <uweigand@de.ibm.com>
* gdb.arch/vsx-regs.exp: Update register content checks.
|
|
Recent gcc 8 trunk emits the warning below,
../../binutils-gdb/gdb/python/py-gdb-readline.c:79:15: error: ‘char* strncpy(char*, const char*, size_t)’ output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
strncpy (q, p, n);
~~~~~~~~^~~~~~~~~
../../binutils-gdb/gdb/python/py-gdb-readline.c:73:14: note: length computed here
n = strlen (p);
~~~~~~~^~~
gdb:
2017-11-22 Yao Qi <yao.qi@linaro.org>
* python/py-gdb-readline.c (gdbpy_readline_wrapper): Use strcpy.
|
|
Recent gcc 8 trunk emits the warning below,
../../../binutils-gdb/gdb/gdbserver/remote-utils.c:1204:14: error: ‘char* strncpy(char*, const char*, size_t)’ output truncated before terminating nul copying 6 bytes from a string of the same length [-Werror=stringop-truncation]
strncpy (buf, "watch:", 6);
~~~~~~~~^~~~~~~~~~~~~~~~~~
../../binutils-gdb/gdb/cli/cli-decode.c:1118:15: error: ‘char* strncpy(char*, const char*, size_t)’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
strncpy (cmdtype1 + 1, cmdtype, len - 1);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../binutils-gdb/gdb/cli/cli-decode.c:1110:16: note: length computed here
len = strlen (cmdtype);
~~~~~~~^~~~~~~~~
../../binutils-gdb/gdb/cli/cli-decode.c:1120:15: error: ‘char* strncpy(char*, const char*, size_t)’ specified bound depends on the length of the source argument [-Werror=stringop-overflow=]
strncpy (cmdtype2, cmdtype, len - 1);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../binutils-gdb/gdb/cli/cli-decode.c:1110:16: note: length computed here
len = strlen (cmdtype);
~~~~~~~^~~~~~~~~
../../binutils-gdb/gdb/cp-namespace.c:1071:11: error: ‘char* strncpy(char*, const char*, size_t)’ output truncated before terminating nul copying 2 bytes from a string of the same length [-Werror=stringop-truncation]
strncpy (full_name + scope_length, "::", 2);
~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This patch fixes it by using memcpy instead of strncpy.
gdb:
2017-11-22 Yao Qi <yao.qi@linaro.org>
* cli/cli-decode.c (help_list): Use memcpy instead of strncpy.
* cp-namespace.c (cp_lookup_transparent_type_loop): Likewise.
gdb/gdbserver:
2017-11-22 Yao Qi <yao.qi@linaro.org>
* remote-utils.c (prepare_resume_reply): Use memcpy.
|
|
When debugging a program using a ravenscar runtime, the thread
layer sometimes gets confused, and even missing some threads.
This was traced to an assumption that ravenscar_wait was making,
which is that calling the "to_wait" target_ops method would
set the inferior_ptid, so that we could then use that assumption
to update our thread_list and current ptid. However, this has not
been the case for quite a while now. This patch fixes the problem
by assigning inferior_ptid the ptid returned by "to_wait".
gdb/ChangeLog:
* ravenscar-thread.c (ravenscar_wait): Update inferior ptid
with event ptid from the lower layer before doing the
ravenscar-specific update.
|
|
Connecting to a TSIM simulator over the remote protocol causes GDB
to crash with the following failed assertion:
(gdb) tar remote :1234
Remote debugging using :1234
/[...]/gdb/ravenscar-thread.c:182: internal-error: ravenscar_update_inferior_ptid: Assertion `!is_ravenscar_task (inferior_ptid)' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) y
What happens is the following. Upon connection to the target, GDB
sends a 'qfThreadInfo' query, which is the query asking the target
for the ID of the first thread, and TSIM replies 'm0':
Sending packet: $qfThreadInfo#bb...Ack
Packet received: m0
As a result of this, GDB takes the '0' as the TID, and because of it,
constructs a ptid whose value is {42000, 0, 0}. This trips our
!is_ravenscar_task check, because all it does to identify threads
corresponding to ravenscar tasks is that their lwp is null, because
that's how we construct their ptid.
But this is unfortunatly not sufficient when debugging with TSIM,
because the thread ID that TSIM returns causes the creation of
a ptid whose lwp is zero, which matches the current identification
scheme and yet is clearly not a ravenscar task.
The fix is to also make sure that the ptid's tid field is nonzero.
gdb/ChangeLog:
* ravenscar-thread.c (is_ravenscar_task): Also verify that
the ptid's TID is nonzero.
|
|
Trying to debug a program using a stripped version of the ravenscar
runtime, we can get the following error:
(gdb) cont
Continuing.
Cannot find Ada_Task_Control_Block type. Aborting
This is because the ravenscar-thread layer makes the assumption that
the runtime is built the way we expect it, meaning that the Ada tasking
units we rely on for Ada tasking debugging, are built with debugging
information, and that this debug information has not been stripped from
the runtime.
When this assumption is not true, resuming such a program can trigger
the error above, which then leads GDB a little confused. For instance,
we can see things like:
(gdb) bt
Target is executing.
This patch fixes the issue by disabling the ravenscar thread layer
if we detect that the runtime is missing some of the debugging info
we need in order to support Ada task debugging. This is the best
we can do, as the ravenscar-thread layer actually depends on the
ada-tasks layer to implement thread debugging.
gdb/ChangeLog:
* ada-lang.h (ada_get_tcb_types_info): Add declaration.
* ada-tasks.c (ada_get_tcb_types_info): Renames get_tcb_types_info.
Make non-static. Change return type to char *. Adjust code
accordingly. Rewrite the function's documentation.
(read_atcb): Adjust call to get_tcb_types_info accordingly.
* ravenscar-thread.c (ravenscar_inferior_created): Check that
we have enough debugging information in the runtime to support
Ada task debugging before we enable the ravenscar-thread layer.
|
|
This patch reworks the ravenscar-thread layer to remove the
assumption that the target only has 1 CPU. In particular,
when connected to a QEMU target over the remote protocol,
QEMU reports each CPU as one thread. This patch adapts
the ravenscar-thread layer to this, and adds a large comment
explaining the general design of this unit.
gdb/ChangeLog:
* ada-lang.h (ada_get_task_info_from_ptid): Add declaration.
* ada-tasks.c (ada_get_task_info_from_ptid): New function.
* ravenscar-thread.c: Add into comment.
(base_magic_null_ptid): Delete.
(base_ptid): Change documentation.
(ravenscar_active_task): Renames ravenscar_running_thread.
All callers updated throughout.
(is_ravenscar_task, ravenscar_get_thread_base_cpu): New function.
(ravenscar_task_is_currently_active): Likewise.
(get_base_thread_from_ravenscar_task): Ditto.
(ravenscar_update_inferior_ptid): Adjust to handle multiple CPUs.
(ravenscar_runtime_initialized): Likewise.
(get_running_thread_id): Add new parameter "cpu". Adjust
implementation to handle this new parameter.
(ravenscar_fetch_registers): Small adjustment to use
is_ravenscar_task and ravenscar_task_is_currently_active in
order to decide whether to use the target beneath or this
module's arch_ops.
(ravenscar_store_registers, ravenscar_prepare_to_store): Likewise.
(ravenscar_stopped_by_sw_breakpoint): Use
get_base_thread_from_ravenscar_task to get the underlying
thread, rather than using base_ptid.
(ravenscar_stopped_by_hw_breakpoint, ravenscar_stopped_by_watchpoint)
(ravenscar_stopped_data_address, ravenscar_core_of_thread):
Likewise.
(ravenscar_inferior_created): Do not set base_magic_null_ptid.
|
|
At the user level, this patch enhances the debugger to print the ID
of the base CPU a task is running on:
(gdb) info task 3
Ada Task: 0x13268
Name: raven1
Thread: 0x13280
LWP: 0
!!!-> Base CPU: 1
No parent
Base Priority: 127
State: Runnable
This new field is only printed when the base CPU is nonzero or, in
other words, if the base CPU info is being provided by the runtime.
For instance, on native systems, where threads/processes can "jump"
from CPU to CPU, the info is not available, and the output of the
command above then remains unchanged.
At the internal level, the real purpose of this change is to prepare
the way for ravenscar-thread to start handling SMP systems. For that,
we'll need to know which CPU each task is running on... More info
on that in the commit that actually adds support for it.
gdb/ChangeLog:
* ada-lang.h (struct ada_task_info) <base_cpu>: New field.
* ada-lang.c (struct atcb_fieldno) <base_cpu>: New field.
(get_tcb_types_info): Set fieldnos.base_cpu.
(read_atcb): Set task_info->base_cpu.
(info_task): Print "Base CPU" info if set by runtime.
|
|
We have noticed a regression in our watchpoint support when debugging
through the remote protocol a program running on a bare metal platform,
when the program uses what we call the Ravenscar Runtime.
This runtime is a subset of the Ada runtime defined by the Ravenscar
Profile. One of the nice things about this runtime is that it provides
tasking, which is equivalent to the concept of threads in C (it is
actually often mapped to threads, when available). For bare metal
targets, however, there is no OS, and therefore no thread layer.
What we did, then, was add a ravenscar-thread layer, which has insider
knowledge of the runtime to get the list of threads, but also all
necessary info to perform thread switching.
For the record, the commit which caused the regression is:
commit 799a2abe613be0645b84f5aaa050f2f91e6ae3f7
Date: Mon Nov 30 16:05:16 2015 +0000
Subject: remote: stop reason and watchpoint data address per thread
Running local-watch-wrong-thread.exp with "maint set target-non-stop
on" exposes that gdb/remote.c only records whether the target stopped
for a breakpoint/watchpoint plus the watchpoint data address *for the
last reported remote event*. But in non-stop mode, we need to keep
that info per-thread, as each thread can end up with its own
last-status pending.
Our testcase is very simple. We have a package defining a global
variable named "Watch"...
package Pck is
Watch : Integer := 1974;
end Pck;
... and a main subprogram which changes its value
procedure Foo is
begin
Pck.Watch := Pck.Watch + 1;
end Foo;
To reproduce, we built our program as usual, started it in QEMU,
and then connected GDB to QEMU...
(gdb) target remote :4444
(gdb) break _ada_foo
(gdb) cont <--- this is to make sure the program is started
and the variable we want to watch is initialized
... at which point we try to use a watchpoint on our global variable:
(gdb) watch watch
... but, upon resuming the execution with a "cont", we expected to
get a watchpoint-hit notification, such as...
(gdb) cont
Hardware watchpoint 2: watch
Old value = 1974
New value = 1975
0xfff00258 in foo () at /[...]/foo.adb:6
6 end Foo;
... but unfortunately, we get a SIGTRAP instead:
(gdb) cont
Program received signal SIGTRAP, Trace/breakpoint trap.
foo () at /[...]/foo.adb:6
6 end Foo;
What happens is that, on the one hand, the change in remote.c
now stores the watchpoint-hit notification info in the thread
that received it; and on the other hand, we have a ravenscar-thread
layer which manages the thread list on top of the remote protocol
layer. The two of them get disconnected, and this eventually results
in GDB not realizing that we hit a watchpoint. Below is how:
First, once connected and just before inserting our watchpoint,
we have the ravenscar-thread layer which built the list of threads
by extracting some info from inferior memory, giving us the following
two threads:
(gdb) info threads
Id Target Id Frame
1 Thread 0 "0Q@" (Ravenscar task) foo () at /[...]/foo.adb:5
* 2 Thread 0x24618 (Ravenscar task) foo () at /[...]/foo.adb:5
The first thread is the only thread QEMU told GDB about. The second
one is a thread that the ravenscar-thread added. QEMU has now way
to know about those threads, since they are really embedded inside
the program; that's why we have the ravenscar layer, which uses
inside-knowledge to extract the list of threads.
Next, we insert a watchpoint, which applies to all threads. No problem
so far.
Then, we continue; meaning that GDB sends a Z2 packet to QEMU to
get the watchpoint inserted, then a vCont to resume the program's
execution. The program hits the watchpoints, and thererfore QEMU
reports it back:
Packet received: T05thread:01;watch:000022c4;
Since QEMU knows about one thread and one thread only, it stands
to reason that it would say that the event applies to thread:01,
which is our first thread in the "info threads" listing. That
thread has a ptid of {42000, lwp=1, tid=0}.
This is where Pedro's change kicks in: Seeing this event, and
having determined that the event was reported for thread 01,
and therefore ptid {42000, lwp=1, tid=0}, it saves the watchpoint-hit
event info in the private area of that thread/ptid. Once this is
done, remote.c's event-wait layer returns.
Enter the ravenscar-thread layer of the event-wait, which does
a little dance to delegate the wait to underlying layers with
ptids that those layers know about, and then when the target_beneath's
to_wait is done, tries to figure out which thread is now the active
thread. The code looks like this:
1. inferior_ptid = base_ptid;
2. beneath->to_wait (beneath, base_ptid, status, 0);
3. [...]
4. ravenscar_update_inferior_ptid ();
5.
6. return inferior_ptid;
Line 1 is where we reset inferior_ptid to the ptid that
the target_beneath layer knows about, allowing us to then
call its to_wait implementation (line 2). And then, upon
return, we call ravenscar_update_inferior_ptid, which reads
inferior memory to determine which thread is actually active,
setting inferior_ptid accordingly. Then we return that
inferior_ptid (which, again, neither QEMU and therefore nor
the remote.c layer knows about).
Upon return, we eventually arrive to the part where we try
to handle the inferior event: we discover that we got a SIGTRAP
and, as part of its handling, we call watchpoints_triggered,
which calls target_stopped_by_watchpoint, which eventually
remote_stopped_by_watchpoint, where Pedro's change kicks in
again:
struct thread_info *thread = inferior_thread ();
return (thread->priv != NULL
&& thread->priv->stop_reason == TARGET_STOPPED_BY_WATCHPOINT);
Because the ravenscar-thread layer changed the inferior_ptid
to the ptid of the active thread, inferior_thread now returns
the private data of that thread. This is not the thread that
QEMU reported the watchpoint-hit on, and thus, the function
returns "no watchpoint hit, mister". Hence GDB not understanding
the SIGTRAP, thus reporting it verbatim.
The way we chose to fix the issue is by making sure that the
ravenscar-thread layer doesn't let the remote layer be called
with inferior_ptid being set to a thread that the remote layer
does not know about.
gdb/ChangeLog:
* ravenscar-thread.c (ravenscar_stopped_by_sw_breakpoint)
(ravenscar_stopped_by_hw_breakpoint, ravenscar_stopped_by_watchpoint)
(ravenscar_stopped_data_address, ravenscar_core_of_thread):
New functions.
(init_ravenscar_thread_ops): Set the to_stopped_by_sw_breakpoint,
to_stopped_by_hw_breakpoint, to_stopped_by_watchpoint,
to_stopped_data_address and to_core_of_thread fields of
ravenscar_ops.
|
|
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.
gdb/gdbserver/ChangeLog:
* linux-low.c (need_step_over_p): Return bool, remove dummy
argument.
(linux_resume, proceed_all_lwps): Use find_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.
|
|
Simply replace with find_thread.
gdb/gdbserver/ChangeLog:
* linux-low.c (stuck_in_jump_pad_callback): Change prototype,
return bool, remove data argument.
(linux_stabilize_threads): Use find_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.
|
|
Now that all its usages are removed, we can get rid of DEF_VEC_I (int).
gdb/ChangeLog:
* common/gdb_vecs.h (DEF_VEC_I (int)): Remove.
|
|
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)
|
|
gdb/ChangeLog:
* ada-lang.c (ada_value_cast): Remove parameter "noside".
Update all callers.
|
|
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 8b2073398477 ("[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.
|
|
gdb/Changelog
2017-11-16 Phil Muldoon <pmuldoon@redhat.com>
* python/python.c (gdbpy_rbreak): New function.
* NEWS: Document Python rbreak feature.
testsuite/Changelog
2017-11-16 Phil Muldoon <pmuldoon@redhat.com>
* gdb.python/py-rbreak.exp: New file.
* gdb.python/py-rbreak.c: New file.
* gdb.python/py-rbreak-func2.c: New file.
doc/Changelog
2017-11-16 Phil Muldoon <pmuldoon@redhat.com>
* python.texi (Basic Python): Add rbreak documentation.
|
|
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.
|
|
gdbserver/
* tdesc.c (tdesc_get_features_xml): Allow null osabi.
|
