[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1c7d9094-c893-4423-822c-4ec33ae06d1b@suse.com>
Date: Mon, 2 Sep 2024 11:52:08 +0200
From: Petr Pavlu <petr.pavlu@...e.com>
To: Sami Tolvanen <samitolvanen@...gle.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 8/29/24 01:09, Sami Tolvanen wrote:
> 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?
Looks reasonable to me.
--
Thanks,
Petr
Powered by blists - more mailing lists