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(). > l > > Alan, > > > 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. - 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,
