From: Jiri Olsa <olsajiri@gmail.com>
To: "Per Sundström XP" <per.xp.sundstrom@ericsson.com>,
"Andrii Nakryiko" <andrii.nakryiko@gmail.com>
Cc: "bpf@vger.kernel.org" <bpf@vger.kernel.org>
Subject: Re: Bad padding with bpftool btf dump .. format c
Date: Fri, 18 Nov 2022 13:42:01 +0100 [thread overview]
Message-ID: <Y3d9mYrkWjrkJ9q2@krava> (raw)
In-Reply-To: <9cfc736f2b45422a50a21b90b94de04b19836682.camel@ericsson.com>
On Fri, Nov 18, 2022 at 10:30:50AM +0000, Per Sundström XP wrote:
> Hi,
>
> I don't know if this is the channel for reporting issues with the
> "bpftool dump .. format c" function.
> If this is not the one, please help me find the correct one.
>
> This bash script illustrates a problem where 'bpftool btf dump <file>
> format c': produces an incorrect 'h' file.
> I looked into it a bit, and the problem seem to be in the
> "libbpf/btfdump.c : btf_dump_emit_bit_padding()" function.
>
> I can dig into it more if you like, but first I want to report it as a
> bug.
>
> Regards,
> /Per
>
> ---- bad_padding bash script ---
> ----------------------------------------------------
> #
> # Reproduction bash script for wrong offsets
> #
> cat >foo.h <<EOF
> #pragma clang attribute push (__attribute__((preserve_access_index)),
> apply_to = record)
> struct foo {
> struct {
> int aa;
> char ab;
> } a;
> long :64;
> int :4;
> char b;
> short c;
> };
> #pragma clang attribute pop
> EOF
>
> cat >foo.c <<EOF
> #include "foo.h"
>
> #define offsetof(TYPE, MEMBER) ((long) &((TYPE*)0)->MEMBER)
>
> long foo()
> {
> long ret = 0;
> //ret += ((struct foo*)0)->a.ab;
> ret += ((struct foo*)0)->b;
> ret += ((struct foo*)0)->c;
> return ret;
> }
> EOF
>
> cat >main.c <<EOF
> #include <stdio.h>
> #include "foo.h"
>
> #define offsetof(TYPE, MEMBER) ((long) &((TYPE*)0)->MEMBER)
>
> void main(){
> printf("offsetof(struct foo, c)=%ld\n", offsetof(struct foo, c));
> }
> EOF
>
> # Vanilla header case
> printf "============ Vanilla ==========\n"
> cat foo.h | awk '/^struct foo/,/^}/'
> gcc -O0 -g -I. -o main main.c; ./main
>
> # Proudce a custom [minimized] header
> CFLAGS="-I. -ggdb -gdwarf -O2 -Wall -fpie -target bpf
> -D__TARGET_ARCH_x86"
> clang $CFLAGS -DBOOTSTRAP -c foo.c -o foo.o
> pahole --btf_encode_detached full.btf foo.o
> bpftool gen min_core_btf full.btf custom.btf foo.o
> bpftool btf dump file custom.btf format c > foo.h
>
> printf "\n============ Custom ==========\n"
> cat foo.h | awk '/^struct foo/,/^}/'
> gcc -O0 -g -I. -o main main.c; ./main
>
> printf "\n=== BTF offsets ===\n"
> printf "full : "
> /usr/sbin/bpftool btf dump file full.btf | grep "'c'"
> printf "custom : "
> /usr/sbin/bpftool btf dump file custom.btf | grep "'c'"
>
> #---------------------end of script -------------------------------
>
>
> Output of ./bad_padding.sh:
> ---
> ============ 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
> offsetof(struct foo, c)=26
>
> === BTF offsets ===
> full : 'c' type_id=6 bits_offset=144
> custom : 'c' type_id=3 bits_offset=144
>
next prev parent reply other threads:[~2022-11-18 12:42 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 [this message]
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
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=Y3d9mYrkWjrkJ9q2@krava \
--to=olsajiri@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=bpf@vger.kernel.org \
--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