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 ADF97C3DA4A for ; Mon, 19 Aug 2024 11:01:12 +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-Type:Cc:To:Subject: Message-ID:Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=ZwUU6FCxyi4adWoMLxBbcUKpuY6U0CqKDUhDDluQfIY=; b=1gdE75gPbVooNsY0jSvFbjMuB8 6tPdVBGYCPSevOlah6NJq1ZzUhfR9zmxiClWd2kbxlyJoNlW4dGwdh78uFsZEH6okUuhTlIoAZ5dS zDnB4sbSueWCWE9UmUmPfFoQun2Quw0DNg3iXD7XFbmz7+NBE+GbM2wjThZ5ZVdAMX1rKIN3D8vcq cV0FOWV/vWv8wPWFE6HyAa7vC5DY7X0xxEg3CInpGYz3NhbS+6nGptwVrayEfziKb4MKXFH8Lg5kd 5Lsd8R8/RtjtKZjjtCRI3SvPFBQ2BAgArelqm5KuvDUAXc6mVL3KaCNZo3hXVuCmFnUvdOlT9786Q /bal9q7Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sg087-00000001A7t-0R5m; Mon, 19 Aug 2024 11:00:55 +0000 Received: from mail-oa1-x2c.google.com ([2001:4860:4864:20::2c]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sg07P-000000019xr-3dz5 for linux-arm-kernel@lists.infradead.org; Mon, 19 Aug 2024 11:00:13 +0000 Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-27045e54272so845054fac.0 for ; Mon, 19 Aug 2024 04:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1724065211; x=1724670011; darn=lists.infradead.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZwUU6FCxyi4adWoMLxBbcUKpuY6U0CqKDUhDDluQfIY=; b=TQZzCn+OZdPuy7f0WK1l1Vr301CRXSgNqYg52D6ccQ7h8Xx3OKExyQ5apLlVBv2cQ6 bfYS1JeeNbrKcUi5TU2XKFdjF6h+XOTotsyGET2pYkW87Ri9Vi527ZrVrhscYv2pPMEa /epWLYZMZf3ojv54hTk0fbP1dnpuCKDlEPLIZ4THzmV7aCnUD7KA5P68EWN20ZXLxUN3 e44EmaHKfgUsvaMKZkAEG2yTv/tMofNCQW+iNHY8MiOvbYH829TUBDefLwYgPZ9MZr3c FmuZ75YA5NT9KLpfnWVVDvkm6f9SLBexKpBpVF3aOhtYHLR03tK/JQiRqlYGE1Yp+7hZ fYpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724065211; x=1724670011; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZwUU6FCxyi4adWoMLxBbcUKpuY6U0CqKDUhDDluQfIY=; b=ZK9XzxHaHpHfez6TzJFsc2meNmV+0Yc3C4aYL9brOBMovNdBT8bGjBuw0cAJmZtIWG rhdOVvdAwKh66bF9BgytVhv9DbGkHFIjQOe6pF+Z0q0nh1SIlbeOnhYPTzQZCr0zN+qC yLGe7bsZwEbQUs5NTP0xEPRKyWihodoXrui1UIV8lPTzCNlXxSfLJC8sMpjqt0zCwmCH 0XOqzez1hZD49Je0YC+4N4sCPCQkTfJiluQD29b3IZ7EDcvPiAolWp4GHtx2YWNfjLst V/Nwr51p/U86e0lhsFxgX0mFIqhyk4ZA1kxtBxicyLnAyNEDBXSRAYR6hMJZf+ov8osN 4lBg== X-Forwarded-Encrypted: i=1; AJvYcCWWMu4I0czuyXCHeMDTvLY+6W8+zNr+CVewb25mj4P8HX5vemVb1qQfnqA98h+Bftil+b72m4tZmueuqTp7c9BqbZEtD4sNJNO5S0HXCpryKT59Gf4= X-Gm-Message-State: AOJu0Ywa9juS16D+fCMGnTXQ9VSR6s1cMovOF1aMzlur5MoJ6zkgOyfd Xn2IXlKKBm9yXT/8OU3y8/kjSnDrFCYVdzboQjVdsy9yrFQXYY9XdVht87LAWE1IFwY2RgOgh2Q z57hqXWHdWVprRYLhdIjKsXb6blDbCPpauNg1mQ== X-Google-Smtp-Source: AGHT+IF1NsUqh9of02Duq6hMyPc/Wal264TNklcZTJs73RIXyNkJbiYtx1Nxd5wIwUbxbO/l4vSg72JW5eyy1muERSw= X-Received: by 2002:a05:6870:8a06:b0:270:1dab:64a9 with SMTP id 586e51a60fabf-2701dab712bmr10656491fac.14.1724065210667; Mon, 19 Aug 2024 04:00:10 -0700 (PDT) MIME-Version: 1.0 References: <20240719092619.274730-1-gankulkarni@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> <4dd7f210-c03e-4203-b8e9-1c26a7f8fe79@arm.com> <27912fc6-8419-4828-82a7-dacde5b4a759@linaro.org> In-Reply-To: <27912fc6-8419-4828-82a7-dacde5b4a759@linaro.org> From: Mike Leach Date: Mon, 19 Aug 2024 11:59:58 +0100 Message-ID: Subject: Re: [PATCH] perf scripts python arm-cs-trace-disasm.py: Skip disasm if address continuity is broken To: James Clark Cc: Leo Yan , Ganapatrao Kulkarni , scclevenger@os.amperecomputing.com, 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 Content-Type: text/plain; charset="UTF-8" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240819_040011_982984_166AC5AE X-CRM114-Status: GOOD ( 44.39 ) 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, A new branch of OpenCSD is available - ocsd-consistency-checks-1.5.4-rc1 Testing I managed to do confirms the N atom on unconditional branches appear to work. I do not have a test case for the range discontinuities. The checks are enabled using operation flags on decoder creation. See the docs for details. Mike On Fri, 9 Aug 2024 at 16:20, James Clark wrote: > > > > On 09/08/2024 3:13 pm, Mike Leach wrote: > > Hi James > > > > On Thu, 8 Aug 2024 at 10:32, James Clark wrote: > >> > >> > >> > >> On 07/08/2024 5:48 pm, Leo Yan wrote: > >>> 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. > >> > >> No OpenCSD isn't passing the correct info here. Higher up in the thread > >> I suggested an OpenCSD patch that makes it detect the error earlier and > >> fixes the issue. It also needs to output a discontinuity when the > >> address goes backwards. So two fixes and then the script works without > >> modifications. > >> > > > > Which address is going backwards here? - OpenCSD generates trace > > ranges only by walking forwards from the last known address till it > > hits a branch. Unless this wraps round 0x000000 this will never result > > in a backwards address as far as I can see. > > Do you have an example dump with OpenCSD outputting a range packet > > with backwards addresses? > > > > Mike > > > The example I have I think is something like this: > > 1. Start address / trace on > 2. E > 3. Output range > ... > 4. Periodic address update > ... > 5. E > 6. Output range > > If decode has gone wrong (but undetectably) between steps 1 and 3. Then > the next steps still output a second range based on the last periodic > address received. (I think it might not necessarily have to be a > periodic address but could also be indirect address packet?). Perf > converts the ranges into branch samples by taking the end of the first > range and beginning of the second range. Then the disassembly script > converts those samples into ranges again by taking the source and > destination of the last two branch samples. > > The original issue that Ganapat saw was that the periodic address causes > OpenCSD to put the source address of the second range somewhere before > the first one, even though it didn't output a branch or discontinuity > that would explain how it got there. > > But yes you're right the ranges themselves always go forwards from the > point of view of their own start and end addresses. > > I thought it might be possible for OpenCSD to check against the last > range output? Although I wasn't sure if maybe it's actually valid to do > a backwards jump like that without the trace on/off packets with address > filtering or something? > > The root cause is still the incorrect image, but I think this check > along with the other direct branch check should make it pretty difficult > for people to make the mistake. -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK