From: Indu Bhagat <indu.bhagat@oracle.com>
To: linux-toolchains@vger.kernel.org
Subject: Discussion on toolchain support for reliable stacktracing at LPC 2022
Date: Thu, 23 Jun 2022 10:34:47 -0700 [thread overview]
Message-ID: <bfe5f610-6fcc-ea70-b75a-2a2796f6d4f9@oracle.com> (raw)
Hello,
What do you think about the following activity at the LPC Plumbers 2022
@ Toolchains and Kernel track ?
Title:
Toolchain support for reliable stack tracing in the Linux kernel
Abstract:
The Linux kernel uses a two fold approach for its stack unwinding needs
-- ORC: the kernel's stack unwinding format
-- objtool: a tool to generate the unwind information by
post-processing the generated binaries
For reliable stack traces, correct and complete metadata is only one of
the pillars. The purpose of this discussion is to brainstorm the
additional components that are required in the form of toolchain
support for assisting the kernel's requirement of reliable stack traces.
Earlier at LPC 2021, we talked about the proposal to define and generate
CTF Frame unwind information in the GNU Toolchain, and also in another
session, the issues with objtool on arm64. In this session, we plan to
converge these discussions with a perspective of what toolchain support
can be provided to support objtool in the Linux kernel to begin with.
Participants: Indu Bhagat, Josh Poimboeuf, anyone else ?
I am looking at the material Mark sent (in another thread) and the
pointers in objtool session slides (from LPC 2021) meanwhile. If you
have suggestions to refine the abstract with more detailed content, that
will be welcome too.
Thanks
Indu
next reply other threads:[~2022-06-23 18:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-23 17:34 Indu Bhagat [this message]
2022-06-29 17:35 ` Discussion on toolchain support for reliable stacktracing at LPC 2022 Indu Bhagat
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=bfe5f610-6fcc-ea70-b75a-2a2796f6d4f9@oracle.com \
--to=indu.bhagat@oracle.com \
--cc=linux-toolchains@vger.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 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.