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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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)






[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux