FreeBSD's librt uses SIGLIBRT as an internal signal to implement
SIGEV_THREAD sigevent notifications. Similar to SIGLWP or SIGCANCEL
this signal should be passed through to child processes by default.
include/ChangeLog:
* signals.def: Add GDB_SIGNAL_LIBRT.
gdb/ChangeLog:
* common/signals.c (gdb_signal_from_host): Handle SIGLIBRT.
(do_gdb_signal_to_host): Likewise.
* infrun.c (_initialize_infrun): Pass GDB_SIGNAL_LIBRT through to
programs.
* proc-events.c (signal_table): Add entry for SIGLIBRT.
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.
John Baldwin
Tom Tromey
Jan Kratochvil
Yao Qi
Chung-Lin Tang
Walfred Tedeschi
Simon Marchi
Manish Goregaokar
Don Breazeal
Pedro Alves