From: Eduard Zingerman <eddyz87@gmail.com>
To: "Andrii Nakryiko" <andrii.nakryiko@gmail.com>,
"Per Sundström XP" <per.xp.sundstrom@ericsson.com>
Cc: "olsajiri@gmail.com" <olsajiri@gmail.com>,
"bpf@vger.kernel.org" <bpf@vger.kernel.org>
Subject: Re: Sv: Bad padding with bpftool btf dump .. format c
Date: Tue, 29 Nov 2022 19:38:03 +0200 [thread overview]
Message-ID: <c4a265caf1653412ac88b8e6c56a694a0d50879c.camel@gmail.com> (raw)
In-Reply-To: <CAEf4Bza8c59wH05pRaBL2hHznFVs0_yWpVy1GHexURu3Ln-a=g@mail.gmail.com>
On Wed, 2022-11-23 at 18:37 -0800, Andrii Nakryiko wrote:
> On Fri, Nov 18, 2022 at 9:26 AM Per Sundström XP
> <per.xp.sundstrom@ericsson.com> wrote:
> >
> >
> > > > ============ Vanilla ==========
> > > > struct foo {
> > > > struct {
> > > > int aa;
> > > > char ab;
> > > > } a;
> > > > long :64;
> > > > int :4;
> > > > char b;
> > > > short c;
> > > > };
> > > > offsetof(struct foo, c)=18
> > > >
> > > > ============ Custom ==========
> > > > struct foo {
> > > > long: 8;
> > > > long: 64;
> > > > long: 64;
> > > > char b;
> > > > short c;
> > > > };
> > >
> > > so I guess the issue is that the first 'long: 8' is padded to full
> > > long: 64 ?
> > >
> > > looks like btf_dump_emit_bit_padding did not take into accout the gap
> > > on the
> > > begining of the struct
> > >
> > > on the other hand you generated that header file from 'min_core_btf'
> > > btf data,
> > > which takes away all the unused fields.. it might not beeen
> > > considered as a
> > > use case before
> > >
> > > jirka
> > >
> >
> > > That could be the case, but I think the 'emit_bit_padding()' will not
> > > really have a
> > > lot to do for the non sparse headers ..
> > > /Per
> >
> >
> > Looks like something like this makes tings a lot better:
>
> yep, this helps, though changes output with padding to more verbose
> version, quite often unnecessarily. I need to thing a bit more on
> this, but the way we currently calculate alignment of a type is not
> always going to be correct. E.g., just because there is an int field,
> doesn't mean that struct actually has 4-byte alignment.
>
> We must take into account natural alignment, but also actual
> alignment, which might be different due to __attribute__((packed)).
>
> Either way, thanks for reporting!
Hi everyone,
I think the fix is simpler:
diff --git a/tools/lib/bpf/btf_dump.c b/tools/lib/bpf/btf_dump.c
index deb2bc9a0a7b..23a00818854b 100644
--- a/tools/lib/bpf/btf_dump.c
+++ b/tools/lib/bpf/btf_dump.c
@@ -860,7 +860,7 @@ static bool btf_is_struct_packed(const struct btf *btf, __u32 id,
static int chip_away_bits(int total, int at_most)
{
- return total % at_most ? : at_most;
+ return total > at_most ? at_most : total;
}
It changes the order in which btf_dump_emit_bit_padding() prints field
sizes. Right now it returns the division remainder on a first call and
full 'at_most' values at subsequent calls. For this particular example
the bit offset of 'b' is 136, so the output looks as follows:
struct foo {
long: 8; // first call pad_bits = 136 % 64 ? : 64; off_diff -= 8;
long: 64; // second call pad_bits = 128 % 64 ? : 64; off_diff -= 64; ...
long: 64;
char b;
short c;
};
This is incorrect, because compiler would always add padding between
the first and second members to account for the second member alignment.
However, my change inverts the order, which avoids the accidental
padding and gets the desired output:
============ Custom ==========
struct foo {
long: 64;
long: 64;
char: 8;
char b;
short c;
};
offsetof(struct foo, c)=18
=== BTF offsets ===
full : 'c' type_id=6 bits_offset=144
custom : 'c' type_id=3 bits_offset=144
wdyt?
>
> >
> > diff --git a/src/btf_dump.c b/src/btf_dump.c
> > index 12f7039..a8bd52a 100644
> > --- a/src/btf_dump.c
> > +++ b/src/btf_dump.c
> > @@ -881,13 +881,13 @@ static void btf_dump_emit_bit_padding(const
> > struct btf_dump *d,
> > const char *pad_type;
> > int pad_bits;
> >
> > - if (ptr_bits > 32 && off_diff > 32) {
> > + if (align > 4 && ptr_bits > 32 && off_diff > 32) {
> > pad_type = "long";
> > pad_bits = chip_away_bits(off_diff, ptr_bits);
> > - } else if (off_diff > 16) {
> > + } else if (align > 2 && off_diff > 16) {
> > pad_type = "int";
> > pad_bits = chip_away_bits(off_diff, 32);
> > - } else if (off_diff > 8) {
> > + } else if (align > 1 && off_diff > 8) {
> > pad_type = "short";
> > pad_bits = chip_away_bits(off_diff, 16);
> > } else {
> > /Per
next prev parent reply other threads:[~2022-11-29 17:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-18 10:30 Bad padding with bpftool btf dump .. format c Per Sundström XP
2022-11-18 12:42 ` Jiri Olsa
2022-11-18 15:10 ` Sv: " Per Sundström XP
2022-11-18 17:26 ` Per Sundström XP
2022-11-24 2:37 ` Andrii Nakryiko
2022-11-29 17:38 ` Eduard Zingerman [this message]
2022-11-30 0:27 ` Andrii Nakryiko
2022-11-30 2:29 ` Eduard Zingerman
2022-11-30 22:49 ` Andrii Nakryiko
2022-11-30 23:06 ` Eduard Zingerman
2022-11-30 23:11 ` Andrii Nakryiko
2022-12-05 13:54 ` Per Sundström XP
2022-12-08 19:04 ` Andrii Nakryiko
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=c4a265caf1653412ac88b8e6c56a694a0d50879c.camel@gmail.com \
--to=eddyz87@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=olsajiri@gmail.com \
--cc=per.xp.sundstrom@ericsson.com \
/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