This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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
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;
 

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]