On Mon, Oct 27, 2025 at 12:09:11PM -0300, Arnaldo Carvalho de Melo wrote: > On Mon, Oct 27, 2025 at 11:58:43AM -0300, Arnaldo Carvalho de Melo wrote: > > On Thu, Oct 23, 2025 at 08:42:34AM -0700, Alexei Starovoitov wrote: > > > On Thu, Oct 23, 2025 at 12:50 AM Jiayuan Chen <[email protected]> > > > wrote: > > > > thanks, but version 1.30 didn't work in my tests - even pahole's master > > > > branch fails, only the next branch works... > > > > > > It seems that the 'old' pahole parses some kfuncs incorrectly, for > > > > example bpf_dynptr_slice().
> > > the introduction of the 'next' branch screwed up the workflow for many > > > people. > > > Let's remove it and merge everything into master. > > > People expect master branch to be the one where active development > > > is happening and the source of truth for the latest features. > > My bad, I've been away for too long, next is supposed to be with things > > for a short while, testing for a few days, for CI consumption, then move > > to master, rinse repeat. > > I think we should go back to that model. > The difference is small but can explain as has changes to the btf > loader, and the reporter, as I now checked the whole thread, says that > 'next' works for him, so I'll move what is in 'next' to 'master' now. > Just for reference since I had done it, my investigation is below. So I had some random 'korg/next' local branch and a 'korg' remote and that messed up my analysis, there are more csets in the 'next' branch, so I'm doing more tests, tomorrow I'll probably have more news. - Arnaldo > > ⬢ [acme@toolbx pahole]$ git remote update korg > Fetching korg > ⬢ [acme@toolbx pahole]$ > ⬢ [acme@toolbx pahole]$ git remote -v | grep korg > korg https://git.kernel.org/pub/scm/devel/pahole/pahole.git (fetch) > korg https://git.kernel.org/pub/scm/devel/pahole/pahole.git (push) > ⬢ [acme@toolbx pahole]$ git diff --stat korg/master korg/next > warning: refname 'korg/next' is ambiguous. > .github/scripts/build-pahole.sh | 23 +++++++++++++++++++++++ > .github/scripts/compare-functions.sh | 30 ++++++++++++++++++++++++++++++ > .github/workflows/test.yml | 4 ++-- > .github/workflows/vmtest.yml | 4 ++++ > CMakeLists.txt | 5 ----- > README | 4 ++++ > btf_loader.c | 23 ++++++++++++++++++++--- > dwarves_fprintf.c | 2 +- > 8 files changed, 84 insertions(+), 11 deletions(-) > ⬢ [acme@toolbx pahole]$ > Related to btf bitfields: > diff --git a/btf_loader.c b/btf_loader.c > index f4f9f65289b5acac..64ea68022ab04e60 100644 > --- a/btf_loader.c > +++ b/btf_loader.c > @@ -645,9 +645,15 @@ static int class__fixup_btf_bitfields(const struct > conf_load *conf, struct tag * > pos->byte_size = tag__size(type, cu); > pos->bit_size = pos->byte_size * 8; > > - /* if BTF data is incorrect and has size == 0, skip field, > - * instead of crashing */ > + /* If the BTF data is incorrect and has size == 0, skip field > + * instead of crashing. However the field can be a zero or > + * variable-length array and we still need to infer alignment. > + */ > if (pos->byte_size == 0) { > + pos->alignment = class__infer_alignment(conf, > + > pos->byte_offset, > + > tag__natural_alignment(type, cu), > + > smallest_offset); > continue; > } > > @@ -672,7 +678,18 @@ static int class__fixup_btf_bitfields(const struct > conf_load *conf, struct tag * > pos->byte_offset, > > tag__natural_alignment(type, cu), > smallest_offset); > - smallest_offset = pos->byte_offset + pos->byte_size; > + > + /* Compute the smallest offset between this field and the next > + * one. > + * > + * In case of bitfields we need to take into account the > + * actual size being used instead of the underlying type one > as > + * it could be larger, otherwise we could miss a hole. > + */ > + smallest_offset = pos->byte_offset; > + smallest_offset += pos->bitfield_size ? > + (pos->bitfield_offset + pos->bitfield_size + 7) / 8 : > + pos->byte_size; > } > > tag_type->alignment = class__infer_alignment(conf,
