From: "Per Sundström XP" <per.xp.sundstrom@ericsson.com>
To: "olsajiri@gmail.com" <olsajiri@gmail.com>,
"andrii.nakryiko@gmail.com" <andrii.nakryiko@gmail.com>
Cc: "bpf@vger.kernel.org" <bpf@vger.kernel.org>
Subject: Re: Sv: Bad padding with bpftool btf dump .. format c
Date: Fri, 18 Nov 2022 17:26:24 +0000 [thread overview]
Message-ID: <b529c3fa5946537f96430d679b9e8a4280f03e4b.camel@ericsson.com> (raw)
In-Reply-To: <HE1PR07MB3321F2F4C156BCA6EFD3A3DBBD099@HE1PR07MB3321.eurprd07.prod.outlook.com>
> > ============ 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:
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-18 17:26 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 [this message]
2022-11-24 2:37 ` Andrii Nakryiko
2022-11-29 17:38 ` Eduard Zingerman
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=b529c3fa5946537f96430d679b9e8a4280f03e4b.camel@ericsson.com \
--to=per.xp.sundstrom@ericsson.com \
--cc=andrii.nakryiko@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=olsajiri@gmail.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