Re: [RFC/PATCHES 00/12] pahole: Reproducible parallel DWARF loading/serial BTF encoding

Eduard Zingerman
2024-04-09T15:01:13Z

On Tue, 2024-04-09 at 07:56 -0700, Alexei Starovoitov wrote:
[...]

> I would actually go with sorted BTF, since it will probably
> make diff-ing of BTFs practical. Will be easier to track changes
> from one kernel version to another. vmlinux.h will become
> a bit more sorted too and normal diff vmlinux_6_1.h vmlinux_6_2.h
> will be possible.
> Or am I misunderstanding the sorting concept?

You understand the concept correctly, here is a sample:

[1] INT '_Bool' size=1 bits_offset=0 nr_bits=8 encoding=BOOL
[2] INT '__int128' size=16 bits_offset=0 nr_bits=128 encoding=SIGNED
[3] INT '__int128 unsigned' size=16 bits_offset=0 nr_bits=128 encoding=(none)
[4] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=(none)
[5] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[6] INT 'long int' size=8 bits_offset=0 nr_bits=64 encoding=SIGNED
[7] INT 'long long int' size=8 bits_offset=0 nr_bits=64 encoding=SIGNED
...
[15085] STRUCT 'arch_elf_state' size=0 vlen=0
[15086] STRUCT 'arch_vdso_data' size=0 vlen=0
[15087] STRUCT 'bpf_run_ctx' size=0 vlen=0
[15088] STRUCT 'dev_archdata' size=0 vlen=0
[15089] STRUCT 'dyn_arch_ftrace' size=0 vlen=0
[15090] STRUCT 'fscrypt_dummy_policy' size=0 vlen=0
...

(Sort by kind, than by vlen, than by name because sorting by name is a
bit costly, then by member properties)