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 222B1C3DA63 for ; Tue, 23 Jul 2024 13:11:19 +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=wmnZGs9h8UXmQiX7cdmDYs2SqUBB+oH005eXrbrPLEE=; b=LSttwGSd8AussG9+sTIO3lS7Rc VtMCzeg3SpJqDHrv7nxuEAH9ik+PQmC+DBBsvKTPWg8kJIz3axEkDTvZIX4ahxVoiufhbNBrPtFij CtNHf95n5GV1Cgq8vqPZr6Njk4hUeL87FCbAD6+Fz4q8AmJatcrsWT7ReeaRy7STpAuN07DjjZt+O aNemuBIiXdcCHdoklfLl5PcrZJaQYRDk+OHAT4K2BwC5umj8CnmHtHrxP/+8+6XDiVxZgCksojXrs 253xyjMxNsfk6sPx7OUtjOwYzaqmFnd+LWgJSdMqvT+JmZgKrahRltsAY2jld0oBORFJ68kHIFOKt TvyELOoQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sWFIH-0000000CTdC-3vCQ; Tue, 23 Jul 2024 13:11:05 +0000 Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sWFHt-0000000CTWz-4BiH for linux-arm-kernel@lists.infradead.org; Tue, 23 Jul 2024 13:10:43 +0000 Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-3683329f787so2941070f8f.1 for ; Tue, 23 Jul 2024 06:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1721740239; x=1722345039; darn=lists.infradead.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=wmnZGs9h8UXmQiX7cdmDYs2SqUBB+oH005eXrbrPLEE=; b=R4COn/vl5Pt2mgyEyyxNe3vDp4iazDsCY0iUZgzoj5sA9cEazJYHt4u0mtJmE0Xge1 J+rAEjcbABJEgGyrjvuBpcb4OZ11p13Z4bunXiEe/Fje9PQG4AMs3Y9q2nzugYV5T3uQ 5jNRgHA19iHNd6uVc2wGvCXEx0RftkKB9kxEf/6/oqcVo2sUUzhaTKQkwxxHjBNr6Vnu tPBRYmp7HgtTtskjTtBtk8tsoX+QMRTNdg1Cf5kSdUlifceVOZpNHif6HQfkVUgWZN3h 0bPHUGegQdyToypHWuxsG+cyck8SeH6bhtADcZMMkl5K4J6Mr0s8YH8GaezzQj0btKZ/ zytA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721740239; x=1722345039; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wmnZGs9h8UXmQiX7cdmDYs2SqUBB+oH005eXrbrPLEE=; b=IiqznOPoOiN863ZN8a/IOnUgkjOaCCSnsnCH4taMeGU/9CMQDXDgyxmqlKLd2zygfr thXZ3c2aCnqWuWRi52CBK55+04tW5TypJAGrTU37D+QfCtuITtXiN7+i+jKy1YjD+vHg KtSaVuOWivkG4NWaToXXQ1Tkxqd4IOIDj4xaAq49ycIBXq5hj052iWn6y1M9bJSDxrwJ KlGxoUbq1wTDgYziDzyYVSLVAu2nXmyKn+0Qb+yBZ4HNLRMZTMZkJ1AiUxZWYRMUF+sy GW/1Gk8k7uJ+HAu1awrPMCUXeO+AozwdlEVDDNhpzO2HwNW7r1t9x4j5BJZouXEdhhn5 Z2rA== X-Forwarded-Encrypted: i=1; AJvYcCVhBarnoZ2oFLZNSuPUVndzCLxUXbEl+CbtUDiQwX35MTiMh9B60Y69n9yx/d4DyKlCWSu6x396sZt0Q4AmasKCbSY1amQbCBWOGTN+KEn7RmW0bBw= X-Gm-Message-State: AOJu0YxZ6Rm41/yGfavngQ523MnkO2x6ymznY54RZyTqCiPA7kdzBPAX M67WHl365e42S3cxhtFWpdBNtqbPFv32JXgKuxT9fFwFjPjQMOTz5ENY4teD9BY= X-Google-Smtp-Source: AGHT+IFEIrDDYHUd5kqrtaL6dqmOmODWqrqO516kkukbC9SSnNU8uiwDiG1oOsLBBFsiEZUmS981QQ== X-Received: by 2002:a5d:5744:0:b0:368:5b78:c92e with SMTP id ffacd0b85a97d-369bae136c6mr5853601f8f.24.1721740239109; Tue, 23 Jul 2024 06:10:39 -0700 (PDT) Received: from [192.168.1.3] ([89.47.253.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-427d6936d62sm168482195e9.42.2024.07.23.06.10.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jul 2024 06:10:38 -0700 (PDT) Message-ID: <8f6f221b-4c9a-42e1-b8ce-1f492caee184@linaro.org> Date: Tue, 23 Jul 2024 14:10:37 +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: Ganapatrao Kulkarni , james.clark@arm.com, mike.leach@linaro.org, suzuki.poulose@arm.com, Leo Yan Cc: acme@redhat.com, coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, darren@os.amperecomputing.com, scclevenger@os.amperecomputing.com References: <20240719092619.274730-1-gankulkarni@os.amperecomputing.com> <7302367c-311f-4655-9a83-3c4034c50086@linaro.org> <6920de94-a9c8-47f4-840f-391d1ec85c0c@os.amperecomputing.com> Content-Language: en-US From: James Clark In-Reply-To: <6920de94-a9c8-47f4-840f-391d1ec85c0c@os.amperecomputing.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240723_061042_071742_A3B86A81 X-CRM114-Status: GOOD ( 30.55 ) 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 On 22/07/2024 11:02 am, Ganapatrao Kulkarni wrote: > > Hi James, > > On 19-07-2024 08:09 pm, James Clark wrote: >> >> >> On 19/07/2024 10:26 am, Ganapatrao Kulkarni wrote: >>> To generate the instruction tracing, script uses 2 contiguous packets >>> address range. If there a continuity brake due to discontiguous branch >>> address, it is required to reset the tracing and start tracing with the >>> new set of contiguous packets. >>> >>> Adding change to identify the break and complete the remaining tracing >>> of current packets and restart tracing from new set of packets, if >>> continuity is established. >>> >> >> Hi Ganapatrao, >> >> Can you add a before and after example of what's changed to the commit >> message? It wasn't immediately obvious to me if this is adding missing >> output, or it was correcting the tail end of the output that was >> previously wrong. > > It is adding tail end of the trace as well avoiding the segfault of the > perf application. With out this change the perf segfaults with as below log > > > ./perf script --script=python:./scripts/python/arm-cs-trace-disasm.py -- > -d objdump -k ../../vmlinux -v $* > dump > objdump: error: the stop address should be after the start address > Traceback (most recent call last): >   File "./scripts/python/arm-cs-trace-disasm.py", line 271, in > process_event >     print_disam(dso_fname, dso_vm_start, start_addr, stop_addr) >   File "./scripts/python/arm-cs-trace-disasm.py", line 105, in print_disam >     for line in read_disam(dso_fname, dso_start, start_addr, stop_addr): >                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >   File "./scripts/python/arm-cs-trace-disasm.py", line 99, in read_disam >     disasm_output = check_output(disasm).decode('utf-8').split('\n') >                     ^^^^^^^^^^^^^^^^^^^^ >   File "/usr/lib64/python3.12/subprocess.py", line 466, in check_output >     return run(*popenargs, stdout=PIPE, timeout=timeout, check=True, >            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >   File "/usr/lib64/python3.12/subprocess.py", line 571, in run >     raise CalledProcessError(retcode, process.args, > subprocess.CalledProcessError: Command '['objdump', '-d', '-z', > '--start-address=0xffff80008125b758', > '--stop-address=0xffff80008125a934', '../../vmlinux']' returned non-zero > exit status 1. > Fatal Python error: handler_call_die: problem in Python trace event handler > Python runtime state: initialized > > Current thread 0x0000ffffb05054e0 (most recent call first): >   > > Extension modules: perf_trace_context, systemd._journal, > systemd._reader, systemd.id128, report._py3report, _dbus_bindings, > problem._py3abrt (total: 7) > Aborted (core dumped) > >> >>> Signed-off-by: Ganapatrao Kulkarni >>> --- >>>   tools/perf/scripts/python/arm-cs-trace-disasm.py | 10 ++++++++++ >>>   1 file changed, 10 insertions(+) >>> >>> diff --git a/tools/perf/scripts/python/arm-cs-trace-disasm.py >>> b/tools/perf/scripts/python/arm-cs-trace-disasm.py >>> index d973c2baed1c..ad10cee2c35e 100755 >>> --- a/tools/perf/scripts/python/arm-cs-trace-disasm.py >>> +++ b/tools/perf/scripts/python/arm-cs-trace-disasm.py >>> @@ -198,6 +198,10 @@ def process_event(param_dict): >>>           cpu_data[str(cpu) + 'addr'] = addr >>>           return >>> +    if (cpu_data.get(str(cpu) + 'ip') == None): >>> +        cpu_data[str(cpu) + 'ip'] = ip >>> + >> >> Do you need to write into the global cpu_data here? Doesn't it get >> overwritten after you load it back into 'prev_ip' > > No, the logic is same as holding the addr of previous packet. > Saving the previous packet saved ip in to prev_ip before overwriting > with the current packet. It's not exactly the same logic as holding the addr of the previous sample. For addr, we return on the first None, with your change we now "pretend" that the second one is also the previous one: if (cpu_data.get(str(cpu) + 'addr') == None): cpu_data[str(cpu) + 'addr'] = addr return <----------------------------sample 0 return if (cpu_data.get(str(cpu) + 'ip') == None): cpu_data[str(cpu) + 'ip'] = ip <---- sample 1 save but no return Then for sample 1 'prev_ip' is actually now the 'current' IP: prev_ip = cpu_data[str(cpu) + 'ip'] This means that prev_ip is sometimes the previous sample's IP only sometimes (samples following 1), otherwise it's the current IP. Does your fix actually require this bit? Because we already save the 'real' previous one: cpu_data[str(cpu) + 'ip'] = stop_addr Also normally we save ip + 4 (stop_addr), where as you save ip. It's not clear why there is no need to add the 4? >> >>    prev_ip = cpu_data[str(cpu) + 'ip'] >> >>    ... then ... >> >>    # Record for previous sample packet >>    cpu_data[str(cpu) + 'addr'] = addr >>    cpu_data[str(cpu) + 'ip'] = stop_addr >> >> Would a local variable not accomplish the same thing? > > No, We need global to hold the ip of previous packet. >> >>> +    prev_ip = cpu_data[str(cpu) + 'ip'] >>>       if (options.verbose == True): >>>           print("Event type: %s" % name) >>> @@ -243,12 +247,18 @@ def process_event(param_dict): >>>       # Record for previous sample packet >>>       cpu_data[str(cpu) + 'addr'] = addr >>> +    cpu_data[str(cpu) + 'ip'] = stop_addr >>>       # Handle CS_ETM_TRACE_ON packet if start_addr=0 and stop_addr=4 >>>       if (start_addr == 0 and stop_addr == 4): >>>           print("CPU%d: CS_ETM_TRACE_ON packet is inserted" % cpu) >>>           return >>> +    if (stop_addr < start_addr): >>> +        # Continuity of the Packets broken, set start_addr to previous >>> +        # packet ip to complete the remaining tracing of the address >>> range. After looking a bit more I'm also not sure why stop_addr < start_addr signifies a discontinuity. What if the discontinuity ends up with stop_addr > start_addr? There's no reason it can't jump forwards as well as backwards. Can you share the 3 samples from the --verbose output to the script that cause the issue? I see discontinuities as having the branch source (ip) set to 0 which is what we do at the start: Sample = { cpu: 0000 addr: 0x0000ffffb807adac phys_addr: 0x0000000000000000 ip: 0x0000000000000000 pid: 28388 } Then the ending one has the branch target (addr) set to 0: Sample = { cpu: 0000 addr: 0x0000000000000000 phys_addr: 0x0000000000000000 ip: 0x0000ffffb7eee168 pid: 28388 } And it doesn't hit objdump because of the range check: Start address 0x0 is out of range ... So I don't see any missing disassembly or crashes for this. >>> +        start_addr = prev_ip >>> + >>>       if (start_addr < int(dso_start) or start_addr > int(dso_end)): >>>           print("Start address 0x%x is out of range [ 0x%x .. 0x%x ] >>> for dso %s" % (start_addr, int(dso_start), int(dso_end), dso)) >>>           return > > Thanks, > Ganapat