From: Alan Maguire <alan.maguire@oracle.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>, bpf@vger.kernel.org
Cc: daniel@iogearbox.net, andrii@kernel.org, eddyz87@gmail.com,
memxor@gmail.com
Subject: Re: [PATCH bpf-next 05/14] bpf: Allow names of Rust types and functions in BTF
Date: Fri, 2 Oct 2026 14:38:21 +0100 [thread overview]
Message-ID: <bb31a195-41e1-4a07-9665-2a5d0720b15d@oracle.com> (raw)
In-Reply-To: <DLUCMHNWQ956.7GB7BFNWNPYU@gmail.com>
On 02/10/2026 13:24, Alexei Starovoitov wrote:
> On Thu, Oct 01, 2026 at 06:42 PM Alan Maguire <alan.maguire@oracle.com> wrote:
>> The idea is that for tracing rust functions you could specify the rust name
>> (from DWARF DW_AT_name) in the SEC(), but to map to the actual symbol
>> address in kallsyms the decl tag that referenced that function could use
>> the DW_AT_linkage name.
>>
>> So the decl tag would have the form
>>
>> <lang>:linkage:<linkage-symbol>
>>
>> and it would reference the FUNC type id.
>>
>> Could we do similar here for the name -> symbol mapping?
>
> I don't think I got the idea.
> To help with mangle/demangle?
> bpf_prog_<tag>_write_fmt_scx_cosmos__BpfStream_
> is imo readable enough for humans.
>
Might be more relevant for Rust kernel modules ; in that case a
function like 'fmt<str>' winds up as
ffffffffc0fec430 t _RNvXs5_NtCs1DErgtJhccC_6kernel3fmtReNtB5_7Display3fmtCs7y3Drb9gYub_15rust_print_main [rust_print]
in kallsyms due to name mangling. So if we want to trace it, we'd rather be
able to do something like
SEC("fentry/rust_print/fmt<str>")
Then libbpf or other tracer can get the kallsyms name from the decl tag
for attachment.
next prev parent reply other threads:[~2026-10-02 13:38 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 19:31 [PATCH bpf-next 00/14] bpf: Support programs compiled by rust-bpf Alexei Starovoitov
2026-09-30 19:31 ` [PATCH bpf-next 01/14] bpf: Allow bitwise ops, shifts and mul/div on pointers with CAP_PERFMON Alexei Starovoitov
2026-09-30 19:31 ` [PATCH bpf-next 02/14] selftests/bpf: Add tests for ALU " Alexei Starovoitov
2026-09-30 19:31 ` [PATCH bpf-next 03/14] bpf: Treat load and store through a number as arena access Alexei Starovoitov
2026-09-30 19:31 ` [PATCH bpf-next 04/14] selftests/bpf: Add tests for arena access through numbers Alexei Starovoitov
2026-09-30 19:48 ` sashiko-bot
2026-09-30 20:22 ` bot+bpf-ci
2026-09-30 19:31 ` [PATCH bpf-next 05/14] bpf: Allow names of Rust types and functions in BTF Alexei Starovoitov
2026-09-30 20:22 ` bot+bpf-ci
2026-10-01 17:42 ` Alan Maguire
2026-10-02 12:24 ` Alexei Starovoitov
2026-10-02 13:38 ` Alan Maguire [this message]
2026-09-30 19:31 ` [PATCH bpf-next 06/14] selftests/bpf: Add tests for " Alexei Starovoitov
2026-09-30 20:22 ` bot+bpf-ci
2026-09-30 19:31 ` [PATCH bpf-next 07/14] bpf: Allow arguments without names in static " Alexei Starovoitov
2026-10-01 21:14 ` Alan Maguire
2026-09-30 19:31 ` [PATCH bpf-next 08/14] selftests/bpf: Add test for arguments without names in static functions Alexei Starovoitov
2026-10-01 21:22 ` Alan Maguire
2026-09-30 19:31 ` [PATCH bpf-next 09/14] bpf: Allow a variable in DATASEC that is smaller than its type Alexei Starovoitov
2026-09-30 19:47 ` sashiko-bot
2026-09-30 19:31 ` [PATCH bpf-next 10/14] selftests/bpf: Add tests for a variable " Alexei Starovoitov
2026-09-30 19:31 ` [PATCH bpf-next 11/14] libbpf: Keep global data in arena when the object has .arena.data Alexei Starovoitov
2026-09-30 19:46 ` sashiko-bot
2026-09-30 20:22 ` bot+bpf-ci
2026-09-30 19:31 ` [PATCH bpf-next 12/14] libbpf: Keep format strings of bpf_printk() in .rodata.str Alexei Starovoitov
2026-09-30 20:22 ` bot+bpf-ci
2026-09-30 19:31 ` [PATCH bpf-next 13/14] selftests/bpf: Add test for global data in arena Alexei Starovoitov
2026-09-30 20:22 ` bot+bpf-ci
2026-09-30 19:31 ` [PATCH bpf-next 14/14] selftests/bpf: Add test for global data of a program in Rust Alexei Starovoitov
2026-09-30 19:53 ` sashiko-bot
2026-09-30 20:22 ` bot+bpf-ci
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=bb31a195-41e1-4a07-9665-2a5d0720b15d@oracle.com \
--to=alan.maguire@oracle.com \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=memxor@gmail.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