BPF List
 help / color / mirror / Atom feed
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
> 

  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