linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Kosina <jikos@kernel.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Jiri Slaby <jslaby@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	live-patching@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	Andy Lutomirski <luto@kernel.org>
Subject: Re: [PATCH 7/7] DWARF: add the config option
Date: Tue, 9 May 2017 20:47:50 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LSU.2.20.1705092040370.26873@cbobk.fhfr.pm> (raw)
In-Reply-To: <20170507165524.cdxfuwbd5alr7v6k@treble>

On Sun, 7 May 2017, Josh Poimboeuf wrote:

> DWARF is great for debuggers.  It helps you find all the registers on 
> the stack, so you can see function arguments and local variables.  All 
> expressed in a nice compact format.
> 
> But that's overkill for unwinders.  We don't need all those registers,
> and the state machine is too complicated.  

OTOH if we make the failures in processing of those "auxiliary" 
information non-fatal (in a sense that it neither causes kernel bug nor 
does it actually corrupt the unwinding process, but the only effect is 
losing "optional" information), having this data available doesn't hurt. 

It's there anyway for builds containing debuginfo, and the information is 
all there so that it can be used by things like gdb or crash, so it seems 
natural to re-use as much as possible of it.

> Unwinders basically only need to know one thing: given an instruction 
> address and a stack pointer, where is the caller's stack frame?

Again, DWARF should be able to give us all of this (including the 
FP-fallback etc). It feels a bit silly to purposedly ignore it and 
reinvent parts of it again, instead of fixing (read: "asking toolchain 
guys to fix") the cases where we actually are not getting the proper data 
in DWARF. That's a win-win at the end of the day.

Thanks,

-- 
Jiri Kosina
SUSE Labs

  parent reply	other threads:[~2017-05-09 18:47 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-05 12:21 [PATCH 1/7] DWARF: add option to preserve unwind info Jiri Slaby
2017-05-05 12:21 ` [PATCH 2/7] DWARF: EH-frame based stack unwinding Jiri Slaby
2017-05-05 12:21 ` [PATCH 3/7] vmlinux.lds: preserve eh_frame for DWARF unwinder Jiri Slaby
2017-05-05 12:21 ` [PATCH 4/7] DWARF: initialize structures for kernel and modules Jiri Slaby
2017-05-05 12:21 ` [PATCH 5/7] unwinder: show_stack, check also ret_addr_p's contents Jiri Slaby
2017-05-05 12:21 ` [PATCH 6/7] unwinder: plug in the DWARF unwinder Jiri Slaby
2017-05-05 12:22 ` [PATCH 7/7] DWARF: add the config option Jiri Slaby
2017-05-05 19:57   ` Linus Torvalds
2017-05-06  7:19     ` Ingo Molnar
2017-05-10  7:46       ` Jiri Slaby
2017-05-06 14:24     ` Jiri Kosina
2017-05-07 16:55     ` Josh Poimboeuf
2017-05-07 17:59       ` Ingo Molnar
2017-05-07 18:08         ` hpa
2017-05-07 21:48           ` Josh Poimboeuf
2017-05-08  7:50             ` Vojtech Pavlik
2017-05-08 13:14               ` Josh Poimboeuf
2017-05-08  5:35       ` Andy Lutomirski
2017-05-08  6:15         ` Ingo Molnar
2017-05-08 14:40         ` Josh Poimboeuf
2017-05-08 18:57           ` hpa
2017-05-09  0:21       ` Andy Lutomirski
2017-05-09  1:38         ` Josh Poimboeuf
2017-05-09  2:31           ` Andy Lutomirski
2017-05-09  3:38             ` Josh Poimboeuf
2017-05-09 10:00               ` hpa
2017-05-09 14:58                 ` Josh Poimboeuf
2017-05-09 16:46                   ` H.J. Lu
2017-05-10  8:15                 ` Jiri Slaby
2017-05-10 13:09                   ` Josh Poimboeuf
2017-05-10 16:23                     ` H.J. Lu
2017-05-09 18:47       ` Jiri Kosina [this message]
2017-05-09 19:22         ` Josh Poimboeuf
2017-05-10  8:32           ` Jiri Slaby
2017-05-10 13:13             ` Josh Poimboeuf
2017-05-23  7:07             ` Peter Zijlstra
2017-05-23  7:27               ` Ingo Molnar
2017-05-19 20:53       ` Josh Poimboeuf
2017-05-19 20:57         ` H. Peter Anvin
2017-05-19 20:59         ` H. Peter Anvin
2017-05-19 21:29           ` Josh Poimboeuf
2017-05-19 21:35             ` Josh Poimboeuf
2017-05-20  5:23               ` Andy Lutomirski
2017-05-20 16:20                 ` Josh Poimboeuf
2017-05-20 17:19                   ` Josh Poimboeuf
2017-05-20 20:01                   ` H.J. Lu
2017-05-20 21:58                     ` Andy Lutomirski
2017-05-20 22:20                       ` H.J. Lu
2017-05-22 11:34                         ` Jiri Kosina
2017-05-22 14:39                           ` H.J. Lu
2017-05-22 21:07                     ` H. Peter Anvin
2017-05-22 21:37                       ` H. Peter Anvin
2017-05-22 22:11                         ` Josh Poimboeuf
2017-05-20 20:16                 ` Linus Torvalds
2017-05-20 21:56                   ` Andy Lutomirski
2017-05-20 23:00                     ` Linus Torvalds
2017-05-20 23:29                       ` Linus Torvalds
2017-05-26  6:54               ` Jiri Slaby
2017-05-26 11:29                 ` Jiri Slaby
2017-05-26 12:14                   ` Josh Poimboeuf
2017-05-22 11:12             ` Ingo Molnar
2017-05-22 21:16               ` H. Peter Anvin
2017-05-22 23:23                 ` Jiri Kosina
2017-05-23  5:49                 ` Ingo Molnar
2017-05-26 19:16                   ` hpa
2017-05-28  9:12                     ` Ingo Molnar
2017-05-10  7:39     ` Jiri Slaby
2017-05-10 12:42       ` Josh Poimboeuf
2017-05-10 12:47         ` Jiri Slaby
2017-05-10 18:11       ` Linus Torvalds

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=alpine.LSU.2.20.1705092040370.26873@cbobk.fhfr.pm \
    --to=jikos@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@redhat.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --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).