| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAP-5=fW7m0AVVn42XK9s=RFmAs63mh4Mk5QehpLKLFMAGje+9A@mail.gmail.com>
Date: Fri, 8 Nov 2024 10:45:54 -0800
From: Ian Rogers <irogers@...gle.com>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>, Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>, Kan Liang <kan.liang@...ux.intel.com>,
John Garry <john.g.garry@...cle.com>, Will Deacon <will@...nel.org>,
James Clark <james.clark@...aro.org>, Mike Leach <mike.leach@...aro.org>,
Leo Yan <leo.yan@...ux.dev>, Guo Ren <guoren@...nel.org>,
Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>, Nick Terrell <terrelln@...com>,
"Masami Hiramatsu (Google)" <mhiramat@...nel.org>, Changbin Du <changbin.du@...wei.com>,
Guilherme Amadio <amadio@...too.org>, Yang Jihong <yangjihong@...edance.com>,
Aditya Gupta <adityag@...ux.ibm.com>, Athira Rajeev <atrajeev@...ux.vnet.ibm.com>,
Masahiro Yamada <masahiroy@...nel.org>, Bibo Mao <maobibo@...ngson.cn>,
Huacai Chen <chenhuacai@...nel.org>, Kajol Jain <kjain@...ux.ibm.com>,
Atish Patra <atishp@...osinc.com>, Shenlin Liang <liangshenlin@...incomputing.com>,
Anup Patel <anup@...infault.org>, Oliver Upton <oliver.upton@...ux.dev>,
"Steinar H. Gunderson" <sesse@...gle.com>, "Dr. David Alan Gilbert" <linux@...blig.org>,
Chen Pei <cp0613@...ux.alibaba.com>, Dima Kogan <dima@...retsauce.net>,
Przemek Kitszel <przemyslaw.kitszel@...el.com>, "David S. Miller" <davem@...emloft.net>,
Alexander Lobakin <aleksander.lobakin@...el.com>, linux-kernel@...r.kernel.org,
linux-perf-users@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-csky@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v3 04/20] perf disasm: Add e_machine/e_flags to struct arch
On Fri, Nov 8, 2024 at 10:38 AM Namhyung Kim <namhyung@...nel.org> wrote:
>
> On Fri, Nov 08, 2024 at 10:19:52AM -0800, Ian Rogers wrote:
> > On Fri, Nov 8, 2024 at 9:33 AM Namhyung Kim <namhyung@...nel.org> wrote:
> > >
> > > On Wed, Oct 16, 2024 at 05:25:04PM -0700, Ian Rogers wrote:
> > > > Currently functions like get_dwarf_regnum only work with the host
> > > > architecture. Carry the elf machine and flags in struct arch so that
> > > > in disassembly these can be used to allow cross platform disassembly.
> > > >
> > > > Signed-off-by: Ian Rogers <irogers@...gle.com>
> > > > ---
> > > > tools/perf/arch/arc/annotate/instructions.c | 2 ++
> > > > tools/perf/arch/arm/annotate/instructions.c | 2 ++
> > > > tools/perf/arch/arm64/annotate/instructions.c | 2 ++
> > > > tools/perf/arch/csky/annotate/instructions.c | 7 ++++++-
> > > > tools/perf/arch/loongarch/annotate/instructions.c | 2 ++
> > > > tools/perf/arch/mips/annotate/instructions.c | 2 ++
> > > > tools/perf/arch/powerpc/annotate/instructions.c | 2 ++
> > > > tools/perf/arch/riscv64/annotate/instructions.c | 2 ++
> > > > tools/perf/arch/s390/annotate/instructions.c | 2 ++
> > > > tools/perf/arch/sparc/annotate/instructions.c | 2 ++
> > > > tools/perf/arch/x86/annotate/instructions.c | 3 ++-
> > > > tools/perf/util/disasm.h | 4 ++++
> > > > 12 files changed, 30 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/tools/perf/arch/arc/annotate/instructions.c b/tools/perf/arch/arc/annotate/instructions.c
> > > > index 2f00e995c7e3..e5619770a1af 100644
> > > > --- a/tools/perf/arch/arc/annotate/instructions.c
> > > > +++ b/tools/perf/arch/arc/annotate/instructions.c
> > > > @@ -5,5 +5,7 @@ static int arc__annotate_init(struct arch *arch, char *cpuid __maybe_unused)
> > > > {
> > > > arch->initialized = true;
> > > > arch->objdump.comment_char = ';';
> > > > + arch->e_machine = EM_ARC;
> > > > + arch->e_flags = 0;
> > > > return 0;
> > > > }
> > > > diff --git a/tools/perf/arch/arm/annotate/instructions.c b/tools/perf/arch/arm/annotate/instructions.c
> > > > index 2ff6cedeb9c5..cf91a43362b0 100644
> > > > --- a/tools/perf/arch/arm/annotate/instructions.c
> > > > +++ b/tools/perf/arch/arm/annotate/instructions.c
> > > > @@ -53,6 +53,8 @@ static int arm__annotate_init(struct arch *arch, char *cpuid __maybe_unused)
> > > > arch->associate_instruction_ops = arm__associate_instruction_ops;
> > > > arch->objdump.comment_char = ';';
> > > > arch->objdump.skip_functions_char = '+';
> > > > + arch->e_machine = EM_ARM;
> > > > + arch->e_flags = 0;
> > > > return 0;
> > > >
> > > > out_free_call:
> > > > diff --git a/tools/perf/arch/arm64/annotate/instructions.c b/tools/perf/arch/arm64/annotate/instructions.c
> > > > index f86d9f4798bd..d465d093e7eb 100644
> > > > --- a/tools/perf/arch/arm64/annotate/instructions.c
> > > > +++ b/tools/perf/arch/arm64/annotate/instructions.c
> > > > @@ -113,6 +113,8 @@ static int arm64__annotate_init(struct arch *arch, char *cpuid __maybe_unused)
> > > > arch->associate_instruction_ops = arm64__associate_instruction_ops;
> > > > arch->objdump.comment_char = '/';
> > > > arch->objdump.skip_functions_char = '+';
> > > > + arch->e_machine = EM_AARCH64;
> > > > + arch->e_flags = 0;
> > > > return 0;
> > > >
> > > > out_free_call:
> > > > diff --git a/tools/perf/arch/csky/annotate/instructions.c b/tools/perf/arch/csky/annotate/instructions.c
> > > > index 5337bfb7d5fc..14270311d215 100644
> > > > --- a/tools/perf/arch/csky/annotate/instructions.c
> > > > +++ b/tools/perf/arch/csky/annotate/instructions.c
> > > > @@ -43,6 +43,11 @@ static int csky__annotate_init(struct arch *arch, char *cpuid __maybe_unused)
> > > > arch->initialized = true;
> > > > arch->objdump.comment_char = '/';
> > > > arch->associate_instruction_ops = csky__associate_ins_ops;
> > > > -
> > > > + arch->e_machine = EM_CSKY;
> > > > +#if defined(__CSKYABIV2__)
> > > > + arch->e_flags = EF_CSKY_ABIV2;
> > > > +#else
> > > > + arch->e_flags = EF_CSKY_ABIV1;
> > > > +#endif
> > >
> > > By moving this into the general code, it should take care of old systems
> > > that doesn't have the macro.
> > >
> > > In file included from util/disasm.c:109:
> > > /linux/tools/perf/arch/csky/annotate/instructions.c: In function 'csky__annotate_init':
> > > /linux/tools/perf/arch/csky/annotate/instructions.c:50:25: error: 'EF_CSKY_ABIV1' undeclared (first use in this function)
> > > 50 | arch->e_flags = EF_CSKY_ABIV1;
> > > | ^~~~~~~~~~~~~
> > > /linux/tools/perf/arch/csky/annotate/instructions.c:50:25: note: each undeclared identifier is reported only once for each function it appears in
> >
> > EF_CSKY_ABIV1 is defined in elf.h and has been there at least 5 years in libelf:
> > https://sourceware.org/git/?p=elfutils.git;a=commit;f=libelf/elf.h;h=9c82942ae7355a3226c53a92c2c73b33193c5e33
> > I suspected the issue here is missing elf.h include, but the .c file
> > is included in tools/perf/util/disasm.c and that must have a
> > transitive dependency given other things are building. Do you want me
> > to send a patch making this conditional with extra #ifdefs or re-send
> > the series?
>
> Yeah, it's unfortunate but I think we can have a small incremental diff
> here to define them if it's not there. Then I'll squash it to the
> patch.
Thanks, sgtm. Could you also explicitly include elf.h into disasm.c
rather than depending on the transitive #include? There's obviously
tech debt to not have .c files including each other to work around the
build system.
Ian
> >
> > > Also, I think __CSKYABIV2__ is defined only when the host is csky. So
> > > it'll use ABI v1 on cross env. I'm not sure if it's a problem. We may
> > > need to save the ABI somewhere in the metadata later.
> >
> > Agreed. In general we should read e_machine and e_flags from the ELF
> > file, so I'm not sure new metadata is needed. This patch is trying to
> > lay groundwork for that.
>
> I understand that. Yeah it should come from the binary.
>
> Thanks,
> Namhyung
>
Powered by blists - more mailing lists