From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 03B17C3DA7F for ; Wed, 7 Aug 2024 16:50:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=aRxImNaoL4Q+lEdeVuQorQOxfMr/0bsf56RmAqqotfc=; b=bRDlH6UJKEzCRa0rvCFb/qSlDc 4bKEdyTTnujf/pT+lnjP1e8fPeXnKKObTgSo/kJz8KoakyK9Pf52MAouXEqVYFN/5j7mYrMtBgOb0 wLA7nwtuj92IyHqDvihx/5l3xbrFo2vA4HgSEDSeU4aCBw+s50kbFdBes5Wr7Qua2RGvrWt4xILxf bDXhNYjnSR1UQqmc10E0zwhWPl+hQwI99KA2p60NJYAdZdqLvKVTA6A6EJoS+3vfRnjIU+IfbKenA P9N+HF7ToghVYeWecVq32Ljx98eBtQX3MJnVyWKngcdsjp7FvNJJoEutjhn73S8aAzzoDU6G92jco oU5je/GA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sbjrh-00000005k6Z-2Dew; Wed, 07 Aug 2024 16:50:21 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sbjqC-00000005jht-2PBj for linux-arm-kernel@lists.infradead.org; Wed, 07 Aug 2024 16:48:50 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EAC63FEC; Wed, 7 Aug 2024 09:49:12 -0700 (PDT) Received: from [10.1.27.29] (PF4Q20KV.arm.com [10.1.27.29]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 50AF03F766; Wed, 7 Aug 2024 09:48:45 -0700 (PDT) Message-ID: <4dd7f210-c03e-4203-b8e9-1c26a7f8fe79@arm.com> Date: Wed, 7 Aug 2024 17:48:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] perf scripts python arm-cs-trace-disasm.py: Skip disasm if address continuity is broken To: James Clark , Ganapatrao Kulkarni , scclevenger@os.amperecomputing.com Cc: acme@redhat.com, coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, darren@os.amperecomputing.com, james.clark@arm.com, suzuki.poulose@arm.com, Al.Grant@arm.com, Mike Leach References: <20240719092619.274730-1-gankulkarni@os.amperecomputing.com> <6920de94-a9c8-47f4-840f-391d1ec85c0c@os.amperecomputing.com> <8f6f221b-4c9a-42e1-b8ce-1f492caee184@linaro.org> <0a697a54-5dd8-4351-a651-991724690db2@os.amperecomputing.com> <543813f6-cb1f-4759-b26f-75246750814d@linaro.org> <00fac24c-d664-4ebb-8c60-f4697b7f76c1@linaro.org> <8b53a424-19f7-4042-a2db-e1c5d051f9cc@os.amperecomputing.com> <6adf84fa-b755-4d7a-957a-9bf01e442238@linaro.org> <6f535bb6-2cee-48e6-93f1-ea19887bae74@os.amperecomputing.com> <027c76a9-9bd4-43e9-a170-8391a0037291@linaro.org> <3d7a6f93-0555-48fa-99cb-bf26b53c2da5@os.amperecomputing.com> Content-Language: en-US From: Leo Yan In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240807_094848_722366_5B2CAD61 X-CRM114-Status: GOOD ( 18.45 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi all, On 8/7/2024 3:53 PM, James Clark wrote: A minor suggestion: if the discussion is too long, please delete the irrelevant message ;) [...] >> --- a/tools/perf/scripts/python/arm-cs-trace-disasm.py >> +++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py >> @@ -257,6 +257,11 @@ def process_event(param_dict): >>                  print("Stop address 0x%x is out of range [ 0x%x .. 0x%x >> ] for dso %s" % (stop_addr, int(dso_start), int(dso_end), dso)) >>                  return >> >> +       if (stop_addr < start_addr): >> +               if (options.verbose == True): >> +                       print("Packet Dropped, Discontinuity detected >> [stop_add:0x%x start_addr:0x%x ] for dso %s" % (stop_addr, start_addr, >> dso)) >> +               return >> + > > I suppose my only concern with this is that it hides real errors and > Perf shouldn't be outputting samples that go backwards. Considering that > fixing this in OpenCSD and Perf has a much wider benefit I think that > should be the ultimate goal. I'm putting this on my todo list for now > (including Steve's merging idea). In the perf's util/cs-etm.c file, it handles DISCONTINUITY with: case CS_ETM_DISCONTINUITY: /* * The trace is discontinuous, if the previous packet is * instruction packet, set flag PERF_IP_FLAG_TRACE_END * for previous packet. */ if (prev_packet->sample_type == CS_ETM_RANGE) prev_packet->flags |= PERF_IP_FLAG_BRANCH | PERF_IP_FLAG_TRACE_END; I am wandering if OpenCSD has passed the correct info so Perf decoder can detect the discontinuity. If yes, then the flag 'PERF_IP_FLAG_TRACE_END' will be set (it is a general flag in branch sample), then we can consider use it in the python script to handle discontinuous data. > > But in the mean time what about having a force option? > >> +       if (stop_addr < start_addr): >> +               if (options.verbose == True or not options.force): >> +                       print("Packet Dropped, Discontinuity detected >> [stop_add:0x%x start_addr:0x%x ] for dso %s" % (stop_addr, start_addr, >> dso)) >> +               if (not options.force): >> +                       return If the stop address is less than the start address, it must be something wrong. In this case, we can report a warning for discontinuity and directly return (also need to save the `addr` into global variable for next parsing). I prefer to not add force option for this case - eventually, this will consume much time for reporting this kind of failure and need to root causing it. A better way is we just print out the reasoning in the log and continue to dump. Thanks, Leo