From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2LH4CNJpql+tBwAAWB0awg (envelope-from ) for ; Tue, 10 Nov 2020 05:22:10 -0500 Received: by simark.ca (Postfix, from userid 112) id 181B31F08B; Tue, 10 Nov 2020 05:22:10 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 0FE891E58F for ; Tue, 10 Nov 2020 05:22:08 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 396FA3857815; Tue, 10 Nov 2020 10:22:07 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 396FA3857815 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1605003727; bh=tHWa0XDnusWdAhjiji90FOwTp1eREQ9NYcobee+sKy4=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=QQfthkNLPHR07VktMCJr+/wepnWxVCJMLvrBdyCWUrs0bHsbVg9NMTldifdIqhxAq B4upquPvqqCOPIv0aQQtDkpqphjBYvbKwVAhXGvDvhnMEDm3QDwgFSovFYdx6GKW3g 0XHbPVQMDb5aciuIcAMHQWoZphopS38pvjrlzTfw= Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 495303857815 for ; Tue, 10 Nov 2020 10:22:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 495303857815 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0AAA2Vk3026616 for ; Tue, 10 Nov 2020 05:22:05 -0500 Received: from ppma03ams.nl.ibm.com (62.31.33a9.ip4.static.sl-reverse.com [169.51.49.98]) by mx0b-001b2d01.pphosted.com with ESMTP id 34qgycmnbr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 10 Nov 2020 05:22:04 -0500 Received: from pps.filterd (ppma03ams.nl.ibm.com [127.0.0.1]) by ppma03ams.nl.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 0AAAGG4n032038 for ; Tue, 10 Nov 2020 10:22:02 GMT Received: from b06avi18626390.portsmouth.uk.ibm.com (b06avi18626390.portsmouth.uk.ibm.com [9.149.26.192]) by ppma03ams.nl.ibm.com with ESMTP id 34nk78k0uc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 10 Nov 2020 10:22:02 +0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 0AAALxIN59441486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 10 Nov 2020 10:21:59 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B7126AE045; Tue, 10 Nov 2020 10:21:59 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A4562AE051; Tue, 10 Nov 2020 10:21:59 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.145.51.32]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 10 Nov 2020 10:21:59 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id 16E40D803D6; Tue, 10 Nov 2020 11:21:59 +0100 (CET) Date: Tue, 10 Nov 2020 11:21:59 +0100 To: Rogerio Alves Subject: Re: [PATCH v1] [powerpc] Remove 512 bytes region limit if using 2nd DAWR. Message-ID: <20201110102159.GA23382@oc3748833570.ibm.com> References: <20201109021204.48664-1-rcardoso@linux.ibm.com> <20201109102434.GA12858@oc3748833570.ibm.com> <916089d8-f003-6e23-2180-8d96d7b3ce6b@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <916089d8-f003-6e23-2180-8d96d7b3ce6b@linux.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-10_04:2020-11-05, 2020-11-10 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 clxscore=1015 malwarescore=0 impostorscore=0 bulkscore=0 lowpriorityscore=0 spamscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011100068 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Ulrich Weigand via Gdb-patches Reply-To: Ulrich Weigand Cc: pedromfc@linux.ibm.com, gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On Mon, Nov 09, 2020 at 10:08:09AM -0300, Rogerio Alves wrote: > On 11/9/20 7:24 AM, Ulrich Weigand wrote: > > On Sun, Nov 08, 2020 at 11:12:04PM -0300, Rogerio Alves wrote: > >> Power 10 introduces the 2nd DAWR (second watchpoint) and also removed > >> a restriction that limit the watch region to 512 bytes. > >> > >> 2020-11-08 Rogerio A. Cardoso > >> > >> gdb/ > >> > >> * ppc-linux-nat.c: (PPC_DEBUG_FEATURE_DATA_BP_ARCH_31): New define. > >> (region_ok_for_hw_watchpoint): Check if 2nd DAWR is avaliable before set > >> region. > > > > This doesn't look correct, the patch not only removes the alignment > > requirement but actually removes support for 512 bytes ranges itself! > > > > The patch doesn't remove the support. If we are using the second > watchpoint (PPC_DEBUG_FEATURE_DATA_BP_ARCH_31) we don't limit the > region_size to 512 (region_size = 512) instead we use > hwdebug_info.data_bp_alignment right? Isn't region_size that create a > 512-byte bondary? hwdebug_info.data_bp_alignment is the required *alignment*, which remains 8 for Power10. I think the problem is that until now, the maximum size was always equal to the required alignment (on Power8: alignment 8, size 8; on Power9: alignment 512, size 512), but on Power10 they are now different: alignment 8, size 512. > > I think for P10 we need to continue to allow watched ranges up to > > 512 bytes in size, but they only need to be 8 byte aligned now and > > may cross a 512-byte boundary. > > > > Since the else case is region_size = hwdebug_info.data_bp_alignment; > I guess this is what it do unless I am missing something here. We'll probably have to use two different variables for size and alignment now, update the test accordingly, and set the values as above. Given the size and alignment value, and given a range start address, the maximum allowable end can be found by rounding the start address *down* to the required alignment, and then adding the maximum size. For example, if we have a start address of 0x1234, then the maximum end address on P9 is 0x1400, but on P10 it would be 0x1430. (With your patch as-is, it would reset to the P8 values, where the maximum end address is only 0x1238.) Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com