This patch adds some sanity check that reinsert breakpoints must be
there when doing step-over on software single step target. The check
triggers an assert when running forking-threads-plus-breakpoint.exp
on arm-linux target,
gdb/gdbserver/linux-low.c:4714: A problem internal to GDBserver has been detected.^M
int finish_step_over(lwp_info*): Assertion `has_reinsert_breakpoints ()' failed.
the error happens when GDBserver has already resumed a thread of
process A for step-over (and wait for it hitting reinsert breakpoint),
but receives detach request for process B from GDB, which is shown in
the backtrace below,
(gdb) bt
#2 0x000228aa in finish_step_over (lwp=0x12bbd98) at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/linux-low.c:4703
#3 0x00025a50 in finish_step_over (lwp=0x12bbd98) at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/linux-low.c:4749
#4 complete_ongoing_step_over () at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/linux-low.c:4760
#5 linux_detach (pid=25228) at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/linux-low.c:1503
#6 0x00012bae in process_serial_event () at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/server.c:3974
#7 handle_serial_event (err=<optimized out>, client_data=<optimized out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/server.c:4347
#8 0x00016d68 in handle_file_event (event_file_desc=<optimized out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/event-loop.c:429
#9 0x000173ea in process_event () at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/event-loop.c:184
#10 start_event_loop () at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/event-loop.c:547
#11 0x0000aa2c in captured_main (argv=<optimized out>, argc=<optimized out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/server.c:3719
#12 main (argc=<optimized out>, argv=<optimized out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/server.c:3804
the sanity check tries to find the reinsert breakpoint from process B,
but nothing is found. It is wrong, we need to search in process A,
since we started step-over of a thread of process A.
(gdb) p lwp->thread->entry.id
$3 = {pid = 25120, lwp = 25131, tid = 0}
(gdb) p current_thread->entry.id
$4 = {pid = 25228, lwp = 25228, tid = 0}
This patch switched current_thread to the thread we are doing step-over
in finish_step_over.
gdb/gdbserver:
2016-06-17 Yao Qi <yao.qi@linaro.org>
* linux-low.c (maybe_hw_step): New function.
(linux_resume_one_lwp_throw): Call maybe_hw_step.
(finish_step_over): Switch current_thread to lwp temporarily,
and assert has_reinsert_breakpoints returns true.
(proceed_one_lwp): Call maybe_hw_step.
* mem-break.c (has_reinsert_breakpoints): New function.
* mem-break.h (has_reinsert_breakpoints): Declare.
Type lengths are unsigned, so they are always greater than or equal to
zero. A check against the length of 'tgt_type' is retained to prevent
dividing by zero.
gdb/ChangeLog:
* v850-tdep.c (v850_use_struct_convention): Trim type length checks.
If the instruction in this case does not include an RA field, then 'ra'
is used uninitialized. Use the same idiom used elsewhere in this file of
initializing ra to zero before check for an RA field.
gdb/ChangeLog:
* rs6000-tdep.c (ppc_process_record_op31): Initialize ra.
If a target does not support making function calls from GDB then in a
number of test files, we currently report an XFAIL and skip some, or all
of the tests. This commit changes the XFAIL to an UNSUPPORTED as this
seems more appropriate in these cases.
Some of the tests used bug ID 2416 to be reported in the XFAIL. In the
current GDB bugzilla bug 2416 has nothing to do with calling target
functions from GDB.
gdb/testsuite/ChangeLog:
* gdb.base/call-ar-st.exp: Report unsupported rather than xfail
for unsupported target features.
* gdb.base/call-rt-st.exp: Likewise.
* gdb.base/call-sc.exp: Likewise.
* gdb.base/call-signal-resume.exp: Likewise.
* gdb.base/call-strs.exp: Likewise.
* gdb.base/callexit.exp: Likewise.
* gdb.base/callfuncs.exp: Likewise.
* gdb.base/nodebug.exp: Likewise.
* gdb.base/printcmds.exp: Likewise.
* gdb.base/ptype.exp: Likewise.
* gdb.base/structs.exp: Likewise.
* gdb.base/unwindonsignal.exp: Likewise.
* gdb.cp/gdb2495.exp: Likewise.
* gdb.cp/templates.exp: Likewise.
* gdb.cp/virtfunc.exp: Likewise.
* gdb.threads/hand-call-in-threads.exp: Likewise.
* gdb.threads/interrupted-hand-call.exp: Likewise.
* gdb.threads/thread-unwindonsignal.exp: Likewise.
While working on the Rust support, I happened to notice that arch_type
and related functions take "char *" arguments, where "const char *"
would be more correct. This patch fixes this oversight. Tested by
rebuilding.
2016-06-10 Tom Tromey <tom@tromey.com>
* gdbtypes.c (arch_type, arch_integer_type, arch_character_type)
(arch_boolean_type, arch_float_type, arch_complex_type)
(arch_flags_type, append_flags_type_field)
(append_flags_type_flag, arch_composite_type)
(append_composite_type_field_raw)
(append_composite_type_field_aligned)
(append_composite_type_field): Make "name" parameter const.
* gdbtypes.h (arch_type, arch_integer_type, arch_character_type)
(arch_boolean_type, arch_float_type, arch_complex_type)
(append_composite_type_field, append_composite_type_field_aligned)
(append_composite_type_field_raw, arch_flags_type)
(append_flags_type_field, append_flags_type_flag): Constify.
PR rust/20110 concerns the type of an integer constant that is too
large for "i32", the default integer type. This patch changes the
type of such a constant to i64. This is important because such values
are often addresses, so truncating them by default is unfriendly.
Built and regtested on x86-64 Fedora 23.
2016-06-10 Tom Tromey <tom@tromey.com>
PR rust/20110:
* rust-exp.y (lex_number): Don't truncate large numbers to i32.
2016-06-10 Tom Tromey <tom@tromey.com>
PR rust/20110:
* gdb.rust/expr.exp: Add test for integer constant larger than
i32.
I noticed that the rust-exp handling in the Makefile differed from
that of other .y files. I believe I noticed this by seeing a stray
"rm" in the build log.
This patch changes the Makefile to bring the rust-exp handling in line
with that of other .y files.
2016-06-10 Tom Tromey <tom@tromey.com>
* Makefile.in (COMMON_OBS): Remove rust-exp.o.
(YYFILES): Add rust-exp.c.
(YYOBJ): Add rust-exp.o.
(local-maintainer-clean): Remove rust-exp.c.
Non-local references in nested functions are usually implemented
by using DWARF static link. This feature was added
with commit 63e43d3aed
(DWARF: handle non-local references in nested functions) but
a testcase was missing in Fortran.
2016-06-10 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Testsuite/Changelog:
* gdb.fortran/nested-funcs.exp: New.
* gdb.fortran/nested-funcs.f90: New.
This change adds support for specifying a negative repeat count to
all the formats of the 'x' command to examine memory backward.
A new testcase 'examine-backward' is added to cover this new feature.
Here's the example output from the new feature:
<format 'i'>
(gdb) bt
#0 Func1 (n=42, p=0x40432e "hogehoge") at main.cpp:5
#1 0x00000000004041fa in main (argc=1, argv=0x7fffffffdff8) at main.cpp:19
(gdb) x/-4i 0x4041fa
0x4041e5 <main(int, char**)+11>: mov %rsi,-0x10(%rbp)
0x4041e9 <main(int, char**)+15>: lea 0x13e(%rip),%rsi
0x4041f0 <main(int, char**)+22>: mov $0x2a,%edi
0x4041f5 <main(int, char**)+27>: callq 0x404147
<format 'x'>
(gdb) x/-4xw 0x404200
0x4041f0 <main(int, char**)+22>: 0x00002abf 0xff4de800 0x76e8ffff 0xb8ffffff
(gdb) x/-4
0x4041e0 <main(int, char**)+6>: 0x7d8910ec 0x758948fc 0x358d48f0 0x0000013e
gdb/ChangeLog:
* NEWS: Mention that GDB now supports a negative repeat count in
the 'x' command.
* printcmd.c (decode_format): Allow '-' in the parameter
"string_ptr" to accept a negative repeat count.
(find_instruction_backward): New function.
(read_memory_backward): New function.
(integer_is_zero): New function.
(find_string_backward): New function.
(do_examine): Use new functions to examine memory backward.
(_initialize_printcmd): Mention that 'x' command supports a negative
repeat count.
gdb/doc/ChangeLog:
* gdb.texinfo (Examining Memory): Document negative repeat
count in the 'x' command.
gdb/testsuite/ChangeLog:
* gdb.base/examine-backward.c: New file.
* gdb.base/examine-backward.exp: New file.
PR python/19819 concerns some unused global variables in
py-xmethods.c. This patch deletes the unused globals.
Tested by rebuilding.
2016-06-09 Tom Tromey <tom@tromey.com>
PR python/19819:
* python/py-xmethods.c (invoke_method_name)
(py_get_result_type_method_name, py_invoke_method_name): Remove.
(gdbpy_initialize_xmethods): Don't initialize
py_invoke_method_name, py_get_result_type_method_name.
Eclipse CDT now supports enabling execution recording using two methods
(full and btrace) and both formats for btrace (bts and pt). In the
event that recording is enabled behind the back of the GUI (by the user
on the command line, or a script), we need to know which method/format
are being used, so it can be correctly reflected in the interface. This
patch adds this information to the =record-started async record.
Before:
=record-started,thread-group="i1"
After:
=record-started,thread-group="i1",method="btrace",format="bts"
=record-started,thread-group="i1",method="btrace",format="pt"
=record-started,thread-group="i1",method="full"
The "format" field is only present when the current method supports
multiple formats (only the btrace method as of now).
gdb/ChangeLog:
* NEWS: Mention the new fields in =record-started.
* common/btrace-common.h (btrace_format_short_string): New function
declaration.
* common/btrace-common.c (btrace_format_short_string): New
function.
* mi/mi-interp.c (mi_record_changed): Output method and format
fields in the =record-started record.
* record-btrace.c (record_btrace_open): Adapt record_changed
notification.
* record-full.c (record_full_open): Likewise.
* record.c (cmd_record_stop): Likewise.
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Async Records): Document method and
format fields in =record-started.
* observer.texi (record_changed): Add method and format
parameters.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-record-changed.exp: Adjust =record-started output
matching.
gdb/ChangeLog:
2016-06-02 Jon Turney <jon.turney@dronecode.org.uk>
* windows-nat.c (handle_output_debug_string): Return type of
gdb_signal_from_host() is gdb_signal, not an int.
(windows_get_exec_module_filename): Add pointer casts for C++.
gdb/gdbserver/ChangeLog:
2016-06-02 Jon Turney <jon.turney@dronecode.org.uk>
* win32-low.c (win32_create_inferior): Add pointer casts for C++.
This fixes PR python/18984.
The bug is that gdbpy_solib_name uses GDB_PY_LL_ARG, whereas it should
use GDB_PY_LLU_ARG to avoid overflow.
Built and tested on x86-64 Fedora 23.
2016-06-02 Tom Tromey <tom@tromey.com>
PR python/18984:
* python/python.c (gdbpy_solib_name): Use GDB_PY_LLU_ARG.
2016-06-02 Tom Tromey <tom@tromey.com>
PR python/18984:
* gdb.python/py-shared.exp: Add solib_name test.
... and fix Ctrl-C races.
The current remote-fileio.c SIGINT/EINTR code can lose Ctrl-C --
there's a period where SIG_IGN is installed as signal handler, for
example.
Since:
- remote.c no longer installs a custom SIGINT handler;
- The current remote-fileio.c SIGINT handler is basically the same as
the default SIGINT handler (event-top.c:handle_sigint), in
principle, except that instead of setting the quit flag, it sets a
separate flag.
I think we should be able to completely remove the remote-fileio.c
SIGINT handler, and centralize on the quit flag, thus fixing the
Ctrl-C race.
gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <palves@redhat.com>
* remote-fileio.c (remote_fio_ctrl_c_flag, remote_fio_sa)
(remote_fio_osa)
(remote_fio_ofunc, remote_fileio_sig_init, remote_fileio_sig_set)
(remote_fileio_sig_exit, remote_fileio_ctrl_c_signal_handler):
Delete.
(remote_fileio_o_quit_handler): New global.
(remote_fileio_quit_handler): New function.
(remote_fileio_reply): Check the quit flag instead of the custom
'remote_fio_ctrl_c_flag' flag. Restore the quit handler instead
of changing the SIGINT handler.
(do_remote_fileio_request): Override the quit handler instead of
changing the SIGINT handler.
Patch 7eb895307f Skip unwritable frames in command "finish"
skips non-writable frames in addition to tailcall frames.
If skip_tailcall_frames already returns NULL, skip_unwritable_frames
will be called with a NULL frame and crash in get_frame_arch. This is
caught by gdb.btrace/tailcall-only.exp.
Further, if we ever end up with a mixture of tailcall and non-writable
frames, we may not skip all of them, as intended.
Loop over skip_tailcall_frames and skip_unwritable_frames as long as at least
one of them makes progress.
gdb/
* infcmd.c (skip_finish_frames): New.
(finish_command): Call skip_finish_frames.
As reported in PR 19998, after type ctrl-c, GDB hang there and does
not send interrupt. It causes a fail in gdb.base/interrupt.exp.
All targets support remote fileio should be affected.
When we type ctrc-c, SIGINT is handled by remote_fileio_sig_set,
as shown below,
#0 remote_fileio_sig_set (sigint_func=0x4495d0 <remote_fileio_ctrl_c_signal_handler(int)>) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:325
#1 0x00000000004495de in remote_fileio_ctrl_c_signal_handler (signo=<optimised out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:349
#2 <signal handler called>
#3 0x00007ffff647ed83 in __select_nocancel () at ../sysdeps/unix/syscall-template.S:81
#4 0x00000000005530ce in interruptible_select (n=10, readfds=readfds@entry=0x7fffffffd730, writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0,
timeout=timeout@entry=0x0) at /home/yao/SourceCode/gnu/gdb/git/gdb/event-top.c:1017
#5 0x000000000061ab20 in stdio_file_read (file=<optimised out>, buf=0x12d02e0 "\n\022-\001", length_buf=16383)
at /home/yao/SourceCode/gnu/gdb/git/gdb/ui-file.c:577
#6 0x000000000044a4dc in remote_fileio_func_read (buf=0x12c0360 "") at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:583
#7 0x0000000000449598 in do_remote_fileio_request (uiout=<optimised out>, buf_arg=buf_arg@entry=0x12c0340)
at /home/yao/SourceCode/gnu/gdb/git/gdb/remote-fileio.c:1179
we don't set quit_serial_event,
do
{
res = gdb_select (n, readfds, writefds, exceptfds, timeout);
}
while (res == -1 && errno == EINTR);
if (res == 1 && FD_ISSET (fd, readfds))
{
errno = EINTR;
return -1;
}
return res;
we can't go out of the loop above, and that is why GDB can't send
interrupt.
Recently, we stop throwing exception from SIGINT handler
(remote_fileio_ctrl_c_signal_handler)
https://sourceware.org/ml/gdb-patches/2016-03/msg00372.html, which
is correct, because gdb_select is interruptible. However, in the
same patch series, we add interruptible_select later as a wrapper
to gdb_select, https://sourceware.org/ml/gdb-patches/2016-03/msg00375.html
and it is not interruptible (because of the loop in it) unless
select/poll-able file descriptors are marked.
This fix in this patch is to call quit_serial_event_set, so that we can
go out of the loop above, return -1 and set errno to EINTR.
2016-06-01 Yao Qi <yao.qi@linaro.org>
PR remote/19998
* remote-fileio.c (remote_fileio_ctrl_c_signal_handler): Call
quit_serial_event_set.
https://sourceware.org/bugzilla/show_bug.cgi?id=19893
I've traced the main source of the problem to pieced_value_funcs.coerce_ref not being
implemented. Since gdb always assumes references are implemented as pointers, this
causes it to think that it's dealing with a NULL pointer, thus breaking any operations
involving synthetic references.
What I did here was implementing pieced_value_funcs.coerce_ref using some of the synthetic
pointer handling code from indirect_pieced_value, as Pedro suggested. I also made a few
adjustments to the reference printing code so that it correctly shows either the address
of the referenced value or (if it's non-addressable) the "<synthetic pointer>" string.
I also wrote some unit tests based on Dwarf::assemble; these took a while to make
because in most cases I needed a synthetic reference to a physical variable. Additionally,
I started working on a unit test for classes that have a vtable, but ran into a few issues
so that'll probably go in a future patch. One thing that should definitely be fixed is that
proc function_range (called for MACRO_AT_func) will always try to compile/link using gcc
with the default options instead of g++, thus breaking C++ compilations that require e.g. libstdc++.
gdb/ChangeLog:
* dwarf2loc.c (coerce_pieced_ref, indirect_synthetic_pointer,
fetch_const_value_from_synthetic_pointer): New functions.
(indirect_pieced_value): Move lower half to indirect_synthetic_pointer.
(pieced_value_funcs): Implement coerce_ref.
* valops.c (value_addr): Call coerce_ref for synthetic references.
* valprint.c (valprint_check_validity): Return true for synthetic
references. Also, don't show "<synthetic pointer>" if they reference
addressable values.
(generic_val_print_ref): Handle synthetic references. Also move some
code to print_ref_address.
(print_ref_address, get_value_addr_contents): New functions.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/implref.exp: Rename to...
* gdb.dwarf2/implref-const.exp: ...this. Also add more test statements.
* gdb.dwarf2/implref-array.c: New file.
* gdb.dwarf2/implref-array.exp: Likewise.
* gdb.dwarf2/implref-global.c: Likewise.
* gdb.dwarf2/implref-global.exp: Likewise.
* gdb.dwarf2/implref-struct.c: Likewise.
* gdb.dwarf2/implref-struct.exp: Likewise.
This patch adds tests for emit operations with 64 bit values. It takes
special care to avoid mistakes that one could make on a 32bit architecture
using 64bit values.
gdb/testsuite/ChangeLog:
* gdb.trace/trace-condition.exp: Add 64bit tests.
This patch add variable length tests for emit_ref by reading the variable
passed as argument of 8 to 64 bit.
gdb/testsuite/ChangeLog:
* gdb.trace/trace-condition.c (marker): Adapt signature to 8 to 64
bits types.
(main): Adapt to 8 to 64 bits types.
* gdb.trace/trace-condition.exp: Add new tests.
This patch moves conditional tests that were done in ftrace.exp to
trace-condition.exp.
Note that emit_ref is now tested by the anarg local variable there is no
need to test the register directly.
All emit calls have been tested using asserts before / after the move, to
ensure that the tests cover the same functions.
Note that these function were not covered before and are still not:
emit_gt_goto, emit_lt_goto, emit_pop, emit_unsigned_less.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace.exp (test_ftrace_condition): Remove.
Move condition tests...
* gdb.trace/trace-condition.exp: Here.
In trace-condition.exp, tests are done by doing a conditional tracepoint
and validating that the trace contains all the frames that could be
collected if that condition is true.
E.g. test_tracepoints $trace_command "21 + 21 == 42" 10
This will always return true and collect the 10 frames possible to collect
with the test program.
However, if the condition evaluation is broken such that the condition is
unconditional we will not notice this problem.
This patch adds counter-cases to such conditions like so:
$trace_command "21 + 11 == 42" 0
This way such a problem would be noticed.
gdb/testsuite/ChangeLog:
* gdb.trace/trace-condition.exp: Add counter-case tests.
Local variables in lambdas are not accessible
https://sourceware.org/bugzilla/show_bug.cgi?id=15231
GDB: read_lexical_block_scope
/* Ignore blocks with missing or invalid low and high pc attributes. */
[...]
if (!dwarf2_get_pc_bounds (die, &lowpc, &highpc, cu, NULL))
return;
But sometimes there is:
FAIL: gcc-5.3.1-6.fc23.x86_64
<2><92>: Abbrev Number: 11 (DW_TAG_lexical_block)
<3><9c>: Abbrev Number: 13 (DW_TAG_structure_type)
<9d> DW_AT_name : (indirect string, offset: 0x3c): <lambda()>
[...]
Where DW_TAG_lexical_block has no attributes. Such whole subtree is currently
dropped by GDB while I think it should just import all its children DIEs.
It even XFAIL->XPASSes gdb.ada/out_of_line_in_inlined.exp:
commit 0fa7fe506c
Author: Joel Brobecker <brobecker@adacore.com>
out of line functions nested inside inline functions.
So I have removed that xfail.
gdb/ChangeLog
2016-05-30 Jan Kratochvil <jan.kratochvil@redhat.com>
PR c++/15231
* dwarf2read.c (enum pc_bounds_kind): Add PC_BOUNDS_INVALID.
(process_psymtab_comp_unit_reader, read_func_scope): Adjust callers.
(read_lexical_block_scope): Import DIEs from bare DW_TAG_lexical_block.
(read_call_site_scope): Adjust callers.
(dwarf2_get_pc_bounds): Implement pc_bounds_invalid.
(dwarf2_get_subprogram_pc_bounds, get_scope_pc_bounds): Adjust callers.
gdb/testsuite/ChangeLog
2016-05-30 Jan Kratochvil <jan.kratochvil@redhat.com>
PR c++/15231
* gdb.ada/out_of_line_in_inlined.exp: Remove xfails.
* gdb.dwarf2/dw2-lexical-block-bare.exp: New file.
Make the code (maybe) more readable + primarily prepare it for [patch 2/2]
enum extension.
This change should have no code change impact.
gdb/ChangeLog
2016-05-30 Jan Kratochvil <jan.kratochvil@redhat.com>
Code cleanup: dwarf2_get_pc_bounds: -1/0/+1 -> enum
* dwarf2read.c (enum pc_bounds_kind) New.
(dwarf2_get_pc_bounds): Use it in the declaration.
(process_psymtab_comp_unit_reader): Adjust caller. Rename has_pc_info
to cu_bounds_kind.
(read_func_scope, read_lexical_block_scope, read_call_site_scope):
Adjust callers.
(dwarf2_get_pc_bounds): Use enum pc_bounds_kind in the definition.
(dwarf2_get_subprogram_pc_bounds, get_scope_pc_bounds): Adjust callers.
Standardize the QCatchSyscalls NEWS entry.
gdb/ChangeLog
2016-05-29 Jan Kratochvil <jan.kratochvil@redhat.com>
* NEWS (QCatchSyscalls): Remove the parameter. Include ...
(QCatchSyscalls:1 in qSupported) ... this separate entry which got
deleted.
If the testsuite is run with a DejaGnu version that predates the fix
from last year:
[PATCH] DejaGnu kills the wrong process due to PID-reuse races
http://lists.gnu.org/archive/html/dejagnu/2015-07/msg00005.html
... gdb.threads/attach-many-short-lived-threads.exp fails randomly,
often. Other tests randomly fail due to that issue too, but this one
is _much_ more exposed.
DejaGnu 1.6 was released meanwhile, which includes that DejaGnu fix,
and also some distros backported the fix too.
So skip the test when run with older/broken DejaGnus.
gdb/testsuite/ChangeLog:
2016-05-27 Pedro Alves <palves@redhat.com>
* gdb.threads/attach-many-short-lived-threads.exp (bad_dejagnu):
New procedure.
(top level): Call it, and bail out of DejaGnu is known to be bad.
gdb/doc/ChangeLog:
* gdb.texinfo (General Query Packets): Move the description of the
response before the long list of the specific 'read' and 'write'
requests.
When evaluating an expression with EVAL_AVOID_SIDE_EFFECTS if the value
we return is forced to be of type not_lval then GDB will be unable to
take the address of the returned value.
Instead, we should properly initialise the LVAL of the returned value.
This commit builds on two previous commits 2520f728b7 (Forward
VALUE_LVAL when avoiding side effects for STRUCTOP_STRUCT) and
ac775bf4d3 (gdb: Forward VALUE_LVAL when avoiding side effects for
STRUCTOP_PTR), which in turn build on ac1ca910d7 (Fixes for PR
exp/15364).
This commit is currently untested due to my lack of access to an OpenCL
compiler, however, if follows the same pattern as the first two commits
mentioned above and so I believe that it is correct.
gdb/ChangeLog:
* opencl-lang.c (evaluate_subexp_opencl): If
EVAL_AVOID_SIDE_EFFECTS mode, forward the VALUE_LVAL attribute to
the returned value in the STRUCTOP_STRUCT case.
Assume that we have a C program like this:
struct foo_type
{
int var;
} foo;
struct foo_type *foo_ptr = &foo;
int
main ()
{
return foo_ptr->var;
}
Then GDB should be able to evaluate the following, however, it currently
does not:
(gdb) start
...
(gdb) whatis &(foo_ptr->var)
Attempt to take address of value not located in memory.
The problem is that in EVAL_AVOID_SIDE_EFFECTS mode,
eval.c:evaluate_subexp_standard always returns a not_lval value as the
result for a STRUCTOP_PTR operation. As a consequence, the rest of
the code believes that one cannot take the address of the returned
value.
This patch fixes STRUCTOP_PTR handling so that the VALUE_LVAL
attribute for the returned value is properly initialized. After this
change, the above session becomes:
(gdb) start
...
(gdb) whatis &(foo_ptr->var)
type = int *
This commit is largely the same as commit 2520f728b7 (Forward
VALUE_LVAL when avoiding side effects for STRUCTOP_STRUCT) but applied
to STRUCTOP_PTR rather than STRUCTOP_STRUCT. Both of these commits are
building on top of commit ac1ca910d7 (Fixes for PR exp/15364).
gdb/ChangeLog:
* eval.c (evaluate_subexp_standard): If EVAL_AVOID_SIDE_EFFECTS
mode, forward the VALUE_LVAL attribute to the returned value in
the STRUCTOP_PTR case.
gdb/testsuite/ChangeLog:
* gdb.base/whatis.c: Extend the test case.
* gdb.base/whatis.exp: Add additional tests.
Ulrich pointed out that an earlier patch had misspelled
HAVE_LIBPYTHON2_4, adding an extra "_". This caused a build failure.
This patch fixes the bug.
2016-05-25 Tom Tromey <tom@tromey.com>
* python/py-value.c (value_object_as_number): Use correct spelling
of HAVE_LIBPYTHON2_4.
Variable "show" was hardcoded to zero for pointer and reference types.
This implementation didn't allow a correct "whatis" print
for those types and results in same output for "ptype" and "whatis".
Before:
(gdb) whatis t3p
type = PTR TO -> ( Type t3
integer(kind=4) :: t3_i
Type t2 :: t2_n
End Type t3 )
After:
(gdb) whatis t3p
type = PTR TO -> ( Type t3 )
2016-05-25 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* f-typeprint.c (f_type_print_base): Replace 0 by show.
gdb/testsuite/Changelog:
* gdb.fortran/type.f90: Add pointer variable.
* gdb.fortran/whatis_type.exp: Add whatis/ptype of pointers.
As as result of printing only the outer elements of nested structures,
some testcases have to be added to check for corner cases with VLA's.
2016-05-25 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/testsuite/Changelog:
* gdb.fortran/vla-type.exp: Access elements in nested structs.
According to the typeprint's description, the level of details is
decreased by one for the typeprint of elements of a structure.
Before:
(gdb) ptype t3v
type = Type t3
integer(kind=4) :: t3_i
Type t2
integer(kind=4) :: t2_i
Type t1
integer(kind=4) :: t1_i
real(kind=4) :: t1_r
End Type t1 :: t1_n
End Type t2 :: t2_n
End Type t3
After:
(gdb) ptype t3v
type = Type t3
integer(kind=4) :: t3_i
Type t2 :: t2_n
End Type t3
2016-05-25 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* f-typeprint.c (f_type_print_base): Decrease show by one.
gdb/testsuite/Changelog:
* gdb.fortran/type.f90: Add nested structures.
* gdb.fortran/whatis-type.exp: Whatis/ptype nested structures.
* gdb.fortran/derived-type.exp: Adapt expected output.
* gdb.fortran/vla-type.exp: Adapt expected output.
According to the typeprint's description, elements of a structure
should not be printed when show is < 1.
This variable is also used to distinguish the level of details
between "ptype" and "whatis" expressions.
Before:
(gdb) whatis t1v
type = Type t1
integer(kind=4) :: t1_i
real(kind=4) :: t1_r
End Type t1
After:
(gdb) whatis t1v
type = Type t1
2016-05-25 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* f-typeprint.c (f_type_print_base): Don't print fields when show < 0.
gdb/testsuite/Changelog:
* gdb.fortran/whatis_type.exp: Adapt expected output.
Level of indentation was not proper handled when printing
the elements type's name.
Before:
type = Type t1
integer(kind=4) :: var_1
integer(kind=4) :: var_2
End Type t1
After:
type = Type t1
integer(kind=4) :: var_1
integer(kind=4) :: var_2
End Type t1
2016-05-25 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* f-typeprint.c (f_type_print_base): Take print level into account.
gdb/testsuite/Changelog:
* gdb.fortran/print_type.exp: Fix expected output.
* gdb.fortran/whatis_type.exp: Fix expected output.
This patch fixes PR python/17386.
The bug is that gdb.Value does not implement the Python __index__
method. This method is needed to convert a Python object to an index
and is used by various operations in Python, such as indexing an
array.
The fix is to implement the nb_index method for gdb.Value.
nb_index was added in Python 2.5. I don't have a good way to test
Python 2.4, but I made an attempt to accomodate it.
I chose to use valpy_long in all cases because this simplifies porting
to Python 3, and because there didn't seem to be any harm.
Built and regtested on x86-64 Fedora 23.
2016-05-24 Tom Tromey <tom@tromey.com>
PR python/17386:
* python/py-value.c (value_object_as_number): Add
nb_inplace_floor_divide, nb_inplace_true_divide, nb_index.
2016-05-24 Tom Tromey <tom@tromey.com>
PR python/17386:
* gdb.python/py-value.exp (test_value_numeric_ops): Add tests that
use value as an index.
Python 2's PyNumberMethods has nb_inplace_divide, but Python 3 does
not. This patch adds it for Python 2.
This buglet didn't cause much fallout because the only non-NULL entry
in value_object_as_number after this is for valpy_divide; and the
missing slot caused it to slide up to nb_floor_divide (where
nb_true_divide was intended).
2016-05-24 Tom Tromey <tom@tromey.com>
* python/py-value.c (value_object_as_number): Add
nb_inplace_divide for Python 2.
PR python/17981 notes that gdb.breakpoints() returns None when there
are no breakpoints; whereas an empty list or tuple would be more in
keeping with Python and the documentation.
This patch fixes the bug by changing the no-breakpoint return to make
an empty tuple.
Built and regtested on x86-64 Fedora 23.
2016-05-23 Tom Tromey <tom@tromey.com>
PR python/17981:
* python/py-breakpoint.c (gdbpy_breakpoints): Return a new tuple
when there are no breakpoints.
2016-05-23 Tom Tromey <tom@tromey.com>
* python.texi (Basic Python): Document gdb.breakpoints return.
2016-05-23 Tom Tromey <tom@tromey.com>
PR python/17981:
* gdb.python/py-breakpoint.exp (test_bkpt_basic): Add test for
no-breakpoint case.
PR gdb/19194 points out a typo in the documentation. I'm checking
this in as obvious.
2016-05-24 Tom Tromey <tom@tromey.com>
PR gdb/19194:
* gdb.texinfo (gdb man): Fix typo.
When GDB attaches to a process, it looks at the /proc/PID/task/ dir
for all clone threads of that process, and attaches to each of them.
Usually, if there is more than one clone thread, it means the program
is multi threaded and linked with pthreads. Thus when GDB soon after
attaching finds and loads a libthread_db matching the process, it'll
add a thread to the thread list for each of the initially found
lower-level LWPs.
If, however, GDB fails to find/load a matching libthread_db, nothing
is adding the LWPs to the thread list. And because of that, "detach"
hits an internal error:
(gdb) PASS: gdb.threads/clone-attach-detach.exp: fg attach 1: attach
info threads
Id Target Id Frame
* 1 LWP 6891 "clone-attach-de" 0x00007f87e5fd0790 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84
(gdb) FAIL: gdb.threads/clone-attach-detach.exp: fg attach 1: info threads shows two LWPs
detach
.../src/gdb/thread.c:1010: internal-error: is_executing: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
FAIL: gdb.threads/clone-attach-detach.exp: fg attach 1: detach (GDB internal error)
From here:
...
#8 0x00000000007ba7cc in internal_error (file=0x98ea68 ".../src/gdb/thread.c", line=1010, fmt=0x98ea30 "%s: Assertion `%s' failed.")
at .../src/gdb/common/errors.c:55
#9 0x000000000064bb83 in is_executing (ptid=...) at .../src/gdb/thread.c:1010
#10 0x00000000004c23bb in get_pending_status (lp=0x12c5cc0, status=0x7fffffffdc0c) at .../src/gdb/linux-nat.c:1235
#11 0x00000000004c2738 in detach_callback (lp=0x12c5cc0, data=0x0) at .../src/gdb/linux-nat.c:1317
#12 0x00000000004c1a2a in iterate_over_lwps (filter=..., callback=0x4c2599 <detach_callback>, data=0x0) at .../src/gdb/linux-nat.c:899
#13 0x00000000004c295c in linux_nat_detach (ops=0xe7bd30, args=0x0, from_tty=1) at .../src/gdb/linux-nat.c:1358
#14 0x000000000068284d in delegate_detach (self=0xe7bd30, arg1=0x0, arg2=1) at .../src/gdb/target-delegates.c:34
#15 0x0000000000694141 in target_detach (args=0x0, from_tty=1) at .../src/gdb/target.c:2241
#16 0x0000000000630582 in detach_command (args=0x0, from_tty=1) at .../src/gdb/infcmd.c:2975
...
Tested on x86-64 Fedora 23. Also confirmed the test passes against
gdbserver with "maint set target-non-stop".
gdb/ChangeLog:
2016-05-24 Pedro Alves <palves@redhat.com>
PR gdb/19828
* linux-nat.c (attach_proc_task_lwp_callback): Mark the lwp
resumed, and add the thread to GDB's thread list.
testsuite/ChangeLog:
2016-05-24 Pedro Alves <palves@redhat.com>
PR gdb/19828
* gdb.threads/clone-attach-detach.c: New file.
* gdb.threads/clone-attach-detach.exp: New file.
Working on the fix for gdb/19828, I saw
gdb.threads/attach-many-short-lived-threads.exp fail once in an
unusual way. Unfortunately I didn't keep debug logs, but it's an
issue similar to what's been fixed in remote.c a while ago --
linux-nat.c was not fetching the pending status from the right place.
gdb/ChangeLog:
2016-05-24 Pedro Alves <palves@redhat.com>
PR gdb/19828
* linux-nat.c (get_pending_status): If the thread reported the
event to the core and it's pending, use the pending status signal
number.
Hacking the gdb.threads/attach-many-short-lived-threads.exp test to
spawn thousands of threads instead of dozens, and running gdb under
perf, I saw that GDB was spending most of the time in find_lwp_pid:
- captured_main
- 93.61% catch_command_errors
- 87.41% attach_command
- 87.40% linux_nat_attach
- 87.40% linux_proc_attach_tgid_threads
- 82.38% attach_proc_task_lwp_callback
- 81.01% find_lwp_pid
5.30% ptid_get_lwp
+ 0.10% ptid_lwp_p
+ 0.64% add_thread
+ 0.26% set_running
+ 0.24% set_executing
0.12% ptid_get_lwp
+ 0.01% ptrace
+ 0.01% add_lwp
attach_proc_task_lwp_callback is called once for each LWP that we
attach to, found by listing the /proc/PID/task/ directory. In turn,
attach_proc_task_lwp_callback calls find_lwp_pid to check whether the
LWP we're about to try to attach to is already known. Since
find_lwp_pid does a linear walk over the whole LWP list, this becomes
quadratic. We do the /proc/PID/task/ listing until we get two
iterations in a row where we found no new threads. So the second and
following times we walk the /proc/PID/task/ dir, we're going to take
an even worse find_lwp_pid hit.
Fix this by adding a hash table keyed by LWP PID, for fast lookup.
The linked list embedded in the LWP structure itself is kept, and made
a double-linked list, so that removals from that list are O(1). An
earlier version of this patch got rid of this list altogether, but
that revealed hidden dependencies / assumptions on how the list is
sorted. For example, killing a process and then waiting for all the
LWPs status using iterate_over_lwps only works as is because the
leader LWP is always last in the list. So I thought it better to take
an incremental approach and make this patch concern itself _only_ with
the PID lookup optimization.
gdb/ChangeLog:
2016-05-24 Pedro Alves <palves@redhat.com>
PR gdb/19828
* linux-nat.c (lwp_lwpid_htab): New htab.
(lwp_info_hash, lwp_lwpid_htab_eq, lwp_lwpid_htab_create)
(lwp_lwpid_htab_add_lwp): New functions.
(lwp_list): Tweak comment.
(lwp_list_add, lwp_list_remove, lwp_lwpid_htab_remove_pid): New
functions.
(purge_lwp_list): Rewrite, using htab_traverse_noresize.
(add_initial_lwp): Add lwp to htab too. Use lwp_list_add.
(delete_lwp): Use lwp_list_remove. Remove htab too.
(find_lwp_pid): Search in htab.
(_initialize_linux_nat): Call lwp_lwpid_htab_create.
* linux-nat.h (struct lwp_info) <prev>: New field.
Hacking the gdb.threads/attach-many-short-lived-threads.exp test to
spawn thousands of threads instead of dozens, I saw GDB having trouble
keeping up with threads being spawned too fast, when it tried to stop
them all. This was because while gdb is doing that, it updates the
thread list to make sure no new thread has sneaked in that might need
to be paused. It does this a few times until it sees no-new-threads
twice in a row. The thread listing update itself is not that
expensive, however, in the Linux backend, updating the threads list
calls linux_common_core_of_thread for each LWP to record on which core
each LWP was last seen running, which opens/reads/closes a /proc file
for each LWP which becomes expensive when you need to do it for
thousands of LWPs.
perf shows gdb in linux_common_core_of_thread 44% of the time, in the
stop_all_threads -> update_thread_list path in this use case.
This patch simply makes linux_common_core_of_thread avoid updating the
core the thread is bound to if the thread hasn't run since the last
time we updated that info. This makes linux_common_core_of_thread
disappear into the noise in the perf report.
gdb/ChangeLog:
2016-05-24 Pedro Alves <palves@redhat.com>
PR gdb/19828
* linux-nat.c (linux_resume_one_lwp_throw): Clear the LWP's core
field.
(linux_nat_update_thread_list): Don't fetch the core if already
known.
... as it's _much_ faster.
Hacking the gdb.threads/attach-many-short-lived-threads.exp test to
spawn thousands of threads instead of dozens to stress and debug
timeout problems with gdb.threads/attach-many-short-lived-threads.exp,
I saw that GDB would spend several seconds just reading the
/proc/PID/smaps file, to determine the vDSO mapping range. GDB opens
and reads the whole file just once, and caches the result, but even
that is too slow. For example, with almost 8000 threads:
$ ls /proc/3518/task/ | wc -l
7906
reading the /proc/PID/smaps file grepping for "vdso" takes over 15
seconds :
$ time cat /proc/3518/smaps | grep vdso
7ffdbafee000-7ffdbaff0000 r-xp 00000000 00:00 0 [vdso]
real 0m15.371s
user 0m0.008s
sys 0m15.017s
Looking around the web for hints, I found a nice description of the
issue here:
http://backtrace.io/blog/blog/2014/11/12/large-thread-counts-and-slow-process-maps/
The problem is that /proc/PID/smaps wants to show the mappings as
being thread stack, and that has the kernel iterating over all threads
in the thread group, for each mapping.
The fix is to use the "map" file under /proc/PID/task/PID/ instead of
the /proc/PID/ one, as the former doesn't mark thread stacks for all
threads.
That alone drops the timing to the millisecond range on my machine:
$ time cat /proc/3518/task/3518/smaps | grep vdso
7ffdbafee000-7ffdbaff0000 r-xp 00000000 00:00 0 [vdso]
real 0m0.150s
user 0m0.009s
sys 0m0.084s
And since we only need the vdso mapping's address range, we can use
"maps" file instead of "smaps", and it's even cheaper:
/proc/PID/task/PID/maps :
$ time cat /proc/3518/task/3518/maps | grep vdso
7ffdbafee000-7ffdbaff0000 r-xp 00000000 00:00 0 [vdso]
real 0m0.027s
user 0m0.000s
sys 0m0.017s
gdb/ChangeLog:
2016-05-24 Pedro Alves <palves@redhat.com>
PR gdb/19828
* linux-tdep.c (find_mapping_size): Delete.
(linux_vsyscall_range_raw): Rewrite reading from
/proc/PID/task/PID/maps directly instead of using
gdbarch_find_memory_regions.
A following patch (fix for gdb/19828) makes linux-nat.c add threads to
GDB's thread list earlier in the "attach" sequence, and that causes a
surprising regression on
gdb.threads/attach-many-short-lived-threads.exp on my machine. The
extra "thread x exited" handling and traffic slows down that test
enough that GDB core has trouble keeping up with new threads that are
spawned while trying to stop existing ones.
I saw the exact same issue with remote/gdbserver a while ago and fixed
it in 65706a29ba (Remote thread create/exit events) so part of the
fix here is the exact same -- add support for thread created events to
gdb/linux-nat.c. infrun.c:stop_all_threads enables those events when
it tries to stop threads, which ensures that new threads never get a
chance to themselves start new threads, thus fixing the race.
gdb/
2016-05-24 Pedro Alves <palves@redhat.com>
PR gdb/19828
* linux-nat.c (report_thread_events): New global.
(linux_handle_extended_wait): Report
TARGET_WAITKIND_THREAD_CREATED if thread event reporting is
enabled.
(wait_lwp, linux_nat_filter_event): Report all thread exits if
thread event reporting is enabled. Remove comment.
(filter_exit_event): New function.
(linux_nat_wait_1): Use it.
(linux_nat_thread_events): New function.
(linux_nat_add_target): Install it as target_thread_events method.
This patch fixes a syntax error which caused a failure in
annota-input-while-running.exp to crash the test suite runner.
2016-05-24 Francis Ricci <francisjricci@gmail.com>
* gdb.base/annota-input-while-running.exp: Fix syntax error.
Nowadays, GDB can't insert breakpoint on the return address of the
exception handler on ARM M-profile, because the address is a magic
one 0xfffffff9,
(gdb) bt
#0 CT32B1_IRQHandler () at ../src/timer.c:67
#1 <signal handler called>
#2 main () at ../src/timer.c:127
(gdb) info frame
Stack level 0, frame at 0x200ffa8:
pc = 0x4ec in CT32B1_IRQHandler (../src/timer.c:67); saved pc = 0xfffffff9
called by frame at 0x200ffc8
source language c.
Arglist at 0x200ffa0, args:
Locals at 0x200ffa0, Previous frame's sp is 0x200ffa8
Saved registers:
r7 at 0x200ffa0, lr at 0x200ffa4
(gdb) x/x 0xfffffff9
0xfffffff9: Cannot access memory at address 0xfffffff9
(gdb) finish
Run till exit from #0 CT32B1_IRQHandler () at ../src/timer.c:67
Ed:15: Target error from Set break/watch: Et:96: Pseudo-address (0xFFFFFFxx) for EXC_RETURN is invalid (GDB error?)
Warning:
Cannot insert hardware breakpoint 0.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
Command aborted.
even some debug probe can't set hardware breakpoint on the magic
address too,
(gdb) hbreak *0xfffffff9
Hardware assisted breakpoint 2 at 0xfffffff9
(gdb) c
Continuing.
Ed:15: Target error from Set break/watch: Et:96: Pseudo-address (0xFFFFFFxx) for EXC_RETURN is invalid (GDB error?)
Warning:
Cannot insert hardware breakpoint 2.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
Command aborted.
The problem described above is quite similar to PR 8841, in which GDB
can't set breakpoint on signal trampoline, which is mapped to a read-only
page by kernel. The rationale of this patch is to skip "unwritable"
frames when looking for caller frames in command "finish", and a new
gdbarch method code_of_frame_writable is added. This patch fixes
the problem on ARM cortex-m target, but it can be used to fix
PR 8841 too.
gdb:
2016-05-10 Yao Qi <yao.qi@arm.com>
* arch-utils.c (default_code_of_frame_writable): New function.
* arch-utils.h (default_code_of_frame_writable): Declare.
* arm-tdep.c (arm_code_of_frame_writable): New function.
(arm_gdbarch_init): Install gdbarch method
code_of_frame_writable if the target is M-profile.
* frame.c (skip_unwritable_frames): New function.
* frame.h (skip_unwritable_frames): Declare.
* gdbarch.sh (code_of_frame_writable): New.
* gdbarch.c, gdbarch.h: Re-generated.
* infcmd.c (finish_command): Call skip_unwritable_frames.
This fixes PR python/19438 and PR python/18393. Both bugs are about
invoking dir() on some Python object implemented by gdb, and getting a
crash.
The crash happens because the dictionary field of these objects was
not initialized. Apparently what happens is that this field can be
lazily initialized by Python when assigning to an attribute; and it
can also be handled ok when using dir() but without __dict__ defined;
but gdb defines __dict__ because this isn't supplied automatically by
Python.
The docs on this seem rather sparse, but this patch works ok.
An alternative might be to lazily create the dictionary in
gdb_py_generic_dict, but I went with this approach because it seemed
more straightforward.
Built and regtested on x86-64 Fedora 23.
2016-05-23 Tom Tromey <tom@tromey.com>
PR python/19438, PR python/18393:
* python/py-objfile.c (objfpy_initialize): Initialize self->dict.
* python/py-progspace.c (pspy_initialize): Initialize self->dict.
2016-05-23 Tom Tromey <tom@tromey.com>
PR python/19438, PR python/18393:
* gdb.python/py-progspace.exp: Add "dir" test.
* gdb.python/py-objfile.exp: Add "dir" test.
This patch fixes the errors below:
Running /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.arch/thumb-prologue.exp ...
gdb compile failed, arm-linux-gnueabihf/bin/ld: cannot open output file /scratch/yao/gdb/build-git/arm-linux-gnueabihf/gdb/testsuite/gdb.arch/thumb-prologue: No such file or directory
collect2: error: ld returned 1 exit status
Running /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.arch/thumb2-it.exp ...
gdb compile failed, arm-linux-gnueabihf/bin/ld: cannot open output file /scratch/yao/gdb/build-git/arm-linux-gnueabihf/gdb/testsuite/gdb.arch/thumb2-it: No such file or directory
gdb/testsuite:
2016-05-23 Yao Qi <yao.qi@linaro.org>
* gdb.arch/thumb-prologue.exp: Use standard_testfile.
* gdb.arch/thumb2-it.exp: Likewise.
Native GDB looks up the function td_thr_validate from libthread_db.so
on Linux, but the value is never used. This commit removes this dead
code.
gdb/ChangeLog:
* nat/gdb_thread_db.h (td_thr_validate_ftype): Remove typedef.
* linux-thread-db.c (struct thread_db_info) <td_thr_validate_p>:
Remove field.
(try_thread_db_load_1): Remove td_thr_validate initialization.
GDB needs kinfo_getvmmap() on GNU/kFreeBSD systems same as on
pure FreeBSD. However on these systems the FreeBSD version of libutil
is renamed to libutil-freebsd.
2016-05-23 Jon Boden <jon@ubuntubsd.org>
* configure.ac: Search for libutil-freebsd as alternative to libutil.
* configure: Re-generated.
Add a new test for PR 20039. The test spawns new threads, then tries to
interrupt, continue, and interrupt again. This use case was fixed by
commit 5fe966540d in master, but gdb 7.11
is affected (so if you try it on the gdb-7.11-branch right now, the test
will fail).
New in v2, the test now handles mi-async on mode properly. The failure
was specific to mi-async off, but I don't think it's bad to test the
same thing under async on mode. I added a little hack when running in
async mode to work around bug 20045.
I also removed one continue/interrupt pair, as a single one was enough to
trigger the problem.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-threads-interrupt.c: New file.
* gdb.mi/mi-threads-interrupt.exp: New file.
When you use a run control command (-exec-run, -exec-continue,
-exec-next, ...) with mi-async on, an extra (gdb) prompt is displayed:
-exec-continue
^running
*running,thread-id="all"
(gdb)
(gdb)
It doesn't seem to be a big problem for front-ends, since this behavior
started in gdb 7.9 and we haven't heard anything about that. However,
it caused me some trouble while writing a test for PR 20039 [1].
The problem comes from an extra (gdb) prompt that we write when running
in mi-async off mode to emulate a past buggy behavior. When executing a
run control command synchronously, previous gdbs always printed a prompt
right away, even though they are not ready to accept new MI commands
until the target stops. Only at this time should they display a prompt.
But to keep backwards compatibility apparently, we print it anyway.
Since commit 198297aaf, the condition that decides whether we should
print that "bogus" prompt or not has become true, even when running with
mi-async on. Since we already print a prompt at the end of the
asynchronous command execution, it results in two prompts for one
command.
The proposed fix is to call target_can_async_p instead of
target_is_async_p, to make the condition:
if (!target_can_async_p () || sync_execution)
... show prompt ...
That shows the prompt if we are emulating a synchronous command on top
of an asynchronous target (sync_execution) or if the target simply can't
run asynchronously (!target_can_async_p ()).
Note that this code is changed and this bug fixed by Pedro's separate
console series, but I think it would be nice to have it fixed in the
mean time.
I ran the gdb.mi directory of the testsuite with mi-async on and off, I
didn't see any regressions.
gdb/ChangeLog:
* mi/mi-main.c (mi_on_resume): Call target_can_async_p instead
of target_is_async_p.
[1] https://sourceware.org/ml/gdb-patches/2016-05/msg00075.html
When doing -exec-run on a freshly started GDB, the only target on the
target stack at the time the dummy one. When mi_async_p is called to
know whether the run should be async, it queries whether the current
target (dummy) supports async, and the answer is no. The fix is to make
the code query the target that will be used for the run, which is not
necessarily the current target.
No regressions in the gdb.mi directory using the unix, native-gdbserver
and native-extended-gdbserver boards. The test doesn't pass when
forcing maint set target-async off, obviously, since it makes mi-async
have no effect. It doesn't seem like other tests are checking for that
eventuality, so I didn't in the new test.
gdb/ChangeLog:
* mi/mi-main.c (run_one_inferior): Use run target to determine
whether to run async or not.
(mi_cmd_exec_run): Likewise.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-async-run.exp: New file.
* gdb.mi/mi-async-run.c: New file.
This patch adds documentation for the new Rust support in gdb.
2016-05-17 Tom Tromey <tom@tromey.com>
* NEWS: Add Rust item.
2016-05-17 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Supported Languages): Mention Rust. Update menu.
(Rust): New node.
This updates the gdb test suite for Rust.
2016-05-17 Tom Tromey <tom@tromey.com>
Manish Goregaokar <manishsmail@gmail.com>
* lib/rust-support.exp: New file.
* lib/gdb.exp (skip_rust_tests): New proc.
(build_executable_from_specs): Handle rust.
* lib/future.exp (gdb_find_rustc): New proc.
(gdb_default_target_compile): Handle rust.
* gdb.rust/expr.exp: New file.
* gdb.rust/generics.exp: New file.
* gdb.rust/generics.rs: New file.
* gdb.rust/methods.exp: New file.
* gdb.rust/methods.rs: New file.
* gdb.rust/modules.exp: New file.
* gdb.rust/modules.rs: New file.
* gdb.rust/simple.exp: New file.
* gdb.rust/simple.rs: New file.
For Rust value-printing, I wanted to use generic_val_print_array, but
I also wanted to control the starting and ending strings.
This patch adds new strings to generic_val_print_decorations, updates
generic_val_print_array to use them, and updates all the existing
instances of generic_val_print_decorations.
2016-05-17 Tom Tromey <tom@tromey.com>
* valprint.h (struct generic_val_print_array) <array_start,
array_end>: New fields.
* valprint.c (generic_val_print_array): Add "decorations"
parameter. Use "array_start", "array_end".
(generic_val_print) <TYPE_CODE_ARRAY>: Update.
* p-valprint.c (p_decorations): Update.
* m2-valprint.c (m2_decorations): Update.
* f-valprint.c (f_decorations): Update.
* c-valprint.c (c_decorations): Update.
I wanted to unit test the Rust lexer, so I added a simple unit testing
command to gdb.
The intent is that self tests will only be compiled into gdb in
development mode. In release mode they simply won't exist. So, this
exposes $development to C code as GDB_SELF_TEST.
In development mode, test functions are registered with the self test
module. A test function is just a function that does some checks, and
throws an exception on failure.
Then this adds a new "maint selftest" command which invokes the test
functions, and a new dejagnu test case that invokes it.
2016-05-17 Tom Tromey <tom@tromey.com>
* NEWS: Add "maint selftest" entry.
* selftest.h: New file.
* selftest.c: New file.
* maint.c: Include selftest.h.
(maintenance_selftest): New function.
(_initialize_maint_cmds): Add "maint selftest" command.
* configure.ac (GDB_SELF_TEST): Maybe define.
* config.in, configure: Rebuild.
* Makefile.in (SFILES): Add selftest.c.
(COMMON_OBS): Add selftest.o.
2016-05-17 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Maintenance Commands): Document "maint selftest".
2016-05-17 Tom Tromey <tom@tromey.com>
* gdb.gdb/unittest.exp: New file.
print_subexp_standard and dump_subexp_body_standard did not handle
OP_F90_RANGE. Attempting to dump an expression using this opcode
would fail.
This patch adds support for this opcode to these functions.
2016-05-17 Tom Tromey <tom@tromey.com>
* expprint.c: Include f-lang.h.
(print_subexp_standard, dump_subexp_body_standard): Handle
OP_F90_RANGE.
gdb's Makefile.in does not currently scan .y files to add global
initializers from these files to init.c. However, at least ada-exp.y
tries to use this feature.
This patch fixes the problem.
2016-05-17 Tom Tromey <tom@tromey.com>
* Makefile.in (init.c): Search .y files for initialization
functions.
This patch is to replace find_inferior (&all_threads, unsuspend_one_lwp, NULL)
with unsuspend_all_lwps (NULL), which is shorter. They are equivalent
to each other.
gdb/gdbserver:
2016-05-17 Yao Qi <yao.qi@linaro.org>
* linux-low.c (linux_stabilize_threads): Call unsuspend_all_lwps
instead of find_inferior.
batch-preserve-term-settings.exp fails if the shell prompt isn't $. It
is # in our testing env. In fact, the shell prompt can be anything.
The perfect solution would be "set_board_info shell_prompt" in the
host board file, and use board_info shell_prompt in
batch-preserve-term-settings.exp. This is a little bit overkill to
me, and we still need to figure out the different prompts on different
shells. I also tried to start shell with the prompt preset, but there is
not unique way to set shell prompt in different shells, so I give up.
It is reasonably simple to match either $ or # for the shell prompt, and
we can easily extend it to match other char, like >.
gdb/testsuite:
2016-05-16 Yao Qi <yao.qi@linaro.org>
* gdb.base/batch-preserve-term-settings.exp: Remove variable
shell_prompt. Update shell_prompt_re.
gdb/ChangeLog:
* dwarf2loc.c (dwarf2_find_location_expression): For DWO files still
add base_offset.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (build_executable_from_fission_assembler): Pass
$options when building executable.
* gdb.dwarf2/fission-loclists-pie.c: New file.
* gdb.dwarf2/fission-loclists-pie.exp: New file.
2016-05-10 Thomas Preud'homme <thomas.preudhomme@arm.com>
bfd/
* elf32-arm.c (elf32_arm_size_stubs): Use new macros
ARM_GET_SYM_BRANCH_TYPE and ARM_SET_SYM_BRANCH_TYPE to respectively get
and set branch type of a symbol.
(bfd_elf32_arm_process_before_allocation): Likewise.
(elf32_arm_relocate_section): Likewise and fix identation along the
way.
(allocate_dynrelocs_for_symbol): Likewise.
(elf32_arm_finish_dynamic_symbol): Likewise.
(elf32_arm_swap_symbol_in): Likewise.
(elf32_arm_swap_symbol_out): Likewise.
gas/
* config/tc-arm.c (arm_adjust_symtab): Use ARM_SET_SYM_BRANCH_TYPE to
set branch type of a symbol.
gdb/
* arm-tdep.c (arm_elf_make_msymbol_special): Use
ARM_GET_SYM_BRANCH_TYPE to get branch type of a symbol.
include/
* arm.h (enum arm_st_branch_type): Add new ST_BRANCH_ENUM_SIZE
enumerator.
(NUM_ENUM_ARM_ST_BRANCH_TYPE_BITS): New macro.
(ENUM_ARM_ST_BRANCH_TYPE_BITMASK): Likewise.
(ARM_SYM_BRANCH_TYPE): Replace by ...
(ARM_GET_SYM_BRANCH_TYPE): This and ...
(ARM_SET_SYM_BRANCH_TYPE): This in two versions depending on whether
BFD_ASSERT is defined or not.
ld/
* emultempl/armelf.em (gld${EMULATION_NAME}_finish): Use
ARM_GET_SYM_BRANCH_TYPE to get branch type of a symbol.
opcodes/
* arm-dis.c (get_sym_code_type): Use ARM_GET_SYM_BRANCH_TYPE to get
branch type of a symbol.
(print_insn): Likewise.
This patch initialize res to zero, otherwise, it may have some garbage
bits after the *the_target->read_memory call.
gdb/gdbserver:
2016-05-05 Yao Qi <yao.qi@linaro.org>
* linux-arm-low.c (get_next_pcs_read_memory_unsigned_integer):
Initialize res to zero.
Variable cpsr holds the value of cpsr register, which is 32-bit. It
is better to explicitly use uint32_t.
gdb/gdbserver:
2016-05-05 Yao Qi <yao.qi@linaro.org>
* linux-arm-low.c (arm_sigreturn_next_pc): Change type of cpsr
to uint32_t.
ChangeLog:
* spu-linux-nat.c (spu_bfd_iovec_pread): Add pointer cast for C++.
(spu_bfd_open): Likewise.
gdbserver/ChangeLog:
* spu-low.c (fetch_ppc_register): Cast PowerPC-Linux-specific value
used as first ptrace argument to PTRACE_TYPE_ARG1 for C++.
(fetch_ppc_memory_1, store_ppc_memory_1): Likewise.
Nowadays, read_memory may throw NOT_AVAILABLE_ERROR (it is done by
patch http://sourceware.org/ml/gdb-patches/2013-08/msg00625.html)
however, read_stack and read_code still throws MEMORY_ERROR only. This
causes PR 19947, that is prologue unwinder is unable unwind because
code memory isn't available, but MEMORY_ERROR is thrown, while unwinder
catches NOT_AVAILABLE_ERROR.
#0 memory_error (err=err@entry=TARGET_XFER_E_IO, memaddr=memaddr@entry=140737349781158) at /home/yao/SourceCode/gnu/gdb/git/gdb/corefile.c:217
#1 0x000000000065f5ba in read_code (memaddr=memaddr@entry=140737349781158, myaddr=myaddr@entry=0x7fffffffd7b0 "\340\023<\001", len=len@entry=1)
at /home/yao/SourceCode/gnu/gdb/git/gdb/corefile.c:288
#2 0x000000000065f7b5 in read_code_unsigned_integer (memaddr=memaddr@entry=140737349781158, len=len@entry=1, byte_order=byte_order@entry=BFD_ENDIAN_LITTLE)
at /home/yao/SourceCode/gnu/gdb/git/gdb/corefile.c:363
#3 0x00000000004717e0 in amd64_analyze_prologue (gdbarch=gdbarch@entry=0x13c13e0, pc=140737349781158, current_pc=140737349781165, cache=cache@entry=0xda0cb0)
at /home/yao/SourceCode/gnu/gdb/git/gdb/amd64-tdep.c:2267
#4 0x0000000000471f6d in amd64_frame_cache_1 (cache=0xda0cb0, this_frame=0xda0bf0) at /home/yao/SourceCode/gnu/gdb/git/gdb/amd64-tdep.c:2437
#5 amd64_frame_cache (this_frame=0xda0bf0, this_cache=<optimised out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/amd64-tdep.c:2508
#6 0x000000000047214d in amd64_frame_this_id (this_frame=<optimised out>, this_cache=<optimised out>, this_id=0xda0c50)
at /home/yao/SourceCode/gnu/gdb/git/gdb/amd64-tdep.c:2541
#7 0x00000000006b94c4 in compute_frame_id (fi=0xda0bf0) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:481
#8 get_prev_frame_if_no_cycle (this_frame=this_frame@entry=0xda0b20) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1809
#9 0x00000000006bb6c9 in get_prev_frame_always_1 (this_frame=0xda0b20) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1983
#10 get_prev_frame_always (this_frame=this_frame@entry=0xda0b20) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1999
#11 0x00000000006bbe11 in get_prev_frame (this_frame=this_frame@entry=0xda0b20) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:2241
#12 0x00000000006bc13c in unwind_to_current_frame (ui_out=<optimised out>, args=args@entry=0xda0b20) at /home/yao/SourceCode/gnu/gdb/git/gdb/frame.c:1485
The fix is to let read_stack and read_code throw NOT_AVAILABLE_ERROR too,
in order to align with read_memory.
gdb:
2016-05-04 Yao Qi <yao.qi@linaro.org>
PR gdb/19947
* corefile.c (read_memory): Rename it to ...
(read_memory_object): ... it. Add parameter object.
(read_memory): Call read_memory_object.
(read_stack): Likewise.
(read_code): Likewise.
This test currently uses [is_remote target] to check if the test is
supported. This is not quite correct, as the limitation is actually
that it requires support for "running", ruling out stub-like targets.
Therefore, it should check for use_gdb_stub.
This has no visible effect right now, but it will once we make the
native-gdbserver board non-dejagnu-remote.
gdb/testsuite/ChangeLog:
* gdb.base/solib-display.exp: Check for [use_gdb_stub] instead
of [is_remote target],
This patch introduces the use_gdb_stub procedure, which allows getting
the right value of the use_gdb_stub variable/property in any all
situations.
When calling it before the $use_gdb_stub global variable has been set,
it will return the value of the use_gdb_stub property from the board
file. This happens when tests want to bail out early (even before gdb
has been started) when the current test setup is a stub.
Otherwise, it returns the value of the $use_gdb_stub global.
It's possible for these two to differ when a test file overrides the
value of the global.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (use_gdb_stub): New procedure.
PR symtab/19914
* dwarf2read.c (open_and_init_dwp_file): Look at backlink if objfile
is separate debug file.
testsuite/
* gdb.dwarf2/dwp-sepdebug.c: New file.
* gdb.dwarf2/dwp-sepdebug.exp: New file.
Valgrind shows:
==26964== Invalid read of size 1
==26964== at 0x6E14100: __GI_strcmp (strcmp.S:180)
==26964== by 0x6DB55AA: setlocale (setlocale.c:238)
==26964== by 0x4E0455: _initialize_python() (python.c:1731)
==26964== by 0x786731: initialize_all_files() (init.c:319)
==26964== by 0x72EF0A: gdb_init(char*) (top.c:1929)
==26964== by 0x60BCAC: captured_main(void*) (main.c:863)
==26964== by 0x606AD5: catch_errors(int (*)(void*), void*, char*, return_mask) (exceptions.c:234)
==26964== by 0x60C608: gdb_main(captured_main_args*) (main.c:1165)
==26964== by 0x40CAEC: main (gdb.c:32)
==26964== Address 0x81d30a0 is 0 bytes inside a block of size 181 free'd
==26964== at 0x4C29CF0: free (vg_replace_malloc.c:530)
==26964== by 0x6DB5B65: setname (setlocale.c:201)
==26964== by 0x6DB5B65: setlocale (setlocale.c:388)
==26964== by 0x4E037F: _initialize_python() (python.c:1712)
==26964== by 0x786731: initialize_all_files() (init.c:319)
==26964== by 0x72EF0A: gdb_init(char*) (top.c:1929)
==26964== by 0x60BCAC: captured_main(void*) (main.c:863)
==26964== by 0x606AD5: catch_errors(int (*)(void*), void*, char*, return_mask) (exceptions.c:234)
==26964== by 0x60C608: gdb_main(captured_main_args*) (main.c:1165)
==26964== by 0x40CAEC: main (gdb.c:32)
The problem is doing this:
oldloc = setlocale (LC_ALL, NULL);
setlocale (LC_ALL, "");
...
setlocale (LC_ALL, oldloc);
I.e., the second setlocale call frees 'oldloc'.
From http://pubs.opengroup.org/onlinepubs/9699919799/functions/setlocale.html :
"The returned string pointer might be invalidated or the string
content might be overwritten by a subsequent call to setlocale()."
gdb/ChangeLog:
2016-05-03 Pedro Alves <palves@redhat.com>
PR python/20037
* python/python.c (_initialize_python) [IS_PY3K]: xstrdup/xfree
oldloc.
This makes no sense -- strlen doesn't really ever fail with -1.
gdb/ChangeLog:
2016-05-03 Pedro Alves <palves@redhat.com>
* python/python.c (_initialize_python) [IS_PY3K]: Remove dead
code.
GDB's use of --dynamic-list to only export the proc-service symbols is
broken due to Python's "python-config --ldflags" saying we should link
with -export-dynamic, causing us to export _all_ extern symbols
anyway. On Fedora 23:
$ python-config --ldflags
-lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic
$ python3.4-config --ldflags
-L/usr/lib64 -lpython3.4m -lpthread -ldl -lutil -lm -Xlinker -export-dynamic
Having GDB export all its symbols leads to issues such as PR gdb/16818
(GDB crashes when using name for target remote hostname:port), where a
GDB symbol unintentionally preempts a symbol in one of the NSS modules
glibc loads into the process. NSS modules should not define symbols
outside the implementation namespace or the relevant standards, but,
alas, that's a longstanding and hard to fix issue. See libc-alpha
discussion at:
[symbol name space issues with NSS modules]
https://sourceware.org/ml/libc-alpha/2016-04/msg00130.html
Python should instead be either using GCC's symbol visibility feature
or -Wl,--dynamic-list as well, to only export Python API symbols, but,
it doesn't. There are bugs open upstream for that:
[Use -Wl,--dynamic-list=x.list, not -Xlinker -export-dynamic]
http://bugs.python.org/issue10112
[Use GCC visibility attrs in PyAPI_*]
http://bugs.python.org/issue11410
But that's taking a long while to resolve.
I thought of working around this Python issue by making GDB build with
-fvisibility=hidden, as Jan suggests in Python issue 10112, as then
Python's "-Xlinker -export-dynamic" has no effect. However, that
would need to be done in the whole source tree (bfd, libiberty, etc.),
and I think that would break GCC plugins, as I believe those have
access to all of GCCs symbols, by "design". So we'd need a new
configure switch, or have the libraries in the tree detect which of
GCC or GDB is being built, but that doesn't work, because the answer
can be "both" with combined builds...
So this patch instead works around Python's bug, by simply sed'ing
away "-Xlinker -export-dynamic" from the result of python-config.py
--ldflags, making -Wl,--dynamic-list work again as it used to. It's
ugly, but so is the bug...
Note that if -Wl,--dynamic-list doesn't work, we always link with
-rdynamic, so static Python should still work.
Tested on F23 with --python=python (Python 2.7) and
--python=python3.4.
gdb/ChangeLog:y
2016-05-03 Pedro Alves <palves@redhat.com>
* configure.ac (PYTHON_LIBS): Sed away "-Xlinker -export-dynamic".
* configure: Regenerate.
The -Wl,--dynamic-list test is currently broken on Fedora 23, when you
configure with --with-python=python3.4. We see:
configure:13741: checking for the dynamic export flag
configure:13796: gcc -o conftest -g3 -O0 -fno-strict-aliasing -DNDEBUG -fwrapv -Wl,--dynamic-list=/home/pedro/gdb/mygit/src/gdb/proc-service.list conftest.c -ldl -lncurses -lm -ldl -lpthread -ldl -lutil -lm -lpython3.4m -Xlinker -export-dynamic >&5
conftest.c:182:30: fatal error: python3.4/Python.h: No such file or directory
compilation terminated.
configure:13796: $? = 1
The correct -I path is in PYTHON_CPPFLAGS:
PYTHON_CPPFLAGS='-I/usr/include/python3.4m -I/usr/include/python3.4m'
(Other Python-related tests in the file are already doing this.)
gdb/ChangeLog:
2016-05-03 Pedro Alves <palves@redhat.com>
* configure.ac (checking for the dynamic export flag): Add
$PYTHON_CPPFLAGS to CPPFLAGS.
* configure: Regenerate.
This test seems to work with both native-gdbserver and
native-extended-gdbserver, so I removed the remote check.
When running with native-gdbserver (a stub-like target), detach makes
gdbserver stop and gdb disconnect. runto_main just spawns a brand new
gdbserver. So it tests the exact same thing twice. It doesn't hurt
though.
With native-extended-gdbserver, the test is probably a bit more useful
(and similar to native). It tests running/detaching twice using the
same gdb/gdbserver instances, since with extended-remote, you can
detach/attach/run all you want, unlike with remote.
gdb/testsuite/ChangeLog:
* gdb.base/detach.exp: Remove is_remote check.
The comment says that we can't use runto_main here becore it doesn't
know how to handle annotation. Instead, the test puts a breakpoint at
main and calls run by hand. Therefore, it can't work with stub targets,
since they can't "run". The check should be then changed to check the
use_gdb_stub variable instead of [is_remote target].
But as an alternative, we can just use runto_main and enable annotations
after, since the "run to main" part is not really part of what we want
to test.
I also removed the "set test..." line that is unused.
gdb/testsuite/ChangeLog:
* gdb.base/annota-input-while-running.exp: Don't check for
[is_remote target]. Enable annotations after running to main.
Remove unused "set test..." line.
Yao Qi
Yan-Ting Lin
John Baldwin
Andrew Burgess
Nick Clifton
Tom Tromey
Bernhard Heckel
Toshihito Kikuchi
Simon Marchi
Jon Turney
Pedro Alves
Markus Metzger
Joel Brobecker
Martin Galvan
Antoine Tremblay
Jan Kratochvil
Alan Modra
Eli Zaretskii
Francis Ricci
Yao Qi
Gary Benson
Jon Boden
Andreas Schwab
Doug Evans
Trevor Saunders
Thomas Preud'homme
Ulrich Weigand
Don Breazeal
Kyrylo Tkachov