Re: [PATCH,ARM] Fix single step on vfork

Yao Qi
2010-09-08T12:26:23Z

[-- Attachment #1: Type: text/plain, Size: 647 bytes --]

Pedro Alves wrote:
> On Monday 06 September 2010 14:29:29, Yao Qi wrote:
>> Pedro Alves wrote:
>>> Thanks. Please go ahead with your patch. Hope you don't mind I tweak
>>> the comment a bit afterwards.
>>>
>> Pedro,
>> Thanks for your view, and free to tweak the comment.
>>
>> Committed to GDB mainline,
>> http://www.cygwin.com/ml/gdb-cvs/2010-09/msg00042.html
>>
>> Once you changed the comment, I'd like to merge it to GDB 7.2 branch then.
>
> Okay. I've now applied this to mainline.

Committed it to GDB 7.2 branch.
http://www.cygwin.com/ml/gdb-cvs/2010-09/msg00054.html

--
Yao Qi
CodeSourcery
yao@codesourcery.com
(650) 331-3385 x739

[-- Attachment #2: single_step_vfork.patch --]
[-- Type: text/x-patch, Size: 2408 bytes --]

Index: infrun.c
2010-09-08 Yao Qi <yao@codesourcery.com>
Pedro Alves <pedro@codesourcery.com>

* infrunc(resume): When inferior is waiting_for_vfork_done,
clear step and don't use displaced stepping.
Extend comment on ignoring single-step requests on vfork
parents waiting for a vfork-done.

===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.445.2.1
diff -u -r1.445.2.1 infrun.c
--- infrun.c 31 Aug 2010 19:31:23 -0000 1.445.2.1
+++ infrun.c 8 Sep 2010 12:16:17 -0000
@@ -1549,6 +1549,25 @@

QUIT;

+ /* Don't try to single-step a vfork parent that is waiting for
+ the child to get out of the shared memory region (by exec'ing
+ or exiting). This is particularly important on software
+ single-step archs, as the child process would trip on the
+ software single step breakpoint inserted for the parent
+ process. Since the parent will not actually execute any
+ instruction until the child is out of the shared region (such
+ are vfork's semantics), it is safe to simply continue it.
+ Eventually, we'll see a TARGET_WAITKIND_VFORK_DONE event for
+ the parent, and tell it to `keep_going', which automatically
+ re-sets it stepping. */
+ if (current_inferior ()->waiting_for_vfork_done)
+ {
+ if (debug_infrun)
+ fprintf_unfiltered (gdb_stdlog,
+ "infrun: resume : clear step\n");
+ step = 0;
+ }
+
if (debug_infrun)
fprintf_unfiltered (gdb_stdlog,
"infrun: resume (step=%d, signal=%d), "
@@ -1576,11 +1595,16 @@
We can't use displaced stepping when we have a signal to deliver;
the comments for displaced_step_prepare explain why. The
comments in the handle_inferior event for dealing with 'random
- signals' explain what we do instead. */
+ signals' explain what we do instead.
+
+ We can't use displaced stepping when we are waiting for vfork_done
+ event, displaced stepping breaks the vfork child similarly as single
+ step software breakpoint. */
if (use_displaced_stepping (gdbarch)
&& (tp->trap_expected
|| (step && gdbarch_software_single_step_p (gdbarch)))
- && sig == TARGET_SIGNAL_0)
+ && sig == TARGET_SIGNAL_0
+ && !current_inferior ()->waiting_for_vfork_done)
{
struct displaced_step_inferior_state *displaced;