On Fri, Oct 23, 2020 at 1:17 PM Jiri Olsa <jolsa@xxxxxxxxxx> 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@xxxxxxxxxx> 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); [...]
