Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp1797617pxm; Thu, 24 Feb 2022 09:28:18 -0800 (PST) X-Google-Smtp-Source: ABdhPJykiZIR9RzUidY0ccK6SCGmbS7wh//oG+lWPNG315wnRFUqMLiAHlCRJyeSxxccIXkkiGrl X-Received: by 2002:aa7:cac3:0:b0:412:fdeb:a5fa with SMTP id l3-20020aa7cac3000000b00412fdeba5famr3216782edt.257.1645723698025; Thu, 24 Feb 2022 09:28:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645723698; cv=none; d=google.com; s=arc-20160816; b=s0X6mh5glPh2EPqed1I3IhpMID9jKkDlmWXVc/J16UpQi3m6gx3tPe6MfsRLkY8aAp OqYcqkrj5ij0QvIVOZ3rNkY77JMlsIgcuWOtEQIpHF7is7+YK2+bit/6N9tV1svrJvGL dNpnUDTLwK0J9qP0NKVZDItdgYzhfqAYjoxGt0JSL4M13l9xm4uW+j6CzjJokzaND9Id YJfPKf1giGgKJkh6NLtVHjzuei7QHrqQ19T1SlQf55wNeATEK2lJsUsrPCOkrLYqWCGZ IbFULPX+6rEn9aZ+Rh23y9EiVPA4cj/XFQUOrLxqTwYgkYVp5DpkBTNfYn8FqPP5XN+p zs+w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=UYzEYr0RwdpYH2UiuC/jNmbojpmA49LfcjZhanYe2ZA=; b=HHOkrEB1+67AFPYxR/CeKVYibxmldLS2v9t7qLyBYtb/3yyHSD8EV6heRFODvouw2L zNtTtfD7fX5QO20/Z829RefIu7ASYJgS2r19ipG0WUBGaeaGMalpNxLBYXMYOjWWjdjx DrBkjnjNCzmUPUEU/nAfypc5SAgbkoHTWRyC38lBfuL+b0V+99ixR9xlCbzk7pr0l8hP 3QtMklGcSxOS1yVTIOqxBzUZzQSHM5ecyvJOzs0oaPgm/LPGORJlSnLi03WCfUDZbTAe qm3O1HMm+o79E1T8LGXVdaJ3HE0Cp2ab4IIDwh54ukCbUsUxkxwC+YdqaPSm6nMbhRIC yn5w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i38-20020a0564020f2600b004108264e75esi113139eda.548.2022.02.24.09.27.54; Thu, 24 Feb 2022 09:28:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230447AbiBXRUj (ORCPT + 99 others); Thu, 24 Feb 2022 12:20:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52378 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231210AbiBXRUg (ORCPT ); Thu, 24 Feb 2022 12:20:36 -0500 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 39DC429F41A; Thu, 24 Feb 2022 09:20:06 -0800 (PST) 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 D6711106F; Thu, 24 Feb 2022 09:20:05 -0800 (PST) Received: from e121896.arm.com (unknown [10.57.37.201]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 5B23E3F70D; Thu, 24 Feb 2022 09:20:04 -0800 (PST) From: James Clark To: acme@kernel.org, linux-perf-users@vger.kernel.org, coresight@lists.linaro.org Cc: James Clark , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , linux-kernel@vger.kernel.org Subject: [PATCH 0/1] perf: Set build-id using build-id header on new mmap records Date: Thu, 24 Feb 2022 17:19:54 +0000 Message-Id: <20220224171955.862983-1-james.clark@arm.com> X-Mailer: git-send-email 2.28.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, We are seeing an issue with doing Coresight decode off target where initially the correct dso from ~/.debug is used, but after a new thread in the perf.data file is passed with its mmap record, the local version of the dso is picked up instead. This happens if the binary exists in the same path on both devices, for example /bin/ls. Initially when parsing the build-ids in the header, the dso for /bin/ls will be created, and the file will correctly point to ~/.debug/bin/ls/2f15ad836be3339dec0e2e6a3c637e08e48aacbd/elf, but for any new threads or mmaps that are also for /bin/ls, they will not have a build-id set so they point to /bin/ls on the local machine rather than the debug folder. To fix this I made it possible to look up which existing dsos have build id's set that originate from the header and then copy that build-id onto the new dso if the name matches. Another way to do it would be to stop comparing the mmap id so it matches on filename only, but I think we do want to differentiate between different mmaps, even if they have the same name, which is how it works in this version. Applies to perf/core 859f7e4554 Thanks James James Clark (1): perf: Set build-id using build-id header on new mmap records tools/perf/util/dso.h | 1 + tools/perf/util/header.c | 1 + tools/perf/util/map.c | 16 ++++++++++++++-- 3 files changed, 16 insertions(+), 2 deletions(-) -- 2.28.0