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, ppc] Fix hw *points for embedded ppc in a threaded environment.


On Mon, 06 Aug 2012 16:33:58 +0200, Luis Gustavo wrote:
> With the somewhat recent booke kernel interface, more hw
> watchpoints/breakpoints are available to GDB.

Which hardware can be BookE tested on?  Red Hat has available for example
PPC970FX, POWER5, POWER7 etc. but those AFAIK are not BookE.  Or does it
depend just on kernel?


> The logic of replicating the existing process' debug state to the
> new thread is still there though, but the new booke interface in the
> kernel already replicates that state. More precisely, the kernel
> gives the new thread the debug state of its parent thread.

I have been testing it recently for fork() (processes, no threads) and my
results were:

kernel-3.3.4-5.fc17.ppc64 clears debug info in both parent (!) and child
kernel-2.6.18-308.el5.ppc64 copies debug info to child and keeps it in parent


> It's still unclear if the kernel is supposed to do this and i'm
> chasing answers with the ppc linux kernel folks (https://lists.ozlabs.org/pipermail/linuxppc-dev/2012-August/100083.html).
> Nonetheless, the kernel is out and it has such behavior.

Yes, I agree GDB should cope with all these kinds of behavior.


> --- gdb_head.orig/gdb/ppc-linux-nat.c	2012-08-06 11:02:12.538532628 -0300
> +++ gdb_head/gdb/ppc-linux-nat.c	2012-08-06 11:04:38.486536320 -0300
> @@ -2179,7 +2179,21 @@ ppc_linux_new_thread (struct lwp_info *l
>        /* Copy that thread's breakpoints and watchpoints to the new thread.  */
>        for (i = 0; i < max_slots_number; i++)
>  	if (hw_breaks[i].hw_break)
> -	  booke_insert_point (hw_breaks[i].hw_break, tid);
> +	  {
> +	    /* The ppc Linux kernel causes a thread to inherit its parent
> +	       thread's debug state, and that includes any hardware
> +	       watchpoints or breakpoints that the parent thread may have set.
> +
> +	       For this reason, the debug state of the new thread is cleared
> +	       before trying to replicate any hardware watchpoints or
> +	       breakpoints contained in other threads.  */
> +
> +	    /* The ppc debug resource accounting is done through "slots".
> +	       Ask the kernel the deallocate this specific *point's slot.  */
> +	    ptrace (PPC_PTRACE_DELHWDEBUG, tid, 0, hw_breaks[i].slot);
> +
> +	    booke_insert_point (hw_breaks[i].hw_break, tid);

I agree with the patch.

I was considering to call PPC_PTRACE_DELHWDEBUG unconditionally but that would
be probably an unneeded overhead.

Did you test that kernel really does not reorder the [i] slots during
inheritance into the new thread?


> +	  }
>      }
>    else
>      ptrace (PTRACE_SET_DEBUGREG, tid, 0, saved_dabr_value);


> This would be nice to include before 7.5, as it's an annoying problem.

Does this fix affect existing testcases on BookE?
Otherwise a new testcase would be appropriate.


Thanks,
Jan


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