Re: [PATCH 2/3] bpf_encoder: Translate SHN_XINDEX in symbol's st_shndx values

From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andriin@fb.com>,
	dwarves@vger.kernel.org, Networking <netdev@vger.kernel.org>,
	bpf <bpf@vger.kernel.org>, Yonghong Song <yhs@fb.com>,
	Hao Luo <haoluo@google.com>, Martin KaFai Lau <kafai@fb.com>,
	Song Liu <songliubraving@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@chromium.org>,
	Joe Lawrence <joe.lawrence@redhat.com>,
	Mark Wielaard <mjw@redhat.com>
Subject: Re: [PATCH 2/3] bpf_encoder: Translate SHN_XINDEX in symbol's st_shndx values
Date: Sat, 23 Jan 2021 12:07:08 -0800	[thread overview]
Message-ID: <CAEf4BzaviAOnNc31vUjWcCK7JvEwc8_nPQTiEpxMFcoTcvNw8w@mail.gmail.com> (raw)
In-Reply-To: <20210123185143.GA117714@krava>

On Sat, Jan 23, 2021 at 10:51 AM Jiri Olsa <jolsa@redhat.com> wrote:
>
> On Fri, Jan 22, 2021 at 02:55:51PM -0800, Andrii Nakryiko wrote:
> > On Fri, Jan 22, 2021 at 12:47 PM Jiri Olsa <jolsa@redhat.com> wrote:
> > >
> > > On Thu, Jan 21, 2021 at 03:32:40PM -0800, Andrii Nakryiko wrote:
> > >
> > > SNIP
> > >
> > > > > @@ -598,9 +599,36 @@ static void collect_symbol(GElf_Sym *sym, struct funcs_layout *fl)
> > > > >                 fl->mcount_stop = sym->st_value;
> > > > >  }
> > > > >
> > > > > +static bool elf_sym__get(Elf_Data *syms, Elf_Data *syms_sec_idx_table,
> > > > > +                        int id, GElf_Sym *sym, Elf32_Word *sym_sec_idx)
> > > > > +{
> > > > > +       if (!gelf_getsym(syms, id, sym))
> > > > > +               return false;
> > > > > +
> > > > > +       *sym_sec_idx = sym->st_shndx;
> > > > > +
> > > > > +       if (sym->st_shndx == SHN_XINDEX) {
> > > > > +               if (!syms_sec_idx_table)
> > > > > +                       return false;
> > > > > +               if (!gelf_getsymshndx(syms, syms_sec_idx_table,
> > > > > +                                     id, sym, sym_sec_idx))
> > > >
> > > >
> > > > gelf_getsymshndx() is supposed to work even for cases that don't use
> > > > extended numbering, so this should work, right?
> > > >
> > > > if (!gelf_getsymshndx(syms, syms_sec_idx_table, id, sym, sym_sec_idx))
> > > >     return false;
> > > >
> > >
> > > it seems you're right, gelf_getsymshndx seem to work for
> > > both cases, I'll check
> > >
> > >
> > > > if (sym->st_shndx == SHN_XINDEX)
> > > >   *sym_sec_idx = sym->st_shndx;
> > >
> > > I don't understand this..  gelf_getsymshndx will return both
> > > symbol and proper index, no? also sym_sec_idx is already
> > > assigned from previou call
> >
> > Reading (some) implementation of gelf_getsymshndx() that I found
> > online, it won't set sym_sec_idx, if the symbol *doesn't* use extended
> > numbering. But it will still return symbol data. So to return the
>
> the latest upstream code seems to set it always,
> but I agree we should be careful

oh, then maybe it's not necessary. I honestly don't even know where
the authoritative source code of libelf is, so I just found some
random source code with Google.

>
> Mark, any insight in here? thanks
>
> > section index in all cases, we need to check again *after* we got
> > symbol, and if it's not extended, then set index manually.
>
> hum, then we should use '!=', right?
>
>   if (sym->st_shndx != SHN_XINDEX)
>     *sym_sec_idx = sym->st_shndx;

yeah, sorry, that was a typo

>
> SNIP
>
> > > > so either
> > > >
> > > > for (id = 0; id < symtab->nr_syms && elf_sym__get(symtab->syms,
> > > > symtab->syms_sec_idx_table, d, &sym, &sym_sec_idx); id++)
> > > >
> > > > or
> > > >
> > > > for (id = 0; id < symtab->nr_syms; id++)
> > > >   if (elf_sym__get(symtab->syms, symtab->syms_sec_idx_table, d, &sym,
> > > > &sym_sec_idx))
> > >
> > > if we go ahead with skipping symbols, this one seems good
> >
> > I think skipping symbols is nicer. If ELF is totally broken, then all
> > symbols are going to be ignored anyway. If it's some one-off issue for
> > a specific symbol, we'll just ignore it (unfortunately, silently).
>
> agreed, I'll use this

sounds good

>
> thanks,
> jirka
>