All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: kexec@lists.infradead.org
Subject: [PATCH 0/2] Expose kallsyms data in vmcoreinfo note
Date: Wed, 18 May 2022 18:19:28 +0800	[thread overview]
Message-ID: <YoTIMEPAxLF9t2eo@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20220517000508.777145-1-stephen.s.brennan@oracle.com>

On 05/16/22 at 05:05pm, Stephen Brennan wrote:
> The kernel can be configured to contain a lot of introspection or
> debugging information built-in, such as ORC for unwinding stack traces,
> BTF for type information, and of course kallsyms. Debuggers could use
> this information to navigate a core dump or live system, but they need
> to be able to find it.
> 
> This patch series adds the necessary symbols into vmcoreinfo, which
> would allow a debugger to find and interpret the kallsyms table. Using
> the kallsyms data, the debugger can then lookup any symbol, allowing it
> to find ORC, BTF, or any other useful data.
> 
> This would allow a live kernel, or core dump, to be debugged without
> any DWARF debuginfo. This is useful for many cases: the debuginfo may
> not have been generated, or you may not want to deploy the large files
> everywhere you need them.
> 
> I've demonstrated a proof of concept for this at LSF/MM+BPF during a
> lighting talk. Using a work-in-progress branch of the drgn debugger, and
> an extended set of BTF generated by a patched version of dwarves, I've
> been able to open a core dump without any DWARF info and do basic tasks
> such as enumerating slab caches, block devices, tasks, and doing
> backtraces. I hope this series can be a first step toward a new
> possibility of "DWARFless debugging".

Thanks. Seems no reason to reject, even though I haven't tried drgn.
And hope it has no security issue, e.g info leakage, at least I don't
see it has. So,

Acked-by: Baoquan He <bhe@redhat.com>



WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Stephen Brennan <stephen.s.brennan@oracle.com>
Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
	akpm@linux-foundation.org,
	Nick Desaulniers <ndesaulniers@google.com>,
	Dave Young <dyoung@redhat.com>, Kees Cook <keescook@chromium.org>,
	Jiri Olsa <jolsa@kernel.org>, Stephen Boyd <swboyd@chromium.org>,
	Bixuan Cui <cuibixuan@huawei.com>,
	David Vernet <void@manifault.com>,
	Vivek Goyal <vgoyal@redhat.com>,
	Sami Tolvanen <samitolvanen@google.com>
Subject: Re: [PATCH 0/2] Expose kallsyms data in vmcoreinfo note
Date: Wed, 18 May 2022 18:19:28 +0800	[thread overview]
Message-ID: <YoTIMEPAxLF9t2eo@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20220517000508.777145-1-stephen.s.brennan@oracle.com>

On 05/16/22 at 05:05pm, Stephen Brennan wrote:
> The kernel can be configured to contain a lot of introspection or
> debugging information built-in, such as ORC for unwinding stack traces,
> BTF for type information, and of course kallsyms. Debuggers could use
> this information to navigate a core dump or live system, but they need
> to be able to find it.
> 
> This patch series adds the necessary symbols into vmcoreinfo, which
> would allow a debugger to find and interpret the kallsyms table. Using
> the kallsyms data, the debugger can then lookup any symbol, allowing it
> to find ORC, BTF, or any other useful data.
> 
> This would allow a live kernel, or core dump, to be debugged without
> any DWARF debuginfo. This is useful for many cases: the debuginfo may
> not have been generated, or you may not want to deploy the large files
> everywhere you need them.
> 
> I've demonstrated a proof of concept for this at LSF/MM+BPF during a
> lighting talk. Using a work-in-progress branch of the drgn debugger, and
> an extended set of BTF generated by a patched version of dwarves, I've
> been able to open a core dump without any DWARF info and do basic tasks
> such as enumerating slab caches, block devices, tasks, and doing
> backtraces. I hope this series can be a first step toward a new
> possibility of "DWARFless debugging".

Thanks. Seems no reason to reject, even though I haven't tried drgn.
And hope it has no security issue, e.g info leakage, at least I don't
see it has. So,

Acked-by: Baoquan He <bhe@redhat.com>


  parent reply	other threads:[~2022-05-18 10:19 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-17  0:05 [PATCH 0/2] Expose kallsyms data in vmcoreinfo note Stephen Brennan
2022-05-17  0:05 ` Stephen Brennan
2022-05-17  0:05 ` [PATCH 1/2] kallsyms: Move declarations to internal header Stephen Brennan
2022-05-17  0:05   ` Stephen Brennan
2022-05-17  0:05 ` [PATCH 2/2] vmcoreinfo: Include kallsyms symbols Stephen Brennan
2022-05-17  0:05   ` Stephen Brennan
2022-05-18 10:19 ` Baoquan He [this message]
2022-05-18 10:19   ` [PATCH 0/2] Expose kallsyms data in vmcoreinfo note Baoquan He
2022-05-23 18:00   ` Stephen Brennan
2022-05-23 18:00     ` Stephen Brennan
2022-05-25  2:39     ` Baoquan He
2022-05-25  2:39       ` Baoquan He
2022-06-13 20:39       ` Stephen Brennan
2022-06-13 20:39         ` Stephen Brennan
2022-06-13 21:26 ` Andrew Morton
2022-06-13 21:26   ` Andrew Morton
2022-06-13 21:59   ` Stephen Brennan
2022-06-13 21:59     ` Stephen Brennan
2022-06-13 22:14     ` Andrew Morton
2022-06-13 22:14       ` Andrew Morton
2022-06-13 22:33       ` Stephen Brennan
2022-06-13 22:33         ` Stephen Brennan

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=YoTIMEPAxLF9t2eo@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=kexec@lists.infradead.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.