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 07:36:51 +0200	[thread overview]
Message-ID: <20201023053651.GE2332608@krava> (raw)
In-Reply-To: <CAEf4BzaZa2NDz38j=J=g=9szqj=ruStE7EiSs2ueQ5rVHXYRpQ@mail.gmail.com>

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

> 
> >
> >
> > the only other workaround I can think of is to check each DW_TAG_subprogram
> > tag name with vmlinux symbol to ensure it's actually present,
> > I'll check on it, because as Mark suggested it might be good
> > for future not to completely rely on dwarf being correct, even
> > if that gcc bug gets eventually fixed
> 
> This might be a good thing to do anyways. Currently BTF contains only
> global functions, but a lot of static functions that didn't end up
> inlined are available for attachment, but because BTF info is not
> there, we can't use fentry/fexit on them. Checking against ELF symbols
> would match kallsyms, right? So we would be able to drop fn->external
> requirement and have all the attachable functions available.

right, both static and global

> 
> Have you tried this? I'm curious how good the data is and how much
> bigger BTF size is with all the functions included?

I did not realize that with droping fn->external this would bring
static functions as well, now I want to try ;-)

jirka

> 
> >
> > jirka
> >
> >
> > ---
> > diff --git a/btf_encoder.c b/btf_encoder.c
> > index e90150784282..51a370d580b7 100644
> > --- a/btf_encoder.c
> > +++ b/btf_encoder.c
> > @@ -302,8 +302,9 @@ int cu__encode_btf(struct cu *cu, int verbose, bool force,
> >
> >         cu__for_each_function(cu, core_id, fn) {
> >                 int btf_fnproto_id, btf_fn_id;
> > +               bool has_pc = !!function__addr(fn) || fn->ranges;
> >
> > -               if (fn->declaration || !fn->external)
> > +               if (!has_pc || !fn->external)
> >                         continue;
> >
> >                 btf_fnproto_id = btf_elf__add_func_proto(btfe, &fn->proto, type_id_off);
> > diff --git a/dwarf_loader.c b/dwarf_loader.c
> > index d3586aa5b0dd..4763b9118475 100644
> > --- a/dwarf_loader.c
> > +++ b/dwarf_loader.c
> > @@ -953,6 +953,7 @@ static struct function *function__new(Dwarf_Die *die, struct cu *cu)
> >                 func->declaration     = dwarf_hasattr(die, DW_AT_declaration);
> >                 func->external        = dwarf_hasattr(die, DW_AT_external);
> >                 func->abstract_origin = dwarf_hasattr(die, DW_AT_abstract_origin);
> > +               func->ranges          = dwarf_hasattr(die, DW_AT_ranges);
> >                 dwarf_tag__set_spec(func->proto.tag.priv,
> >                                     attr_type(die, DW_AT_specification));
> >                 func->accessibility   = attr_numeric(die, DW_AT_accessibility);
> > @@ -2023,8 +2024,10 @@ static int tag__recode_dwarf_type(struct tag *tag, struct cu *cu)
> >                         dtype = dwarf_cu__find_tag_by_ref(cu->priv, &dtag->abstract_origin);
> >                         if (dtype == NULL)
> >                                 dtype = dwarf_cu__find_tag_by_ref(cu->priv, &specification);
> > -                       if (dtype != NULL)
> > +                       if (dtype != NULL) {
> >                                 fn->name = tag__function(dtype->tag)->name;
> > +                               fn->external = tag__function(dtype->tag)->external;
> > +                       }
> >                         else {
> >                                 fprintf(stderr,
> >                                         "%s: couldn't find name for "
> > diff --git a/dwarves.h b/dwarves.h
> > index 7c4254eded1f..3204f69abfe5 100644
> > --- a/dwarves.h
> > +++ b/dwarves.h
> > @@ -813,6 +813,7 @@ struct function {
> >         uint8_t          virtuality:2; /* DW_VIRTUALITY_{none,virtual,pure_virtual} */
> >         uint8_t          declaration:1;
> >         uint8_t          btf:1;
> > +       uint8_t          ranges:1;
> >         int32_t          vtable_entry;
> >         struct list_head vtable_node;
> >         /* fields used by tools */
> >
> 


  reply	other threads:[~2020-10-23  5:37 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 [this message]
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
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=20201023053651.GE2332608@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.