dwarves.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).