Re: Build failures: unresolved symbol vfs_getattr

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Fri, Oct 23, 2020 at 1:17 PM Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Fri, Oct 23, 2020 at 11:22:05AM -0700, Andrii Nakryiko wrote:
> > On Thu, Oct 22, 2020 at 11:58 PM Jiri Olsa <jolsa@redhat.com> wrote:
> > >
> > > On Fri, Oct 23, 2020 at 07:36:57AM +0200, Jiri Olsa wrote:
> > > > On Thu, Oct 22, 2020 at 01:00:19PM -0700, Andrii Nakryiko wrote:
> > > >
> > > > SNIP
> > > >
> > > > > >
> > > > > > hi,
> > > > > > FYI there's still no solution yet, so far the progress is:
> > > > > >
> > > > > > the proposed workaround was to use the negation -> we don't have
> > > > > > DW_AT_declaration tag, so let's find out instead which DW_TAG_subprogram
> > > > > > tags have attached code and skip them if they don't have any:
> > > > > >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060#c10
> > > > > >
> > > > > > the attached patch is doing that, but the resulting BTF is missing
> > > > > > several functions due to another bug in dwarf:
> > > > > >   https://bugzilla.redhat.com/show_bug.cgi?id=1890107
> > > > >
> > > > > It seems fine if there are only few functions (especially if those are
> > > > > unlikely to be traced). Do you have an estimate of how many functions
> > > > > have this second DWARF bug?
> > > >
> > > > it wasn't that many, I'll recheck
> > >
> > > 127 functions missing if the workaround is applied, list attached
> > >
> >
> > some of those seem pretty useful... I guess the quick workaround in
> > pahole would be to just remember function names that were emitted
> > already. The problem with that is that we can pick a version without
> > parameter names, which is not the end of the world, but certainly
> > annoying.
>
> right, we can generate them in bpftrace, but it's a shame
>
>
> >
> > But otherwise, I don't really have a good feeling what's the perfect
> > solution here...
>
> I tried the check of dwarf record against function symbols
> with adresses mentioned earlier (attached)
>
> getting more functions of course ;-)
>
> $ bpftool btf dump file ./vmlinux | grep 'FUNC '  | wc -l
> 46606
>
> compared to 22869 on the same .config with working gcc
> and current pahole

Just curious, what's the change in BTF size due to this?

>
> and resolve_btfids is happy, because there are no duplications
>
> jirka
>
>
> ---

[...]

>  static int btf_var_secinfo_cmp(const void *a, const void *b)
>  {
>         const struct btf_var_secinfo *av = a;
> @@ -72,6 +157,7 @@ struct btf_elf *btf_elf__new(const char *filename, Elf *elf)
>         if (!btfe)
>                 return NULL;
>
> +       btfe->symbols = RB_ROOT;

Can you please check what we do for per-cpu variables with ELF
symbols? Perhaps we can unify approaches. I'd also favor using a sort
+ bsearch approach instead of rb_tree, given we don't really need to
dynamically add/delete elements, it's a one-time operation to iterate
and initialize everything. Also binary search of linear arrays would
be more memory-efficient and cache-efficient, most probably.

>         btfe->in_fd = -1;
>         btfe->filename = strdup(filename);
>         if (btfe->filename == NULL)
> @@ -177,6 +263,7 @@ void btf_elf__delete(struct btf_elf *btfe)
>                         elf_end(btfe->elf);
>         }
>
> +       btfe__delete_symbols(btfe);
>         elf_symtab__delete(btfe->symtab);
>         __gobuffer__delete(&btfe->percpu_secinfo);
>         btf__free(btfe->btf);

[...]