From: Ian Rogers <irogers@google.com>
To: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Kan Liang <kan.liang@linux.intel.com>,
Kajol Jain <kjain@linux.ibm.com>,
Athira Rajeev <atrajeev@linux.vnet.ibm.com>,
"Steinar H. Gunderson" <sesse@google.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Alexander Lobakin <aleksander.lobakin@intel.com>,
Hemant Kumar <hemant@linux.vnet.ibm.com>,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
Yang Jihong <yangjihong@bytedance.com>,
leo.yan@arm.com
Subject: [PATCH v1 0/3] 2 memory fixes and a build fix
Date: Mon, 23 Sep 2024 17:37:17 -0700 [thread overview]
Message-ID: <20240924003720.617258-1-irogers@google.com> (raw)
I was looking into some lsan regressions and a latent issue with
libdw, creating these fixes.
A thought, we should probably simplify the libdw logic but rather than
do it here I'll do it as a separate series on top of these. The issues
I see are:
1) dwfl_thread_getframes is used to test for the presence of
libdw-dwarf-unwind. The blame date on this function is
2013-05-30. As the function is 10 years old I think having libdw
implies having dwfl_thread_getframes and so we can just merge the
two pieces of logic instead of having different feature tests and
ifdefs.
2) similarly, dwarf_getlocations has a blame date of 2013-08-23 so
let's just make libdw tests test for this and make having libdw
imply dwarf_getlocations support.
3) similarly, dwarf_getcfi has a blame date of 2009-06-24 so let's
just make libdw tests test for this and make having libdw imply
dwarf_getcfi support.
4) in Makefie.config feature-dwarf is a synonym for libdw support. I
think using the name libdw is more intention revealing as dwarf can
mean multiple things. Let's change HAVE_DWARF_SUPPORT to
HAVE_LIBDW_SUPPORT and all similar dwarf vs libdw names.
5) We have "#if _ELFUTILS_PREREQ(0, 142)" testing for elfutils version
0.142. Elfutils 0.142 was released around 2009-06-13 (via git blame
on the NEWS file). Let's remove the #if and ensure elfutils feature
tests for at least 0.142. If someone were using an incredibly old
version then they'd lose some elfutils support, but given the 15
year old age of the library I find it unlikely anyone is doing
this. They can also just move to a newer version.
From the mailing list I notice also overlap with the last patch and
this series:
https://lore.kernel.org/lkml/20240919013513.118527-1-yangjihong@bytedance.com/
Simplifying the libdw support will address some of those issues too.
Ian Rogers (3):
perf disasm: Fix capstone memory leak
perf probe: Fix libdw memory leak
perf build: Fix !HAVE_DWARF_GETLOCATIONS_SUPPORT
tools/perf/Makefile.config | 6 ++++++
tools/perf/util/disasm.c | 11 +++++++----
tools/perf/util/dwarf-aux.h | 1 +
tools/perf/util/probe-finder.c | 5 +++++
4 files changed, 19 insertions(+), 4 deletions(-)
--
2.46.0.792.g87dc391469-goog
next reply other threads:[~2024-09-24 0:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-24 0:37 Ian Rogers [this message]
2024-09-24 0:37 ` [PATCH v1 1/3] perf disasm: Fix capstone memory leak Ian Rogers
2024-09-24 18:38 ` Namhyung Kim
2024-09-24 19:51 ` Ian Rogers
2024-09-25 5:57 ` Namhyung Kim
2024-09-24 0:37 ` [PATCH v1 2/3] perf probe: Fix libdw " Ian Rogers
2024-09-24 9:17 ` James Clark
2024-09-24 18:39 ` Namhyung Kim
2024-09-24 19:47 ` Ian Rogers
2024-09-25 6:00 ` Namhyung Kim
2024-10-02 17:43 ` Namhyung Kim
2024-10-02 19:08 ` Ian Rogers
2024-10-02 21:53 ` Namhyung Kim
2024-09-24 0:37 ` [PATCH v1 3/3] perf build: Fix !HAVE_DWARF_GETLOCATIONS_SUPPORT Ian Rogers
2024-09-24 9:18 ` [PATCH v1 0/3] 2 memory fixes and a build fix James Clark
2024-09-24 18:25 ` Namhyung Kim
2024-10-01 5:11 ` Ian Rogers
2024-10-01 23:58 ` Namhyung Kim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240924003720.617258-1-irogers@google.com \
--to=irogers@google.com \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=aleksander.lobakin@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=davem@davemloft.net \
--cc=hemant@linux.vnet.ibm.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=kjain@linux.ibm.com \
--cc=leo.yan@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=przemyslaw.kitszel@intel.com \
--cc=sesse@google.com \
--cc=yangjihong@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®