mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	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>, Jiri Kosina <jikos@kernel.org>
Subject: Re: [PATCH 7/7] DWARF: add the config option
Date: Mon, 8 May 2017 08:15:34 +0200	[thread overview]
Message-ID: <20170508061534.4pil6hleyvkutl6e@gmail.com> (raw)
In-Reply-To: <CALCETrWan_2AVds=LfneJFDH66swPasirGBiYU+LDK15M_fBew@mail.gmail.com>


* Andy Lutomirski <luto@amacapital.net> wrote:

> I think that, if the code were sufficiently robust, it would be handy if the 
> unwinder displayed function arguments.  DWARF can do that to a limited extent.
> 
> That being said, having a simpler table format would probably cover most of the 
> use cases.

I'd say that if objtool generates the kernel's debuginfo, it all becomes a kernel 
internal matter to a large degree: we can add function argument display support as 
well and see what effect it has on data structure size and complexity - it would 
certainly be a nice improvement in oops output to see function arguments.

But it should all start from a minimum complexity step (which will be complex 
enough!) and the first step should be stack trace display, in a performance 
optimized data structure, to allow both kernel stack dumps and various tracing and 
other instrumentation facilities that make use of the kernel's dwarf-ish unwider 
as-is.

The goal of this first step would be to allow x86 to drop generating the RBP frame 
pointer:

 - This shrinks kernel text and instruction count (by 1-2% IIRC),
 - speeds up certain code paths measurably,
 - plus it also allows larger functions to use one more general purpose register.

... so it's a good thing to have, if and only if the unwinder's fragility and 
complexity does not kill us. And much of that fragility comes from who generates 
the debuginfo ...

Thanks,

	Ingo

  reply	other threads:[~2017-05-08  6:15 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 [this message]
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
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=20170508061534.4pil6hleyvkutl6e@gmail.com \
    --to=mingo@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=luto@amacapital.net \
    --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

all inboxes | Powered by JetHome®