This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug server/15959] GDBserver hangs when started with --wrapper
- From: "qiyao at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Tue, 17 Sep 2013 03:59:10 +0000
- Subject: [Bug server/15959] GDBserver hangs when started with --wrapper
- Auto-submitted: auto-generated
- References: <bug-15959-4717 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=15959
Yao Qi <qiyao at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at sourceware dot org |qiyao at gcc dot gnu.org
--- Comment #1 from Yao Qi <qiyao at gcc dot gnu.org> ---
'git bisect' tells me that the this is the bad commit.
$ git bisect bad
6876850721768f002bdebf47ea013b6283403d37 is the first bad commit
commit 6876850721768f002bdebf47ea013b6283403d37
Author: Pedro Alves <palves@redhat.com>
Date: Thu May 23 17:17:50 2013 +0000
range stepping: gdbserver (x86 GNU/Linux)
This patch adds support for range stepping to GDBserver, teaching it
about vCont;r.
It'd be easy to enable this for all hardware single-step targets
without needing the linux_target_ops hook, however, at least PPC needs
special care, due to the fact that PPC atomic sequences can't be
hardware single-stepped through, a thing which GDBserver doesn't know
about. So this leaves the support limited to x86/x86_64.
gdb/
2013-05-23 Pedro Alves <palves@redhat.com>
* NEWS: Mention GDBserver range stepping support.
gdb/gdbserver/
2013-05-23 Yao Qi <yao@codesourcery.com>
Pedro Alves <palves@redhat.com>
* linux-low.c (lwp_in_step_range): New function.
(linux_wait_1): If the thread was range stepping and stopped
outside the stepping range, report the stop to GDB. Otherwise,
continue stepping. Add range stepping debug output.
(linux_set_resume_request): Copy the step range from the resume
request to the lwp.
(linux_supports_range_stepping): New.
(linux_target_ops) <supports_range_stepping>: Set to
linux_supports_range_stepping.
* linux-low.h (struct linux_target_ops)
<supports_range_stepping>: New field.
(struct lwp_info) <step_range_start, step_range_end>: New fields.
* linux-x86-low.c (x86_supports_range_stepping): New.
(the_low_target) <supports_range_stepping>: Set to
x86_supports_range_stepping.
* server.c (handle_v_cont): Handle 'r' action.
(handle_v_requests): Append ";r" if the target supports range
stepping.
* target.h (struct thread_resume) <step_range_start,
step_range_end>: New fields.
(struct target_ops) <supports_range_stepping>:
New field.
(target_supports_range_stepping): New macro.
:040000 040000 589d7012bc4251860fbd2d58331ed2a8f58ae61b
ff6f44eb52779599f339d0461f92a54bfcd924dc M gdb
In this commit, we added two fields in 'struct thread_resume', but these two
fields are not initialized properly in 'start_inferior',
struct thread_resume resume_info;
resume_info.thread = pid_to_ptid (signal_pid);
resume_info.kind = resume_continue;
resume_info.sig = 0;
I'll post a patch.
--
You are receiving this mail because:
You are on the CC list for the bug.