All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Andrii Nakryiko <andrii@kernel.org>
Cc: dwarves@vger.kernel.org, bpf@vger.kernel.org, kernel-team@fb.com,
	ast@kernel.org, Andrii Nakryiko <andriin@fb.com>
Subject: Re: [PATCH v2 dwarves 1/8] btf_loader: use libbpf to load BTF
Date: Fri, 9 Oct 2020 11:53:43 -0300	[thread overview]
Message-ID: <20201009145343.GA322246@kernel.org> (raw)
In-Reply-To: <20201008234000.740660-2-andrii@kernel.org>

Em Thu, Oct 08, 2020 at 04:39:53PM -0700, Andrii Nakryiko escreveu:
> From: Andrii Nakryiko <andriin@fb.com>
> 
> Switch BTF loading to completely use libbpf's own struct btf and related APIs.
> BTF encoding is still happening with pahole's own code, so these two code
> paths are not sharing anything now. String fetching is happening based on
> whether btfe->strings were set to non-NULL pointer by btf_encoder.

While testing this one I noticed a problem, but it isn't caused by this
particular patch:

[acme@five pahole]$ cp ~/git/build/v5.9-rc6+/net/ipv4/tcp_ipv4.o .
[acme@five pahole]$ readelf -SW tcp_ipv4.o | grep BTF
[acme@five pahole]$ pahole -J tcp_ipv4.o
[acme@five pahole]$ readelf -SW tcp_ipv4.o | grep BTF
  [105] .BTF              PROGBITS        0000000000000000 0fbb3c 03f697 00      0   0  1
[acme@five pahole]$ ./btfdiff tcp_ipv4.o
--- /tmp/btfdiff.dwarf.BDAvGi	2020-10-09 11:41:45.161509391 -0300
+++ /tmp/btfdiff.btf.p81icw	2020-10-09 11:41:45.177509720 -0300
@@ -4056,7 +4056,7 @@ struct tcp_congestion_ops {
 	u32                        (*min_tso_segs)(struct sock *); /*    96     8 */
 	u32                        (*sndbuf_expand)(struct sock *); /*   104     8 */
 	void                       (*cong_control)(struct sock *, const struct rate_sample  *); /*   112     8 */
-	size_t                     (*get_info)(struct sock *, u32, int *, union tcp_cc_info *); /*   120     8 */
+	size_t                     (*get_info)(struct sock *, u32, int *, struct tcp_cc_info *); /*   120     8 */
 	/* --- cacheline 2 boundary (128 bytes) --- */
 	char                       name[16];             /*   128    16 */
 	struct module *            owner;                /*   144     8 */
[acme@five pahole]$ git log --oneline -5
ef4f971a9cf745fc (HEAD) dwarf_loader: Conditionally define DW_AT_alignment
cc3f9dce3378280f pahole: Implement --packed
08f49262f474370a man-pages: Fix 'coimbine' typo
fdc639188cb514e4 (tag: v1.18) dwarves: Prep v1.18
70c3e669709b6351 spec: Set the build type to 'Release'
[acme@five pahole]$

And looking at the source code it is a union:

include/net/tcp.h

        size_t (*get_info)(struct sock *sk, u32 ext, int *attr,
                           union tcp_cc_info *info);


So this tcp_cc_info isn't available in DWARF and thus isn't available in
the resulting BTF:

[acme@five pahole]$ pahole -F dwarf -C tcp_cc_info tcp_ipv4.o
pahole: type 'tcp_cc_info' not found
[acme@five pahole]$ pahole -F btf -C tcp_cc_info tcp_ipv4.o
pahole: type 'tcp_cc_info' not found
[acme@five pahole]$


If you look at /sys/kernel/btf/vmlinux it is there:

[acme@five pahole]$ pahole tcp_cc_info
union tcp_cc_info {
	struct tcpvegas_info       vegas;              /*     0    16 */
	struct tcp_dctcp_info      dctcp;              /*     0    16 */
	struct tcp_bbr_info        bbr;                /*     0    20 */
};
[acme@five pahole]$

I.e. when encoding vmlinux we're good and for the BTF use case so far
this is thus not a problem, will continue processing your patches and
then later try to figure this out.

For completeness when looking at tcp_congestion_ops using
/sys/kernel/btf/vmlinux, all is ok:

[acme@five pahole]$ pahole tcp_congestion_ops
struct tcp_congestion_ops {
	struct list_head           list;                 /*     0    16 */
	u32                        key;                  /*    16     4 */
	u32                        flags;                /*    20     4 */
	void                       (*init)(struct sock *); /*    24     8 */
	void                       (*release)(struct sock *); /*    32     8 */
	u32                        (*ssthresh)(struct sock *); /*    40     8 */
	void                       (*cong_avoid)(struct sock *, u32, u32); /*    48     8 */
	void                       (*set_state)(struct sock *, u8); /*    56     8 */
	/* --- cacheline 1 boundary (64 bytes) --- */
	void                       (*cwnd_event)(struct sock *, enum tcp_ca_event); /*    64     8 */
	void                       (*in_ack_event)(struct sock *, u32); /*    72     8 */
	u32                        (*undo_cwnd)(struct sock *); /*    80     8 */
	void                       (*pkts_acked)(struct sock *, const struct ack_sample  *); /*    88     8 */
	u32                        (*min_tso_segs)(struct sock *); /*    96     8 */
	u32                        (*sndbuf_expand)(struct sock *); /*   104     8 */
	void                       (*cong_control)(struct sock *, const struct rate_sample  *); /*   112     8 */
	size_t                     (*get_info)(struct sock *, u32, int *, union tcp_cc_info *); /*   120     8 */
	/* --- cacheline 2 boundary (128 bytes) --- */
	char                       name[16];             /*   128    16 */
	struct module *            owner;                /*   144     8 */

	/* size: 152, cachelines: 3, members: 18 */
	/* last cacheline: 24 bytes */
};
[acme@five pahole]$

And a btfdiff on vmlinux also shows BTF and DWARF produce the same
results:

[acme@five pahole]$ cp ~/git/build/bpf-next-v5.9.0-rc8+/vmlinux .
[acme@five pahole]$ readelf -SW vmlinux  | grep BTF
  [24] .BTF              PROGBITS        ffffffff82494ac0 1694ac0 340207 00   A  0   0  1
  [25] .BTF_ids          PROGBITS        ffffffff827d4cc8 19d4cc8 0000a4 00   A  0   0  1
[acme@five pahole]$ ./btfdiff vmlinux
[acme@five pahole]$

- Arnaldo

  reply	other threads:[~2020-10-09 14:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-08 23:39 [PATCH v2 dwarves 0/8] Switch BTF loading and encoding to libbpf APIs Andrii Nakryiko
2020-10-08 23:39 ` [PATCH v2 dwarves 1/8] btf_loader: use libbpf to load BTF Andrii Nakryiko
2020-10-09 14:53   ` Arnaldo Carvalho de Melo [this message]
2020-10-09 17:49     ` Andrii Nakryiko
2020-10-08 23:39 ` [PATCH v2 dwarves 2/8] btf_encoder: use libbpf APIs to encode BTF type info Andrii Nakryiko
2020-10-08 23:39 ` [PATCH v2 dwarves 3/8] btf_encoder: fix emitting __ARRAY_SIZE_TYPE__ as index range type Andrii Nakryiko
2020-10-08 23:39 ` [PATCH v2 dwarves 4/8] btf_encoder: discard CUs after BTF encoding Andrii Nakryiko
2020-10-09 15:47   ` Arnaldo Carvalho de Melo
2020-10-08 23:39 ` [PATCH v2 dwarves 5/8] btf_encoder: revamp how per-CPU variables are encoded Andrii Nakryiko
2020-10-09 15:53   ` Arnaldo Carvalho de Melo
2020-10-08 23:39 ` [PATCH v2 dwarves 6/8] dwarf_loader: increase the size of lookup hash map Andrii Nakryiko
2020-10-08 23:39 ` [PATCH v2 dwarves 7/8] strings: use BTF's string APIs for strings management Andrii Nakryiko
2020-10-08 23:40 ` [PATCH v2 dwarves 8/8] btf_encoder: support cross-compiled ELF binaries with different endianness Andrii Nakryiko
2020-10-09 16:22 ` [PATCH v2 dwarves 0/8] Switch BTF loading and encoding to libbpf APIs Arnaldo Carvalho de Melo
2020-10-09 17:59   ` 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=20201009145343.GA322246@kernel.org \
    --to=acme@kernel.org \
    --cc=andrii@kernel.org \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=dwarves@vger.kernel.org \
    --cc=kernel-team@fb.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.