From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14724 invoked by alias); 3 Aug 2018 22:09:53 -0000 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 Received: (qmail 14702 invoked by uid 89); 3 Aug 2018 22:09:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=collection_list, treat_as_expr, pseudo-register, pseudoregister X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 03 Aug 2018 22:09:51 +0000 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w73M8m6b138615 for ; Fri, 3 Aug 2018 18:09:49 -0400 Received: from e13.ny.us.ibm.com (e13.ny.us.ibm.com [129.33.205.203]) by mx0b-001b2d01.pphosted.com with ESMTP id 2kmy75gpvr-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 03 Aug 2018 18:09:49 -0400 Received: from localhost by e13.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 3 Aug 2018 18:09:48 -0400 Received: from b01cxnp23032.gho.pok.ibm.com (9.57.198.27) by e13.ny.us.ibm.com (146.89.104.200) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Fri, 3 Aug 2018 18:09:45 -0400 Received: from b01ledav004.gho.pok.ibm.com (b01ledav004.gho.pok.ibm.com [9.57.199.109]) by b01cxnp23032.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w73M9iYq6423032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 3 Aug 2018 22:09:44 GMT Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CE6D3112061; Fri, 3 Aug 2018 18:09:26 -0400 (EDT) Received: from b01ledav004.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9C9C5112063; Fri, 3 Aug 2018 18:09:26 -0400 (EDT) Received: from pedro.localdomain (unknown [9.85.153.37]) by b01ledav004.gho.pok.ibm.com (Postfix) with ESMTP; Fri, 3 Aug 2018 18:09:26 -0400 (EDT) Received: by pedro.localdomain (Postfix, from userid 1000) id 11DDF3C03FA; Fri, 3 Aug 2018 19:09:41 -0300 (-03) From: Pedro Franco de Carvalho To: Ulrich Weigand Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v2 4/6] Use remote register numbers in tracepoint mask In-Reply-To: <20180802165834.4BA59D802AB@oc3748833570.ibm.com> References: <20180802165834.4BA59D802AB@oc3748833570.ibm.com> Date: Fri, 03 Aug 2018 22:09:00 -0000 MIME-Version: 1.0 Content-Type: text/plain x-cbid: 18080322-0064-0000-0000-00000334EF43 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00009479; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000266; SDB=6.01069608; UDB=6.00550096; IPR=6.00848264; MB=3.00022492; MTD=3.00000008; XFM=3.00000015; UTC=2018-08-03 22:09:46 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18080322-0065-0000-0000-00003A2CC6E6 Message-Id: <87a7q385lm.fsf@linux.vnet.ibm.com> X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00076.txt.bz2 Ulrich Weigand writes: > The alternative I guess would be to have collect_symbol fall back to > the "treat_as_expr" case for collecting pseudo registers; and then > possibly implementing as optimization a check whether the agent > expression is actually empty except for the register mask ... > Something similar would then also have to be done in encode_actions_1. > > Do you think this would be doable? I tried doing something like this but in add_local_register (this way even if add_memranges uses a pseudoregister for some reason, it should also work). See the next message for the updated patch. I just check if ax_regs_mask adds anything to the expression other than the mask, and add the expression to the collection_list. I'm not sure that this is the best approach, would it make sense to create a full expression, and generate an ax from that? This means that if a pseudo-register does something more complicated like reading memory, the ax it generates through gdbarch_ax_pseudo_register_collect should include the trace bytecodes for the memory it needs. I don't think this was the original intent, and it isn't clear that the rest of the ax code was made to work with that, but I tested this with a pseudoreg that reads the backchain from r1 (in powerpc), and it works. Alternatively, I can just raise an error in add_local_register if the length of the ax after ax_regs_mask is non-zero. I also refactored the lines that check if an ax is valid into a function, which is now also called from add_local_register too, since a full ax might be added. Previously only validate_actionline checked that the expression was not too long, now every place that generates an ax does this as well. Thanks for the review! -- Pedro Franco de Carvalho