From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31538 invoked by alias); 6 Aug 2012 18:40:02 -0000 Received: (qmail 31428 invoked by uid 22791); 6 Aug 2012 18:40:00 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 06 Aug 2012 18:39:42 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q76IcvSO017285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Aug 2012 14:39:18 -0400 Received: from host2.jankratochvil.net (ovpn-116-27.ams2.redhat.com [10.36.116.27]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q76H45CD030225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 6 Aug 2012 13:04:08 -0400 Date: Mon, 06 Aug 2012 18:40:00 -0000 From: Jan Kratochvil To: Luis Gustavo Cc: gdb-patches@sourceware.org, prasad@linux.vnet.ibm.com, benh@kernel.crashing.org Subject: Re: [PATCH, ppc] Fix hw *points for embedded ppc in a threaded environment. Message-ID: <20120806170405.GA9225@host2.jankratochvil.net> References: <501FD5D6.30005@mentor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <501FD5D6.30005@mentor.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-08/txt/msg00188.txt.bz2 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