linux-kernel - Re: [PATCH 09/23] perf annotate-data: Maintain variable type info

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAM9d7cjatKSH7hw_sC3MCmY1fYT+bDBgSpFWJg=RM2oqgL5X0A@mail.gmail.com>
Date: Tue, 19 Mar 2024 10:44:31 -0700
From: Namhyung Kim <namhyung@...nel.org>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Ian Rogers <irogers@...gle.com>, Jiri Olsa <jolsa@...nel.org>, 
	Adrian Hunter <adrian.hunter@...el.com>, Peter Zijlstra <peterz@...radead.org>, 
	Ingo Molnar <mingo@...nel.org>, LKML <linux-kernel@...r.kernel.org>, 
	linux-perf-users@...r.kernel.org, 
	Linus Torvalds <torvalds@...ux-foundation.org>, Stephane Eranian <eranian@...gle.com>, 
	Masami Hiramatsu <mhiramat@...nel.org>, linux-toolchains@...r.kernel.org, 
	linux-trace-devel@...r.kernel.org
Subject: Re: [PATCH 09/23] perf annotate-data: Maintain variable type info

On Tue, Mar 19, 2024 at 7:07 AM Arnaldo Carvalho de Melo
<acme@...nel.org> wrote:
>
> On Mon, Mar 18, 2024 at 10:51:01PM -0700, Namhyung Kim wrote:
> > As it collected basic block and variable information in each scope, it
> > now can build a state table to find matching variable at the location.
> >
> > The struct type_state is to keep the type info saved in each register
> > and stack slot.  The update_var_state() updates the table when it finds
> > variables in the current address.  It expects die_collect_vars() filled
> > a list of variables with type info and starting address.
> >
> > Signed-off-by: Namhyung Kim <namhyung@...nel.org>
> > ---
> >  tools/perf/util/annotate-data.c | 173 ++++++++++++++++++++++++++++++++
> >  tools/perf/util/dwarf-aux.c     |   4 +
> >  2 files changed, 177 insertions(+)
> >
> > diff --git a/tools/perf/util/annotate-data.c b/tools/perf/util/annotate-data.c
> > index f482ccfdaa91..8eaa06f1cee5 100644
> > --- a/tools/perf/util/annotate-data.c
> > +++ b/tools/perf/util/annotate-data.c
> > @@ -46,6 +46,62 @@ static void pr_debug_type_name(Dwarf_Die *die)
> >       free(str);
> >  }
> >
> > +/* Type information in a register, valid when ok is true */
> > +struct type_state_reg {
> > +     Dwarf_Die type;
> > +     bool ok;
> > +};
> > +
> > +/* Type information in a stack location, dynamically allocated */
> > +struct type_state_stack {
> > +     struct list_head list;
> > +     Dwarf_Die type;
> > +     int offset;
> > +     int size;
> > +     bool compound;
> > +};
> > +
> > +/* FIXME: This should be arch-dependent */
> > +#define TYPE_STATE_MAX_REGS  16
> > +
> > +/*
> > + * State table to maintain type info in each register and stack location.
> > + * It'll be updated when new variable is allocated or type info is moved
> > + * to a new location (register or stack).  As it'd be used with the
> > + * shortest path of basic blocks, it only maintains a single table.
> > + */
> > +struct type_state {
> > +     struct type_state_reg regs[TYPE_STATE_MAX_REGS];
> > +     struct list_head stack_vars;
> > +};
> > +
> > +static bool has_reg_type(struct type_state *state, int reg)
> > +{
> > +     return (unsigned)reg < ARRAY_SIZE(state->regs);
> > +}
> > +
> > +/* These declarations will be remove once they are changed to static */
> > +void init_type_state(struct type_state *state, struct arch *arch __maybe_unused);
> > +void exit_type_state(struct type_state *state);
> > +void update_var_state(struct type_state *state, struct data_loc_info *dloc,
> > +                   u64 addr, u64 insn_offset, struct die_var_type *var_types);
> > +
> > +void init_type_state(struct type_state *state, struct arch *arch __maybe_unused)
> > +{
> > +     memset(state, 0, sizeof(*state));
> > +     INIT_LIST_HEAD(&state->stack_vars);
> > +}
> > +
> > +void exit_type_state(struct type_state *state)
> > +{
> > +     struct type_state_stack *stack, *tmp;
> > +
> > +     list_for_each_entry_safe(stack, tmp, &state->stack_vars, list) {
> > +             list_del(&stack->list);
>
> list_del_init()?

Maybe.. but I'm not sure how much value it'd have as we free it right after.

Thanks,
Namhyung

>
> > +             free(stack);
> > +     }
> > +}
> > +