All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Veronika Kabatova <vkabatov@redhat.com>,
	Andrii Nakryiko <andriin@fb.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	bpf <bpf@vger.kernel.org>, "Frank Ch. Eigler" <fche@redhat.com>,
	Mark Wielaard <mjw@redhat.com>
Subject: Re: Build failures: unresolved symbol vfs_getattr
Date: Fri, 23 Oct 2020 22:45:39 +0200	[thread overview]
Message-ID: <20201023204539.GB2495983@krava> (raw)
In-Reply-To: <CAEf4BzZzMNfBBPGeXazk0Qh8pbXMPip-i3iaSt6QqXE-tttT=A@mail.gmail.com>

On Fri, Oct 23, 2020 at 01:32:44PM -0700, Andrii Nakryiko wrote:

SNIP

> > 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?

current: 3342279
new:     4361045

so about 1MB

> 
> >
> > 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.

ok, will check

jirka

> 
> >         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);
> 
> [...]
> 


  reply	other threads:[~2020-10-23 20:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1723352278.11013122.1600093319730.JavaMail.zimbra@redhat.com>
2020-09-14 14:48 ` Build failures: unresolved symbol vfs_getattr Veronika Kabatova
2020-09-14 18:25   ` Jiri Olsa
2020-09-14 22:26     ` Andrii Nakryiko
2020-09-15  7:30       ` Jiri Olsa
2020-09-15 12:17         ` Jiri Olsa
2020-09-16  9:06           ` Jiri Olsa
2020-10-16 21:38             ` Jiri Olsa
2020-10-21 19:42               ` Jiri Olsa
2020-10-22 20:00                 ` Andrii Nakryiko
2020-10-23  5:36                   ` Jiri Olsa
2020-10-23  6:58                     ` Jiri Olsa
2020-10-23 18:22                       ` Andrii Nakryiko
2020-10-23 20:17                         ` Jiri Olsa
2020-10-23 20:32                           ` Andrii Nakryiko
2020-10-23 20:45                             ` Jiri Olsa [this message]
2020-10-23 22:02                               ` Andrii Nakryiko
2020-10-26 10:14                         ` Jiri Olsa
2020-10-26 22:06                           ` Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201023204539.GB2495983@krava \
    --to=jolsa@redhat.com \
    --cc=acme@redhat.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=fche@redhat.com \
    --cc=mjw@redhat.com \
    --cc=vkabatov@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.