Re: [PATCH v2 08/19] gendwarfksyms: Expand subroutine_type
From: Sami Tolvanen
Date: Thu Sep 05 2024 - 13:23:01 EST
On Tue, Sep 3, 2024 at 8:11 AM Petr Pavlu <petr.pavlu@xxxxxxxx> wrote:
>
> On 8/15/24 19:39, Sami Tolvanen wrote:
> >
> > +static int __process_subroutine_type(struct state *state, struct die *cache,
> > + Dwarf_Die *die, const char *type)
> > +{
> > + check(process(state, cache, type));
> > + check(process(state, cache, "("));
> > + check(process_linebreak(cache, 1));
> > + /* Parameters */
> > + check(process_die_container(state, cache, die, process_type,
> > + match_formal_parameter_type));
> > + check(process_linebreak(cache, -1));
> > + check(process(state, cache, ")"));
> > + process_linebreak(cache, 0);
> > + /* Return type */
> > + check(process(state, cache, "-> "));
> > + return check(process_type_attr(state, cache, die));
> > +}
>
> If I understand correctly, this formatting logic also affects the
> symtypes output. Looking at its format, I would like to propose a few
> minor changes.
Correct, it's passed directly to the symtypes output.
> Example of the current symtypes output:
> kprobe_event_cmd_init subprogram( formal_parameter pointer_type <unnamed> { s#dynevent_cmd } byte_size(8), formal_parameter pointer_type <unnamed> { base_type char byte_size(1) encoding(8) } byte_size(8), formal_parameter base_type int byte_size(4) encoding(5), ) -> base_type void
>
> Proposed changes:
> kprobe_event_cmd_init subprogram ( formal_parameter pointer_type <unnamed> { s#dynevent_cmd } byte_size(8) , formal_parameter pointer_type <unnamed> { base_type char byte_size(1) encoding(8) } byte_size(8) , formal_parameter base_type int byte_size(4) encoding(5) ) -> base_type void
> ^- (1) ^- (2) ^- (3)
>
> (1) "subprogram(" is split to "subprogram (".
> (2) A space is added prior to ",".
> (3) String ", " is removed after the last parameter.
>
> Separating each token with a whitespace matches the current genksyms
> format, makes the data trivially parsable and easy to pretty-print by
> additional tools. If some tokens are merged, as in "subprogram(", then
> such a tool needs to have extra logic to parse each word and split it
> into tokens.
Sure, that makes sense. I'll clean this up.
Sami