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>,
"John Garry" <john.g.garry@oracle.com>,
"Will Deacon" <will@kernel.org>,
"James Clark" <james.clark@linaro.org>,
"Mike Leach" <mike.leach@linaro.org>,
"Leo Yan" <leo.yan@linux.dev>, guoren <guoren@kernel.org>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Charlie Jenkins" <charlie@rivosinc.com>,
"Bibo Mao" <maobibo@loongson.cn>,
"Huacai Chen" <chenhuacai@kernel.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Jiri Slaby" <jirislaby@kernel.org>,
"Björn Töpel" <bjorn@rivosinc.com>,
"Howard Chu" <howardchu95@gmail.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
linux-riscv@lists.infradead.org, "Arnd Bergmann" <arnd@arndb.de>
Subject: Re: [PATCH v4 06/11] perf dso: Add support for reading the e_machine type for a dso
Date: Thu, 6 Mar 2025 17:22:20 -0800 [thread overview]
Message-ID: <Z8pKTE7tOqdqNUdA@google.com> (raw)
In-Reply-To: <20250304050305.901167-7-irogers@google.com>
On Mon, Mar 03, 2025 at 09:03:00PM -0800, Ian Rogers wrote:
> For ELF file dsos read the e_machine from the ELF header. For kernel
> types assume the e_machine matches the perf tool. In other cases
> return EM_NONE.
>
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> tools/perf/util/dso.c | 54 +++++++++++++++++++++++++++++++++++++++++++
> tools/perf/util/dso.h | 1 +
> 2 files changed, 55 insertions(+)
>
> diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
> index 5c6e85fdae0d..7f2f1af4f73b 100644
> --- a/tools/perf/util/dso.c
> +++ b/tools/perf/util/dso.c
> @@ -1170,6 +1170,60 @@ ssize_t dso__data_read_offset(struct dso *dso, struct machine *machine,
> return data_read_write_offset(dso, machine, offset, data, size, true);
> }
>
> +uint16_t dso__e_machine(struct dso *dso, struct machine *machine)
> +{
> + uint16_t e_machine = EM_NONE;
> + int fd;
> +
> + switch (dso__binary_type(dso)) {
> + case DSO_BINARY_TYPE__KALLSYMS:
> + case DSO_BINARY_TYPE__GUEST_KALLSYMS:
> + case DSO_BINARY_TYPE__VMLINUX:
> + case DSO_BINARY_TYPE__GUEST_VMLINUX:
> + case DSO_BINARY_TYPE__GUEST_KMODULE:
> + case DSO_BINARY_TYPE__GUEST_KMODULE_COMP:
> + case DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE:
> + case DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE_COMP:
> + case DSO_BINARY_TYPE__KCORE:
> + case DSO_BINARY_TYPE__GUEST_KCORE:
> + case DSO_BINARY_TYPE__BPF_PROG_INFO:
> + case DSO_BINARY_TYPE__BPF_IMAGE:
> + case DSO_BINARY_TYPE__OOL:
> + case DSO_BINARY_TYPE__JAVA_JIT:
I think some of them can be possible in recorded data. But let's go
simple with EM_HOST as we haven't supported cross-arch trace.
> + return EM_HOST;
> + case DSO_BINARY_TYPE__DEBUGLINK:
> + case DSO_BINARY_TYPE__BUILD_ID_CACHE:
> + case DSO_BINARY_TYPE__BUILD_ID_CACHE_DEBUGINFO:
> + case DSO_BINARY_TYPE__SYSTEM_PATH_DSO:
> + case DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO:
> + case DSO_BINARY_TYPE__FEDORA_DEBUGINFO:
> + case DSO_BINARY_TYPE__UBUNTU_DEBUGINFO:
> + case DSO_BINARY_TYPE__MIXEDUP_UBUNTU_DEBUGINFO:
> + case DSO_BINARY_TYPE__BUILDID_DEBUGINFO:
> + break;
> + case DSO_BINARY_TYPE__NOT_FOUND:
> + default:
> + return EM_NONE;
> + }
> +
> + pthread_mutex_lock(&dso__data_open_lock);
Hmm.. I'm afraid it'd slow down perf trace a bit more. It sees
occasional LOST events. But it may be ok as it's cached in thread later.
> +
> + /*
> + * dso__data(dso)->fd might be closed if other thread opened another
> + * file (dso) due to open file limit (RLIMIT_NOFILE).
> + */
> + try_to_open_dso(dso, machine);
> + fd = dso__data(dso)->fd;
> + if (fd >= 0) {
> + _Static_assert(offsetof(Elf32_Ehdr, e_machine) == 18, "Unexpected offset");
> + _Static_assert(offsetof(Elf64_Ehdr, e_machine) == 18, "Unexpected offset");
> + if (pread(fd, &e_machine, sizeof(e_machine), 18) != sizeof(e_machine))
I think it needs to check the endianess and swap the data.
Thanks,
Namhyung
> + e_machine = EM_NONE;
> + }
> + pthread_mutex_unlock(&dso__data_open_lock);
> + return e_machine;
> +}
> +
> /**
> * dso__data_read_addr - Read data from dso address
> * @dso: dso object
> diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
> index f3ca2a5e7670..ba9b83db061a 100644
> --- a/tools/perf/util/dso.h
> +++ b/tools/perf/util/dso.h
> @@ -818,6 +818,7 @@ int dso__data_file_size(struct dso *dso, struct machine *machine);
> off_t dso__data_size(struct dso *dso, struct machine *machine);
> ssize_t dso__data_read_offset(struct dso *dso, struct machine *machine,
> u64 offset, u8 *data, ssize_t size);
> +uint16_t dso__e_machine(struct dso *dso, struct machine *machine);
> ssize_t dso__data_read_addr(struct dso *dso, struct map *map,
> struct machine *machine, u64 addr,
> u8 *data, ssize_t size);
> --
> 2.48.1.711.g2feabab25a-goog
>
WARNING: multiple messages have this Message-ID (diff)
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>,
"John Garry" <john.g.garry@oracle.com>,
"Will Deacon" <will@kernel.org>,
"James Clark" <james.clark@linaro.org>,
"Mike Leach" <mike.leach@linaro.org>,
"Leo Yan" <leo.yan@linux.dev>, guoren <guoren@kernel.org>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Albert Ou" <aou@eecs.berkeley.edu>,
"Charlie Jenkins" <charlie@rivosinc.com>,
"Bibo Mao" <maobibo@loongson.cn>,
"Huacai Chen" <chenhuacai@kernel.org>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Jiri Slaby" <jirislaby@kernel.org>,
"Björn Töpel" <bjorn@rivosinc.com>,
"Howard Chu" <howardchu95@gmail.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
"linux-csky@vger.kernel.org" <linux-csky@vger.kernel.org>,
linux-riscv@lists.infradead.org, "Arnd Bergmann" <arnd@arndb.de>
Subject: Re: [PATCH v4 06/11] perf dso: Add support for reading the e_machine type for a dso
Date: Thu, 6 Mar 2025 17:22:20 -0800 [thread overview]
Message-ID: <Z8pKTE7tOqdqNUdA@google.com> (raw)
In-Reply-To: <20250304050305.901167-7-irogers@google.com>
On Mon, Mar 03, 2025 at 09:03:00PM -0800, Ian Rogers wrote:
> For ELF file dsos read the e_machine from the ELF header. For kernel
> types assume the e_machine matches the perf tool. In other cases
> return EM_NONE.
>
> Signed-off-by: Ian Rogers <irogers@google.com>
> ---
> tools/perf/util/dso.c | 54 +++++++++++++++++++++++++++++++++++++++++++
> tools/perf/util/dso.h | 1 +
> 2 files changed, 55 insertions(+)
>
> diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
> index 5c6e85fdae0d..7f2f1af4f73b 100644
> --- a/tools/perf/util/dso.c
> +++ b/tools/perf/util/dso.c
> @@ -1170,6 +1170,60 @@ ssize_t dso__data_read_offset(struct dso *dso, struct machine *machine,
> return data_read_write_offset(dso, machine, offset, data, size, true);
> }
>
> +uint16_t dso__e_machine(struct dso *dso, struct machine *machine)
> +{
> + uint16_t e_machine = EM_NONE;
> + int fd;
> +
> + switch (dso__binary_type(dso)) {
> + case DSO_BINARY_TYPE__KALLSYMS:
> + case DSO_BINARY_TYPE__GUEST_KALLSYMS:
> + case DSO_BINARY_TYPE__VMLINUX:
> + case DSO_BINARY_TYPE__GUEST_VMLINUX:
> + case DSO_BINARY_TYPE__GUEST_KMODULE:
> + case DSO_BINARY_TYPE__GUEST_KMODULE_COMP:
> + case DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE:
> + case DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE_COMP:
> + case DSO_BINARY_TYPE__KCORE:
> + case DSO_BINARY_TYPE__GUEST_KCORE:
> + case DSO_BINARY_TYPE__BPF_PROG_INFO:
> + case DSO_BINARY_TYPE__BPF_IMAGE:
> + case DSO_BINARY_TYPE__OOL:
> + case DSO_BINARY_TYPE__JAVA_JIT:
I think some of them can be possible in recorded data. But let's go
simple with EM_HOST as we haven't supported cross-arch trace.
> + return EM_HOST;
> + case DSO_BINARY_TYPE__DEBUGLINK:
> + case DSO_BINARY_TYPE__BUILD_ID_CACHE:
> + case DSO_BINARY_TYPE__BUILD_ID_CACHE_DEBUGINFO:
> + case DSO_BINARY_TYPE__SYSTEM_PATH_DSO:
> + case DSO_BINARY_TYPE__OPENEMBEDDED_DEBUGINFO:
> + case DSO_BINARY_TYPE__FEDORA_DEBUGINFO:
> + case DSO_BINARY_TYPE__UBUNTU_DEBUGINFO:
> + case DSO_BINARY_TYPE__MIXEDUP_UBUNTU_DEBUGINFO:
> + case DSO_BINARY_TYPE__BUILDID_DEBUGINFO:
> + break;
> + case DSO_BINARY_TYPE__NOT_FOUND:
> + default:
> + return EM_NONE;
> + }
> +
> + pthread_mutex_lock(&dso__data_open_lock);
Hmm.. I'm afraid it'd slow down perf trace a bit more. It sees
occasional LOST events. But it may be ok as it's cached in thread later.
> +
> + /*
> + * dso__data(dso)->fd might be closed if other thread opened another
> + * file (dso) due to open file limit (RLIMIT_NOFILE).
> + */
> + try_to_open_dso(dso, machine);
> + fd = dso__data(dso)->fd;
> + if (fd >= 0) {
> + _Static_assert(offsetof(Elf32_Ehdr, e_machine) == 18, "Unexpected offset");
> + _Static_assert(offsetof(Elf64_Ehdr, e_machine) == 18, "Unexpected offset");
> + if (pread(fd, &e_machine, sizeof(e_machine), 18) != sizeof(e_machine))
I think it needs to check the endianess and swap the data.
Thanks,
Namhyung
> + e_machine = EM_NONE;
> + }
> + pthread_mutex_unlock(&dso__data_open_lock);
> + return e_machine;
> +}
> +
> /**
> * dso__data_read_addr - Read data from dso address
> * @dso: dso object
> diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
> index f3ca2a5e7670..ba9b83db061a 100644
> --- a/tools/perf/util/dso.h
> +++ b/tools/perf/util/dso.h
> @@ -818,6 +818,7 @@ int dso__data_file_size(struct dso *dso, struct machine *machine);
> off_t dso__data_size(struct dso *dso, struct machine *machine);
> ssize_t dso__data_read_offset(struct dso *dso, struct machine *machine,
> u64 offset, u8 *data, ssize_t size);
> +uint16_t dso__e_machine(struct dso *dso, struct machine *machine);
> ssize_t dso__data_read_addr(struct dso *dso, struct map *map,
> struct machine *machine, u64 addr,
> u8 *data, ssize_t size);
> --
> 2.48.1.711.g2feabab25a-goog
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2025-03-07 1:50 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-04 5:02 [PATCH v4 00/11] perf: Support multiple system call tables in the build Ian Rogers
2025-03-04 5:02 ` Ian Rogers
2025-03-04 5:02 ` [PATCH v4 01/11] perf dso: Move libunwind dso_data variables into ifdef Ian Rogers
2025-03-04 5:02 ` Ian Rogers
2025-03-05 17:52 ` Arnaldo Carvalho de Melo
2025-03-05 17:52 ` Arnaldo Carvalho de Melo
2025-03-04 5:02 ` [PATCH v4 02/11] perf dso: kernel-doc for enum dso_binary_type Ian Rogers
2025-03-04 5:02 ` Ian Rogers
2025-03-05 17:54 ` Arnaldo Carvalho de Melo
2025-03-05 17:54 ` Arnaldo Carvalho de Melo
2025-03-07 1:14 ` Namhyung Kim
2025-03-07 1:14 ` Namhyung Kim
2025-03-04 5:02 ` [PATCH v4 03/11] perf syscalltbl: Remove syscall_table.h Ian Rogers
2025-03-04 5:02 ` Ian Rogers
2025-03-04 5:02 ` [PATCH v4 04/11] perf trace: Reorganize syscalls Ian Rogers
2025-03-04 5:02 ` Ian Rogers
2025-03-04 5:02 ` [PATCH v4 05/11] perf syscalltbl: Remove struct syscalltbl Ian Rogers
2025-03-04 5:02 ` Ian Rogers
2025-03-04 5:03 ` [PATCH v4 06/11] perf dso: Add support for reading the e_machine type for a dso Ian Rogers
2025-03-04 5:03 ` Ian Rogers
2025-03-07 1:22 ` Namhyung Kim [this message]
2025-03-07 1:22 ` Namhyung Kim
2025-03-07 5:30 ` Ian Rogers
2025-03-07 5:30 ` Ian Rogers
2025-03-04 5:03 ` [PATCH v4 07/11] perf thread: Add support for reading the e_machine type for a thread Ian Rogers
2025-03-04 5:03 ` Ian Rogers
2025-03-04 5:03 ` [PATCH v4 08/11] perf trace beauty: Add syscalltbl.sh generating all system call tables Ian Rogers
2025-03-04 5:03 ` Ian Rogers
2025-03-04 5:03 ` [PATCH v4 09/11] perf syscalltbl: Use lookup table containing multiple architectures Ian Rogers
2025-03-04 5:03 ` Ian Rogers
2025-03-04 5:03 ` [PATCH v4 10/11] perf build: Remove Makefile.syscalls Ian Rogers
2025-03-04 5:03 ` Ian Rogers
2025-03-04 5:03 ` [PATCH v4 11/11] perf syscalltbl: Mask off ABI type for MIPS system calls Ian Rogers
2025-03-04 5:03 ` Ian Rogers
2025-03-04 7:04 ` [PATCH v4 00/11] perf: Support multiple system call tables in the build Ian Rogers
2025-03-04 7:04 ` Ian Rogers
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=Z8pKTE7tOqdqNUdA@google.com \
--to=namhyung@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=aou@eecs.berkeley.edu \
--cc=arnd@arndb.de \
--cc=bjorn@rivosinc.com \
--cc=catalin.marinas@arm.com \
--cc=charlie@rivosinc.com \
--cc=chenhuacai@kernel.org \
--cc=guoren@kernel.org \
--cc=howardchu95@gmail.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jirislaby@kernel.org \
--cc=john.g.garry@oracle.com \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=leo.yan@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=maobibo@loongson.cn \
--cc=mark.rutland@arm.com \
--cc=mike.leach@linaro.org \
--cc=mingo@redhat.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
/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.