From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Stanislav Fomichev <sdf@fomichev.me>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Stanislav Fomichev <sdf@google.com>,
Network Development <netdev@vger.kernel.org>,
bpf <bpf@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Yonghong Song <yhs@fb.com>
Subject: Re: debug annotations for bpf progs. Was: [PATCH bpf-next 1/3] bpf: preserve command of the process that loaded the program
Date: Thu, 17 Oct 2019 23:19:47 -0700 [thread overview]
Message-ID: <CAADnVQKWN87F=xnbBwwm+B04rt5HTRRmwMjepqWrgsxuS+sPHA@mail.gmail.com> (raw)
In-Reply-To: <20191017162843.GB2090@mini-arch>
On Thu, Oct 17, 2019 at 9:28 AM Stanislav Fomichev <sdf@fomichev.me> wrote:
> Tried to do the following:
>
> 1. Add: static volatile const char __annotate_source1[] = __FILE__;
> to test_rdonly_maps.c and I think it got optimized away :-/
> At least I don't see it in the 'bpftool btf dump' output.
>
> 2. Add: char __annotate_source2[] SEC(".meta") = __FILE__;
> to test_rdonly_maps.c and do all the required plumbing in libbpf
> to treat .meta like .rodata. I think it works, but the map
> disappears after bpftool exits because this data is not referenced
> in the prog and the refcount drops to zero :-(
>
> Am I missing something?
"Some assembly required".
I think first variant should work at the end.
I don't think extra section should be a requirement.
Sounds like with 2 it's pretty close. Just need to make sure
that prog side sees the map as referenced.
And more importantly bpftool can find that map from prog later.
prev parent reply other threads:[~2019-10-18 6:20 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-11 16:21 [PATCH bpf-next 1/3] bpf: preserve command of the process that loaded the program Stanislav Fomichev
2019-10-11 16:21 ` [PATCH bpf-next 2/3] tools/bpf: sync bpf.h Stanislav Fomichev
2019-10-11 16:21 ` [PATCH bpf-next 3/3] bpftool: print the comm of the process that loaded the program Stanislav Fomichev
2019-10-11 20:19 ` Martin Lau
2019-10-11 20:37 ` Stanislav Fomichev
2019-10-11 21:11 ` Arnaldo Carvalho de Melo
2019-10-11 21:30 ` Stanislav Fomichev
2019-10-12 0:10 ` [PATCH bpf-next 1/3] bpf: preserve command " Alexei Starovoitov
2019-10-12 0:38 ` Stanislav Fomichev
2019-10-15 21:21 ` debug annotations for bpf progs. Was: " Alexei Starovoitov
2019-10-15 22:14 ` Andrii Nakryiko
2019-10-15 22:24 ` Alexei Starovoitov
2019-10-15 22:33 ` Andrii Nakryiko
2019-10-15 22:48 ` Alexei Starovoitov
2019-10-15 22:26 ` Stanislav Fomichev
2019-10-16 14:01 ` Daniel Borkmann
2019-10-17 16:28 ` Stanislav Fomichev
2019-10-18 6:19 ` Alexei Starovoitov [this message]
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='CAADnVQKWN87F=xnbBwwm+B04rt5HTRRmwMjepqWrgsxuS+sPHA@mail.gmail.com' \
--to=alexei.starovoitov@gmail.com \
--cc=andrii.nakryiko@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=sdf@fomichev.me \
--cc=sdf@google.com \
--cc=yhs@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.