Re: [PATCH 2/2] btf_encoder: Fix function generation

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Mon, Nov 16, 2020 at 07:21:45PM +0100, Jiri Olsa escreveu:
> On Mon, Nov 16, 2020 at 10:50:16AM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Nov 13, 2020 at 01:43:47PM -0800, Andrii Nakryiko escreveu:
> > > On Fri, Nov 13, 2020 at 1:29 PM Jiri Olsa <jolsa@redhat.com> wrote:
> > 
> > > > On Fri, Nov 13, 2020 at 12:56:40PM -0800, Andrii Nakryiko wrote:
> > > > > On Fri, Nov 13, 2020 at 7:13 AM Jiri Olsa <jolsa@kernel.org> wrote:
> > 
> > > > > > Current conditions for picking up function records break
> > > > > > BTF data on some gcc versions.
> > 
> > > > > > Some function records can appear with no arguments but with
> > > > > > declaration tag set, so moving the 'fn->declaration' in front
> > > > > > of other checks.
> > 
> > > > > > Then checking if argument names are present and finally checking
> > > > > > ftrace filter if it's present. If ftrace filter is not available,
> > > > > > using the external tag to filter out non external functions.
> > 
> > > > > > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > 
> > > > > I tested locally, all seems to work fine. Left few suggestions below,
> > > > > but those could be done in follow ups (or argued to not be done).
> > 
> > > > > Acked-by: Andrii Nakryiko <andrii@kernel.org>
> > 
> > > > > BTW, for some stats.
> > 
> > > > > BEFORE allowing static funcs:
> > 
> > 
> > Nowhere in the last patchkit comments is some explanation for the
> > inclusion of static functions :-\ After the first patch in the last
> > series I get:
> > 
> >   $ llvm-objcopy --remove-section=.BTF vmlinux
> >   $ readelf -SW vmlinux  | grep BTF
> >   $ pahole -J vmlinux
> >   $ bpftool btf dump file ./vmlinux | grep 'FUNC '| cut -d\' -f2 | sort > before.bpftool
> >   $ cp vmlinux vmlinux.before.all
> >   $ wc -l before.bpftool
> >   28829 before.bpftool
> 
> I think you see the original number of functions, because without
> the 'not merged' kernel patch, that added the special init section,
> pahole will fail to detect vmlinux and fall back to checking dwarf
> declarations

Indeed, I moved the verbose/force setting to the beggining of the
encoder and:

------------
Found 352 per-CPU variables!
vmlinux not detected, falling back to dwarf data
File vmlinux:
search cu '/home/acme/git/linux/arch/x86/kernel/head_64.S' for percpu global variables.
-----------------

Now I have to read that code to figure out what that "vmlinux not
detected, falling back to dwarf data" message means, as vmlinux is where
DWARF data is, so what is that isn't being "detected", /me checks...

- Arnaldo
 
> there's a verbose message for the fall back, but it is not displayed
> at the moment ;-) with the fix below you should see it:
> 
>   $ LLVM_OBJCOPY=objcopy ./pahole -V -J vmlinux >out
>   $ cat out | grep 'vmlinux not detected'
>   vmlinux not detected, falling back to dwarf data
> 
> I'll check on the verbose setup and send full patch,
> I did not expect it would not get printed, sry
> 
> so the new numebr ~41k functions is together static functions
> and init functions
> 
> jirka
> 
> 
> ---
> diff --git a/btf_encoder.c b/btf_encoder.c
> index 9b93e9963727..7efd26de5815 100644
> --- a/btf_encoder.c
> +++ b/btf_encoder.c
> @@ -584,6 +584,8 @@ int cu__encode_btf(struct cu *cu, int verbose, bool force,
>  	struct tag *pos;
>  	int err = 0;
>  
> +	btf_elf__verbose = verbose;
> +
>  	if (btfe && strcmp(btfe->filename, cu->filename)) {
>  		err = btf_encoder__encode();
>  		if (err)
> @@ -623,7 +625,6 @@ int cu__encode_btf(struct cu *cu, int verbose, bool force,
>  		}
>  	}
>  
> -	btf_elf__verbose = verbose;
>  	btf_elf__force = force;
>  	type_id_off = btf__get_nr_types(btfe->btf);
>  
> diff --git a/lib/bpf b/lib/bpf
> --- a/lib/bpf
> +++ b/lib/bpf
> @@ -1 +1 @@
> -Subproject commit ff797cc905d9c5fe9acab92d2da127342b20f80f
> +Subproject commit ff797cc905d9c5fe9acab92d2da127342b20f80f-dirty
> 

-- 

- Arnaldo