linux-trace-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	bpf@vger.kernel.org, x86@kernel.org,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andrii Nakryiko <andrii@kernel.org>,
	Indu Bhagat <indu.bhagat@oracle.com>,
	"Jose E. Marchesi" <jemarch@gnu.org>,
	Beau Belgrave <beaub@linux.microsoft.com>,
	Jens Remus <jremus@linux.ibm.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>, Florian Weimer <fweimer@redhat.com>,
	Sam James <sam@gentoo.org>,
	Brian Robbins <brianrob@microsoft.com>,
	Elena Zannoni <elena.zannoni@oracle.com>
Subject: Re: [RFC] New codectl(2) system call for sframe registration
Date: Wed, 23 Jul 2025 09:26:20 +0900	[thread overview]
Message-ID: <20250723092620.c208fc0d3b9d800c47f87556@kernel.org> (raw)
In-Reply-To: <2fa31347-3021-4604-bec3-e5a2d57b77b5@efficios.com>

Hi Mathieu,

On Mon, 21 Jul 2025 11:20:34 -0400
Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:

> Hi!
> 
> I've written up an RFC for a new system call to handle sframe registration
> for shared libraries. There has been interest to cover both sframe in
> the short term, but also JIT use-cases in the long term, so I'm
> covering both here in this RFC to provide the full context. Implementation
> wise we could start by only covering the sframe use-case.
> 
> I've called it "codectl(2)" for now, but I'm of course open to feedback.

Nice idea for JIT, but I doubt we need this for ELF.

> 
> For ELF, I'm including the optional pathname, build id, and debug link
> information which are really useful to translate from instruction pointers
> to executable/library name, symbol, offset, source file, line number.

For ELF file, does the kernel already know how to parse the elf header?
I just wonder what happen if user sends different information to the
kernel.

> This is what we are using in LTTng-UST and Babeltrace debug-info filter
> plugin [1], and I think this would be relevant for kernel tracers as well
> so they can make the resulting stack traces meaningful to users.
> 
> sys_codectl(2)
> =================
> 
> * arg0: unsigned int @option:
> 
> /* Additional labels can be added to enum code_opt, for extensibility. */
> 
> enum code_opt {
>      CODE_REGISTER_ELF,
>      CODE_REGISTER_JIT,
>      CODE_UNREGISTER,
> };
> 
> * arg1: void * @info
> 
> /* if (@option == CODE_REGISTER_ELF) */
> 
> /*
>   * text_start, text_end, sframe_start, sframe_end allow unwinding of the
>   * call stack.
>   *
>   * elf_start, elf_end, pathname, and either build_id or debug_link allows
>   * mapping instruction pointers to file, symbol, offset, and source file
>   * location.
>   */
> struct code_elf_info {
> :   __u64 elf_start;
>      __u64 elf_end;
>      __u64 text_start;
>      __u64 text_end;

What happen if there are multiple .text.* sections?
Or, does it used for each text section?

>      __u64 sframe_start;
>      __u64 sframe_end;
>      __u64 pathname;              /* char *, NULL if unavailable. */
> 
>      __u64 build_id;              /* char *, NULL if unavailable. */
>      __u64 debug_link_pathname;   /* char *, NULL if unavailable. */
>      __u32 build_id_len;
>      __u32 debug_link_crc;
> };
> 
> 
> /* if (@option == CODE_REGISTER_JIT) */
> 
> /*
>   * Registration of sorted JIT unwind table: The reserved memory area is
>   * of size reserved_len. Userspace increases used_len as new code is
>   * populated between text_start and text_end. This area is populated in
>   * increasing address order, and its ABI requires to have no overlapping
>   * fre. This fits the common use-case where JITs populate code into
>   * a given memory area by increasing address order. The sorted unwind
>   * tables can be chained with a singly-linked list as they become full.
>   * Consecutive chained tables are also in sorted text address order.
>   *
>   * Note: if there is an eventual use-case for unsorted jit unwind table,
>   * this would be introduced as a new "code option".
>   */
> 
> struct code_jit_info {
>      __u64 text_start;      /* text_start >= addr */
>      __u64 text_end;        /* addr < text_end */
>      __u64 unwind_head;     /* struct code_jit_unwind_table * */
> };
> 
> struct code_jit_unwind_fre {
>      /*
>       * Contains info similar to sframe, allowing unwind for a given

Hmm, why not just the sframe?
(Is there any library to generate sframe online for JIT?)

Thank you,

>       * code address range.
>       */
>      __u32 size;
>      __u32 ip_off;  /* offset from text_start */
>      __s32 cfa_off;
>      __s32 ra_off;
>      __s32 fp_off;
>      __u8 info;
> };
> 
> struct code_jit_unwind_table {
>      __u64 reserved_len;
>      __u64 used_len; /*
>                       * Incremented by userspace (store-release), read by
>                       * the kernel (load-acquire).
>                       */
>      __u64 next;     /* Chain with next struct code_jit_unwind_table. */
>      struct code_jit_unwind_fre fre[];
> };
> 
> /* if (@option == CODE_UNREGISTER) */
> 
> void *info
> 
> * arg2: size_t info_size
> 
> /*
>   * Size of @info structure, allowing extensibility. See
>   * copy_struct_from_user().
>   */
> 
> * arg3: unsigned int flags (0)
> 
> /* Flags for extensibility. */
> 
> Your feedback is welcome,
> 
> Thanks,
> 
> Mathieu
> 
> [1] https://babeltrace.org/docs/v2.0/man7/babeltrace2-filter.lttng-utils.debug-info.7/
> 
> -- 
> Mathieu Desnoyers
> EfficiOS Inc.
> https://www.efficios.com
> 


-- 
Masami Hiramatsu (Google) <mhiramat@kernel.org>

  parent reply	other threads:[~2025-07-23  0:26 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-21 15:20 [RFC] New codectl(2) system call for sframe registration Mathieu Desnoyers
2025-07-21 18:53 ` Steven Rostedt
2025-07-21 20:58   ` Mathieu Desnoyers
2025-07-21 21:15     ` Steven Rostedt
2025-07-22 13:51       ` Mathieu Desnoyers
2025-07-22 16:25         ` Steven Rostedt
2025-07-22 18:26           ` Mathieu Desnoyers
2025-07-22 19:11             ` Steven Rostedt
2025-07-22 18:56           ` Jose E. Marchesi
2025-07-22 19:17             ` Steven Rostedt
2025-07-22 21:04               ` Indu Bhagat
2025-07-22 21:13                 ` Steven Rostedt
2025-07-22 21:57                   ` Indu Bhagat
2025-07-23 15:09                   ` Mathieu Desnoyers
2025-07-23 16:29                     ` Indu Bhagat
2025-07-23 15:07                 ` Mathieu Desnoyers
2025-07-22 18:21 ` Indu Bhagat
2025-07-22 18:49   ` Mathieu Desnoyers
2025-07-23  8:16     ` Indu Bhagat
2025-07-23 14:32       ` Mathieu Desnoyers
2025-07-23  0:26 ` Masami Hiramatsu [this message]
2025-07-23 15:15   ` Mathieu Desnoyers

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=20250723092620.c208fc0d3b9d800c47f87556@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=andrii@kernel.org \
    --cc=axboe@kernel.dk \
    --cc=beaub@linux.microsoft.com \
    --cc=bpf@vger.kernel.org \
    --cc=brianrob@microsoft.com \
    --cc=elena.zannoni@oracle.com \
    --cc=fweimer@redhat.com \
    --cc=indu.bhagat@oracle.com \
    --cc=jemarch@gnu.org \
    --cc=jolsa@kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=jremus@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sam@gentoo.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /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).