From: Namhyung Kim <namhyung@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Jiri Olsa <jolsa@kernel.org>,
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: Re: [PATCH v1 0/3] 2 memory fixes and a build fix
Date: Tue, 24 Sep 2024 11:25:30 -0700 [thread overview]
Message-ID: <ZvMEGn5RIWMZNvFc@google.com> (raw)
In-Reply-To: <20240924003720.617258-1-irogers@google.com>
On Mon, Sep 23, 2024 at 05:37:17PM -0700, Ian Rogers wrote:
> 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.
Looking at the map file in libdw, the latest addition was 0.158 for
dwfl_thread_getframes(). Probably we can add the version check to the
feature test to make sure if it has all the required APIs.
https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdw/libdw.map;h=552588a94c0c1a1f2fd5b973553c784026e6de14;hb=HEAD#l274
>
> 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.
Yeah I noticed that too and feel like it should go to perf-tools tree.
Probably it doesn't clash with this so I think it's ok to have this in
perf-tools-next.
Thanks,
Namhyung
>
> 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 prev parent reply other threads:[~2024-09-24 18:25 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-24 0:37 [PATCH v1 0/3] 2 memory fixes and a build fix Ian Rogers
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 [this message]
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=ZvMEGn5RIWMZNvFc@google.com \
--to=namhyung@kernel.org \
--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=irogers@google.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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.