In https://sourceware.org/ml/gdb-patches/2016-07/msg00152.html,
Yao noted that a patch of mine was missing a newline.
I thought I had fixed this but when looking today I realized it was
not fixed. This patch adds it.
I'm checking this in as obvious.
2016-07-14 Tom Tromey <tom@tromey.com>
* python/py-breakpoint.c (gdbpy_breakpoint_deleted): Add missing
newline.
This patch consolidates the (possibly-questionable) spots where we
remove a declaration but continue to call some function for side
effects. In a couple of cases it wasn't entirely clear to me that
this mattered; and in some other cases it might be more aesthetically
pleasing to use ATTRIBUTE_UNUSED. So, I broke this out into a
separate patch for simpler review.
2016-07-14 Tom Tromey <tom@tromey.com>
* arch-utils.c (default_skip_permanent_breakpoint): Remove
"bp_insn".
* disasm.c (do_assembly_only): Remove "num_displayed".
* dwarf2read.c (read_abbrev_offset): Remove "length".
(dwarf_decode_macro_bytes) <DW_MACINFO_vendor_ext>: Remove
"constant".
* m32c-tdep.c (make_regs): Remove "r2hl", "r3hl", and "intbhl".
* microblaze-tdep.c (microblaze_frame_cache): Remove "func".
* tracefile.c (trace_save): Remove "status".
This patch removes some unneeded initializations in overlay code in
symfile.c. It also deletes some old commented-out code.
2016-07-14 Tom Tromey <tom@tromey.com>
* symfile.c (simple_overlay_update_1): Remove initialization
of "size", and commented-out code.
(simple_overlay_update): Likewise.
As suggested by Pedro, this changes a few spots to use getcurx, rather
than getyx. This avoids some unused variable warnings.
2016-07-14 Tom Tromey <tom@tromey.com>
* tui/tui-winsource.c (tui_show_source_line): Use getcurx.
* tui/tui-io.c (tui_puts): Use getcurx.
(tui_redisplay_readline): Likewise.
One spot needed ATTRIBUTE_UNUSED to cope with the new warnings.
The case in inflow.c is just a mass of ifdefs; and while the only use
of "result" is guarded by "#if 0", I thought it simplest to leave it
all in place.
2016-07-14 Tom Tromey <tom@tromey.com>
* inflow.c (child_terminal_ours_1): Use ATTRIBUTE_UNUSED.
This seems to be a real bug found by -Wunused-but-set-variable. If
"stat" fails for some reason, gdb would use the uninitialized "st".
2016-07-14 Tom Tromey <tom@tromey.com>
* corefile.c (reopen_exec_file): Only examine st.st_mtime if stat
succeeded.
This patch adds some breakpoint events to Python. In particular,
there is a creation event that is emitted when a breakpoint is
created; a modification event that is emitted when a breakpoint
changes somehow; and a deletion event that is emitted when a
breakpoint is deleted.
In this patch, the event's payload is the breakpoint itself. I
considered making a new event type to hold the breakpoint, but I
didn't see a need. Still, I thought I would mention this as a spot
where some other choice is possible.
Built and regtested on x86-64 Fedora 23.
2016-07-13 Tom Tromey <tom@tromey.com>
PR python/15620, PR python/18620:
* python/py-evts.c (gdbpy_initialize_py_events): Call
add_new_registry for new events.
* python/py-events.h (events_object) <breakpoint_created,
breakpoint_deleted, breakpoint_modified>: New fields.
* python/py-breakpoint.c (gdbpy_breakpoint_created): Emit the
breakpoint changed event.
(gdbpy_breakpoint_deleted): Emit the breakpoint deleted event.
(gdbpy_breakpoint_modified): New function.
(gdbpy_initialize_breakpoints): Attach to the breakpoint modified
observer.
2016-07-13 Tom Tromey <tom@tromey.com>
PR python/15620, PR python/18620:
* python.texi (Events In Python): Document new breakpoint events.
2016-07-13 Tom Tromey <tom@tromey.com>
PR python/15620, PR python/18620:
* gdb.python/py-breakpoint.exp (connect_event, check_last_event)
(test_bkpt_events): New procs.
This patch adds a "pending" attribute to gdb.Breakpoint.
Built and regtested on x86-64 Fedora 23.
2016-07-13 Tom Tromey <tom@tromey.com>
PR python/17698:
* NEWS: Update.
* python/py-breakpoint.c (bppy_get_pending): New function.
(breakpoint_object_getset): Add entry for "pending".
* breakpoint.h (pending_breakpoint_p): Declare.
* breakpoint.c (pending_breakpoint_p): New function.
2016-07-13 Tom Tromey <tom@tromey.com>
PR python/17698:
* python.texi (Breakpoints In Python): Document
Breakpoint.pending.
2016-07-13 Tom Tromey <tom@tromey.com>
PR python/17698:
* gdb.python/py-breakpoint.exp (test_bkpt_basic): Add "pending"
test.
(test_watchpoints): Likewise.
(test_bkpt_pending): New proc.
I noticed that bppy_get_visibility and gdbpy_breakpoint_created
implemented their own visibility checks, but subtly different from
user_breakpoint_p. I think the latter is more correct, and so changed
the Python code to use it.
I suspect there isn't a decent way to test this, so no new test.
Built and regtested on x86-64 Fedora 23.
2016-07-13 Tom Tromey <tom@tromey.com>
* python/py-breakpoint.c (bppy_get_visibility)
(gdbpy_breakpoint_created): Use user_breakpoint_p.
I noticed that the Python breakpoint documentation was ordered a bit
oddly. It documented the constructor; then the stop method; then the
watchpoint constants (used for the constructor); then various other
methods and attributes; then the other constants used by the
constructor; and then finally some more methods and attributes.
This patch rearranges the node a little to move the constants to just
after the constructor and before the other methods and attributes.
2016-07-13 Tom Tromey <tom@tromey.com>
* python.texi (Breakpoints In Python): Move table of types and
table of watchpoint types earlier in node.
PR cli/18053 concerns a couple of minor bugs in the JIT debuginfo
support. First, jit-reader-load should use filename completion and
support tilde expansion. Second, the help for jit-reader-unload is
incorrect. While working on this I also realized that
jit-reader-unload should use the no-op completer, so I've included
that as well.
Built and regtested on x86-64 Fedora 23. A completer test for
jit-reader-load is included, but not a tilde-expansion test, as I
couldn't think of a reliable way to test that.
2016-07-13 Tom Tromey <tom@tromey.com>
PR cli/18053:
* jit.c (jit_reader_load_command): Use tilde_expand.
(_initialize_jit): Fix help for jit-reader-unload. Set completer
for new commands.
2016-07-13 Tom Tromey <tom@tromey.com>
PR cli/18053:
* gdb.base/jit-so.exp (one_jit_test): Add jit-reader-load
completion test.
Marin Cermak has found various testcases (or one of them) of GDB FAIL on
ppc64.
https://sourceware.org/bugzilla/show_bug.cgi?id=20328
.o contained only the function descriptor address.
The DWARF as produced by Tcl Dwarf::assemble:
<1><27>: Abbrev Number: 4 (DW_TAG_subprogram)
<28> DW_AT_name : main
<2d> DW_AT_external : 1
<2e> DW_AT_low_pc : 0x1001ff98
<36> DW_AT_high_pc : 0x1002ff98
<2><3e>: Abbrev Number: 5 (DW_TAG_lexical_block)
Runtime info:
$2 = {<text variable, no debug info>} 0x10000674 <.main>
$3 = {void ()} 0x1001ff98 <main>
On Tue, 12 Jul 2016 15:22:49 +0200, Ulrich Weigand wrote:
Well, most of the gdb.dwarf2 test cases simply use explicitly placed labels
for the DW_AT_low_pc / DW_AT_high_pc attributes.
See e.g. dw2-unresolved-main.c:
asm (".globl cu_text_start");
asm ("cu_text_start:");
On Wed, 13 Jul 2016 10:54:00 +0200, Jan Kratochvil wrote:
Now I see I should not do that because:
lib/dwarf.exp:
proc function_range { func src } {
So I am providing this patch.
gdb/testsuite/ChangeLog
2016-07-13 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.dwarf2/atomic-type.exp: Use function_range for low_pc and high_pc.
* gdb.dwarf2/atomic.c (f): Rename f_end_lbl to f_label.
* gdb.dwarf2/dw2-bad-mips-linkage-name.c (f): Rename f_end_lbl to
f_label.
(g): Rename g_end_lbl to g_label.
* gdb.dwarf2/dw2-bad-mips-linkage-name.exp: Use function_range for
low_pc and high_pc.
* gdb.dwarf2/dw2-lexical-block-bare.exp: Likewise.
PR python/19293 notes that when a Python unwinder is disabled, the
frame cache is not invalidated. This means that disabling an unwinder
doesn't have any immediate effect -- but in my experience it's often
the case that I want to enable or disable an unwinder in order to see
what happens.
This patch adds a new gdb.invalidate_cached_frames function and
arranges for the relevant bits of library code to call it. I've only
partially documented this function, considering a warning sufficient
without going into all the reasons ordinary code should not call it.
The name of the new function was taken from a comment in frame.h next
to reinit_frame_cache.
No new test as I think the updates to the existing test are sufficient
to show that the code is working as intended.
Built and regtested on x86-64 Fedora 23.
2016-07-12 Tom Tromey <tom@tromey.com>
PR python/19293:
* python/lib/gdb/command/unwinders.py (do_enable_unwinder): Call
gdb.invalidate_cached_frames.
* python/lib/gdb/unwinder.py (register_unwinder): Call
gdb.invalidate_cached_frames.
* python/python.c (gdbpy_invalidate_cached_frames): New function.
(python_GdbMethods): Add entry for invalidate_cached_frames.
2016-07-12 Tom Tromey <tom@tromey.com>
PR python/19293:
* python.texi (Frames In Python): Document
gdb.invalidate_cached_frames.
2016-07-12 Tom Tromey <tom@tromey.com>
PR python/19293:
* gdb.python/py-unwind-maint.exp: Update tests.
In gdb.gdb/observer.exp, I see the following fail,
(gdb) break captured_main^M
Breakpoint 1 at 0x57e409: file ../../binutils-gdb/gdb/main.c, line 492.^M
(gdb) PASS: gdb.gdb/observer.exp: breakpoint in captured_main
run -nw -nx -data-directory /home/yao.qi/SourceCode/gnu/build/gdb/testsuite/../data-directory^M
Starting program: /home/yao.qi/SourceCode/gnu/build/gdb/testsuite/outputs/gdb.gdb/observer/xgdb -nw -nx -data-directory /home/yao.qi/SourceCode/gnu/build/gdb/testsuite/../data-directory^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".^M
^M
Breakpoint 1, gdb_main (args=args@entry=0x7fffffffdca0) at ../../binutils-gdb/gdb/main.c:1157^M
1157 captured_main (args);^M
(gdb) FAIL: gdb.gdb/observer.exp: run until breakpoint at captured_main
looks the test sets breakpoint on captured_main, and expects program
stops at captured_main. However, program stops at the place where
captured_main is called, because captured_main is inlined,
<1><8519e3>: Abbrev Number: 58 (DW_TAG_subprogram)
<8519e4> DW_AT_name : (indirect string, offset: 0x880d3): captured_main
<8519e8> DW_AT_decl_file : 1
<8519e9> DW_AT_decl_line : 444
<8519eb> DW_AT_type : <0x846e48>
<8519ef> DW_AT_inline : 1 (inlined)
<8519f0> DW_AT_sibling : <0x851c01>
The test passes if I build GDB with '-O0 -g3', because captured_main
isn't inlined. This patch is to match the output when captured_main
is inlined.
gdb/testsuite:
2016-07-12 Yao Qi <yao.qi@linaro.org>
* lib/selftest-support.exp (selftest_setup): Match the output
when captured_main is inlined.
Compiler complains about possible utilization of "symbol" which is member
of lang_def.
Initialization was added.
2016-07-07 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/ChangeLog:
* cp-namespace.c (cp_lookup_bare_symbol): Initialize
lang_this.symbol.
Using the default lookup for the symbol "this" might lead to segmentation
fault in GDB.
Some languages, e.g. Fortran, use as default lookup routine the C++
routines.
For those languages "this" can be the instance of a class or even the
definition of a class.
When an instance of a class having the name "this" is evaluated
in GDB a segmentation fault was observed.
As example of the issue take into consideration the Fortran code:
type foo
real :: a
type(bar) :: x
character*7 :: b
end type foo
type(foo) :: this
Issue appears when evaluating the variable "this" in GDB.
Within the language definition structure there is a field that represents
the name of the special symbol used for the C++ "this" for the language
being described.
The fix presented here takes into account the aforementioned field. In the
case the aforementioned field is NULL "this" is not represented in the
language described and the lookup should return a null_block_symbol.
Tests: Performed tests with gfortran and ifort.
Reviewed:
https://sourceware.org/ml/gdb-patches/2016-04/msg00068.html
After the commited patch:
https://sourceware.org/ml/gdb-patches/2016-06/msg00364.html
Patch can be applied.
2016-06-16 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/ChangeLog:
* cp-namespace.c (cp_lookup_bare_symbol): Use language passed as
parameter to look for the symbol "this".
gdb/testsuite/ChangeLog:
* gdb.fortran/derived-types.exp (result_line, result_line_2):
New variables.
(print this%a, print this%b, print this): New tests.
* gdb.fortran/derived-types.f90 (this): New object and
initialization.
The output of Ada tests create a layout where the test name
("formatted_ref" in this example) appears twice:
outputs
└── gdb.ada
└── formatted_ref
└── formatted_ref
├── b~formatted_ref.adb
├── b~formatted_ref.ads
├── b~formatted_ref.ali
├── b~formatted_ref.o
├── defs.ali
├── defs.o
├── formatted_ref
├── formatted_ref.ali
└── formatted_ref.o
This causes a problem when testing with the native-gdbserver board, when
the binary has the same name as the test. When gdb_remote_download is
called to upload the compiled binary, the implementation for
native-gdbserver copies it in the standard output directory (in
outputs/gdb.ada/formatted_ref). However, there is already a directory
named formatted_ref in there, so the copy fails and gdbserver isn't able
to load the binary.
This patch bypasses the problem by removing the extra directory level.
The compiled binary will already be in its final location in the
standard output directory, so the copy will effectively be a no-op.
gdb/testsuite/ChangeLog:
* lib/ada.exp: Remove extra directory level in build directory.
* gdb.ada/cond_lang.exp: Likewise.
* gdb.ada/exec_changed.exp: Likewise.
* gdb.ada/lang_switch.exp: Likewise.
Since CORE_ADDR is unsigned, the saved FP register is always greater than
or equal to zero. Replace the comparison by explicitly setting uses_fp to
1 for frames with a valid FP register.
gdb/ChangeLog:
* sh64-tdep.c (sh64_analyze_prologue): Set "uses_fp" when setting
the MEDIA_FP_REGNUM register.
Since CORE_ADDR is unsigned, this value can never be negative.
gdb/ChangeLog:
* score-tdep.c (score7_malloc_and_get_memblock): Remove check for
negative size.
When GDB determines whether type T can be part of candidate for
passing and returning in VFP registers, it calls
arm_vfp_cprc_sub_candidate recursively. However, if type T has
self-reference field, like,
class C
{
static C s;
};
arm_vfp_cprc_sub_candidate won't return. This fix is to skip calling
arm_vfp_cprc_sub_candidate if the field is static.
gdb:
2016-07-06 Yao Qi <yao.qi@linaro.org>
* arm-tdep.c (arm_vfp_cprc_sub_candidate): Don't call
arm_vfp_cprc_sub_candidate for static field.
This will be useful for dealing with vectors; regardless of our final solution
for the Index trait.
2016-07-06 Manish Goregaokar <manish@mozilla.com>
gdb/ChangeLog:
* rust-lang.c (rust_subscript): Allow subscripting pointers
gdb/testsuite/ChangeLog:
* simple.rs: Add test for raw pointer subscripting
* simple.exp: Add test expectations
Commit 38b022b445 adds "method" and
"format" fields in =record-started, but doesn't update test case
gdb.mi/mi-reverse.exp, so it causes the fail like this,
PASS: gdb.mi/mi-reverse.exp: mi runto main
Expecting: ^(-interpreter-exec console record[^M
]+)?(=record-started,thread-group="i1"^M
\^done[^M
]+[(]gdb[)] ^M
[ ]*)
-interpreter-exec console record^M
=record-started,thread-group="i1",method="full"^M
^done^M
(gdb) ^M
FAIL: gdb.mi/mi-reverse.exp: Turn on process record
and regression was found by buildbot too
https://sourceware.org/ml/gdb-testers/2016-q2/msg04492.html
gdb/testsuite:
2016-07-05 Yao Qi <yao.qi@linaro.org>
* gdb.mi/mi-reverse.exp: Match =record-started output.
Some analysis we did here showed that increasing the cap on the
transfer size in target.c:memory_xfer_partial could give 20% or more
improvement in remote load across JTAG. Transfer sizes were capped
to 4K bytes because of performance problems encountered with the
restore command, documented here:
https://sourceware.org/ml/gdb-patches/2013-07/msg00611.html
and in commit 67c059c29e ("Improve performance of large restore
commands").
The 4K cap was introduced because in a case where the restore command
requested a 100MB transfer, memory_xfer_partial would repeatedy
allocate and copy an entire 100MB buffer in order to properly handle
breakpoint shadow instructions, even though memory_xfer_partial would
actually only write a small portion of the buffer contents.
A couple of alternative solutions were suggested:
* change the algorithm for handling the breakpoint shadow instructions
* throttle the transfer size up or down based on the previous actual
transfer size
I tried implementing the throttling approach, and my implementation
reduced the performance in some cases.
This patch implements a new target function that returns that target's
limit on memory transfer size. It defaults to ULONGEST_MAX bytes,
because for native targets there is no marshaling and thus no limit is
needed. For remote targets it uses get_memory_write_packet_size.
gdb/ChangeLog:
* remote.c (remote_get_memory_xfer_limit): New function.
* target-delegates.c: Regenerate.
* target.c (memory_xfer_partial): Call
target_ops.to_get_memory_xfer_limit.
* target.h (struct target_ops)
<to_get_memory_xfer_limit>: New member.
FreeBSD does not currently report a ptrace event for a parent process
after it resumes due to the child exiting the shared memory region after
a vfork. Take the same approach used in linux-nat.c in this case of
sleeping for a while and then reporting a fake VFORK_DONE event.
gdb/ChangeLog:
* fbsd-nat.c (struct fbsd_fork_child_info): Rename to ...
(struct fbsd_fork_info): ... this.
(struct fbsd_fork_info) <child>: Rename to ...
(struct fbsd_fork_info) <ptid>: ... this.
(fbsd_pending_children): Update type.
(fbsd_remember_child): Update type and field name.
(fbsd_is_child_pending): Likewise.
(fbsd_pending_vfork_done): New variable.
(fbsd_is_vfork_done_pending): New function.
(fbsd_next_vfork_done): New function.
(fbsd_resume): Don't resume processes with a pending vfork done
event.
(fbsd_wait): Report pending vfork done events.
(fbsd_follow_fork): Delay and record a pending vfork done event
for a vfork parent when detaching the child.
Only detach from the new child process in the follow fork callback
if detach_fork is true.
gdb/ChangeLog:
* fbsd-nat.c (fbsd_follow_fork): Only detach child if
"detach_fork" is true.
Move the debug register support code from amd64bsd-nat.c and
i386bsd-nat.c into a shared x86bsd-nat.c.
Instead of setting up x86_dr_low in amd64fbsd-nat.c and
i386fbsd-nat.c, add a x86bsd_target function that creates a new target
that inherits from inf_ptrace and sets up x86 debug registers if
supported. In addition to initializing x86_dr_low, the x86bsd target
installs a custom mourn_inferior target operation to clean up the
x86 debug register state. Previously this was only done on amd64.
Now it will be done for both i386 and amd64. The i386bsd_target and
amd64bsd_target functions create targets that inherit from x86bsd
rather than inf_ptrace.
gdb/ChangeLog:
* Makefile.in [HFILES_NO_SRCDIR]: Replace 'amd64bsd-nat.h' with
'x86bsd-nat.h'.
* amd64bsd-nat.c: Include 'x86bsd-nat.h' instead of
'amd64bsd-nat.h'.
(amd64bsd_xsave_len): Rename and move to x86bsd-nat.c.
(amd64bsd_fetch_inferior_registers): Replace 'amd64bsd_xsave_len'
with 'x86bsd_xsave_len'.
(amd64bsd_store_inferior_registers): Likewise.
(amd64bsd_target): Inherit from x86bsd_target.
(amd64bsd_dr_get): Rename and move to x86bsd-nat.c.
(amd64bsd_dr_set): Likewise.
(amd64bsd_dr_set_control): Likewise.
(amd64bsd_dr_set_addr): Likewise.
(amd64bsd_dr_get_addr): Likewise.
(amd64bsd_dr_get_status): Likewise.
(amd64bsd_dr_get_control): Likewise.
* amd64fbsd-nat.c: Include 'x86bsd-nat.h' instead of
'amd64bsd-nat.h'.
(super_mourn_inferior): Move to x86bsd-nat.c.
(amd64fbsd_mourn_inferior): Rename and move to x86bsd-nat.c.
(amd64fbsd_read_description): Replace 'amd64bsd_xsave_len' with
'x86bsd_xsave_len'.
(_initialize_amd64fbsd_nat): Remove x86 watchpoint setup and
mourn_inferior' target op.
* config/i386/fbsd.mh (NATDEPFILES): Add x86bsd-nat.o.
* config/i386/fbsd64.mh: Likewise.
* config/i386/nbsd64.mh: Likewise.
* config/i386/nbsdelf.mh: Likewise.
* config/i386/obsd.mh: Likewise.
* config/i386/obsd64.mh: Likewise.
* i386bsd-nat.c: Include 'x86bsd-nat.h'.
(i386bsd_xsave_len): Rename and move to x86bsd-nat.c.
(i386bsd_fetch_inferior_registers): Replace 'i386bsd_xsave_len'
with 'x86bsd_xsave_len'.
(i386bsd_store_inferior_registers): Likewise.
(i386bsd_target): Inherit from x86bsd_target.
(i386bsd_dr_get): Rename and move to x86bsd-nat.c.
(i386bsd_dr_set): Likewise.
(i386bsd_dr_set_control): Likewise.
(i386bsd_dr_set_addr): Likewise.
(i386bsd_dr_get_addr): Likewise.
(i386bsd_dr_get_status): Likewise.
(i386bsd_dr_get_control): Likewise.
* i386bsd-nat.h (i386bsd_xsave_len): Remove.
(i386bsd_dr_set_control): Remove.
(i386bsd_dr_set_addr): Remove.
(i386bsd_dr_get_addr): Remove.
(i386bsd_dr_get_status): Remove.
(i386bsd_dr_get_control): Remove.
* i386fbsd-nat.c: Include 'x86bsd-nat.h'.
(i386fbsd_read_description): Replace 'i386bsd_xsave_len' with
'x86bsd_xsave_len'.
(_initialize_i386fbsd_nat): Remove x86 watchpoint setup and
mourn_inferior' target op.
* x86bsd-nat.c: New file.
* x86bsd-nat.h: New file.
The jit-reader.exp test isn't really exercising the jit-reader's
unwinder API at all. This commit address that, and then fixes GDB
problems exposed.
- The custom JIT reader provided for the jit-reader.exp testcase
always rejects the jitted function's frame...
This is because the custom JIT reader in the testcase never ever
sets state->code_begin/end, so the bounds check in
gdb.base/jitreader.c:unwind_frame:
if (this_ip >= state->code_end || this_ip < state->code_begin)
return GDB_FAIL;
tends to fail, unless you're "lucky" (because it references
uninitialized data).
The result is that GDB is always actually using a built-in unwinder
for the jitted function.
- The provided unwinder doesn't do anything that GDB's built-in
unwinder can't do.
IOW, we can't really tell whether the JIT reader's unwinder is
working or not.
I fixed that by making the jitted function mangle its own stack
pointer with a xor, and then teaching the jit unwinder to demangle
it back (another xor). So now "backtrace" with GDB's built-in
unwinder fails while with the jit unwinder, it succeeds.
- GDB crashes after unloading the JIT reader, and flushing frames...
I made the testcase use the "flushregs" command after unloading the
JIT reader, to force the JIT frames to be flushed. However, that
crashes GDB...
When reinit_frame_cache tears down a frame's cache, it calls its
unwinder's dealloc_cache method, which for JIT frames ends up in
jit.c:jit_dealloc_cache. This function calls each of the frame's
gdb_reg_value's "free" pointer:
for (i = 0; i < gdbarch_num_regs (frame_arch); i++)
if (priv_data->registers[i] && priv_data->registers[i]->free)
priv_data->registers[i]->free (priv_data->registers[i]);
and the problem is these gdb_reg_value instances have been returned
by the JIT reader that has been already unloaded, and their "free"
function pointers likely point to functions in the DSO that has
already been unloaded...
A fix for that could be to call reinit_frame_cache in
jit_reader_unload_command _before_ unloading the jit reader DSO so
that the jit reader is given a chance to clean up the gdb_reg_values
before it is unloaded. However, the fix for the point below makes
this unnecessary, because it stops jit.c from keeping around
gdb_reg_values in the first place.
- However, it still makes sense to clear the frame cache when loading
or unloading a JIT unwinder.
This makes testing a JIT unwinder a bit simpler.
- Not only the frame cache actually -- gdb is not unloading the
jit-registered objfiles when the JIT reader is unloaded, and not
loading the already-registered descriptors when a JIT reader is
loaded.
The new test exercises unloading the jit reader, loading it back
again, and then making sure the JIT reader's unwinder works again.
Without the unload/re-load of already-read descriptors, the newly
loaded JIT would have no idea where the new function is, because
it's stored at symbol read time.
- I added a couple "info frame" calls to the test, and that
crashes GDB...
The problem is that jit_frame_prev_register assumes it'll only be
called for raw registers, so when it gets a pseudo register number,
the "priv->registers[reg]" access is really an out-of-bounds access.
To fix that, I made jit_frame_prev_register use
gdbarch_pseudo_register_read_value for reading the pseudo-registers.
However, that works with a regcache and we don't have one. To fix
that, I made the JIT unwinder store a regcache in its cache instead
of an array of gdb_reg_value pointers.
gdb/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
Tom Tromey <tom@tromey.com>
* jit.c (jit_reader_load_command): Call reinit_frame_cache and
jit_inferior_created_hook.
(jit_reader_unload_command): Call reinit_frame_cache and
jit_inferior_exit_hook.
* jit.c (struct jit_unwind_private) <registers>: Delete field.
<regcache>: New field.
(jit_unwind_reg_set_impl): Set the register's value in the
regcache. Free the passed-in gdb_reg_value.
(jit_dealloc_cache): Adjust to free the regcache.
(jit_frame_sniffer): Allocate a regcache instead of an array of
gdb_reg_value pointers.
(jit_frame_this_id): Adjust.
(jit_frame_prev_register): Read raw registers off of the regcache
instead of from the gdb_reg_value pointer array. Use
gdbarch_pseudo_register_read_value to read pseudo registers.
* regcache.c (regcache_raw_set_cached_value): New function,
factored out from ...
(regcache_raw_write): ... here.
* regcache.h (regcache_raw_set_cached_value): Declare.
gdb/testsuite/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
* gdb.base/jit-reader.exp (info_registers_current_frame): New
procedure.
(jit_reader_test): Test the jit reader's unwinder.
* gdb.base/jithost.c (jit_function_00_code): New global.
(main): Use memcpy to fill in the mmapped code, instead of poking
bytes manually here.
* gdb.base/jitreader.c (enum register_mapping) <AMD64_RBP>: New
value.
(read_debug_info): Save the function's range.
(read_sp): New function.
(unwind_frame): Use it. Also unwind RBP.
(get_frame_id): Use read_sp.
(gdb_init_reader): Use calloc instead of malloc.
* lib/gdb.exp (get_hexadecimal_valueof): Add optional 'test'
parameter. Use gdb_test_multiple.
This commit fixes detaching on Linux when some thread exits the whole
thread group (process) just while we're detaching.
On Linux, a ptracer must detach from each LWP individually, with
PTRACE_DETACH. Since PTRACE_DETACH sets the thread running free, if
one of the already-detached threads causes the whole thread group to
exit (e.g., simply calls exit), the kernel force-kills the other
threads in the group, making them zombie, just as we're still
detaching them. Since PTRACE_DETACH against a zombie thread fails
with ESRCH, and gdb/gdbserver are not expecting this, the detach fails
with an error like: "Can't detach process: No such process.".
This patch detects this detach failure as normal, and instead of
erroring out, reaps the now-dead thread.
New test included, that exercises several different scenarios that
cause GDB/GDBserver to error out when it should not.
Tested on x86-64 GNU/Linux with {unix, native-gdbserver,
native-extended-gdbserver}
Note: without the previous fix, the "single-process + continue"
variant of the new test would fail with:
(gdb) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: switch to parent
continue
Continuing.
Warning:
Could not insert hardware watchpoint 3.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
Command aborted.
(gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: continue
gdb/gdbserver/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
Antoine Tremblay <antoine.tremblay@ericsson.com>
* linux-low.c: Change interface to take the target lwp_info
pointer directly and return void. Handle detaching from a zombie
thread.
(linux_detach_lwp_callback): New function.
(linux_detach): Detach from the leader thread after detaching from
the clone threads.
gdb/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
Antoine Tremblay <antoine.tremblay@ericsson.com>
* inf-ptrace.c (inf_ptrace_detach_success): New function, factored
out from ...
(inf_ptrace_detach): ... here.
* inf-ptrace.h (inf_ptrace_detach_success): New declaration.
* linux-nat.c (get_pending_status): Rename to ...
(get_detach_signal): ... this, and return a host signal instead of
filling in a wait status.
(detach_one_lwp): New function, factored out from detach_callback
and adjusted to handle detaching from a zombie thread.
(detach_callback): Skip the leader thread.
(linux_nat_detach): No longer defer to inf_ptrace_detach to detach
the leader thread, nor build a signal string to pass down.
Instead, use target_announce_detach, detach_one_lwp and
inf_ptrace_detach_success.
gdb/testsuite/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
Antoine Tremblay <antoine.tremblay@ericsson.com>
* gdb.threads/process-dies-while-detaching.c: New file.
* gdb.threads/process-dies-while-detaching.exp: New file.
If you have two inferiors (or more), set watchpoints in one of the
inferiors, and then that inferior exits, until you manually delete the
watchpoint (or something forces a breakpoint re-set), you can't resume
the other inferior.
This is exercised by the test added by this commit. Without the GDB
fix, this test fails like this:
FAIL: gdb.multi/watchpoint-multi-exit.exp: dispose=kill: continue to marker in inferior 1
FAIL: gdb.multi/watchpoint-multi-exit.exp: dispose=detach: continue to marker in inferior 1
FAIL: gdb.multi/watchpoint-multi-exit.exp: dispose=exit: continue to marker in inferior 1
and gdb.log shows (in all three cases):
(gdb) continue
Continuing.
Warning:
Could not insert hardware watchpoint 2.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
Command aborted.
(gdb) FAIL: gdb.multi/watchpoint-multi-exit.exp: dispose=kill: continue to marker in inferior 1
The problem is that GDB doesn't forget about the locations of
watchpoints set in the inferior that is now dead. When we try to
continue the inferior that is still alive, we reach
insert_breakpoint_locations, which has the the loop that triggers the
error:
/* If we failed to insert all locations of a watchpoint, remove
them, as half-inserted watchpoint is of limited use. */
That loop finds locations that are not marked inserted, but which
according to should_be_inserted should have been inserted, and so
errors out.
gdb/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
* breakpoint.c (breakpoint_init_inferior): Discard watchpoint
locations.
* infcmd.c (detach_command): Call breakpoint_init_inferior.
gdb/testsuite/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
* gdb.multi/watchpoint-multi-exit.c: New file.
* gdb.multi/watchpoint-multi-exit.exp: New file.
Several targets have a copy of the same code that prints
"Detaching from program ..."
in their target_detach implementation. Factor that out to a common
function.
(For now, I left the couple targets that print this a bit differently
alone. Maybe this could be further pulled out into infcmd.c. If we
did that, and those targets want to continue printing differently,
this new function could be converted to a target method.)
gdb/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
* darwin-nat.c (darwin_detach): Use target_announce_detach.
* inf-ptrace.c (inf_ptrace_detach): Likewise.
* nto-procfs.c (procfs_detach): Likewise.
* remote.c (remote_detach_1): Likewise.
* target.c (target_announce_detach): New function.
* target.h (target_announce_detach): New declaration.
Commit 51f77c3704 ("Add testing infrastruture bits for running with
MI on a separate UI") broke MI testing with native-gdbserver:
$ make check RUNTESTFLAGS="--target_board=native-gdbserver mi-var-child.exp"
...
Running .../src/binutils-gdb/gdb/testsuite/gdb.mi/mi-var-child.exp ...
can't unset "inferior_spawn_id": no such variable
while executing
"unset inferior_spawn_id"
(procedure "close_gdbserver" line 20)
invoked from within
"close_gdbserver"
...
When testing with gdbserver, gdb_exit is overridden with a special
version that calls close_gdbserver, which clears inferior_spawn_id.
The problem is that the commit mentioned above made
gdb_exit/mi_gdb_exit clear inferior_spawn_id too, and clearing a
non-existing variable is a tcl error.
Since gdb_exit/mi_gdb_exit always clears inferior_spawn_id now, the
fix is simply to stop clearing it in close_gdbserver.
gdb/testsuite/
2016-06-30 Pedro Alves <palves@redhat.com>
* lib/gdbserver-support.exp (close_gdbserver, gdb_exit): Don't
unset inferior_spawn_id.
Runing the whole gdb testsuite with MI on a separate tty, with:
make check RUNTESTFLAGS="FORCE_SEPARATE_MI_TTY=1"
Doesn't actually work because commit 51f77c3704 ("Add testing
infrastruture bits for running with MI on a separate UI") included a
last-minute rename typo, now fixed with this commit.
gdb/testsuite/ChangeLog:
2016-06-30 Pedro Alves <palves@redhat.com>
* lib/mi-support.exp (default_mi_gdb_start): Declare global
FORCE_SEPARATE_MI_TTY, not SEPARATE_MI_TTY.
PR python/20129 concerns the error message one gets from a command
like "disable frame-filter global NoSuchFilter". Currently this
throws a second, unexpected, exception due to the use of a
non-existing variable named "name".
This patch adds regression tests and fixes a couple of spots to use
the correct variable name.
Built and regtested on x86-64 Fedora 23.
2016-06-29 Tom Tromey <tom@tromey.com>
PR python/20129:
* python/lib/gdb/command/frame_filters.py (_do_enable_frame_filter)
(SetFrameFilterPriority._set_filter_priority): Use "frame_filter",
not "name".
2016-06-29 Tom Tromey <tom@tromey.com>
PR python/20129:
* gdb.python/py-framefilter.exp: Add tests for setting priority
and disabling of non-existent frame filter.
PR gdb/17210 concerns a possible memory leak in read_memory_robust.
The bug can happen because read_memory_robust allocates memory, does
not install any cleanups, and invokes QUIT. Similarly, target_read
calls QUIT, so it too can potentially throw.
The fix is to install cleanups to guard the allocated memory.
Built and regtested on x86-64 Fedora 23. I couldn't think of a way to
test this, so no new test; and of course this means it should have
more careful review.
2016-06-29 Tom Tromey <tom@tromey.com>
PR gdb/17210:
* target.c (free_memory_read_result_vector): Take a pointer to the
VEC as an argument.
(read_memory_robust): Install a cleanup for "result".
* mi/mi-main.c (mi_cmd_data_read_memory_bytes): Update.
Building gdb with --enable-build-with-cxx=no trips on a warning:
../../binutils-gdb/gdb/rust-lang.c:173:15: error: saveptr may be used
uninitialized in this function [-Werror=maybe-uninitialized]
ret.name = concat (TYPE_NAME (type), "::", token, (char *) NULL);
The problem is that gcc doesn't understand that "tail" can never be
NULL in the call to strtok_r:
name = xstrdup (TYPE_FIELD_NAME (type, 0));
cleanup = make_cleanup (xfree, name);
tail = name + strlen (RUST_ENUM_PREFIX);
...
for (token = strtok_r (tail, "$", &saveptr);
Fix this by always initializing saveptr.
2016-06-29 Manish Goregaokar <manish@mozilla.com>
gdb/ChangeLog:
* rust-lang.c (rust_get_disr_info): Initialize saveptr to NULL.
Currently, we use 123456789 as unknown or illegal syscall number, and
expect program return ENOSYS. Although 123456789 is an illegal syscall
number on arm linux, kernel sends SIGILL rather than returns -ENOSYS.
However, arm linux kernel returns -ENOSYS if syscall number is within
0xf0001..0xf07ff, so we can use 0xf07ff for unknown_syscall in test.
gdb/testsuite:
2016-06-29 Yao Qi <yao.qi@linaro.org>
* gdb.base/catch-syscall.c [__arm__]: Set unknown_syscall to
0x0f07ff.
In AArch64 displaced stepping and fast tracepoint, GDB/GDBserver needs
to check whether the offset can fit in the range. We are using int32_t
for offset, it is sufficient to get an offset from an instruction, but
it is not enough to get an offset from two addresses. For example,
we have a BL in shared lib which is at 0x0000002000040774, and the
scratch pad for displaced stepping is at 0x400698. The offset can't
fit in 28 bit imm. However, since we are using int32_t for offset, GDB
thinks the offset can fit it, and generate the B instruction with wrong
offset.
It fixes the following fail,
-FAIL: gdb.base/dso2dso.exp: next over call to sub2
gdb:
2016-06-28 Yao Qi <yao.qi@linaro.org>
* aarch64-tdep.c (aarch64_displaced_step_b): Use int64_t for
variable new_offset.
gdb/gdbserver:
2016-06-28 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (aarch64_ftrace_insn_reloc_b): Use int64_t
for variable new_offset.
(aarch64_ftrace_insn_reloc_b_cond): Likewise.
(aarch64_ftrace_insn_reloc_cb): Likewise.
(aarch64_ftrace_insn_reloc_tb): Likewise.
(aarch64_install_fast_tracepoint_jump_pad): Likewise. Use
PRIx64 instead of PRIx32.
When I implement linux_target_ops.get_syscall_trapinfo for aarch64 and arm,
I find the second parameter sysret isn't used at all. In RSP, we don't
need syscall return value either, because GDB can figure out the return
value from registers content got by 'g' packet.
This patch is to remove them.
gdb/gdbserver:
2016-06-28 Yao Qi <yao.qi@linaro.org>
* linux-low.c (get_syscall_trapinfo): Remove parameter sysret.
Callers updated.
* linux-low.h (struct linux_target_ops) <get_syscall_trapinfo>:
Remove parameter sysno.
* linux-x86-low.c (x86_get_syscall_trapinfo): Remove parameter
sysret.
In 82075af2c1 (Implement 'catch syscall'
for gdbserver), only x86 is supported, but the test can still be run
on other linux targets, like aarch64 and ppc, with native-gdbserver.
This causes many new fails.
This patch removes the check on isnative and on target triplets.
Instead, we can insert catch point, and resume the program to see whether
catch syscall is supported or not.
gdb/testsuite:
2016-06-28 Yao Qi <yao.qi@linaro.org>
* gdb.base/catch-syscall.exp: Remove check on isnative and target
triplets. Start gdb, execute catch syscall, and continue. Check
gdb's output to determine catch syscall is supported.
Rust prefers to not specify the return type of a function when it is unit
(`()`). The type is also referred to as "void" in debuginfo but not in actual
usage, so we should never be printing "void" when the language is Rust.
2016-06-27 Manish Goregaokar <manish@mozilla.com>
gdb/ChangeLog:
* rust-lang.c (rust_print_type): Print unit types as "()"
* rust-lang.c (rust_print_type): Omit return type for functions
returning unit
gdb/testsuite/ChangeLog:
* gdb.rust/simple.rs: Add test for returning unit in a function
* gdb.rust/simple.exp: Add expectation for functions returning unit
When a Python script tries to create a breakpoint but fails to do so,
gdb.Breakpoint.__init__ raises an exception and the breakpoint does not
exist anymore in the Python interpreter. However, GDB still keeps a
reference to the Python object to be used for a later hook, which is
wrong.
This commit adds the necessary cleanup code so that there is no stale
reference to this Python object. It also adds a new testcase to
reproduce the bug and check the fix.
2016-06-25 Pierre-Marie de Rodat <derodat@adacore.com>
gdb/
* python/py-breakpoint.c (bppy_init): Clear bppy_pending_object
when there is an error during the breakpoint creation.
gdb/testsuite
* gdb.python/py-breakpoint-create-fail.c,
gdb.python/py-breakpoint-create-fail.exp,
gdb.python/py-breakpoint-create-fail.py: New testcase.
This fixes up a few formatting nits in rust-lang.c.
Built and regtested on x86-64 Fedora 23.
2016-06-25 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_get_disr_info, rust_print_type): Fix
formatting.
gdb/testsuite/ChangeLog:
2016-06-25 Manish Goregaokar <manish@mozilla.com>
PR gdb/20239
* gdb.rust/simple.rs: Add more tests for printing NonZero enums.
* gdb.rust/simple.exp: Add test expectations for new NonZero tests.
GDB computes structure byte offsets using a 32 bit integer. And,
first it computes the offset in bits and then converts to bytes. The
result is that any offset that if 512K bytes or larger overflows.
This patch changes GDB to use LONGEST for such calculations.
PR gdb/17520 Structure offset wrong when 1/4 GB or greater.
* c-lang.h: Change all parameters, variables, and struct or union
members used as struct or union fie3ld offsets from int to
LONGEST.
* c-valprint.c: Likewise.
* cp-abi.c: Likewise.
* cp-abi.h: Likewise.
* cp-valprint.c: Likewise.
* d-valprint.c: Likewise.
* dwarf2loc.c: Likewise.
* eval.c: Likewise.
* extension-priv.h: Likewise.
* extension.c: Likewise.
* extension.h: Likewise.
* findvar.c: Likewise.
* gdbtypes.h: Likewise.
* gnu-v2-abi.c: Likewise.
* gnu-v3-abi.c: Likewise.
* go-valprint.c: Likewise.
* guile/guile-internal.h: Likewise.
* guile/scm-pretty-print.c: Likewise.
* jv-valprint.c Likewise.
* opencl-lang.c: Likewise.
* p-lang.h: Likewise.
* python/py-prettyprint.c: Likewise.
* python/python-internal.h: Likewise.
* spu-tdep.c: Likewise.
* typeprint.c: Likewise.
* valarith.c: Likewise.
* valops.c: Likewise.
* valprint.c: Likewise.
* valprint.h: Likewise.
* value.c: Likewise.
* value.h: Likewise.
* p-valprint.c: Likewise.
* c-typeprint.c (c_type_print_base): When printing offset, use
plongest, not %d.
* gdbtypes.c (recursive_dump_type): Ditto.
All platforms on FreeBSD use a shared system call table, so use a
single XML file to describe the system calls available on each FreeBSD
platform.
Recent versions of FreeBSD include the identifier of the current
system call when reporting a system call entry or exit event in the
ptrace_lwpinfo structure obtained via PT_LWPINFO in fbsd_wait. As
such, FreeBSD native targets do not use the gdbarch method to fetch
the system call code. In addition, FreeBSD register sets fetched via
ptrace do not include an equivalent of 'orig_rax' (on amd64 for
example), so the system call code cannot be extracted from the
available registers during a system call exit. However, GDB assumes
that system call catch points are not supported if the gdbarch method
is not present. As a workaround, FreeBSD ABIs install a dummy gdbarch
method that throws an internal_error if it is ever invoked.
gdb/ChangeLog:
* configure.ac: Check for support for system call LWP fields on
FreeBSD.
* config.in, configure: Rebuild.
* data-directory/Makefile.in (SYSCALLS_FILES): Add freebsd.xml.
* fbsd-nat.c (fbsd_wait) [HAVE_STRUCT_PTRACE_LWPINFO_PL_SYSCALL_CODE]:
Report system call events.
[HAVE_STRUCT_PTRACE_LWPINFO_PL_SYSCALL_CODE]
(fbsd_set_syscall_catchpoint): New function.
(fbsd_nat_add_target) [HAVE_STRUCT_PTRACE_LWPINFO_PL_SYSCALL_CODE]:
Set "to_set_syscall_catchpoint" to "fbsd_set_syscall_catchpoint".
* fbsd-tdep.c: Include xml-syscall.h
(fbsd_get_syscall_number): New function.
(fbsd_init_abi): Set XML system call file name.
Add "get_syscall_number" gdbarch method.
* syscalls/freebsd.xml: New file.
Add a 'print_auxv_entry' method for FreeBSD ABIs that parses
FreeBSD-specific auxiliary vector entries and outputs a suitable
description using fprint_auxv_entry.
gdb/ChangeLog:
* fbsd-tdep.c: Include "auxv.h".
(fbsd_print_auxv_entry): New function.
(fbsd_init_abi): Install gdbarch "print_auxv_entry" method.
Different platforms have different meanings for auxiliary vector
entries. The 'print_auxv_entry' gdbarch method allows an architecture
to output a suitable description for platform-specific entries.
A fprint_auxv_entry function is split out of fprint_target_auxv.
This function outputs the description of a single auxiliary vector
entry to the specified file using caller-supplied formatting and
strings to describe the vector type.
The existing switch on auxiliary vector types is moved out of
fprint_target_auxv into a new default_print_auxv_entry function.
default_print_auxv_entry chooses an appropriate format and description
and calls fprint_single_auxv to describe a single vector entry.
This function is used as the default 'print_auxv_entry' gdbarch method.
fprint_target_auxv now invokes the gdbarch 'print_auxv_entry' method
on each vector entry.
gdb/ChangeLog:
* auxv.c (fprint_auxv_entry): New function.
(default_print_auxv_entry): New function.
(fprint_target_auxv): Use gdbarch_print_auxv_entry.
* auxv.h (enum auxv_format): New enum.
(fprint_auxv_entry): Declare.
(default_print_auxv_entry): Declare.
* gdbarch.sh (print_auxv_entry): New.
* gdbarch.c, gdbarch.h: Re-generated.
Use the kern.proc.auxv.<pid> sysctl to fetch the ELF auxiliary vector for
a live process.
gdb/ChangeLog:
* fbsd-nat.c [KERN_PROC_AUXV] New variable super_xfer_partial.
(fbsd_xfer_partial): New function.
(fbsd_nat_add_target) [KERN_PROC_AUXV] Set "to_xfer_partial" to
"fbsd_xfer_partial".
This patch moves most of the demangling logic out of
symbol_find_demangled_name into the various language_defn objects.
The simplest way to do this seemed to be to add a new method to
language_defn. This is shame given the existing la_demangle, but
given Ada's unusual needs, and the differing demangling options
between languages, la_demangle didn't seem to fit.
In order to make this work, I made enum language order-sensitive.
This helps preserve the current ordering of demangling operations.
2016-06-23 Tom Tromey <tom@tromey.com>
* symtab.c (symbol_find_demangled_name): Loop over languages and
use language_sniff_from_mangled_name.
* rust-lang.c (rust_sniff_from_mangled_name): New function.
(rust_language_defn): Update.
* p-lang.c (pascal_language_defn): Update.
* opencl-lang.c (opencl_language_defn): Update.
* objc-lang.c (objc_sniff_from_mangled_name): New function.
(objc_language_defn): Update.
* m2-lang.c (m2_language_defn): Update.
* language.h (struct language_defn) <la_sniff_from_mangled_name>: New
field.
(language_sniff_from_mangled_name): Declare.
* language.c (language_sniff_from_mangled_name): New function.
(unknown_language_defn, auto_language_defn, local_language_defn):
Update.
* jv-lang.c (java_sniff_from_mangled_name): New function.
(java_language_defn): Use it.
* go-lang.c (go_sniff_from_mangled_name): New function.
(go_language_defn): Use it.
* f-lang.c (f_language_defn): Update.
* defs.h (enum language): Reorder.
* d-lang.c (d_sniff_from_mangled_name): New function.
(d_language_defn): Use it.
* cp-support.h (gdb_sniff_from_mangled_name): Declare.
* cp-support.c (gdb_sniff_from_mangled_name): New function.
* c-lang.c (c_language_defn, cplus_language_defn)
(asm_language_defn, minimal_language_defn): Update.
* ada-lang.c (ada_sniff_from_mangled_name): New function.
(ada_language_defn): Use it.
This moves filename extensions from a function in symfile.c out to
each language_defn. I think this is an improvement because it means
less digging around when writing a new language port.
2016-06-23 Tom Tromey <tom@tromey.com>
* ada-lang.c (ada_extensions): New array.
(ada_language_defn): Use it.
* c-lang.c (c_extensions): New array.
(c_language_defn): Use it.
(cplus_extensions): New array.
(cplus_language_defn): Use it.
(asm_extensions): New array.
(asm_language_defn): Use it.
(minimal_language_defn): Update.
* d-lang.c (d_extensions): New array.
(d_language_defn): Use it.
* f-lang.c (f_extensions): New array.
(f_language_defn): Use it.
* go-lang.c (go_language_defn): Update.
* jv-lang.c (java_extensions): New array.
(java_language_defn): Use it.
* language.c (add_language): Call add_filename_language.
(unknown_language_defn, auto_language_defn, local_language_defn):
Update.
* language.h (struct language_defn) <la_filename_extensions>: New
field.
* m2-lang.c (m2_language_defn): Update.
* objc-lang.c (objc_extensions): New array.
(objc_language_defn): Use it.
* opencl-lang.c (opencl_language_defn): Update.
* p-lang.c (p_extensions): New array.
(pascal_language_defn): Use it.
* rust-lang.c (rust_extensions): New array.
(rust_language_defn): Use it.
* symfile.c (add_filename_language): No longer static. Make "ext"
const.
(init_filename_language_table): Remove.
(_initialize_symfile): Update.
* symfile.h (add_filename_language): Declare.
This patch changes filename_language_table to be a VEC. This seemed
like a reasonable cleanup over the old code.
2016-06-23 Tom Tromey <tom@tromey.com>
* symfile.c (filename_language_table): Now a VEC.
(fl_table_size, fl_table_next): Remove.
(add_filename_language): Use VEC_safe_push.
(set_ext_lang_command, info_ext_lang_command)
(deduce_language_from_filename): Use VEC_iterate.
(init_filename_language_table): Use VEC_empty.
While working on the next patch in this series, I noticed that
gdbpy_parameter did not need to be exported. This makes it "static".
2016-06-23 Tom Tromey <tom@tromey.com>
* python/python.c (gdbpy_parameter): Now static.
* python/python-internal.h (gdbpy_parameter): Don't declare.
PR gdb/16483 notes that the output of "info frame-filters" is quite
voluminous. In particular it prints an entry for each objfile, even if
only to say that the objfile does not have any associated frame filters.
I think it's better to only print output when there is a frame filter.
There's nothing worth doing with the no-frame-filter information, and
limiting the output makes it much more readable.
Built and regtested on x86-64 Fedora 23.
2016-06-23 Tom Tromey <tom@tromey.com>
PR gdb/16483:
* python/lib/gdb/command/frame_filters.py
(InfoFrameFilter.list_frame_filters): Rename to print_list. Print
nothing if no filters found. Return value indicating whether
filters were printed.
(InfoFrameFilter.print_list): Remove.
(InfoFrameFilter.invoke): Print message if no frame filters
found.
2016-06-23 Tom Tromey <tom@tromey.com>
PR gdb/16483:
* gdb.python/py-framefilter.exp: Add "info frame-filter" test
before any filters are loaded.
Output for Fortran derived classes is like:
"( 9, 'abc')"
with this changes the output is changed to:
"( lucky_number = 9, letters = 'abc')"
2016-06-21 Walfred Tedeschi <walfred.tedeschi@intel.com>
* f-valprint.c (f_val_print): Add field names for printing
derived types fields.
gdb/testsuite:
* gdb.fortran/derived-type.exp (print q): Add fields to the output.
* gdb.fortran/vla-type.exp (print twov): Fix vla tests with
structs.
* gdb.fortran/derived-type-function.exp: New file.
* gdb.fortran/derived-type-function.f90: New file.
This fixes a typo in the name of the "last-break" regset.
gdb/ChangeLog:
* s390-linux-tdep.c (s390_iterate_over_regset_sections): Fix typo
in name of last-break regset.
This adds a test that uses new-ui to create a secondary console, and
then runs some basic smoke tests. It ensures that:
- synchronous commands send output to the UI that initiated it
- asynchronous events like breakpoint hits are reported on all
consoles.
- "new-ui" without arguments doesn't crash.
- The "new-ui" command doesn't repeat.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.base/new-ui.exp: New file.
* lib/mi-support.exp (switch_gdb_spawn_id): Move to ...
* lib/gdb.exp (switch_gdb_spawn_id): ... here.
(with_spawn_id): New procedure.
The following scenario:
- gdb started in normal CLI mode.
- separate MI channel created with new-ui
- inferior output redirected with the "set inferior-tty" command.
- use -exec-run in the MI channel to run the inferior
is presently mishandled.
When we create the inferior, in fork-child.c, right after vfork, we'll
close all the file descriptors in the vfork child, and then dup the
tty to file descriptors 0/1/2, create a session, etc. Note that when
we close all descriptors, we close the file descriptors behind
gdb_stdin/gdb_stdout/gdb_stderr of all secondary UIs... So if
anything goes wrong in the child and it calls warning/error, it'll end
up writting to the current UI's stdout/stderr streams, which are
backed by file descriptors that have since been closed. Because this
happens in a vfork region, the corresponding stdin/stdout/stderr in
the parent/gdb end up corrupted.
The fix is to switch to the main UI right after the vfork, so that
gdb_stdin/gdb_stdout/gdb_stderr are correctly mapped to
stdin/stdout/stderr (and thus to file descriptors 0/1/2), so this code
works as it has always worked.
(Technically, we're doing a lot of stuff we shouldn't be doing after a
vfork, while we should only be calling async-signal-safe functions.)
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* fork-child.c (fork_inferior): Switch the child to the main UI
right after vfork. Save/restore the current UI in the parent.
Flush outputs of the main UI instead of the current UI.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.mi/mi-exec-run.exp: New file.
mi-break.exp regresses when tested with MI running on a secondary UI,
with RUNTESTFLAGS="FORCE_SEPARATE_MI_TTY=1".
The problem is simply that the test sets a breakpoint, and attaches
"print" commands to the breakpoint. Since breakpoint commands always
run with the main UI as current UI, the breakpoint command's output
goes to the main UI. So we need to tweak the test to expect it there.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.mi/mi-break.exp (test_breakpoint_commands): Always expect
breakpoint command's output on the main UI.
(test_break): New procedure, factored out from calls in the top
level.
(top level): Use foreach_with_prefix to test MI as main UI and as
separate UI.
Testing with:
make check RUNTESTFLAGS="SEPARATE_MI_TTY=1"
shows this, in gdb.mi/mi-watch.exp:
-*stopped,reason="watchpoint-scope",wpnum="2",frame={addr="0x00000000004005cb",
+*stopped,frame={addr="0x00000000004005cb",
(...)
-PASS: gdb.mi/mi-watch.exp: hw: watchpoint trigger
+FAIL: gdb.mi/mi-watch.exp: hw: watchpoint trigger (unknown output after running)
That is, we lose the "watchpoint-scope" output on the MI UI.
This commit fixes it, and makes the test run with MI running as both
main UI and separate UI.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* breakpoint.c (watchpoint_check): Send watchpoint-deleted output
to all UIs.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.mi/mi-watch.exp (test_watchpoint_creation_and_listing)
(test_awatch_creation_and_listing)
(test_rwatch_creation_and_listing, test_watchpoint_triggering):
Remove 'type' parameter.
(test_watchpoint_all): New parameter mi_mode. Remove
with_test_prefix.
(top level): Use foreach_with_prefix, and add main/separate UI MI
testing axis.
With this, a specific test may can start GDB with MI on a separate UI
by using:
mi_gdb_start separate-mi-tty
In addition, it's also possible to run the whole testsuite with MI on
a separate tty, with:
make check RUNTESTFLAGS="FORCE_SEPARATE_MI_TTY=1"
gdb_main_spawn_id and mi_spawn_id are added so that tests may expect
output from either channel.
While at it, inferior_spawn_id was not being cleared when gdb exits,
unlike the other spawn ids, thus a test that starts gdb more than once
would end up using a stale spawn id.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* README (Testsuite Parameters): Document FORCE_SEPARATE_MI_TTY.
* lib/gdb.exp (default_gdb_exit): Clear inferior_spawn_id.
* lib/mi-support.exp (mi_uncatched_gdb_exit): Unset
gdb_main_spawn_id, mi_spawn_id, unset inferior_spawn_id.
(gdb_main_spawn_id, mi_spawn_id): Declare and
comment.
(mi_create_inferior_pty): New procedure,
factored out from default_mi_gdb_start.
(switch_gdb_spawn_id, mi_gdb_start_separate_mi_tty): New
procedures.
(default_mi_gdb_start): Call mi_gdb_start_separate_mi_tty if the
separate-mi-tty option is specified, or SEPARATE_MI_TTY is set.
Use mi_create_inferior_pty.
(mi_gdb_start): Use eval to pass down args list.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* NEWS: Mention support for running interpreters on separate
UIs and the new new-ui command.
gdb/doc/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Interpreters): Update intepreter-exec section,
document new-ui and explain use case.
With all the previous plumbing in place, it's now easy to add a
command that actually creates a new console/mi UI.
The intended use case is to make it possible and easy for MI frontends
to provide a fully featured GDB console to users, with readline
support, command line editing, history, etc., just like if gdb was
started on the command line. Currently MI frontends have to try to
implement all of that theirselves and make use of "-interpreter-exec
console ...", which is far from perfect. If you ever tried Eclipse's
gdb console window, you'll know what I mean...
Instead of trying to multiplex console through MI, this command let's
just leverage all the built in readline/editing support already inside
gdb.
The plan is for the MI frontend to start GDB in regular console mode,
running inside a terminal emulator widget embedded in Eclipse (which
already exists, for supporting the shell widget; other frontends have
similar widgets), and then tell GDB to run a full MI interpreter on an
specified input/output device, independent of the console.
My original prototype planned to do things the other way around --
start GDB in MI mode, and then start an extra CLI console on separate
tty. I handed over that prototype to Marc Khouzam @ Eclipse CDT, and
after experimentation and discussion, we ended up concluding that
starting GDB in CLI mode instead was both easier and actually also
supported an interesting use case -- connect an Eclipse frontend to a
GDB that is already running outside Eclipse.
The current usage is "new-ui <interpreter> <tty>".
E.g., on a terminal run this scriplet:
$ cat gdb-client
#!/bin/bash
reset
tty
tail -f /dev/null
$ gdb-client
/dev/pts/15
Now run gdb on another terminal, and tell it to start a MI interpreter
on the tty of the other terminal:
...
(gdb) new-ui mi /dev/pts/15
New UI allocated
Now back to the the gdb-client terminal, we'll get an MI prompt, ready
for MI input:
/dev/pts/15
=thread-group-added,id="i1"
(gdb)
You can also start a new UI running a CLI, with:
(gdb) new-ui console /dev/pts/15
Though note that this console won't support readline command editing.
It works as if "set editing off" was entered.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* interps.c (set_top_level_interpreter): New function, factored
out from captured_main.
(interpreter_completer): Make extern.
* interps.h (set_top_level_interpreter, interpreter_completer):
New declarations.
(captured_main): Use set_top_level_interpreter.
* top.c [!O_NOCTTY] (O_NOCTTY): Define as 0.
(open_terminal_stream, new_ui_command): New functions.
(init_main): Install the "new-ui" command.
This commit makes each UI have its own "stdin" stream pointer. This
is used to determine whether the "from_tty" argument to
execute_command, etc. should be true.
Related, this commit makes input_from_terminal_p take an UI parameter,
and then avoids the gdb_has_a_terminal in it. gdb_has_a_terminal only
returns info on gdb's own main/primary terminal (the real stdin).
However, the places that call input_from_terminal_p really want to
know is whether the command came from an interactive tty. This patch
thus renames input_from_terminal_p to input_interactive_p for clarity,
and then makes input_interactive_p check for "set interactive" itself,
along with ISATTY, instead of calling gdb_has_a_terminal. Actually,
quit_force wants to call input_interactive_p _after_ stdin is closed,
we can't call ISATTY that late. So instead we save the result of
ISATTY in a field of the UI.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* cli/cli-script.c (read_next_line): Adjust to per-UI stdin.
(read_command_lines): Use input_interactive_p instead of
input_from_terminal_p.
* defs.h (struct ui): Forward declare.
(input_from_terminal_p): Rename to ...
(input_interactive_p): ... this.
* event-top.c (stdin_event_handler): Pass 0 as from_tty argument
to quit_command.
(command_handler): Adjust to per-UI stdin.
(handle_line_of_input): Adjust to per-UI stdin and use
input_interactive_p instead of ISATTY and input_from_terminal_p.
(gdb_readline_no_editing_callback): Adjust to per-UI stdin.
(command_line_handler): Always pass true as "from_tty" parameter
of handle_line_of_input and execute_command.
(async_sigterm_handler): Pass 0 as from_tty argument to
quit_command.
* inflow.c (interactive_mode, show_interactive_mode): Moved to ...
(gdb_has_a_terminal): Don't check interactive_mode here.
(_initialize_inflow): Don't install "set interactive-mode" here.
* main.c (captured_command_loop): Adjust to per-UI stdin.
* mi/mi-interp.c (mi_execute_command_wrapper): Adjust to per-UI
stdin.
* top.c (new_ui): Save the stdin stream and whether it's a tty.
(dont_repeat): Adjust to per-UI stdin.
(command_line_input): Adjust to per-UI stdin and to use
input_interactive_p.
(quit_force): Write history if any UI supports interactive input.
(interactive_mode, show_interactive_mode): Move here, from
inflow.c.
(input_from_terminal_p): Rename to ...
(input_interactive_p): ... this, and check the "interactive_mode"
global instead of calling gdb_has_a_terminal.
(_initialize_top): Install "set interactive-mode" here.
* top.h (struct ui) <stdin_stream, input_interactive_p>: New
fields.
* utils.c (quit): Pass 0 as from_tty argument to quit_force.
(defaulted_query): Adjust to per-UI stdin and to use
input_interactive_p.
Without this, GDB exits if a secondary UIs terminal/input stream is
closed:
$ ./gdb -ex "new-ui mi /dev/pts/6"
New UI allocated
<<< close /dev/pts/6
(gdb) Error detected on fd 9
$
We want that for the main UI, but not secondary UIs.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* event-top.c (stdin_event_handler): Don't quit gdb if it was a
secondary UI's input stream that closed. Instead, just delete the
UI.
This is preparation for being able to create more than one UI object.
The change to gdb_main to stop using catch_errors is necessary because
catch_errors references current_uiout, which expands to
current_ui->m_current_ui, which would crash because current_ui is not
initialized yet at that point. It didn't trigger earlier in the
series because before this patch, main_ui/current_ui always start out
non-NULL.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* event-top.c (main_ui_): Delete.
(main_ui, current_ui, ui_list): No longer initialize here.
* main.c (captured_main): UI initialization code factored out to
new new_ui function.
(gdb_main): Wrap captured_main with TRY/CATCH instead of
catch_errors.
* top.c (highest_ui_num): New global.
(new_ui): New function.
* top.h (struct ui) <num>: New field.
(new_ui): New declaration.
Currently when a "step", "next", etc. finishes, the current source
line is printed on all console UIs.
This patch makes the CLI and TUI interpreters reuse MI's logic to only
emit console output related to a synchronous command on the
console-like interpreter that started the command in the first place.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* cli/cli-interp.c (cli_on_normal_stop): Bail out early if there's
nothing to print. Use should_print_stop_to_console.
* tui/tui-interp.c (tui_on_normal_stop): Likewise.
I noticed that if we step into an inline function, step_1 never
reaches proceed, and thus nevers sets the thread's
tp->control.command_interp. Because of that,
should_print_stop_to_console fails to determine that is should print
stop output to the console.
The fix is to set the thread's command_interp earlier. However, I
realized that we can move that field to the thread_fsm, given that its
lifetime is exactly the same as thread_fsm. So the patch plumbs all
fsms constructors to take the command interp and store it in the
thread_fsm.
We can see the fix in action, with e.g., the gdb.opt/inline-cmds.exp
test, and issuing a step when stopped at line 67:
&"s\n"
^running
*running,thread-id="all"
(gdb)
~"67\t result = func2 ();\n"
*stopped,reason="end-stepping-range",frame={addr="0x00000000004004d0",func="main",args=[],file="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.opt/inline-cmds.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.opt/inline-cmds.c",line="67"},thread-id="1",stopped-threads="all",core="0"
(gdb)
s
&"s\n"
^running
*running,thread-id="all"
(gdb)
+ ~"func2 () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.opt/inline-cmds.c:67\n"
+ ~"67\t result = func2 ();\n"
*stopped,reason="end-stepping-range",frame={addr="0x00000000004004d0",func="func2",args=[],file="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.opt/inline-cmds.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.opt/inline-cmds.c",line="67"},thread-id="1",stopped-threads="all",core="0"
(gdb)
(The inline-cmds.exp command is adjusted to exercise this.)
(Due to the follow_fork change, this also fixes "next N" across a fork
with "set follow-fork child" with "set detach-on-fork on". Commands
that rely on internal breakpoints, like "finish" will still require
more work to migrate breakpoints etc. to the child thread.)
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* breakpoint.c (new_until_break_fsm): Add 'cmd_interp' parameter.
(until_break_fsm_should_stop, until_break_fsm_clean_up): Add
thread parameter.
(until_break_command): Pass command interpreter to thread fsm
ctor.
* cli/cli-interp.c (should_print_stop_to_console): Adjust.
* gdbthread.h (struct thread_control_state) <command_interp>:
Delete field.
* infcall.c (new_call_thread_fsm): Add 'cmd_interp' parameter.
Pass it down.
(call_thread_fsm_should_stop): Add thread parameter.
(call_function_by_hand_dummy): Pass command interpreter to thread
fsm ctor. Pass thread pointer to fsm clean up method.
* infcmd.c: Include interps.h.
(struct step_command_fsm) <thread>: Delete field.
(new_step_command_fsm): Add 'cmd_interp' parameter. Pass it down.
(step_command_fsm_prepare): Remove references to fsm's thread
field.
(step_1): Pass command interpreter to thread
fsm ctor. Pass thread pointer to fsm clean up method.
(step_command_fsm_should_stop, step_command_fsm_clean_up): Add
thread parameter and use it.
(new_until_next_fsm): Add 'cmd_interp' parameter. Pass it down.
(until_next_fsm_should_stop, until_next_fsm_clean_up): Add thread
parameter and use it.
(until_next_command): Pass command interpreter to thread fsm ctor.
(struct finish_command_fsm) <thread>: Delete field.
(finish_command_fsm_ops): Add NULL slot for should_notify_stop.
(new_finish_command_fsm): Add 'cmd_interp' parameter and pass it
down. Remove thread parameter and adjust.
(finish_command_fsm_should_stop, finish_command_fsm_clean_up): Add
thread parameter and use it.
(finish_command): Pass command interpreter to thread fsm ctor.
Don't pass thread.
* infrun.c (follow_fork): Move thread fsm to child fork instead of
command interpreter, only.
(clear_proceed_status_thread): Remove reference to command_interp.
(proceed): Don't record the thread's command interpreter.
(clean_up_just_stopped_threads_fsms): Pass thread to fsm clean_up
method.
(fetch_inferior_event): Pass thread to fsm should_stop method.
* thread-fsm.c (thread_fsm_ctor): Add 'cmd_interp' parameter.
Store it.
(thread_fsm_clean_up, thread_fsm_should_stop): Add thread
parameter and pass it down.
* thread-fsm.h (struct thread_fsm) <command_interp>: New field.
(struct thread_fsm_ops) <clean_up, should_stop>: Add thread
parameter.
(thread_fsm_ctor): Add 'cmd_interp' parameter.
(thread_fsm_clean_up, thread_fsm_should_stop): Add thread
parameter.
* thread.c (thread_cancel_execution_command): Pass thread to
thread fsm clean_up method.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.opt/inline-cmds.c: Add "set mi break here" marker.
* gdb.opt/inline-cmds.exp: Add MI tests.
There's code in the MI interpreter that decides whether a stop should
be sent to MI's console stream. Move this check to the CLI
interpreter code, so that we can reuse it in both the CLI and TUI
interpreters.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* cli/cli-interp.c: Include gdbthread.h and thread-fsm.h.
(should_print_stop_to_console): New function, factored out from
mi_on_normal_stop_1.
* cli/cli-interp.h (should_print_stop_to_console): Declare.
* mi/mi-interp.c (mi_on_normal_stop_1): Use
should_print_stop_to_console. Pass it the current UI's console
interpreter.
* mi/mi-main.c (captured_mi_execute_command): Use the
INTERP_CONSOLE symbol rather than explicit "console".
Running mi-break.exp with MI on a secondary UI reveals that MI emits
spurious prompts compared MI running as primary UI:
-exec-continue
^running
*running,thread-id="all"
(gdb)
=breakpoint-modified,bkpt={number="9",type="breakpoint",disp="keep",enabled="y",func="callee2",line="39",script={"set $i=0","while $i<10","print $i","set $i=$i+1","end","continue"}}
~"\n"
~"Breakpoint 9, callee2 (intarg=2, strarg=0x400730 \"A string argument.\") at ...src/gdb/testsuite/gdb.mi/basics.c:39\n"
~"39\t callee3 (strarg);\n"
*stopped,reason="breakpoint-hit",disp="keep",bkptno="9",frame={addr="0x00000000004005dd",func="callee2",...
*running,thread-id="all"
>> (gdb)
=breakpoint-modified,bkpt={number="9",...
~"\n"
~"Breakpoint 9, callee2 (intarg=2, strarg=0x400730 \"A string argument.\") at ...src/gdb/testsuite/gdb.mi/basics.c:39\n"
~"39\t callee3 (strarg);\n"
*stopped,reason="breakpoint-hit",disp="keep",bkptno="9",...
*running,thread-id="all"
~"[Inferior 1 (process 12639) exited normally]\n"
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1",exit-code="0"
*stopped,reason="exited-normally"
FAIL: gdb.mi/mi-break.exp: intermediate stop and continue
FAIL: gdb.mi/mi-break.exp: test hitting breakpoint with commands (timeout)
Note the line marked >> above.
The test sets a breakpoint that runs "continue", a foreground command.
When we get to run the "continue", we've already emitted the *stopped
event on the MI UI, and set its prompt state to PROMPT_NEEDED (this is
done from within normal_stop). Since inferior events are always
handled with the main UI as current UI, breakpoint commands always run
with the main UI as current UI too. This means that the "continue"
ends up always disabling the prompt on the main UI, instead of the UI
that had just been done with synchronous execution.
I think we'll want to extend this with a concept of "set of
threads/inferiors a UI/interpreter is blocked waiting on", but I'm
leaving that for a separate series.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* infcmd.c (prepare_execution_command): Use
all_uis_on_sync_execution_starting.
* infrun.c (all_uis_on_sync_execution_starting): New function.
* infrun.h (all_uis_on_sync_execution_starting): Declare.
When sync_execution (a boolean) is true, it means we're running a
foreground command -- we hide the prompt stop listening to input, give
the inferior the terminal, then go to the event loop waiting for the
target to stop.
With multiple independent UIs, we need to track whether each UI is
synchronously blocked waiting for the target. IOW, if you do
"continue" in one console, that console stops accepting commands, but
you should still be free to type other commands in the others
consoles.
Just simply making sync_execution be per-UI alone not sufficient,
because of this in fetch_inferior_event:
/* If the inferior was in sync execution mode, and now isn't,
restore the prompt (a synchronous execution command has finished,
and we're ready for input). */
if (current_ui->async && was_sync && !sync_execution)
observer_notify_sync_execution_done ();
We'd have to record at entry the "was_sync" state for each UI, not
just of the current UI.
This patch instead replaces the sync_execution flag by a per-UI
tristate flag indicating the command line prompt state:
enum prompt_state
{
/* The command line is blocked simulating synchronous execution.
This is used to implement the foreground execution commands
('run', 'continue', etc.). We won't display the prompt and
accept further commands until the execution is actually over. */
PROMPT_BLOCKED,
/* The command finished; display the prompt before returning back to
the top level. */
PROMPT_NEEDED,
/* We've displayed the prompt already, ready for input. */
PROMPTED,
;
I think the end result is _much_ clearer than the current code, and,
it addresses the original motivation too.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* annotate.c: Include top.h.
(async_background_execution_p): Delete.
(print_value_flags): Check the UI's prompt state rather then
async_background_execution_p.
* event-loop.c (start_event_loop): Set the prompt state to
PROMPT_NEEDED.
* event-top.c (display_gdb_prompt, async_enable_stdin)
(async_disable_stdin): Check the current UI's prompt state instead
of the sync_execution global.
(command_line_handler): Set the prompt state to PROMPT_NEEDED
before running a command, and display the prompt if still needed
afterwards.
* infcall.c (struct call_thread_fsm) <waiting_ui>: New field.
(new_call_thread_fsm): New parameter 'waiting_ui'. Store it.
(call_thread_fsm_should_stop): Set the prompt state to
PROMPT_NEEDED.
(run_inferior_call): Adjust to temporarily set the prompt state to
PROMPT_BLOCKED instead of using the sync_execution global.
(call_function_by_hand_dummy): Pass the current UI to
new_call_thread_fsm.
* infcmd.c: Include top.h.
(continue_1): Check the current UI's prompt state instead of the
sync_execution global.
(continue_command): Validate global execution state before calling
prepare_execution_command.
(step_1): Call all_uis_check_sync_execution_done.
(attach_post_wait): Don't call async_enable_stdin here. Remove
reference to sync_execution.
* infrun.c (sync_execution): Delete global.
(follow_fork_inferior)
(reinstall_readline_callback_handler_cleanup): Check the current
UI's prompt state instead of the sync_execution global.
(check_curr_ui_sync_execution_done)
(all_uis_check_sync_execution_done): New functions.
(fetch_inferior_event): Call all_uis_check_sync_execution_done
instead of trying to determine whether the global sync execution
changed.
(handle_no_resumed): Check the prompt state of all UIs.
(normal_stop): Emit the no unwait-for even to all PROMPT_BLOCKED
UIs. Emit the "Switching to" notification to all UIs. Enable
stdin in all UIs.
* infrun.h (sync_execution): Delete.
(all_uis_check_sync_execution_done): Declare.
* main.c (captured_command_loop): Don't call
interp_pre_command_loop if the prompt is blocked.
(catch_command_errors, catch_command_errors_const): Adjust.
(captured_main): Set the initial prompt state to PROMPT_NEEDED.
* mi/mi-interp.c (display_mi_prompt): Set the prompt state to
PROMPTED.
(mi_interpreter_resume): Don't clear sync_execution. Remove hack
comment.
(mi_execute_command_input_handler): Set the prompt state to
PROMPT_NEEDED before executing the command, and only display the
prompt if the prompt state is PROMPT_NEEDED afterwards.
(mi_on_resume_1): Adjust to check the prompt state.
* target.c (target_terminal_inferior): Adjust to check the prompt
state.
* top.c (wait_sync_command_done, maybe_wait_sync_command_done)
(execute_command): Check the current UI's prompt state instead of
sync_execution.
* top.h (enum prompt_state): New.
(struct ui) <prompt_state>: New field.
(ALL_UIS): New macro.
All interpreter types (CLI/TUI/MI) print the prompt, and then call
start_event_loop.
Because we'll need an interpreter hook to display the
interpreter-specific prompt before going back to the event loop,
without actually starting an event loop, this patch moves the
start_event_loop call to common code, and replaces the command_loop
hook with a pre_command_look hook, that now just prints the prompt.
Turns out to be a cleanup on its own right anyway.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* cli/cli-interp.c (cli_interpreter_pre_command_loop): New
function.
(cli_interp_procs): Install it instead of cli_command_loop.
* cli/cli-interp.h (cli_interpreter_pre_command_loop): Declare.
* event-top.c (cli_command_loop): Delete.
* interps.c (interp_new): Remove reference to command_loop_proc.
(current_interp_command_loop): Delete.
(interp_pre_command_loop): New function.
(interp_command_loop_ftype): Delete.
* interps.h (interp_pre_command_loop_ftype): New typedef.
(struct interp_procs) <command_loop_proc>: Delele field.
<pre_command_loop_proc>: New field.
(current_interp_command_loop): Delete declaration.
(interp_pre_command_loop): New declaration.
* main.c (captured_command_loop): Call interp_pre_command_loop
instead of current_interp_command_loop and start an event loop.
* mi/mi-interp.c (mi_command_loop): Delete.
(mi_interpreter_pre_command_loop): New.
(mi_interp_procs): Update.
* tui/tui-interp.c (tui_interp_procs): Install
cli_interpreter_pre_command_loop instead of cli_command_loop.
Each MI instance should obviously have its own raw output channel,
along with save_raw_stdout.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* interps.c (current_interpreter): New function.
* interps.h (current_interpreter): New declaration.
* mi/mi-cmds.h (raw_stdout): Delete declaration.
* mi/mi-common.h (struct mi_interp) <raw_stdout,
saved_raw_stdout>: New field.
* mi/mi-interp.c (display_mi_prompt): New parameter 'mi'. Adjust
to per-UI raw_stdout.
(mi_interpreter_init): Adjust to per-UI raw_stdout.
(mi_on_sync_execution_done, mi_execute_command_input_handler)
(mi_command_loop): Pass MI instance to display_mi_prompt.
(mi_on_normal_stop_1, mi_output_running_pid, mi_on_resume_1)
(mi_on_resume): Adjust to per-UI raw_stdout.
(saved_raw_stdout): Delete.
(mi_set_logging): Adjust to per-UI raw_stdout and
saved_raw_stdout.
* mi/mi-main.c (raw_stdout): Delete.
(mi_cmd_gdb_exit, captured_mi_execute_command)
(mi_print_exception, mi_load_progress): Adjust to per-UI
raw_stdout.
(print_diff_now, mi_print_timing_maybe): New ui_file parameter.
Pass it along.
(print_diff): New ui_file parameter. Send output there instead of
raw_stdout.
* mi/mi-main.h (struct ui_file): Forward declare.
(mi_print_timing_maybe): Add ui_file parameter.
Since we always run the inferior in the main console (unless "set
inferior-tty" is in effect), when some UI other than the main one
calls target_terminal_inferior/target_terminal_inferior, then we only
register/unregister the UI's input from the event loop, but leave the
main UI's terminal settings as is.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* target.c (target_terminal_inferior): Bail out after
unregistering input_fd if not on the main UI.
(target_terminal_ours): Bail out after registering input_fd if not
on the main UI.
(target_terminal_ours_for_output): Bail out if not on the main UI.
This makes target events always be always processed with the main UI
as current UI. This way, warnings, debug output, etc. are always
consistently sent to the main console.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* event-top.c (restore_ui_cleanup): Make extern.
* infrun.c (fetch_inferior_event): Always switch to the main UI.
* top.h (restore_ui_cleanup): Declare.
Due to the way that readline's API works (based on globals), we can
only have one instance of readline in a process. So the goal of this
patch is to only allow editing in the main UI, and make sure that only
one UI calls into readline. Some MI paths touch readline variables
currently, which is bad as that is changing variables that matter for
the main console UI. This patch fixes those.
This actually fixes a nasty bug -- starting gdb in MI mode ("gdb
-i=mi"), and then doing "set editing on" crashes GDB, because MI is
not prepared to use readline:
set editing on
&"set editing on\n"
=cmd-param-changed,param="editing",value="on"
^done
(gdb)
p 1
readline: readline_callback_read_char() called with no handler!
Aborted (core dumped)
The fix for that was to add an interp_proc method to query the
interpreter whether it actually supports editing. New test included.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
PR mi/20034
* cli/cli-interp.c: Include cli-interp.h and event-top.h.
(cli_interpreter_resume): Pass 1 to gdb_setup_readline. Set the
UI's input_handler here.
(cli_interpreter_supports_command_editing): New function.
(cli_interp_procs): Install it.
* cli/cli-interp.h: New file.
* event-top.c (async_command_editing_p): Rename to ...
(set_editing_cmd_var): ... this.
(change_line_handler): Add parameter 'editing', and use it. Bail
early if the interpreter doesn't support editing. Don't touch
readline state if editing is off.
(gdb_rl_callback_handler_remove, gdb_rl_callback_handler_install)
(gdb_rl_callback_handler_reinstall): Assert the current UI is the
main UI.
(display_gdb_prompt): Don't call gdb_rl_callback_handler_remove if
not using readline. Check whether the current UI is using command
editing instead of checking the async_command_editing_p global.
(set_async_editing_command): Delete.
(gdb_setup_readline): Add 'editing' parameter. Only allow editing
on the main UI. Don't touch readline state if editing is off.
(gdb_disable_readline): Don't touch readline state if editing is
off.
* event-top.h (gdb_setup_readline): Add 'int' parameter.
(set_async_editing_command): Delete declaration.
(change_line_handler, command_line_handler): Declare.
(async_command_editing_p): Rename to ...
(set_editing_cmd_var): ... this.
* infrun.c (reinstall_readline_callback_handler_cleanup): Check
whether the current UI has editing enabled rather than checking
the async_command_editing_p global.
* interps.c (interp_supports_command_editing): New function.
* interps.h (interp_supports_command_editing_ftype): New typedef.
(struct interp_procs) <supports_command_editing_proc>: New field.
(interp_supports_command_editing): Declare.
* mi/mi-interp.c (mi_interpreter_resume): Pass 0 to
gdb_setup_readline. Don't clear the async_command_editing_p
global. Update comments.
* top.c (gdb_readline_wrapper_line, gdb_readline_wrapper): Check
whether the current UI has editing enabled rather than checking
the async_command_editing_p global. Don't touch readline state if
editing is off.
(undo_terminal_modifications_before_exit): Switch to the main UI.
Unconditionally call gdb_disable_readline.
(set_editing): New function.
(show_async_command_editing_p): Rename to ...
(show_editing): ... this. Show the state of the current UI.
(_initialize_top): Adjust.
* top.h (struct ui) <command_editing>: New field.
* tui/tui-interp.c: Include cli/cli-interp.h.
(tui_resume): Pass 1 to gdb_setup_readline. Set the UI's
input_handler.
(tui_interp_procs): Install
cli_interpreter_supports_command_editing.
* tui/tui-io.c (tui_getc): Check whether the current UI has
editing enabled rather than checking the async_command_editing_p
global.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
PR mi/20034
* gdb.mi/mi-editing.exp: New file.
Currently, current_uiout starts out pointing to def_uiout, a dummy
ui_out implementation.
Since we create a replacement uiout early on as soon as we create the
interpreter, we never actually use def_uiout. So this patch removes
it.
The proof that it works is that starting with current_uiout set to
NULL does not crash.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* ui-out.c (default_ui_out_impl): Delete.
(def_uiout): Delete.
(current_uiout): Set to NULL.
(default_table_begin, default_table_body, default_table_end)
(default_table_header, default_begin, default_end)
(default_field_int, default_field_skip, default_field_string)
(default_field_fmt, default_spaces, default_text, default_message)
(default_wrap_hint, default_flush, default_data_destroy): Delete.
stderr_fileopen () references stderr directly, which doesn't work when
we have a separate UI with its own stderr-like stream. So this also
adds a "errstream" to "struct ui", and plumbs stderr_fileopen to take
a stream parameter.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* event-top.c (gdb_setup_readline): Pass the UI's outstream and
errstream to stdout_fileopen and stderr_fileopen.
* exceptions.c: Include top.h.
(print_flush): Open the current UI's outstream file descriptor,
instead of hardcoding file descriptor 1.
* main.c (captured_main): Save the main UI's out and error
streams. Adjust stderr_fileopen call.
* top.h (struct ui) <outstream, errstream>: New fields.
* ui-file.c (stderr_fileopen): Add stream parameter. Use it
instead of stderr.
* ui-file.h (stderr_fileopen): Add stream parameter and update
comment.
And with that, we can switch the current UI to the UI whose input
descriptor woke up the event loop. IOW, if the user types in UI 2,
the event loop wakes up, switches to UI 2, and processes the input.
Next the user types in UI 3, the event loop wakes up and switches to
UI 3, etc.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* event-top.c (input_fd): Delete.
(stdin_event_handler): Switch to the UI whose input descriptor got
the event. Adjust to per-UI input_fd.
(gdb_setup_readline): Don't set the input_fd global. Adjust to
per-UI input_fd.
(gdb_disable_readline): Adjust to per-UI input_fd.
* event-top.h (input_fd): Delete declaration.
* linux-nat.c (linux_nat_terminal_inferior): Don't remove input_fd
from the event-loop here.
(linux_nat_terminal_ours): Don't register input_fd in the
event-loop here.
* main.c (captured_main): Adjust to per-UI input_fd.
* remote.c (remote_terminal_inferior): Don't remove input_fd from
the event-loop here.
(remote_terminal_ours): Don't register input_fd in the event-loop
here.
* target.c: Include top.h and event-top.h.
(target_terminal_inferior): Remove input_fd from the event-loop
here.
(target_terminal_ours): Register input_fd in the event-loop.
* top.h (struct ui) <input_fd>: New field.
Async signal handlers have no connection to whichever was the current
UI, and thus always run on the main one.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* event-loop.c: Include top.h.
(invoke_async_signal_handlers): Switch to the main UI.
* event-top.c (main_ui_): Update comment.
(main_ui): New global.
* top.h (main_ui): Declare.
When we have multiple consoles, MI channels, etc., then we need to
broadcast breakpoint hits, etc. to all UIs. In the past, I've
adjusted most of the run control to communicate events to the
interpreters through observer notifications, so events would be
properly sent to console and MI streams, in sync and async modes.
This patch does the next logical step -- have each interpreter's
observers output interpreter-specific info to _all_ UIs.
Note that when we have multiple instances of active cli/tui
interpreters, then the cli_interp and tui_interp globals no longer
work. This is addressed by this patch.
Also, the interpreters currently register some observers when resumed
and remove them when suspended. If we have multiple instances of the
interpreters, and they can be suspended/resumed at different,
independent times, that no longer works. What we instead do is always
install the observers, and then have the observers themselves know
when to do nothing.
An earlier prototype of this series did the looping over struct UIs in
common code, and then dispatched events to the interpreters through a
matching interp_on_foo method for each observer. That turned out a
lot more complicated than the present solution, as we'd end up with
having to create a new interp method every time some interpreter
wanted to listen to some observer notification, resulting in a lot of
duplicated make-work and more coupling than desirable.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* cli/cli-interp.c (cli_interp): Delete.
(as_cli_interp): New function.
(cli_on_normal_stop, cli_on_signal_received)
(cli_on_end_stepping_range, cli_on_signal_exited, cli_on_exited)
(cli_on_no_history): Send output to all CLI UIs.
(cli_on_sync_execution_done, cli_on_command_error): Skip output if
the top level interpreter is not a CLI.
(cli_interpreter_init): Don't set cli_interp or install observers
here.
(_initialize_cli_interp): Install observers here.
* event-top.c (main_ui_, ui_list): New globals.
(current_ui): Point to main_ui_.
(restore_ui_cleanup, switch_thru_all_uis_init)
(switch_thru_all_uis_cond, switch_thru_all_uis_next): New
functions.
* mi/mi-interp.c (as_mi_interp): New function.
(mi_interpreter_init): Don't install observers here.
(mi_on_sync_execution_done): Skip output if the top level
interpreter is not a MI.
(mi_new_thread, mi_thread_exit, mi_record_changed)
(mi_inferior_added, mi_inferior_appeared, mi_inferior_exit)
(mi_inferior_removed): Send output to all MI UIs.
(find_mi_interpreter, mi_interp_data): Delete.
(find_mi_interp): New function.
(mi_on_signal_received, mi_on_end_stepping_range)
(mi_on_signal_exited, mi_on_exited, mi_on_no_history): Send output
to all MI UIs.
(mi_on_normal_stop): Rename to ...
(mi_on_normal_stop_1): ... this.
(mi_on_normal_stop): Reimplement, sending output to all MI UIs.
(mi_traceframe_changed, mi_tsv_created, mi_tsv_deleted)
(mi_tsv_modified, mi_breakpoint_created, mi_breakpoint_deleted)
(mi_breakpoint_modified, mi_output_running_pid): Send output to
all MI UIs.
(mi_on_resume): Rename to ...
(mi_on_resume_1): ... this. Don't handle infcalls here.
(mi_on_resume): Reimplement, sending output to all MI UIs.
(mi_solib_loaded, mi_solib_unloaded, mi_command_param_changed)
(mi_memory_changed): Send output to all MI UIs.
(report_initial_inferior): Install observers here.
* top.h (struct ui) <next>: New field.
(ui_list): Declare.
(struct switch_thru_all_uis): New.
(switch_thru_all_uis_init, switch_thru_all_uis_cond)
(switch_thru_all_uis_next): Declare.
(SWITCH_THRU_ALL_UIS): New macro.
* tui/tui-interp.c (tui_interp): Delete global.
(as_tui_interp): New function.
(tui_on_normal_stop, tui_on_signal_received)
(tui_on_end_stepping_range, tui_on_signal_exited, tui_on_exited)
(tui_on_no_history): Send output to all TUI UIs.
(tui_on_sync_execution_done, tui_on_command_error): Skip output if
the top level interpreter is not a TUI.
(tui_init): Don't set tui_interp or install observers here.
(_initialize_tui_interp): Install observers here.
If every UI instance has its own set of interpreters, then the current
scheme of creating the interpreters at GDB initialization time no
longer works. We need to create them whenever a new UI instance is
created.
The scheme implemented here has each interpreter register a factory
callback that when called creates a new instance of a specific
interpreter type. Then, when some code in gdb looks up an interpreter
(always by name), if there's none yet, the factory method is called to
construct one.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* cli/cli-interp.c (cli_uiout): Delete, moved into ...
(struct cli_interp): ... this new structure.
(cli_on_normal_stop, cli_on_signal_received)
(cli_on_end_stepping_range, cli_on_signal_exited, cli_on_exited)
(cli_on_no_history): Use interp_ui_out.
(cli_interpreter_init): If top level, set the cli_interp global.
(cli_interpreter_init): Return the interp's data instead of NULL.
(cli_interpreter_resume, cli_interpreter_exec, cli_ui_out): Adjust
to cli_uiout being in the interpreter's data.
(cli_interp_procs): New, factored out from _initialize_cli_interp.
(cli_interp_factory): New function.
(_initialize_cli_interp): Call interp_factory_register.
* interps.c (get_interp_info): New, factored out from ...
(get_current_interp_info): ... this.
(interp_new): Add parameter 'data'. Store it.
(struct interp_factory): New function.
(interp_factory_p): New typedef. Define a VEC_P.
(interpreter_factories): New global.
(interp_factory_register): New function.
(interp_add): Add 'ui' parameter. Use get_interp_info and
interp_lookup_existing.
(interp_lookup): Rename to ...
(interp_lookup_existing): ... this. Add 'ui' parameter. Don't
check for NULL or empty name here.
(interp_lookup): Add 'ui' parameter and reimplement.
(interp_set_temp, interpreter_exec_cmd): Adjust.
(interpreter_completer): Complete on registered interpreter
factories instead of interpreters.
* interps.h (interp_factory_func): New typedef.
(interp_factory_register): Declare.
(interp_new, interp_add): Adjust.
(interp_lookup): Declare.
* main.c (captured_main): Adjust.
* mi/mi-interp.c (mi_cmd_interpreter_exec): Adjust.
(mi_interp_procs): New, factored out from
_initialize_mi_interp.
(mi_interp_factory): New function.
* python/python.c (execute_gdb_command): Adjust.
* tui/tui-interp.c (tui_init): If top level, set the tui_interp
global.
(tui_interp_procs): New.
(tui_interp_factory): New function.
(_initialize_tui_interp): Call interp_factory_register.
Make each UI have its own interpreter list, top level interpreter,
current interpreter, etc. The "interpreter_async" global is not
really specific to an struct interp (it crosses interpreter-exec ...),
so I moved it to "struct ui" directly, while the other globals were
left hidden in interps.c, opaque to the rest of GDB.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* breakpoint.c (bpstat_do_actions_1): Access the current UI's
async field instead of the interpreter_async global.
* cli/cli-script.c (execute_user_command, while_command)
(if_command, script_from_file): Likewise.
* compile/compile.c: Include top.h instead of interps.h.
(compile_file_command, compile_code_command)
(compile_print_command): Access the current UI's async field
instead of the interpreter_async global.
* guile/guile.c: Include top.h instead of interps.h.
(guile_repl_command, guile_command, gdbscm_execute_gdb_command):
Access the current UI's async field instead of the
interpreter_async global.
* guile/scm-ports.c: Include top.h instead of interps.h.
(ioscm_with_output_to_port_worker): Access the current UI's async
field instead of the interpreter_async global.
* inf-loop.c (inferior_event_handler): Likewise.
* infcall.c (run_inferior_call): Likewise.
* infrun.c (reinstall_readline_callback_handler_cleanup)
(fetch_inferior_event): Likewise.
* interps.c (interpreter_async): Delete.
(struct ui_interp_info): New.
(get_current_interp_info): New function.
(interp_list, current_interpreter, top_level_interpreter_ptr):
Delete.
(interp_add, interp_set, interp_lookup, interp_ui_out)
(current_interp_set_logging, interp_set_temp)
(current_interp_named_p): Adjust to per-UI interpreters.
(command_interpreter): Delete.
(command_interp, current_interp_command_loop, interp_quiet_p)
(interp_exec, interpreter_exec_cmd, interpreter_completer)
(top_level_interpreter, top_level_interpreter_data): Adjust to
per-UI interpreters.
* interps.h (interpreter_async): Delete.
* main.c (captured_command_loop): Access the current UI's async
field instead of the interpreter_async global.
* python/python.c (python_interactive_command, python_command)
(execute_gdb_command): Likewise.
* top.c (maybe_wait_sync_command_done, execute_command_to_string):
Access the current UI's async field instead of the
interpreter_async global.
* top.h (struct tl_interp_info): Forward declare.
(struct ui) <interp_info, async>: New fields.
We need to have these send output to the proper UI.
However, this patch still make them look like globals. Kind of like
__thread variables, if you will. Changing everything throughout to
write something like current_ui->gdb_stdout instead would be massive
overkill, IMNSHO.
This leaves gdb_stdtargin/stdtarg/stdtargerr global, but maybe that was a
mistake, I'm not sure -- IIRC, MI formats target I/O differently, so
if we have a separate MI channel, then I guess target output should go
there instead of to gdb's stdout. OTOH, maybe GDB should send that
instead to "set inferior-tty", instead of multiplexing it over MI. We
can always fix those later when it gets clearer where they should go.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* main.c (gdb_stdout, gdb_stderr, gdb_stdlog, gdb_stdin): Delete
globals.
(gen_ret_current_ui_field_ptr): New macro. Use it to generate
wrappers for gdb_stdout, gdb_stderr, gdb_stdlog and gdb_stdin.
* top.h (struct ui) <m_gdb_stdout, m_gdb_stdin, m_gdb_stderr,
m_gdb_stdlog>: New fields.
(current_ui_gdb_stdout_ptr, current_ui_gdb_stdin_ptr)
(current_ui_gdb_stderr_ptr, current_ui_gdb_stdlog_ptr): Declare.
(gdb_stdout, gdb_stdin, gdb_stderr, gdb_stdlog): Reimplement as
macros.
This is a step towards supporting multiple consoles/MIs, each on its
own stdio streams / terminal.
See intro comment in top.h.
(I've had trouble picking a name for this object. I've started out
with "struct console" originally. But then this is about MI as well,
and there's "interpreter-exec console", which is specifically about
the CLI...
So I changed to "struct terminal", but, then we have a terminal object
that works when the input is not a terminal as well ...
Then I sort of gave up and renamed it to "struct top_level". But it
then gets horribly confusing when we talk about the "top level
interpreter that's running on the current top level".
In the end, I realized we're already sort of calling this "ui", in
struct ui_out, struct ui_file, and a few coments here and there.)
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* event-top.c: Update readline-related comments.
(input_handler, call_readline): Delete globals.
(gdb_rl_callback_handler): Call the current UI's input_handler
method.
(change_line_handler): Adjust to set current UI's properties
instead of globals.
(current_ui_, current_ui): New globals.
(get_command_line_buffer): Rewrite to refer to the current UI.
(stdin_event_handler): Adjust to call the call_readline method of
the current UI.
(gdb_readline_no_editing_callback): Adjust to call the current UI's
input_handler method.
(gdb_setup_readline): Adjust to set current UI's properties
instead of globals.
* event-top.h (call_readline, input_handler): Delete declarations.
* mi/mi-interp.c (mi_interpreter_resume): Adjust to set current
UI's properties instead of globals.
* top.c (gdb_readline_wrapper_cleanup): Adjust to set current UI's
properties instead of globals.
(gdb_readline_wrapper): Adjust to call and set current UI's
methods instead of globals.
* top.h: Include buffer.h and event-loop.h.
(struct ui): New struct.
(current_ui): New declaration.
Looking at testsuite results, I noticed this warning in an MI test:
~"\nCatchpoint "
~"2, "
&"warning: failed to get exception name: No definition of \"e.full_name\" in current context.\n"
~"exception at 0x000000000040192d in foo () at /home/pedro/brno/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/mi_catch_ex/foo.adb:20\n"
~"20\t raise Constraint_Error; -- SPOT1\n"
*stopped,reason="breakpoint-hit",disp="keep",bkptno="2",exception-name="CONSTRAINT_ERROR",frame={addr="0x000000000040192d",func="foo",args=[],file="/home/pedro/brno/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/mi_catch_ex/foo.adb",fullname="/home/pedro/brno/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/mi_catch_ex/foo.adb",line="20"},thread-id="1",stopped-threads="all",core="5"
(gdb)
PASS: gdb.ada/mi_catch_ex.exp: continue until CE caught by all-exceptions catchpoint
The problem is that:
- MI prints the breakpoint hit twice: once on the MI stream;
another time on the console stream.
- After printing the Ada catchpoint hit, gdb selects a non-current
frame, from within the catchpoint's print_it routine.
So the second time the breakpoint is printed, the selected frame is no
longer the current frame, and then evaluating e.full_name in
ada_exception_name_addr fails.
This commit fixes the problem and enhances the gdb.ada/mi_catch_ex.exp
test to make sure the catchpoint hit is printed correctly on the
console stream too.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* ada-lang.c (ada_exception_name_addr_1): Add comment.
(print_it_exception): Select the current frame.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.ada/mi_catch_ex.exp (continue_to_exception): New procedure.
(top level): Use it instead of mi_execute_to.
Similarly to 5068630ad3
(gdb.python/py-events.exp and normal_stop observers ordering) [1],
this commit makes the gdb.python/py-mi-events.exp test not rely on
order in which MI and Python observers run, or even on where each
observer sends its output to.
This shows up as a problem when testing with MI running as a separate
terminal, for example, where Python event output and MI output go to
different channels, even. But in any case, relying on the order in
which observers run is always going to be fragile.
The fix is to save the string output in the handlers in some variables
and then having MI print them explicitly, instead of printing them
directly from the Python events.
Tested on x86_64 Fedora 23.
https://sourceware.org/ml/gdb-patches/2015-07/msg00290.html
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.python/py-mi-events-gdb.py (stop_handler_str)
(cont_handler_str): New.
(signal_stop_handler): Set stop_handler_str instead of printing to
stdout.
(continue_handler): Set cont_handler_str instead of printing to
stdout.
* gdb.python/py-mi-events.exp: Ues mi_execute_to instead of
mi_send_resuming_command. Print stop_handler_str and
cont_handler_str instead of expecting the python events print
directly.
Originally intended to be committed on 2013-01-17 in
675921c059 (Test case for the
jit-reader), but by mistake the files were not added. Fortunately
they still work.
gdb/testsuite/ChangeLog:
2016-06-17 Sanjoy Das <sanjoy@playingwithpointers.com>
* gdb.base/jit-reader.exp: New file.
* gdb.base/jithost.c: New file.
* gdb.base/jithost.h: New file.
* gdb.base/jitreader.c : New file.
* gdb.base/jit-protocol.h: New file.
This patch extends step-over-syscall.exp by setting different values to
detach-on-fork and follow-fork.
gdb/testsuite:
2016-06-17 Yao Qi <yao.qi@linaro.org>
* gdb.base/step-over-syscall.exp (break_cond_on_syscall): New
parameters follow_fork and detach_on_fork. Set follow-fork-mode
and detach-on-fork. Adjust tests.
(top level): Invoke break_cond_on_syscall with combinations of
syscall, follow-fork-mode and detach-on-fork.
When a thread is doing step-over with reinsert breakpoint, and the
instruction executed is a syscall doing vfork, both parent and child
share the memory, so the reinsert breakpoint in the space is visible
to both of them. Also, removing the reinsert breakpoints from the
child will effectively remove them from the parent. We should
carefully manipulate reinsert breakpoints for both processes.
What we are doing here is that
- uninsert reinsert breakpoints from the parent before cloning the
breakpoint list. We use "uninsert" instead of "remove", because
we need to "reinsert" them back after vfork is done. In fact,
"uninsert" removes them from both child and parent process space.
- reinsert breakpoints in parent process are still copied to child's
breakpoint list,
- remove them from child's breakpoint list as what we did for fork,
at this point, reinsert breakpoints are removed from the child and
the parent, but they are still tracked by the parent's breakpoint
list,
- once vfork is done, "reinsert" them back to the parent,
gdb/gdbserver:
2016-06-17 Yao Qi <yao.qi@linaro.org>
* linux-low.c (handle_extended_wait): Call
uninsert_reinsert_breakpoints for the parent process. Remove
reinsert breakpoints from the child process. Reinsert them to
the parent process when vfork is done.
* mem-break.c (uninsert_reinsert_breakpoints): New function.
(reinsert_reinsert_breakpoints): New function.
* mem-break.h (uninsert_reinsert_breakpoints): Declare
(reinsert_reinsert_breakpoints): Declare.
When a thread is stepping over a syscall instruction with software
single step, GDBserver inserts reinsert breakpoints at the next pcs.
If the syscall call is fork, the forked child has reinsert breakpoint
in its space, and GDBserver clones parent's breakpoint list to child's.
When GDBserver resumes the child, its bp_reinsert is zero, but has
reinsert breakpoints, so the following assert is triggered if I apply
the patch extending step-over-syscall.exp.
gdb/gdbserver/linux-low.c:4292: A problem internal to GDBserver has been detected.^M
void linux_resume_one_lwp_throw(lwp_info*, int, int, siginfo_t*): Assertion `!has_reinsert_breakpoints (proc)' failed.
gdb/gdbserver:
2016-06-17 Yao Qi <yao.qi@linaro.org>
* linux-low.c (handle_extended_wait): If the parent is doing
step-over, remove the reinsert breakpoints from the forked child.
This patch fixes a GDBserver crash when one thread is stepping over
a syscall instruction which is exit. Step-over isn't finished due
to the exit, but GDBserver doesn't clean up the state of step-over,
so in the wait next time, GDBserver will wait on step_over_bkpt,
which is already exited, and GDBserver crashes because
'requested_child' is NULL. See gdbserver logs below,
Need step over [LWP 14858]? yes, found breakpoint at 0x2aaaaad91307^M
proceed_all_lwps: found thread 14858 needing a step-over^M
Starting step-over on LWP 14858. Stopping all threads^M
>>>> entering void stop_all_lwps(int, lwp_info*)
....
<<<< exiting void stop_all_lwps(int, lwp_info*)^M
Done stopping all threads for step-over.^M
pc is 0x2aaaaad91307^M
Writing 0f to 0x2aaaaad91307 in process 14858^M
Could not find fast tracepoint jump at 0x2aaaaad91307 in list (uninserting).^M
pending reinsert at 0x2aaaaad91307^M
step from pc 0x2aaaaad91307^M
Resuming lwp 14858 (step, signal 0, stop not expected)^M
# Start step-over for LWP 14858
>>>> entering ptid_t linux_wait_1(ptid_t, target_waitstatus*, int)
....
LLFE: 14858 exited.
...
<<<< exiting ptid_t linux_wait_1(ptid_t, target_waitstatus*, int)
# LWP 14858 exited
.....
>>>> entering ptid_t linux_wait_1(ptid_t, target_waitstatus*, int)^M
linux_wait_1: [<all threads>]^M
step_over_bkpt set [LWP 14858.14858], doing a blocking wait
# but step_over_bkpt is still LWP 14858, which is wrong
The fix is to finish step-over if it is ongoing, and unsuspend other
threads. Without the fix in linux-low.c, GDBserver will crash in
with running gdb.base/step-over-exit.exp.
gdb/gdbserver:
2016-06-17 Yao Qi <yao.qi@linaro.org>
* linux-low.c (unsuspend_all_lwps): Declare.
(linux_low_filter_event): If thread exited, call finish_step_over.
If step-over is finished, unsuspend other threads.
gdb/testsuite:
2016-06-17 Yao Qi <yao.qi@linaro.org>
* gdb.base/step-over-exit.c: New.
* gdb.base/step-over-exit.exp: New.
This patch adds more asserts, so the incorrect or sub-optimal
reinsert breakpoints manipulations (from the tests in the following
patches) can trigger them.
gdb/gdbserver:
2016-06-17 Yao Qi <yao.qi@linaro.org>
* linux-low.c (linux_resume_one_lwp_throw): Assert
has_reinsert_breakpoints returns false.
* mem-break.c (delete_disabled_breakpoints): Assert
bp type isn't reinsert_breakpoint.
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.
* windows-nat.c (_initialize_check_for_gdb_ini): Fix off-by-one
error in allocation of space for "$HOME/.gdbinit" string. This
caused GDB to abort on startup whenever a '~/gdb.ini' file was
actually found, because xsnprintf would hit an assertion
violation.
Just like completion doesn't show deprecated commands, I think that help
should not list them, so that we don't incite users to use them.
gdb/ChangeLog:
* cli/cli-decode.c (help_cmd_list): Do not list commands that
are deprecated.
This patch adds a test for tracepoints enabling/disabling, which
didn't work properly for fast tracepoints on big endian systems.
gdb/testsuite/ChangeLog:
* gdb.trace/trace-enable-disable.exp: New file.
* gdb.trace/trace-enable-disable.c: New file.
I am sending this fix on behalf of Par Olsson, as a follow-up of this
one:
https://www.sourceware.org/ml/gdb-patches/2015-10/msg00196.html
This problem is exposed when enabling/disabling fast tracepoints on big
endian machines. The flag is defined as an int8_t, but is written from
gdbserver as an integer (usually 32 bits). When the agent code reads it
as an int8_t, it only considers the most significant byte, which is
always 0.
Also, we were writing 32 bits in an 8 bits field, so the write would
overflow, but since the following bytes are padding (the next field is
an uint64_t), it luckily didn't cause any issue on little endian
systems.
The fix was originally tested on ARM big endian systems, but I don't
have access to such a system. However, thanks to Marcin's PowerPC fast
tracepoint patches and gcc110 (big endian Power7) on the gcc compile
farm, I was able to reproduce the problem, test the fix and write a
test (the following patch).
gdb/gdbserver/ChangeLog:
YYYY-MM-DD Par Olsson <par.olsson@windriver.com>
* tracepoint.c (write_inferior_int8): New function.
(cmd_qtenable_disable): Write enable flag using
write_inferior_int8.
Some fast tracepoints tests make sure that the in-process agent library
is properly loaded, by searching for the library name in "info
sharedlibrary".
Originally, it would search for the full path. Since patch "Make ftrace
tests work with remote targets" [1], the "runtime" location of the IPA,
in the standard output directory, is not the same as the original
location, in the gdbserver build directory. Therefore, the patch
changed the checks:
gdb_test "info sharedlibrary" ".*${libipa}.*" "IPA loaded"
to
gdb_test "info sharedlibrary" ".*[file tail ${libipa}].*" "IPA loaded"
so that only the "libinproctrace.so" part would be searched for.
Antoine (in CC) pointed out that I missed some, so I have to update
them. In the mean time, I noticed that I missed a few test failures:
adding the SONAME to the IPA makes it possible for the test executable
to erroneously pick up libinproctrace.so from /usr/lib if the test
harness failed to put the libinproctrace.so we want to test in the right
place. To mitigate that kind of error in the future, we can use the
return value of gdb_load_shlib (the path of the "runtime" version of the
library) and use that to search in the output of info sharedlibrary.
When testing locally, gdb_load_shlib returns the full normalized path of
the destination library, which the test executable should use e.g.:
/path/to/gdb/testsuite/outputs/gdb.trace/thetest/libinproctrace.so
My testing showed that it was the same path that gdb displayed in info
sharedlibrary. If the test executable picks up another
libinproctrace.so, the test will fail.
When testing remotely, gdb_load_shlib/gdb_remote_download only returns
us "libinproctrace.so", so the situation doesn't really change. If
there is a rogue libinproctrace.so in /usr/lib on the target and we fail
to download ours, it might cover up a test failure. But that situation
is probably still better than the original one, where it wasn't possible
to test remotely using the IPA at all.
[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=6e774b13c3b81ac2599812adf058796948ce7e95
gdb/testsuite/ChangeLog:
* gdb.arch/ftrace-insn-reloc.exp: Save gdb_load_shlib result,
use it in info sharedlibrary test.
* gdb.trace/ftrace-lock.exp: Likewise.
* gdb.trace/ftrace.exp: Likewise.
* gdb.trace/range-stepping.exp: Likewise.
* gdb.trace/trace-break.exp: Likewise.
* gdb.trace/trace-condition.exp: Likewise.
* gdb.trace/trace-mt.exp: Likewise.
Hi,
I happen to see that field need_step_over in struct lwp_info is only
used to print a debug info. need_step_over is set in linux_wait_1
when breakpoint_here is true, however, we check breakpoint_here too in
need_step_over_p and do the step over. I think we don't need field
need_step_over, and check breakpoint_here directly in need_step_over_p.
This field was added in this patch
https://sourceware.org/ml/gdb-patches/2010-03/msg00605.html and the code
wasn't changed much since then.
This patch is to remove it.
gdb/gdbserver:
2016-04-28 Yao Qi <yao.qi@linaro.org>
* linux-low.h (struct lwp_info) <need_step_over>: Remove.
* linux-low.c (linux_wait_1): Update.
(need_step_over_p): Likewise.
This patch makes gdb_load_shlibs return the destination path of the
copied library. To make the procedure implementation and interface more
straightforward, it also changes it so that it accepts a single shared
library path at the time. Therefore, calls that are passed multiple
libraries:
gdb_load_shlibs $lib1 $lib2
must be changed to separate calls:
gdb_load_shlibs $lib1
gdb_load_shlibs $lib2
A subtle impact is the solib-search-path handling. In the former
version, solib-search-path is set using the directory of the first
passed lib (further calls overwrite the value). In the later version,
the directory of the library passed to the last call to gdb_load_shlibs
remnains. I don't think that's a problem in practice, since if we had
tests that needed multiple different paths in solib-search-path, they
wouldn't work in the first place.
Changed in v2:
* Split behavioural and rename changes in two separate patches.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_load_shlibs): Accept a single argument. Return
result of gdb_remote_download.
* gdb.base/ctxobj.exp: Split gdb_load_shlibs call.
* gdb.base/dso2dso.exp: Likewise.
* gdb.base/global-var-nested-by-dso.exp: Likewise.
* gdb.base/print-file-var.exp: Likewise.
* gdb.base/shlib-call.exp: Likewise.
* gdb.base/shreloc.exp: Likewise.
* gdb.base/solib-overlap.exp: Likewise.
* gdb.base/solib-weak.exp (do_test): Likewise.
* gdb.base/unload.exp: Likewise.
With current FSF GDB HEAD and old FSF gdbserver I expected I could do:
gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234'
(supplying that unsupported qXfer:exec-file:read by "file")
But that does not work because:
Sending packet: $vFile:setfs:0#bf...Packet received: OK
Packet vFile:setfs (hostio-setfs) is supported
...
Sending packet: $vFile:setfs:104#24...Packet received: OK
"target:/root/redhat/threadit": could not open as an executable file: Invalid argument
GDB documentation says:
The valid responses to Host I/O packets are:
An empty response indicates that this operation is not recognized.
This "empty response" vs. "OK" was a bug in gdbserver < 7.7. It was fixed by:
commit e7f0d979dd
Author: Yao Qi <yao@codesourcery.com>
Date: Tue Dec 10 21:59:20 2013 +0800
Fix a bug in matching notifications.
Message-ID: <1386684626-11415-1-git-send-email-yao@codesourcery.com>
https://sourceware.org/ml/gdb-patches/2013-12/msg00373.html
2013-12-10 Yao Qi <yao@codesourcery.com>
* notif.c (handle_notif_ack): Return 0 if no notification
matches.
with unpatched old FSF gdbserver and patched FSF GDB HEAD:
gdb -ex 'file target:/root/redhat/threadit' -ex 'target remote :1234'
Sending packet: $vFile:setfs:0#bf...Packet received: OK
Packet vFile:setfs (hostio-setfs) is NOT supported
...
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00007ffff7ddbae0 0x00007ffff7df627a Yes (*) target:/lib64/ld-linux-x86-64.so.2
0x00007ffff7bc48a0 0x00007ffff7bcf514 Yes (*) target:/lib64/libpthread.so.0
gdb/ChangeLog
2016-04-26 Jan Kratochvil <jan.kratochvil@redhat.com>
* remote.c (remote_start_remote): Detect PACKET_vFile_setfs.support.
I get a timeout fail in branch-to-self.exp when it is compiled by a
bare-mental target running qemu, which doesn't have signal.
The test should be skipped if gdb,nosignals exists, and that is
what this patch does.
gdb/testsuite:
2016-04-27 Yao Qi <yao.qi@linaro.org>
* gdb.base/branch-to-self.exp: Skip it if gdb,nosignals
exists.
Currently c_value_print will turn struct reference values into pointers before
doing a set of RTTI checks. This was introduced as a fix to PR c++/15401.
If there's RTTI the pointer will be adjusted and converted back to a reference.
However, if there's no RTTI the value will still be treated as a pointer during
the remainder of the function.
This patch moves the conversion down so that it's always performed when needed.
Notice this currently has not user-visible effects, so can be seen as a small
code cleanup. However, it'll be necessary for the bug-fix for handling
synthetic C++ references. It causes no testsuite regressions.
gdb/ChangeLog:
2016-04-26 Martin Galvan <martin.galvan@tallertechnologies.com>
* c-valprint.c (c_value_print): Always convert val back to reference
type if we converted it to a pointer type.
Hi,
command "tfind" will find the first trace snapshot if no trace
snapshot is selected, but this behavior isn't documented.
This patch completes the doc of command "tfind" without argument.
gdb/doc:
2016-04-27 Yao Qi <yao.qi@linaro.org>
* gdb.texinfo (tfind): Complete doc about tfind without
argument.
In some babeltrace versions before 1.2.0, the header file iterator.h
declares the enum values `BT_SEEK_*' within the struct declaration of
bt_iter_pos. The enum values are supposed to be globally-scoped, which
works for C, but not for C++. Later babeltrace versions declare the
enum outside the struct:
https://lists.lttng.org/pipermail/lttng-dev/2013-September/021411.html
Now that GDB is compiled with C++, the GDB build fails on a system with
an affected babeltrace version: the compiler complains about a missing
declaration of BT_SEEK_BEGIN in ctf.c.
This patch enhances the configure check to recognize such babeltrace
versions as unusable for GDB.
gdb/ChangeLog:
* configure.ac: Enhance configure check for babeltrace to reject
non-C++-enabled versions.
* configure: Regenerate.
Instead of pre-computing indices into a fortran array re-use
the value_* interfaces to subscript a fortran array.
The benefit of using the new interface is that it takes care of
dynamic types and resolve them when needed.
This fixes issues when printing structures with dynamic arrays from toplevel.
Before:
(gdb) p twov
$1 = ( (( ( 6352320, 0, -66, -1, 267) ( 343476, 1, -15, 1, 0) ( 5, 0, 5, 0, 1) ...
After:
(gdb) p twov
$1 = ( (( ( 1, 1, 1, 1, 1) ( 1, 1, 321, 1, 1) ( 1, 1, 1, 1, 1) ...
2016-04-26 Sanimir Agovic <sanimir.agovic@intel.com>
Keven Boell <keven.boell@intel.com>
Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* f-valprint.c (f77_create_arrayprint_offset_tbl): Remove
function.
(F77_DIM_SIZE, F77_DIM_OFFSET): Remove macro.
(f77_print_array_1): Use value_subscript to subscript a
value array.
(f77_print_array): Remove call to f77_create_arrayprint_offset_tbl.
(f_val_print): Use value_field to construct a field value.
gdb/testsuite/Changelog:
* vla-type.exp: Print structure from toplevel.
Resolve type of an array's element to be printed in case it is dynamic.
Otherwise we don't use the correct boundaries nor the right location.
Before:
ptype fivearr(1)
type = Type five
Type one
integer(kind=4) :: ivla(34196784:34196832,34197072:34197120,34197360:34197408)
End Type one :: tone
End Type five
After:
ptype fivearr(1)
type = Type five
Type one
integer(kind=4) :: ivla(2,4,6)
End Type one :: tone
End Type five
2016-04-26 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* valarith.c (value_address): Resolve dynamic types.
gdb/testsuite/Changelog:
* gdb.fortran/vla-type.f90: Add test for static and dynamic arrays
of dynamic types.
* gdb.fortran/vla-type.exp: Add test for static and dynamic arrays
of dynamic types.
Fortran supports dynamic types for which bounds, size and location
can vary during their lifetime. As a result of the dynamic
behaviour, they have to be resolved at every query.
This patch will resolve the type of a structure field when it
is dynamic.
2016-04-26 Bernhard Heckel <bernhard.heckel@intel.com>
2016-04-26 Keven Boell <keven.boell@intel.com>
Before:
(gdb) print threev%ivla(1)
Cannot access memory at address 0x3
(gdb) print threev%ivla(5)
no such vector element
After:
(gdb) print threev%ivla(1)
$9 = 1
(gdb) print threev%ivla(5)
$10 = 42
gdb/Changelog:
* NEWS: Add new supported features for fortran.
* gdbtypes.c (remove_dyn_prop): New.
(resolve_dynamic_struct): Keep type length for fortran structs.
* gdbtypes.h: Forward declaration of new function.
* value.c (value_address): Return dynamic resolved location of a value.
(set_value_component_location): Adjust the value address
for single value prints.
(value_primitive_field): Support value types with a dynamic location.
(set_internalvar): Remove dynamic location property of
internal variables.
gdb/testsuite/Changelog:
* gdb.fortran/vla-type.f90: New file.
* gdb.fortran/vla-type.exp: New file.
When GDBserver steps over a breakpoint using software single step, it
enqueues the signal, single step and deliver the signal in the next
resume if step over is not needed. In this way, the program won't
receive the signal if the conditional breakpoint is set a branch to
self instruction, because the step over is always needed.
This patch removes the restriction that don't deliver the signal to
the inferior if we are trying to reinsert a breakpoint for software
single step and change the decision on resume vs. step-over when the
LWP has pending signals to deliver.
gdb/gdbserver:
2016-04-25 Yao Qi <yao.qi@linaro.org>
* linux-low.c (lwp_signal_can_be_delivered): Adjust.
(need_step_over_p): Return zero if the LWP has pending signals
can be delivered on software single step target.
GDBserver steps over a breakpoint while the single step breakpoint
is inserted at the same address, there are two breakpoint objects
using single raw breakpoint, which is inserted (for single step).
When step over is finished, GDBserver reinsert the breakpoint, but
it finds the raw breakpoint is already inserted, and error out
"Breakpoint already inserted at reinsert time." Even if I change the
order to delete reinsert breakpoints first (which only decreases the
refcount, but leave inserted flag unchanged), the error is still
there.
The fix is to remove the error and return instead.
gdb/gdbserver:
2016-04-25 Yao Qi <yao.qi@linaro.org>
* linux-low.c (reinsert_raw_breakpoint): If bp->inserted is true
return instead of error.
When GDBserver inserts a breakpoint, it looks for raw breakpoint, if
the raw breakpoint is found, increase its refcount, and return. This
doesn't work when it steps over a breakpoint using software single
step and the underneath instruction of breakpoint is branch to self.
When stepping over a breakpoint on ADDR using software single step,
GDBserver uninsert the breakpoint, so the corresponding raw breakpoint
RAW's 'inserted' flag is zero. Then, GDBserver insert single step
breakpoint at the same address ADDR because the instruction is branch
to self, the same raw brekapoint RAW is found, and increase the
refcount. However, the raw breakpoint is not inserted, and the
program won't stop.
gdb/gdbserver:
2016-04-25 Pedro Alves <palves@redhat.com>
Yao Qi <yao.qi@linaro.org>
* mem-break.c (set_raw_breakpoint_at): Create a raw breakpoint
object. Insert it if it is not inserted yet. Increase the
refcount and link it into the proc's raw breakpoint list.
GDB doesn't insert software single step breakpoint if the instruction
branches to itself, so that the program can't stop after command "si".
(gdb) b 32
Breakpoint 2 at 0x8680: file git/gdb/testsuite/gdb.base/branch-to-self.c, line 32.
(gdb) c
Continuing.
Breakpoint 2, main () at gdb/git/gdb/testsuite/gdb.base/branch-to-self.c:32
32 asm (".Lhere: " BRANCH_INSN " .Lhere"); /* loop-line */
(gdb) si
infrun: clear_proceed_status_thread (Thread 3991.3991)
infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: step-over queue now empty
infrun: resuming [Thread 3991.3991] for step-over
infrun: skipping breakpoint: stepping past insn at: 0x8680
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sending packet: $Z0,8678,4#f3...Packet received: OK
infrun: skipping breakpoint: stepping past insn at: 0x8680
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sending packet: $Z0,b6fe86c8,4#82...Packet received: OK
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 3991.3991] at 0x868
breakpoint.c:should_be_inserted thinks the breakpoint shouldn't be
inserted, which is wrong. This patch restrict the condition that
only skip the non-single-step breakpoints if they are inserted at
the place we are stepping over, however we don't want to skip
single-step breakpoint if its thread is the thread we are stepping
over, so in this patch, I add a thread num in 'struct step_over_info'
to record the thread we're stepping over.
gdb:
2016-04-25 Yao Qi <yao.qi@linaro.org>
* breakpoint.c (should_be_inserted): Return 0 if the location's
owner is not single step breakpoint or single step breakpoint's
thread isn't the thread which is stepping past a breakpoint.
* gdbarch.sh (software_single_step): Update comments.
* gdbarch.h: Regenerated.
* infrun.c (struct step_over_info) <thread>: New field.
(set_step_over_info): New argument 'thread'. Callers updated.
(clear_step_over_info): Set field thread to -1.
(thread_is_stepping_over_breakpoint): New function.
* infrun.h (thread_is_stepping_over_breakpoint): Declaration.
gdb/ChangeLog
* ppc-linux-nat.c (ppc_linux_read_description): Use PPC_FEATURE_HAS_VSX
and PPC_FEATURE_HAS_ALTIVEC to check if such features are available.
I am seeing some test fails in gdb.trace/unavailable.exp on aarch64-linux,
like this,
print derived_whole^M
$43 = (Derived) {<Middle> = {<Base> = {x = 2}, _vptr.Middle = 0x401860 <VTT for Derived>, y = 3}, _vptr.Derived = 0x401848 <vtable for Derived+32>, z = 4}^M
(gdb) FAIL: gdb.trace/unavailable.exp: collect globals: print object on: print derived_whole
print derived_whole^M
$47 = {<Middle> = {<Base> = {x = 2}, _vptr.Middle = 0x401860 <VTT for Derived>, y = 3}, _vptr.Derived = 0x401848 <vtable for Derived+32>, z = 4}^M
(gdb) FAIL: gdb.trace/unavailable.exp: collect globals: print object off: print derived_whole
these fails are also found by recent x86_64-linux buildbot,
https://sourceware.org/ml/gdb-testers/2016-q2/msg00622.html
The fix is exactly the same as this one
http://www.sourceware.org/ml/gdb-patches/2015-10/msg00252.html (the
extra "VTT" after hex), in which we match extra things after $hex.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.trace/unavailable.exp (gdb_collect_globals_test_1): Match
more after $hex.
Before this patch
https://sourceware.org/ml/gdb-patches/2014-02/msg00709.html
read_value_memory checks parameter 'stack', and call read_stack or
read_memory respectively. However, 'stack' is not checked and
TARGET_OBJECT_MEMORY is always used in target_xfer_partial, which is
a mistake in the patch above.
This patch checks parameter 'stack', and choose TARGET_OBJECT_MEMORY
or TARGET_OBJECT_STACK_MEMORY accordingly.
gdb:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* valops.c (read_value_memory): New local variable 'stack'.
Set it to either TARGET_OBJECT_STACK_MEMORY or
TARGET_OBJECT_MEMORY.
This factors out all the yy-variables remapping to a single file,
instead of each parser having to do the same, with different prefixes.
With this, a parser just needs to define the prefix they want and
include yy-remap.h, which does the dirty job.
Note this renames the c_error, ada_error, etc. functions. Writing the
remapping pattern as:
#define yyerror GDB_YY_REMAP (error)
instead of:
#define yyerror GDB_YY_REMAP (yyerror)
would have avoided the renaming. However, that would be problematic
if we have a macro 'foo' in scope, when we write:
#define yyfoo GDB_YY_REMAP (foo)
as that would expand 'foo'.
The c_yyerror etc. naming end ups indicating that this is a yacc
related function more clearly, so feels like a good change, anyway.
gdb/ChangeLog:
2016-04-22 Pedro Alves <palves@redhat.com>
* ada-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* ada-lang.c (ada_language_defn): Adjust.
* ada-lang.h (ada_error): Rename to ...
(ada_yyerror): ... this.
* c-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* c-lang.c (c_language_defn, cplus_language_defn)
(asm_language_defn, minimal_language_defn): Adjust.
* c-lang.h (c_error): Rename to ...
(c_yyerror): ... this.
* d-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* d-lang.c (d_language_defn): Adjust.
* d-lang.h (d_error): Rename to ...
(d_yyerror): ... this.
* f-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* f-lang.c (f_language_defn): Adjust.
* f-lang.h (f_error): Rename to ...
(f_yyerror): ... this.
* go-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* go-lang.c (go_language_defn): Adjust.
* go-lang.h (go_error): Rename to ...
(go_yyerror): ... this.
* jv-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* jv-lang.c (java_language_defn): Adjust.
* jv-lang.h (java_error): Rename to ...
(java_yyerror): ... this.
* m2-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* m2-lang.c (m2_language_defn): Adjust.
* m2-lang.h (m2_error): Rename to ...
(m2_yyerror): ... this.
* objc-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* objc-lang.c (objc_language_defn): Adjust.
* opencl-lang.c (opencl_language_defn): Adjust.
* p-exp.y: Remove all yy symbol remappings.
(GDB_YY_REMAP_PREFIX): Define.
Include "yy-remap.h".
* p-lang.c (pascal_language_defn): Adjust.
* p-lang.h (pascal_error): Rename to ...
(pascal_yyerror): ... this.
* yy-remap.h: New file.
The exceptions-across-readline issue was fixed by the previous commit.
Let's try this again.
gdb/ChangeLog:
2016-04-22 Pedro Alves <palves@redhat.com>
* common/common-exceptions.h (GDB_XCPT_TRY): Remove mention of
the foreign frames issue.
[__cplusplus] (GDB_XCPT): Define as GDB_XCPT_TRY.
If we map GDB'S TRY/CATCH macros to C++ try/catch, GDB breaks on
systems where readline isn't built with exceptions support. The
problem is that readline calls into GDB through the callback
interface, and if GDB's callback throws a C++ exception/error, the
system unwinder won't manage to unwind past the readline frame, and
ends up calling std::terminate(), which aborts the process:
(gdb) whatever-command-that-causes-an-error
terminate called after throwing an instance of 'gdb_exception_RETURN_MASK_ERROR'
Aborted
$
This went unnoticed for so long because:
- the x86-64 ABI requires -fasynchronous-unwind-tables, making it
possible for exceptions to cross readline with no special handling.
But e.g., on ARM or AIX, unless you build readline with
-fexceptions, you trip on the problem.
- TRY/CATCH was mapped to setjmp/longjmp, even in C++ mode, until
quite recently.
The fix is to catch and save any GDB exception that is thrown inside
the GDB readline callback, and then once the callback returns back to
the GDB code that called into readline in the first place, rethrow the
saved GDB exception.
This is similar in spirit to how we catch/map GDB exceptions at the
GDB/Python and GDB/Guile API boundaries.
The next question is then: if we intercept all exceptions within GDB's
readline callback, should we simply return normally to readline? The
callback prototype has no way to signal an error back to readline (*).
The answer is no -- if we return normally, we'll be returning to a
loop inside rl_callback_read_char that continues processing pending
input, calling into GDB again, redisplaying the prompt, etc. Thus if
we want to error out of rl_callback_read_char, we need to long jump
across it, just like we always did before TRY/CATCH were ever mapped
to C++ exceptions.
My first approach built a specialized API to handle this, with a
couple macros to hide the setjmp/longjmp and the struct gdb_exception
saving/rethrowing.
However, I realized that we need to:
- Handle multiple active rl_callback_read_char invocations. If,
while processing input something triggers a secondary prompt, we
end up in a nested rl_callback_read_char call, through
gdb_readline_wrapper.
- Propagate a struct gdb_exception along with the longjmp.
... and that this is exactly what the setjmp/longjmp-based TRY/CATCH
does.
So the fix makes the setjmp/longjmp TRY/CATCH always available under
new TRY_SJLJ/CATCH_SJLJ aliases, even when TRY/CATCH is mapped to C++
try/catch, and then uses TRY_SJLJ/CATCH_SJLJ to propagate GDB
exceptions across the readline callback.
This turns out to be a much better looking fix than my bespoke API
attempt, even. We'll probably be able to simplify TRY_SJLJ/CATCH_SJLJ
when we finally get rid of TRY/CATCH all over the tree, but until
then, this reuse seems quite nice for avoiding a second parallel
setjmp/longjmp mechanism.
(*) - maybe we could propose a readline API change, but we still need
to handle current readline, anyway.
gdb/ChangeLog:
2016-04-22 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (enum catcher_state, struct catcher)
(current_catcher): Define in C++ mode too.
(exceptions_state_mc_catch): Call throw_exception_sjlj instead of
throw_exception.
(throw_exception_sjlj, throw_exception_cxx): New functions,
factored out from throw_exception.
(throw_exception): Reimplement.
* common/common-exceptions.h (exceptions_state_mc_init)
(exceptions_state_mc_action_iter)
(exceptions_state_mc_action_iter_1, exceptions_state_mc_catch):
Declare in C++ mode too.
(TRY): Rename to ...
(TRY_SJLJ): ... this.
(CATCH): Rename to ...
(CATCH_SJLJ): ... this.
(END_CATCH): Rename to ...
(END_CATCH_SJLJ): ... this.
[GDB_XCPT == GDB_XCPT_SJMP] (TRY, CATCH, END_CATCH): Map to SJLJ
equivalents.
(throw_exception): Update comments.
(throw_exception_sjlj): Declare.
* event-top.c (gdb_rl_callback_read_char_wrapper): Extend intro
comment. Wrap body in TRY_SJLJ/CATCH_SJLJ and rethrow any
intercepted exception.
(gdb_rl_callback_handler): New function.
(gdb_rl_callback_handler_install): Always install
gdb_rl_callback_handler as readline callback.
Use the "gdb_rl_" prefix like other gdb readline function wrappers to
make it clear this is a gdb function, not a readline function.
gdb/ChangeLog:
2016-04-22 Pedro Alves <palves@redhat.com>
* event-top.c (rl_callback_read_char_wrapper): Rename to ...
(gdb_rl_callback_read_char_wrapper): ... this.
(change_line_handler, gdb_setup_readline): Adjust.
Bits 20 ~ 23 of CPSR are reserved (RAZ, read as zero), but they are not
zero if the arm program runs on aarch64-linux. AArch64 tracer gets PSTATE
from arm 32-bit tracee as CPSR, but bits 20 ~ 23 are used in PSTATE. I
think kernel should clear these bits when it is read through ptrace, but
the fix in user space is still needed.
This patch fixes these two fails,
-FAIL: gdb.reverse/insn-reverse.exp: ext_reg_push_pop: compare registers on insn 0:vldr d7, [r11, #-12]
-FAIL: gdb.reverse/insn-reverse.exp: ext_reg_push_pop: compare registers on insn 0:vldr d7, [r7]
gdb:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* aarch32-linux-nat.c (aarch32_gp_regcache_supply): Clear CPSR
bits 20 to 23.
gdb/gdbserver:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* linux-aarch32-low.c (arm_store_gregset): Clear CPSR bits 20
to 23.
Hi,
I am seeing the fail below on aarch64-linux with gcc 4.9.2,
break main
Breakpoint 1 at 0x4006e8: file binutils-gdb/gdb/testsuite/gdb.base/annota1.c, line 14.^M
(gdb) FAIL: gdb.base/annota1.exp: breakpoint main
the test expects the breakpoint is set on line 15. Let us look at
the main function,
12 int
13 main (void)
14 {
15 int my_array[3] = { 1, 2, 3 }; /* break main */
16
17 value = 7;
18
19 #ifdef SIGUSR1
20 signal (SIGUSR1, handle_USR1);
21 #endif
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004006e0 <+0>: stp x29, x30, [sp,#-48]!
0x00000000004006e4 <+4>: mov x29, sp
0x00000000004006e8 <+8>: adrp x0, 0x411000 <signal@got.plt>
0x00000000004006ec <+12>: add x0, x0, #0x40
the breakpoint is set on the right address after skipping prologue, but
0x00000000004006e8 is mapped to the line 14, as shown below,
(gdb) maintenance info line-table
objfile: /home/yao.qi/source/build-aarch64/gdb/testsuite/outputs/gdb.base/annota1/annota1 ((struct objfile *) 0x2b0e1850)
compunit_symtab: ((struct compunit_symtab *) 0x2b0ded50)
symtab: /home/yao.qi/source/binutils-gdb/gdb/testsuite/gdb.base/annota1.c ((struct symtab *) 0x2b0dedd0)
linetable: ((struct linetable *) 0x2b12c8b0):
INDEX LINE ADDRESS
0 7 0x00000000004006d0
1 8 0x00000000004006d8
2 14 0x00000000004006e0
3 14 0x00000000004006e8
4 15 0x00000000004006fc
so GDB does nothing wrong. Program hits breakpoint on either line 14
or line 15 is right to me. With anther gcc (4.9.3), the line-table looks
correct, and no test fail. Instead of setting breakpoint on main and
assuming the line is what we get from the source, we can set breakpoint
on that line. On the other hand, the test prints the values of the
array and check, so we need to set breakpoint on the line setting the
values of array and "next", rather than setting the breakpoint on main.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.base/annota1.exp: Set breakpoint on line $main_line.
* gdb.base/annota3.exp: Likewise.
Simple exchange of mpx-avx for avx-mpx.
Other occurrences were not found.
2016-04-22 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/gdbserver/ChangeLog:
* configure.srv (srv_amd64_xmlfiles): Exchange
i386/amd64-mpx-avx.xml for i386/amd64-avx-mpx.xml.
I see the following test fail in arm-linux with -marm and -fomit-frame-pointer,
step
callee () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c:27
27 } /* RETURN FROM CALLEE */
(gdb) step
main () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c:58
58 callee(); /* STEP INTO THIS CALL */
(gdb) FAIL: gdb.reverse/step-precsave.exp: reverse step into fn call
As we can see, the "step" has already stepped into the function callee,
but in the last line. The second "step" attempts to step to function
body, but it goes out of callee, which isn't expected.
The program is compiled with -marm and -fomit-frame-pointer, the
function callee is prologue-less, because nothing needs to be saved
on stack,
(gdb) disassemble callee
Dump of assembler code for function callee:
0x00010680 <+0>: movw r3, #2364 ; 0x93c
0x00010684 <+4>: movt r3, #2
0x00010688 <+8>: ldr r3, [r3]
0x0001068c <+12>: add r2, r3, #1
0x00010690 <+16>: movw r3, #2364 ; 0x93c
0x00010694 <+20>: movt r3, #2
0x00010698 <+24>: str r2, [r3]
0x0001069c <+28>: mov r3, #0
0x000106a0 <+32>: mov r0, r3
0x000106a4 <+36>: bx lr
program stops at the 0x106a0 (passed the epilogue) after the first
"step". When second "step" is executed, the stepping range is
[0x10680-0x106a0], which starts from the first instruction of function
callee (because it doesn't have prologue).
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [LWP 2461] at 0x1069c^M
infrun: prepare_to_wait^M
infrun: target_wait (-1.0.0, status) =^M
infrun: 2461.2461.0 [LWP 2461],^M
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP^M
infrun: TARGET_WAITKIND_STOPPED^M
infrun: stop_pc = 0x10698^M
infrun: stepping inside range [0x10680-0x106a0]
When program goes out of the range, it stops at the caller of callee,
and test fails. IOW, if function callee has prologue, the stepping
range won't start from the first instruction of the function, and
program stops at the prologue and test passes.
IMO, GDB does nothing wrong, but test shouldn't expect the program
stops in callee after the second "step". I decide to fix test rather
than GDB. In this patch, I change to test to do one "step", and check
the program is still in callee, then, do multiple "step" until program
goes out of the callee.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.reverse/step-precsave.exp: Do one step and test program
stops in "callee" and do multiple steps until program goes out
of "callee".
* gdb.reverse/step-reverse.exp: Likewise.
GDBserver doesn't deliver signal when stepping over a breakpoint even
hardware single step is used. When GDBserver started to step over
(thread creation) breakpoint for mutlit-threaded debugging in 2002 [1],
GDBserver behaves this way.
This behavior gets trouble on conditional breakpoints on branch to
self instruction like this,
0x00000000004005b6 <+29>: jmp 0x4005b6 <main+29>
and I set breakpoint
$(gdb) break branch-to-self.c:43 if counter > 3
and the variable counter will be set to 5 in SIGALRM signal handler.
Since GDBserver keeps stepping over breakpoint, the SIGALRM can never
be dequeued and delivered to the inferior, so the program can't stop.
The test can be found in gdb.base/branch-to-self.exp.
GDBserver didn't deliver signal when stepping over a breakpoint because
a tracepoint is collected twice if GDBserver does so in the following
scenario, which can be reproduced by gdb.trace/signal.exp.
- program stops at tracepoint, and tracepoint is collected,
- gdbserver starts a step-over,
- a signal arrives, step-over is canceled, and signal should be passed,
- gdbserver starts a new step-over again, pass the signal as well,
- program stops at the entry of signal handler, step-over finished,
- gdbserver proceeds,
- program returns from the signal handler, again to the tracepoint,
and thus is collected again.
The spurious collection isn't that harmful, IMO, so it should be OK
to let GDBserver deliver signal when stepping over a breakpoint.
gdb/gdbserver:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* linux-low.c (lwp_signal_can_be_delivered): Don't deliver
signal when stepping over breakpoint with software single
step.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.trace/signal.exp: Also pass if
$tracepoint_hits($i) > $iterations.
This is to test whether GDBserver deliver signal to the inferior while
doing the step over. Nowadays, GDBserver doesn't deliver signal, so
there won't be spurious collection, however, if GDBserver does deliver
signal, there might be spurious collection.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.trace/signal.c: New file.
* gdb.trace/signal.exp: New file.