From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Christoph Hellwig <hch@lst.de>
Cc: dwarves@vger.kernel.org
Subject: Re: pahole treats embedded structures a holes
Date: Thu, 28 May 2026 16:48:44 -0300 [thread overview]
Message-ID: <ahicHN7iwtCwasPj@x1> (raw)
In-Reply-To: <20260528135852.GA30243@lst.de>
On Thu, May 28, 2026 at 03:58:52PM +0200, Christoph Hellwig wrote:
> On Thu, May 28, 2026 at 10:39:34AM -0300, Arnaldo Carvalho de Melo wrote:
> > > struct rhash_head is a single pointer, so 8 bytes on x86-64, and
> > > xfs_daddr_t is also a 64-bit type, so both the 0 size and the 8
> > > byte hole are clearly wrong. The kernel .config is attached in case
> > > it matter.
> > Starting from using the BTF info, that becomes available thru sysfs as
> > soon as we load the xfs kernel module:
> This works fine on my installed distro kernel as well. But this is
> for test builds which are only going to run in a VM. I don't really
> care about DWARF vs BTF, but I do care about not having to run the
> kernel :)
Sure, I was just checking with what I had at hand, before building the
kernel, to see if the problem was there as well.
> Note that I'm also seeing this for other code than XFS, e.g. the nvme
> driver or block layer code.
> > Now I'll try with a fresh kernel build, with a default fedora kernel
> > config, will take a while, but having access to a separate .o file from
> > the kernel build process, with just DWARF info is what we need to get to
> > the state you're in, that should work, lets see why you're getting the
> > unsatisfactory results you're getting, maybe we need further info about
> > compiler versions, etc, but lets see...
> gcc (Debian 15.2.0-17) 15.2.0
acme@number:~$ pahole -C xfs_buf git/build/allmodconfig/fs/xfs/xfs_buf.o | head
struct xfs_buf {
struct rhash_head b_rhash_head; /* 0 8 */
xfs_daddr_t b_rhash_key; /* 8 8 */
int b_length; /* 16 4 */
/* XXX 4 bytes hole, try to pack */
struct lockref b_lockref __attribute__((__aligned__(8))); /* 24 80 */
/* --- cacheline 1 boundary (64 bytes) was 40 bytes ago --- */
atomic_t b_lru_ref __attribute__((__aligned__(4))); /* 104 4 */
acme@number:~$
acme@number:~$ pahole -E -C xfs_buf git/build/allmodconfig/fs/xfs/xfs_buf.o | head
struct xfs_buf {
struct rhash_head {
struct rhash_head * next; /* 0 8 */
} b_rhash_head; /* 0 8 */
/* typedef xfs_daddr_t -> __s64 */ long long int b_rhash_key; /* 8 8 */
int b_length; /* 16 4 */
/* XXX 4 bytes hole, try to pack */
struct lockref {
acme@number:~$
acme@number:~$ readelf -wi git/build/allmodconfig/fs/xfs/xfs_buf.o | grep -m1 DW_AT_producer
<e> DW_AT_producer : (indirect string, offset: 0x923f): GNU C11 16.1.1 20260515 (Red Hat 16.1.1-2) -march=znver5 -mpopcnt -msse3 -mssse3 -msse4.1 -msse4.2 -mavx2 -mno-fma4 -mno-xop -mfma -mavx512f -mbmi -mbmi2 -maes -mpclmul -mavx512vl -mavx512bw -mavx512dq -mavx512cd -mavx512vbmi -mavx512ifma -mavx512vpopcntdq -mavx512vbmi2 -mgfni -mvpclmulqdq -mavx512vnni -mavx512bitalg -mavx512bf16 -mavx512vp2intersect -madx -mabm -mno-cldemote -mclflushopt -mclwb -mclzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mmovdir64b -mmovdiri -mmwaitx -mno-pconfig -mpku -mprfchw -mno-ptwrite -mrdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize -mno-sgx -msha -mshstk -mno-tbm -mno-tsxldtrk -mvaes -mno-waitpkg -mwbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mavxvnni -mno-avx512fp16 -mno-avxifma -mno-avxvnniint8 -mno-avxneconvert -mno-cmpccxadd -mno-amx-fp16 -mprefetchi -mno-raoint -mno-amx-complex -mno-avxvnniint16 -mno-sm3 -mno-sha512 -mno-sm4 -mno-apxf -mno-usermsr -mno-avx10.1 -mno-avx10.2 -mno-amx-avx512 -mno-amx-tf32 -mno-amx-fp8 -mno-movrs -mno-amx-movrs -mno-avx512bmm --param=l1-cache-size=48 --param=l1-cache-line-size=64 --param=l2-cache-size=1024 -mtune=znver5 -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -mno-sse4a -m64 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mno-red-zone -mcmodel=kernel -mstack-protector-guard-reg=gs -mstack-protector-guard-symbol=__ref_stack_chk_guard -mindirect-branch=thunk-extern -mindirect-branch-register -mindirect-branch-cs-prefix -mfunction-return=thunk-extern -mharden-sls=all -mrecord-mcount -mfentry -mtls-dialect=gnu2 -g -O2 -std=gnu11 -p -fshort-wchar -funsigned-char -fno-common -fno-PIE -fno-strict-aliasing -fms-extensions -fcf-protection=branch -falign-jumps=1 -falign-loops=1 -fno-asynchronous-unwind-tables -fno-jump-tables -fpatchable-function-entry=64,64 -fno-delete-null-pointer-checks -fno-allow-store-data-races -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining -fstack-protector-strong -ftrivial-auto-var-init=pattern -fzero-init-padding-bits=all -fno-stack-clash-protection -fdiagnostics-show-context=2 -fzero-call-used-regs=used-gpr -fno-inline-functions-called-once -fmin-function-alignment=64 -fstrict-flex-arrays=3 -fno-strict-overflow -fstack-check=no -fconserve-stack -fno-builtin-wcslen -fsanitize=kernel-address -fasan-shadow-offset=0xdffffc0000000000 -fsanitize=bounds-strict -fsanitize=shift -fsanitize=integer-divide-by-zero -fsanitize=bool -fsanitize=enum -fsanitize-coverage=trace-pc -fsanitize-coverage=trace-cmp --param=asan-instrumentation-with-call-threshold=10000 --param=asan-stack=1 --param=asan-instrument-allocas=1 --param=asan-globals=1 --param=asan-kernel-mem-intrinsic-prefix=1
acme@number:~$
then, please take a look at this sequence:
acme@number:~$ readelf -wi git/build/allmodconfig/fs/xfs/xfs_buf.o | grep -w xfs_buf$ -B1 -A12
<1><15f59>: Abbrev Number: 76 (DW_TAG_structure_type)
<15f5a> DW_AT_name : (indirect string, offset: 0x8a96): xfs_buf
<15f5e> DW_AT_byte_size : 664
<15f60> DW_AT_alignment : 8
<15f61> DW_AT_decl_file : 49
<15f62> DW_AT_decl_line : 138
<15f63> DW_AT_decl_column : 8
<15f64> DW_AT_sibling : <0x1610b>
<2><15f68>: Abbrev Number: 4 (DW_TAG_member)
<15f69> DW_AT_name : (indirect string, offset: 0x4e54): b_rhash_head
<15f6d> DW_AT_decl_file : 49
<15f6e> DW_AT_decl_line : 146
<15f6f> DW_AT_decl_column : 20
<15f70> DW_AT_type : <0x5b22>
acme@number:~$
acme@number:~$ readelf -wi git/build/allmodconfig/fs/xfs/xfs_buf.o | grep '<5b22>' -A12
<1><5b22>: Abbrev Number: 30 (DW_TAG_structure_type)
<5b23> DW_AT_name : (indirect string, offset: 0x1bb8): rhash_head
<5b27> DW_AT_byte_size : 8
<5b28> DW_AT_decl_file : 160
<5b29> DW_AT_decl_line : 19
<5b2a> DW_AT_decl_column : 8
<5b2b> DW_AT_sibling : <0x5b3d>
<2><5b2f>: Abbrev Number: 4 (DW_TAG_member)
<5b30> DW_AT_name : (indirect string, offset: 0x123e3): next
<5b34> DW_AT_decl_file : 160
<5b35> DW_AT_decl_line : 20
<5b36> DW_AT_decl_column : 28
<5b37> DW_AT_type : <0x5b42>
acme@number:~$
iacme@number:~$ readelf -wi git/build/allmodconfig/fs/xfs/xfs_buf.o | grep '<5b42>' -A4
<1><5b42>: Abbrev Number: 8 (DW_TAG_pointer_type)
<5b43> DW_AT_byte_size : 8
<5b43> DW_AT_type : <0x5b22>
<1><5b47>: Abbrev Number: 30 (DW_TAG_structure_type)
<5b48> DW_AT_name : (indirect string, offset: 0x14c84): rhlist_head
acme@number:~$
So everything is in this CU (debug info for the .o file), at least here,
what do you see on your system?
- Arnaldo
next prev parent reply other threads:[~2026-05-28 19:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-28 5:11 pahole treats embedded structures a holes Christoph Hellwig
2026-05-28 13:39 ` Arnaldo Carvalho de Melo
2026-05-28 13:58 ` Christoph Hellwig
2026-05-28 19:48 ` Arnaldo Carvalho de Melo [this message]
2026-05-29 4:02 ` Christoph Hellwig
2026-05-29 19:28 ` Arnaldo Carvalho de Melo
-- strict thread matches above, loose matches on Subject: below --
2026-06-05 19:28 Arnaldo Carvalho de Melo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ahicHN7iwtCwasPj@x1 \
--to=acme@kernel.org \
--cc=dwarves@vger.kernel.org \
--cc=hch@lst.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox