A little patch for two comments in infrun.c

A little patch for two comments in infrun.c

[Wu Zhou]

Hi,

I am reading the source of infrun.c, and having a couple questions about 
two comments in the code:

First, in resume (int step, enum target_signal sig), one comment says:

  /* FIXME: calling breakpoint_here_p (read_pc ()) three times! */

Does this still make sense?  In function resume, there does exist three 
call for breakpoint_here_p (read_pc ()).  But read_pc () might return 
various values at various points.  The breakpoint chain maintained in 
this function might also change as the execution proceeds.  So I am 
thinking this comment doesn't make sense here.  Am I right?  Any error, 
feel free to correct me.

I also think the comment in the following code (in handle_inferior_event) 
should be changed.
  
  /* If it's a new process, add it to the thread database */

  ecs->new_thread_event = (!ptid_equal (ecs->ptid, inferior_ptid)
                           && !ptid_equal (ecs->ptid, minus_one_ptid)
                           && !in_thread_list (ecs->ptid));

IMHO, "new thread" describes more properly about the code.

I have a patch for the above two comments.

--- infrun.c.orig	2006-05-29 23:52:47.000000000 -0700
+++ infrun.c	2006-05-29 23:53:24.000000000 -0700
@@ -531,9 +531,6 @@ resume (int step, enum target_signal sig
     fprintf_unfiltered (gdb_stdlog, "infrun: resume (step=%d, signal=%d)\n",
 			step, sig);
 
-  /* FIXME: calling breakpoint_here_p (read_pc ()) three times! */
-
-
   /* Some targets (e.g. Solaris x86) have a kernel bug when stepping
      over an instruction that causes a page fault without triggering
      a hardware watchpoint. The kernel properly notices that it shouldn't
@@ -1290,7 +1287,7 @@ handle_inferior_event (struct execution_
 
   flush_cached_frames ();
 
-  /* If it's a new process, add it to the thread database */
+  /* If it's a new thread, add it to the thread database */
 
   ecs->new_thread_event = (!ptid_equal (ecs->ptid, inferior_ptid)
 			   && !ptid_equal (ecs->ptid, minus_one_ptid)

OK to commit?

Regards
- Wu Zhou

Re: A little patch for two comments in infrun.c

[Jim Blandy]

Wu Zhou <woodzltc@cn.ibm.com> writes:
> --- infrun.c.orig	2006-05-29 23:52:47.000000000 -0700
> +++ infrun.c	2006-05-29 23:53:24.000000000 -0700
> @@ -531,9 +531,6 @@ resume (int step, enum target_signal sig
>      fprintf_unfiltered (gdb_stdlog, "infrun: resume (step=%d, signal=%d)\n",
>  			step, sig);
>  
> -  /* FIXME: calling breakpoint_here_p (read_pc ()) three times! */
> -
> -
>    /* Some targets (e.g. Solaris x86) have a kernel bug when stepping
>       over an instruction that causes a page fault without triggering
>       a hardware watchpoint. The kernel properly notices that it shouldn't
> @@ -1290,7 +1287,7 @@ handle_inferior_event (struct execution_
>  
>    flush_cached_frames ();
>  
> -  /* If it's a new process, add it to the thread database */
> +  /* If it's a new thread, add it to the thread database */
>  
>    ecs->new_thread_event = (!ptid_equal (ecs->ptid, inferior_ptid)
>  			   && !ptid_equal (ecs->ptid, minus_one_ptid)
>

This looks right to me (with an appropriate (trivial) ChangeLog entry,
of course).  But let's wait a bit to see if anyone more familiar with
infrun.c comments.

Re: A little patch for two comments in infrun.c

[Daniel Jacobowitz]

On Tue, May 30, 2006 at 04:24:11PM +0800, Wu Zhou wrote:
> Hi,
> 
> I am reading the source of infrun.c, and having a couple questions about 
> two comments in the code:
> 
> First, in resume (int step, enum target_signal sig), one comment says:
> 
>   /* FIXME: calling breakpoint_here_p (read_pc ()) three times! */
> 
> Does this still make sense?  In function resume, there does exist three 
> call for breakpoint_here_p (read_pc ()).  But read_pc () might return 
> various values at various points.  The breakpoint chain maintained in 
> this function might also change as the execution proceeds.  So I am 
> thinking this comment doesn't make sense here.  Am I right?  Any error, 
> feel free to correct me.

That's why it hasn't been fixed yet :-)  It's wasteful, but not very
wasteful, because of the register cache.  The breakpoint chain
shouldn't change during the function; the singlestep breakpoint is
modified, but isn't on that chain.

I don't much care if you leave or remove the FIXME.


-- 
Daniel Jacobowitz
CodeSourcery