[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240828230919.GI2130480@google.com>
Date: Wed, 28 Aug 2024 23:09:19 +0000
From: Sami Tolvanen <samitolvanen@...gle.com>
To: Petr Pavlu <petr.pavlu@...e.com>
Cc: Masahiro Yamada <masahiroy@...nel.org>,
Luis Chamberlain <mcgrof@...nel.org>,
Miguel Ojeda <ojeda@...nel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Matthew Maurer <mmaurer@...gle.com>,
Alex Gaynor <alex.gaynor@...il.com>,
Wedson Almeida Filho <wedsonaf@...il.com>,
Gary Guo <gary@...yguo.net>, Neal Gompa <neal@...pa.dev>,
Hector Martin <marcan@...can.st>, Janne Grunau <j@...nau.net>,
Asahi Linux <asahi@...ts.linux.dev>, linux-kbuild@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-modules@...r.kernel.org,
rust-for-linux@...r.kernel.org
Subject: Re: [PATCH v2 02/19] gendwarfksyms: Add symbol list handling
On Wed, Aug 28, 2024 at 02:35:29PM +0200, Petr Pavlu wrote:
> On 8/15/24 19:39, Sami Tolvanen wrote:
> > diff --git a/scripts/gendwarfksyms/dwarf.c b/scripts/gendwarfksyms/dwarf.c
> > index 65a29d0bd8f4..71cfab0553da 100644
> > --- a/scripts/gendwarfksyms/dwarf.c
> > +++ b/scripts/gendwarfksyms/dwarf.c
> > @@ -5,6 +5,48 @@
> > [...]
> > +
> > +static bool is_export_symbol(struct state *state, Dwarf_Die *die)
> > +{
> > + Dwarf_Die *source = die;
> > + Dwarf_Die origin;
> > +
> > + state->sym = NULL;
> > +
> > + /* If the DIE has an abstract origin, use it for type information. */
> > + if (get_ref_die_attr(die, DW_AT_abstract_origin, &origin))
> > + source = &origin;
> > +
> > + state->sym = symbol_get(get_name(die));
> > +
> > + /* Look up using the origin name if there are no matches. */
> > + if (!state->sym && source != die)
> > + state->sym = symbol_get(get_name(source));
> > +
> > + state->die = *source;
> > + return !!state->sym;
> > +}
>
> Sorry, I don't want to comment much on function names.. but I realized
> the name of is_export_symbol() isn't really great. The "is_" prefix
> strongly indicates that it is only a query function, yet it changes the
> state. It makes its caller process_exported_symbols() hard to understand
> on the first read.
I see your point. How would you make this more obvious? get_ doesn't
seem entirely accurate either. match_ perhaps?
Sami
Powered by blists - more mailing lists